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: files /etc/iscsi/nodes files /etc/iscsi/send_targets 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: > /var/db/iscsi > > 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 > classifications: > > 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 of curiousity?
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: http://groups.google.com/group/open-iscsi/browse_thread/thread/3d606dfef4e368de/947c9dde9f36ed88 http://groups.google.com/group/open-iscsi/browse_thread/thread/8e46a9f2e7e58f4e/5df7ea1d389468ea http://groups.google.com/group/open-iscsi/browse_thread/thread/9a578aaadfe4cdc2/b968368f1b4c77e4
(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).
Tangent ... (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
Well... 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) > Well... > > 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 operation. 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.
So, /var/lib/iscsi?
yeah that is fine with me.
OK, changed in cvs.
iscsi-initiator-utils changed in iscsi-initiator-utils-6.2.0.695-0.5. Thanks for the bug report Mark and thanks for the help Bill.