Nscd - man page but no software

I have a man page installed for nscd. However, I have search the forums, bundles, and individual packages for the software but have so far been unable to locate it. Does Clear Linux use a different nameservice caching package?

I have a man page installed for nscd. However, I have search the forums, bundles, and individual packages for the software but have so far been unable to locate it. Does Clear Linux use a different nameservice caching package?

CL installed the man pages from:
https://www.kernel.org/pub/linux/docs/man-pages/man-pages-5.01.tar.xz

This package provide:

/usr/share/man/man5/nscd.conf.5
/usr/share/man/man8/nscd.8

That’s why you see it at man pages.

You can try dnsmaq which is included in dhcp-server bundle

I am looking for caching for authentication credentials. I did find SSSD in the list of packages, although no bundle supplies it yet.

Which brings up the question… why are there packages that are not in a bundle?
Are they packages still under development? Are there changes coming to these services that these packages will become a part of?

Authconfig is a package that is available and needed by myself but not found in any bundle… however a search returns this string:

$ sudo swupd search authconfig
Component authconfig has version 7.0.1

What does this mean? If I do a filesystem search with locate for authconfig, no files found.

CL is adding new packages and adding to a proper bundle.

some packages are not integrated because they are a build requirements
or waiting to be added a proper bundle.

nscd was stripped from the package in the past. We currently have the tools to add it back but keep it out of glibc since we didn’t want it to be part of every build for size/resource reasons. Maybe we can do something like that again so for the few users that have a valid need for it… it would be available.

I would like to bundle krb5, sssd, nss_pam_ldapd, and authconfig which are needed for a FreeIPA client. Is it possible to make a bundle with those packages without resorting to making a new MIX? I would prefer to not be responsible for updates, especially when CL maintains the needed packages.

A more generic LDAP client bundle without sssd and using ncsd instead, I think is possible. I must make it happen one way or another, the decision to move forward with CL in production has already been made.

I’ll add those to https://github.com/clearlinux/clr-bundles/blob/master/bundles/enterprise-login

1 Like

This will be wonderful, thank you very much. When might I expect to see them added?

nscd might need to be added too, if that would be possible.

In 1 or 2 days you will find it

1 Like

I have installed the updated enterprise-login bundle, thank you very much!

I think there is one more package we will want, to make this work: certmonger

“certmonger is a service which attempts to simplify interaction with certifying authorities (CAs) on networks which use public-key infrastructure (PKI).”

It will automatically renew certs before they expire to keep things moving along.

It can be found here: https://pagure.io/certmonger

It appears we will also need the systemd files for sssd.

Below is a list of files from a working CentOS/RHEL 7 FreeIPA client:
/etc/systemd/system/multi-user.target.wants/sssd.service
/usr/lib/systemd/system/sssd-autofs.service
/usr/lib/systemd/system/sssd-autofs.socket
/usr/lib/systemd/system/sssd-nss.service
/usr/lib/systemd/system/sssd-nss.socket
/usr/lib/systemd/system/sssd-pac.service
/usr/lib/systemd/system/sssd-pac.socket
/usr/lib/systemd/system/sssd-pam-priv.socket
/usr/lib/systemd/system/sssd-pam.service
/usr/lib/systemd/system/sssd-pam.socket
/usr/lib/systemd/system/sssd-secrets.service
/usr/lib/systemd/system/sssd-secrets.socket
/usr/lib/systemd/system/sssd-ssh.service
/usr/lib/systemd/system/sssd-ssh.socket
/usr/lib/systemd/system/sssd-sudo.service
/usr/lib/systemd/system/sssd-sudo.socket
/usr/lib/systemd/system/sssd.service

I have open tickets for both the addition of certmonger and the sssd systemd files.

And I should add that it appears to me that while the authconfig has been added to the enterprise-login bundle, it does not seem to run properly against CL. Modifying pam without a functioning authconfig is quite tricky. However, I can not confirm this… just that when you run it, it does not make all of the correct modifications and if you run it multiple times in succession, you get different output results.

Hmm, this is more difficult than it first appeared.

When I attempt to start sssd
$ /usr/bin/sssd -i --logger=stderr

I receive the following:dbus[1673]: arguments to dbus_server_get_address() were incorrect, assertion “server != NULL” failed in file dbus-server.c line 835.
This is normally a bug in some application using the D-Bus library.

D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

When I run with strace, I believe the following is applicable:
chown("/var/lib/sss/db/cache_{ourdomain}.com.ldb", 0, 0) = 0
chown("/var/lib/sss/db/timestamps_{ourdomain}.com.ldb", 0, 0) = 0
clock_getres(CLOCK_MONOTONIC, {tv_sec=0, tv_nsec=1}) = 0
getresuid([0], [0], [0]) = 0
getresgid([0], [0], [0]) = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 10UNIX:36049
stat("/var/lib/sss/pipes/private/sbus-monitor", 0x7ffec994ec30) = -1 ENOENT (No such file or directory)
bind(10UNIX:36049, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/private/sbus-monitor"}, 41) = -1 ENOENT (No such file or directory)
close(10UNIX:36049) = 0
getpid() = 1621
write(2</dev/pts/0<char 136:0>>, "dbus[1621]: ", 12dbus[1621]: ) = 12
write(2</dev/pts/0<char 136:0>>, “arguments to dbus_server_get_add”…, 189arguments to dbus_server_get_address() were incorrect, assertion “server != NULL” failed in file dbus-server.c line 835.

Note: the “{ourdomain}” is my edit to obfuscate our domain.