[Bug nscd/2132] New: Use nscd to support disconnected LDAP operation

I am interested in allowing laptop users to integrate into an
LDAP/Kerberos network but retain the ability to operate away from their
network.  When connected, LDAP will provide NSS data and authentication
will be performed using kerberos.  When disconnected, information will
somehow be cached locally on the laptop.  This seems to be an important
feature and is generally expected in many environments.

Some time ago I ran across the pam_ccreds PAM module[1].  This module
caches authentication tokens locally and works well.  Fedora provides
a pam_ccreds package.

On the other hand, caching NSS data does not yet seem to be solved.
This means that, for example, UID's will not be resolved to usernames
when an LDAP server is unavailable.  There are currently two options
that people claim are not optimal:

1.  nss_updatedb[2] maintains a local cache of user and group information.
Several individuals have claimed that this solution is not feasible for
very large installations.

2.  nscd, a solution within glibc, caches NSS data as it is requested.
There is not massive transfer of NSS data involved.  However, in order
for nscd to support disconnected operation, its TTL must be set to a
long period.  This has the disadvantage that network information will
not be updated on the client even if it changes.

Given option two, nscd, is it possible to a second TTL to the daemon?  One
(small) TTL will be used when the daemon can communicate with the LDAP server.
The other (large) TTL will be used when the LDAP server is not available (laptop
away from network.)  Nscd would maintain some sort of heartbeat with the LDAP
server to determine which TTL to use.

Is this feasible, given nscd's architecture?

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145044 for
more discussion.  Also, see
https://www.redhat.com/archives/fedora-devel-list/2006-January/msg00230.html, as
 a similar query was made on the fedora-devel mailing list.

[1] http://www.padl.com/OSS/pam_ccreds.html
[2] http://www.padl.com/OSS/nss_updatedb.html

--
           Summary: Use nscd to support disconnected LDAP operation
           Product: glibc
           Version: 2.3.6
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: nscd
        AssignedTo: drepper at redhat dot com
        ReportedBy: redhat at flyn dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From drepper at redhat dot com  2006-01-09 23:41 -------
nscd already caches entries and gives them out if the services are not available.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From redhat at flyn dot org  2006-01-10 01:39 -------
Right.  However, imagine I set my cache TTL to 30 days.  This will allow me to
operate my laptop away from my LDAP server for 30 days.  However, if I do
connect my laptop to the LDAP server it will continue to use cached data.  So if
the network administrator changes some NSS data, this change will not propagate
to my laptop until my 30 TTL expires, even if I connect my laptop to the network
before then.

This is why I am wondering if two TTL's would be more appropriate.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From drepper at redhat dot com  2006-01-10 03:02 -------
This is what the reload-count value is for.  Stop reopening bugs.  This is no
place to get free support for your non-existing knowledge.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From redhat at flyn dot org  2006-02-12 15:24 -------
With all due respect, I am not trying "to get free support for [my] non-
existing knowledge."  Everyone I have talked to has said that the feature I am
speaking about does not yet exist.  This is why I made this entry in
Bugzilla.  Also, I never claimed this to be a bug -- it is a feature request
and has always been classified as such.

In my defense, the "reload-count" feature was not documented.  Though
the "reload-count" parameter is not what I am looking for, I properly reported
this (see  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177368) and
now it is fixed in Fedora Raw Hide's man-pages package.  So I am here to help,
and would appreciate the respect I am due.

The ability to cache NSS data so that laptops may operate for an extended
period of time away from their LDAP server is an important feature that is not
yet satisfactorily present in Linux-based systems.  Several people (including
some who are employed by Red Hat like Ulrich) believe that nscd is the correct
place to address this deficiency.  After looking at a few options (see
original comment), I also hold this opinion.

So, I would like to ask that this feature request remains open until:

1.  Someone presents a better alternative after demonstrating why nscd is not
the proper place to address this issue.

- or -

2.  Nscd supports this feature.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From drepper at redhat dot com  2007-02-18 04:49 -------
I have explained before that the reload-count value is exactly for the purpose
you need it for.  It's not my fault that nobody you talk to has any clue and
tells you the functionality is not provided.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From costinel at gmail dot com  2007-04-05 15:10 -------
Created an attachment (id=1669)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1669&action=view)
log describing nscd behaviour

here is an example of "reload-count" option set to "unlimited" but entries are
not kept in cache. note that during initial soft reconnection the data is still
cached (command issued at 16:48:18) but after the hard reconnect (at 16:49:06)
"id" returns no such user.

please reopen this bug

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From costinel at gmail dot com  2007-04-05 15:25 -------
(In reply to comment #6)
> Created an attachment (id=1669)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1669&action=view)
> log describing nscd behaviour
>
> here is an example of "reload-count" option set to "unlimited" but entries are
> not kept in cache. note that during initial soft reconnection the data is still
> cached (command issued at 16:48:18) but after the hard reconnect (at 16:49:06)
> "id" returns no such user.
>
> please reopen this bug

forgot to mention that the log is from a rhel 4.4 box

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From brian at interlinx dot bc dot ca  2009-10-22 03:33 -------
(In reply to comment #5)
> I have explained before that the reload-count value is exactly for the purpose
> you need it for.  It's not my fault that nobody you talk to has any clue and
> tells you the functionality is not provided.

How about the log (http://sourceware.org/bugzilla/attachment.cgi?id=1669) in
which Costin demonstrates that it just doesn't work as you describe it?

I also found myself without my account in my local cache today on my
disconnected laptop and I have reload-count set to unlimited as well.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From brian at interlinx dot bc dot ca  2009-10-24 14:22 -------
So, it would seem, as I learned in a discussion elsewhere, that what is making
this caching-indefinitely-while-disconnected work, per attachment 1669 is that
entries that are cached will be dropped if they are not accessed at all within
their TTL, regardless of the value of reload-count.

Is this true?  Does this behavior seem correct?

I'm going to reopen this bug to see if we can get a discussion going.  I hope
that doesn't offend anyone.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From brian at interlinx dot bc dot ca  2009-10-24 15:06 -------
(In reply to comment #9)
>
> entries that are cached will be dropped if they are not accessed at all within
> their TTL, regardless of the value of reload-count.

Having given this some thought, I wonder if the scenario is this...

While connected to the server, there are two ways that the cache entry is kept
"fresh".  One is by access to the cache from applications and the other is that
in the absence of applications causing the freshness "stamp" to be updated, is
that "reloads" update the stamp.

Now when the machine is disconnected from the server, reloads won't be
successful any more, causing the second case above to not to happen and all that
is left trying to keep entries fresh is application access.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From drepper at redhat dot com  2009-10-25 22:51 -------
Stop reopneing bugs.  This is no place to ask questions.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From dqarras at yahoo dot com  2009-10-26 20:09 -------
As mentioned above reload-count should fulfill this purpose but according to

https://bugzilla.redhat.com/show_bug.cgi?id=488597

its functionality seems to be buggy at the moment.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From howard at cohtech dot com  2009-10-27 13:58 -------
I suspect that the real cause of the problems described below are in the
nss_ldap code.

I have looked into the nss_ldap code and it responds with NSS_STATUS_UNAVAIL,
errno = EPERM for the following cases.

LDAP_SERVER_DOWN, LDAP_TIMEOUT, LDAP_UNAVAILABLE, LDAP_BUSY,
LDAP_CONNECT_ERROR, LDAP_LOCAL_ERROR, LDAP_INVALID_CREDENTIALS.

The last 2 are, I suspect, correct but the first 5 are really candidates
for 'server has gone away'. I suspect, but can't quite decide whether I am
right, that the code should respond with NSS_STATUS_TRYAGAIN, errno = EAGAIN
for the cache to continue to be populated with the entry.

If anybody who understands the nsswitch internals can confirm which is the
correct response I will patch the nss_ldap library (I have half a patch
already) and try this out.


--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

------- Additional Comments From arthur at arthurdejong dot org  2009-11-01 14:49 -------
According to http://www.gnu.org/software/libc/manual/html_node/NSS-Modules-Interface.html there
are four error conditions that can be returned by an NSS module:

NSS_STATUS_TRYAGAIN+EAGAIN
NSS_STATUS_TRYAGAIN+ERANGE
NSS_STATUS_UNAVAIL+ENOENT
NSS_STATUS_NOTFOUND+ENOENT

Is it really correct for an NSS module to return NSS_STATUS_TRYAGAIN+EAGAIN when the LDAP server
is unavailable or would NSS_STATUS_UNAVAIL+EAGAIN be better (or perhaps something else)?

Wouln't it be better if nscd only enters data in the cache on NSS_STATUS_SUCCESS and
NSS_STATUS_NOTFOUND? (that should also solve this problem and probably be more consistent)

--


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dqarras at yahoo dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=2132

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.