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@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. 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
