cyborgworkshop.org

The iproute2 tools are default installed on most major linux distributions now, but few people know how to use them. Once you are familiar with them though, you will lament having to use ifconfig and route. Here is a quick chart on iproute2 replacement commands.

I don’t usually write about specific products, but I have to drop a line about this new Atom 330 based board that I picked up from newegg. First off, it’s a dual core Atom CPU (with HT) that clocks in at 1.6ghz in 8 watts. Two SATA 2 ports and a single IDE attach the storage, 1 PCI slot, 1 DDR2 DIMM slot, onboard RTL gigabit LAN and Intel analog video with s-video out. Pretty much a 3 generation old PC. But here is the kicker, this little board runs EVERYTHING! Right now, I’m triple booting OSX (Kalyway with 0 tweaks, it just works) Mint Linux XFCE and VMWare ESXi (!). The ESXi did require me to smack in an intel based NIC, but the ICH7 chipset allows you to use the onboard sata storage as VMFS. The only real drag about this board is that it tops out at 2 gig of RAM, otherwise I would be ordering these things in bulk!

By default, when you enable iscsi sharing within zfs, the share is created and bound to all available ethernet interfaces. This isn’t necessarily a bad thing, but if for some reason you can reach your iscsi share via two paths, you run the chance of sending iscsi traffic over a non optimized path and really messing with your performance. Fortunately, a way exists to bind iscsi to specific interfaces using interface groups.

First, we need to create the interface group. This is assuming that the IP 192.168.1.1 is the IP address that is assigned to the interface (or in the case of bound channels, multiple interfaces) that you want a specific share to use.

iscsitadm create tpgt
iscsitadm modify tpgt -i 192.168.1.1 1

A quick

iscsitadm list tpgt -v 1

Will let you know if this worked.

Now that your interface group is created, all you have to do is bind it to a specific share.

iscsitadm modify target -p 1 zpool/iscsiTarget

Done! This leaves open some interesting opportunities for using the same iscsi SAN to service connections on different networks in a relatively secure manner. Have fun!

If you have netcat and dd installed, you have a wicked fast way to clone a harddrive over the network.  You’ll need netcat and dd installed on both machines.   On the target machine (the machine you want to push the drive image to) run

nc -l -p 1337 | dd of=/dev/sda

and on the host machine (the machine you want to clone)

dd if=/dev/sda | nc 192.168.1.1 1337

This assumes that your IP is 192.168.1.1, so adjust accordingly.

How many of you saw this one coming? In my haste, I accidentally did a zpool destroy -r on the wrong pool this morning and offlined my SAN. Not good. I walked around the entire rest of the day bumming over all of the stuff I’d lost since my last backup to tape because now all of my snapshots were gone. I spent my lunch hour browsing some docs over on sun admin and came across what ended up being my salvation. How to undestroy a destroyed pool. To save you the time, you need to know two commands

zpool import -D

That will show you what pools you have that are still around, but have been deleted.

zpool import -Df tank

That command does the leg work and brings the good old tank pool back online. Hopefully you didn’t lose any drives during this process, but in theory you should be able to recover a degraded pool. Best bet though, don’t try to clean up the SAN at 5:30am before you go to work.