F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Ben Cotton]

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(a)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.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Pavel Březina]

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.

[Petr Pisar]

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

[Pavel Březina]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Petr Pisar]

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

[Pavel Březina]

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

[Petr Pisar]

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

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Michael Catanzaro]

On Wed, Jan 19 2022 at 12:56:26 PM +0100, Vitaly Zaitsev via devel 
<devel(a)lists.fedoraproject.org&gt; 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.

[Fabio Valentini]

On Tue, Jan 18, 2022 at 6:34 PM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)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. 
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

[Neal Gompa]

On Wed, Jan 19, 2022 at 10:19 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Tue, Jan 18, 2022 at 6:34 PM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)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.
>
>  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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Colin Walters]

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.

[Chris Murphy]

On Wed, Jan 19, 2022 at 3:04 AM Petr Pisar <ppisar(a)redhat.com&gt; 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.

-- 
Chris Murphy

[Chris Murphy]

On Wed, Jan 19, 2022 at 4:56 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; 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.


-- 
Chris Murphy

[Chris Adams]

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.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Chris Murphy]

On Wed, Jan 19, 2022 at 11:48 AM Chris Adams <linux(a)cmadams.net&gt; 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?



-- 
Chris Murphy

[Chris Adams]

Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; 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.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Chris Murphy]

On Wed, Jan 19, 2022 at 6:14 PM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; 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

[Panu Matilainen]

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 -

[Pavel Březina]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Pavel Březina]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Petr Pisar]

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

[Vít Ondruch]

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(a)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.
>
>
>

[Demi Marie Obenour]

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”.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Pavel Březina]

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(a)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.
> >
> >
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Vít Ondruch]

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

[Chris Murphy]

On Wed, Jan 19, 2022 at 11:14 PM Panu Matilainen <pmatilai(a)redhat.com&gt; 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.

-- 
Chris Murphy

[Neal Gompa]

On Thu, Jan 20, 2022 at 8:14 AM Demi Marie Obenour
<demiobenour(a)gmail.com&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Pavel Březina]

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.

[Vít Ondruch]

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

[Lennart Poettering]

On Di, 18.01.22 12:32, Ben Cotton (bcotton(a)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