9:35 a.m.
My current Fedora 26 default nsswitch.conf contains these lines:
passwd: sss files systemd
shadow: files sss
group: sss files systemd
Not sure which package created this configuration, but:
* Where is the consistency?
* Where is the Fedora Change page that talks about these modifications
of fairly critical systemwide configuration file?
* From which time systemd started to manage user accounts of the
machine, again where is the Fedora Change page for such change?
Regards,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
10:15 a.m.
On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
My current Fedora 26 default nsswitch.conf contains these lines:
passwd: sss files systemd
shadow: files sss
group: sss files systemd
Not sure which package created this configuration, but:
* Where is the consistency?
* Where is the Fedora Change page that talks about these modifications
of fairly critical systemwide configuration file?
* From which time systemd started to manage user accounts of the
machine, again where is the Fedora Change page for such change?
Is this what you are looking for?
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
That page says:
"""
This change proposes leveraging a new "files" provider SSSD will ship in
the next version in order to resolve also users from the local files.
That way, the "sss" NSS module can be configured before the files module
in nsswitch.conf and the system could leverage sss_nss caching for both
local and remote users.
"""
10:22 a.m.
On Mon, 2017-05-15 at 17:15 +0200, Jakub Hrozek wrote:
On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
> My current Fedora 26 default nsswitch.conf contains these lines:
>
> passwd: sss files systemd
> shadow: files sss
> group: sss files systemd
>
> Not sure which package created this configuration, but:
>
> * Where is the consistency?
> * Where is the Fedora Change page that talks about these
> modifications
> of fairly critical systemwide configuration file?
> * From which time systemd started to manage user accounts of the
> machine, again where is the Fedora Change page for such change?
Is this what you are looking for?
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
That page says:
"""
This change proposes leveraging a new "files" provider SSSD will ship
in
the next version in order to resolve also users from the local files.
That way, the "sss" NSS module can be configured before the files
module
in nsswitch.conf and the system could leverage sss_nss caching for
both
local and remote users.
"""
The questions still hold for the consistency between passwd and shadow
and also for the systemd module present.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
10:30 a.m.
On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
On Mon, 2017-05-15 at 17:15 +0200, Jakub Hrozek wrote:
> On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
> > My current Fedora 26 default nsswitch.conf contains these lines:
> >
> > passwd: sss files systemd
> > shadow: files sss
> > group: sss files systemd
> >
> > Not sure which package created this configuration, but:
> >
> > * Where is the consistency?
> > * Where is the Fedora Change page that talks about these
> > modifications
> > of fairly critical systemwide configuration file?
> > * From which time systemd started to manage user accounts of the
> > machine, again where is the Fedora Change page for such change?
>
> Is this what you are looking for?
> https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
>
> That page says:
> """
> This change proposes leveraging a new "files" provider SSSD will ship
> in
> the next version in order to resolve also users from the local files.
> That way, the "sss" NSS module can be configured before the files
> module
> in nsswitch.conf and the system could leverage sss_nss caching for
> both
> local and remote users.
> """
The questions still hold for the consistency between passwd and shadow
and also for the systemd module present.
Since sssd doesn't handle the password map, being consistent there in
the ordering sense (sss before files) wouldn't make much sense, because
the nss module functions for the shadow map are not even implemented in
nss_sss. We could even omit the sss module from that map altogether.
10:37 a.m.
On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
> On Mon, 2017-05-15 at 17:15 +0200, Jakub Hrozek wrote:
>> On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
>>> My current Fedora 26 default nsswitch.conf contains these lines:
>>>
>>> passwd: sss files systemd
>>> shadow: files sss
>>> group: sss files systemd
>>>
>>> Not sure which package created this configuration, but:
>>>
>>> * Where is the consistency?
>>> * Where is the Fedora Change page that talks about these
>>> modifications
>>> of fairly critical systemwide configuration file?
>>> * From which time systemd started to manage user accounts of the
>>> machine, again where is the Fedora Change page for such change?
>> Is this what you are looking for?
>> https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
>>
>> That page says:
>> """
>> This change proposes leveraging a new "files" provider SSSD will ship
>> in
>> the next version in order to resolve also users from the local files.
>> That way, the "sss" NSS module can be configured before the files
>> module
>> in nsswitch.conf and the system could leverage sss_nss caching for
>> both
>> local and remote users.
>> """
> The questions still hold for the consistency between passwd and shadow
> and also for the systemd module present.
Since sssd doesn't handle the password map, being consistent there in
the ordering sense (sss before files) wouldn't make much sense, because
the nss module functions for the shadow map are not even implemented in
nss_sss. We could even omit the sss module from that map altogether.
The only historical reason it is there is because authconfig didn't
differentiate them; it made all changes to shadow identically to passwd.
I don't know if that's still the case, but I'm pretty sure it was when
we first added SSSD support to authconfig. It's not harmful, since the
SSSD client just immediately returns with an appropriate NSS error code
if it's asked for any shadow map function.
6:04 a.m.
On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
> On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
>> The questions still hold for the consistency between passwd
and shadow
>> and also for the systemd module present.
> Since sssd doesn't handle the password map, being consistent there in
> the ordering sense (sss before files) wouldn't make much sense, because
> the nss module functions for the shadow map are not even implemented in
> nss_sss. We could even omit the sss module from that map altogether.
The only historical reason it is there is because authconfig didn't
differentiate them; it made all changes to shadow identically to passwd.
I don't know if that's still the case, but I'm pretty sure it was when
we first added SSSD support to authconfig. It's not harmful, since the
SSSD client just immediately returns with an appropriate NSS error code
if it's asked for any shadow map function.
Stephen, activating *any* service you don't need and using it for work
that cannot possibly succeed is potentially harmful to performance and
stability of the system. It may not be notably destructive or very
expensive, and in this case would normally be harmless. But it helps
create another possible point of failure in a system critical
function. The underlying problem there would seem to be one of
authconfig activating features pointlessly in /etc/nsswitch.cnf, not
of the sssd software itself.
Tomasz's tone has been consistently rude. In this cae, he did seem to
have a point. sssd is, in this case, re-inventing some of the wheels
of nscd. He could have said so much more nicely. And Tomasz? sssd was
apparently *designed* with philosophy much like that of systemd. It's
supposed to be a unified set of tools replacing a lot of already
existing functionality, and adding some useful features.
Unfortunately, its unifying multiple service and multiple host
authentication doesn't seem to have become popular: Most folks I've
seen using Kerberos and LDAP, which sssd was designed to integrate,
have simply ignored sssd and gone straight to the more multi-platform
supported Samba. And authconfig has never really evolved to provide
more robust, consistent activation of localized configurations,
settings which are overwritten without notification when authconfig is
run. Authconfig is a fairly dangerous tool if you need to customize
local configurations, including its inability to remove obsolete
domains or to support multiple domains in the /etc/krb5.cnf
configurations, and its consistent overwriting of localized
configurations for password expiration in /etc/nsswitch.cnf.
The resulting potential for confusion would thus not really seem to be
an sssd issue. It would seem to be an authconfig issue. Since shadow,
and password, are distinct settings with distinct sets of attributes
driven by sssd activation, perhaps that would be a good place to spend
some configuration management time, rather than relying on sssd to
reply sensibly to a request that it will never be able to fulfill.
7:20 a.m.
On 05/16/2017 07:04 AM, Nico Kadel-Garcia wrote:
On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
>
>
> On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
>> On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
>>> The questions still hold for the consistency between passwd and shadow
>>> and also for the systemd module present.
>> Since sssd doesn't handle the password map, being consistent there in
>> the ordering sense (sss before files) wouldn't make much sense, because
>> the nss module functions for the shadow map are not even implemented in
>> nss_sss. We could even omit the sss module from that map altogether.
>
> The only historical reason it is there is because authconfig didn't
> differentiate them; it made all changes to shadow identically to passwd.
> I don't know if that's still the case, but I'm pretty sure it was when
> we first added SSSD support to authconfig. It's not harmful, since the
> SSSD client just immediately returns with an appropriate NSS error code
> if it's asked for any shadow map function.
Stephen, activating *any* service you don't need and using it for work
that cannot possibly succeed is potentially harmful to performance and
stability of the system. It may not be notably destructive or very
expensive, and in this case would normally be harmless. But it helps
create another possible point of failure in a system critical
function. The underlying problem there would seem to be one of
authconfig activating features pointlessly in /etc/nsswitch.cnf, not
of the sssd software itself.
To clarify, having this in nsswitch.conf does *NOT* activate the SSSD service on
the system (in and of itself). And the system around it is carefully designed so
that if SSSD is not running or accessible, it immediately returns control to
glibc which then goes through the classic nss_files path.
Tomasz's tone has been consistently rude. In this cae, he did
seem to
have a point. sssd is, in this case, re-inventing some of the wheels
of nscd. He could have said so much more nicely.
Yes, SSSD does reinvent nscd, because nscd did not meet the needs of a great
many people. Its caching methodology is too simplistic (it uses the exact same
approach to deal with all possible name-service maps, which means that its
decision process has to be least-common-denominator). We very much set out to
replace nscd because it didn't work well and the upstream at the time was
immovable on many of these points. While this may no longer be true, that ship
has sailed.
And Tomasz? sssd was
apparently *designed* with philosophy much like that of systemd.
It's
supposed to be a unified set of tools replacing a lot of already
existing functionality, and adding some useful features.
Unfortunately, its unifying multiple service and multiple host
authentication doesn't seem to have become popular: Most folks I've
seen using Kerberos and LDAP, which sssd was designed to integrate,
have simply ignored sssd and gone straight to the more multi-platform
supported Samba.
Just a reminder: anecdotes do not equal rigorous data :)
SSSD is in extremely wide use around the world and is the preferred
LDAP/Kerberos client option in all of the major Linux distributions.
And authconfig has never really evolved to provide
more robust, consistent activation of localized configurations,
settings which are overwritten without notification when authconfig is
run. Authconfig is a fairly dangerous tool if you need to customize
local configurations, including its inability to remove obsolete
domains or to support multiple domains in the /etc/krb5.cnf
configurations, and its consistent overwriting of localized
configurations for password expiration in /etc/nsswitch.cnf.
Yes, authconfig is *not* a good tool for managing centralized authentication
services and its upstream has been unable to keep up with the changing needs of
the system. That's why work is under way to replace it with more robust tools. I
think Jakub can talk more about that.
The resulting potential for confusion would thus not really seem to
be
an sssd issue. It would seem to be an authconfig issue. Since shadow,
and password, are distinct settings with distinct sets of attributes
driven by sssd activation, perhaps that would be a good place to spend
some configuration management time, rather than relying on sssd to
reply sensibly to a request that it will never be able to fulfill.
I'm not sure what exactly you're saying here other than "don't include
'sss' in
the 'shadow' line, to which I completely agree.
8:18 a.m.
On 16/05/17 14:20, Stephen Gallagher wrote:
> apparently *designed* with philosophy much like that of systemd.
It's
> supposed to be a unified set of tools replacing a lot of already
> existing functionality, and adding some useful features.
> Unfortunately, its unifying multiple service and multiple host
> authentication doesn't seem to have become popular: Most folks I've
> seen using Kerberos and LDAP, which sssd was designed to integrate,
> have simply ignored sssd and gone straight to the more multi-platform
> supported Samba.
Just a reminder: anecdotes do not equal rigorous data :)
SSSD is in extremely wide use around the world and is the preferred
LDAP/Kerberos client option in all of the major Linux distributions.
Just to backup this a bit further. Those integrating with AD, will also
most likely take advantage of LDAP/Kerberos as well. Kerberos is the
only authentication scheme I know of which also enables a truly working
SSO solution, which tackles the full stack from localhost login to
various network services.
In addition, SSSD provides a possibility to cache authentication details
so you can have laptops fully integrated with an LDAP/Kerberos
environment, provide a centralized password policy and yet be able to do
local authentication if the LDAP/Kerberos backends are unavailable.
And then there is the support for OTP based authentication, which it
also seems to be handled quite well regardless if you are online or not.
From my perspective, SSSD solves more issues than what nscd is capable
of, at least to how I've learnt to know nscd. And my experience with
computers enrolled into a FreeIPA managed network have overall just been
a wonderful and easy experience.
--
kind regards,
David Sommerseth
5:17 a.m.
On Tue, May 16, 2017 at 08:20:49AM -0400, Stephen Gallagher wrote:
On 05/16/2017 07:04 AM, Nico Kadel-Garcia wrote:
> On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
>>
>>
>> On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
>>> On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
>
>>>> The questions still hold for the consistency between passwd and shadow
>>>> and also for the systemd module present.
>>> Since sssd doesn't handle the password map, being consistent there in
>>> the ordering sense (sss before files) wouldn't make much sense, because
>>> the nss module functions for the shadow map are not even implemented in
>>> nss_sss. We could even omit the sss module from that map altogether.
>>
>> The only historical reason it is there is because authconfig didn't
>> differentiate them; it made all changes to shadow identically to passwd.
>> I don't know if that's still the case, but I'm pretty sure it was
when
>> we first added SSSD support to authconfig. It's not harmful, since the
>> SSSD client just immediately returns with an appropriate NSS error code
>> if it's asked for any shadow map function.
>
> Stephen, activating *any* service you don't need and using it for work
> that cannot possibly succeed is potentially harmful to performance and
> stability of the system. It may not be notably destructive or very
> expensive, and in this case would normally be harmless. But it helps
> create another possible point of failure in a system critical
> function. The underlying problem there would seem to be one of
> authconfig activating features pointlessly in /etc/nsswitch.cnf, not
> of the sssd software itself.
>
To clarify, having this in nsswitch.conf does *NOT* activate the SSSD service on
the system (in and of itself). And the system around it is carefully designed so
that if SSSD is not running or accessible, it immediately returns control to
glibc which then goes through the classic nss_files path.
> Tomasz's tone has been consistently rude. In this cae, he did seem to
> have a point. sssd is, in this case, re-inventing some of the wheels
> of nscd. He could have said so much more nicely.
Yes, SSSD does reinvent nscd, because nscd did not meet the needs of a great
many people. Its caching methodology is too simplistic (it uses the exact same
approach to deal with all possible name-service maps, which means that its
decision process has to be least-common-denominator). We very much set out to
replace nscd because it didn't work well and the upstream at the time was
immovable on many of these points. While this may no longer be true, that ship
has sailed.
And Tomasz? sssd was
> apparently *designed* with philosophy much like that of systemd. It's
> supposed to be a unified set of tools replacing a lot of already
> existing functionality, and adding some useful features.
> Unfortunately, its unifying multiple service and multiple host
> authentication doesn't seem to have become popular: Most folks I've
> seen using Kerberos and LDAP, which sssd was designed to integrate,
> have simply ignored sssd and gone straight to the more multi-platform
> supported Samba.
Just a reminder: anecdotes do not equal rigorous data :)
SSSD is in extremely wide use around the world and is the preferred
LDAP/Kerberos client option in all of the major Linux distributions.
And authconfig has never really evolved to provide
> more robust, consistent activation of localized configurations,
> settings which are overwritten without notification when authconfig is
> run. Authconfig is a fairly dangerous tool if you need to customize
> local configurations, including its inability to remove obsolete
> domains or to support multiple domains in the /etc/krb5.cnf
> configurations, and its consistent overwriting of localized
> configurations for password expiration in /etc/nsswitch.cnf.
>
Yes, authconfig is *not* a good tool for managing centralized authentication
services and its upstream has been unable to keep up with the changing needs of
the system. That's why work is under way to replace it with more robust tools. I
think Jakub can talk more about that.
Yeah, there is a project in a fairly early stage (so, we don't even have
a Fedora Change page yet, but we need to file one for F-27) to replace
authconfig.
The basic idea is that instead of trying to generate a nss/pam stack
based on what the admin called authconfig with (and hope for the best)
the tool would include a curated and well tested set of stacks to support
the common configuration types.
8:24 a.m.
On Thu, May 18, 2017 at 6:17 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
On Tue, May 16, 2017 at 08:20:49AM -0400, Stephen Gallagher wrote:
> Yes, authconfig is *not* a good tool for managing centralized
authentication
> services and its upstream has been unable to keep up with the changing needs of
> the system. That's why work is under way to replace it with more robust tools. I
> think Jakub can talk more about that.
Yeah, there is a project in a fairly early stage (so, we don't even have
a Fedora Change page yet, but we need to file one for F-27) to replace
authconfig.
The basic idea is that instead of trying to generate a nss/pam stack
based on what the admin called authconfig with (and hope for the best)
the tool would include a curated and well tested set of stacks to support
the common configuration types.
Cool. I'd love to see, for example "sss" not even listed in the
equivalent of /etc/nsswitch.conf for systems that haven't specifically
enabled any service that actually uses LDAP. Currently, the stack
relies on authconfig turning *off* the sssd daemon. I'd prefer to see
it listed there only if there's actually anything configured to use
it.
8:33 a.m.
On 05/18/2017 09:24 AM, Nico Kadel-Garcia wrote:
On Thu, May 18, 2017 at 6:17 AM, Jakub Hrozek
<jhrozek(a)redhat.com> wrote:
> On Tue, May 16, 2017 at 08:20:49AM -0400, Stephen Gallagher wrote:
>> Yes, authconfig is *not* a good tool for managing centralized authentication
>> services and its upstream has been unable to keep up with the changing needs of
>> the system. That's why work is under way to replace it with more robust
tools. I
>> think Jakub can talk more about that.
>
> Yeah, there is a project in a fairly early stage (so, we don't even have
> a Fedora Change page yet, but we need to file one for F-27) to replace
> authconfig.
>
> The basic idea is that instead of trying to generate a nss/pam stack
> based on what the admin called authconfig with (and hope for the best)
> the tool would include a curated and well tested set of stacks to support
> the common configuration types.
Cool. I'd love to see, for example "sss" not even listed in the
equivalent of /etc/nsswitch.conf for systems that haven't specifically
enabled any service that actually uses LDAP. Currently, the stack
relies on authconfig turning *off* the sssd daemon. I'd prefer to see
it listed there only if there's actually anything configured to use
it.
That's a perfectly reasonable request. I think it's fair to say that if no
central user management is required, it's reasonable that our default would be
to drop 'sss' from nsswitch.conf and turn nscd back on (to avoid I/O lookups on
the local files).
Though if we do that, I'd still like to see some daemon *somewhere* monitoring
the files and flushing the nscd cache if they are modified, because an outdated
nscd cache is one of the hardest things for an end-user to debug because there's
really nowhere that can log it.
8:41 a.m.
On 18 May 2017 at 14:33, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 05/18/2017 09:24 AM, Nico Kadel-Garcia wrote:
> On Thu, May 18, 2017 at 6:17 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
>> On Tue, May 16, 2017 at 08:20:49AM -0400, Stephen Gallagher wrote:
>
>>> Yes, authconfig is *not* a good tool for managing centralized authentication
>>> services and its upstream has been unable to keep up with the changing needs
of
>>> the system. That's why work is under way to replace it with more robust
tools. I
>>> think Jakub can talk more about that.
>>
>> Yeah, there is a project in a fairly early stage (so, we don't even have
>> a Fedora Change page yet, but we need to file one for F-27) to replace
>> authconfig.
>>
>> The basic idea is that instead of trying to generate a nss/pam stack
>> based on what the admin called authconfig with (and hope for the best)
>> the tool would include a curated and well tested set of stacks to support
>> the common configuration types.
>
> Cool. I'd love to see, for example "sss" not even listed in the
> equivalent of /etc/nsswitch.conf for systems that haven't specifically
> enabled any service that actually uses LDAP. Currently, the stack
> relies on authconfig turning *off* the sssd daemon. I'd prefer to see
> it listed there only if there's actually anything configured to use
> it.
That's a perfectly reasonable request. I think it's fair to say that if no
central user management is required, it's reasonable that our default would be
to drop 'sss' from nsswitch.conf and turn nscd back on (to avoid I/O lookups on
the local files).
Though if we do that, I'd still like to see some daemon *somewhere* monitoring
the files and flushing the nscd cache if they are modified, because an outdated
nscd cache is one of the hardest things for an end-user to debug because there's
really nowhere that can log it.
The lack of logging of nscd, if anything, I'd argue is a reason for
the various Working Groups for the Products to have sssd enabled (with
sss at the start of nsswitch) and running by default, and with systemd
always restarting it.
9:04 a.m.
On 05/18/2017 09:41 AM, James Hogarth wrote:
On 18 May 2017 at 14:33, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> That's a perfectly reasonable request. I think it's fair to say that if no
> central user management is required, it's reasonable that our default would be
> to drop 'sss' from nsswitch.conf and turn nscd back on (to avoid I/O lookups
on
> the local files).
>
> Though if we do that, I'd still like to see some daemon *somewhere* monitoring
> the files and flushing the nscd cache if they are modified, because an outdated
> nscd cache is one of the hardest things for an end-user to debug because there's
> really nowhere that can log it.
>
>
The lack of logging of nscd, if anything, I'd argue is a reason for
the various Working Groups for the Products to have sssd enabled (with
sss at the start of nsswitch) and running by default, and with systemd
always restarting it.
In other words, the exact current state of Fedora 26 (modulo the systemd piece;
some parts of SSSD can be auto-managed by systemd, the rest are managed by the
sssd "monitor" process which does the auto-restarting if needed).
9:22 a.m.
On 18 May 2017 at 15:04, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 05/18/2017 09:41 AM, James Hogarth wrote:
> On 18 May 2017 at 14:33, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>> That's a perfectly reasonable request. I think it's fair to say that if
no
>> central user management is required, it's reasonable that our default would
be
>> to drop 'sss' from nsswitch.conf and turn nscd back on (to avoid I/O
lookups on
>> the local files).
>>
>> Though if we do that, I'd still like to see some daemon *somewhere*
monitoring
>> the files and flushing the nscd cache if they are modified, because an outdated
>> nscd cache is one of the hardest things for an end-user to debug because
there's
>> really nowhere that can log it.
>>
>>
>
> The lack of logging of nscd, if anything, I'd argue is a reason for
> the various Working Groups for the Products to have sssd enabled (with
> sss at the start of nsswitch) and running by default, and with systemd
> always restarting it.
In other words, the exact current state of Fedora 26 (modulo the systemd piece;
some parts of SSSD can be auto-managed by systemd, the rest are managed by the
sssd "monitor" process which does the auto-restarting if needed).
Right, I'm agreeing the F26 piece is far preferable to the other
outline with nscd.
10:28 a.m.
On 15 May 2017 at 17:15, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
This change proposes leveraging a new "files" provider SSSD
will ship in
the next version in order to resolve also users from the local files.
That way, the "sss" NSS module can be configured before the files module
in nsswitch.conf and the system could leverage sss_nss caching for both
local and remote users.
So someone reinvented the wheel/nscd?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
10:35 a.m.
On 05/15/2017 11:28 AM, Tomasz Kłoczko wrote:
On 15 May 2017 at 17:15, Jakub Hrozek <jhrozek(a)redhat.com>
wrote:
> This change proposes leveraging a new "files" provider SSSD will ship in
> the next version in order to resolve also users from the local files.
> That way, the "sss" NSS module can be configured before the files module
> in nsswitch.conf and the system could leverage sss_nss caching for both
> local and remote users.
So someone reinvented the wheel/nscd?
Tomasz, your tone is needlessly hostile. If you have a question, ask it. If you want to
make a suggestion, make it. But casting aspersions on people doing work is unacceptable.
Frankly, nearly all of your posts to this list have been hostile to the rest of the
community and have not added to the discussion in any way. You can do better than this,
and we expect you to do so if you don't want people to just start blocking your
messages and ignoring you entirely.
Now, in this particular case, what happened is that SSSD was developed which is a
significant improvement over NSCD when used with central identity stores like LDAP,
FreeIPA, etc. However, one down-side to this is that it can't coexist with nscd
because nscd is too greedy and doesn't allow requests to always pass to the SSSD
service. So when using SSSD for central identities, we take a performance hit on local
lookups (they need to go to I/O against the disk). A recent enhancement to SSSD allows the
performance to be restored to nscd levels when dealing with the local accounts. So we
enabled that and made SSSD the primary source for lookups.
10:57 a.m.
On 15 May 2017 at 17:35, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
Tomasz, your tone is needlessly hostile. If you have a question, ask
it. If you want to make a suggestion, make it. But casting aspersions on people doing work
is unacceptable.
Just please read my question straight. What I've wrote it is very
simple technical question as glibc NSS code *ALWAYS* is trying to
communicate with nscd ov. socket before calling any routine from any
nss_<map> modules even if nscd is not running.
In this context implementing in sssd any caching infrastructure is
more like idiotic than well justified (technically) move.
Did anyone tested what happens in the system authenticated ov (for
example) LDAP where ncsd and sssd are running on the same system? As I
was in the past few years shadow-utils source code maintainer I know
that after each modifications files used by NSS (like passwd, shadow,
group, passwd, group, sgroup, networks and few other in /etc) is
necessary to communicate with nscd to do do cache clean.
I would be not surprised if in case enabled caching by sssd and modify
for example /etc/passwd nothing from shadow-utils will be trying to
communicate with sssd to clear its passwd map cache.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
11:20 a.m.
On Mon, May 15, 2017 at 05:57:50PM +0200, Tomasz Kłoczko wrote:
In this context implementing in sssd any caching infrastructure is
more like idiotic than well justified (technically) move.
Ok, look. You've been warned on this before. You are now on moderation
on this list. You're welcome to contribute to Fedora in a positive way,
but this is *not* how we work together as friends in this community.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:47 p.m.
On Mon, May 15, 2017 at 05:57:50PM +0200, Tomasz Kłoczko wrote:
On 15 May 2017 at 17:35, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> Tomasz, your tone is needlessly hostile. If you have a question, ask it. If you want
to make a suggestion, make it. But casting aspersions on people doing work is
unacceptable.
Just please read my question straight. What I've wrote it is very
simple technical question as glibc NSS code *ALWAYS* is trying to
communicate with nscd ov. socket before calling any routine from any
nss_<map> modules even if nscd is not running.
In this context implementing in sssd any caching infrastructure is
more like idiotic than well justified (technically) move.
Did anyone tested what happens in the system authenticated ov (for
example) LDAP where ncsd and sssd are running on the same system?
This has been strongly discouraged for years as Stephen said and sssd
would warn you loudly to syslog if it was running together with nscd and
nscd was caching the maps that sssd handles as well (so, caching hosts
would be fine for example)
As I
was in the past few years shadow-utils source code maintainer I know
that after each modifications files used by NSS (like passwd, shadow,
group, passwd, group, sgroup, networks and few other in /etc) is
necessary to communicate with nscd to do do cache clean.
I would be not surprised if in case enabled caching by sssd and modify
for example /etc/passwd nothing from shadow-utils will be trying to
communicate with sssd to clear its passwd map cache.
Right, in this case we try to detect the inconsistency in SSSD and fall
back to nss_files (which is still in nsswitch, just not on the first
place anymore) by just flushing the caches when SSSD detects the files
have changed.
But you are right that in order to be on the safe side, we also need to
invalidate the sssd caches from shadow-utils. And we have a sssd ticket
to track this (admittedly we should have a bugzilla as well, I took a
note to file one)
10:24 a.m.
On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
My current Fedora 26 default nsswitch.conf contains these lines:
passwd: sss files systemd
shadow: files sss
group: sss files systemd
* Where is the consistency?
* Where is the Fedora Change page that talks about these modifications
of fairly critical systemwide configuration file?
* From which time systemd started to manage user accounts of the
machine, again where is the Fedora Change page for such change?
systemd does not manage user accounts, this is for resolving DynamicUsers
for services;
https://github.com/systemd/systemd/commit/4ffe24797cc881f1dc95f39badf6fac...
--
Tomasz Torcz Only gods can safely risk perfection,
xmpp: zdzichubg(a)chrome.pl it's a dangerous thing for a man. -- Alia
2532
days inactive
2535
days old
19 comments
9 participants
participants (9)
-
David Sommerseth -
Jakub Hrozek -
James Hogarth -
Matthew Miller -
Nico Kadel-Garcia -
Stephen Gallagher -
Tomas Mraz -
Tomasz Kłoczko -
Tomasz Torcz