8 Nov
2022
8 Nov
'22
05:03
Lee Duncan wrote: > On 10/21/22 09:05, Jan Engelhardt wrote: > > On Friday 2022-10-21 16:26, Lee Duncan wrote: > > In the past these files went in /etc/iscsi. I have moved them to /var/lib/iscsi > > in Factory/openSUSE, but I have left them in /etc/iscsi for SUSE. > > Something is going to expect /etc/iscsi (like a config file?), so > > under that consideration, you cannot move it. > > (I was thinking of /etc/my.cnf for example. There is a line > > "datadir=/var/lib/mysql" in that file, which means you could not move > > /var/lib/mysql to anywhere else without breaking the setup.) > > Hi Jan: > Thank you for your reply! > Actually, there are two types of files (in SLE) in /etc/iscsi: > * Database files, and > * Configuration files > I do not plan to (ever?) move the configuration files. These are > initiatorname.iscsi and iscsid.conf. > But the database files really don't belong in /etc, and have already > been moved in other distros, e.g. RedHat. These are: > /etc/iscsi/ > ifaces/ interface DB > ifaces.example > nodes/ discovered Node DB > send_targets/ discovery records DB > lock a lock file > (I would also like to move the lock file, but I see no problem doing that) > So "ifaces", "nodes", and "send_targets" contain history that should not > be lost. > Generally, humans don't edit these files, though they can edit them. > (There are commands to do it, but some just use an editor.) > I understand config files shouldn't move -- that's why we *still* have a > symlink: > > /etc/iscsid.conf --> /etc/iscsi/iscsid.conf > > because we moved this file years ago. > NOTE: I'm mostly interested in this for SLE-15-SP5. It seems like having > the DB files move when upgrading to a new service pack seems reasonable, > if and only if I can somehow copy the old DB files to the new location > when installing my package. Is that possible? > NOTE2: these DB files are already moved in Tumbleweed, and not a single > user filed a bug. Perhaps that just means the package isn't used much in > Tumbleweed? My concern was that if moving those DB folders open-iscsi would recreated them again under /etc, but I see there's an option to change that (dbroot Meson option). I believe you could use a pre scriptlet for this job, something like: > %pre > if [ "$1" -gt 1 ]; then # We only need this scriptlet for upgrades. > DBDIRS='ifaces nodes send_targets' > OLD_DB_ROOTDIR=%{_sysconfdir}/iscsi > NEW_DB_ROOTDIR=%{_sharedstatedir}/iscsi > for dir in $DBDIRS; do > [ -d "$OLD_DB_ROOTDIR/$dir" ] && cp -r "$OLD_DB_ROOTDIR/$dir" "$NEW_DB_ROOTDIR/$dir" > done > fi Now, my new concern is that in the spec file there's only: %dir %{_dbroot} %dir %{_dbroot}/ifaces %{_dbroot}/ifaces/iface.example regarding /(etc|var/lib)/iscsi. So I'm not sure how would RPM react when those folders that that pre scriptlet snippet copyied to /var/lib/iscsi. But you could setup a test with that snippet. In the test you could even create a very simple dummy package meant to only test the concepts here. First create a dummy package with /etc/foo/a/a.example with version, let's say, 1.0 and build it. Then increase the version and implement the pre scriptlet above, but adapted to those dummy dirs/file. Now, install the dummy package version 1.0. Create another directory, let's say, /etc/foo/b with a b.db. Create a /etc/foo/a/a.db dummy file too. And then upgrade the package so you can see how RPM will react to having a directory it's about to install already in place (foo/a, created by the package) that's listed in the spec, and a directory that's not listed in the spec (and foo/b, created by the user). See what happens to a.db too and pay attention if the old location will be empty after upgrading the dummy package.