On Wed, Nov 11, 2020 at 7:41 AM Pavel Březina <pbrezina@xxxxxxxxxx> wrote: > > On 11/5/20 1:58 PM, Nico Kadel-Garcia wrote: > > On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík <pemensik@xxxxxxxxxx> wrote: > >> > >> No, no, NO again. > >> > >> nscd has no important active bugs in Fedora. I am not sure what bugs are > >> mentioned, but just a few active bugs are on glibc component in Fedora. > >> Therefore it seems just fine no commits are good. > >> > >> Just unlike systemd-resolved, which actively breaks some use cases. It > >> changes resolution order of search directive in resolv.conf, breaks > >> DNSSEC, breaks one label names resolution. It is famous among DNS > >> community [1]. > > > > sssd also breaks other LDAP setups, It's extremely broken with larger > > LDAP setups because it insists on caching *ALL* of the LDAP, barring > > being able to filter to only a smaller set of the LDAP. But because so > > many LDAP setups scatter group and user information in so many > > distinct parts of the LDAP layout, this never works and it *ALWAYS* > > times out in large, remot4e LDAP setups. It works for a few seconds at > > start time, then crashes and takes out *all* sssd based services. > > SSSD only stores required data, i.e. requested users, groups or whatever > unless you set enumerate=true which is explicitly stated as "not > recommended" in SSSD manual pages. Unless it's been heavily modified, it pre-caches *EVERYTHING* from LDAP by default. It's possible to limit the sssd.conf to restricted groups or users in specific LDAP ou's, but the larger the company, the more likely the necessary ou's for relevant users and groups are likely to be in very large, scattered ou's throughout the LDAP layout, and the result is excessive caching and unavoidable timeouts. Been there, done that, about 24 months ago. > > The sophisticated setups available by hand-editing sssd are also > > *inevitably* overwritten by any use of the 'authconfig' command, which > > is used by various RPM '%post' operations. sssd's configuration > > Authconfig used to only override domain named "default" which was > created by authconfig and it only touched a specific set of options that > were requested by authconfig arguments. Also users usually don't name > their domain as "default" so I don't deem this a valid point. > Furthermore, real authconfig is not around since Fedora 28 and the > wrapper around authselect touches only a configuration snippet. authconfig doesn't clean up. It has no *options* to clean up. And at last look, it blew away the hand-tuning of sssd.conf. to restrict the LDAP caching to more finely tuned ou's. It was not my friend. Last time, I threw it the !@#$ out in plain old LDAP and Kerberos setups for a much more robust and industry capable setup. > > options are so poor that they may as well be malicious. It is most > > effective in small and unsophisticated network environments. It > > suffers from the "systemd" style, sprawling universal management tool > > design principles and makes many straightforward operations very > > difficult if not impossible. > > What kind of operations? > > I don't know when it was the last time you tried SSSD or authconfig and > I know nothing about your environment but these are just hateful > paragraphs without any kind of evidence. If you have any issue with > SSSD, feel free to open bug report and we can see what needs to be done > to make it work for you. > > > nscd is a lightweight and *far* more stable tool, and should be used > > in preference to sssd wherever possible. An indepent LDAP and Kerberos > > toolkit is *far* more stable than sssd. > > > >> Instead, I request again, split systemd-resolved into subpackage. I want > >> it removed on my system and so do more people. Also, when I disable it, > >> I have to fix /etc/resolv.conf by hand. I would think NetworkManager > >> restart would refresh classic /etc/resolv.conf, like in F32. > > > > That's a separate issue. Maybe start a separate thread about that? > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
