Red Hat Bugzilla – Bug 208864
/var/db/iscsi has moved - /etc/rwtab needs updating
Last modified: 2014-03-16 23:02:50 EDT
See also #208548
What was in /var/db/iscsi is now in /etc/iscsi/send_targets and
/etc/iscsi/nodes. So, /etc/rwtab should contain:
Would it not be more sane, though, for iscsi-initiator-utils itself to install a
file into rwtab.d? That way, if the location changes again, rwtab would be
updated with the package
For reference - here's Mike's reply to the original readonly-root audit:
Bill Nottingham wrote:
> As part of Stateless Linux, we've been examining packages that keep data
> in /var outside of well defined places such as /var/run or /var/lock.
> You're listed as the owner of iscsi-initiator-utils, which places data in:
> What we'd like is a quick description of what this data is, and how
> and when it's written to. For example, does it fit one of the following
> 1) Temporary run-time state (such as lock files)
> 2) Persistent run-time state (such as dhcp server leases)
> 3) Persistent data that doesn't necessarily need modified at runtime
> (such as locate databases)
> 4) Persistent data that *does* need modified at runtime
> 5) Persistent data that would arguably moved elsewhere on a stateless
> implementation (http server content)
Currently it is #4. It The info stored in /var/db/iscsi is the setup
info needed for iscsi connection to a specific target port.
A user typically performs iscsi discovery using the iscsiadm tool
whenever there is new storage in the iscsi network. At that time we
store the discovery info, such as discovery address and discovery type
in /var/db/iscsi DB and we also store the discovery results such as what
targets and their ports were found and other configuration info.
Later, a user or startup script can connect to the a target port found
during discovery by running something like "iscsiadm -record
this-is-the-/var/db/iscsi-record-number -login". At this time the DB
info is read and used to login.
A user may want to remove the connection info from the DB, if the target
port is removed or if there is some other storage reconfiguration event,
and can do this with a iscsiadm remove command. At that time we write to
/var/db/iscsi to remove that target info.
And at any time after discovery has been performed, the user can modify
the configuration info for any target port, and that requries a read and
write to the DB in /var/db/iscsi. They may want to do this to add iSCSI
CHAP info or override the defaults used.
I can change the stock one - that's not an issue. Why did it move to /etc, out
I'm not sure why it moved to /etc - /var still seems to me a sane place to have it
These were the threads on the open-iscsi list about it:
(In reply to comment #2)
> I can change the stock one - that's not an issue. Why did it move to /etc, out
> of curiousity?
To sum up the threads from Mark.
We used to use db4-devel to store iscsi info in a db at /var/db/iscsi. When we
removed db4 usage and went to text files, it was thought that the iscsi target
info is similar to eth0 or scsi3 (NIC or SCSI HBA) config info, so I put it in
/etc/sysconfig. It turned out that people did not like sysconfig and most people
liked /etc/iscsi so I put it there (Some of the other files like lock and pid
got moved by accident due to a bulk cut and replace).
I do not care where it goes. And, I do not know the proper place to put it so I
rely on the pepole one the list to inform me when I mssed up some userspace
thing. So if /var is best we can move it. If it is a Red Hat reason though
please let me know, so I can change it upstream so SUSE and debain can change it
(gentoo agrees it should go in /var/run but only due to read only concerns).
(In reply to comment #2)
> I can change the stock one - that's not an issue.
What I'm saying is that if this was in a rwtab shipped by the iscsi package,
then we wouldn't have upgrade issues (i.e. rwtab out of sync with iscsi) when
changes like this happen
Dunno, I'm just suprised that so far we've gone with everything in the stock one
and no package specific ones
1) it seems more like run-time state, which would be more normally in /var
2) what happens with root-on-iscsi - is it just ignored?
(In reply to comment #6)
> 1) it seems more like run-time state, which would be more normally in /var
> 2) what happens with root-on-iscsi - is it just ignored?
For root-on-iscsi, I think we will want to be able to update the iscsi node info
(text files currently in /etc/iscsi). So all this means it should be in /var
right? Would it be /var/iscsi or /var/db/iscsi?
Per-boot would be /var/run/iscsi, if it's persistent, /var/lib/iscsi? Might need
to re-read what the FHS suggests.
In FHS 2.3, there is this for "/var/lib":
Users must never need to modify files in /var/lib to configure a package's
But the files in /etc/iscsi/nodes and send_targets are config files either our
tools create/modify or the user creates/modifies. Does this mean that it should
not be in /var/lib?
Probably not - is this a config file or run-time state? It seems to be both.
(In reply to comment #10)
> Probably not - is this a config file or run-time state? It seems to be both.
I think both and maybe it depends on how you see the system and tools. I am just
going to stick this in /var/lib then.
yeah that is fine with me.
OK, changed in cvs.
iscsi-initiator-utils changed in iscsi-initiator-utils-18.104.22.1685-0.5. Thanks for
the bug report Mark and thanks for the help Bill.