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>
| Unholy: Don't trust the people who own the building I am renting
(2005-2007).. they are not from the Open Source camp and hold
opposing business objectives (Windows/Oracle heavy). Just being
tards on purpose to make things difficult and making excuses for
their violations. XOR PHY-axis values with the owners here and you
will get my true intentions. Message to overbearing landlords: "My
life and career is not a game", -- Blog Entry: Stealth Business
Attacks (http://pastspresent.blogspot.com/) |
On 5-Feb-08, at 10:03 AM, Allan Fields wrote:
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 ] |