Re: Wild changes in nsswitch.conf

[James Hogarth]

On 18 May 2017 at 15:04, Stephen Gallagher  wrote:
> On 05/18/2017 09:41 AM, James Hogarth wrote:
>> On 18 May 2017 at 14:33, Stephen Gallagher  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Stephen Gallagher]

On 05/18/2017 09:41 AM, James Hogarth wrote:
> On 18 May 2017 at 14:33, Stephen Gallagher  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).




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[James Hogarth]

On 18 May 2017 at 14:33, Stephen Gallagher  wrote:
> On 05/18/2017 09:24 AM, Nico Kadel-Garcia wrote:
>> On Thu, May 18, 2017 at 6:17 AM, Jakub Hrozek  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Stephen Gallagher]

On 05/18/2017 09:24 AM, Nico Kadel-Garcia wrote:
> On Thu, May 18, 2017 at 6:17 AM, Jakub Hrozek  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.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Nico Kadel-Garcia]

On Thu, May 18, 2017 at 6:17 AM, Jakub Hrozek  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

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  
> > 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[David Sommerseth]

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



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Stephen Gallagher]

On 05/16/2017 07:04 AM, Nico Kadel-Garcia wrote:
> On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher  
> 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.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Nico Kadel-Garcia]

On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

On Mon, May 15, 2017 at 05:57:50PM +0200, Tomasz Kłoczko wrote:
> On 15 May 2017 at 17:35, Stephen Gallagher  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_ 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)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Matthew Miller]

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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Tomasz Kłoczko]

On 15 May 2017 at 17:35, Stephen Gallagher  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_ 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Stephen Gallagher]

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.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Stephen Gallagher]

On 05/15/2017 11:28 AM, Tomasz Kłoczko wrote:
> On 15 May 2017 at 17:15, Jakub Hrozek  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.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Tomasz Kłoczko]

On 15 May 2017 at 17:15, Jakub Hrozek  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Tomasz Torcz]

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/4ffe24797cc881f1dc95f39badf6facd8061117e

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Tomas Mraz]

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.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

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. 
"""
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org