On 05/16/2017 07:04 AM, Nico Kadel-Garcia wrote: > On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
