http://www.dmsolar.com/gable-fan-with-126w-solar-pa.html
solar gable fan (attach in below existing attic vent)
Tuesday, July 28, 2009
Wednesday, July 8, 2009
create ssh keys
http://pkeck.myweb.uga.edu/ssh/
---cut---
94 ssh-keygen -t dsa
95 scp id_dsa.pub root@ip23:/root/.ssh/authorized_keys2
96 ssh ip23
---cut---
HOWTO: set up ssh keys
Paul Keck, 2001
Getting Started
1. First, install OpenSSH on two UNIX machines, hurly and burly. This works best using DSA keys and SSH2 by default as far as I can tell. All the other HOWTOs I've seen seem to deal with RSA keys and SSH1, and the instructions not surprisingly fail to work with SSH2.
2. On each machine type ssh somemachine.example.com and make a connection with your regular password. This will create a .ssh dir in your home directory with the proper perms.
3. On your primary machine where you want your secret keys to live (let's say hurly), type
ssh-keygen -t dsa
This will prompt you for a secret passphrase. If this is your primary identity key, make sure to use a good passphrase. If this works right you will get two files called id_dsa and id_dsa.pub in your .ssh dir. Note: it is possible to just press the enter key when prompted for a passphrase, which will make a key with no passphrase. This is a Bad Idea ™ for an identity key, so don't do it! See below for uses of keys without passphrases.
4.
scp ~/.ssh/id_dsa.pub burly:.ssh/authorized_keys2
Copy the id_dsa.pub file to the other host's .ssh dir with the name authorized_keys2.
5. Now burly is ready to accept your ssh key. How to tell it which keys to use? The ssh-add command will do it. For a test, type
ssh-agent sh -c 'ssh-add < /dev/null && bash'
This will start the ssh-agent, add your default identity(prompting you for your passphrase), and spawn a bash shell. From this new shell you should be able to:
6.
ssh burly
This should let you in without typing a password or passphrase. Hooray! You can ssh and scp all you want from this bash shell and not have to type any password or passphrase.
Using X Windows
Now this is all well and good, but who wants to run their whole life from a single bash instance? If you use an X window system, you can type your passphrase once when you fire up X and all subprocesses will have your keys stored.
1. In the ~/.xinitrc file, modify your line which spawns windowmaker to read:
exec ssh-agent sh -c 'ssh-add
This will prompt you for your passphrase when you start up X, and then not again. All shells you spawn from X will have your keys stored.
2. This brings up a security issue- if someone comes upon your X session, they can spawn ssh sessions to burly and other hosts where you have put your id_dsa.pub information into the authorized_keys2 file. A locking screensaver like xlock is vital.
Different usernames
By default ssh assumes the same username on the remote machine. If you have a different username on the other machine, follow the normal ssh procedure:
[pkeck@hurly /]$ ssh -l paulkeck burly
More keys!
You are not limited to one public key in your authorized_keys2 file. Append as many as you like! If you, say, generated a unique private key on every machine you log into, and then appended the id_dsa.pub files to each of the other machines' authorized_keys2 file, you'd have the equivalent of a .rhosts file with two added benefits:
* Someone would need to know your passphrase to use it, so a cracker gaining access to an account on one machine will not jeopardize the other accounts. (If you foolishly use the same passphrase or, heaven forbid, id_dsa file on all the hosts, it would make it easier to exploit, so don't do that.)
* Traffic is encrypted.
This command will do it without requiring an scp and vi session:
cat foo.pub |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'
Single-purpose keys
So now you're sshing and scping your brains out. Sooner or later you'll come across one or both of these situations:
1. You want to automate some ssh/scp process to be done after hours, but can't because no one will be around to type the passphrase.
2. You want to allow an account to do some sort of ssh/scp operation on another machine, but are hesitant to append a key to your authorized_keys2 file because that essentially "opens the barn door" to anything that other account wants to do, not just the one operation you want to let it do. (This is the situation if you use a .shosts file.)
Single-purpose keys to the rescue!
1. Make yourself another key:
ssh-keygen -t dsa -f ~/.ssh/whoisit
Just press return when it asks you to assign it a passphrase- this will make a key with no passphrase required. If this works right you will get two files called whoisit and whoisit.pub in your .ssh dir.
2. cp ~/.ssh/whoisit.pub tempfile
We want to work on it a little. tempfile should consist of one really long line that looks kind of like this:
ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== pkeck@hurly.example.com
3. Edit tempfile and prepend some things to that line so that it looks like this:
command="echo I\'m `/usr/ucb/whoami` on `/usr/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
That will do what we want on Solaris; to try this example on Linux use this:
command="echo I\'m `/usr/bin/whoami` on `/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
The stuff to prepend is your command that will be run when this key is activated, and some options to keep it from being abused (hopefully). The last thing on the line is just a comment, but you probably want to set it to something meaningful.
Also, most examples I see use no-pty as an additional option, but this messes up the carriage-return/linefeediness of the output of the above example. (Try it.) I haven't looked into it enough to see why you would want it, but there you go.
4. cat tempfile |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'
Append tempfile to your authorized_keys2 file on burly.
5. To "activate" (or perhaps "detonate") the key from hurly (or anywhere that has the secret key), do this (maybe there is a better way?):
ssh -i ~/.ssh/whoisit burly
The following also works but is cumbersome:
ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && ssh burly'
You can also append this "command key" to a different account's authorized_keys2 file and trigger it from a different username. You just need the secret key. Like so:
ssh -i ~/.ssh/whoisit -l paulkeck burly'
The next leap in the pattern is something like this:
ssh -i /home/pkeck/.ssh/whoisit -l paulkeck burly'
This could be run by any user on the box if they could read your secret key, so always keep your .ssh dir and all your keys chmodded to 700 and 600 respectively.
6. You could make single-purpose keys with commands to (haven't tested all these):
*
mt -f /dev/nst0 rewind
Rewind a tape on a remote machine
*
nice -n 19 dd of=/dev/nst0
Send STDIN to that tape drive. Maybe STDIN is a tar stream from tar -cf -.
*
nice -n 19 dd if=/dev/nst0
Read stuff from there to my STDIN
*
cat claxon.au > /dev/audio
Play an alarm noise on a remote machine
*
cat - > /dev/audio
Play any sound you send on STDIN
*
cat - > /etc/dhcpd.conf
Replace /etc/dhcpd.conf with some stuff from STDIN on the triggering machine (sounds like a temp file would be better)
*
*
*
*
*
*
You can send the stuff on STDIN with something like this on the triggering machine:
ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && cat alarm.au | ssh burly'
or
ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && tar cf - /home/pkeck | ssh burly'
Maybe for that one the corresponding command to "catch" that stream would be:
cat - > ~/backups/pkeck.tar.`date +%Y%m%d.%H-%M-%S`
You get the idea! Go crazy!
Tape examples from Ed Cashin's Gettin' Fancy with SSH Keys, my inspiration for getting into this whole thing!
---cut---
94 ssh-keygen -t dsa
95 scp id_dsa.pub root@ip23:/root/.ssh/authorized_keys2
96 ssh ip23
---cut---
HOWTO: set up ssh keys
Paul Keck, 2001
Getting Started
1. First, install OpenSSH on two UNIX machines, hurly and burly. This works best using DSA keys and SSH2 by default as far as I can tell. All the other HOWTOs I've seen seem to deal with RSA keys and SSH1, and the instructions not surprisingly fail to work with SSH2.
2. On each machine type ssh somemachine.example.com and make a connection with your regular password. This will create a .ssh dir in your home directory with the proper perms.
3. On your primary machine where you want your secret keys to live (let's say hurly), type
ssh-keygen -t dsa
This will prompt you for a secret passphrase. If this is your primary identity key, make sure to use a good passphrase. If this works right you will get two files called id_dsa and id_dsa.pub in your .ssh dir. Note: it is possible to just press the enter key when prompted for a passphrase, which will make a key with no passphrase. This is a Bad Idea ™ for an identity key, so don't do it! See below for uses of keys without passphrases.
4.
scp ~/.ssh/id_dsa.pub burly:.ssh/authorized_keys2
Copy the id_dsa.pub file to the other host's .ssh dir with the name authorized_keys2.
5. Now burly is ready to accept your ssh key. How to tell it which keys to use? The ssh-add command will do it. For a test, type
ssh-agent sh -c 'ssh-add < /dev/null && bash'
This will start the ssh-agent, add your default identity(prompting you for your passphrase), and spawn a bash shell. From this new shell you should be able to:
6.
ssh burly
This should let you in without typing a password or passphrase. Hooray! You can ssh and scp all you want from this bash shell and not have to type any password or passphrase.
Using X Windows
Now this is all well and good, but who wants to run their whole life from a single bash instance? If you use an X window system, you can type your passphrase once when you fire up X and all subprocesses will have your keys stored.
1. In the ~/.xinitrc file, modify your line which spawns windowmaker to read:
exec ssh-agent sh -c 'ssh-add
This will prompt you for your passphrase when you start up X, and then not again. All shells you spawn from X will have your keys stored.
2. This brings up a security issue- if someone comes upon your X session, they can spawn ssh sessions to burly and other hosts where you have put your id_dsa.pub information into the authorized_keys2 file. A locking screensaver like xlock is vital.
Different usernames
By default ssh assumes the same username on the remote machine. If you have a different username on the other machine, follow the normal ssh procedure:
[pkeck@hurly /]$ ssh -l paulkeck burly
More keys!
You are not limited to one public key in your authorized_keys2 file. Append as many as you like! If you, say, generated a unique private key on every machine you log into, and then appended the id_dsa.pub files to each of the other machines' authorized_keys2 file, you'd have the equivalent of a .rhosts file with two added benefits:
* Someone would need to know your passphrase to use it, so a cracker gaining access to an account on one machine will not jeopardize the other accounts. (If you foolishly use the same passphrase or, heaven forbid, id_dsa file on all the hosts, it would make it easier to exploit, so don't do that.)
* Traffic is encrypted.
This command will do it without requiring an scp and vi session:
cat foo.pub |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'
Single-purpose keys
So now you're sshing and scping your brains out. Sooner or later you'll come across one or both of these situations:
1. You want to automate some ssh/scp process to be done after hours, but can't because no one will be around to type the passphrase.
2. You want to allow an account to do some sort of ssh/scp operation on another machine, but are hesitant to append a key to your authorized_keys2 file because that essentially "opens the barn door" to anything that other account wants to do, not just the one operation you want to let it do. (This is the situation if you use a .shosts file.)
Single-purpose keys to the rescue!
1. Make yourself another key:
ssh-keygen -t dsa -f ~/.ssh/whoisit
Just press return when it asks you to assign it a passphrase- this will make a key with no passphrase required. If this works right you will get two files called whoisit and whoisit.pub in your .ssh dir.
2. cp ~/.ssh/whoisit.pub tempfile
We want to work on it a little. tempfile should consist of one really long line that looks kind of like this:
ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== pkeck@hurly.example.com
3. Edit tempfile and prepend some things to that line so that it looks like this:
command="echo I\'m `/usr/ucb/whoami` on `/usr/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
That will do what we want on Solaris; to try this example on Linux use this:
command="echo I\'m `/usr/bin/whoami` on `/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
The stuff to prepend is your command that will be run when this key is activated, and some options to keep it from being abused (hopefully). The last thing on the line is just a comment, but you probably want to set it to something meaningful.
Also, most examples I see use no-pty as an additional option, but this messes up the carriage-return/linefeediness of the output of the above example. (Try it.) I haven't looked into it enough to see why you would want it, but there you go.
4. cat tempfile |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'
Append tempfile to your authorized_keys2 file on burly.
5. To "activate" (or perhaps "detonate") the key from hurly (or anywhere that has the secret key), do this (maybe there is a better way?):
ssh -i ~/.ssh/whoisit burly
The following also works but is cumbersome:
ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && ssh burly'
You can also append this "command key" to a different account's authorized_keys2 file and trigger it from a different username. You just need the secret key. Like so:
ssh -i ~/.ssh/whoisit -l paulkeck burly'
The next leap in the pattern is something like this:
ssh -i /home/pkeck/.ssh/whoisit -l paulkeck burly'
This could be run by any user on the box if they could read your secret key, so always keep your .ssh dir and all your keys chmodded to 700 and 600 respectively.
6. You could make single-purpose keys with commands to (haven't tested all these):
*
mt -f /dev/nst0 rewind
Rewind a tape on a remote machine
*
nice -n 19 dd of=/dev/nst0
Send STDIN to that tape drive. Maybe STDIN is a tar stream from tar -cf -.
*
nice -n 19 dd if=/dev/nst0
Read stuff from there to my STDIN
*
cat claxon.au > /dev/audio
Play an alarm noise on a remote machine
*
cat - > /dev/audio
Play any sound you send on STDIN
*
cat - > /etc/dhcpd.conf
Replace /etc/dhcpd.conf with some stuff from STDIN on the triggering machine (sounds like a temp file would be better)
*
*
*
*
*
*
You can send the stuff on STDIN with something like this on the triggering machine:
ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && cat alarm.au | ssh burly'
or
ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && tar cf - /home/pkeck | ssh burly'
Maybe for that one the corresponding command to "catch" that stream would be:
cat - > ~/backups/pkeck.tar.`date +%Y%m%d.%H-%M-%S`
You get the idea! Go crazy!
Tape examples from Ed Cashin's Gettin' Fancy with SSH Keys, my inspiration for getting into this whole thing!
Saturday, July 4, 2009
Bubble Tea
From: http://www.gainesville.com/article/20080531/MAGAZINE01/670473188?Title=Drink-Dessert-
Lychee Green Tea
Courtesy of Lollicup - Serves 1
Ingredients
2 ounces lychee concentrate available at Asian food stores
1 ounce sugar syrup
1/2 cup ice
13 ounces chilled freshly brewed loose leaf green tea (leaves removed after brewing)
Preparation
Mix lychee concentrate, sugar syrup and ice together. Add in loose leaf green tea. Mix in a shaker for 10 seconds.
Mango Bubble Slush
Courtesy of Lollicup - Serves 1
Ingredients
1/2 cup mango pieces
2 ounces fresh mango pulp (available at The Fresh Market or the ethnic food aisle at local grocery stores)
1 ounce sugar syrup
4 ounces water
2 cups ice
Preparation
Blend mango pieces, fresh pulp and sugar syrup together with water and ice.
Blend on low speed for an icier slush, high speed for a thicker slush. Blend on medium speed for the best result.
Add tapioca pearls (prepared acording to package directions) if desired
Taro Bubble
Courtesy of Lollicup - Serves 1
Ingredients
2 cups water
2 cups chopped taro (available at
local Asian food stores)
1/2 teaspoon salt
1 cup sugar
1 cup low-fat coconut milk
Preparation
Add taro, salt, sugar and coconut milk to boiling water. Let boil for 15 minutes. Cool and let refrigerate for an hour or until thickened.
Avocado Bubble Snow
Courtesy of Lollicup - Serves 1
Ingredients
Half avocado
2 teaspoons sugar
1 tablespoon condensed milk
2 cups ice
5 ounces low-fat milk
Preparation
Blend avocado, sugar, condensed milk, ice and low-fat milk on low to medium speed until smooth.
Bubble Tea How-To:
Bubble Tea may seem foreign at first, but it's easier to make than you might think. The tapioca pearls and jellies can be found at Asian food stores. Before adding pearls to a tea, boil them for about 15 minutes and then wash them under cool water.
Friday, July 3, 2009
set up dual network cards
http://www.physics.umd.edu/pnce/pcs-docs/Glue/linux-route-hack.html
for a system with two IP addresses. Note the multiple default routes, although the
Hacks to Fix Routing Problems on Linux
In working with linux boxes in Glued environment, we have had cause to have a couple of boxes with multiple IP addresses, and the default Red Hat network configuration scripts do not seem to work correctly for what we needed in some of these cases. This document lists the problems seen and some hacks to fix them.
Note: These fixes are called hacks for a reason. While I do use them on several production machines I am responsible for, they are hacks and there is no guarantee of any kind that they will work, or even not make things worse, for you. Use at your own risk. While constructive comments are welcome, and I'll even entertain requests for assistance with these hacks, assistance to others comes after my own work obligations and my free time is severely limitted.
Problems encountered, and hacks to fix them
The following list enumerates the problems seen:
- Single box with 2 NICs on different subnets: Only one NIC is visible outside the two local subnets (or possibly from the alternate local subnet).
- Single box with 1 NIC, but multiple IP addresses on the one NIC: AFS/kerberos issues. Machine will boot, but can only login on the console, and even then cannot su to root. Get an 'invalid IP address' when attempt to ksu. (This may also affect boxes with multiple NICs each with a separate IP address all on the same subnet, but I have not tested that situation.)
IP addresses on different subnets
The situation: A single box has multiple NICs in it, each connected to a different subnet (and therefore with distinct IP addresses). For specificity in the following, let us assume it has two NICs, one NICA having an IP address IPaddrA on the subnetA subnet. The other, NICB, has IP address IPaddrB on the subnetB subnet.
The symptoms: All machines on subnetA can see the box using IPaddrA. Similarly, boxes on subnetB can see the box using IPaddrB. I believe you should also be able to see either address ( IPaddrA or IPaddrB ) if on the other subnet ( subnetB or subnetA, respectively), but won't guarrantee it. The problem is that outside hosts, not on either local subnet (neither subnetA nor subnetB ) can only see the machine using one of the two addresses, and get no response from the other one.
Specifics: Observed with Glued Red Hat Enterprise Edition v3 for x86 based processors. Mainly seen on one box, a Dell PowerEdge 1650 with dual onboard Intel 82544EI NICs.
My analysis: Let us assume that it is IPaddrA which is visible from the outside world, and IPaddrB that is blocked. What appears to be happening is that both NICs function properly with respect to traffic on their own subnet. IPaddrA functions properly even for stuff not on subnetA; when a machine on some other net tries to contact, the subnetA gateway sends the packets to NICA, and the response goes out on NICA back to the gateway, with a source address of IPaddrA and the foreign machines IP address.
When a machine not on subnetB tries to talk to IPaddrB, things start the same. The subnetB gateway sends the packets to NICB, the linux box decides how to respond, and a response is sent out. However, the response goes out on NICA but with the IPaddrB source address. If the machine trying to be reached is on subnetA, the packets seem to get to the destination and no one complains. But if the packets are for another subnet, the router drops the packets because the source address is illegal for subnetA (as it is IPaddrB which is a subnetB address).
Hack to fix it: In the rc.machine file, use the /sbin/ip command to set up a somewhat more complicated routing scenario with a separate routing table for each subnet. For each subnet, the routing table simply goes out through the NIC if local, or through the NIC to the appropriate gateway if non-local. Then hook these tables into the routing rule based on the source IP address.
For example, if the two subnets are 172.70.12.0/23 and 172.80.24/23 on and , respectively, with 172.70.12.1 and 172.80.24.1 as the gateways you can do something like
#Set up the first subnet's routing table (we'll name it 70)
ip route flush table 70
ip route add table 70 to 172.70.12.0/23 dev eth0
ip route add table 70 to default via 172.70.12.1 dev eth0
#Set up the second subnet's routing table (we'll call it 80)
ip route flush table 80
ip route add table 80 to 172.80.24.0/23 dev eth1
ip route add table 80 to default via 172.80.24.1 dev eth1
#Create the rules to choose what table to use. Choose based on source IP
#We need to give the rules different priorities; for convenience name priority
#after the table
ip rule add from 172.70.12.0/23 table 70 priority 70
ip rule add from 172.80.24.0/23 table 80 priority 80
#Flush the cache to make effective
ip route flush cachePhysics typically puts this into a file called rc.linux-dual-net-route-hack in the sysconfig tree and calls this script from rc.machine. This seems to work fine, as the primary interface works properly even without the hack, and that is the interface used to communicate with AFS, KDC, etc. servers, so machine seems to boot OK. The extra bit of network connectivity gained by the other NIC can wait until the rc.machine script gets run.
Multiple IP addresses, single subnet
The situation: A single box has multiple IP addresses on the same subnet (in observed cases, all on the same NIC, not sure if matters). For specificity, assume it has two IP addresses, IPaddrA and IPaddrB on the subnetA subnet.
The symptoms: The machine boots fully and appears to be up and happy. However, network based logins get denied. It is possible to login on the console, but even then some problems. Most notably, attempting to ksu to root yields an error message about wrong target hostname or IP address. Basically, pure Unix stuff works, but a lot of AFS/kerberos related stuff having problems.
Specifics: Observed on a number of Glued Red Hat Enterprise Edition v3 for x86 based processors. Systems observed on include a number of Dell PowerEdge 1650s and 1750's. The systems were all using one of the onboard NICs, which were Broadcom NetXtreme BCM5704 Gigabits and Intel 82544EI Gigabits. In all cases tried, two or three IP addresses were attached to the same NIC. Note: Tried it on a Sun V20 AMD64 box, and the problem was not seen. Not sure why the difference.
My analysis: The presence of multiple IP addresses appears to be causing the system to create a rather complicated route table, with what appears to be 2N-1 default routes where is the number of IP addresses. The basic route command does not help much, showing something like:
| Destination | Gateway | GenMask | Flags | Metric | Ref | Use | Iface |
| subnetA | * | maskA | U | 0 | 0 | 0 | NICA |
| default | gatewayA | 0.0.0.0 | UG | 0 | 0 | 0 | NICA |
| default | gatewayA | 0.0.0.0 | UG | 0 | 0 | 0 | NICA |
| default | gatewayA | 0.0.0.0 | UG | 1 | 0 | 0 | NICA |
route command does not provide information to distinguish much, other than one has metric 1. Using /sbin/ip route command, we can see a bit more, e.g. entries like:
default via gatewayA dev NICA src IPaddrA
default via gatewayA dev NICA
default via gatewayA dev NICA src IPaddrA metric 1
default via gatewayA dev NICA
default via gatewayA dev NICA src IPaddrA metric 1
I am not an expert at reading route entries, but normally expect to see a single default route on a subnet, corresponding to the second line above (without the src specification.
What appears to be happening (based on interpretation of above and sniffing the network traffic), is that traffic originating from the host to hesiod or KDC or AFS servers appears to be using the second (or last) IP address as the source address. As the primary machine name is based on the first IP address, kerberos is not happy, and all the kerberos stuff appears to fail.
Hack to fix it: The solution appears to be to delete all the existing default routes and add a proper default route. This can be done manually, booting the machine into single user mode, starting up networking (e.g.
/etc/init.d/network start
and then issuing the commands route
route del default
until no more default routes are defined, and then issuing the command route del default
route add default gw gatewayA
To fix the problem in a more automated fashion, we run the following in the machines rc.machine, or more typically, create a script rc.linux-multi-ips-on-subnet-route-hack in the sysconfig tree and run that from the rc.machine file. The script consists of the lines:
echo "Fixing default route..."
#Get $GATEWAY
. /etc/sysconfig/network
RES=`route | grep default`
while [ "x$RES" != "x" ]
do
route del default
RES=`route | grep default`
done
route add default gw $GATEWAY
echo "default route should be fixed"Currently, Physics is running this from the rc.machine file, (directly or indirectly), and this appears to be working. We need to look into it a bit more and ensure nothing requiring kerberos identity is breaking due to the lateness with which this hack is applied.
Subscribe to:
Posts (Atom)