Package: nscd Version: 2.3.6.ds1-13 According to documentation on how to set up Linux laptops for disconnected operations with LDAP and Kerberos, one key configuration setting to update is the nscd caching time. The other part is using libpam_ccreds to cache the user password for disconnected authentication. See <URL: http://www.flyn.org/laptopldap/laptopldap.html >, <URL: http://fedoraproject.org/wiki/Features/DisconnectedOperation > and <URL: http://www.builderau.com.au/program/linux/soa/Authentication-caching-with-nscd/0,339028299,339285682,00.htm> for background information. The default TTL for NSS entries is 1 hour at the moment, while it need to be a lot more for this to work with disconnected operations. I would like to be able to configure this automatically at install time for Debian Edu, and I see two obvious approaches to do this in a policy compliant way. The issue here is that /etc/nscd.conf is a conffile, and policy require that any editing need to be done by the nscd package. One approach would be to change the default configuration in /etc/nscd.conf to use a longer timeout for the cache values. For example these values to get 30 days timeout: positive-time-to-live passwd 2592000 positive-time-to-live group 2592000 positive-time-to-live hosts 2592000 An alternative is to make it possible to switch to a different nscd.conf file at install time, by changing /etc/init.d/nscd to allow a configuration option to be provided in a non-conffile we can provide in Debian Edu (for example by reading a list of extra options to use from /etc/default/nscd and not include that file in the nscd package). This way we could add that file with content like OPTIONS="-f /etc/nscd.conf-debian-edu" and provide the longer timeout values in this file. Happy hacking,
[Petter Reinholdtsen] Another approach is to set the reload-count value to 'unlimited'. I am not sure if this should be done in addition to or just instead of increasing the ttl values. Until it is well known how to configure laptops for disconnected operation, I suspect it is best to provide a simple way to replace nscd.conf instead of changing the default values. Happy hacking,
found 485282 2.10.2-6 tag 485282 + patch user debian-edu@lists.debian.org usertags 485282 + debian-edu As described earlier, for nscd to work properly with laptops using a remote directory service like LDAP, the nscd cache values need to be tuned a bit. Based on the recipe available from <URL:http://www.flyn.org/laptopldap/>, it is possible to configure nscd to work while offline by allowing it to cache values longer, and to not require a reload when a value has been used for a few times. To allow disconnected operations to be working out of the box in Debian by installing the libpam-ccreds and nscd packages, I propose to apply this change to the default nscd.conf settings. The positive-time-to-live value is 30 days in seconds.--- a/nscd.conf +++ b/nscd.conf @@ -36,12 +36,12 @@ # server-user nobody # stat-user somebody debug-level 0 -# reload-count 5 + reload-count unlimited paranoia no # restart-interval 3600 enable-cache passwd yes - positive-time-to-live passwd 600 + positive-time-to-live passwd 2592000 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes @@ -51,7 +51,7 @@ auto-propagate passwd yes enable-cache group yes - positive-time-to-live group 3600 + positive-time-to-live group 2592000 negative-time-to-live group 60 suggested-size group 211 check-files group yes @@ -72,7 +72,7 @@ max-db-size hosts 33554432 enable-cache services yes - positive-time-to-live services 28800 + positive-time-to-live services 2592000 negative-time-to-live services 20 suggested-size services 211 check-files services yes Happy hacking, -- Petter Reinholdtsen
Is the danger of the cache being 30 days out-of-date not a worry in practice?
[Clint Adams] It depends, I guess. I suspect those worring about that will just deinstall nscd to avoid it. The most worrying part for a roaming laptop is the fact that entries in the cache disappear after a while. When one is on a reseach trip for several weeks, one do not want to be locked out of ones laptop because the cache was purged. How often will the cache content be verified with the default and the 30 day time-to-live? I would like the content to be verified when the laptop is able to connect to LDAP, and never disappears when the laptop is unable to connect to LDAP. I do not understand all aspects of the setting for roaming laptops, so I very much welcome input on my proposed settings, which were based on a working setup for disconnected operation. Happy hacking,
And what about the increased memory usage on large systems? I am not persuaded at all that this change is appropriate for the default configuration. I'd even say that supporting offline nscd lookups is a corner case that does not justify the possible negative effects for everybody else. What about deleted user? Deleted users still existing for 30 days could be a nasty security issue.
Great to have more feedback on this issue. :) I hope someone with knowledge and experience on offline operation of a networked laptop can share their view. :) [Marco d'Itri] What increased memory usage? I got nscd running on a laptop connected to the university of Oslo with ~60000 users and ~6000 groups, and do not see large memory usage by nscd. Well, at least here at the university, laptops are becoming the normal setup, and having offline authentication and operation work is becoming a vital requirement. :) If bugs #485282, #566718 and #568577 are solved, it would be a simple matter of installing nscd and libpam-ccreds to get it in Debian. :) You seem to be arguing only against the increased positive time to live. Is that the case? For offline operation, I suspect the "reload-count unlimited" setting is the most important one. If increased timeout is left out from the default configuration, please implement support for sourcing /etc/default/nscd and allow a policy compliant mechanism to replace the configuration file used by nscd. Happy hacking,
[Petter Reinholdtsen] Something like this would make that possible, as long as the /etc/default/nscd fil is not included in the nscd package.--- nscd.orig 2010-05-02 09:18:23.770594050 +0200 +++ nscd 2010-05-02 09:23:22.494799709 +0200 @@ -21,10 +21,15 @@ DESC="Name Service Cache Daemon" DAEMON="/usr/sbin/nscd" PIDFILE="/var/run/nscd/nscd.pid" +CONFFILE=/etc/nscd.conf +OPTIONS # Sanity checks. umask 022 -[ -f /etc/nscd.conf ] || exit 0 + +if [ -r /etc/default/nscd ]; then . /etc/default/nscd ; fi + +[ -f "$CONFFILE" ] || exit 0 [ -x "$DAEMON" ] || exit 0 [ -d /var/run/nscd ] || mkdir -p /var/run/nscd . /lib/lsb/init-functions @@ -34,7 +39,7 @@ # Return # 0 if daemon has been started or was already running # 2 if daemon could not be started - start-stop-daemon --start --quiet --pidfile "$PIDFILE" --exec "$DAEMON" || return 2 + start-stop-daemon --start --quiet --pidfile "$PIDFILE" --exec "$DAEMON" -- $OPTIONS || return 2 } stop_nscd() Happy hacking, -- Petter Reinholdtsen
I wonder if this could be handled sanely with a debconf question. Also I suspect that mimicking the behavior of other operating systems could be useful for the more generic case.
I've a very strange feeling when reading this bug report.
I'm under the impression that the proposed nscd config is something
that will more or less allow to do offline login without nscd having
being designed for that. So, I expect that nasty corner cases will
occur (deleted account being still valid for 30 days, ...)
For me, what is wanted is a local slave ldap server with all the
required protocol needed to work while (and recover after) a network
failure. Ie, a cache (nscd) should be used to cache data and get better
performances, not to take place of a broken ldap server.
If the classical ldap server is too heavy for this task (or does not have
this feature), then working on this part (a new small dedicated ldap
replicate server) is probably the better long-term solution.
Regards,
Vincent
According to the glibc developer Ulrich Drepper, nscd should be able to handle disconnected operations. See <URL: https://bugzilla.redhat.com/show_bug.cgi?id=145044 > and <URL: http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132 > for background information. An alternative solution is to get sssd into Debian, but its WNPP request (#579593) is still not acted on. Besides, I have problems getting sssd to work, but suspect that is only because I do not yet know how to configure it properly. Happy hacking,