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

[OCLUG-Tech] iSCSI target daemons

Hello,

One current project I'm working on is an install of Linux iSCSI with a single target test volume on a CentOS 5 machine. One approach we've been using is to install iscsi-initiator-utils vs. open-iscsi. Any thoughts/experience using either daemon as a target? Since iscsid initially has shown some port binding/connection difficulties, I will have to resolve that first or simply stick with tgtd/tgtadm(8) [http://linux.die.net/man/8/tgtadm].

The initiator is using open-iscsi.  Apparently according to:
http://groups.google.com/group/open-iscsi/browse_thread/thread/ 7aac95e730767e53/94093b77ad7680d3#94093b77ad7680d3 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.

One thing to note is the iscsid requires SELinux rules to be enabled. I am not 100% certain if the below rules are preventing the daemon from connecting to it's listener socket, or if I've perhaps done something wrong in the config files. I've already done a:

# setsebool -P iscsid_disable_trans=1
yet connect() call fails to the tcp socket/listener.

# sesearch -a|grep iscsi |grep tcp
allow iscsid_t @ttr0100 : node { tcp_recv tcp_send udp_recv udp_send };
   allow iscsid_t @ttr0113 : tcp_socket { recv_msg send_msg };
   allow iscsid_t http_port_t : tcp_socket name_connect ;
   allow iscsid_t iscsi_port_t : tcp_socket name_connect ;
allow iscsid_t @ttr0749 : netif { tcp_recv tcp_send udp_recv udp_send }; allow iscsid_t iscsid_t : tcp_socket { ioctl read write create getattr setattr append bind connect listen accept getopt setopt shutdown }; allow iscsid_t dns_port_t : tcp_socket { recv_msg send_msg name_connect };
   allow ftpd_t iscsi_port_t : tcp_socket name_bind ;

Either way it shouldn't matter once it's up and running, unless there are stark operational or performance differences between the two implementations.


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