Jul 022015
 

NetworkIt seems that two months after the last maintenance in May another one needs to be done on 2015-07-08 around 00:00 AM – 06:00 AM UTC+1. Again this means that all XIN.at services may see some downtime during this period, this weblog included. So no eMail server, no web server, no anything. By trend these maintenances tend to put me offline for short periods of time only, but who knows what UPCs gonna do. Just so you know.

Aug 012013
 

Tux-troll logoRecently, I was supposed to do a simple change on a set of users stored in a central OpenLDAP database on Linux. That central database holds all user-related data like user names, hashed passwords, home directory locations etc. After the changes were made, I noticed that the client machines which were authenticating against LDAP via pam hadn’t gotten any wind of the new settings. And they reason was, that the old settings were cached locally on each client machine, by a facility called NSCD or the name service caching daemon, which does cache different kinds of data, like hostname to IP resolutions, group memberships of users or directly user-specific stuff like a users login shell or home directory location.

Problem is, that NSCD is watching certain local configuration files on the client machines to determine whether the cache is clean or whether it should be flushed and rebuilt. For user metadata it watches /etc/passwd.  If your user metadata is stored elsewhere as defined by /etc/nsswitch.conf, this will make the cache dirty as soon as something changes.

Now, in case you do not know about NSCD already, you might think a simple restart of the daemon might work, something like /etc/init.d/nscd restart? Nah, that won’t do it, as the cache sits in files that are kept, even if NSCD is shut down. After that shutdown, you’ll get the correct information as there is no live cache. Start NSCD again, and you’ll get the old and invalid data just like before.

NSCD does have a way of quickly and easily flushing each cache independently though. First, have a look at what caches your system has. For that, just list the files present in /var/db/nscd. In my case this reveals the following:

[gat@localhorst ~]$ ls /var/db/nscd
group  hosts  passwd  services

So, there is a cache for groups, hostnames, user-related metadata (“passwd”) and services, each one will hold cached data that will be accessed automatically by certain system calls like getpwnam(), getgrnam() or getaddrinfo() and many more. To flush say the passwd one, just invoke nscd directly like that:

nscd --invalidate=passwd

Or, in short form:

nscd -i passwd

And done! If you’d like to change NSCDs behaviour by the way, like say you’d want to disable a specific cache or change the time-to-live settings, have a look at /etc/nscd.conf. If you’d like to invalidate all caches at once, NSCD doesn’t offer an option for that, but it’s relatively easy in case you ever need that:

for k in /var/db/nscd/*; do nscd -i `basename $k`; done

You could also just switch it off of course, but that will make certain things slower and increase network traffic. So usually a cache is a good idea. Just keep in mind that sometimes you’ll need to invalidate it manually if you’re using non-“standard” name services and where waiting for the TTL to run out is not an option.