Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Ben Cotton]

FESCo's approval[1] of this proposal was contingent on splitting it into
two phases. For Fedora 34, nscd will be deprecated[2]. For Fedora 35, nscd
will be removed[3].

[1] https://pagure.io/fesco/issue/2501#comment-704653
[2] https://fedoraproject.org/wiki/Changes/DeprecateNSCD
[3] https://fedoraproject.org/wiki/Changes/RemoveNSCD

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
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-announce@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Ben Cotton]

FESCo's approval[1] of this proposal was contingent on splitting it into
two phases. For Fedora 34, nscd will be deprecated[2]. For Fedora 35, nscd
will be removed[3].

[1] https://pagure.io/fesco/issue/2501#comment-704653
[2] https://fedoraproject.org/wiki/Changes/DeprecateNSCD
[3] https://fedoraproject.org/wiki/Changes/RemoveNSCD

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Marius Schwarz:

>  It not only caches names, it also RANDOMIZES the requests to the dns
> servers configured, increasing the privacy of ones internet journey.

> That it does it, was the reason i tried it out at home  ;)

Let me repeat then, less politely: It does not do any such thing.  You
have been misled.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

On 11/17/20 10:12 AM, Lennart Poettering wrote:
> On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote:
> 
>> But it does not have to learn everything about a server, because it
>> switched the active one. If it has to, try to find way to store server
>> instance features per server IP, not per link.
> 
> We do exactly this. But we also have a grace period after which we
> forget everything again, and go back to the best server feature level again,
> which then takes some time to settle back on the actual server feature
> level.
I think smart RTT checking every few minutes would be better, than
forgetting everything about server always responding quickly.
> 
> When we always use the same server, then we probe it once, and use it
> for the full grace period without any further delays. When we use
> numerous servers, and a different one for each lookup, then this means
> we have to probe each and every single one of them once and that slows
> down things.
You can cache average response time for the server. If answer did not
arrive in triple or usuall RTT, send to other servers too. It should not
be done for each request. Depends on how long grace period, right?
> 
> It's a very easy calulation: if you use n=1 servers for 500 lookups
> within the grace period, you experience 1 slow lookup in the worst
> case that required the feature probing, plus 499 speedy lookups
> because we already knew the earlier probing results. If otoh you use
> n=250 servers for 500 lookups you experience 250 worst case slow
> lookups, since we need to learn for each server individually what it
> can and can't do, plus 250 speedy lookups. And then, after the grace
> period is over, you get another 250 slow lookups...
I would think you can detect almost everything from 2 requests and
replies. Only special workarounds for broken implementations may take more.

It could work by timeout not too visible. It would send few queries to
secondary server, metering averate round-trip time. If it was
significantly better than the current server, switch to it. Unless
connection changed, you can expect previous quirks apply, but still you
can test response time. I think dnsmasq sends ocassinally few requests
to non-primary. If answers don't arrive withing hundreds of ms, try also
others. So user has answer soon and it did measure response time of all
used servers. Even if any of them is offline. It does not have to be 50%
of queries just to test it.
> 
>>> It might be something to add as opt-in, and come with the warning that
>>> you better list DNS servers that aren't crap if you want to use that,
>>> so that we never have to downgrade protocol level, and thus the
>>> learning phase is short.
>>
>> Sure enough, many router DNS implementations are bad or ugly. If it can
>> choose from full featured validated ISP resolver and crappy router
>> implementation, prefer the one with better features. Most likely it is
>> much better maintained as well.
> 
> I am sorry, but that is not a suitable approach for an "edge" DNS
> clients. We need to go through the DNS server info we acquired through
> DHCP or so, since private domains do exist. We must keep router admin
> pages accessible.
I haven't mentioned using any external DHCP client. Problem is, there is
no standard way to configure slit DNS over DHCP. Or even declare private
domains used by local networks via autoconfiguration.

I tried Mikrotik's 'router' name on rawhide container.
# dig @127.0.0.53 router
gives status: NXDOMAIN
# dig @127.0.0.53 router.
gives status: NXDOMAIN

/etc/resolv.conf points to /run/systemd/resolve/resolv.conf
but getent can deliver results. How is that possible?

# getent hosts router
192.168.88.1router

# grep hosts /etc/nsswitch.conf
hosts:  resolve [!UNAVAIL=return] myhostname files mdns4_minimal
[NOTFOUND=return] dns

Of course, Mikrotik supports only DNS, not LLMNR or mDNS.

Are you sure you don't support your router's bogus domain, but forgot
about other vendors?

What I am saying is, resolved might choose only the second server from
DHCP list. Where only first knew about private domains for example. It
is kind of broken configuration, but not uncommon. Router's DNS might be
out of date, vulnerable to various attacks, but would be first IP on DNS
servers from DHCP. Second would be ISP's resolver with up-to-date
security backups. Now, systemd-resolved understands DNS servers as a
set, but not ordered list, right? Would and should it choose ISP's
server or my home router? What are checked metrics?

> 
> Hence, the "server spread" thing where queries are spread over a ton
> of DNS servers only really works if configured for the manual opt-in
> case. It's not something we could ever deploy by default. By default
> we need something that works, doesn't break private domains, and isn't
> slow.
I agree, but just partially. Original behaviour of nss_dns.so plugin was
to always keep order of used DNS servers constant. I am not sure this is
possible to 

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[przemek klosowski via devel]

On 11/17/20 4:24 AM, Lennart Poettering wrote:

dig @9.9.9.9 +nsid heise.de


FWIW, a neat way to look at differences like that is

    watch -d dig @9.9.9.9 +nsid heise.de

I use it often for looking at hotplugs (watch -d lsusb) etc.

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Lennart Poettering]

On So, 15.11.20 18:25, Chris Adams (li...@cmadams.net) wrote:

> Once upon a time, Stephen John Smoogen  said:
> > Because a lot of networks use routing tricks to send traffic to particular
> > DNS server IP addresses. They may round robin, traffic route, or other
> > methods to send you to different DNS servers with the same ip address. Even
> > if they are all the same 'model' device, they have different features
> > turned on or are at different revisions.. so whatever you have cached is
> > wrong.
>
> I'm pretty sure that's considered "their problem"... anycast servers are
> expected to behave the same (or similar enough) in terms of features
> supported.  Real DNS recursive servers like Unbound and BIND keep info
> about particular servers by IP.

We do exactly this.

(It is far from perfect though, for example, quad9's DNS servers you
reach via 9.9.9.9 might have a different feature set whenever you
reach them. Try "dig @9.9.9.9 +nsid heise.de" a bunch of times. It
will sometimes advertise an EDNS dgram size of 512 and sometimes of
1232. Which is quite some discrepancy in configuration. — And
sometimes it returns NSID, and sometimes it doesn't, but I am fine to
ignore that.)

Lennart

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Lennart Poettering]

On So, 15.11.20 15:36, Samuel Sieb (sam...@sieb.net) wrote:

> On 11/15/20 7:31 AM, Lennart Poettering wrote:
> > Implementing this does not come without drawbacks though: right now
> > resolved tries hard to use the same server if at all possible, since
> > we want to use newer DNS features if possible, but many DNS servers
> > (wifi routers, yuck) tend to support them quite badly. This means
> > resolved has an elaborate scheme to learn about the feature set of the
> > DNS servers it contacts. And that can be slow, in particular on
> > servers where we step-by-step have to downgrade to the most minimal of
> > DNS protocols. This learning phase is run only when first contacting
> > some server (and after some grace period). If we'd switch servers all
> > the time, for every single lookup, then we'd start from zero every
> > time, not knowing what the server supports, and thus having to learn
> > about it over and over again. This would hence make all,
> > *every*single* transaction pretty slow. And that sucks.
>
> Wouldn't you just need to do it once for each server and cache that info?
> And why do you need to re-do the learning phase for a server you've already
> checked?

We do remember that. But if you stick to talking to one server for 500
transactions, you will have one slow lookup, the initial one that
needs to probe the feature set, plus 499 speedy ones. If you however
spread your 500 lookups over 250 servers, you will get 250 slow looups
plus 250 speedy ones — all in the worst case. Simply becaue we then
need to probe 250 servers for the first time... (See other mail)

> > DoT becomes efficient when we can reuse the established TCP/TLS connection
> > for multiple lookups. But if we'd switch servers all the time, then of
> > course there's no reuse of TCP/TLS connections possible.
>
> Same thing here.  Would it be a problem to keep a connection open for each
> server?

We keep one connection open for each server, if it let's us. Typically
they don't let us keep it open for long though. if you have actually
have a ton of servers and distribute lookups over all of them, it
decreases the chance of connection reuse, and thus increases the
chance that connections will go idle from perspective of the server
operator, and thus will be disconnected. Given the short idle timeouts
of popular servers such as 8.8.8.8 this actually matters a lot.

Lennart

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Lennart Poettering]

On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote:

> But it does not have to learn everything about a server, because it
> switched the active one. If it has to, try to find way to store server
> instance features per server IP, not per link.

We do exactly this. But we also have a grace period after which we
forget everything again, and go back to the best server feature level again,
which then takes some time to settle back on the actual server feature
level.

When we always use the same server, then we probe it once, and use it
for the full grace period without any further delays. When we use
numerous servers, and a different one for each lookup, then this means
we have to probe each and every single one of them once and that slows
down things.

It's a very easy calulation: if you use n=1 servers for 500 lookups
within the grace period, you experience 1 slow lookup in the worst
case that required the feature probing, plus 499 speedy lookups
because we already knew the earlier probing results. If otoh you use
n=250 servers for 500 lookups you experience 250 worst case slow
lookups, since we need to learn for each server individually what it
can and can't do, plus 250 speedy lookups. And then, after the grace
period is over, you get another 250 slow lookups...

> > It might be something to add as opt-in, and come with the warning that
> > you better list DNS servers that aren't crap if you want to use that,
> > so that we never have to downgrade protocol level, and thus the
> > learning phase is short.
>
> Sure enough, many router DNS implementations are bad or ugly. If it can
> choose from full featured validated ISP resolver and crappy router
> implementation, prefer the one with better features. Most likely it is
> much better maintained as well.

I am sorry, but that is not a suitable approach for an "edge" DNS
clients. We need to go through the DNS server info we acquired through
DHCP or so, since private domains do exist. We must keep router admin
pages accessible.

Hence, the "server spread" thing where queries are spread over a ton
of DNS servers only really works if configured for the manual opt-in
case. It's not something we could ever deploy by default. By default
we need something that works, doesn't break private domains, and isn't
slow.

Lennart

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Simo Sorce]

On Thu, 2020-11-05 at 07:58 -0500, Nico Kadel-Garcia wrote:
> On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  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. 

Sorry but this is simply not true, you can apply filters to reduce the
set to what you want.

> 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.
> 
> 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
> 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.

open bugs please.

> 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.

It is also a very crude tool that fails in different scenarios.

If NSCD was a good caching tool I would not have had the need to invent
SSSD in the first place.

nscd has extremely bad failure modes that makes it completely unusable
for example for a laptop, or a server that can be disconnected from the
mothership for more than a network blip. SSSD can handle long
disconnection times instead as it has an offline mode concept.

Nothing is perfect, but NSCD is far from good as well.

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

On 11/15/20 4:31 PM, Lennart Poettering wrote:
> On So, 15.11.20 10:18, Marius Schwarz (fedora...@cloud-foo.de) wrote:
> 
>> Am 11.11.20 um 16:58 schrieb Lennart Poettering:
>>> So if you configure 4 DNS servers then each will still get roughly
>>> 1/4th of your requests? That's still quite a lot of info.
>> the more you use, and i did, the better it protects against tracking by the
>> dns cache owners.
Use stubby. 1/4 is not enough, more resolvers are necessary. Or just
find a trusted ISP and hide in his resolver crowd.
>>
>> How about putting this as a feature request in resolved?
> 
> Please file an RFE issue on github:
> 
> https://github.com/systemd/systemd/issues/new?template=Feature_request.md
> 
> Implementing this does not come without drawbacks though: right now
> resolved tries hard to use the same server if at all possible, since
> we want to use newer DNS features if possible, but many DNS servers
> (wifi routers, yuck) tend to support them quite badly. This means
> resolved has an elaborate scheme to learn about the feature set of the
> DNS servers it contacts. And that can be slow, in particular on
> servers where we step-by-step have to downgrade to the most minimal of
> DNS protocols. This learning phase is run only when first contacting
> some server (and after some grace period). 

Understood, learning about server features, especially weird ones that
use request drop instead of request refusal, can take some time. It
definitely should be cached for some time.

If we'd switch servers all
> the time, for every single lookup, then we'd start from zero every
> time, not knowing what the server supports, and thus having to learn
> about it over and over again. This would hence make all,
> *every*single* transaction pretty slow. And that sucks.

This is ridiculous. It might be limitation of current systemd-resolved
implementation, but it is not necessary. All DNS servers track info
about used remotes and their detected features. Even dnsmasq, which is
not full recursive server, just like systemd-resolved. It can learn
about each configured server and keep information about it cached for
some time. Just like TTL of cached records. It can also flush such cache
on interface configuration change, network errors from the server etc.

But it does not have to learn everything about a server, because it
switched the active one. If it has to, try to find way to store server
instance features per server IP, not per link.
> 
> It might be something to add as opt-in, and come with the warning that
> you better list DNS servers that aren't crap if you want to use that,
> so that we never have to downgrade protocol level, and thus the
> learning phase is short.

Sure enough, many router DNS implementations are bad or ugly. If it can
choose from full featured validated ISP resolver and crappy router
implementation, prefer the one with better features. Most likely it is
much better maintained as well.

However, some people rely on the order of used servers in resolv.conf.
First server might know some local names, which secondary backup does
not know about. Such situation is impossible to detect automatically,
but is not too uncommon. I miss some way to force first server always
first if possible. Something like --strict-order of dnsmasq.
> 
> (There have been suggestions to probe ahead-of-time, i.e. already
> before we have to dispatch the first lookup request to it, i.e. at the
> time the DNS server address is configured. However that is a privacy
> issue, too, since it means systems would suddenly start contacting DNS
> servers, even without anyone needing it.)
> 
>> It should of course use encrypted protocols first.
It is questionable, how much are encrypted protocols needed. Of course,
ISP can monitor all your traffic. They can usually monitor all your
queries. But if you seek protection for it, why don't you change your
ISP? Thanks to GDPR, they cannot just sell information about your
actions without your consent. And cannot force you to give the consent
too. If you connect to ISP's server, they can see your queries anyway.
Even encrypted. If you don't, they can see TLS info, which usually leaks
plaintext hostnames too. In the last resort, then can see targetted IPs
and can deduce from them a lot. In short, if you dont trust them, use
full VPN or change them altogether. Most of us living in a free world
can do that.

> It supports DoT since a longer time. Is currently opt-in on Fedora
> though, but we should change that.
> 
> DoT becomes efficient when we can reuse the established TCP/TLS connection
> for multiple lookups. But if we'd switch servers all the time, then of
> course there's no reuse of TCP/TLS connections possible.

I don't see a reason for it here as well. It should be perfectly
possible to have 3 connections to one server and 2 to another one. And
randomize queries to each connection. Reuse of TLS connection is
definitely wanted feature. Again, it might be limitation of current

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 16, 2020 at 07:45:54AM -0500, Stephen John Smoogen wrote:
> On Sun, 15 Nov 2020 at 19:26, Chris Adams  wrote:
> 
> > Once upon a time, Stephen John Smoogen  said:
> > > Because a lot of networks use routing tricks to send traffic to
> > particular
> > > DNS server IP addresses. They may round robin, traffic route, or other
> > > methods to send you to different DNS servers with the same ip address.
> > Even
> > > if they are all the same 'model' device, they have different features
> > > turned on or are at different revisions.. so whatever you have cached is
> > > wrong.
> >
> > I'm pretty sure that's considered "their problem"... anycast servers are
> > expected to behave the same (or similar enough) in terms of features
> > supported.  Real DNS recursive servers like Unbound and BIND keep info
> > about particular servers by IP.
> >
> > However, using info that's being tracked as a reason to not to use
> > multiple servers is a rather weak argument... keeping track of info for
> > additional servers should not be difficult.

Currently resolved switches servers when it doesn't "like" the current
server (timeout, or not working as expected, etc). I think it'd be
fairly easy to implement a mode where the switch also happens on the basis
of time or the number of packets handled. In that mode, it should remember
what capabilities the given server had and just seamlessly restart later on.

OTOH, with two or three servers, the "privacy gains" are so tiny. It's
completely routine to resolve the same names over and over, so each server
has a large chance of capturing enough queries of interest. And also
often even one query is enough to determine a lot about what the user
is doing.

Overall, I think that the caching that is currently happening with resolved
does more for privacy, just by reducing the number of requests, than the
server rotation without cache.

So... I expect that this will be implemented, if somebody provides a patch
or if enough people express interest. I expect upstream to treat it as low
priority though.

(FWIW, a patch to do randomization of results delivered to
applications, even if the same cached upstream answer is being reused,
has been recently merged. This promotes random selection of a specific
address on the application side when a name resolves to more than
one. The justification was that it's simple to implement, and even if
the effect is weak, it *may* be useful in some scenarios.)

> Good point. However at what point to improving these features becomes where
> systemd "bloat. Systemd came up with an "ok" low level solution and then
> people keep nitpicking that it could do a better job and track more
> things.. and eventually you have systemd rewritten in eLISP and a native
> emacs mode. [Change to more appropriate languages for the 21st century..
> rewritten in javascript and a native Node-VSCode mode.]

So far we have resisted the urge do to plugins and extensions. Let's
say that elips or js support is unlikely ;]

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Marius Schwarz]

Am 16.11.20 um 00:36 schrieb Samuel Sieb:
DoT becomes efficient when we can reuse the established TCP/TLS 
connection

for multiple lookups. But if we'd switch servers all the time, then of
course there's no reuse of TCP/TLS connections possible.


Same thing here.  Would it be a problem to keep a connection open for 
each server?


I'm pretty sure, DNS Cache owners won't keep your connection open 
forever due to available sockets on a system.


So randomization may have it's limits, if used with DoT or DoH.  No 
limits for UDP transports here.


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Stephen John Smoogen]

On Sun, 15 Nov 2020 at 19:26, Chris Adams  wrote:

> Once upon a time, Stephen John Smoogen  said:
> > Because a lot of networks use routing tricks to send traffic to
> particular
> > DNS server IP addresses. They may round robin, traffic route, or other
> > methods to send you to different DNS servers with the same ip address.
> Even
> > if they are all the same 'model' device, they have different features
> > turned on or are at different revisions.. so whatever you have cached is
> > wrong.
>
> I'm pretty sure that's considered "their problem"... anycast servers are
> expected to behave the same (or similar enough) in terms of features
> supported.  Real DNS recursive servers like Unbound and BIND keep info
> about particular servers by IP.
>
> However, using info that's being tracked as a reason to not to use
> multiple servers is a rather weak argument... keeping track of info for
> additional servers should not be difficult.
>

Good point. However at what point to improving these features becomes where
systemd "bloat. Systemd came up with an "ok" low level solution and then
people keep nitpicking that it could do a better job and track more
things.. and eventually you have systemd rewritten in eLISP and a native
emacs mode. [Change to more appropriate languages for the 21st century..
rewritten in javascript and a native Node-VSCode mode.]



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


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Chris Adams]

Once upon a time, Stephen John Smoogen  said:
> Because a lot of networks use routing tricks to send traffic to particular
> DNS server IP addresses. They may round robin, traffic route, or other
> methods to send you to different DNS servers with the same ip address. Even
> if they are all the same 'model' device, they have different features
> turned on or are at different revisions.. so whatever you have cached is
> wrong.

I'm pretty sure that's considered "their problem"... anycast servers are
expected to behave the same (or similar enough) in terms of features
supported.  Real DNS recursive servers like Unbound and BIND keep info
about particular servers by IP.

However, using info that's being tracked as a reason to not to use
multiple servers is a rather weak argument... keeping track of info for
additional servers should not be difficult.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Stephen John Smoogen]

On Sun, 15 Nov 2020 at 18:37, Samuel Sieb  wrote:

> On 11/15/20 7:31 AM, Lennart Poettering wrote:
> > Implementing this does not come without drawbacks though: right now
> > resolved tries hard to use the same server if at all possible, since
> > we want to use newer DNS features if possible, but many DNS servers
> > (wifi routers, yuck) tend to support them quite badly. This means
> > resolved has an elaborate scheme to learn about the feature set of the
> > DNS servers it contacts. And that can be slow, in particular on
> > servers where we step-by-step have to downgrade to the most minimal of
> > DNS protocols. This learning phase is run only when first contacting
> > some server (and after some grace period). If we'd switch servers all
> > the time, for every single lookup, then we'd start from zero every
> > time, not knowing what the server supports, and thus having to learn
> > about it over and over again. This would hence make all,
> > *every*single* transaction pretty slow. And that sucks.
>
> Wouldn't you just need to do it once for each server and cache that
> info?  And why do you need to re-do the learning phase for a server
> you've already checked?
>
>
Because a lot of networks use routing tricks to send traffic to particular
DNS server IP addresses. They may round robin, traffic route, or other
methods to send you to different DNS servers with the same ip address. Even
if they are all the same 'model' device, they have different features
turned on or are at different revisions.. so whatever you have cached is
wrong.




> > DoT becomes efficient when we can reuse the established TCP/TLS
> connection
> > for multiple lookups. But if we'd switch servers all the time, then of
> > course there's no reuse of TCP/TLS connections possible.
>
> Same thing here.  Would it be a problem to keep a connection open for
> each server?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Samuel Sieb]

On 11/15/20 7:31 AM, Lennart Poettering wrote:

Implementing this does not come without drawbacks though: right now
resolved tries hard to use the same server if at all possible, since
we want to use newer DNS features if possible, but many DNS servers
(wifi routers, yuck) tend to support them quite badly. This means
resolved has an elaborate scheme to learn about the feature set of the
DNS servers it contacts. And that can be slow, in particular on
servers where we step-by-step have to downgrade to the most minimal of
DNS protocols. This learning phase is run only when first contacting
some server (and after some grace period). If we'd switch servers all
the time, for every single lookup, then we'd start from zero every
time, not knowing what the server supports, and thus having to learn
about it over and over again. This would hence make all,
*every*single* transaction pretty slow. And that sucks.


Wouldn't you just need to do it once for each server and cache that 
info?  And why do you need to re-do the learning phase for a server 
you've already checked?



DoT becomes efficient when we can reuse the established TCP/TLS connection
for multiple lookups. But if we'd switch servers all the time, then of
course there's no reuse of TCP/TLS connections possible.


Same thing here.  Would it be a problem to keep a connection open for 
each server?

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Lennart Poettering]

On So, 15.11.20 10:18, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> Am 11.11.20 um 16:58 schrieb Lennart Poettering:
> > So if you configure 4 DNS servers then each will still get roughly
> > 1/4th of your requests? That's still quite a lot of info.
> the more you use, and i did, the better it protects against tracking by the
> dns cache owners.
>
> How about putting this as a feature request in resolved?

Please file an RFE issue on github:

https://github.com/systemd/systemd/issues/new?template=Feature_request.md

Implementing this does not come without drawbacks though: right now
resolved tries hard to use the same server if at all possible, since
we want to use newer DNS features if possible, but many DNS servers
(wifi routers, yuck) tend to support them quite badly. This means
resolved has an elaborate scheme to learn about the feature set of the
DNS servers it contacts. And that can be slow, in particular on
servers where we step-by-step have to downgrade to the most minimal of
DNS protocols. This learning phase is run only when first contacting
some server (and after some grace period). If we'd switch servers all
the time, for every single lookup, then we'd start from zero every
time, not knowing what the server supports, and thus having to learn
about it over and over again. This would hence make all,
*every*single* transaction pretty slow. And that sucks.

It might be something to add as opt-in, and come with the warning that
you better list DNS servers that aren't crap if you want to use that,
so that we never have to downgrade protocol level, and thus the
learning phase is short.

(There have been suggestions to probe ahead-of-time, i.e. already
before we have to dispatch the first lookup request to it, i.e. at the
time the DNS server address is configured. However that is a privacy
issue, too, since it means systems would suddenly start contacting DNS
servers, even without anyone needing it.)

> It should of course use encrypted protocols first.

It supports DoT since a longer time. Is currently opt-in on Fedora
though, but we should change that.

DoT becomes efficient when we can reuse the established TCP/TLS connection
for multiple lookups. But if we'd switch servers all the time, then of
course there's no reuse of TCP/TLS connections possible.

or in other words: adding this conflicts with other (and I think more
important) goals here. Thus if we add this, only as option i
figure. It's not suitable as sensible default.

Lennart

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Marius Schwarz]

Am 11.11.20 um 16:58 schrieb Lennart Poettering:

So if you configure 4 DNS servers then each will still get roughly
1/4th of your requests? That's still quite a lot of info.
the more you use, and i did, the better it protects against tracking by 
the dns cache owners.


How about putting this as a feature request in resolved? It should of 
course use encrypted protocols first.


Best regards,
Marius

BTW: Der Landesdatenschutz hat eine Überprüfung der Frage des 
Datenschutzverstoßes bei  IPs an Cloudflare angenommen, aber wegen 
chronischer Überlastung wird das vermutlich Monate oder gar Jahre 
dauern, bis wir da was bekommen. Für Niedersachsen gibt es genau eine 
Personalstelle für "Internet"-Sachen ;)


For anyone else, the german state agency for dataprotection of Lower 
Saxony has accepted  the case of resolved using CF or Google as 
fallback. The rule if or if not it's a dp fault can take years due to a 
bad personal situation at the agency.

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Marius Schwarz]

Am 09.11.20 um 18:34 schrieb Florian Weimer:

It not only caches names, it also RANDOMIZES the requests to the dns
servers configured, increasing the privacy of ones internet journey.

nscd?  I don't think it does anything like that.  It doesn't even have
its own DNS code, it uses the same code that would you get as an
in-process library in your application.

That it does it, was the reason i tried it out at home  ;)

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Markus Larsson]

On Sat, 2020-11-14 at 19:11 -0500, Nico Kadel-Garcia wrote:
> On Sat, Nov 14, 2020 at 6:02 PM Markus Larsson 
> wrote:
> 
> > Sounds like a horrible experience. It seems circumventable by not
> > caching entire OUs though. They way sssd has been used where I have
> > been it has only cached users actually logging in. That's a single
> > setting in sssd.conf that makes all the difference.
> > Not saying you're wrong though, I've just never seen the issue over
> > the years.
> > I have seen early sssd take down an AD domain controller do to
> > aggressively asking for every user but that was many years ago :)
> 
> Which setting are you referring to? Because a couple of years ago, I
> couldn't find a graceful way to prevent it.

ignore_group_members is the one. It has other implications which can
make a fuzz in certain situations though.
Generally what is problematic in my book is that most LDAP directories
has a group that contains every user of the directory which promts sssd
to pull every user.
One could also mask the offending group and in some case that solves
the issue.
I feel your pain though, I have seen quite a few LDAPs but never a tidy
one (not even my freeipa at home is as tidy as I would like it to be).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Nico Kadel-Garcia]

On Sat, Nov 14, 2020 at 6:02 PM Markus Larsson  wrote:

> Sounds like a horrible experience. It seems circumventable by not caching 
> entire OUs though. They way sssd has been used where I have been it has only 
> cached users actually logging in. That's a single setting in sssd.conf that 
> makes all the difference.
> Not saying you're wrong though, I've just never seen the issue over the years.
> I have seen early sssd take down an AD domain controller do to aggressively 
> asking for every user but that was many years ago :)

Which setting are you referring to? Because a couple of years ago, I
couldn't find a graceful way to prevent it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Markus Larsson]

On 14 November 2020 23:35:09 CET, Nico Kadel-Garcia  wrote:
>On Sat, Nov 14, 2020 at 5:11 PM Markus Larsson  wrote:
>>
>>
>>
>> On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia  wrote:
>> >
>> >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.
>>
>> I don't share this experience and I run sssd in large environments. Sssd 
>> will by default lookup the user authenticating, the groups that user belongs 
>> to and all members of those groups.
>> Looking up group members is easily turned off and leads to a much smoother 
>> experience from what I have seen.
>> I still don't think deprecating nscd seems like a reasonable change. Change 
>> defaults, well ok. Deprecating, I don't really see why tbh.
>
>Part of the difficulty comes when you only want to see certain LDAP
>groups, or permit access only for certain groups. When those groups
>are scattered around a poorly organized LDAP layout, it means you need
>to cache *all* the relevant OU's. Unless your pipeline to your remote
>environment is large, or you have deployed local LDAP servers to
>provide a remote mirror, the bulk pre-caching times out and causes all
>sssd related daemons to turn off after working for a short period, the
>daemons die. This was *nasty* when I observed it a few years ago, I
>had to convince the LDAP admins to set up new mirror groups in a much
>smaller OU workspace.

Sounds like a horrible experience. It seems circumventable by not caching 
entire OUs though. They way sssd has been used where I have been it has only 
cached users actually logging in. That's a single setting in sssd.conf that 
makes all the difference.
Not saying you're wrong though, I've just never seen the issue over the years.
I have seen early sssd take down an AD domain controller do to aggressively 
asking for every user but that was many years ago :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Nico Kadel-Garcia]

On Sat, Nov 14, 2020 at 5:11 PM Markus Larsson  wrote:
>
>
>
> On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia  wrote:
> >
> >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.
>
> I don't share this experience and I run sssd in large environments. Sssd will 
> by default lookup the user authenticating, the groups that user belongs to 
> and all members of those groups.
> Looking up group members is easily turned off and leads to a much smoother 
> experience from what I have seen.
> I still don't think deprecating nscd seems like a reasonable change. Change 
> defaults, well ok. Deprecating, I don't really see why tbh.

Part of the difficulty comes when you only want to see certain LDAP
groups, or permit access only for certain groups. When those groups
are scattered around a poorly organized LDAP layout, it means you need
to cache *all* the relevant OU's. Unless your pipeline to your remote
environment is large, or you have deployed local LDAP servers to
provide a remote mirror, the bulk pre-caching times out and causes all
sssd related daemons to turn off after working for a short period, the
daemons die. This was *nasty* when I observed it a few years ago, I
had to convince the LDAP admins to set up new mirror groups in a much
smaller OU workspace.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Markus Larsson]

On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia  wrote:
>
>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.

I don't share this experience and I run sssd in large environments. Sssd will 
by default lookup the user authenticating, the groups that user belongs to and 
all members of those groups.
Looking up group members is easily turned off and leads to a much smoother 
experience from what I have seen.
I still don't think deprecating nscd seems like a reasonable change. Change 
defaults, well ok. Deprecating, I don't really see why tbh.

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Nico Kadel-Garcia]

On Wed, Nov 11, 2020 at 7:41 AM Pavel Březina  wrote:
>
> On 11/5/20 1:58 PM, Nico Kadel-Garcia wrote:
> > On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  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@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 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@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Petr Menšík:

>> Fedora made the decision to promote systemd-resolved as a local DNS
>> cache.  To me, that means that we can gradually remove other DNS caches
>> from the distribution.

> I maintain also dnsmasq and I doubt there is reason to remove it from
> the distribution. I would oppose if anyone intented to do it.

dnsmasq has other uses in the distribution, see e.g. libvirt.  We don't
quite see that for nscd anymore.

>> There seem to be a lot of misconceptions about what nscd does and which
>> benefits it brings (see the claim about increased privacy).  So I think
>> it's important to be precise here.

> I expect it would only cache simple name:ip pairs, nothing more. No, I
> doubt nscd can bring any additional privacy.

Ahem.  Name/sets of addresses, which covers negative caching as well.

>> 
>> From my point of view, nscd is not a very satisfactory solution for DNS
>> caching because it can't do DNSSEC, it can't do recursion, it can't do
>> prefetching, it doesn't have a good way to detect dead servers, it can't
>> inject local stub zones, and so on.

> We can argue whether people need DNSSEC. Systemd-resolved cannot work
> with it correctly and it actively BREAKS its usage. Just like dnsmasq,
> nscd just caches and no more. It usually does not break anything. I
> think it preserves most features of libnss_dns.so behaviour. No
> recursion, dead servers detection or injecting local zones is required.
> It is not done without the cache anyway. Dead servers detection could be
> improved I think.

Dead server detection is what people expect that have migrated from
other systems.  dnsmasq has a rudimentary form of it:

  /* In strict_order mode, always try servers in the order 
 specified in resolv.conf, if a domain is given 
 always try all the available servers,
 otherwise, use the one last known to work. */

I think that probably covers 80% of the use cases.

(This really needs a separate daemon that centralizes the state, so that
processes that just do one DNS query and exit can pick the right
upstream server for the query.)

>> I also think that not changing /etc/resolv.conf isn't a feasible goal
>> because that's the file applications use to locate the system DNS
>> resolver if they can't use the glibc interfaces for some reason.

> Sure. If they can't use glibc interface, they would not use nscd. That
> clearly its advantage!

Typically, they still want a reliable DNS service, and in some
deployment scenarios, that basically needs a local caching stub that
does some rudimentary form of dead-server detection.

> It does not have to implement dnssec or edns0, because getaddrinfo api
> does not include such flags. If clients needs advanced usage, unlike
> systemd-resolved, it does not stand in the way. I think this is the
> greatest advantage. Advanced uses can work around only a simple
> service without problem. They don't collide.

They still suffer from the lack of local cache.  I think the local cache
is highly beneficially and important to Fedora, so I'm excited that we
finally got one by default in Fedora 33.

>> The big one is the general cache instability:
>> 
>>   nscd: Concurrency issues with cache.
>>   
>> 
>> (Internal bug #1172792.)
> This bug reminds me bug #1740511 [1], which was very hard for me. Later,
> mlichvar discovered real reason for it. Atomic operations required
> different flags to atomic operations. ppc64le platform has different
> memory ordering than x86_64, where it worked flawlessly. It crashed
> often just on ppc64le. Our fix was to switch to memory_order_acquire,
> where integrity was enforced properly. I have seen relaxed in bug
> attached patches, would recommend checking it out.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1740511
> https://en.cppreference.com/w/c/atomic/memory_order

We had someone look at this who literally has a PhD in this area
(software transactional memory).  And yet here were are. 8-(

>> Related to DNS data, there are bunch of issues that need investigating
>> or fixing:
>> 
>>   getaddrinfo drops ipv6 V4MAPPED addresses from ncsd results
>>   
>> 
>>   Problems with nscd and systemd-resolved interactions on IPv6 network.
>>   
>> 
>>   nscd doesn't cache record containing more than one IP address.
>>   
>> 
>>   Reload nscd cache entry even if its timeout is equal to the current time
>>   
>> 
>>   hosts caching does not respect TTL, and caches old IP's
>>   

> Is there any design document about nscd?

Not really, it's necessary to reconstruct this from the implementation.

> How are interfaces to cache implemented from glibc? Is connection to
> nscd hardocoded 

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Lennart Poettering]

On Sa, 07.11.20 15:33, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> Am 05.11.20 um 12:39 schrieb Petr Menšík:
> > There is no controversy with nscd, it just caches names and nothing
> > more. I think this is its advantage. Unless there is any stronger
> > reason, I am against this change in advance.
> >
> It not only caches names, it also RANDOMIZES the requests to the dns servers
> configured, increasing the privacy of ones internet journey.

What do you mean by that? That it distributes DNS lookups between multiple,
randomly selected servers?

So if you configure 4 DNS servers then each will still get roughly
1/4th of your requests? That's still quite a lot of info.

I mean, if it would distribute it to >1000 different DNS servers this might be
interesting, but it doesn't really sound like it gives you much of
privacy benefit IRL...

Lennart

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Chris Adams:

> Once upon a time, Florian Weimer  said:
>> Fedora made the decision to promote systemd-resolved as a local DNS
>> cache.  To me, that means that we can gradually remove other DNS caches
>> from the distribution.
>
> Since when does Fedora choosing a default mean other options must be
> removed from the distribution?

What I meant: If Fedora chooses a default, it is reasonable to expect
that less effort is spent on alternatives, especially if the maintainers
for those alternatives desire to do so.

In theory, users could have been presented with a choice of different
caching options during installation, including Unbound, dnsmasq and
nscd, but that is not what was implemented, despite some concerns
regarding the readiness of systemd-resolved.  To me, this suggests that
the Fedora project does not think that having those alternatives an
option brings substantial value.  I think it's only fair if package
maintainers prioritize accordingly.

Unbound and dnsmasq clearly have alternative usage scenarios beyond a
caching DNS stub resolver, but we just don't see such alternative usage
scenarios for nscd.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Ben Cotton:

> https://fedoraproject.org/wiki/Changes/RemoveNSCD
>
> == Summary ==
> This proposal intends to replace the ''nscd'' cache for named services
> with ''systemd-resolved'' for the `hosts` database and the ''sssd''
> daemon for everything else.
>
> == Owner ==
> * Name: [[User:submachine| Arjun Shankar]]
> * Email: ar...@redhat.com
>
> == Detailed Description ==

Arjun brought this up on the musl list as well:

  

I'm not sure if there's a clear consensus there.  Obviously the core
interest lies elsewhere.  I do not know how much software deployed using
musl actually depends on nscd for enterprise name lookup integration.
(The nscd protocol is the only way musl consume these glibc services;
it does not have a similar plug-in framework.)

I do not view the musl dependency as a significant obstacle to nscd
removal.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Chris Adams]

Once upon a time, Florian Weimer  said:
> Fedora made the decision to promote systemd-resolved as a local DNS
> cache.  To me, that means that we can gradually remove other DNS caches
> from the distribution.

Since when does Fedora choosing a default mean other options must be
removed from the distribution?

> Even if systemd-resolved has issues, they still need to be fixed because
> it's the Fedora default.

And yet, it was made default and objections about issues hand-waved away
as not important use cases... I'm not holding my breath for them to be
fixed.

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

Hi Florian,

more below...

On 11/11/20 11:39 AM, Florian Weimer wrote:
> * Petr Menšík:
>>> This proposal is about nscd, not systemd-resolved.
> 
>> systemd-resolved is mentioned in the title and the body of proposal. So
>> it seems it is about it.
> 
> Fedora made the decision to promote systemd-resolved as a local DNS
> cache.  To me, that means that we can gradually remove other DNS caches
> from the distribution.
I maintain also dnsmasq and I doubt there is reason to remove it from
the distribution. I would oppose if anyone intented to do it.
> 
> Even if systemd-resolved has issues, they still need to be fixed because
> it's the Fedora default.
systemd-resolved brings more changes than were announced. Not all of
them have fixes and some were refused. I think systemd people close too
many bugs with WORKSFORME reason personally. But sure, bugs should be fixed.

On the other hand, there are a lot of use cases, where it works better
without systemd-resolved. I think we want alternatives supported
regardless what is the default. Need to say I am not happy it became
default and I would prefer it would first fix (already) known issues.
> 
>>> If Fedora chooses to adopt another local DNS cache, glibc will use that
>>> (probably using the built-in nss_dns service module) systemd-resolved is
>>> just what we have for now, so the proposal references it.  But any other
>>> DNS cache will work as well.
> 
>> I do not think there is another cache like nscd, which does not require
>> /etc/resolv.conf change or special nss hosts module. While I admit there
>> are more caches, I don't think any provides drop-in replacement.
>> Especially resolve nss plugin introduces so many (unannounced) changes,
>> I don't think it is a good alternative. Caching via dns module might be
>> more predictable even with systemd-resolved.
> 
> What do you mean by “Caching via dns module”?  nss_dns does not have any
> cache whatsoever.
What I mean is omitting resolve module. So hosts db either reads
/etc/hosts, or uses /etc/resolv.conf via /lib64/libnss_dns.so.2.
> 
> There seem to be a lot of misconceptions about what nscd does and which
> benefits it brings (see the claim about increased privacy).  So I think
> it's important to be precise here.
I expect it would only cache simple name:ip pairs, nothing more. No, I
doubt nscd can bring any additional privacy.
> 
> From my point of view, nscd is not a very satisfactory solution for DNS
> caching because it can't do DNSSEC, it can't do recursion, it can't do
> prefetching, it doesn't have a good way to detect dead servers, it can't
> inject local stub zones, and so on.
We can argue whether people need DNSSEC. Systemd-resolved cannot work
with it correctly and it actively BREAKS its usage. Just like dnsmasq,
nscd just caches and no more. It usually does not break anything. I
think it preserves most features of libnss_dns.so behaviour. No
recursion, dead servers detection or injecting local zones is required.
It is not done without the cache anyway. Dead servers detection could be
improved I think.
> 
> I also think that not changing /etc/resolv.conf isn't a feasible goal
> because that's the file applications use to locate the system DNS
> resolver if they can't use the glibc interfaces for some reason.
Sure. If they can't use glibc interface, they would not use nscd. That
clearly its advantage! It does not have to implement dnssec or edns0,
because getaddrinfo api does not include such flags. If clients needs
advanced usage, unlike systemd-resolved, it does not stand in the way. I
think this is the greatest advantage. Advanced uses can work around only
a simple service without problem. They don't collide.
> 
>>> The hosts cache in nscd is arguably the weakest part of it, so
>>> deprecating really shouldn't be controversial at all.
> 
>> If you offer alternative, which improves caching without additional
>> regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
>> can be compared to no configuration of nscd. Unlike other resolvers,
>> nscd caches only getaddrinfo calls, without ever touching outgoing DNS
>> client queries or /etc/resolv.conf modification. Is there any other
>> service able to do it?
>>
>> Are there bugs I can help fixing, especially in hosts or ahosts
>> databases?
> 
> Thanks for the offer.
> 
> The big one is the general cache instability:
> 
>   nscd: Concurrency issues with cache.
>   
> 
> (Internal bug #1172792.)
This bug reminds me bug #1740511 [1], which was very hard for me. Later,
mlichvar discovered real reason for it. Atomic operations required
different flags to atomic operations. ppc64le platform has different
memory ordering than x86_64, where it worked flawlessly. It crashed
often just on ppc64le. Our fix was to switch to memory_order_acquire,
where integrity was enforced properly. I have seen relaxed in bug
attached patches, would recommend checking it out.

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Pavel Březina]

On 11/5/20 1:58 PM, Nico Kadel-Garcia wrote:

On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  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.



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.



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


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Nico Kadel-Garcia:

> On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  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.

Have you filed a bug report?  I have seen similar reports, but I think
they were unexpected interactions with certain LDAP servers and
schemata.

(I personally do not work on sssd, though.)

> 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.

Just because it works for you doesn't mean that it's bug-free.  We know
from reviewing the source code that nscd has several problem areas that
are difficult to fix.  It may work fine under low-load situations.

I think it is more useful to focus on improving SSSD (which is already
more or less required for Windows domain integration) than maintain two
different caching solutions.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Petr Menšík:

> On 11/5/20 12:49 PM, Florian Weimer wrote:
>> * Petr Menšík:
>> 
>> 
>> nscd has more usage downstream, leading to bugs such as:
>> 
>>   
>
> I have very limited understanding of sssd principles. But I think it is
> not comparable to nscd, which you just start or stop. No other
> configuration is required.

sssd without LDAP integration should work out of the box, too, and
automatically cache /etc/passwd and other databases.  It's even smarter
about that than nscd, I think, reading the files on startup and
monitoring them for changes.

>>> 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.
>> 
>> This proposal is about nscd, not systemd-resolved.

> systemd-resolved is mentioned in the title and the body of proposal. So
> it seems it is about it.

Fedora made the decision to promote systemd-resolved as a local DNS
cache.  To me, that means that we can gradually remove other DNS caches
from the distribution.

Even if systemd-resolved has issues, they still need to be fixed because
it's the Fedora default.

>> If Fedora chooses to adopt another local DNS cache, glibc will use that
>> (probably using the built-in nss_dns service module) systemd-resolved is
>> just what we have for now, so the proposal references it.  But any other
>> DNS cache will work as well.

> I do not think there is another cache like nscd, which does not require
> /etc/resolv.conf change or special nss hosts module. While I admit there
> are more caches, I don't think any provides drop-in replacement.
> Especially resolve nss plugin introduces so many (unannounced) changes,
> I don't think it is a good alternative. Caching via dns module might be
> more predictable even with systemd-resolved.

What do you mean by “Caching via dns module”?  nss_dns does not have any
cache whatsoever.

There seem to be a lot of misconceptions about what nscd does and which
benefits it brings (see the claim about increased privacy).  So I think
it's important to be precise here.

From my point of view, nscd is not a very satisfactory solution for DNS
caching because it can't do DNSSEC, it can't do recursion, it can't do
prefetching, it doesn't have a good way to detect dead servers, it can't
inject local stub zones, and so on.

I also think that not changing /etc/resolv.conf isn't a feasible goal
because that's the file applications use to locate the system DNS
resolver if they can't use the glibc interfaces for some reason.

>> The hosts cache in nscd is arguably the weakest part of it, so
>> deprecating really shouldn't be controversial at all.

> If you offer alternative, which improves caching without additional
> regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
> can be compared to no configuration of nscd. Unlike other resolvers,
> nscd caches only getaddrinfo calls, without ever touching outgoing DNS
> client queries or /etc/resolv.conf modification. Is there any other
> service able to do it?
>
> Are there bugs I can help fixing, especially in hosts or ahosts
> databases?

Thanks for the offer.

The big one is the general cache instability:

  nscd: Concurrency issues with cache.
  

(Internal bug #1172792.)

Related to DNS data, there are bunch of issues that need investigating
or fixing:

  getaddrinfo drops ipv6 V4MAPPED addresses from ncsd results
  

  Problems with nscd and systemd-resolved interactions on IPv6 network.
  

  nscd doesn't cache record containing more than one IP address.
  

  Reload nscd cache entry even if its timeout is equal to the current time
  

  hosts caching does not respect TTL, and caches old IP's
  

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Marius Schwarz:

> Am 05.11.20 um 12:39 schrieb Petr Menšík:
>> There is no controversy with nscd, it just caches names and nothing
>> more. I think this is its advantage. Unless there is any stronger
>> reason, I am against this change in advance.

> It not only caches names, it also RANDOMIZES the requests to the dns
> servers configured, increasing the privacy of ones internet journey.

nscd?  I don't think it does anything like that.  It doesn't even have
its own DNS code, it uses the same code that would you get as an
in-process library in your application.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

Hi Marius,

If you want to randomize requests to different servers, please try
stubby package. I think it should offer best anonymity available.

It is not true nscd is the only one. I think unbound at least randomizes
queries, but I admit it is not configured via /etc/resolv.conf. With
I think both dnsmasq and systemd-resolved does not keep strict ordering,
which selects random server. But sure, it does not usually spread like
option random in resolv.conf.

I would suggest local unbound with qname-minimisation: yes. It is fedora
default. I think it would also spread the usage, but would have to
verify it.

Cheers,
Petr

On 11/7/20 3:33 PM, Marius Schwarz wrote:
> Am 05.11.20 um 12:39 schrieb Petr Menšík:
>> There is no controversy with nscd, it just caches names and nothing
>> more. I think this is its advantage. Unless there is any stronger
>> reason, I am against this change in advance.
>>
> It not only caches names, it also RANDOMIZES the requests to the dns
> servers configured, increasing the privacy of ones internet journey.
> 
> AFAIK, it's the only dnscomponent available with fedora to do so.
> Deprecating a unique component with no major bugs or flaws seems to be
> illogical.
> 
> best regards,
> Marius


-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Description: application/pgp-keys


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Marius Schwarz]

Am 05.11.20 um 12:39 schrieb Petr Menšík:

There is no controversy with nscd, it just caches names and nothing
more. I think this is its advantage. Unless there is any stronger
reason, I am against this change in advance.

It not only caches names, it also RANDOMIZES the requests to the dns 
servers configured, increasing the privacy of ones internet journey.


AFAIK, it's the only dnscomponent available with fedora to do so. 
Deprecating a unique component with no major bugs or flaws seems to be 
illogical.


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Arthur G]

"Is there a concern or known issue that will cause systemd-resolved to
not work in your setup?"
I have a ton of experience with sssd and before that samba winbind so know
the benefits and limitations of this software stack well. I'm new to
systemd-resolved but have been reading the lively Fedora threads about it
and think it could still do with some further improvements, which I'm sure
will occur in the goodness of time, but as it stands right now the argument
to jump to it isn't compelling enough for me.

nscd may be old and decrepit but it's still delivering the goods.

On Fri, 6 Nov 2020 at 03:47, Arjun Shankar  wrote:

> > Definitely happy to throw nscd out for something better that was just as
> > simple and easy to set up.
>
> > I'll leave systemd-resolved for the trail blazers.
>
> Since systemd-resolved is already on by default since Fedora 33 [1],
> the user base should be up quite a bit as users continue to upgrade.
> It's not just trail blazers any more, and it's not just easy: it's already
> set
> up.
>
> Is there a concern or known issue that will cause systemd-resolved to
> not work in your setup?
>
> [1] https://fedoraproject.org/wiki/Changes/systemd-resolved
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Arjun Shankar]

> Definitely happy to throw nscd out for something better that was just as
> simple and easy to set up.

> I'll leave systemd-resolved for the trail blazers.

Since systemd-resolved is already on by default since Fedora 33 [1],
the user base should be up quite a bit as users continue to upgrade.
It's not just trail blazers any more, and it's not just easy: it's already set
up.

Is there a concern or known issue that will cause systemd-resolved to
not work in your setup?

[1] https://fedoraproject.org/wiki/Changes/systemd-resolved
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

On 11/5/20 12:49 PM, Florian Weimer wrote:
> * Petr Menšík:
> 
> 
> nscd has more usage downstream, leading to bugs such as:
> 
>   

I have very limited understanding of sssd principles. But I think it is
not comparable to nscd, which you just start or stop. No other
configuration is required.
> 
> Most of them are private, but you should be able to view them.
Yes, I can. Linked bug references netgroup not cached, I cannot comment
it, know no additional information.
> 
>> 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.
> 
> This proposal is about nscd, not systemd-resolved.
systemd-resolved is mentioned in the title and the body of proposal. So
it seems it is about it.
> 
> If Fedora chooses to adopt another local DNS cache, glibc will use that
> (probably using the built-in nss_dns service module) systemd-resolved is
> just what we have for now, so the proposal references it.  But any other
> DNS cache will work as well.
I do not think there is another cache like nscd, which does not require
/etc/resolv.conf change or special nss hosts module. While I admit there
are more caches, I don't think any provides drop-in replacement.
Especially resolve nss plugin introduces so many (unannounced) changes,
I don't think it is a good alternative. Caching via dns module might be
more predictable even with systemd-resolved.
> 
> The hosts cache in nscd is arguably the weakest part of it, so
> deprecating really shouldn't be controversial at all.
If you offer alternative, which improves caching without additional
regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
can be compared to no configuration of nscd. Unlike other resolvers,
nscd caches only getaddrinfo calls, without ever touching outgoing DNS
client queries or /etc/resolv.conf modification. Is there any other
service able to do it?

Are there bugs I can help fixing, especially in hosts or ahosts databases?

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Description: application/pgp-keys


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Nico Kadel-Garcia]

On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  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.

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
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.

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Arthur G]

"the system administrator will need to install and configure
sssd to replace it after the update. Even when this is not done, the
only visible affect will be slower resolution of named service queries
due to a missing cache."

I use nscd on a few application servers that point to unreliable DNS
servers that we have no control over (thanks to our Microsofties) and find
caching only the positive responses smooths things out very well.

>From the day ncsd was created it has always been easy to set up and always
had funny execution quirks. My nscd implementation occasionally bloats to
600Mb of memory usage just on host caching but fortunately nscd has an auto
restart feature which I've set to run daily to cure this.

Definitely happy to throw nscd out for something better that was just as
simple and easy to set up. Unfortunately sssd is quite sophisticated and
therefore complex, and does caching secondary from its main purpose which
seems overkill if that was the only reason for running it. I'll leave
systemd-resolved for the trail blazers.

I'd still like to see nscd continue to be available but wholeheartedly
agree it's showing its age.



On Thu, 5 Nov 2020 at 22:49, Florian Weimer  wrote:

> * Petr Menšík:
>
> > 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].
> >
> > There is no controversy with nscd, it just caches names and nothing
> > more. I think this is its advantage. Unless there is any stronger
> > reason, I am against this change in advance.
> >
> > If serious bugs are in NSCD, please fill bugs on the component.
>
> nscd has more usage downstream, leading to bugs such as:
>
>   
>
> Most of them are private, but you should be able to view them.
>
> > 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.
>
> This proposal is about nscd, not systemd-resolved.
>
> If Fedora chooses to adopt another local DNS cache, glibc will use that
> (probably using the built-in nss_dns service module) systemd-resolved is
> just what we have for now, so the proposal references it.  But any other
> DNS cache will work as well.
>
> The hosts cache in nscd is arguably the weakest part of it, so
> deprecating really shouldn't be controversial at all.
>
> Thanks,
> Florian
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
> O'Neill
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Petr Menšík:

> 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].
>
> There is no controversy with nscd, it just caches names and nothing
> more. I think this is its advantage. Unless there is any stronger
> reason, I am against this change in advance.
>
> If serious bugs are in NSCD, please fill bugs on the component.

nscd has more usage downstream, leading to bugs such as:

  

Most of them are private, but you should be able to view them.

> 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.

This proposal is about nscd, not systemd-resolved.

If Fedora chooses to adopt another local DNS cache, glibc will use that
(probably using the built-in nss_dns service module) systemd-resolved is
just what we have for now, so the proposal references it.  But any other
DNS cache will work as well.

The hosts cache in nscd is arguably the weakest part of it, so
deprecating really shouldn't be controversial at all.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

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].

There is no controversy with nscd, it just caches names and nothing
more. I think this is its advantage. Unless there is any stronger
reason, I am against this change in advance.

If serious bugs are in NSCD, please fill bugs on the component.

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.

I don't see any advantage to have systemd-resolved in a container. I
suggest removing systemd-resolved instead from minimal installation. I
don't think nscd is mandatory there too.

There has been no change in bug #1879028, which received exception to
F33. I would hope there would be work-in-progress on some upstream
branch, but doubt it. Until systemd upstream fixes all relevant bugs,
please avoid its tighter integration into the system.

Thank you.

1.
https://lists.dns-oarc.net/pipermail/dns-operations/2020-November/020651.html
2. https://bugzilla.redhat.com/show_bug.cgi?id=1879028


On 11/4/20 7:13 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RemoveNSCD
> 
> == Summary ==
> This proposal intends to replace the ''nscd'' cache for named services
> with ''systemd-resolved'' for the `hosts` database and the ''sssd''
> daemon for everything else.
> 
> == Owner ==
> * Name: [[User:submachine| Arjun Shankar]]
> * Email: ar...@redhat.com
> 
> == Detailed Description ==
> 
> ''nscd'' is a daemon that provides caching for accesses of the
> `passwd`, `group`, `hosts`, `services`, and `netgroup` databases
> through standard libc interfaces (such as `getpwnam`, `getpwuid`,
> `getgrnam`, `getgrgid`, `gethostbyname`, etc.). This proposal intends
> to replace ''nscd'' in Fedora with ''systemd-resolved'' for the
> `hosts` database and the ''sssd'' daemon for everything else.
> Accordingly, the `nscd` sub-package of glibc will be removed and
> obsoleted.
> 
> == Benefit to Fedora ==
> 
> While still maintained within the glibc source tree, ''nscd'' has
> received less than forty commits in the past three years and has
> gathered significant technical debt, and has bugs which are hard to
> fix.  There are concurrency bugs in the shared mappings, cache
> unification (IPv4 vs. IPv6 vs. AF_UNSPEC) issues, and more which would
> require significant investment to fix in nscd.  Such an investment
> seems like duplicate effort among our communities given the quality
> and state of ''sssd'', and ''systemd-resolved'' which is already
> proposed to be enabled by default from [[Changes/systemd-resolved |
> Fedora 33 onwards]].
> 
> At a high level, sssd and systemd-resolved together provide a caching
> solution that has feature parity with nscd, with systemd-resolved
> covering the hosts cache and sssd the rest. The removal of nscd from
> Fedora will:
> * move the user base over to a more modern solution for named services
> caching, and
> * reduce maintenance work on the Fedora glibc package and the
> duplication of effort on nscd upstream.
> 
> 
> == Scope ==
> * Proposal owners:
> The volume of work required is minimal, with the only change being the
> removal and obsolescence of the nscd sub-package offered by glibc
> which can be achieved by minor changes to the spec file. Since nscd is
> not installed by default, the affect on the distribution is minimal.
> Users who have installed nscd in an earlier release of Fedora will
> need to install and configure sssd instead.
> 
> * Other developers: `nss-pam-ldapd` has a weak dependency on nscd that
> will need to be removed. `libuser` has a build dependency on nscd that
> will also need to be removed.
> 
> * Release engineering:
> This change does not require coordination with or have impact on
> release engineering and does not require a mass rebuild.
> 
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: Yes, this proposal aligns with the
> [https://docs.fedoraproject.org/en-US/project/objectives current
> objective] of "Fedora Minimization".
> 
> == Upgrade/compatibility impact ==
> N/A (not a System Wide Change)
> 
> == User Experience ==
> * Most users will be unaffected by this change because nscd is not
> installed by default. It is usually used on systems configured with
> LDAP, where nscd provides caching of remote queries.
> * On a system using nscd that is updated to Fedora 34 from a previous
> version, the system 

Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RemoveNSCD

== Summary ==
This proposal intends to replace the ''nscd'' cache for named services
with ''systemd-resolved'' for the `hosts` database and the ''sssd''
daemon for everything else.

== Owner ==
* Name: [[User:submachine| Arjun Shankar]]
* Email: ar...@redhat.com

== Detailed Description ==

''nscd'' is a daemon that provides caching for accesses of the
`passwd`, `group`, `hosts`, `services`, and `netgroup` databases
through standard libc interfaces (such as `getpwnam`, `getpwuid`,
`getgrnam`, `getgrgid`, `gethostbyname`, etc.). This proposal intends
to replace ''nscd'' in Fedora with ''systemd-resolved'' for the
`hosts` database and the ''sssd'' daemon for everything else.
Accordingly, the `nscd` sub-package of glibc will be removed and
obsoleted.

== Benefit to Fedora ==

While still maintained within the glibc source tree, ''nscd'' has
received less than forty commits in the past three years and has
gathered significant technical debt, and has bugs which are hard to
fix.  There are concurrency bugs in the shared mappings, cache
unification (IPv4 vs. IPv6 vs. AF_UNSPEC) issues, and more which would
require significant investment to fix in nscd.  Such an investment
seems like duplicate effort among our communities given the quality
and state of ''sssd'', and ''systemd-resolved'' which is already
proposed to be enabled by default from [[Changes/systemd-resolved |
Fedora 33 onwards]].

At a high level, sssd and systemd-resolved together provide a caching
solution that has feature parity with nscd, with systemd-resolved
covering the hosts cache and sssd the rest. The removal of nscd from
Fedora will:
* move the user base over to a more modern solution for named services
caching, and
* reduce maintenance work on the Fedora glibc package and the
duplication of effort on nscd upstream.


== Scope ==
* Proposal owners:
The volume of work required is minimal, with the only change being the
removal and obsolescence of the nscd sub-package offered by glibc
which can be achieved by minor changes to the spec file. Since nscd is
not installed by default, the affect on the distribution is minimal.
Users who have installed nscd in an earlier release of Fedora will
need to install and configure sssd instead.

* Other developers: `nss-pam-ldapd` has a weak dependency on nscd that
will need to be removed. `libuser` has a build dependency on nscd that
will also need to be removed.

* Release engineering:
This change does not require coordination with or have impact on
release engineering and does not require a mass rebuild.

* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Yes, this proposal aligns with the
[https://docs.fedoraproject.org/en-US/project/objectives current
objective] of "Fedora Minimization".

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== User Experience ==
* Most users will be unaffected by this change because nscd is not
installed by default. It is usually used on systems configured with
LDAP, where nscd provides caching of remote queries.
* On a system using nscd that is updated to Fedora 34 from a previous
version, the system administrator will need to install and configure
sssd to replace it after the update. Even when this is not done, the
only visible affect will be slower resolution of named service queries
due to a missing cache.
* Users on a system running sssd and systemd-resolved instead of nscd
shouldn't see any noticeable difference in system behaviour or latency
in resolving named services.

== Dependencies ==
* `nss-pam-ldapd` has a weak dependency on nscd that will need to be removed.
* `libuser` has a build dependency on nscd that will also need to be removed.

Both changes are minimal, requiring a removal of the dependency in the
spec file, and a rebuild.

== Contingency Plan ==
* Contingency mechanism: Revert changes to glibc spec file and
continue to ship nscd. Revert changes to libuser and nss-pam-ldapd
packages; this will need to be done by the respective package
maintainers.
* Contingency deadline: Fedora 34 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? None

== Documentation ==
N/A (not a System Wide Change)

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
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-announce@lists.fedoraproject.org

Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RemoveNSCD

== Summary ==
This proposal intends to replace the ''nscd'' cache for named services
with ''systemd-resolved'' for the `hosts` database and the ''sssd''
daemon for everything else.

== Owner ==
* Name: [[User:submachine| Arjun Shankar]]
* Email: ar...@redhat.com

== Detailed Description ==

''nscd'' is a daemon that provides caching for accesses of the
`passwd`, `group`, `hosts`, `services`, and `netgroup` databases
through standard libc interfaces (such as `getpwnam`, `getpwuid`,
`getgrnam`, `getgrgid`, `gethostbyname`, etc.). This proposal intends
to replace ''nscd'' in Fedora with ''systemd-resolved'' for the
`hosts` database and the ''sssd'' daemon for everything else.
Accordingly, the `nscd` sub-package of glibc will be removed and
obsoleted.

== Benefit to Fedora ==

While still maintained within the glibc source tree, ''nscd'' has
received less than forty commits in the past three years and has
gathered significant technical debt, and has bugs which are hard to
fix.  There are concurrency bugs in the shared mappings, cache
unification (IPv4 vs. IPv6 vs. AF_UNSPEC) issues, and more which would
require significant investment to fix in nscd.  Such an investment
seems like duplicate effort among our communities given the quality
and state of ''sssd'', and ''systemd-resolved'' which is already
proposed to be enabled by default from [[Changes/systemd-resolved |
Fedora 33 onwards]].

At a high level, sssd and systemd-resolved together provide a caching
solution that has feature parity with nscd, with systemd-resolved
covering the hosts cache and sssd the rest. The removal of nscd from
Fedora will:
* move the user base over to a more modern solution for named services
caching, and
* reduce maintenance work on the Fedora glibc package and the
duplication of effort on nscd upstream.


== Scope ==
* Proposal owners:
The volume of work required is minimal, with the only change being the
removal and obsolescence of the nscd sub-package offered by glibc
which can be achieved by minor changes to the spec file. Since nscd is
not installed by default, the affect on the distribution is minimal.
Users who have installed nscd in an earlier release of Fedora will
need to install and configure sssd instead.

* Other developers: `nss-pam-ldapd` has a weak dependency on nscd that
will need to be removed. `libuser` has a build dependency on nscd that
will also need to be removed.

* Release engineering:
This change does not require coordination with or have impact on
release engineering and does not require a mass rebuild.

* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Yes, this proposal aligns with the
[https://docs.fedoraproject.org/en-US/project/objectives current
objective] of "Fedora Minimization".

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== User Experience ==
* Most users will be unaffected by this change because nscd is not
installed by default. It is usually used on systems configured with
LDAP, where nscd provides caching of remote queries.
* On a system using nscd that is updated to Fedora 34 from a previous
version, the system administrator will need to install and configure
sssd to replace it after the update. Even when this is not done, the
only visible affect will be slower resolution of named service queries
due to a missing cache.
* Users on a system running sssd and systemd-resolved instead of nscd
shouldn't see any noticeable difference in system behaviour or latency
in resolving named services.

== Dependencies ==
* `nss-pam-ldapd` has a weak dependency on nscd that will need to be removed.
* `libuser` has a build dependency on nscd that will also need to be removed.

Both changes are minimal, requiring a removal of the dependency in the
spec file, and a rebuild.

== Contingency Plan ==
* Contingency mechanism: Revert changes to glibc spec file and
continue to ship nscd. Revert changes to libuser and nss-pam-ldapd
packages; this will need to be done by the respective package
maintainers.
* Contingency deadline: Fedora 34 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? None

== Documentation ==
N/A (not a System Wide Change)

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org