#2501 F34 System-Wide Change: Remove nscd in favour of sssd and systemd-resolved
Closed: Accepted 2 years ago by sgallagh. Opened 2 years ago by bcotton.

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.

I don't feel like I can make an informed decision for or against this Change, since I don't understand the problem well enough and the discussion on the devil list had mixed opinions as well. ±0

I think we should wait for the discussion to proceed further on fedora-devel.
- nscd is in a separate subpackage and not enabled by default
- dropping nscd reduces the maintainance burden and immediately allows a bunch of thorny bugs to be closed
- dropping nscd does not cause any change for users who haven't opted in
- because it's a separate package, dropping nscd is not relevant for minimization efforts as the term is generally understood
- there are clearly some users of nscd, and they would need to adjust. At least some of those users will be served sufficiently by systemd-resolved.
- There might be some nscd users for whom systemd-resolved is not a good fit. I hope the discussion on fedora-devel will help clarify this.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

2 years ago

I am still trying to catch up with the discussion on devel. I don't have an idea of the number of nscd users because it's not something I often hear people talk about. So I would guess there either are not a lot of nscd users -or- they are all quiet because it works fine.

Regardless, understanding the nscd use cases and making sure there's a transition plan for them would be in order.

I did see a concern regarding musl's use of nscd. I'm not sure how much that matters for Fedora, though we do offer the musl library+toolchain.

We discussed this in today's fesco meeting (
@submachine Do you know what glibc upstream wrt. to nscd are, i.e. might it be dropped there too?
Also, would it be possible to slow the removal down a bit: in F34 deprecate the package and mark it as Provides: deprecated() and announce the intent to remove, and then only remove it in F35?

@zbyszek There is currently no discussion upstream regarding possibly dropping nscd.

In Fedora, yes, deprecating in F34 and announcing the intent to remove is possible and okay with us.

@submachine Could you please update the change proposal to include that?

(Also, procedural -1 from me to prevent automatic approval.)

Metadata Update from @churchyard:
- Issue untagged with: meeting

2 years ago

@submachine Please update the proposal so we can vote on it.

+1 for updated proposal. Thanks.

  • AGREED: Deprecation of nscd is approved for F34, removal of nscd is approved for F35 (+6, 0, -0) (sgallagh, 15:27:11)
  • ACTION: arjun will split the Change proposal for F34 and F35 and update the FESCo ticket with the new links. (sgallagh, 15:27:48)

Metadata Update from @sgallagh:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @bcotton:
- Issue untagged with: F34
- Issue set to the milestone: Fedora 34

2 years ago

@submachine I will wait to process this change until you've made the necessary edits to the page to split into deprecation and removal steps.

I have edited the RemoveNSCD page back to describe removal (now in Fedora 35):

I have created a new page DeprecateNSCD, to track deprecation in Fedora 34:


LGTM. I edited the page for F35 to also include dropping support for nscd in systemd.

Thanks for the edit, and for submitting the systemd pull request.

Login to comment on this ticket.