home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] iSCSI target daemons

Hello,  (-vv skip if you got all this already...)

tgtd included in CentOS 5 base (scsi-target- utils-0.0-0.20070620snap.el5) doesn't seem to access ietd.conf or any config file for that matter, while newer ietd does. I checked with strace and manpages. I am assuming that this was only added to later ietd release and verified the path in the source.
	plain.c:26:#define CONFIG_FILE  "/etc/ietd.conf"

	[centos ~]# tgtd --version
	(complain)

	[gentoo ~]# ietd --version
	iscsid version 0.4.15

The question is whether this justifies grabbing a newer rpm or compiling update tarball, because there is a quick way of working around the config file anyway which some might prefer. Here is a small patch I wrote:

--- /etc/init.d/tgtd    2008-02-04 11:46:29.000000000 -0500
+++ /etc/init.d/tgtd.orig       2008-02-04 08:44:34.000000000 -0500
@@ -10,9 +10,6 @@
#              machine daemon.
### END INIT INFO
#
-# !! NOTE: site specific deltas added - afields - 2008-02       !!
-# !!       SEE BELOW: target_{start,stop}                      !!
-#
#
# pidfile: /var/run/tgtd.pid
#
@@ -23,26 +20,6 @@

RETVAL=0

-## BEGIN: site specific { ##
-#  routines to easily add/remove iscsi targets to IET
-# target_start(): Execute rc files in format S<tid><targetname> to add target/bindings -# target_stop(): Execute rc files in format K<tid><targetname> to remove target
-#
-TARG=/etc/iscsi/tgtd.d
-target_start()
-{
-       echo -n $"Adding iscsi targets: "
- find ${TARG} -name "S[0-9]*" -type f -perm /u+x -exec $ {SHELL} {} \;
-       echo
-}
-target_stop()
-{
-       echo -n $"Removing iscsi targets: "
- find ${TARG} -name "K[0-9]*" -type f -perm /u+x -exec $ {SHELL} {} \;
-       echo
-}
-## } END ##
-
start()
{
        echo -n $"Starting SCSI target daemon: "
@@ -58,14 +35,10 @@
        if [ $RETVAL -eq "0" ]; then
                touch /var/lock/subsys/tgtd
        fi
-
-       target_start
}

stop()
{
-       target_stop
-
        echo -n $"Stopping SCSI target daemon: "

        if [ ! -f /var/lock/subsys/tgtd ]; then
_EOF_


Deltas to /etc/init.d/tgtd which now call /etc/iscsi/tgtd.d/ S<tid><target>,K<id><target>

# ls -al /etc/iscsi/tgtd.d
total 48
drwxr-xr-x 2 root root 4096 Feb  4 11:44 .
drwxr-xr-x 5 root root 4096 Feb  4 11:44 ..
-rwxr-xr-x 1 root root  283 Feb  4 10:43 K2iscsi-test
-rw-r--r-- 1 root root  284 Feb  4 10:41 .KnTemplate
-rwxr-xr-x 1 root root  509 Feb  4 10:45 S2iscsi-test
-rw-r--r-- 1 root root  492 Feb  4 10:41 .SnTemplate

--- /etc/iscsi/tgtd.d/.KnTemplate:
#
# IET target setup script: target_remove
#
TGTADM="tgtadm --lld iscsi"
DATE="2008-02"
DOMAIN="ca.example.host"
DEV="lvm"
TID=<n>
TGTNAME="<template>"
IQN="iqn.${DATE}.${DOMAIN}:${DEV}.${TGTNAME}"

echo -n "$TGTNAME "
${TGTADM} --op delete --mode target --tid=${TID} --targetname=${IQN}
_EOF_

--- /etc/iscsi/tgtd.d/.SnTemplate:
#
# IET target setup script: target_add
#
TGTADM="tgtadm --lld iscsi"
DATE="2008-02"
DOMAIN="ca.example.host"
DEV="lvm"
STORAGE="/<path>/<dev>"
NETWORK="ALL" # Change to your local subnet/host
TID=<n>
TGTNAME="<template>"
IQN="iqn.${DATE}.${DOMAIN}:${DEV}.${TGTNAME}"

echo -n "$TGTNAME "
${TGTADM} --op new  --mode target      --tid=${TID} --targetname=${IQN}
${TGTADM} --op new --mode logicalunit --tid=${TID} --lun=1 --backing- store=${STORAGE} ${TGTADM} --op bind --mode target --tid=${TID} --initiator- address=${NETWORK}
_EOF_

Also note here is an UPDATE notice regarding the iSCSI initiator changes which I touched upon.
	* http://fedoranews.org/cms/node/2110

On the latest XE4 [XenServer release 4.0.1-4249p (xenenterprise)] it is not possible to use iscsiadm --mode iface but it does persist database entries using plaintext in /etc/iscsi/ {ifaces,nodes,send_targets}.

- afields


On 6-Feb-08, at 7:53 PM, Allan Fields wrote:

On the issue of documentation, simple answer..

No need to write an updated HowTo, because it already exists:
	* http://www.howtoforge.com/iscsi_on_linux
This one is good in that it is concise, describes the terminology and provides excellent illustrations. (Though it wasn't among first few search results in my initial search:) It did appear in: * http://www.google.com/search?client=safari&rls=en&q=linux+iscsi +howto&ie=UTF-8&oe=UTF-8


Since this was my first deployment of Linux open-iscsi, I thought I'd clarify my original statement:

the I_T nexus can be established with-out difficulty between two different iSCSI implementations on Linux. Given that iSCSI is a standard (RFC3721), that is the expect behavior or the implementation is broken.

target-utils (IET) and open-iscsi are complimentary, which might not be clear from the outset, leading to confusion (open-iscsi is an initiator implementation only, despite having a daemon.) When open-iscsi docs refer to persistent targets, these are I_T nexus ''nodes'' mappings from initiator to target, not targets which can be mapped by another open-iscsi initiator.

Please verify (iSCSI experts) -

My initial preparation time was effected due to circumstances out of my control, but now I have a better working knowledge of Linux iSCSI deployment. What is not yet solved is why /etc/ietd.conf doesn't successfully generate targets on startup, leading to my working around that config file entirely. They didn't move the config file around on us did they? I tried: /etc/ietd.conf /etc/ iscsi/ietd.conf and /etc/iscsi/iscsid.conf with the following Target definition example:

	Target iqn.2008-02.ca.tld.xyz:lvm.LocalicalVolume:test.iscsi
        	User
        	Lun 0 /dev/LogicalVolume/test
        	Alias test

The database appears to be a text string based 'dbm' file format (such as in PHP4) vs binary NDBM. The source shows how the nodes are populated with a default parameter set and persisted to a config file. * http://git.kernel.org/?p=linux/kernel/git/mnc/open- iscsi.git;a=blob_plain;f=usr/idbm.c;hb=master

Persistent vs. Active representation: You may use iscsiadm to administer these targets including removal in the case when a stale target is present. I found that I had one stale target, due to a changed iqn during testing. These do not seem to clear on their own when the nexus is broken or across iscsid restarts, which is probably a feature to avoid a temporarily down target from being purged from the database entirely.


Thanks,
	Allan Fields <afields [ at ] ncf [ dot ] ca>