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 ] |