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