I ended up going with the EeePC (The 1000H model), because I could get the entire laptop for only a little more than repairing the screen of my MacBook (and a brand new Mac is terribly expensive). I’ve been playing with my new netbook for about a week now, and I thought I’d share some of my experiences.

The EeePC came with Windows XP preinstalled, so I promptly partitioned it down to 25g for Windows, 40g for Music and the rest (~90g) for Ubuntu-eee. I decided to go with Ubuntu-eee because of the custom kernel that supported the hardware out of the box without fiddling around. While I really really enjoy fiddling to get stuff to work, I don’t want to have to fiddle just to be able to get a working machine, especially when I’m somewhere I need to actually do some work. I almost immediately switched from the user-friendly Netbook remix interface to a classic Gnome interface, but I could see how it would be really nice for someone newer to Linux.

Here’s some of the key things (?) about my new EeePC (and Ubuntu-eee):

• I like how portable this is, it’s definitely lighter than my MacBook Pro
• It’s not ridiculously expensive like a Mac is
• I like Linux, since I tend to do all of my development on *nix systems, it’s great to have one as a main machine.
• 1024×600 is very small, especially coming from 1440×900. This is helped by fullscreen mode in things like Firefox (with Vimperator for even more screen space) and Gnome Terminal.
• Wifi and networking work great, this has always been shaky on Linux systems, I’m glad that I don’t have to fiddle for 20 minutes just to join a coffeeshop’s hotspot
• Suspend and Hibernate work great, also a big feature, especially since Apple’s sleep feature spoiled me to never turn my Mac off.
• I don’t like some of the trackpad stuff. It’s difficult to turn off the tap-to-click, attempting to install packages to manage it disable the vertical 2-finger scrolling, it’s _insanely_ sensitive (the pad, the buttons themselves are kind of stiff).
• The keyboard is great, since I got the 10″, it’s not small enough to bother me during coding sessions, which I’m sure the 8.9″ would have.
• This machine definitely has less power than I’m used to, but I make up for it by doing a lot of resource-intensive stuff on my home machine over SSH, which makes up for it.
• Con: Linux twitter clients suck. Adobe AIR clients take a ton of resources also.
• Con: Linux sound stuff still sucks, it struggles with 2 processes attempting to share the sound device using ALSA.

I would definitely _not_ recommend this device to anyone with ailing eyesight, I tend to use 8 or 9pt font for everything, and I could definitely see some eye strain for anyone who has vision trouble. Don’t get one for your grandparents unless you don’t play on much screen space being usable (or don’t do everything in the console, like I do ).

And, since I like pictures, here’s a few pictures of my new machine:

Download the script here.

Read about aimsnarf in the previous post about it.

Changes in this version:

• Trillian is now supported, as well as AOL’s AIM client. Most other clients should be supported too, I figured out the variable length/number of TLV fields in the packet, so aimsnarf is much smarter about decoding them
• Code cleaned up to be more readable
• Fixed some misc messages that were showing up, you still might see a few

Todos:

• Figure out what the heck iChat is doing, it doesn’t seem to be sending the same kind of data as all the other AIM clients
• Still do OTR stuff
• Maybe add support for different protocols?
• More testing!

If you find any bugs, send me a note or leave a comment. If you really want to help, you can send me some pcap data to analyze   If you have any feature requests, lemme know!

Firstly, download the script here.

aimsnarf.rb is a small (~200 lines) Ruby script that I’ve written to sniff and dump AOL IM messages to STDOUT. I wrote this an as alternative to aimsniff, because I really dislike having to install aimsniff and all of it’s dependancies when all I want is a simple text transcript. I really felt like the dsniff toolkit should have had something like this (they already have urlsnarf, filesnarf, etc) to be used for penetration testing.

The only thing aimsnarf requires is Ruby and the ruby-pcap library (which is waaay easier to install than the 10+ CPAN modules that aimsniff requires). After installing the pcap library, simply run aimsnarf.rb on the console, here’s the usage:

Use '-h' to display usage
Usage: aimsnarf.rb [ -dnv ] [ -i interface | -r file ] [ -c count ] [ -s snaplen ] [ filter ]
Options:
-n do not convert address to name
-d debug mode
-v verbose mode

Due to the way that ruby-pcap works, I don’t have control over the usage displayed, currently the only real options you should mess with are ‘-i interface‘ and ‘-r file‘, changing anything else might produce “unknown” consequences ;). If you want to see hex dumps of the AIM data, edit the script and change the line “ap.data_debug(0)” to be “ap.data_debug(1)“, this will display the hex data as it is received.

Ignore the “pcap.bundle: warning: do not use Fixnums as Symbols” warnings you get when you run the program, the warning lies with the ruby-pcap library, so it’s out of my hands to fix. When run correctly, you should see something like this:

****** --> <you>: <HTML>what're you up to?</HTML>
<you> --> ******: <HTML>doing some stuff</HTML>
****** --> <you>: <HTML>awesome</HTML>
<you> --> ******: <HTML>talkity talk talk</HTML>
etc, etc

“******” will be the screen name of the person that’s talking. Yes, AIM sends the HTML tags, I don’t put those on.

Tangent:
Let’s talk a little bit about how much I hate the AIM protocol
Take a look at the protocol listing as given from ethereal, you can see that each AIM packet actually holds a pretty good amount of information, turns out, AOL decided to make a ton of their fields variable length, which means a headache for me in decoding it, because the length has to be read, translated, then used to set the offset for reading the data, this is the reason the code for the script is incredibly messy, I plan on cleaning it up at a later time. In a future post, I’ll also go into more detail about how this particular script decodes the protocol (very much hackish at the moment).

Known Issues:

• Messages received by people who are away don’t get intercepted due to the packet being different than a regular incoming message packet
• Different clients might not work (depending on the features supported). Right now I’ve tested with GAIM/Pidgin and Adium, it looks like Trillian isn’t working correctly yet, although I’ve collected some data for analysis so I can get it working.
• This is probably the first *useful* script I’ve written in Ruby. I am not a ruby master so the code is really messy and probably badly written, have a problem with it? Send a patch!
• OTR encrypted chat interception doesn’t work (duh)

TODO (no particular order):

• Clean up code to make it easier to extend to different protocol/clients
• Fix the Trillian problem
• Test with AOL’s AIM client
• Fix the incoming/away message
• Correctly detect OTR chat and do (something?) about it

Remember people, don’t send credit card numbers, social security numbers, passwords, PIN numbers, etc over IM, ESPECIALLY when you’re somewhere like a coffeeshop using public wifi.

Thanks to the HeX LiveCD team for putting out a great release, already having the tools installed for use in a system is super helpful

Questions? Problems? Patches? Hatemail? Email me or leave a comment below!

Enable IPv6 on *most* Cisco switches (I used a 3750):
1. Telnet to the switch
2. Use “enable” to escalate privledges
3. configure terminal
4. sdm prefer dual-ipv4-and-ipv6 routing
5. end
6. reload (this will reboot the switch)

If you need to make sure it’s set correctly, telnet into the switch, enable and then run “show sdm prefer” and verify that it’s running ipv4-and-ipv6.

Enabling IPv6 on Solaris:
1. touch /etc/hostname6.<interfacename>
<interfacename> is the name of the hardware interface, something like ce0 or e1000g0, etc.

Enabling IPv6 on RedHat Linux
1. system-config-network, select the interface, edit the properties and check the box that says “Enable IPv6 on this interface”

Enabling IPv6 on Windows
1. ipv6 install at a command prompt.

You can test it using ping on Solaris and ping6 on Linux and Windows. Good luck!

[root@lava2054 ~]# tail /var/log/messages
Segmentation fault
[root@lava2054 ~]# dmesg
-bash: dmesg: command not found
[root@lava2054 ~]# sync;reboot
-bash: sync: command not found
reboot: error while loading shared libraries: libattr.so.1: cannot open shared object file: No such file or directory

Ack. *runs off to find the problem*

Update:

Turns out that one of the partitions in the LVM that was the / partition (I *hate* RedHat’s default partitioning) died, which caused the machine to panic every time I booted. Since I needed the particular machine by the end of the day and didn’t have a lot of time to debug what went wrong, I just performed a fresh install. Problem Fixed (If a little ungracefully).

Okay, after reading Himanshu Dwivedi’s presentation[PDF] on iSCSI security (insecure-SCSI hur hur hur) I decided to try and replicate one of the attacks that he mentioned in the presentation. Following is how I managed to get the data shown of a different machine.

Firstly, I needed to get the initiatorname for the iscsi daemon on the target host. In this case the /etc/initiatorname.iscsi file is -rw-------, so I needed a way to find out the initiator name without root privileges. In this case I used wireshark (used to be ethereal) to sniff the traffic for a plain-text initiator name. Okay, so here’s what I did:

Fire up Wireshark (Ethereal) and set it to promiscuous mode, with a filter for port 3260 (the iscsid port), feel free to filter by host, etc. Run the live capture for a while, what you’re going to be looking for is a sequence of packets that look more like this:
…
iSCSI Login Command
TCP [PSH,ACK] <other information>
TCP [ACK] <other information>
iSCSI Login Response (Success)
…
I can’t say how long it’s going to take this, but it’s much easier to get when the iscsi service is being started on the machine you’re trying to sniff, therefore, if you can sniff while a machine is coming online from a reboot you will most likely have a much better chance of detecting this.

There’s another easier way of getting what you want just doing a string search. Search for the string “Initiator” below you can see a picture what you should be looking for in Wireshark:

Note the highlighted text at the bottom, this is what you’re looking for. Copied straight out you get something like this:
`
7LrEN@@
By"p/
InitiatorName=iqn.1987-05.com.cisco:01.87956e84f925InitiatorAlias=lava2163SessionType=DiscoveryHeaderDigest=NoneDataDigest=NoneMaxRecvDataSegmentLength=8192DefaultTime2Wait=0DefaultTime2Retain=0IFMarker=NoOFMarker=NoErrorRecoveryLevel=0X-com.cisco.PingTimeout=5X-com.cisco.sendAsyncText=YesX-com.cisco.protocol=draft20

All we really care about in that text is the part that is bolded, using this, we can manually set the /etc/initiatorname.iscsi file on a different Linux server to have the line “InitiatorName=iqn.1987-05.com.cisco:01.87956e84f925“. Don’t forget to change the /etc/iscsi.conf file to have the following line in it:
DiscoveryAddress=<ip of iscsi target host>
Fill in the host with the IP address that your sniffing showed (in this case, it was 10.5.140.229 as you can see in the picture)

After this step, if this were a real attack it would probably be a good idea to preform a DOS attack on the original target to knock it out of connection with the server (you don’t really want 2 hosts attempting to get the same information from an iSCSI target). Then start the iscsi daemon with “/etc/init.d/iscsi start” and you should be seeing the data originally meant for the other host.

This is really a simple attack and barely requires any technical knowledge of iSCSI to exploit it. It’s nothing special, but it does show that you really need to implement some kind of security in your network (CHAP or whatever else suits you).

What kind of security do you use for iSCSI? CHAP? None? Leave a comment and let me know!

EDIT: Blog O’Matty has an article on the Solaris iSCSI stack in the August issue of SysAdmin magazine if you’re interested. I find his articles to be very insightful and I highly recommend checking out some of the other ones at prefetch.net. Check it out!

We are going to configure 2 machines to be in a Active/Passive failover situation, which means that if the primary machine dies, the secondary will take over its identity and continue functioning as previously.

Primary: lava2042 (10.5.140.42) (192.168.1.1 for crossover interface)
Secondary: lava2138 (10.5.140.138) (192.168.1.2 for crossover interface)
HA-address: lava2222 (10.5.140.222)

Configuring heartbeat

Step 1.
Install Heartbeat and DRBD on BOTH machines that you are planning on configuring. This should be a very straightforward step and I’m not going to go into detail.

Step 2.
We’re going to need a way to connect the machines, you can use either a crossover cable from an additional ethernet port to the other or you can use a serial cable. In this example I’m using a crossover cable.

Step 3.
Now we’re going to configure the /etc/ha.d/ha.cf file for our machine. Here is what I’ve put into the /etc/ha.d/ha.cf file ON EACH MACHINE:
bcast eth1
keepalive 2
warntime 10
deadtime 30
initdead 120
udpport 694
auto_failback on
node lava2042
node lava2138
Check this page if you have trouble or are using a serial connection instead of a crossover cable. It has instructions on how to configure this file for a serial interface.

Step 4.
Now configure the /etc/ha.d/authkeys file ON EACH MACHINE for what kind of security and file checking you want, I don’t care about security in this example so I put this is the file since it’s the fastest:
auth 2
2 crc
(See here for more information)

We’ll also need to configure the /etc/ha.d/haresources file, but we won’t do that until we get DRBD working correctly.

Configuring DRBD

Step 1.
The /etc/drbd.conf file needs to be configured. It should already have an example setup in the file. I used the already existing resource r0 and edited the nodes. Inside the “resource r0 {” bracket there should be a part that says “on <something>”. Here is what I put for my 2 nodes:
on lava2042 {
device /dev/drbd0;
disk /dev/sda1;
address 10.5.140.42:7788;
meta-disk internal;
}

on lava2138 {
device /dev/drbd0;
disk /dev/sda8;
address 10.5.140.138:7788;
meta-disk internal;
}

Now let me give a little background. I had already made the /dev/sda1 partition on lava2042 and the /dev/sda8 partition on lava2138, each 1 gig to store the data that was going to be shared. /dev/drbd0 is the device that will actually be mounted and read from. Other than that, I left the entire file to be it’s defaults. Make sure to comment out any other resources unless you need more than one filesystem replicated.

Step 2.
Make sure to load the drbd module by doing a modprobe drbd and check the dmesg command to make sure the output looks correct (Sorry, I don’t have what it should look like, I’ll keep better notes in the future).

Step 3.
Now we need to initialize our metadata for DRBD. We do this by running this on EACH machine:
drbdmeta create-md r0
Where r0 is the name of the resource from the /etc/drbd.conf file. You should now be able to run the following on each machine:
drbdadm up all
After running these two commands, you should be able to check dmesg and /proc/drbd to see the status of your filesystem.

Step 4.
The next step is to force one of the machines to be the primary and create a filesystem. In this case I’m choosing lava2042 as the primary, so I will run this on the machine:
lava2042# drbdsetup /dev/drbd0 primary -o
This will do the initial sync between the machines, you should only need to do this once. After that, run this command:
lava2042# drbdadm primary all
To force lava2042 into the primary state and make /etc/drbd0 usable. From here you can create a filesystem by doing a:
lava2042# mkfs.ext3 /dev/drbd0 (or whatever filesystem you want)
And mount the filesystem to check it out (make sure to unmount it after you’re done)

You should now be able to do a drbdadm primary all on either machine (while in a Secondary/Secondary state (check /proc/drbd)) and mount the filesystem

Step 5.
Okay, now let’s drop back into secondary mode for lava2042 by doing this:
lava2042# drbdadm secondary all
The /proc/drbd file should look something like this:
version: 8.0.3 (api:86/proto:86)
SVN Revision: 2881 build by root@lava2138, 2007-06-18 09:50:33
0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
ns:316952 nr:1221300 dw:1222380 dr:346211 al:8 bm:107 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:81456 misses:98 starving:0 dirty:0 changed:98
act_log: used:0/257 hits:262 misses:8 starving:0 dirty:0 changed:8
(Important part bolded) The filesystem needs to be in a Secondary state for both machines in order for heartbeat to work properly

And now we’re going to edit the /etc/ha.d/haresources file to take care of sharing the filesystem. Here’s what I have in the file:
lava2042 drbddisk::r0 Filesystem::/dev/drbd0::/opt/EMC::ext3 10.5.140.222 httpd
Let’s go through it line by line:
lava2042 – the machine that will be the primary node
drbddisk::r0 – activate the r0 resource disk (make sure r0 corresponds to whatever your resource is named)
Filesystem::/dev/drbd0::/opt/EMC::ext3 – mount /dev/drbd0 on /opt/EMC as an ext3 filesystem
10.5.140.222 – the IP address for our solution (see the beginning of the post)
httpd – the service we’re going to watch over and take care of, in this case httpd (which wasn’t really what I was configuring, but it’s the easiest to show as an example)
Don’t forget this file has to be the same on BOTH MACHINES.

Step 6.
Make sure heartbeat and the service(s) you’re watching DO NOT start at boot, otherwise things get really ugly if when you screw up:
chkconfig heartbeat off
chkconfig httpd off
/etc/init.d/httpd stop
(on both machines)

Step 7. (The cross your fingers step)
Alright, it’s finally time to test your failover configuration. First, we need to start heartbeat on the primary machine:
lava2042# /etc/init.d/heartbeat start
Then, start it on the secondary machine
lava2138# /etc/init.d/heartbeat start

You should now be able to ping the cluster IP (lava2222 or 10.5.140.222). You can also check that the /dev/drbd0 filesystem is mounted on the primary node using df. Check the /var/log/messages file on either machine for debugging information.

The moment of truth
Go to your primary node and yank the power cable out of the back. Head back to your machine and carefully watch the /var/log/messages file on the secondary node. You should see information about the link being down, the drbd having trouble accessing the filesystem, then heartbeat should kick in and start taking over, mounting the filesystem and finally starting your httpd service. Congratulations, you have now successfully failed over.

If you have an error, check the error messages and see if you can figure out what to do, if you need any help leave a comment or email me and I’ll try and help. Hopefully this helps somebody as this took me quite a while to figure out, having never worked with either piece of software.

Additional links:
Information mostly pulled from:
http://linux-ha.org/GettingStarted
http://www.linux-ha.org/DRBD/GettingStarted
http://www.linux-ha.org/DRBD/HowTo

P.S. Ralf Ramge emailed me an updated version of his bash zfs backup script. I am still working on getting it put together to post. Thanks for the email Ralf

I had expected to hear a pretty good discussion around the “linuxification” of Solaris and how Ian Murdock plans to approach it, turns out about halfway through I was a little disappointed by the zealotry of some of the audience members. To *me* at least, it seems like they were arguing trivial points that led to the discussion going way off track. About 2/3 of the way through I turned if off so I could concentrate of a perl script I was writing (see below :P). Here’s what my opinion is about the subject:

• Who cares if you call the Linux userland “Linux” instead of “GNU”?? Most managers and people engaged in casual conversation reference the entire userland as Linux anyway, it makes it easier to talk about. Yes, everyone that is involved in OSS knows that Linux is just the kernel, but that seems like a pretty trivial point to make when you’re not even discussing that in the first place.
•  Solaris needs a better userland. This, I agree with, I used to hate Solaris because I didn’t know how to do things with it, I think Ian makes a good point in that in college, the majority of students that ran an “alternative” operating system were running Linux, they knew it, they loved it, they wanted to use it when they got out of college (at least, I did). I certainly wish I had been experimenting with Solaris in college (I think I only did once). Now that I’ve been administering Solaris for the last year, it is by far my favorite administration platform, it might not be great for everything, but I certainly love it for my sysadmin work. Now if only the rest of the world would come to see the way I feel…
• I commented about GNU having a better userland on a post on OSnews.com some time ago and someone alerted me to the fact that Solaris utilities have a better POSIX standardization than GNU utilities. After doing some poking around I definitely agree with that, I mean, in Linux, do you use -option? –option -option=? Is the manpage helpful ? (Hint: no). What I really miss are the features of the GNU tools, windowing in grep, -iname option for find. Things like that.
• I read an article a couple days ago about how Solaris has a more powerful administration interface, however, Linux has an easier administration interface. I would say that’s about true. When it comes down to it, a lot of people are going to choose what they think will the best and easiest to administer. More education is needed. That and Linux is beating Solaris in online documentation by about 1000 webpages for every 1. Finding what I need for Solaris has always been a more extensive challenge to my GoogleFu than with Linux.
• Almost every person that commented in the forum with Ian reminded me of that annoying guy from CS classes in college who thought he knew everything and was very elitist. Ugh, I just want to hit someone.

There you go, personal opinions that have almost no logical reason other than personal preference, way to go internet.

Ugh, re-reading this it is clear I am not an english major. Sorry for the disjointedness.

# Generated by iptables-save v1.2.11 on Thu May 17 14:52:04 2007
*filter
:INPUT DROP [13164:946396]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 128.222.228.235 -p tcp -j ACCEPT
-A INPUT -s 128.222.228.235 -p udp -j ACCEPT
-A INPUT -s 128.222.228.236 -p tcp -j ACCEPT
-A INPUT -s 128.222.228.236 -p udp -j ACCEPT
-A INPUT -s 128.222.12.10 -p tcp -j ACCEPT
-A INPUT -s 128.222.12.10 -p udp -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -j ACCEPT
-A OUTPUT -p udp -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
COMMIT
# Completed on Thu May 17 14:52:04 2007

(128.222.228.235/236 and 128.221.12.10 are our DNS servers, I also accept pings too because I’m nice like that and people around here tend to freak out if they can’t ping their machine. I also let anything out, easy to comment out to deny outbound traffic.)