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

Re: [OCLUG-Tech] iSCSI target daemons

SELinux is actually a good topic to investigate in some depth and any excuse to keep people on that topic or security in general, is a good one. SELinux graphical policy tool described: * http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to- building-a-new-selinux-policy-module/

On 1-Feb-08, at 2:12 PM, Joe Burpee wrote:

On Fri, Feb 01, 2008 at 08:12:38 -0500, Allan Fields wrote:
So far fixing the SELinux rules doesn't seem to do the trick, even though audit2allow returned some rules. As recommended in the manpage you can then compile these rules to a new policy (in the case the existing policy
is not functioning properly).

# cat /var/log/audit/audit.log | grep iscsi |  audit2allow -m local >
local.te
# checkmodule -M -m -o local.mod local.te
# semodule_package -o local.pp -m local.mod
# semodule -i local.pp

netstat -nlt|grep 3260
<< no results >>

I'm not sure this resolves anything (unless you're running in Permissive mode in which case your problem is not selinux). For one thing I often
can't fix selinux issues in one pass like that.  E.g. opening up
permission for a "getattr" may simply lead to failure of a subsequent
"write".

Even with SELinux in Enforcing mode, iscsid now works. It turned out to be an unrelated network issue.

Since documentation has proven inadequate in my deployment for the most recent implementation of both open-iscsi and IET, I'm considering writing some unambiguous directions just as soon as I decipher the config and target specifications (which is still not 100% clear to me even after going through the mass of docs/howto). I did manage to get this setup working well by avoiding certain config issues. With Gigabit LAN, the speeds are well with-in reason/ expectations, though I did no monitoring. (*another project)

Also, simply because there are so many different recommendations online that it's not clear to the un-initialized what the implementors want to do with iSCSI on Linux or which configuration choices to make, the docs need updating. (Unless I just missed the updated version?)

In a number of cases certain options are not available or have changed, so you need to use your clue or guess. This is muchly the case with XenEnterprise as well, but the User Forums help. In another instance there is a suggestion that targets be defined in the config file or persisted in a database. In open-iscsi it appears node definitions and targets are specified in the filesystem hierarchy under: /var/lib/iscsi in textfiles vs. a binary format, despite what the documentation suggests.

I guess the suggestion of reading through mailing lists and support groups/forums still stands, note however that this usually provides mostly case-specific analysis of the implementation and developer notes.

	open-iscsi:
	* /usr/share/doc/iscsi-initiator-utils-6.2.0.865/README
	* http://www.open-iscsi.org/index.html#docs
	* http://www.open-iscsi.org/docs/README
* http://www.cyberciti.biz/tips/rhel-centos-fedora-linux-iscsi- howto.html
	* http://lxer.com/module/newswire/view/94841/index.html
	* Groups open-iscsi: http://groups.google.com/group/open-iscsi/topics

	IET (scsi-target-utils):
	* /usr/share/doc/scsi-target-utils-0.0/README
	* /usr/share/doc/scsi-target-utils-0.0/README.iscsi
	* http://iscsitarget.sourceforge.net/wiki/index.php/HowToInstall
* A Quick Guide to iSCSI on Linux - http://www.cuddletech.com/ articles/iscsi/index.html
	* http://gentoo-wiki.com/HOWTO_iscsi
* http://sourceforge.net/mailarchive/forum.php? forum_name=iscsitarget-devel

// Of importance is to note that tgtd didn't persist targets by default, so what I've done is simply add init script hooks to add/ remove them from /etc/init.d/tgtd using a rc.d startup file format with target specifications and network address bindings.

  Also here are some links to the RFCs:
* RFC3720 (http://www.rfc-archive.org/getrfc.php?rfc=3720 ) covers basic iSCSI protocol, while * RFC3721 (http://www.rfc-archive.org/getrfc.php?rfc=3721 ) covers iSCSI numbering, and * RFC3723 (http://www.rfc-archive.org/getrfc.php?rfc=3723 ) covers iSCSI security issues


Also while your "grep iscsi" probably isolates the iscsid_t domain, IMO it's kind of flying blind. Even for a quick and dirty solution I think it's a good idea to take a look at the rules, including what hasn't been resolved after a first (or second or ...) pass. But I'm not saying you need to wade through the full audit2allow output from audit.log*. E.g. if you have X and the setroubleshoot-* packages installed, you might want
to see what the gui client (sealert -b) says, in real time.  Without X
perhaps sealert -a would be useful.

Yes, I do get some error reports from sealert -a, but they also suggest that the setsebool -P iscsid_disable_trans=1 should do the job for each occurrence. If the policy is broken for iscsid, I could submit a patch using the RedHat Bugzilla as suggested.

On Thu, Jan 31, 2008 at 16:53:14 -0500, Allan Fields wrote:
One thing to note is the iscsid requires SELinux rules to be enabled.

But perhaps running temporarily in Permissive mode (setenforce 0) would
help isolate the problem.

Yes, it appears that this is the case.


Joe

- afields

| Those that must race the Lord or their fellow man in direct competition rather than Enlightenment, are in a race with the Devil and not yet liberated to the greater freedom and refinement of intellect that comes with seeking out the Sun in the common pursuit of liberty and spiritual justice. ... that and blue LEDS are awesome. [ http://en.wikipedia.org/wiki/Light-emitting_diode ] |