Jul/090
Riverbed Steelhead: Purdy kernel panic message :)
So I was playing around with a brand new Steelhead web accelerator appliance. Curiosity made me try to virtualize the darn thing and see if I can get it to work with multiple NICS and without the fancy box. Since nothing is impossible and no one was around to stop me, I created an image of the drive and converted it to a VMware Server virtual appliance… it MUST be a *nix flavor, right? No doubt! Who the heck would ever think of Redmond when it comes to creativity?
I was right because the first thing I ran into was a kernel panic. I decided to screenshot and post it for everyone to see… it’s “slightly” different than a normal kernel panic:
There it is. I leave it to you to figure out why I liked it. To the Riverbed guys: nice touch 
P.S. Don’t ask about what happened after I took care of the panicing kernel… hush!
Jul/093
Linux: vsftpd and symbolic links
vsftpd is all about security, and that’s why you cannot access linked directories through vsftpd with any ftp client. My arguement is that if you know how to use symlinks, or are careful enough not to link directories you don’t want to share then who’s vsftpd to butt in and completely disallow you to use such convenient feature of an OS? Reminds me of Windows Server type security… they block IE by default so that you have to either allow every single site, or disable IE ESC altogether.
Here is my convenient workaround: use mount bind!
mount --bind /sourcedirectory /destinationdirectory
You can either use @reboot cron job to have the directories mounted, or mount though fstab by adding the following line:
/directory-you-want-to-mount /destination-directory none bind
Haa… gotcha, but don’t go too fast! This is mount, not ln and will NOT create a mount point in your destination directory. For instance, if you want to mount /home/share to /home/user/share you will need to create /home/user/share first, then mount. Also keep in mind that if you have a copy or rsync job to copy contents of /home/share AND /home/user recursively, you will create two full copies of /home/share directory. One in /home/share and one in /home/user/share. Exclude one of the directories from your cp or rsync job.
Jul/094
Debian: dmesg output contains “Error: Driver ‘pcspkr’ is already registered, aborting…”
Here is what’s transpiring: the boot sequence attempts to load two different drivers for the integrated PC speaker. To solve the problem install alsa-base package:
aptitude install alsa-base
And then execute the following command:
echo blacklist snd-pcsp >> /etc/modprobe.d/alsa-base-blacklist
Jun/093
Debian: open-iscsi, use iSCSI initiator to connect to a SAN
It is actually quite easy as long as your kernel is 2.6.16 or newer. Debian supports fibre channel out of the box, and for iSCSI you only need to install the open-iscsi package (you can easily taylor this to your distro):
aptitude install open-iscsi
Once the package is installed restart the initiator:
/etc/init.d/open-iscsi restart
To find out the indentifier name take a look at initiatorname.iscsi file:
cat /etc/iscsi/initiatorname.iscsi
You can find the initiator identifier towards the bottom of the file… mine is InitiatorName=iqn.1993-08.org.debian:01:61ddbbf82a70. Once you found the name you should be able to discover the target with the following command (my LeftHandNetworks iSCSI SAN IP is 192.168.1.70):
iscsiadm -m discovery -t sendtargets -p 192.168.1.70
Make a note of the record ID (mine is iqn.2003-10.com.lefthandnetworks:sancrp:3139:debian) and connect to it using the following command:
iscsiadm --mode node --targetname iqn.2003-10.com.lefthandnetworks:sancrp:3139:debian --portal 192.168.1.70:3260 --login
Once you initiated the command your iSCSI target will become visible to the OS as an SCSI disk (/dev/sda). You can now partition, format and then mount the LUN just like any other storage device. Add the target to your fstab and it should be auto-mounted everytime your system boots.
nano /etc/fstab
and add:
/dev/sda1 /iscsi ext3 _netdev 0 0
To have the LUN mounted to /iscsi directory. It didn’t work that well in my case… fstab mounts devices early during startup and before iscsi init, and OS couldn’t find the target to mount. I ended up scripting the initiator and mount… created a file “initiscsi” in /etc/init.d directory and added the following lines:
iscsiadm --mode node --targetname iqn.2003-10.com.lefthandnetworks:sancrp:3139:debian --portal 192.168.1.70:3260 --login sleep 5 mount -t ext3 /dev/sda1 /iscsi
I’m sure there is a proper way to have the session initiated before the mount, but I didn’t care enough to figure it out. Init and mount script will do just fine in my case since my LUN is just a storage device.
That sleep command is to make sure the LUN is visible to the OS before it’s mounted. I added the script to my startup sequence after making it executable:
chmod +x initiscsi update-rc.d initiscsi defaults
This is of course for Debian startup.
If you are using CHAP you will need to edit your iscsid.conf file:
nano /etc/iscsi/iscsid.conf
and update it with correct authentication info:
node.startup = automatic node.session.auth.username = username node.session.auth.password = password discovery.sendtargets.auth.username = username discovery.sendtargets.auth.password = password
Save and close the file, then initiate discovery.
Added by Tim Rogers (thanks!):
If you wish to do this properly, you must change the boot order so that the disks are available when the iscsiadm daemon starts. To do this
mv /etc/rcS.d/S25open-iscsi /etc/rcS.d/S88open-iscsi
Check the etc/rcsS.d file first to check when open-iscsi is initiated. May have to change the command to relate to your particular setup. Then there is no need to set up the initiscsi file as described above if this is done.
