Latest News

«iSCSI has become the storage connectivity of choice for small business, with applications such as VMware VI3, Exchange, and MS SQL certified on it. It runs on standard Ethernet networks.»

--Green Pages

iSCSI is a network protocol that allows remote disks to appear as local devices to computer. At a very high level, this schema falls under the rubric of Storage Area Network. The difference between iSCSI and NAS protocols that deliver file systems like NFS or Samba, is that that the shared iSCSI resources look like local devices to the system using them. This has some interesting consequences for diskless terminals and the like.

iSCSI is a client-server system. The server presents iSCSI targets (hard drives or files that pretend to be hard drives) clients that can use these resources. The clients are called initiators since they start the protocol. That is, servers with targets do not broadcast their services. iSCSI targets must be discovered by initiators.

When a client finds a desired target, it asks for authorization to use the resource via a login command. If that succeeds, a new SCSI devices appears on the client system that's read for partitioning and provisioning. If the disk as already been initialized, then the resouce can be mounted like any other filesystem.

It turns out, configuring iSCSI on Ubuntu (and other linux distros) is pretty straight-forward. Let's first set up a system that offers iSCSI targets. In this example, the target will be a file rather than a physical device.

Log into your Ubuntu machine. Become root (sudo su -) of you aren't. Create a disk image (dd if=/dev/zero of=/iscsi.disk count=0 obs=1 seek=2G). In this case, a empty 2GB file is created at the root of the filesystem. Install the iscsitarget package (apt-get install iscsitarget). Define the new target in /etc/ietd.conf. Edit the file so that it looks something like:

Target iqn.2010-filer.network.local:iscsi.lun1
   Lun 0 Path=/iscsi.disk,Type=fileio

The name of the target is pretty arbitrary, but you must have a unique naming convention for resources across your network of iSCSI targets. For more on this, see the Wikipedia article cited above. Since this target is the first one list, it gets Lun 0. This is analogous to how the first disk in a SCSI chain is listed by hardware.

Now, we need to twiddle some permissions. By default, iSCSI targets are not published and allow no initiators. To enable targets to be discovered, edit /etc/default/iscsitarget and set the ENABLE flag to "true". Now allow initiators to discover your targets by editing /etc/initiators.allow. Add a the following line to the bottom of the file ALL ALL.

Finally, we're ready to start the target daemon. This is the process that initiators talk to. To start (or restart it), type /etc/init.d/iscsitarget restart.

Now we're ready to configure the initiator. Simple install the following utilities: apt-get install open-iscsi open-iscsi-utils. Now, discover the targets. In this example, assume that the target machine is called filer.network.local.

iscsiadm -m discovery -t sendtargets -p filer.network.local

You should see a list of available targets offered by the filer. Select one (e.g. "iqn.2010-filer.network.local:iscsi.lun1") and get authorized to use it:

iscsiadm -m node -p filer.network.local \
   --targetname "iqn.2010-filer.network.local:iscsi.lun1" --login

Please note that I merely split the line for display purposes. If all has gone well, you should be able to see the new device through fdisk: fdisk -l. You may see a new and empty device called /dev/sdb (if you already have one SCSI disk). This disk is ready for partitioning with fdisk, provisioning with mkfs and mounting on your root filesystem.

When you reboot, your iSCSI disks should be available without using the iscsiadm tool. The daemon processed that do this are controlled by the /etc/init.d/open-iscsi script.

What I presented here is fine for local, trusted networks. There is zero security in this configuration. There are all sorts of authentication schemes for targets and encryption options for the iSCSI traffic. Also, using a fake disk (i.e. a file) as a target will not give you very good performance on the host. I leave all of these enhancements as an exercise for the reader.

UPDATE: Here a link to the Microsoft iSCSI initiator for Windows XP and above.

I tweeted yesterday about my centos 5 linux box losing sound (and frankly X, but that's another story). I tried to use the sound card detector (system-config-soundcard) to find the card again, but it silently failed (typical). The Linux sound howto is over nine years old, so that's pretty useless. What to do?

Well, I turned to my old friends lsmod, dmesg and strace. I could see tha there were kernel sound modules loaded. I could knew that I had configuration that was working. So I issued the following command:

# strace mpg123 /path/to/mp3file

I got quite a bit of output, but the relevant line was this:

open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory)

And sure enough, this is what was in my /dev/snd directory:

[root@durgan snd]# ls
controlC0  
hwC1D2    
pcmC1D0c  
pcmC1D1p  
timer
controlC1  
pcmC0D0c  
pcmC1D0p  
seq

Oh look! There's no pcmC0D0p file. What to do. I could try to create the missing dev file, but I just symlinked the pcmC1D0p to pcmC0D0p.

And yes, this horrible, horrible hack worked like a charm.

What happened to delete this device file? Why couldn't I make the system re-detect and re-initialize the sound system? It's stupid, stupid user issues like this that have plagued linux since 1995 and show no signs of getting better today. This is why you don't see a lot of linux notebooks or games.

xv is an ancient but small X graphic file viewer. If you try to compile the latest source (3.10a) on Centos 5, you'll get the following fatal error message:

In file included from xv.c:11:
xv.h:119 error: conflicting types for 'sys_errlist'

To get a successful compile, simply edit xv.h. Remove all the #defines around 'include <errno.h>' (about 4 or 5 lines). Replace with the single line:

include <errno.h>

Type 'make' again and your compile should succeed.

Note to self: Example interface files for ubuntu/debian systems.

DHCP:

iface eth0 inet dhcp

Static:

iface eth0 inet static 
   address 1.2.3.4
   netmask 255.0.0.0
   gateway 1.0.0.1

Now, don't forget it!

There are two utilities I've found that let Windows users manage files on EXT-2 (and so EXT-3) filesystems.

The first is a filesystem driver that let's you mount EXT-2 drives just like any other VFAT, NTFS drive. Appears to work like a champ.

The other is a less invasive tool that allows you explore EXT-2 filesystems without mounting them.

I have a network filer running linux with RAID-1, which is great. I have a SATA drive in a USB enclosure for backups. Now, I can directly access the backup drive from Windows, should the filer fail.

EXT-2/3 is nice because it handles large files and large capacities. VFAT just can't handle the new drive capacities without magic (even though the linux vfat drive can handle 300GB drives without complaint).

Some good friends of mine stongly urged me to stop watching CNN for a spell. Apparently, I'm becoming hysterical. How they isolated the cause of this hysteria to CNN is beyond my feeble powers to discern. Nevertheless, I going to avoid CNN and the Boston Globe for 5 days or so.

The effect of this isolation is that my journal entries will devolve into increasing esoteric topics. Hence, the following.

In this age of increasing complex X desktop environments, I've taking a courageous step back in time by tweaking my .xinitrc and .twmrc files. That's right, my current window manager of choice is the tab window manager. Take a second to try out these settings. (note: hard coded for 1028x768 screen resolution).

.xinitrc

xsetroot -solid gray85 &
xterm -fg blue -bg white -g 80x25+0+0 &
xterm -fg red -bg white -g 80x25+0-0 &
xterm -fg orange -bg white -g 80x25-0+0 &
xclock -digital -update 5 -bg white -fg gray45 -g -0+420 &
exec twm

.twmrc

ShowIconManager
IconManagerGeometry "191x200-0+468" 2
IconifyByUnmapping
RandomPlacement
NoGrabServer
RestartPreviousState
DecorateTransients
TitleFont "-misc-fixed-medium-r-normal--*-90-*-*-*-*-*-*"
ResizeFont "-misc-fixed-medium-r-normal--*-90-*-*-*-*-*-*"
MenuFont "-misc-fixed-medium-r-normal--*-90-*-*-*-*-*-*"
IconFont "-misc-fixed-medium-r-normal--*-90-*-*-*-*-*-*"
IconManagerFont "-misc-fixed-medium-r-normal--*-90-*-*-*"

Color
{
BorderColor "black"
DefaultBackground "white"
DefaultForeground "gray60"
TitleBackground "white"
TitleForeground "gray60"
MenuBackground "white"
MenuForeground "gray60"
MenuTitleBackground "white"
MenuTitleForeground "gray60"
IconBackground "white"
IconForeground "gray60"
IconBorderColor "black"
IconManagerBackground "white"
IconManagerForeground "gray60"
}

MoveDelta 3
Function "move-or-lower" { f.move f.deltastop f.lower }
Function "move-or-raise" { f.move f.deltastop f.raise }
Function "move-or-iconify" { f.move f.deltastop f.iconify }

Button1 = : root : f.menu "defops"
Button1 = m : window|icon : f.function "move-or-lower"
Button2 = m : window|icon : f.iconify
Button3 = m : window|icon : f.function "move-or-raise"

Button1 = : title : f.function "move-or-raise"
Button2 = : title : f.raiselower

Button1 = : icon : f.function "move-or-iconify"
Button2 = : icon : f.iconify

Button1 = : iconmgr : f.iconify
Button2 = : iconmgr : f.iconify

menu "defops"
{
"Twm" f.title
"Iconify" f.iconify
"Resize" f.resize
"Move" f.move
"" f.nop
"Focus" f.focus
"Unfocus" f.unfocus
"Show Iconmgr" f.showiconmgr
"Hide Iconmgr" f.hideiconmgr
"" f.nop
"CDPlayer" f.exec "exec xplaycd &"
"Gdict" f.exec "exec gdict -a &"
"Netscape" f.exec "exec netscape &"
"Xterm" f.exec "exec xterm &"
"" f.nop
"Kill" f.destroy
"Delete" f.delete
"" f.nop
"Restart" f.restart
"Exit" f.quit
}

IconManagerDontShow
{
"xclock"
}

[Original use.perl.org post and comments.]

[Original use.perl.org post and comments.]

Ian Lance Taylor suggests that perhaps Red Hat ought to buy SCO. Others, including me, have suggested IBM ought to buy SCO. Both of these solutions are designed to shut up the yapping dog that is SCO's claim of IP infringement against Linux. It does suck to reward bad behavior, but I think there is a business case to be made for Red Hat acquiring SCO.

SCO UNIX ™ is used in several niche, but lucrative markets, including accounting applications for construction companies. Red Hat would do well to bolster its holdings with some of these plum accounts. In fact, porting these boring business applications to Linux may produce new customers for these aging applications. I suspect there is a good opportunity to pick low-hanging fruit in there for RedHat.

SCO also claims to have a single-source authentication solution that integrates into MS Active Directory (or what we *nix geeks would call "LDAP"). Linux needs a this kind of management tool, as any SA will testify to. As the number of machines on a network grows, it becomes impossible to manage user accounts for each host. Centralizing this task and making it work in a hetrogenous environment would be a Big Win for Red Hat. While NIS/NIS+ and even primative LDAP authentication support now exists in Linux, it doesn't seem to enough for many admins (no doubt some SA's here will comment on the paucity of delights in using NIS+). SCO's authentication may be part of a comprehensive authentication solution for Linux.

Of course the biggest win for Red Hat is that it gets to own the UNIX name. While that may not have a dollar value, it sure would differentiate the company from other Linux vendors. Recall the boost in credibility that Caldera briefly had when it merged with SCO? Red Hat would certainly handle the UNIX mantle more adroitly and, I suspect, more profitably.

SCO's inflated market value is 150 million inflated dollars, which is at an inflated level of the company's true (less-inflated) worth. I don't know exactly how much SCO would be worth to Red Hat, but even at $75 million, SCO would add some tangible value to the company. Red Hat is reportedly worth about $300 million.

The case for IBM buying SCO is not easy to make. SCO has nothing the IBM needs. It's in no markets big enough for IBM to care about. And, SCO has spit in IBM's eye. So, I think IBM would rather see the executive board of SCO in front of the SEC trying to explain their bad-faith behavior rather than make this whole "Linux License Program" of SCO go away.

SCO has played a very dangerous gambit. As more news surfaces about SCO's erroneous or felonious claims of copyright infringment by Linux, there is a very real possibility that some SCO execs will do jail time. The SEC doesn't take kindly to companies inflating their stock prices with protection rackets built on vapor. Expect SCO to continue its jihad to the bitter end. I assure you, it won't be pretty.

[Original use.perl.org post and comments.]

« "...will discontinue maintenance and errata support for Red Hat Linux 7.1, 7.2, 7.3 and 8.0 as of December 31, 2003," that "Red Hat will discontinue maintenance and errata support for Red Hat Linux 9 as of April 30, 2004," and that "Red Hat does not plan to release another product in the Red Hat Linux line." »

This comes has a shock to me, since I've come to really enjoy using Red Hat. At least I knew how to wrangle it to the ground when it got uppity. Oh well. The King is dead. Long live the King.

[Original use.perl.org post and comments.]

Mary, Joseph and the Spook!

If I never see another goddamn inconsistent filesystem on a linux box, it will be way too soon.

Jeez-suhs...

I've got a Redhat 9.0 box running a software RAID1 array with two 160GB IDE. It works well and I can't complain about the performance. Like the idiot that I am, I failed to set up notification to tell me when a disk in the array fails (UPDATE: use smartd to check the health of hard drives and even mdmonitor to watch for a failed disk in array sets).

This happened recently (within the month), and the array degraded gracefully to using the remaining disk. But I still had to replace the "broken" one (which I don't believe to be broken at all).

To do this, install the new disk as planned. When you boot, you'll be shoved into a root shell.

• fdisk the new disk.
• create a new partition with partition type 0xFD.
• write the new partition table out.
• edit the /etc/raidtab file. Promote the remaining disk to being the first in the array.
• start raid with mdadm: mdadm --assemble --run /dev/md0 /dev/hd
• add the new disk into the existing array: mdadm --add /dev/md0 /dev/hd
• The new disk will sync up to the old. Verify with cat /proc/mdstat. This process took about five hours on my system.
• Reboot your new, happy system.

Just to make this more concrete, my /etc/raidtab looked like this:

raiddev             /dev/md0
raid-level                  1
nr-raid-disks               2
chunk-size                  4
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hdb1
    raid-disk     0
    device          /dev/hdc1
    raid-disk     1

Recently, /dev/hdb1 failed (although it seems ok. fsck revealed no problems, but it was out of sync with /dev/hdc1). I then replaced the drive (Slave HD on the primary IDE channel). I booted the box and changed /etc/raidtools:

raiddev             /dev/md0
raid-level                  1
nr-raid-disks               2
chunk-size                  4
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hdc1
    raid-disk     0
    device          /dev/hdb1
    raid-disk     1

I then started the RAID: mdadm --assemble --run /dev/md0 /dev/hdc1. Then, I added the new disk: mdadm --add /dev/md0 /dev/hdb1.

Hope this limited and cursory treatment of a complex topic helps.

UPDATE: Also see this primer on LVM and RAID tools in modern RedHat. This system was running RedHat 9 and so used the older raidtools stuff. You really only need mdadm, which can create, restore and repair RAID disk sets. Configure /etc/mdadm accordingly.