8:48 a.m.
= Proposed Self Contained Change: Authselect: new tool to replace authconfig =
https://fedoraproject.org/wiki/Changes/Authselect
Change owner(s):
* Pavel Březina <pbrezina(a)redhat.com>
Authselect is a tool to select system authentication and identity
sources from a list of supported profiles.
It is designed to be a replacement for authconfig but it takes a
different approach to configure the system. Instead of letting the
administrator build the pam stack with a tool (which may potentially
end up with a broken configuration), it would ship several tested
stacks (profiles) that solve a use-case and are well tested and
supported. At the same time, some obsolete features of authconfig
would not be supported by authselect.
This tool aims to be first shipped along and later deprecate and later
replace authconfig in a future Fedora release.
== Detailed Description ==
Authselect will allow the administrator to choose one of the supported
profiles. A profile provides description of how the resulting pam and
nsswitch configuration looks like. The tool will be packaged with a
default profile set that will be fully supported. If an administrator
has different needs they can create a custom profile and make it
accessible by authselect by dropping it in the tool directory.
The authentication and identity configuration is hardcoded within the
profile. However each profile is also allowed to contain some
conditional modules that can be either enabled or disabled to allow
the administrator to enable some optional behaviour such as password
policy or ecryptfs support.
Authselect will not configure daemons that provide the selected
identity and authentication services such as SSSD or winbind, it will
only configure pam and nsswitch. Daemons must be configured manually
or through other system tools like realmd or ipa-client-install.
The default profile set will contain the following profiles:
Local users + SSSD -- local users and remote users are handled by sssd
Local users + SSSD + Fingerprint -- same as above but also pam_fprintd
is enabled
Local users + winbind -- local users are handled by files and remote
users by winbind
Local users + winbind + Fingerprint -- same as above but also
pam_fprintd is enabled
We do not want to support nss-pam-ldapd and pam_krb5 in default
profiles since their use-cases are completely or almost completely
covered by SSSD. SSSD can be used as a complete replacement for
pam_krb5 and there are only few old and rarely used maps for LDAP that
remain unimplemented within SSSD such as hosts and aliases. These maps
will be added in a future SSSD version.
== Scope ==
* Proposal owners: implement the change
* Other developers: N/A (not a System Wide Change)
* Release engineering: [1] (a check of an impact with Release
Engineering is needed)
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
[1] https://pagure.io/releng/issue/6907
Jaroslav
8:55 a.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On 18/07/17 14:48, Jaroslav Reznik wrote:
The default profile set will contain the following profiles:
Local users + SSSD -- local users and remote users are handled by sssd
Local users + SSSD + Fingerprint -- same as above but also pam_fprintd
is enabled
Local users + winbind -- local users are handled by files and remote
users by winbind
Local users + winbind + Fingerprint -- same as above but also
pam_fprintd is enabled
No "local only" profiles for people that don't need sssd?
What is the effect of this on configurations that haven't been using
sssd at all? Is everything going to suddenly start blocking/timing out
on being unable to talk to it?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:12 a.m.
On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom(a)compton.nu> wrote:
On 18/07/17 14:48, Jaroslav Reznik wrote:
> The default profile set will contain the following profiles:
>
> Local users + SSSD -- local users and remote users are handled by sssd
> Local users + SSSD + Fingerprint -- same as above but also pam_fprintd
> is enabled
> Local users + winbind -- local users are handled by files and remote
> users by winbind
> Local users + winbind + Fingerprint -- same as above but also
> pam_fprintd is enabled
No "local only" profiles for people that don't need sssd?
What is the effect of this on configurations that haven't been using
sssd at all? Is everything going to suddenly start blocking/timing out
on being unable to talk to it?
Starting with F26, the default configuration is for all setups to be using
SSSD. See https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
This is actually advantageous, since the previous behavior was that all
access to local users previously had to hit the disk (unless nscd was
manually configured). If SSSD isn't responding, nsswitch will fail back to
the old behavior fairly quickly.
Also, the authselect stuff *puts* the configuration into place. If you
don't want your configuration to change, don't call authselect. (Even if
you do, it will detect that you have a manual configuration and won't
change anything unless you pass a "force" option).
9:16 a.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On 18/07/17 15:12, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom(a)compton.nu
<mailto:tom@compton.nu>> wrote:
On 18/07/17 14:48, Jaroslav Reznik wrote:
> The default profile set will contain the following profiles:
>
> Local users + SSSD -- local users and remote users are handled by
sssd
> Local users + SSSD + Fingerprint -- same as above but also
pam_fprintd
> is enabled
> Local users + winbind -- local users are handled by files and remote
> users by winbind
> Local users + winbind + Fingerprint -- same as above but also
> pam_fprintd is enabled
No "local only" profiles for people that don't need sssd?
What is the effect of this on configurations that haven't been using
sssd at all? Is everything going to suddenly start blocking/timing out
on being unable to talk to it?
Starting with F26, the default configuration is for all setups to be
using SSSD. See
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
Well none of my newly upgraded F26 machines appear to be running it ;-)
This is actually advantageous, since the previous behavior was that
all
access to local users previously had to hit the disk (unless nscd was
manually configured). If SSSD isn't responding, nsswitch will fail back
to the old behavior fairly quickly.
I normally disabled nscd as well because the caching was just way too
annoying...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:26 a.m.
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom(a)compton.nu> wrote:
On 18/07/17 15:12, Stephen Gallagher wrote:
>
>
> On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom(a)compton.nu
> <mailto:tom@compton.nu>> wrote:
>
> On 18/07/17 14:48, Jaroslav Reznik wrote:
>
> > The default profile set will contain the following profiles:
> >
> > Local users + SSSD -- local users and remote users are handled by
> sssd
> > Local users + SSSD + Fingerprint -- same as above but also
> pam_fprintd
> > is enabled
> > Local users + winbind -- local users are handled by files and
remote
> > users by winbind
> > Local users + winbind + Fingerprint -- same as above but also
> > pam_fprintd is enabled
>
> No "local only" profiles for people that don't need sssd?
>
> What is the effect of this on configurations that haven't been using
> sssd at all? Is everything going to suddenly start blocking/timing
out
> on being unable to talk to it?
>
>
>
> Starting with F26, the default configuration is for all setups to be
> using SSSD. See
> https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
Well none of my newly upgraded F26 machines appear to be running it ;-)
I said "default". So for fresh installs this is the case.
> This is actually advantageous, since the previous behavior was
that all
> access to local users previously had to hit the disk (unless nscd was
> manually configured). If SSSD isn't responding, nsswitch will fail back
> to the old behavior fairly quickly.
I normally disabled nscd as well because the caching was just way too
annoying...
SSSD's caching is a lot more reliable for local users than nscd, as it
monitors all of the relevant files with inotify and will immediately flush
its cache anytime a change occurs to those files. It also does a full cache
when this happens, rather than on-demand, so the only time there should
ever be a lag here is on a request the instant between when a change is
made on the disk and SSSD reloads it (during this time, SSSD just doesn't
cache at all and passes the request on to nss_files.so to answer straight
from the disk).
Also, the SSSD cache in use isn't strictly dependent on the SSSD daemon
running; if SSSD was to crash and be in the middle of restarting, the
memory-mapped fast cache will continue on independently. So in theory,
there really shouldn't be any downside to this change (and I encourage you
to tweak your upgraded boxes to use the new configuration).
2:30 p.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom(a)compton.nu
<mailto:tom@compton.nu>> wrote:
Well none of my newly upgraded F26 machines appear to be running it ;-)
I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually
editing nsswitch.conf however, so running "authconfig --updateall" to
rebuild the configuration would have disabled it.
> This is actually advantageous, since the previous behavior
was
that all
> access to local users previously had to hit the disk (unless nscd was
> manually configured). If SSSD isn't responding, nsswitch will
fail back
> to the old behavior fairly quickly.
I normally disabled nscd as well because the caching was just way too
annoying...
SSSD's caching is a lot more reliable for local users than nscd, as it
monitors all of the relevant files with inotify and will immediately
flush its cache anytime a change occurs to those files. It also does a
full cache when this happens, rather than on-demand, so the only time
there should ever be a lag here is on a request the instant between when
a change is made on the disk and SSSD reloads it (during this time, SSSD
just doesn't cache at all and passes the request on to nss_files.so to
answer straight from the disk).
Also, the SSSD cache in use isn't strictly dependent on the SSSD daemon
running; if SSSD was to crash and be in the middle of restarting, the
memory-mapped fast cache will continue on independently. So in theory,
there really shouldn't be any downside to this change (and I encourage
you to tweak your upgraded boxes to use the new configuration).
I never really bothered with sssd because I understood it's purpose to
be caching network users for disconnected use and I as I don't use
network users anywhere, let alone on machines that need to continue
working when disconnected, it didn't seem worth learning about.
I have now tried enabling it on another machine and we'll see how that
goes...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
2:43 p.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On Tue, Jul 18, 2017 at 08:30:57PM +0100, Tom Hughes wrote:
On 18/07/17 15:26, Stephen Gallagher wrote:
> On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom(a)compton.nu
> <mailto:tom@compton.nu>> wrote:
>
> Well none of my newly upgraded F26 machines appear to be running it ;-)
>
> I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually editing
The default nsswitch.conf is owned by libc, which, if I remember the
discussions with Florian earlier is also not deemed ideal.
nsswitch.conf however, so running "authconfig --updateall"
to rebuild the
configuration would have disabled it.
I would say this is a bug in authconfig (and by the way, this is one of
the reasons curated and tested NSS/PAM stacks would be more reliable than
generating the stack based on user input where more or less anything goes..)
2:51 p.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On 18/07/17 20:43, Jakub Hrozek wrote:
On Tue, Jul 18, 2017 at 08:30:57PM +0100, Tom Hughes wrote:
> On 18/07/17 15:26, Stephen Gallagher wrote:
>
>> On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom(a)compton.nu
>> <mailto:tom@compton.nu>> wrote:
>>
>> Well none of my newly upgraded F26 machines appear to be running it ;-)
>>
>> I said "default". So for fresh installs this is the case.
>
> Yes my laptop, which had been installed with F26, was indeed running it.
>
> It appears that whatever enabled it (anaconda?) did so by manually editing
The default nsswitch.conf is owned by libc, which, if I remember the
discussions with Florian earlier is also not deemed ideal.
> nsswitch.conf however, so running "authconfig --updateall" to rebuild the
> configuration would have disabled it.
I would say this is a bug in authconfig (and by the way, this is one of
the reasons curated and tested NSS/PAM stacks would be more reliable than
generating the stack based on user input where more or less anything goes..)
Well I'm just going by USESSSD=no in /etc/sysconfig/authconfig...
Interestingly something had changed that file in other ways - the
default one installed by authconfig doesn't even have shadow enabled but
my laptop had it enabled so anaconda had presumably run authconfig
--enableshadow or something.
I agree that I'm no fan of authconfig but I've been in the habit of
running --updateall when I get rpmnew files for nsswitch or the pam
files that it generates which is fairly common on a upgrade to a new
Fedora version.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
3:01 a.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On Tue, 2017-07-18 at 20:30 +0100, Tom Hughes wrote:
On 18/07/17 15:26, Stephen Gallagher wrote:
> On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom(a)compton.nu
> <mailto:tom@compton.nu>> wrote:
>
> Well none of my newly upgraded F26 machines appear to be
> running it ;-)
>
> I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running
it.
It appears that whatever enabled it (anaconda?) did so by manually
editing nsswitch.conf however, so running "authconfig --updateall"
to
rebuild the configuration would have disabled it.
That would be most probably authconfig bug, could you please report it,
ideally with steps to reproduce?
The contents of the /etc/nsswitch.conf should have priority over
/etc/sysconfig/authconfig. I already have RFE for authconfig to
basically keep /etc/sysconfig/authconfig only as a hint and diminish
its use. Unfortunately I have not had time to work on that yet.
--
Tomáš Mráz
Red Hat
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
* Google and NSA associates, this message is none of your business.
* Please leave it alone, and consider whether your actions are
* authorized by the contract with Red Hat, or by the US constitution.
* If you feel you're being encouraged to disregard the limits built
* into them, remember Edward Snowden and Wikileaks.
3:27 a.m.
New subject: F27 Self Contained Change: Authselect: new tool to replace
authconfig
On 19/07/17 09:01, Tomas Mraz wrote:
On Tue, 2017-07-18 at 20:30 +0100, Tom Hughes wrote:
> On 18/07/17 15:26, Stephen Gallagher wrote:
>
>> On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom(a)compton.nu
>> <mailto:tom@compton.nu>> wrote:
>>
>> Well none of my newly upgraded F26 machines appear to be
>> running it ;-)
>>
>> I said "default". So for fresh installs this is the case.
>
> Yes my laptop, which had been installed with F26, was indeed running
> it.
>
> It appears that whatever enabled it (anaconda?) did so by manually
> editing nsswitch.conf however, so running "authconfig --updateall"
> to
> rebuild the configuration would have disabled it.
That would be most probably authconfig bug, could you please report it,
ideally with steps to reproduce?
The contents of the /etc/nsswitch.conf should have priority over
/etc/sysconfig/authconfig. I already have RFE for authconfig to
basically keep /etc/sysconfig/authconfig only as a hint and diminish
its use. Unfortunately I have not had time to work on that yet.
Oh in that case there might not be a bug. I didn't actually try it but I
assumed that authconfig would rebuild the rules based on it's
configuration rather then preserving what is already there which would
seem to defeat the object of it?
Hmm actually having tried it my assumption appears to have been correct
as sss has been removed from nsswitch.conf.
I'll file a bug...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
11:36 a.m.
>>>> "JR" == Jaroslav Reznik
<jreznik(a)redhat.com> writes:
JR> At the same time, some obsolete features of authconfig
JR> would not be supported by authselect.
I have a couple of concerns about this.
First, this seems to impact anaconda/kickstart since the "authconfig"
line basically _is_ an authconfig command line.
Secondly, what would replace a call like:
authconfig --enableldap --ldapbase=dc=whatever
--ldapserver=ldaps://ldap1.whatever,ldaps://ldap2.whatever,ldaps://ldap3.whatever
--enablekrb5 --krb5realm=WHATEVER
--krb5kdc=kerberos1.whatever,kerberos2.whatever
--krb5adminserver=kerberos1.whatever --useshadow
Is setting those ldap and kerberos servers in the proper files now
obsolete functionality? If that all needs to be configured manually
(since there's no IPA or AD server involved here) then will anaconda
grow support for that or will existing authconfig lines just not work?
Disclaimer: Fortunately for me I've recently switched to doing that kind
of setup via ansible instead of using the authconfig line in kickstart.
So technically I don't care any more, but I can imagine that there are
still a number of people who do.
JR> == Scope ==
JR> * Proposal owners: implement the change
JR> * Other developers: N/A (not a System Wide Change)
So I do think this is a bit wider in scope than the authconfig command
going away, unless anaconda has stopped implementing the 'authconfig'
directive by running authconfig.
- J<
12:43 p.m.
On Tue, Jul 18, 2017 at 12:38 PM Jason L Tibbitts III <tibbs(a)math.uh.edu>
wrote:
>>>>> "JR" == Jaroslav Reznik
<jreznik(a)redhat.com> writes:
JR> At the same time, some obsolete features of authconfig
JR> would not be supported by authselect.
I have a couple of concerns about this.
First, this seems to impact anaconda/kickstart since the "authconfig"
line basically _is_ an authconfig command line.
Secondly, what would replace a call like:
authconfig --enableldap --ldapbase=dc=whatever
--ldapserver=ldaps://ldap1.whatever,ldaps://ldap2.whatever,ldaps://ldap3.whatever
--enablekrb5 --krb5realm=WHATEVER
--krb5kdc=kerberos1.whatever,kerberos2.whatever
--krb5adminserver=kerberos1.whatever --useshadow
Is setting those ldap and kerberos servers in the proper files now
obsolete functionality? If that all needs to be configured manually
(since there's no IPA or AD server involved here) then will anaconda
grow support for that or will existing authconfig lines just not work?
Disclaimer: Fortunately for me I've recently switched to doing that kind
of setup via ansible instead of using the authconfig line in kickstart.
So technically I don't care any more, but I can imagine that there are
still a number of people who do.
JR> == Scope ==
JR> * Proposal owners: implement the change
JR> * Other developers: N/A (not a System Wide Change)
So I do think this is a bit wider in scope than the authconfig command
going away, unless anaconda has stopped implementing the 'authconfig'
directive by running authconfig.
Short version: this isn't going away in F27 and the Change title is
misleading. Authconfig isn't going away at least until F28 (once authselect
has been tested in the real world). The "auth" line in Anaconda will
continue to be handled by authconfig in F27 (which is why this is a
self-contained change rather than a system-wide one).
It will not actually *replace* authconfig until it can satisfy the
requirements of the kickstarts as well (and not any earlier than F28).
2534
days inactive
2535
days old
11 comments
6 participants
participants (6)
-
Jakub Hrozek -
Jaroslav Reznik -
Jason L Tibbitts III -
Stephen Gallagher -
Tom Hughes -
Tomas Mraz