https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups.
The files that will be moved are: * /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db * /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks * /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth * /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf * /var/lib/authselect/password-auth /etc/authselect/.state/password-auth * /var/lib/authselect/postlogin /etc/authselect/.state/postlogin * /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth * /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
== Owner == * Name: [[User:pbrezina| Pavel Březina]] * Email: pbrezina@redhat.com
== Detailed Description ==
These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'. There are two reasons for the move:
1. The current location conflicts with ostree model where /var is not writable during rpm transaction and this currently blocks compose of ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360]
2. Removing these files would reduce authselect functionality, user would need to run 'authselect select --force' to restore it. Since /var should contain only files that can be safely removed, /etc is a better place for them.
== Feedback ==
This change is accepted by ostree system maintainers, see [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].
== Benefit to Fedora == This makes authselect more compatible with ostree model.
== Scope == * Proposal owners: Build authselect with --statedir=/etc/authselect/.state and move files from /var/lib/authselect to the new location. Spec file changes only.
* Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/10544 #10544] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
No impact. Files will be moved automatically during update and everything will keep working as prior.
== How To Test ==
1. Authselect keeps working as expected after the upgrade
== User Experience ==
This change is only under the hood, it does not affect user experience.
== Dependencies ==
No dependencies.
== Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change)
== Documentation == N/A (not a System Wide Change)
== Release Notes ==
Authselect state files moved from /var/lib/authselect to /etc/authselect/.state.
On 18/01/2022 18:32, Ben Cotton wrote:
Authselect state files moved from/var/lib/authselect to /etc/authselect/.state.
Why /etc/authselect/.state and not /etc/authselect/state? Dot in front of the name means hidden file/directory.
On 1/18/22 19:03, Vitaly Zaitsev via devel wrote:
On 18/01/2022 18:32, Ben Cotton wrote:
Authselect state files moved from/var/lib/authselect to /etc/authselect/.state.
Why /etc/authselect/.state and not /etc/authselect/state? Dot in front of the name means hidden file/directory.
This is the intention, it should not be touched by users therefore it should not be visible to users, in my opinion.
On 19/01/2022 09:54, Pavel Březina wrote:
This is the intention, it should not be touched by users therefore it should not be visible to users, in my opinion.
Packaging of hidden files/directories is not a good idea.
/etc is meant to be editable by user.
On Wed, Jan 19 2022 at 12:56:26 PM +0100, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
Packaging of hidden files/directories is not a good idea.
Yeah that seems too creative. I don't think we need to hide files in system directories.
On Wed, Jan 19, 2022 at 4:56 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 19/01/2022 09:54, Pavel Březina wrote:
This is the intention, it should not be touched by users therefore it should not be visible to users, in my opinion.
Packaging of hidden files/directories is not a good idea.
/etc is meant to be editable by user.
Whereas /var/lib is not:
FHS 5.8.1 Users must never need to modify files in /var/lib to configure a package's operation, and the specific file hierarchy used to store the data must not be exposed to regular users.
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
-- Petr
On 1/19/22 11:04, Petr Pisar wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Though when removed, the application should remain functional and just recreate it automatically, right?
Authselect would require user intervention.
-- Petr
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:04, Petr Pisar wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Though when removed, the application should remain functional and just recreate it automatically, right?
Yes.
Authselect would require user intervention.
Yes.
-- Petr
On 1/19/22 11:35, Petr Pisar wrote:
V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:04, Petr Pisar wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Though when removed, the application should remain functional and just recreate it automatically, right?
Yes.
Authselect would require user intervention.
Yes.
Ok, how about phrasing it:
Removing these files would reduce authselect functionality, user would need to run 'authselect select --force' to restore it. This however conflicts with purpose of /var which should contain only data that do not affect functionality when removed.
Thanks, Pavel
V Wed, Jan 19, 2022 at 11:55:48AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:35, Petr Pisar wrote:
V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:04, Petr Pisar wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Though when removed, the application should remain functional and just recreate it automatically, right?
Yes.
Authselect would require user intervention.
Yes.
Ok, how about phrasing it:
Removing these files would reduce authselect functionality, user would need to run 'authselect select --force' to restore it. This however conflicts with purpose of /var which should contain only data that do not affect functionality when removed.
That's better, but still not right. /var is not about "functionality when removed". /var is simply about files which can change (as an opposite to a change when installing a software). (Compare to https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#purpose31. E.g. if you delete /var/spool/mail, then a lot of people will say that a functionallity of their mailboxes is seriously affected.)
I would simply remove the sentence "This however...". Because the truth is that the conflict is not with the purpose of /var.
If you want reason why /var is not suitable, then simpy admit that /var is not managed by os-tree and that thus you need a better location which /etc seems to be because you are moving authconfig's configuration files.
-- Petr
On 1/19/22 12:40, Petr Pisar wrote:
V Wed, Jan 19, 2022 at 11:55:48AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:35, Petr Pisar wrote:
V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:04, Petr Pisar wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Though when removed, the application should remain functional and just recreate it automatically, right?
Yes.
Authselect would require user intervention.
Yes.
Ok, how about phrasing it:
Removing these files would reduce authselect functionality, user would need to run 'authselect select --force' to restore it. This however conflicts with purpose of /var which should contain only data that do not affect functionality when removed.
That's better, but still not right. /var is not about "functionality when removed". /var is simply about files which can change (as an opposite to a change when installing a software). (Compare to https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#purpose31. E.g. if you delete /var/spool/mail, then a lot of people will say that a functionallity of their mailboxes is seriously affected.)
I would simply remove the sentence "This however...". Because the truth is that the conflict is not with the purpose of /var.
If you want reason why /var is not suitable, then simpy admit that /var is not managed by os-tree and that thus you need a better location which /etc seems to be because you are moving authconfig's configuration files.
Thank you. This statement about /var was indeed an attempt to justify the change outside ostree-enabled systems. But as it seems to be false and it created unexpected discussion I rephrased the section to:
""" These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'.
Unfortunately, the current location conflicts with ostree model where /var is not writable during rpm transaction and this currently blocks compose of ostree systems (see BZ#2034360). At the same time /usr is read-only on client side of ostree-enabled installations therefore the files can not be moved there since it would break authselect on the client side.
Storing these files under /etc/authselect will make authselect work on both server and client side of ostree systems. """
-- Petr
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
V Thu, Jan 20, 2022 at 11:26:49AM +0100, Pavel Březina napsal(a):
On 1/19/22 12:40, Petr Pisar wrote:
V Wed, Jan 19, 2022 at 11:55:48AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:35, Petr Pisar wrote:
V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):
On 1/19/22 11:04, Petr Pisar wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a): > Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Though when removed, the application should remain functional and just recreate it automatically, right?
Yes.
Authselect would require user intervention.
Yes.
Ok, how about phrasing it:
Removing these files would reduce authselect functionality, user would need to run 'authselect select --force' to restore it. This however conflicts with purpose of /var which should contain only data that do not affect functionality when removed.
That's better, but still not right. /var is not about "functionality when removed". /var is simply about files which can change (as an opposite to a change when installing a software). (Compare to https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#purpose31. E.g. if you delete /var/spool/mail, then a lot of people will say that a functionallity of their mailboxes is seriously affected.)
I would simply remove the sentence "This however...". Because the truth is that the conflict is not with the purpose of /var.
If you want reason why /var is not suitable, then simpy admit that /var is not managed by os-tree and that thus you need a better location which /etc seems to be because you are moving authconfig's configuration files.
Thank you. This statement about /var was indeed an attempt to justify the change outside ostree-enabled systems. But as it seems to be false and it created unexpected discussion I rephrased the section to:
""" These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'.
Unfortunately, the current location conflicts with ostree model where /var is not writable during rpm transaction and this currently blocks compose of ostree systems (see BZ#2034360). At the same time /usr is read-only on client side of ostree-enabled installations therefore the files can not be moved there since it would break authselect on the client side.
Storing these files under /etc/authselect will make authselect work on both server and client side of ostree systems. """
Thanks.
-- Petr
On Wed, Jan 19, 2022 at 3:04 AM Petr Pisar ppisar@redhat.com wrote:
V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
Since /var should contain only files that can be safely removed,
While I agree with your change, this statement is false. /var is for any files which are variable. Files which can be safely removed belong to /var/tmp and /var/cache.
Either /etc or /var should contain files that can be safely removed, i.e. the system or application shouldn't break. Anything needing some sort of base state information to function at all, needs to put that in /usr, and customization/modification results in it being written to /etc (configuration) or /var (runtime variable state information).
So if the files in question being moved were to be deleted, authselect needs to handle that potential regardless of whether the state information is in /etc or /var.
From FHS 5.8.1 about /var/lib "State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application."
If anything is more likely to get wiped in a factory/system reset, I think it's /etc. I expect upon configuration information being reset, that by extension the variable state information is rendered unreliable or useless. Conversely, upon wiping a program's /var/lib information, the configuration information in /etc is not inherently invalid. I don't see much information in the FHS about the expected behavior or consequences of wiping either location. But I think as a distribution we can have the opinion the programs that face plant upon finding empty /etc or /var/lib still should have the ability to self-configure from /usr - be it a built-in process or some upstream default /usr/etc configuration or base state information in /usr/var - customization of either means populating the proper /etc or /var/lib
FHS 3.7 is pretty clear that /etc is for configuration information, no binaries. I'm not completely sure I agree that state information is disallowed in /etc, although I think the intent of the FHS here is so that users can ostensibly reset a program's persistent state by wiping the program's /var/lib information, which wouldn't alter its configuration. If it's possible such a scenario confuses the program, it really needs to be better prepared for this potential.
This push to destroy /var really needs to be stopped, or at least handled as a whole and not on a piecemeal basis. There are many packages that store data and config in /var that is NOT to be deleted at will. The big thing is databases, but there are lots of little things. For example, snmpd stores program-generated config in /var/lib/net-snmp, which gets merged with config from /etc/snmp.
On Wed, Jan 19, 2022 at 11:48 AM Chris Adams linux@cmadams.net wrote:
This push to destroy /var really needs to be stopped, or at least handled as a whole and not on a piecemeal basis. There are many packages that store data and config in /var that is NOT to be deleted at will. The big thing is databases, but there are lots of little things.
No one is envisioning non-obvious or automatic factory resets as a matter of course.
Firefox keeps a bunch of databases ~/.mozilla/firefox. Were it true that deleting any of these databases resulted in Firefox crashing, or otherwise being non-functional, that would be a bug. It is also true that deleting these databases, or the entire user profile, constitutes data loss. That it is data loss doesn't absolve an application from misbehaving, rather than reverting to a default but functional state.
For example, snmpd stores program-generated config in /var/lib/net-snmp, which gets merged with config from /etc/snmp.
What's the exact consequence of deleting either /etc/snmp and /var/lib/net-snmp - separately and together?
If there's program-generated config in /var/lib/net-snmp, why can't it regenerate it when its missing?
Once upon a time, Chris Murphy lists@colorremedies.com said:
For example, snmpd stores program-generated config in /var/lib/net-snmp, which gets merged with config from /etc/snmp.
What's the exact consequence of deleting either /etc/snmp and /var/lib/net-snmp - separately and together?
Delete either one and permanent config is lost. Admin config is in /etc/snmp and program-generated config (sometimes based on admin config) /var/lib/net-snmp.
If there's program-generated config in /var/lib/net-snmp, why can't it regenerate it when its missing?
The documented way to create SNMPv3 users puts the config in /var/lib/net-snmp. The system serial number and engine ID are randomly generated at the first startup and saved in /var/lib/net-snmp (but are then supposed to stay constant for the life of the system). Persistent network interface IDs are stored in /var/lib/net-snmp. Those are just a few things I know of.
Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a new system, with new IDs, a renumbered interface table, and loss of SNMPv3 users.
And that's just one thing I know of that uses /var in such a manner. How many other things expect /var to be an integrated part of the OS? Making /usr "special" and throwing all other directories away is a bad plan, only sustainable for a niche subset of packages. If snapshots are so important, an actual integrated plan for the WHOLE OS needs to be created, not just by recreating all the parts of / that someone is interested in under /usr.
On Wed, Jan 19, 2022 at 6:14 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
For example, snmpd stores program-generated config in /var/lib/net-snmp, which gets merged with config from /etc/snmp.
What's the exact consequence of deleting either /etc/snmp and /var/lib/net-snmp - separately and together?
Delete either one and permanent config is lost. Admin config is in /etc/snmp and program-generated config (sometimes based on admin config) /var/lib/net-snmp.
So it renders the system like a cleanly installed Fedora system. It's not like there's additional breakage beyond simply not having access to particular SNMP services. I don't have an /etc/snmp dir, and the /var/lib/net-snmp dir contains a couple empty directories.
Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a new system, with new IDs, a renumbered interface table, and loss of SNMPv3 users.
You're not going to wipe /var to do a reset casually - the idea would be, this hardware isn't coming back to this environment. An easy option with snapshots is you can define your own rollback point, which includes environment specific configuration rather than the "wipe /var and /etc" method of factory reset.
And that's just one thing I know of that uses /var in such a manner. How many other things expect /var to be an integrated part of the OS?
Well, affore mentioned selinux issue https://bugzilla.redhat.com/show_bug.cgi?id=1290659
But deleting /var/lib/selinux doesn't cause obvious failure - though I might be (silently) in a security reduced situation, I can't really tell.
Making /usr "special" and throwing all other directories away is a bad plan, only sustainable for a niche subset of packages. If snapshots are so important, an actual integrated plan for the WHOLE OS needs to be created, not just by recreating all the parts of / that someone is interested in under /usr.
The snapshots, rollbacks, FHS, /usr /var question is bigger than, and is also out of scope for, this change proposal. I think it's relevant and important, but needs to go into its own thread.
-- Chris Murphy
On 1/20/22 06:16, Chris Murphy wrote:
Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a new system, with new IDs, a renumbered interface table, and loss of SNMPv3 users.
You're not going to wipe /var to do a reset casually - the idea would be, this hardware isn't coming back to this environment. An easy option with snapshots is you can define your own rollback point, which includes environment specific configuration rather than the "wipe /var and /etc" method of factory reset.
Who exactly is the alleged user of the "factory reset" feature?
Nobody in their right mind should think, or be lead to think, that 'rm -rf /some /dirs' is sufficient to wipe your possibly confidential data to a degree that you can just ship the hardware away.
- Panu -
On 1/20/22 01:13, Panu Matilainen wrote:
On 1/20/22 06:16, Chris Murphy wrote:
Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a new system, with new IDs, a renumbered interface table, and loss of SNMPv3 users.
You're not going to wipe /var to do a reset casually - the idea would be, this hardware isn't coming back to this environment. An easy option with snapshots is you can define your own rollback point, which includes environment specific configuration rather than the "wipe /var and /etc" method of factory reset.
Who exactly is the alleged user of the "factory reset" feature?
Nobody in their right mind should think, or be lead to think, that 'rm -rf /some /dirs' is sufficient to wipe your possibly confidential data to a degree that you can just ship the hardware away.
- Panu -
Agreed. “Factory reset” means either “I trust the secure erase function on all of my disks” or “all the data that has ever hit the disk was encrypted and I just securely deleted the encryption key”.
On Thu, Jan 20, 2022 at 8:14 AM Demi Marie Obenour demiobenour@gmail.com wrote:
On 1/20/22 01:13, Panu Matilainen wrote:
On 1/20/22 06:16, Chris Murphy wrote:
Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a new system, with new IDs, a renumbered interface table, and loss of SNMPv3 users.
You're not going to wipe /var to do a reset casually - the idea would be, this hardware isn't coming back to this environment. An easy option with snapshots is you can define your own rollback point, which includes environment specific configuration rather than the "wipe /var and /etc" method of factory reset.
Who exactly is the alleged user of the "factory reset" feature?
Nobody in their right mind should think, or be lead to think, that 'rm -rf /some /dirs' is sufficient to wipe your possibly confidential data to a degree that you can just ship the hardware away.
- Panu -Agreed. “Factory reset” means either “I trust the secure erase function on all of my disks” or “all the data that has ever hit the disk was encrypted and I just securely deleted the encryption key”.
"Factory reset" means "reset to initial setup state". You're talking about "secure erase", which is very different and leaves the system unusable.
On Wed, Jan 19, 2022 at 11:14 PM Panu Matilainen pmatilai@redhat.com wrote:
On 1/20/22 06:16, Chris Murphy wrote:
Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a new system, with new IDs, a renumbered interface table, and loss of SNMPv3 users.
You're not going to wipe /var to do a reset casually - the idea would be, this hardware isn't coming back to this environment. An easy option with snapshots is you can define your own rollback point, which includes environment specific configuration rather than the "wipe /var and /etc" method of factory reset.
Who exactly is the alleged user of the "factory reset" feature?
Nobody in their right mind should think, or be lead to think, that 'rm -rf /some /dirs' is sufficient to wipe your possibly confidential data to a degree that you can just ship the hardware away.
The thread is about an Authselect change. I think interesting but unrelated discussions should go in a dedicated thread.
Resetting a computer's OS to default settings is not the same thing as media sanitization. One is strictly about reverting to default configuration. The other is about removing latent data from the media.
On Tue, Jan 18, 2022 at 6:34 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups.
The files that will be moved are:
- /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
- /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
- /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth
- /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
- /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
- /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
- /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth
- /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
== Owner ==
- Name: [[User:pbrezina| Pavel Březina]]
- Email: pbrezina@redhat.com
== Detailed Description ==
These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'. There are two reasons for the move:
- The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360]
- Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since /var should contain only files that can be safely removed, /etc is a better place for them.
I wonder why you seem to be reinventing the wheel here?
We are already moving rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm for a very similar reason, so wouldn't it make sense to do a similar thing here, and use /usr/lib/sysimage/authselect? Putting those files inside /etc (especially inside a hidden directoy) seems very wrong.
Fabio
On Wed, Jan 19, 2022 at 10:19 AM Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Jan 18, 2022 at 6:34 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups.
The files that will be moved are:
- /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
- /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
- /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth
- /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
- /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
- /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
- /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth
- /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
== Owner ==
- Name: [[User:pbrezina| Pavel Březina]]
- Email: pbrezina@redhat.com
== Detailed Description ==
These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'. There are two reasons for the move:
- The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360]
- Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since /var should contain only files that can be safely removed, /etc is a better place for them.
I wonder why you seem to be reinventing the wheel here?
We are already moving rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm for a very similar reason, so wouldn't it make sense to do a similar thing here, and use /usr/lib/sysimage/authselect? Putting those files inside /etc (especially inside a hidden directoy) seems very wrong.
I agree, I think it should move to /usr/lib/sysimage/authselect instead.
On Wed, Jan 19, 2022, at 10:25 AM, Neal Gompa wrote:
I agree, I think it should move to /usr/lib/sysimage/authselect instead.
That would break the use case of running it on an image based (i.e. readonly /usr) system *client side*.
We settled on having it in /etc in https://bugzilla.redhat.com/show_bug.cgi?id=2034360 because that works symmetrically across both. It's also keeps the backups closer to the original files (e.g. they're more likely to be on the same file so reflinks could be used). I think these authselect backups are really similar to e.g. `.rpmnew/.rpmorig` and similar.
On 1/19/22 17:06, Colin Walters wrote:
On Wed, Jan 19, 2022, at 10:25 AM, Neal Gompa wrote:
I agree, I think it should move to /usr/lib/sysimage/authselect instead.
That would break the use case of running it on an image based (i.e. readonly /usr) system *client side*.
We settled on having it in /etc in https://bugzilla.redhat.com/show_bug.cgi?id=2034360 because that works symmetrically across both. It's also keeps the backups closer to the original files (e.g. they're more likely to be on the same file so reflinks could be used). I think these authselect backups are really similar to e.g. `.rpmnew/.rpmorig` and similar.
The purpose of these files is to detect user's non-authselect modifications of the configuration and prevent overwriting user's configuration. In other words, if you choose to modify PAM or nsswitch on your own without authselect, then authselect will stop managing the files for you unless you tell it to do so again.
The problem with ostree is that /var is read-only on server side and /usr is read-only on client side so neither can store these data. /etc is writable on both sides.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I have naive question why these files are not static and in /usr.
I mean, I am pretty sure I won't run `authselect select --force` or anything similar any time soon. So why the configuration is not static, generated at build time, not having anything in /etc unless somebody really wants to change something.
Vít
Dne 18. 01. 22 v 18:32 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups.
The files that will be moved are:
- /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
- /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
- /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth
- /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
- /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
- /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
- /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth
- /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
== Owner ==
- Name: [[User:pbrezina| Pavel Březina]]
- Email: pbrezina@redhat.com
== Detailed Description ==
These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'. There are two reasons for the move:
- The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360]
- Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since /var should contain only files that can be safely removed, /etc is a better place for them.
== Feedback ==
This change is accepted by ostree system maintainers, see [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].
== Benefit to Fedora == This makes authselect more compatible with ostree model.
== Scope ==
- Proposal owners: Build authselect with
--statedir=/etc/authselect/.state and move files from /var/lib/authselect to the new location. Spec file changes only.
- Other developers: N/A (not needed for this Change)
- Release engineering: [https://pagure.io/releng/issue/10544 #10544]
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
No impact. Files will be moved automatically during update and everything will keep working as prior.
== How To Test ==
- Authselect keeps working as expected after the upgrade
== User Experience ==
This change is only under the hood, it does not affect user experience.
== Dependencies ==
No dependencies.
== Contingency Plan ==
- Contingency mechanism: N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change)
== Documentation == N/A (not a System Wide Change)
== Release Notes ==
Authselect state files moved from /var/lib/authselect to /etc/authselect/.state.
On 1/20/22 12:52, Vít Ondruch wrote:
I have naive question why these files are not static and in /usr.
I mean, I am pretty sure I won't run `authselect select --force` or anything similar any time soon. So why the configuration is not static, generated at build time, not having anything in /etc unless somebody really wants to change something.
The files are not static at all, they are change with different kinds of authselect calls:
- user wants to use different profile then default: authselect select - enable/disable single feature: authselect enable/disable-feature - apply changes when package is updated: authselect apply-changes - apply changes when you modify your custom profile: authselect apply-changes
They remembers how the current configuration looks like so we can check if user modified nsswitch and PAM configuration on their own or not.
Vít
Dne 18. 01. 22 v 18:32 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups.
The files that will be moved are:
- /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
- /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
- /var/lib/authselect/fingerprint-auth
/etc/authselect/.state/fingerprint-auth
- /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
- /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
- /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
- /var/lib/authselect/smartcard-auth
/etc/authselect/.state/smartcard-auth
- /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
== Owner ==
- Name: [[User:pbrezina| Pavel Březina]]
- Email: pbrezina@redhat.com
== Detailed Description ==
These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'. There are two reasons for the move:
- The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360]
- Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since /var should contain only files that can be safely removed, /etc is a better place for them.
== Feedback ==
This change is accepted by ostree system maintainers, see [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].
== Benefit to Fedora == This makes authselect more compatible with ostree model.
== Scope ==
- Proposal owners: Build authselect with
--statedir=/etc/authselect/.state and move files from /var/lib/authselect to the new location. Spec file changes only.
- Other developers: N/A (not needed for this Change)
- Release engineering: [https://pagure.io/releng/issue/10544 #10544]
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
No impact. Files will be moved automatically during update and everything will keep working as prior.
== How To Test ==
- Authselect keeps working as expected after the upgrade
== User Experience ==
This change is only under the hood, it does not affect user experience.
== Dependencies ==
No dependencies.
== Contingency Plan ==
- Contingency mechanism: N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change)
== Documentation == N/A (not a System Wide Change)
== Release Notes ==
Authselect state files moved from /var/lib/authselect to /etc/authselect/.state.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):
On 1/20/22 12:52, Vít Ondruch wrote:
I have naive question why these files are not static and in /usr.
I mean, I am pretty sure I won't run `authselect select --force` or anything similar any time soon. So why the configuration is not static, generated at build time, not having anything in /etc unless somebody really wants to change something.
The files are not static at all, they are change with different kinds of authselect calls:
- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature
As I said, the above is not my case and I'd say not case for most of Fedora users.
- apply changes when package is updated: authselect apply-changes
Why is this needed? In which packages? Why simply not apply the changes regardless of the previous state?
- apply changes when you modify your custom profile: authselect
apply-changes
This is again belongs to the initial group.
They remembers how the current configuration looks like so we can check if user modified nsswitch and PAM configuration on their own or not.
"user modified nsswitch and PAM configuration" is not thing I do. The only time I needed to touch nsswitch configuration was always because the configuration was screwed up by some updates, not by me.
IOW, from users perspective, the configuration is static. If installation/updates changes the configuration, then it is again static from user perspective. So I still don't see the need to have the configuration files around by default.
Also, I think this proposal is focusing on wrong aspect, i.e. moving files around from one location to another. It would be much better to remove their need.
Vít
On 1/20/22 15:15, Vít Ondruch wrote:
Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):
On 1/20/22 12:52, Vít Ondruch wrote:
I have naive question why these files are not static and in /usr.
I mean, I am pretty sure I won't run `authselect select --force` or anything similar any time soon. So why the configuration is not static, generated at build time, not having anything in /etc unless somebody really wants to change something.
The files are not static at all, they are change with different kinds of authselect calls:
- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature
As I said, the above is not my case and I'd say not case for most of Fedora users.
- apply changes when package is updated: authselect apply-changes
Why is this needed? In which packages? Why simply not apply the changes regardless of the previous state?
- apply changes when you modify your custom profile: authselect
apply-changes
This is again belongs to the initial group.
They remembers how the current configuration looks like so we can check if user modified nsswitch and PAM configuration on their own or not.
"user modified nsswitch and PAM configuration" is not thing I do. The only time I needed to touch nsswitch configuration was always because the configuration was screwed up by some updates, not by me.
IOW, from users perspective, the configuration is static. If installation/updates changes the configuration, then it is again static from user perspective. So I still don't see the need to have the configuration files around by default.
Also, I think this proposal is focusing on wrong aspect, i.e. moving files around from one location to another. It would be much better to remove their need.
Vít
That would be the ideal world, wouldn't it? Especially for me, as authselect maintainer :-)
Fedora 36 will move most of the users to authselect and packages won't screw the configuration anymore. However, most of the guides on the internet on the subject matter don't mention authselect yet so there will be cases when users modify the configuration manually without disabling authselect even though not intentionally. And again - not overwriting user's configuration is important design decision to authselect.
We can of course simplify the detection and not rely on the configuration content anymore but perhaps just rely on the presence and validity of /etc/authselect/authselect.conf - if it is there, assume that user wants to use authselect. I'd would certainly welcome such change.
This however would be a major functional change, so perhaps something to consider for the next release.
Dne 21. 01. 22 v 11:23 Pavel Březina napsal(a):
On 1/20/22 15:15, Vít Ondruch wrote:
Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):
On 1/20/22 12:52, Vít Ondruch wrote:
I have naive question why these files are not static and in /usr.
I mean, I am pretty sure I won't run `authselect select --force` or anything similar any time soon. So why the configuration is not static, generated at build time, not having anything in /etc unless somebody really wants to change something.
The files are not static at all, they are change with different kinds of authselect calls:
- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature
As I said, the above is not my case and I'd say not case for most of Fedora users.
- apply changes when package is updated: authselect apply-changes
Why is this needed? In which packages? Why simply not apply the changes regardless of the previous state?
- apply changes when you modify your custom profile: authselect
apply-changes
This is again belongs to the initial group.
They remembers how the current configuration looks like so we can check if user modified nsswitch and PAM configuration on their own or not.
"user modified nsswitch and PAM configuration" is not thing I do. The only time I needed to touch nsswitch configuration was always because the configuration was screwed up by some updates, not by me.
IOW, from users perspective, the configuration is static. If installation/updates changes the configuration, then it is again static from user perspective. So I still don't see the need to have the configuration files around by default.
Also, I think this proposal is focusing on wrong aspect, i.e. moving files around from one location to another. It would be much better to remove their need.
Vít
That would be the ideal world, wouldn't it? Especially for me, as authselect maintainer :-)
Fedora 36 will move most of the users to authselect and packages won't screw the configuration anymore. However, most of the guides on the internet on the subject matter don't mention authselect yet
1) If there is no configuration file, which is mentioned in such guide, that could give them hint
2) If the hint from previous step is not enough, then authselect could warn.
so there will be cases when users modify the configuration manually without disabling authselect even though not intentionally. And again
- not overwriting user's configuration is important design decision to
authselect.
We can of course simplify the detection and not rely on the configuration content anymore but perhaps just rely on the presence and validity of /etc/authselect/authselect.conf - if it is there, assume that user wants to use authselect. I'd would certainly welcome such change.
This however would be a major functional change, so perhaps something to consider for the next release.
That would be great. Looking forward to it. Thx for considering!
Vít
On Di, 18.01.22 12:32, Ben Cotton (bcotton@redhat.com) wrote:
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups.
The files that will be moved are:
- /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
- /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
A lock file in /etc? What is that precisely? Shouldn't that be in /run? (i.e. locks are runtime concepts typically, hence should neither be in /etc/ not in /var/.
- /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth
- /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
- /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
- /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
- /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth
- /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
I think it would be best to put a comment in each saying something like:
# This file is autogenerated by foo, do not edit. Use foo --regenerate # to modify, see foo(1) for details.
at the top of each file, and not hide them.
Hiding stuff is mean. Might be fine for temporary files, but not for stuff that actually matters. Might be OK in $HOME too, maybe, but otherwise, please don't hide stuff.
Lennart
-- Lennart Poettering, Berlin
-
Ben Cotton -
Chris Adams -
Chris Murphy -
Colin Walters -
Demi Marie Obenour -
Fabio Valentini -
Lennart Poettering -
Michael Catanzaro -
Neal Gompa -
Panu Matilainen -
Pavel Březina -
Petr Pisar -
Vitaly Zaitsev -
Vít Ondruch