Hi all,
As many of you will have seen there is an ongoing effort to move config files which currently sit in /etc to /usr (where possible). I just wanted to provide a quick overview of the wider changes and how this affects new packages.
DBUS-1 conf files: - Currently in /etc/dbus-1/system.d - Moving to /usr/share/dbus-1/system.d - If this is a change to an existing package, please file a SUSE security bug before sending it to Factory (example: https://bugzilla.suse.com/show_bug.cgi?id=1204055) - If this is a new package, please try to move the file to the /usr location and then you'll have to create a security bug anyway for Factory inclusion.
pam.d files: - Currently in /etc/pam.d - Moving to /usr/lib/pam.d - Please use the %_pam_vendordir macro - These were previously moving to /usr/etc/pam.d (SUSE location) but then upstream created a vendor location so we follow that, files located in /usr/etc will still be read.
XDG autostart files: - Currently in /etc/xdg/autostart - Moving to /usr/etc/xdg/autostart - There previously was an issue where files located in /usr/etc weren't being detected by the systemd generator, this was fixed (ref: https://github.com/openSUSE/aaa_base/pull/118) (bug: https://bugzilla.suse.com/show_bug.cgi?id=1201802)
System user accounts and groups: - Currently created by useradd in %pre - Moving to creation based on /usr/lib/sysusers.d conf file (systemd / sysuser-shadow) - Information on how to create a sysusers.d file can be found at: https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
Notes: - When moving existing packages config files to /usr, you will require a section in the %pre and %posttrans sections to restore the admin's copy of the conf file (ref: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...). Although this doesn't really apply to the dbus-1 changes since admins typically would have no reason to overwrite them. - Don't use %config or %config(noreplace) on the /usr version of the file
More information on other smaller changes and packaging information can be found here: https://en.opensuse.org/openSUSE:Packaging_UsrEtc
P.S. This was a quick general guide, so some information may be slightly wrong.
Am 12. Dezember 2022 17:34:26 MEZ schrieb Callum Farmer gmbr3@opensuse.org:
Hi all,
As many of you will have seen there is an ongoing effort to move config files which currently sit in /etc to /usr (where possible). I just wanted to provide a quick overview of the wider changes and how this affects new packages.
DBUS-1 conf files:
- Currently in /etc/dbus-1/system.d
- Moving to /usr/share/dbus-1/system.d
- If this is a change to an existing package, please file a SUSE
security bug before sending it to Factory (example: https://bugzilla.suse.com/show_bug.cgi?id=1204055)
- If this is a new package, please try to move the file to the
/usr location and then you'll have to create a security bug anyway for Factory inclusion.
pam.d files:
- Currently in /etc/pam.d
- Moving to /usr/lib/pam.d
- Please use the %_pam_vendordir macro
- These were previously moving to /usr/etc/pam.d (SUSE location)
but then upstream created a vendor location so we follow that, files located in /usr/etc will still be read.
XDG autostart files:
- Currently in /etc/xdg/autostart
- Moving to /usr/etc/xdg/autostart
- There previously was an issue where files located in /usr/etc
weren't being detected by the systemd generator, this was fixed (ref: https://github.com/openSUSE/aaa_base/pull/118) (bug: https://bugzilla.suse.com/show_bug.cgi?id=1201802)
System user accounts and groups:
- Currently created by useradd in %pre
- Moving to creation based on /usr/lib/sysusers.d conf file
(systemd / sysuser-shadow)
- Information on how to create a sysusers.d file can be found at:
https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
Notes:
- When moving existing packages config files to /usr, you will
require a section in the %pre and %posttrans sections to restore the admin's copy of the conf file (ref: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...). Although this doesn't really apply to the dbus-1 changes since admins typically would have no reason to overwrite them.
- Don't use %config or %config(noreplace) on the /usr version of the file
More information on other smaller changes and packaging information can be found here: https://en.opensuse.org/openSUSE:Packaging_UsrEtc
P.S. This was a quick general guide, so some information may be slightly wrong.
No one can understand that. Four different destinations. Or even more. For me, there is absolutely no logic behind this. Is this really supposed to be set so well?
Regards Eric
This is not FHS-compliant and should not be implemented.
On Mon, Dec 12, 2022 at 12:14 PM Eric Schirra ecsos@opensuse.org wrote:
Am 12. Dezember 2022 17:34:26 MEZ schrieb Callum Farmer < gmbr3@opensuse.org>:
Hi all,
As many of you will have seen there is an ongoing effort to move config files which currently sit in /etc to /usr (where possible). I just wanted to provide a quick overview of the wider changes and how this affects new packages.
DBUS-1 conf files:
- Currently in /etc/dbus-1/system.d
- Moving to /usr/share/dbus-1/system.d
- If this is a change to an existing package, please file a SUSE
security bug before sending it to Factory (example: https://bugzilla.suse.com/show_bug.cgi?id=1204055)
- If this is a new package, please try to move the file to the
/usr location and then you'll have to create a security bug anyway for Factory inclusion.
pam.d files:
- Currently in /etc/pam.d
- Moving to /usr/lib/pam.d
- Please use the %_pam_vendordir macro
- These were previously moving to /usr/etc/pam.d (SUSE location)
but then upstream created a vendor location so we follow that, files located in /usr/etc will still be read.
XDG autostart files:
- Currently in /etc/xdg/autostart
- Moving to /usr/etc/xdg/autostart
- There previously was an issue where files located in /usr/etc
weren't being detected by the systemd generator, this was fixed (ref: https://github.com/openSUSE/aaa_base/pull/118) (bug: https://bugzilla.suse.com/show_bug.cgi?id=1201802)
System user accounts and groups:
- Currently created by useradd in %pre
- Moving to creation based on /usr/lib/sysusers.d conf file
(systemd / sysuser-shadow)
- Information on how to create a sysusers.d file can be found at:
https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
Notes:
- When moving existing packages config files to /usr, you will
require a section in the %pre and %posttrans sections to restore the admin's copy of the conf file (ref:
https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi... ).
Although this doesn't really apply to the dbus-1 changes since admins typically would have no reason to overwrite them.
- Don't use %config or %config(noreplace) on the /usr version of the
file
More information on other smaller changes and packaging information can be found here: https://en.opensuse.org/openSUSE:Packaging_UsrEtc
P.S. This was a quick general guide, so some information may be slightly
wrong.
No one can understand that. Four different destinations. Or even more. For me, there is absolutely no logic behind this. Is this really supposed to be set so well?
Regards Eric
On Monday 2022-12-12 18:19, Chris Punches wrote:
This is not FHS-compliant and should not be implemented.
FHS has been dormant for a long-time and everybody has moved on a bit; https://man7.org/linux/man-pages/man7/hier.7.html is the contemporary description of what people consider standard today.
That is absolutely not the case: The manpage you are referencing is literally a copy of the FHS 3 standard, cites the FHS 3.0 standard as its source, and claims to be intended to be conformant to it.
Please read your cited manpage as you are misinforming anyone who might be reading your incorrect statements here that doesn't know better already.
On Mon, Dec 12, Eric Schirra wrote:
No one can understand that. Four different destinations. Or even more. For me, there is absolutely no logic behind this. Is this really supposed to be set so well?
The different locations are all historical. Don't forget, we did not invent that move, but after first upstream projects did it and we had a need for it, we pushed it hard.
We also tried hard to unify this to one location, we had talks on several conferences about this, we spoke with other distributors, but there was no real interest. One the one side you had already several locations, since every project did choose their own, on the other side, many people don't see the need yet. It's the chicken/egg problem: as long as the clean split of /etc is not done, some features are hard to implement. But without this features especially Desktop users don't see the need.
So sorry, but yes, it's a mess and there is no way to clean that up anymore. But even worse would be, if we would change the path of established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit. But 3rd party packages could not longer be installed without problems.
Thorsten
On Mon, Dec 12, Jan Engelhardt wrote:
On Monday 2022-12-12 18:19, Chris Punches wrote:
This is not FHS-compliant and should not be implemented.
FHS has been dormant for a long-time and everybody has moved on a bit; https://man7.org/linux/man-pages/man7/hier.7.html is the contemporary description of what people consider standard today.
But that includes even stuff already removed in FHS 3.0 and not used anymore today.
And to make it really complex, here is the next variant (from the sytemd people, how they see the world): https://manpages.opensuse.org/Tumbleweed/systemd/file-hierarchy.7.en.html
Thorsten
These changes don't comply with systemd's publication either.
systemd's hier page you linked to is a subset of FHS 3.0 and plainly states so in their document. It is not a deviation of FHS 3.0 to follow it. This does not follow it.
But even worse would be, if we would change the path of
established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit
That's why the FHS standard exists in the first place. It's not up to upstream projects where files go on the system. It is up to the distribution maintainers and packagers to maintain FHS compliance to avoid such issues.
Why does it feel like people are not reading the documents they're citing on this?
On Mon, Dec 12, Chris Punches wrote:
That is absolutely not the case: The manpage you are referencing is literally a copy of the FHS 3 standard, cites the FHS 3.0 standard as its source, and claims to be intended to be conformant to it.
Please read your cited manpage as you are misinforming anyone who might be reading your incorrect statements here that doesn't know better already.
I have no idea why you think the whole stuff is incompatible to FHS, but it looks like you should read it yourself again: (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)
"/etc - Host-specific system-wide configuration files."
So every configuration file, which get's installed in /etc and you did never modify, is clearly not host specific and is violating FHS ;)
Our approach (and the one of upstream projects) is fully FHS conform in this regard, as /etc should only contain host specific configuration files (like /etc/fstab) and admin made changes (which are also host specific).
That the FHS is dead since many years and the "current maintainers" refuse to update it to todays needs does not make it easier. Which means, strictly spoken, there is no single Linux distribution out there following to 100% the FHS. That's just impossible if you don't want to miss all new development of the last decade.
Thorsten
On Monday 2022-12-12 18:46, Chris Punches wrote:
But even worse would be, if we would change the path of established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit
That's why the FHS standard exists in the first place. It's not up to upstream projects where files go on the system. It is up to the distribution maintainers and packagers to maintain FHS compliance to avoid such issues.
On Mon, Dec 12, Chris Punches wrote:
These changes don't comply with systemd's publication either.
systemd's hier page you linked to is a subset of FHS 3.0 and plainly states so in their document. It is not a deviation of FHS 3.0 to follow it. This does not follow it.
???
The file-hierarchy.7 clearly states that it is inspired by FHS, but does not follow it. So if you follow the systemd definition, you are no longer FHS conform.
And what we do is exactly the same as systemd is doing.
So FHS != systemd We follow systemd
But you are claiming systemd = FHS and but we not?
But even worse would be, if we would change the path of
established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit
That's why the FHS standard exists in the first place. It's not up to upstream projects where files go on the system. It is up to the distribution maintainers and packagers to maintain FHS compliance to avoid such issues.
Why does it feel like people are not reading the documents they're citing on this?
Why do you always claim we are not FHS without proving it? Why do you not read the documents yourself as you claim others are not doing it?
Please stop ranting here and come up with concrete examples.
Thorsten
Jan Engelhardt wrote:
On Monday 2022-12-12 18:46, Chris Punches wrote:
But even worse would be, if we would change the path of established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit That's why the FHS standard exists in the first place. It's not up to upstream projects where files go on the system. It is up to the distribution maintainers and packagers to maintain FHS compliance to avoid such issues. https://kubic.opensuse.org/blog/2019-12-05-usr-etc/
That explains it. It looks like SUSE has indeed abandoned the FHS by policy.
Sad to hear, as that means standards spread will eventually make it wholly incompatible with the rest of the world, a concern previously expressed by Thorsten Kukuk earlier in the thread as somehow the very justification for standards spread.
!
I'm ducking out of SUSE and this will be the last of my participation. I just had to tell a thread full of accomplished linux engineers why open standards are important, after being told that the manpage which cites FHS 3.0 as its source is not FHS. This entire thread is nonsense and you can all do better.
I get that standards are hard, but the solution to people not being able to track standards is not to abandon them -- it's to train people to do better and for teams to hold each other accountable.
On Mon, 12 Dec 2022 at 18:00, Chris Punches punches.chris@gmail.com wrote:
Jan Engelhardt wrote:
On Monday 2022-12-12 18:46, Chris Punches wrote:
But even worse would be, if we would change the path of established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit That's why the FHS standard exists in the first place. It's not up to upstream projects where files go on the system. It is up to the distribution maintainers and packagers to maintain FHS compliance to avoid such issues. https://kubic.opensuse.org/blog/2019-12-05-usr-etc/
That explains it. It looks like SUSE has indeed abandoned the FHS by policy.
Yes and no. FHS is still valid for us, it's seriously though not the be all and end all of filesystem organisation as it used to be. FHS 3.0 (of 2015) is firstly not 100% correct anyway they tried to change things from earlier releases that would cause issues hence EVERYONE ignored some of what they call 'requirements' (/etc/adjtime to /var/lib as an example). The make up of a Linux system has changed since 2015 but they haven't updated the document. These changes we are doing also do not break the basic /etc and /usr requirements even if FHS said no to /usr/etc because the admin conf file will still reside in /etc, only the vendor (openSUSE) copy will reside in /usr.
Sad to hear, as that means standards spread will eventually make it wholly incompatible with the rest of the world, a concern previously expressed by Thorsten Kukuk earlier in the thread as somehow the very justification for standards spread.
No you're entirely missing the point, following FHS 3.0 entirely in 2022 would CAUSE issues for us and our users, not fix them. The upstreams decided where they want the files to be located and really as long as they don't get stupid (and say put conf files in /usr/bin), the locations they chose are fine logically.
!
I'm ducking out of SUSE and this will be the last of my participation. I just had to tell a thread full of accomplished linux engineers why open standards are important, after being told that the manpage which cites FHS 3.0 as its source is not FHS. This entire thread is nonsense and you can all do better.
This isn't about open standards, it's about an outdated one. Systemd says that because it's telling you hey us and FHS don't agree with each other because FHS no longer makes sense for how we want you to understand how systemd is being designed. You are saying this will lead to us being different from everyone else, it will not because it is written in the upstream documentation such as dbus-1, pam and systemd (example: https://dbus.freedesktop.org/doc/dbus-daemon.1.html)
I get that standards are hard, but the solution to people not being able to track standards is not to abandon them -- it's to train people to do better and for teams to hold each other accountable.
Some of my replies got lost due to Gmail changing from my openSUSE address to my personal address and hence they got rejected by the mail bot.
But this reply allows me to express all of them so here they are.
On Monday 2022-12-12 19:00, Chris Punches wrote:
Jan Engelhardt wrote:
On Monday 2022-12-12 18:46, Chris Punches wrote:
But even worse would be, if we would change the path of established upstream projects, like dbus. This would make us just incompatible with the rest of the world without any benefit That's why the FHS standard exists in the first place. It's not up to upstream projects where files go on the system. It is up to the distribution maintainers and packagers to maintain FHS compliance to avoid such issues. https://kubic.opensuse.org/blog/2019-12-05-usr-etc/
That explains it. It looks like SUSE has indeed abandoned the FHS by policy.
Sad to hear, as that means standards spread will eventually make it wholly incompatible with the rest of the world
Boohoo. HDMI made everything incompatible with the rest of the (VGA) world.
Deal with it.
On 12/12/22 08:34, Callum Farmer wrote:
Hi all,
As many of you will have seen there is an ongoing effort to move config files which currently sit in /etc to /usr (where possible). I just wanted to provide a quick overview of the wider changes and how this affects new packages.
DBUS-1 conf files: - Currently in /etc/dbus-1/system.d - Moving to /usr/share/dbus-1/system.d - If this is a change to an existing package, please file a SUSE security bug before sending it to Factory (example: https://bugzilla.suse.com/show_bug.cgi?id=1204055) - If this is a new package, please try to move the file to the /usr location and then you'll have to create a security bug anyway for Factory inclusion.
pam.d files: - Currently in /etc/pam.d - Moving to /usr/lib/pam.d - Please use the %_pam_vendordir macro - These were previously moving to /usr/etc/pam.d (SUSE location) but then upstream created a vendor location so we follow that, files located in /usr/etc will still be read.
XDG autostart files: - Currently in /etc/xdg/autostart - Moving to /usr/etc/xdg/autostart - There previously was an issue where files located in /usr/etc weren't being detected by the systemd generator, this was fixed (ref: https://github.com/openSUSE/aaa_base/pull/118) (bug: https://bugzilla.suse.com/show_bug.cgi?id=1201802)
System user accounts and groups: - Currently created by useradd in %pre - Moving to creation based on /usr/lib/sysusers.d conf file (systemd / sysuser-shadow) - Information on how to create a sysusers.d file can be found at: https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
Notes: - When moving existing packages config files to /usr, you will require a section in the %pre and %posttrans sections to restore the admin's copy of the conf file (ref: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...). Although this doesn't really apply to the dbus-1 changes since admins typically would have no reason to overwrite them. - Don't use %config or %config(noreplace) on the /usr version of the file
More information on other smaller changes and packaging information can be found here: https://en.opensuse.org/openSUSE:Packaging_UsrEtc
P.S. This was a quick general guide, so some information may be slightly wrong.
So you expect upstream packages we use in openSUSE to create a layered configuration file system, since systemd does it that way?
The way I see it, I'd have to submit changes upstream to do this (ignoring the hours of work it would take), then hope they accept them, and if they do then other distributions using the code would have to change as well. And all to support some transactional model layered on top of Linux?
I guess at some point you're just going to have to quit supporting many packages then.
On Mon, 12 Dec 2022 at 20:21, Lee Duncan lduncan@suse.com wrote:
On 12/12/22 08:34, Callum Farmer wrote:
Hi all,
As many of you will have seen there is an ongoing effort to move config files which currently sit in /etc to /usr (where possible). I just wanted to provide a quick overview of the wider changes and how this affects new packages.
DBUS-1 conf files: - Currently in /etc/dbus-1/system.d - Moving to /usr/share/dbus-1/system.d - If this is a change to an existing package, please file a SUSE security bug before sending it to Factory (example: https://bugzilla.suse.com/show_bug.cgi?id=1204055) - If this is a new package, please try to move the file to the /usr location and then you'll have to create a security bug anyway for Factory inclusion.
pam.d files: - Currently in /etc/pam.d - Moving to /usr/lib/pam.d - Please use the %_pam_vendordir macro - These were previously moving to /usr/etc/pam.d (SUSE location) but then upstream created a vendor location so we follow that, files located in /usr/etc will still be read.
XDG autostart files: - Currently in /etc/xdg/autostart - Moving to /usr/etc/xdg/autostart - There previously was an issue where files located in /usr/etc weren't being detected by the systemd generator, this was fixed (ref: https://github.com/openSUSE/aaa_base/pull/118) (bug: https://bugzilla.suse.com/show_bug.cgi?id=1201802)
System user accounts and groups: - Currently created by useradd in %pre - Moving to creation based on /usr/lib/sysusers.d conf file (systemd / sysuser-shadow) - Information on how to create a sysusers.d file can be found at: https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
Notes: - When moving existing packages config files to /usr, you will require a section in the %pre and %posttrans sections to restore the admin's copy of the conf file (ref: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...). Although this doesn't really apply to the dbus-1 changes since admins typically would have no reason to overwrite them. - Don't use %config or %config(noreplace) on the /usr version of the file
More information on other smaller changes and packaging information can be found here: https://en.opensuse.org/openSUSE:Packaging_UsrEtc
P.S. This was a quick general guide, so some information may be slightly wrong.
So you expect upstream packages we use in openSUSE to create a layered configuration file system, since systemd does it that way?
Why is my small guide to an active SUSE driven change suddenly controversial?
No, only if they already support it or when SUSE can easily patch the program
The way I see it, I'd have to submit changes upstream to do this (ignoring the hours of work it would take), then hope they accept them, and if they do then other distributions using the code would have to change as well. And all to support some transactional model layered on top of Linux?
If the program doesn't support this at the moment, that's still fine, no need to do anything. This is mostly only in the documented cases on the wiki.
If the program has one of the documented cases but the build system doesn't have an option to move the file, you can move it in packaging.
I guess at some point you're just going to have to quit supporting many packages then.
Exactly why this isn't for everything and why I didn't say that.
-- Lee Duncan Owner of half a dozen packages that use /etc for config files.
Was this necessary?
On Mon, Dec 12, Lee Duncan wrote:
So you expect upstream packages we use in openSUSE to create a layered configuration file system, since systemd does it that way?
Many upstream packages do that already, we just never really enforced, that package maintainers adjust their packages. See e.g. dbus.
The way I see it, I'd have to submit changes upstream to do this (ignoring the hours of work it would take), then hope they accept them, and if they do then other distributions using the code would have to change as well. And all to support some transactional model layered on top of Linux?
Not because of transactional update or something similar, there are many more reasons. Just read the blog mentioned in this thread or the old discussion on factory about this some years ago.
And about upstream: my team made very good experience with this. We upstreamed many of our changes, and only once a maintainer refused the idea at all. Else all changes are upstream. Only today we got support for /etc/shells (/etc/shells.d, /usr/*/shells.d/, ...) upstream in Linux-PAM and util-linux, shadow is only waiting for some documentation adjustements.
Latest if this https://uapi-group.org/ get's further this all about /etc will get a real boost.
Thorsten
I guess at some point you're just going to have to quit supporting many packages then.
-- Lee Duncan Owner of half a dozen packages that use /etc for config files.
On 12/12/22 13:27, Thorsten Kukuk wrote:
On Mon, Dec 12, Lee Duncan wrote:
So you expect upstream packages we use in openSUSE to create a layered configuration file system, since systemd does it that way?
Many upstream packages do that already, we just never really enforced, that package maintainers adjust their packages. See e.g. dbus.
The way I see it, I'd have to submit changes upstream to do this (ignoring the hours of work it would take), then hope they accept them, and if they do then other distributions using the code would have to change as well. And all to support some transactional model layered on top of Linux?
Not because of transactional update or something similar, there are many more reasons. Just read the blog mentioned in this thread or the old discussion on factory about this some years ago.
I read the blog post. It still seems a lot of work for no change to the end user.
Each time something moves like this, in a package, users have to learn the new location. And then distributions (like SUSE) need to jump through hoops to support both the old and the new location.
For example, I moved the configuring file for open-iscsi from /etc/iscsid.conf to /etc/iscsi/iscsid.conf about 10 years ago. And the symlink /etc/iscsid.conf I created to keep users from freaking out is still there. And now I'm moving database files from /etc/iscsi to /var/log/iscsi, and again I'm having to put in quite a few hours to package this correctly for both TW and SLES. (Oh yeah: and /sbin vs /usr/sbin.) So now let's also just quit using redesign our configuration system to support stacked config directories? I can see this in new packages, but in existing ones?
And about upstream: my team made very good experience with this. We upstreamed many of our changes, and only once a maintainer refused the idea at all. Else all changes are upstream. Only today we got support for /etc/shells (/etc/shells.d, /usr/*/shells.d/, ...) upstream in Linux-PAM and util-linux, shadow is only waiting for some documentation adjustements.
In this case I'm one of the two upstream maintainers for two of my packages that use /etc for configuration.
On 13.12.2022 00:43, Lee Duncan wrote:
For example, I moved the configuring file for open-iscsi from /etc/iscsid.conf to /etc/iscsi/iscsid.conf about 10 years ago. And the symlink /etc/iscsid.conf I created to keep users from freaking out is still there. And now I'm moving database files from /etc/iscsi to /var/log/iscsi,
/var/log sounds like a strange location for a database. /var/lib would be more logical.
On 12/12/22 20:03, Andrei Borzenkov wrote:
On 13.12.2022 00:43, Lee Duncan wrote:
For example, I moved the configuring file for open-iscsi from /etc/iscsid.conf to /etc/iscsi/iscsid.conf about 10 years ago. And the symlink /etc/iscsid.conf I created to keep users from freaking out is still there. And now I'm moving database files from /etc/iscsi to /var/log/iscsi,
/var/log sounds like a strange location for a database. /var/lib would be more logical.
Apologies, it is actually /var/lib/iscsi. If you have tumbleweed you can install open-iscsi and see for yourself how it's currently configured there.
-
Andrei Borzenkov -
Callum Farmer -
Chris Punches -
Eric Schirra -
Jan Engelhardt -
Lee Duncan -
Thorsten Kukuk