Showing posts with label centos. Show all posts
Showing posts with label centos. Show all posts

Wednesday, October 24, 2012

Customizing grub2 boot options in Fedora 18

In days of old, with RedHat Linux, and Fedora and Centos, on servers I used to disable the default behaviour of console display blanking screen-saver by putting the 'setterm -blank 0' command into file '/etc/rc.local'. On recent versions of Fedora, you do not get a '/etc/rc.local' file, however you can create one like this:
# vi /etc/rc.d/rc.local
# chmod a+x /etc/rc.d/rc.local
# ln -s /etc/rc.d/rc.local /etc
# ll /etc/rc.local
lrwxrwxrwx. 1 root root 18 Sep 24 15:44 /etc/rc.local -> /etc/rc.d/rc.local
#

But this no longer seem to be an appropriate way to run  'setterm -blank 0', as the command just seems to be ignored. I tried setting my '/etc/rc.local' file to this:
# cat /etc/rc.local
#!/bin/sh
/bin/date > /root/rc.local.start
/bin/sleep 5
/bin/setterm -blank 0
/bin/date > /root/rc.local.done

..just to prove the command was executing, and it was, but still the screen blanked after the timeout.

After much Googling, I found the answer was to use a kernel command line option of 'consoleblank=0'.

Now again in days of old, I would just edit '/etc/grub.conf' to set these kernel parameters, But now recent versions of Fedora are using Grub2, things have changed. I found that you can specify the kernel parameters, in file '/etc/default/grub', using the 'GRUB_CMDLINE_LINUX_DEFAULT' option.

And while I was editing the grub file, I decided to change some other settings. I wanted to disable the graphical boot splash screen, and just have a basic 'text' screen to select which kernel to boot, so I added 'GRUB_TERMINAL=console'. I also removed the 'rhgb quiet' options, as I like to see all those boot messages scrolling up the screen.

# cd /etc/default/
# cp grub grub.orig
# vi grub
# diff -u grub.orig grub
--- grub.orig   2012-10-24 10:28:28.120869824 +0100
+++ grub        2012-10-24 10:52:40.940184853 +0100
@@ -1,6 +1,8 @@
-GRUB_TIMEOUT=5
+GRUB_TIMEOUT=10
 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
 GRUB_DEFAULT=saved
-GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet"
+GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :)"
+GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"
 GRUB_DISABLE_RECOVERY="true"
 GRUB_THEME="/boot/grub2/themes/system/theme.txt"
+GRUB_TERMINAL=console
#
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.6.2-2.fc18.x86_64
Found initrd image: /boot/initramfs-3.6.2-2.fc18.x86_64.img
Found linux image: /boot/vmlinuz-3.6.0-1.fc18.x86_64
Found initrd image: /boot/initramfs-3.6.0-1.fc18.x86_64.img
#

Ok, so lets check that worked....
# grep $'\tlinux' /boot/grub2/grub.cfg
linux   /vmlinuz-3.6.2-2.fc18.x86_64 root=UUID=9d81334c-ed70-4cc8-9279-e82eb8cdef1e ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0  consoleblank=0
linux   /vmlinuz-3.6.0-1.fc18.x86_64 root=UUID=9d81334c-ed70-4cc8-9279-e82eb8cdef1e ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0  consoleblank=0

In the above, note how I get grep to match for the tab character.

References:
http://lists.fedoraproject.org/pipermail/users/2012-March/415317.html
http://superuser.com/questions/152347/change-linux-console-screen-blanking-behavior
http://thangnguyennang.wordpress.com/2012/06/17/change-the-grub-menu-timeout-on-fedora-17-20-2/
http://ubuntuforums.org/showthread.php?t=1456104
http://www.dedoimedo.com/computers/grub-2.htm
http://fedoraproject.org/wiki/GRUB_2
http://www.redhat.com/archives/rhl-list/2004-May/msg07775.html
http://savannah.gnu.org/bugs/?23535
http://www.howtoarena.com/how-to-disable-linux-console-screen-blank-out-feature/

Thursday, July 12, 2012

Centos vlan configuration

On our Centos boxes, we start with a minimal installation, and then add additional rpm packages as required. Today, we wanted to add a vlan trunk interface on an existing box. We created the config file as follows:
# cat /etc/sysconfig/network-scripts/ifcfg-eth5.800
# Intel Corporation 82546GB Gigabit Ethernet Controller (Copper)
DEVICE=eth5.800
BOOTPROTO=static
HWADDR=00:1B:21:52:09:0F
ONBOOT=yes
IPADDR=192.168.51.193
NETMASK=255.255.255.192
VLAN=yes
#

But when we tried to bring up the vlan interface, we got this error:
# ifup eth5.800
Device eth5.800 does not seem to be present, delaying initialization.
#

This was caused because the 'vconfig' program was missing, and so we had to install that package:
# which vconfig
/usr/bin/which: no vconfig in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)
# yum install vconfig
# which vconfig
/sbin/vconfig
#

Then everything worked as expected:
# ifup eth5.800
Added VLAN with VID == 800 to IF -:eth5:-
# ls -l /proc/net/vlan
-rw------- 1 root root 0 Jul 12 10:35 config
-rw------- 1 root root 0 Jul 12 10:35 eth5.800
# lsmod | grep 8021q
8021q 57425 0
#

BTW, the above commands were run on the following version of Centos:
# cat /etc/redhat-release
CentOS release 5.8 (Final)
#

Friday, August 05, 2011

bash initialisation files

I've been installing Centos 5 into VirtualBox this evening. Due to some mistyping, I ended up in the situation where I needed to manually create the 'home' directory for the user 'nwsmith'. Ok, thats simple, just remember to set the correct user and group, and the correct permissions:

# mkdir /home/nwsmith
# chown nwsmith.nwsmith /home/nwsmith
# chmod 700 /home/nwsmith

But when I logged in as user 'nwsmith' I was not getting the correct bash prompt. It looked like PS1 was not being set correctly. I quickly realised that I was missing the '.bashrc' file from my home directory, so I copied that across from '/etc/skel/.bashrc'.

But still I was not getting the correct prompt. But I found that if I ran the command 'source ./.bashrc' then I did get the correct prompt. Finally the penny dropped, when I googled up this link Initialisation files and configuration from the University of Cambridge Computer Laboratory. I'm just going to quote the paragraph I found really useful:

When bash is invoked as a login shell it first reads and executes commands from the file /etc/profile, if that file exists. This initialises a few environment variables, and calls a set of small initialisation scripts from the directory /etc/profile.d, which will vary depending on the software loaded on the machine (for example, if KDE is loaded there will be one called kde.sh).

After reading that file, it looks for ~/.bash_profile or ~/.bash_login or ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. (The --noprofile option could be used when the shell is started to inhibit this behaviour.)

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. (This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc).

Thus, by default, the file ~/.bashrc is not read automatically when a login shell is started. For this reason it is usual behaviour to add a section to ~/.profile (or ~/.bash_profile or ~/.bash_login) to read and execute it, so that you get uniform behaviour on both login shells and normal interactive shells.

After reading that I realised that I also need a '.bash_profile' file in my home directory, so I copied one across from '/etc/skel/.bash_profile'. And then when I logged in as user 'nwsmith' I got the prompt I was expecting.

By the way, '.bash_profile' and '.bashrc' do NOT need to have 'x' executable permission.

Monday, July 19, 2010

Patching vmxnet to disable LRO

We've been playing with two Centos 5.5 virtual machines connected over a virtual switch on VMware ESX 4.0 update 2. Unfortunately we experienced very poor TCP performance. I think the same issue affects ESX 4.1 as we found this reference in the release notes:
Poor TCP performance can occur in traffic-forwarding virtual machines with LRO enabled
Some Linux modules cannot handle LRO-generated packets.
As a result, having LRO enabled on a VMXNET 2 or VMXNET 3 device in a traffic
forwarding virtual machine running a Linux guest operating system can cause
poor TCP performance. LRO is enabled by default on these devices.

Workaround: In traffic-forwarding virtual machines running Linux guests,
set the module load time parameter for the VMXNET 2 or VMXNET 3 Linux driver
to include disable_lro=1.

We found that this works:
# rmmod vmxnet
# modprobe vmxnet disable_lro=1

BUT the problem is how to make vmxnet default to disabling LRO when the VM is first booted.

We tried editing '/etc/modprobe.conf' and adding 'options vmxnet disable_lro=1' but this was not sufficent. It seems that the vmxnet module is first loaded during bootup from the initrd.

Our conclusion was that patching the source code of vmxnet was the best way. So here is what we did:
# cd /usr/lib/vmware-tools/modules/source/
# tar xvf vmxnet.tar
# cd vmxnet-only
# grep -n disable_lro *
vmxnet.c:155:static int disable_lro = 0;
vmxnet.c:157: module_param(disable_lro, int, 0);
vmxnet.c:159: MODULE_PARM(disable_lro, "i");
vmxnet.c:931: !disable_lro) {
# cp vmxnet.c vmxnet.c.orig
# chmod +w vmxnet.c
# vi vmxnet.c
# diff -u vmxnet.c.orig vmxnet.c
--- vmxnet.c.orig 2010-07-19 13:20:44.000000000 +0100
+++ vmxnet.c 2010-07-19 13:57:43.000000000 +0100
@@ -152,7 +152,7 @@
#endif // VMXNET_DO_ZERO_COPY

#ifdef VMXNET_DO_TSO
-static int disable_lro = 0;
+static int disable_lro = 1;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 9)
module_param(disable_lro, int, 0);
#else
@@ -932,6 +932,14 @@
lp->lpd = TRUE;
printk(" lpd");
}
+
+ if (disable_lro) {
+ printk(" disable_lro:1");
+ }
+ else {
+ printk(" disable_lro:0");
+ }
+
#endif
#endif

# cd ..
# mv vmxnet.tar vmxnet.tar.orig
# tar cvf vmxnet.tar vmxnet-only/
# vmware-config-tools.pl -c

The change to the source code was just to change the value of the disable_lro variable from zero to one. And we also added some code to report the value of the variable when the module loads.

To recompile the modules, you will need these rpm packages installed:
gcc, binutils, kernel-devel, kernel-headers

For reference, the version of vmware tools we were using was:
VMwareTools-8195-261974

Of course, if you update vmware-tools, you may need to review this fix, and re-patch the file.

If you are using the vmxnet3 driver, the fix should be similar to the above.

I'd like to thank Michael Melling for helping test the above patch.
Regards
Nigel Smith

Sunday, January 14, 2007

Linux iScsi Target and the Inquiry LUN Response

Ok, last time we completed compiling and installing the Linux iScsi target. Now we need to configure it and start it. All I wanted to do, at this stage, was a simple test. So I just did the minimal amount of configuration. I was going to be running the target on Centos-4, running under VmWare, so it was easy to add a second virtual hard drive to the environment, in this case '/dev/sdb', to export out from the target.
# cat /etc/ietd.conf
#IncomingUser nwsmith secretsecret
Target iqn.2007-01.net.nwsmith:test01
Lun 0 /dev/sdb fileio
Alias iscsitest01

# service iscsi-target start
Starting iSCSI target service: [ OK ]

# netstat -ntlp | grep 3260
tcp 0 0 0.0.0.0:3260 0.0.0.0:* LISTEN 3160/ietd

# tail /var/log/messages
Jan 14 15:59:02 localhost kernel: iSCSI Enterprise Target Software - version 0.4.5
Jan 14 15:59:02 localhost kernel: iotype_init(91) register fileio
Jan 14 15:59:03 localhost kernel: target_param(109) d 1 8192 262144 65536 2 20 8 0
Jan 14 15:59:03 localhost iscsi-target: ietd startup succeeded

The Linux iScsi target seems to work fine with the Microsoft iScsi initiator (v2.03).

Ok, now we have the target running, one of the thing I wanted to look at was how the Linux iScsi target handled the initial login and connection from the Microsoft initiator. I was looking for how it handles the "Inquiry LUN" packet. I used Ethereal to capture and analyse the packets - filter on port 3260.

I had a look at the source code, and found what I was looking for in file "target_disk.c" and in function:
static int build_inquiry_response(struct iscsi_cmnd *cmnd)

By editing the values in this function, you can adjust the following fields in the response packet:

Version, Flags, Vendor Id:, Product Id:, Product Revision Level:

I tried changing some of these fields in the code, recompiling, restarting the target, and then used Ethereal to check that the response (from the target) to the (initiators) 'Inquiry' LUN packet changed as expected. And it did what I expected. (To change the Version returned, edit the line "data[2] = 3;").

The Version field indicates which version of SCSI is supported by the target. You can check which values are valid by reading the specification. The specification is called "SCSI Primary Commands - 3" or SPC-3 and you can download it from www.t10.org.

In the case of the version field, the valid values are shown in table 84:
0x00 - The device does not claim conformance to any standard.
0x02 - Obsolete.
0x03 - The device complies to ANSI INCITS 301-1997 (SPC).
0x04 - The device complies to ANSI INCITS 351-2001 (SPC-2).
0x05 - The device complies to T10/1416-D (SPC-3).

Ok, I think that's enough detail for this post.

Saturday, January 13, 2007

Centos 4 and the Linux iScsi Target

I wanted to do some tests with the Microsoft iScsi initiator and the Linux iScsi target, but first I had to install and configure the target. I had Centos 4.4 (a RHEL4 Linux clone) setup in VmWare, so i thought that using that would be the easy way to do the test.

I had read in PcPro magazine, last year, issue 137 (March 2006) page 197, that the Linux iScsi target would compile & install on Centos-4, but they did not say exactly which version they used.

Ok, so I download the latest version "iscsitarget-0.4.14.tar.gz".

I knew there was a potential problem, as the README file said it needed kernel version of 2.6.14 or newer, and the CONFIG_CRYPTO_CRC32C option had to be enabled. Centos 4.4 uses kernel 2.6.9, but with many additional patches from latter kernels, and the PCpro people said it would be ok.

Ok, so lets try it:

# cat /etc/redhat-release
CentOS release 4.4 (Final)
# uname -a
Linux localhost.localdomain 2.6.9-42.0.3.EL #1 Fri Oct 6 05:59:54 CDT 2006 i686 i686 i386 GNU/Linux
# cat /usr/src/kernels/2.6.9-42.0.3.EL-i686/crypto/Kconfig | grep -A 6 CRC
config CRYPTO_CRC32C
tristate "CRC32c CRC algorithm"
depends on CRYPTO
select LIBCRC32C
help
Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used
by iSCSI for header and data digests and by others.
See Castagnoli93. This implementation uses lib/libcrc32c.
Module will be crc32c.

# cd /home
# tar xfz iscsitarget-0.4.14.tar.gz
# chown -R root:root iscsitarget-0.4.14
# ll
drwxr-xr-x 7 root root 4096 Oct 19 10:48 iscsitarget-0.4.14
-rw-r--r-- 1 root root 92608 Mar 14 2006 iscsitarget-0.4.14.tar.gz
# cd iscsitarget-0.4.14
# export KERNELSRC=/usr/src/kernels/2.6.9-42.0.3.EL-i686/
# make
make -C usr
make[1]: Entering directory `/home/iscsitarget-0.4.14/usr'
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietd.o ietd.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o iscsid.o iscsid.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o conn.o conn.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o session.o session.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o target.o target.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o message.o message.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ctldev.o ctldev.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o log.o log.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o chap.o chap.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o event.o event.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o param.o param.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o plain.o plain.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o isns.o isns.c
cc ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o chap.o event.o param.o plain.o isns.o -o ietd -lcrypto
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietadm.o ietadm.c
cc ietadm.o param.o -o ietadm
make[1]: Leaving directory `/home/iscsitarget-0.4.14/usr'
make -C /lib/modules/2.6.9-42.0.3.EL/build SUBDIRS=/home/iscsitarget-0.4.14/kernel modules
make[1]: Entering directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'
CC [M] /home/iscsitarget-0.4.14/kernel/tio.o
CC [M] /home/iscsitarget-0.4.14/kernel/iscsi.o
CC [M] /home/iscsitarget-0.4.14/kernel/nthread.o
CC [M] /home/iscsitarget-0.4.14/kernel/wthread.o
CC [M] /home/iscsitarget-0.4.14/kernel/config.o
/home/iscsitarget-0.4.14/kernel/config.c:312: error: unknown field `unlocked_ioctl' specified in initializer
/home/iscsitarget-0.4.14/kernel/config.c:312: warning: initialization from incompatible pointer type
/home/iscsitarget-0.4.14/kernel/config.c:313: error: unknown field `compat_ioctl' specified in initializer
/home/iscsitarget-0.4.14/kernel/config.c:313: warning: initialization from incompatible pointer type
make[2]: *** [/home/iscsitarget-0.4.14/kernel/config.o] Error 1
make[1]: *** [_module_/home/iscsitarget-0.4.14/kernel] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'
make: *** [mods] Error 2

# cat /home/iscsitarget-0.4.14/kernel/config.c | grep -n ioctl
219:static long ioctl(struct file *file, unsigned int cmd, unsigned long arg)
312: .unlocked_ioctl = ioctl,
313: .compat_ioctl = ioctl,

Oops! It failed to compile.
Ok, let's google around and see who else has this problem...

It seems other people are getting the same sort of problem with the target versions 4.13 and 4.12 and the older Centos kernel 2.6.9-22.EL

I found this link, where you can download a patch for the target version 0.4.12, which should allow it to compile on kernel 2.6.9, but I did not try it, as it's a "quick hack - Use at your own risk". Maybe someone else can try this patch and give a report.

Ok, so should I dump Centos-4 for now and install Fedora 6, which has an up-to-date kernel. Or should I try and work out which version of the target it was that the Pcpro guy's were using? Ok, I choose the latter.

I went back and downloaded the older versions of the target. And to cut a long story short, I discovered that this version "iscsitarget-0.4.5.tar.gz" will compile on Centos-4. (If you look at the README for that version of the target, it says it is happy with kernel 2.6.10)
Here is the proof that it compiles:

# tar xfz iscsitarget-0.4.5.tar.gz
# chown -R root:root iscsitarget-0.4.5
# cd iscsitarget-0.4.5
# make
make -C usr
make[1]: Entering directory `/home/iscsitarget-0.4.5/usr'
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietd.o ietd.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o iscsid.o iscsid.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o conn.o conn.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o session.o session.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o target.o target.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o message.o message.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ctldev.o ctldev.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o log.o log.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o md5.o md5.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o isns.o isns.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o sha1.o sha1.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o chap.o chap.c
cc ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o md5.o isns.o sha1.o chap.o -o ietd
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietadm.o ietadm.c
cc ietadm.o ctldev.o -o ietadm
make[1]: Leaving directory `/home/iscsitarget-0.4.5/usr'
make -C /usr/src/kernels/2.6.9-42.0.3.EL-i686/ SUBDIRS=/home/iscsitarget-0.4.5/kernel modules
make[1]: Entering directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'
CC [M] /home/iscsitarget-0.4.5/kernel/tio.o
CC [M] /home/iscsitarget-0.4.5/kernel/iscsi.o
CC [M] /home/iscsitarget-0.4.5/kernel/nthread.o
CC [M] /home/iscsitarget-0.4.5/kernel/wthread.o
CC [M] /home/iscsitarget-0.4.5/kernel/config.o
CC [M] /home/iscsitarget-0.4.5/kernel/digest.o
CC [M] /home/iscsitarget-0.4.5/kernel/conn.o
CC [M] /home/iscsitarget-0.4.5/kernel/session.o
CC [M] /home/iscsitarget-0.4.5/kernel/target.o
CC [M] /home/iscsitarget-0.4.5/kernel/volume.o
CC [M] /home/iscsitarget-0.4.5/kernel/iotype.o
CC [M] /home/iscsitarget-0.4.5/kernel/file-io.o
CC [M] /home/iscsitarget-0.4.5/kernel/target_disk.o
LD [M] /home/iscsitarget-0.4.5/kernel/iscsi_trgt.o
Building modules, stage 2.
MODPOST
CC /home/iscsitarget-0.4.5/kernel/iscsi_trgt.mod.o
LD [M] /home/iscsitarget-0.4.5/kernel/iscsi_trgt.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'

# make install
`usr/ietd' -> `/usr/sbin/ietd'
`usr/ietadm' -> `/usr/sbin/ietadm'
if [ -f /etc/debian_version ]; then \
install -v -m 755 etc/initd/initd.debian /etc/init.d/iscsi-target; \
elif [ -f /etc/redhat-release ]; then \
install -v -m 755 etc/initd/initd.redhat /etc/init.d/iscsi-target; \
elif [ -f /etc/slackware-version ]; then \
install -v -m 755 etc/initd/initd /etc/rc.d/iscsi-target; \
else \
install -v -m 755 etc/initd/initd /etc/init.d/iscsi-target; \
fi
`etc/initd/initd.redhat' -> `/etc/init.d/iscsi-target'
install: creating directory `/lib/modules/2.6.9-42.0.3.EL/kernel/iscsi'
`kernel/iscsi_trgt.ko' -> `/lib/modules/2.6.9-42.0.3.EL/kernel/iscsi/iscsi_trgt.ko'
depmod -aq
#

Version 0.4.5 was released on 2005-02-21, so that PcPro article must have been on the editors desk for a year!

Ok, I still need to see if it will work, but that something for another post!