HOWTO: the definitive guide to Debian Etch open-iscsi (step-by-step)
Posted by Vide on September 15, 2008
Ok, maybe this is a little bit arrogant title :) but since I’ve experienced more than a problem/issue when installing iSCSI initiator support in Debian 4.0 Etch, I think that this howto could help people setting up their first open-iscsi in Etch (in which open-iscsi is UTTERLY broken, let me say it loud).
First of all, install open-iscsi
aptitude install open-iscsi
and remove the broken init scripts (they are going to give you lots of headaches when rebooting, if you don’t do this.)
update-rc.d -f open-iscsi remove
create a couple of symlinks to fix paths needed to automatically detect targets on reboot, and thus creating the sdX devices
ln -s /etc/{iscsid.conf,initiatorname.iscsi} /etc/iscsi/
edit /etc/iscsi/iscsid.conf and make sure that
node.startup = automatic
Restart open-iscsi
/etc/init.d/open-iscsi restart
Now, let’s discover the iSCSI targets connected to the net:
iscsiadm -m discovery -t sendtargets -p $SAN_IP_ADDRESS
Restart open-iscsi again, now you should see sdX appear in dmesg!
/etc/init.d/open-iscsi restart
You can now partition and format the new disk(s) just as they were phisically attached disks… but beware, it’s not over yet, you’ll have to keep in mind and tweak a couple of things.
First, when you add the disk entry in your /etc/fstab, remember to use the -_netdev option, so for example:
/dev/sdb1 /mnt/logs ext3 defaults,auto,_netdev 0 0
This will make scripts like /etc/init.d/umountnfs.sh aware that they are remote network resources and… do nothing different because as I said Debian Etch is bugged as hell when dealing with iSCSI. :(
The default behaviour is, in fact, to kill the iscsid process and bring down the network interfaces before umounting the iSCSI disk, with effects ranging from kernel panics to “normal” lock-ups when rebooting the machine.
So, edit /etc/network/interfaces with your favourite editor and put something like this in the network interface you’re using to connect to the iSCSI SAN:
post-up echo "Waiting for network to come up before starting iSCSI..." && sleep 5
post-up /etc/init.d/open-iscsi start
pre-down umount -a -O _netdev
pre-down /etc/init.d/open-iscsi stop
moreover, edit /etc/default/rcS and put
ASYNCMOUNTNFS=no
to disable async mounting which in theory works better but in practice doesn’t work very well in Debian Etch when dealing with iSCSI.
The sleep is to assure that the interface is really up&running before trying to start open-iscsi, otherwise automounting on boot won’t work. I know, it looks like an hack and indeed it’s an ugly, awful hack, but it works, at least in my environment :)
The other thing we have to tweak is the /etc/init.d/sendsigs script, which is used to kill all the running processes when rebooting/shutting down the server. This script is going to kill the iscsid daemon before umounting can happen, so making impossible to reboot your machine without physical access (and we all leave our machines in datacenters, don’t we?). So, here it is another simple hack to work around the problem:
mv /etc/rc6.d/S20sendsigs /etc/rc6.d/S39sendsigs
mv /etc/rc0.d/S20sendsigs /etc/rc0.d/S39sendsigs
(runlevel 0 is halt, runlevel 6 is reboot)
this way we tell init to execute sendsigs after umountnfs.sh, networking, ifupdown, thus solving our problem. :)
And that’s all now, you should be able to reboot your machine and have it to boot again, mounting your iSCSI volumes automatically.
Keep in mind that this howto is thought for servers in front of the SAN, so I’m supposing you’re not going to mount/umount things all the time, or bring up and down interfaces all the time. So for example do not complain if with a ifdown $IFACE you are bringing all the iSCSI infrastructure down.
One last note: I’ve been inspired by these post I found on the Internet, but they are not completly working with Debian bugs or they do things in a more complicated way (at least for me). Anyway thanks to their authors, they were really useful posts:
HOWTO: the definitive guide to Debian Etch open-iscsi (take 2) « The eternal fight between admins and computers said
[...] the fact I’m here writing again on this topic goes for that definitive I put in the title the first time :) So obviously it was not so definitive, and here we are again with a, I hope, better and improved [...]
David said
Excellent little guide. The hint to use open-iscsi from backports would have saved me quite some time getting the package from etch to work properly. Many many thanks!