Nabble - NSS LDAP

Re: nss_ldap-265

2009-11-06T09:56:19Z

Luke Howard a écrit :

> 265 Luke Howard <lukeh@...>
>
> * fix for BUG#132: add versioning information to binary
> * fix for BUG#403: add AM_MAINTAINER_MODE
> * fix for BUG#388: bad LDAP query for ether lookups
> * fix for BUG#391: clarify bind timelimit defaults
> in ldap.conf
> * fix for BUG#392: call do_close() if ldap_result()
> or ldap_parse_result() fails (before returning
> NSS_UNAVAIL)
> * fix for BUG#401: FreeBSD thread library check
> * fix for BUG#409: deallocate context in
> _nss_ldap_ent_context_release() to avoid bad usage
> * fix for BUG#410: don't leak file descriptors in
> _nss_ldap_readconfig

I had to use this patch to make it build, as current directory is
unlikely to be in PATH:

--- nss_ldap-265/Makefile.am 2009-11-06 11:28:08.000000000 +0100
+++ nss_ldap-265-Makefile/Makefile.am 2009-11-06 15:05:18.000000000 +0100
@@ -109,5 +109,5 @@
@$(NORMAL_UNINSTALL)

vers.c: $(top_srcdir)/CVSVersionInfo.txt
- CVSVERSIONDIR=$(top_srcdir) vers_string -v
+ CVSVERSIONDIR=$(top_srcdir) $(top_srcdir)/vers_string -v

--
BOFH excuse #20:

divide-by-zero error

nss_ldap-265

2009-11-06T02:28:55Z

265 Luke Howard <lukeh@...>

* fix for BUG#132: add versioning information to binary
* fix for BUG#403: add AM_MAINTAINER_MODE
* fix for BUG#388: bad LDAP query for ether lookups
* fix for BUG#391: clarify bind timelimit defaults
in ldap.conf
* fix for BUG#392: call do_close() if ldap_result()
or ldap_parse_result() fails (before returning
NSS_UNAVAIL)
* fix for BUG#401: FreeBSD thread library check
* fix for BUG#409: deallocate context in
_nss_ldap_ent_context_release() to avoid bad usage
* fix for BUG#410: don't leak file descriptors in
_nss_ldap_readconfig

Re: Call for nss_ov and nss-ldapd Testers

2009-11-05T07:47:35Z

On Nov 5, 2009, at 2:54 AM, stephen mulcahy wrote:

> Hi Matthew,
>
> Apologies for asking but what is nss_ov? A quick google didn't shed
> any light on it.

Not at all- maybe a little history is in order:

Those of you familiar with Arthur's work will know that the nss-ldapd
project originally consisted of a very small nss_ldap library module
that communicated with a local daemon called ldapd, which in turn
communicated with a remote LDAP server. Many instances of the nss_ldap
library communicated with a single ldapd process. The ldapd process
performed the heavy lifting, and the nss_ldap module was therefore
much smaller, simpler and faster. In addition, consolidating the LDAP
communication functions into a daemon would make it easier to develop
caching strategies and enhanced access control features.
Unfortunately, since the ldapd was and is still relatively new, these
features are yet to be developed.

Howard Chu looked at Arthur's work and realized that the OpenLDAP
server daemon, slapd, already had everything needed to implement
caching, replication, and many more desirable features, and only
needed a listener to let it interface to the new nss_ldap module. Thus
was born nss_ov, a slapd overlay that listens for requests from nss-
ldapd's nss_ldap library and turns them into the appropriate internal
slapd operations for processing. A slapd server process could now
replace the original ldap process. For it's part, slapd could be
configured as a cache server, or as a full or partial replica of
another OpenLDAP server. The replication strategy allowed for fully
disconnected operation if desired. OpenLDAP's rich access control
policies enabled the creation of many more methods of managing login
access to systems.

The work done for nss_ldap was a great step forward, but any system
using it still had need of PAM functionality to handle LDAP
authentication. Configuring pam_ldap entailed installing and managing
much of the same infrastructure needed for the original nss_ldap code,
so it actually became more difficult to configure and manage systems
using pam_ldap and the new nss_ldap/ldapd combination. Our goal was to
only have to manage a single system, so Howard developed a small
pam_ldap module that could communicate with nss_ov/slapd and added the
necessary support functions to nss_ov. When Howard submitted the new
PAM module for inclusion in the nss-ldapd project, Arthur added the
requisite functionality to the ldapd daemon to support PAM operations.

So now the nss-ldapd pam_ldap and nss_ldap libraries can be used
either with Arthur's ldapd daemon, or with the OpenLDAP Project's
slapd daemon. Each has their advantages: ldapd is relatively small and
light, but at present doesn't support caching and is relatively
untested. The slapd daemon is larger and can consume more resources,
but offers caching, replication, a richer access control model, and
many more capabilities as discussed above. The need for additional
resources is mitigated by the fact that most systems these days can
provide them, and the fact that the functionality brought by using
slapd is well worth the additional resources.

With SUUM v4, Symas is providing an integrated package that blends the
nss_ldap and pam_ldap modules from the nss-ldapd project with a
version of OpenLDAP tailored to run on a client in any of several
modes. Sample configuration files will help the new user get started
quickly.

I should also point out that new work on OpenLDAP's pcache overlay
greatly enhances the ability of a client to run in disconnected mode
with master servers other than OpenLDAP, but that's a discussion for
another time.

Cheers,

-Matt

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

>
> Thanks,
>
> -stephen
>
> --
> Stephen Mulcahy, DI2, Digital Enterprise Research Institute,
> NUI Galway, IDA Business Park, Lower Dangan, Galway, Ireland
> http://di2.deri.ie http://webstar.deri.ie http://sindice.com

Call for nss_ov and nss-ldapd Testers

2009-11-04T12:22:57Z

For those of you interested in the intersection of the excellent work
done by Arthur de Jong on nss-ldapd and Howard Chu on nss_ov, Symas is
developing an integrated package consisting of the nss_ldap and
pam_ldap libraries from nss-ldapd and the OpenLDAP server configured
with the nss_ov overlay.

The new package has been dubbed Symas Unified User Management version
4 and is available now without download restrictions. Symas will
provide complimentary technical support during the testing period.

Available platforms include Solaris and Red Hat Linux, with more
platforms becoming available as we have the opportunity to port to
them. As always, the results of our work are submitted for inclusion
upstream in the nss-ldapd and OpenLDAP projects.

The release announcement is here: http://www.symas.com/updates/?p=37.
Subscribe to this blog's RSS feed to stay abreast of new releases as
they become available.

Please direct support questions to support@.... We'll do our
best to resolve any issues as quickly as possible.

Cheers,

-Matt

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

Re: disconnected nss_ldap

2009-11-01T22:24:06Z

On Sun, 2009-11-01 at 22:19 -0500, Brian J. Murrell wrote:
>

Hrm. I spoke too soon. :-(

> Some debugging in nscd reveals that the problem lies in that the
> only error value that nscd is allowing for the "unreachable server" case
> is EAGAIN. However, in my case (at least), where I am blocking the LDAP
> server with iptables configured to send back TCP RST, the error value is
> ENOTCONN and when I tell nscd that ENOTCONN is a vaild error for the
> "unreachable" case, nscd seems to hold on to the entries it had before
> the LDAP server became unreachable.

But in testing what nscd does when the network connection is down
altogether, it would seem that __getpw{nam|uuid}_r() returns an ENOENT
(2). Which of course it not valid for the "server unreachable" clause
of nscd which simply allows the cached record to live on.

I'm not sure why that is TBH. It seems reasonable that an ENOENT is
suitable for the local, /etc/passwd entry (in absence of any other
databases), but surely when configured with nss_ldap ("passwd: compat
ldap" in /etc/nsswitch.conf), an ENOENT for a missing /etc/passwd entry
is suppressed and the return from nss_ldap is the final return for the
__getpw{nam|uuid}_r() functions, yes?

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-11-01T19:19:32Z

On Sun, 2009-11-01 at 19:59 -0500, Brian J. Murrell wrote:
>
> What can I do to help narrow this down?

OK. Some debugging in nscd reveals that the problem lies in that the
only error value that nscd is allowing for the "unreachable server" case
is EAGAIN. However, in my case (at least), where I am blocking the LDAP
server with iptables configured to send back TCP RST, the error value is
ENOTCONN and when I tell nscd that ENOTCONN is a vaild error for the
"unreachable" case, nscd seems to hold on to the entries it had before
the LDAP server became unreachable.

More time will tell for sure.

b.

signature.asc (204 bytes) Download Attachment

Re: Re: disconnected nss_ldap

2009-11-01T18:01:13Z

Brian J. Murrell wrote:

> I got it to build and install without much ado.
>
> Unfortunately, it doesn't seem to do much better than we had before.
>
> I am using an iptables rule (which sends back a TCP RST to existing and
> new connection attempts) at my ldap server to simulate disconnection.
>
> For a short while after "disconnection" "id brian" returns a result, but
> as before, not very long after disconnection it starts failing.
>
> What can I do to help narrow this down?

You're chasing a dead-end. Even if you get this aspect working, nscd still
doesn't cache enumerations, which are the most expensive nss lookup operation.
(e.g., an unqualified "getent" call). nscd is broken by design.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: disconnected nss_ldap

2009-11-01T16:59:51Z

On Sun, 2009-11-01 at 15:19 -0400, Ryan Lynch wrote:
> Not yet--i ran into some problems compiling w/ Howard's 'mega'
> patch--there are some conflicts between ./configure options that I
> don't understand. Howard hasn't gotten back to me, yet, so I'm
> probably going to have to go trial-and-error on Monday.

I got it to build and install without much ado.

Unfortunately, it doesn't seem to do much better than we had before.

I am using an iptables rule (which sends back a TCP RST to existing and
new connection attempts) at my ldap server to simulate disconnection.

For a short while after "disconnection" "id brian" returns a result, but
as before, not very long after disconnection it starts failing.

What can I do to help narrow this down?

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-11-01T11:19:51Z

Not yet--i ran into some problems compiling w/ Howard's 'mega'
patch--there are some conflicts between ./configure options that I
don't understand. Howard hasn't gotten back to me, yet, so I'm
probably going to have to go trial-and-error on Monday.

-Ryan

On 2009-11-01, Brian J. Murrell <brian@...> wrote:
> On Tue, 2009-10-27 at 22:10 -0400, Ryan Lynch wrote:
>> I'm sorry, I got busy with another project, and didn't get paste
>> making the RPMs. I'll see about it, tomorrow.
>
> Any progress there Ryan?
>
> b.
>
>

--
Ryan B. Lynch
ryan.b.lynch@...

Re: disconnected nss_ldap

2009-10-30T21:05:20Z

On Tue, 2009-10-27 at 22:10 -0400, Ryan Lynch wrote:
> I'm sorry, I got busy with another project, and didn't get paste
> making the RPMs. I'll see about it, tomorrow.

Any progress there Ryan?

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-10-27T19:10:23Z

I'm sorry, I got busy with another project, and didn't get paste
making the RPMs. I'll see about it, tomorrow.

-Ryan

On 2009-10-27, Ryan Lynch <ryan.b.lynch@...> wrote:

> On Tue, Oct 27, 2009 at 11:27, Howard Wilkinson <howard@...> wrote:
>> Ryan,
>>
>> please try this out - it applies and runs in the environment here but I
>> would not call that an exhaustive test!
>>
>> This is very much a hack - but without a complete write through the
>> ldap-nss logic is too complex to do this any other way today.
>
> I should have something back to you in a few hours.
>
> -Ryan
>

--
Ryan B. Lynch
ryan.b.lynch@...

Re: Re: Re: disconnected nss_ldap

2009-10-27T08:38:46Z

On Tue, Oct 27, 2009 at 11:27, Howard Wilkinson <howard@...> wrote:
> Ryan,
>
> please try this out - it applies and runs in the environment here but I would not call that an exhaustive test!
>
> This is very much a hack - but without a complete write through the ldap-nss logic is too complex to do this any other way today.

I should have something back to you in a few hours.

-Ryan

RE: Re: Re: disconnected nss_ldap

2009-10-27T08:27:00Z

Ryan,

please try this out - it applies and runs in the environment here but I would not call that an exhaustive test!

This is very much a hack - but without a complete write through the ldap-nss logic is too complex to do this any other way today.

Howard.

On Tue, Oct 27, 2009 at 10:35, Howard Wilkinson <howard@...> wrote:
> I am working on this now and hope to have something out today. The internals of nss_ldap are a bit of mess in this area, but I think I have a handle on it.

Fire when ready.

> This will have to go on the top of the mega patch as the original code is even worse in this area..... ;-(

That's good--I was in the process of rebuilding RPMs with your latest
mega rev when I saw your original message, so I can save a little time
testing both at once.

-Ryan

diff -ruN nss_ldap-264-save/nss_ldap-264/ldap-nss.c nss_ldap-264/nss_ldap-264/ldap-nss.c
--- nss_ldap-264-save/nss_ldap-264/ldap-nss.c 2009-10-26 11:05:50.659588000 +0000
+++ nss_ldap-264/nss_ldap-264/ldap-nss.c 2009-10-27 15:19:42.053806000 +0000
@@ -308,6 +308,11 @@
static NSS_STATUS do_map_error (int rc);

/*
+ * Map status to status and errno - handles out of buffer fudges
+ */
+static NSS_STATUS do_map_errno (NSS_STATUS status, int *errnop);
+
+/*
* support the sasl interaction
*/
static int do_sasl_interact (LDAP * ld, unsigned flags, void *defaults, void *p);
@@ -1665,7 +1670,7 @@
}
}

-void
+static void
do_init_mechs (ldap_session_t *session)
{
int i;
@@ -2523,7 +2528,7 @@
#define _APPEND_STRING(_buffer, _buflen, _s, _len) do { \
if ((_buflen) < (size_t)((_len) + 1)) \
{ \
- return NSS_TRYAGAIN; \
+ return NSS_RETURN; \
} \
memcpy((_buffer), (_s), (_len)); \
(_buffer)[(_len)] = '\0'; \
@@ -2610,7 +2615,7 @@
len = strlen (filter);

if (buflen < len + 1 /* ')' */ )
- return NSS_TRYAGAIN;
+ return NSS_RETURN;

memcpy (bufptr, filter, len);
bufptr[len] = '\0';
@@ -2619,7 +2624,7 @@
}

if (buflen < 2)
- return NSS_TRYAGAIN;
+ return NSS_RETURN;

*bufptr++ = ')';
*bufptr++ = '\0';
@@ -2705,7 +2710,7 @@
args->la_arg1.la_triple.user,
args->la_arg1.la_triple.domain,
filterBufP, filterSiz);
- if (stat == NSS_TRYAGAIN)
+ if (stat == NSS_RETURN)
{
filterBufP = *dynamicUserBuf = realloc (*dynamicUserBuf,
2 * filterSiz);
@@ -2714,7 +2719,7 @@
filterSiz *= 2;
}
}
- while (stat == NSS_TRYAGAIN);
+ while (stat == NSS_RETURN);
break;
#endif /* HAVE_NSSWITCH_H || HAVE_IRS_H */
case LA_TYPE_STRING_LIST_OR:
@@ -2724,7 +2729,7 @@
stat = do_aggregate_filter (args->la_arg1.la_string_list,
args->la_type,
filterprot, filterBufP, filterSiz);
- if (stat == NSS_TRYAGAIN)
+ if (stat == NSS_RETURN)
{
filterBufP = *dynamicUserBuf = realloc (*dynamicUserBuf,
2 * filterSiz);
@@ -2733,7 +2738,7 @@
filterSiz *= 2;
}
}
- while (stat == NSS_TRYAGAIN);
+ while (stat == NSS_RETURN);
break;
default:
return NSS_UNAVAIL;
@@ -2963,6 +2968,7 @@
int maxtries;
int hard;
int firstTime = 1;
+ int errnotmp = 0;

debug ("==> do_with_reconnect");

@@ -3116,7 +3122,7 @@
"nss_ldap: could not %s %sconnect to LDAP server - %s",
hard ? "hard" : "soft", tries ? "re" : "",
ldap_err2string (rc));
- stat = NSS_UNAVAIL;
+ /* stat = NSS_UNAVAIL; */
break;
case NSS_SUCCESS:
if (log != 0)
@@ -3148,6 +3154,8 @@

debug ("<== do_with_reconnect returns %s(%d)", __nss_ldap_status2string(stat), stat);

+ stat = do_map_errno(stat, &errnotmp);
+
return stat;
}

@@ -3273,10 +3281,10 @@
return rc;
}

-static void
+static NSS_STATUS
do_map_errno (NSS_STATUS status, int *errnop)
{
- if (status == NSS_TRYAGAIN)
+ if (status == NSS_RETURN)
{
#ifdef HAVE_NSSWITCH_H
errno = ERANGE;
@@ -3284,11 +3292,17 @@
#else
*errnop = errno = ERANGE;
#endif
+ status = NSS_TRYAGAIN;
+ }
+ else if (status == NSS_TRYAGAIN)
+ {
+ *errnop = errno = EAGAIN;
}
else
{
*errnop = 0;
}
+ return status;
}

/*
@@ -3342,7 +3356,7 @@
buffer, buflen);

/* hold onto the state if we're out of memory XXX */
- ctx->ec_state.ls_retry = (parseStat == NSS_TRYAGAIN && buffer != NULL ? 1 : 0);
+ ctx->ec_state.ls_retry = (parseStat == NSS_RETURN && buffer != NULL ? 1 : 0);

/* free entry is we're moving on */
if (ctx->ec_state.ls_retry == 0 &&
@@ -3356,7 +3370,7 @@
}
while (parseStat == NSS_NOTFOUND);

- do_map_errno (parseStat, errnop);
+ parseStat = do_map_errno (parseStat, errnop);

debug ("<== do_parse");

@@ -3408,17 +3422,17 @@
* If we do not parse the entry because of a schema
* violation, the parser should return NSS_NOTFOUND.
* We'll keep on trying subsequent entries until we
- * find one which is parseable, or exhaust avialable
+ * find one which is parseable, or exhaust available
* entries, whichever is first.
*/
parseStat = parser (e, &ctx->ec_state, result, buffer, buflen);

/* hold onto the state if we're out of memory XXX */
- ctx->ec_state.ls_retry = (parseStat == NSS_TRYAGAIN && buffer != NULL ? 1 : 0);
+ ctx->ec_state.ls_retry = (parseStat == NSS_RETURN && buffer != NULL ? 1 : 0);
}
while (parseStat == NSS_NOTFOUND);

- do_map_errno (parseStat, errnop);
+ parseStat = do_map_errno (parseStat, errnop);

debug ("<== do_parse_s");

@@ -4076,7 +4090,7 @@
if (bytesleft (buffer, buflen, char *) < (valcount + 1) * sizeof (char *))
{
ldap_value_free (vals);
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

align (buffer, buflen, char *);
@@ -4110,7 +4124,7 @@
if (buflen < (size_t) (vallen + 1))
{
ldap_value_free (vals);
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

/* copy this value into the next block of buffer space */
@@ -4156,7 +4170,7 @@
vallen = strlen (ovr);
if (*buflen < (size_t) (vallen + 1))
{
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4184,7 +4198,7 @@
vallen = strlen (def);
if (*buflen < (size_t) (vallen + 1))
{
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4207,7 +4221,7 @@
if (*buflen < (size_t) (vallen + 1))
{
ldap_value_free (vals);
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4304,7 +4318,7 @@
ldap_value_free (vals);
}
debug ("<== _nss_ldap_assign_userpassword");
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4679,6 +4693,7 @@
{
debug ("<== _nss_ldap_proxy_bind (empty password not permitted)");
/* XXX overload */
+ do_map_errno(NSS_TRYAGAIN, &rc);
return NSS_TRYAGAIN;
}

@@ -4749,6 +4764,8 @@

debug ("<== _nss_ldap_proxy_bind");

+ stat = do_map_errno(stat, &rc);
+
return stat;
}

Re: Re: Re: disconnected nss_ldap

2009-10-27T07:59:14Z

On Tue, Oct 27, 2009 at 10:35, Howard Wilkinson <howard@...> wrote:
> I am working on this now and hope to have something out today. The internals of nss_ldap are a bit of mess in this area, but I think I have a handle on it.

Fire when ready.

> This will have to go on the top of the mega patch as the original code is even worse in this area..... ;-(

That's good--I was in the process of rebuilding RPMs with your latest
mega rev when I saw your original message, so I can save a little time
testing both at once.

-Ryan

RE: Re: Re: disconnected nss_ldap

2009-10-27T07:35:31Z

Hi Ryan,

Howard,

On Tue, Oct 27, 2009 at 08:24, Howard Wilkinson <howard@...> wrote:
> 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.

I'm in a position to test patches for this, even if they're a bit
rough--I have a couple of throwaway VMs specifically intended for
this. Feel free to send anything you have, I'd love to see this issue
resolved, soon.

I am working on this now and hope to have something out today. The internals of nss_ldap are a bit of mess in this area, but I think I have a handle on it.

Also, will your patch for this issue sit on top of your "mega" patch,
or on the unpatched PADL tree?

-Ryan

This will have to go on the top of the mega patch as the original code is even worse in this area..... ;-(

Howard.

Re: Re: Re: disconnected nss_ldap

2009-10-27T07:21:28Z

Howard,

On Tue, Oct 27, 2009 at 08:24, Howard Wilkinson <howard@...> wrote:
> 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.

I'm in a position to test patches for this, even if they're a bit
rough--I have a couple of throwaway VMs specifically intended for
this. Feel free to send anything you have, I'd love to see this issue
resolved, soon.

Also, will your patch for this issue sit on top of your "mega" patch,
or on the unpatched PADL tree?

-Ryan

RE: Re: Re: disconnected nss_ldap

2009-10-27T05:24:37Z

Brian et al,

I think the problem with the nscd issue may be a bug in nss_ldap's interface with the nsswitch interface.

.......

nscd really does seem like it would complete the solution if it didn't
suffer from redhat bug 2132.

Cheers,
b.

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 either NSS_STATUS_TRYAGAIN, errno != ERANGE, or NSS_STATUS_UNAVAIL, 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.

Howard.

Re: Re: Re: how disable shadow map

2009-10-26T08:53:03Z

On Mon, 2009-10-26 at 09:50 -0500, Douglas E. Engert wrote:
> Well then set the userPassword attributes to "{crypt}NP"
> as I described on 10/21. pam_unix will not complain,

I'm not so sure of this. But as I posted to this thread a few days ago,
the real solution is to remove the shadowAccount object class from
records you don't want shadow information made available for.

b.

signature.asc (204 bytes) Download Attachment

Re: Re: Re: how disable shadow map

2009-10-26T07:50:22Z

Brian J. Murrell wrote:

> On Fri, 2009-10-23 at 20:16 -0700, Paul B. Henson wrote:
>> Sorry, I wasn't paying attention to the beginning of this thread, so I
>> don't recall what OS you're using. Linux variants of pam_unix support the
>> "broken_shadow" option:
>>
>> broken_shadow
>> Ignore errors reading shadow information for users in the
>> account management module.
>>
>> Which I think will do exactly what you want, if you're running Linux.
>
> Indeed, it does and I tested that before posting. But my distro
> (Ubuntu) maintainer reports that not having shadow map entries when the
> password is "x" is just broken (which given what I have read, I agree)
> and I tend to think they will likely refuse to use such hacks and insist
> that the breakage be fixed instead.

Well then set the userPassword attributes to "{crypt}NP"
as I described on 10/21. pam_unix will not complain,
and since you are using pam_krb5 for authentication this works
fine with our Ubuntu systems.

>
> I'm starting to feel like I'm pissing up a rope with regard to the basic
> bug here though.
>
> b.
>

--

Douglas E. Engert <DEEngert@...>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Re: Mega patch against nss_ldap 264

2009-10-25T07:12:48Z

I have revisited this code and posted some new patches to the bugzilla.
This now includes more comprehensive recovery code when the connection
to the server goes down.

I know of one outstanding issue with the group stuff, where recursion is
used to expand nested groups the recovery code fails. I intend to remove
the recursion and replace with list walking code to produce the
transitive closure needed for this function.

Anybody who is feeling brave and would like to test this out then I need
to know I have not broken any of:
1. Plain text password binds
2. Anonymous binds
3. SSL/TLS binds
4. Other LDAP backends - my major testing has been against Active
Directory, so tests against the Fedora Directory Server (389DS) and
OpenLDAP would be useful.

Furthermore, I have tested but not implemented in production the keytab
based renewal code. So if someone can hammer this it would be great.

Howard.

P.S. I think the hard/soft features in the Bind code should now function
as advertised - can somebody check this as well?

On Tue, 2008-12-09 at 22:13 +0000, Luke Howard wrote:

> Thanks Howard! I am a bit snowed under now but I really look forward
> to taking a look at this.
>
> -- Luke
>
> On 10/12/2008, at 5:30 AM, Howard Wilkinson wrote:
>
> > I have just pushed a large patch against nss_Ldap 264 up to the
> > bugzilla.
> >
> > This is a structural alteration at the source code level to ldap-
> > nss.c which is generally just changing how it reads. However, it
> > fixes some bugs in the kerberos pathways and also commons up code
> > that had multiple copies in the code source.
> >
> > I would be very grateful if anybody could try it out and let me
> know
> > what I have broken.
> >
> > My intention with this is to make the critical path through the
> code
> > run the minimal code when a connection to the LDAP server exists,
> > make recovery on failure more resilient, and provide for multiple
> > SASL mechs without need to alter the ldap-nss code.
> >
> > Comments, improvements and fault reports much appreciated.
> >
> > I am hoping that Luke will push this out as the basis for the main
> > development downstream, so that I can add the extra features on the
> > kerberos side I am looking for.
> >
> > Howard.
> >
> >
>
> --
> www.padl.com | www.fghr.net
>
>
>

--
Howard Wilkinson <howard@...>
Coherent Technology Limited

[solved] how disable shadow map

2009-10-24T07:15:34Z

On Wed, 2009-10-21 at 12:12 -0400, Brian J. Murrell wrote:
> Hi,
>
> I want to disable the shadow map, and specifically, stop the passwd map
> from returning "x" in the password field.

This is in fact quite simple to do, on a user-by-user basis even.

> I noticed from a quick browse of the code:
>
> if (_nss_ldap_oc_check (e, "shadowAccount") == NSS_SUCCESS)
> {
> /* don't include password for shadowAccount */
> if (buflen < 3)
> return NSS_TRYAGAIN;
>
> pw->pw_passwd = buffer;
> strcpy (buffer, "x");
> buffer += 2;
> buflen -= 2;
> }
> else
> {
> stat =
> _nss_ldap_assign_userpassword (e, ATM (LM_PASSWD, userPassword),
> &pw->pw_passwd, &buffer, &buflen);
> if (stat != NSS_SUCCESS)
> return stat;
> }

This above code snippet is really what led me to the solution.

One simply removes (if it exists, which it should if your passwd entry
is "x") the shadowAccount object class from the LDAP record (which your
nss_ldap is configured to map to the passwd map) for users which you
don't want shadow information available. The "x" in the password field
of the passwd entry changes to a "*" once this is done and there is no
entry in the shadow map any more.

Cheers,
b.

signature.asc (204 bytes) Download Attachment

Re: Re: Re: how disable shadow map

2009-10-24T06:18:25Z

[ Hrm. Gabor's message doesn't seem to have been copied to the list
despite being sent there. I will reply to the list in any case as that
was his intention. ]

On Sat, 2009-10-24 at 10:24 +0200, Gabor Gombas wrote:

> It seems you do not want any of the functionality of pam_unix.

Ahhh. But I do, for any accounts that might be in the local /etc/passwd
and /etc/shadow files. I just don't want it for accounts that would
come from Kerberos/LDAP.

> Then why
> do you use it?

Per above.

b.

signature.asc (204 bytes) Download Attachment

Re: Re: disconnected nss_ldap

2009-10-24T06:03:05Z

On Sat, 2009-10-24 at 03:16 -0400, Ryan Lynch wrote:
>
> nscd and the name service switch arent' supposed to handle
> authenticating users via LDAP binds.

They are not. It was the pam_unix modules "account" mode that was
refusing the access because when the password map returns an "x" in the
password field, a shadow entry must be available for pam_unix to verify
the expiry status of the password.

When you are disconnected from the LDAP server you don't have shadow
entries so pam_unix fails the "account" checks which denies login.

This is why I started the other thread about having nss_ldap not return
a "x" for the password when the shadow map is not available/desired.
Which just happens to be all of the time when you are using Kerberos.

> Authentication and authorization
> are two totally separate chains of events.

Understood, very well.

> You need to set up 'pam_ldap' and 'pam_ccreds', which will run in
> parallel with 'nscd' and 'nss_ldap(d)'.

But neither of those deals with the shadow map problem.

> nscd caches the group-to-GID
> and user-to-UID mappings, and 'pam_ccreds' caches the LDAP creds and
> bind results.

Right. And nothing caches the shadow map for pam_unix's account module,
hence the need for the "broken_shadow" hack or more properly the ability
to disable the "x" in the password field of the passwd map on
configurations that don't really need or want shadow functionality.

> I can't speak to Ubuntu-specific issues, I don't have a lot of
> experience there, but I've seen a decent number of bugs in the PADL
> suite and nscd, in the last few years. Maybe Launchpad has a ticket
> from between those two releases that explains the difference?

No, it's quite easily the bug you mentioned earlier in that something
needs to probe all cache entries at least once per TTL or they get
dropped.

> Can I suggest something? If you haven't already gotten in touch with
> someone who's using LDAP authen and authn caching (pam_ldap and
> pam_ccreds), it might be worthwhile to re-phrase that issue as a
> separate question on the list. I can show you how I do authen, but my
> bag is all Kerberos, and it sounds like you're probably headed for an
> all-LDAP setup.

No. I authenticate with Kerberos as well. And everything works just
fine for all of my clients except the disconnected ones (only when
disconnected of course), so I have everything set up as I need it. It's
just this nscd and dropping cached entries when it shouldn't be
silliness that is punching a hole in the solution.

nscd really does seem like it would complete the solution if it didn't
suffer from redhat bug 2132.

Cheers,
b.

signature.asc (204 bytes) Download Attachment

Re: Re: disconnected nss_ldap

2009-10-24T05:51:46Z

On Sat, 2009-10-24 at 03:49 -0400, Ryan Lynch wrote:
> So nscd IS caching shadow info (password hashes), for you?

As you discovered, no. I am using kerberos for authentication.

> I'm using some pretty high TTLs on disconnected machines,

The problem with high TTLs is that changes you make to your LDAP NSS
data takes too long (i.e. the TTL -- which needs to be like 30 days to
avoid dropping entries before you really want to) to get updated to the
nscd-running machines despite being connected to the LDAP server.

> There's a reason for the
> enormous TTLs, too, which it looks like you may have already
> discovered?
>
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132

Yeah. I talked about this bug in one of my previous posts here and
also, as you've probably noticed, I commented on that bug, but Mr.
Drepper seems to be simply ignoring the real-world evidence that his
proposed solution, "reload-count unlimited" just doesn't work.

> nscd drops a cached name if the TTL expires without it b eing
> requested, regardless of the 'reload-count' setting.

Yeah. So what's the point of "reload-count", then really, yes?

> To effectively
> use it for disconnected operations, you need to be reasonably certain
> that some local activity will trigger a lookup on each cached name
> more often than the TTL time.

Which is just silly.

> So basically, you have to set your TTLs
> pretty high,

And let your cached data get stale, despite having easy access to the
fresh data.

> or you need to convince Ulrich Drepper to make nscd
> smarter.

Well, bug 2132 sure doesn't give anyone any warm fuzzies that he's
actually willing to listen to how nscd works (or doesn't as the case may
be) in the real world vs. how he thinks it's suppose to operate. He is
simply ignoring the evidence that demonstrates that he's wrong.

I wonder how difficult the fix is to not drop records who's TTL expires
before they are re-requested. I can't imagine terribly so. I wonder if
he'd be more (or at all) responsive to a patch than he has been to the
presentation of evidence that his solution simply doesn't work in the
real world.

b.

signature.asc (204 bytes) Download Attachment

Re: Re: disconnected nss_ldap

2009-10-24T00:54:58Z

On Sat, Oct 24, 2009 at 03:49, Ryan Lynch <ryan.b.lynch@...> wrote:

> On Sat, Oct 24, 2009 at 02:17, Brian J. Murrell <brian@...> wrote:
>> On Sat, 2009-10-24 at 01:38 -0400, Brian J. Murrell wrote:
>>>
>>> But as soon as the LDAP server is available again, ssh to the node works
>>> just fine.
>>
>> I fixed this. This is because of pam_unix's account mode. It wants to
>> verify the shadow entry when the passwd entry contains a "x" for the
>> password -- hence my previous thread about fixing this in nss_ldap.
>> Adding broken_shadow to pam_unix's entry in the account mode works
>> around it.
>
> So nscd IS caching shadow info (password hashes), for you? I didn't
> think it would handle that, but I guess it makes sense. In that case,
> I'm not sure if there's an advantage to useing 'pam_ccreds' and
> 'pam_ldap' over nscd's shadow caching.

Wrong again--I just noticed your other thread, where you mentioned
that you're using Kerberos to authenticate. I had no idea, I thought
you were doing pure LDAP.

Re: Re: disconnected nss_ldap

2009-10-24T00:49:10Z

On Sat, Oct 24, 2009 at 02:17, Brian J. Murrell <brian@...> wrote:

> On Sat, 2009-10-24 at 01:38 -0400, Brian J. Murrell wrote:
>>
>> But as soon as the LDAP server is available again, ssh to the node works
>> just fine.
>
> I fixed this. This is because of pam_unix's account mode. It wants to
> verify the shadow entry when the passwd entry contains a "x" for the
> password -- hence my previous thread about fixing this in nss_ldap.
> Adding broken_shadow to pam_unix's entry in the account mode works
> around it.

So nscd IS caching shadow info (password hashes), for you? I didn't
think it would handle that, but I guess it makes sense. In that case,
I'm not sure if there's an advantage to useing 'pam_ccreds' and
'pam_ldap' over nscd's shadow caching.

>> Indeed. My experiments were that even with unlimited, the passwd entry
>> for the current, logged in user disappeared. I was going to demonstrate
>> on my Ubuntu Karmic laptop but I can't seem to reproduce this here.
>
> I spoke too soon/didn't wait long enough.
>
> Witness my laptop, where I am logged in (as brian), have nscd running
> with:
> reload-count unlimited
> positive-time-to-live passwd 60
>
> $ id brian
> id: brian: No such user
>
> I also have a user "keith" in my LDAP directory mapped into the NSS
> passwd map which I was testing with before when I thought it was
> working. All this to say that "keith" should definitely be in nscd's
> persistent cache as I was executing "id keith" repeatedly, watching for
> it to disappear, and now, like the "brian" entry, it has:
>
> $ id keith
> id: keith: No such user
>
> So for whatever reason, NSCD is expiring entries from it's persistent
> cache despite the "reload-count unlimited". ~sigh~

I'm using some pretty high TTLs on disconnected machines, and some
Kerberos house-keeping scripts that generally make sure nscd's cache
gets hit more often than the TTL time. There's a reason for the
enormous TTLs, too, which it looks like you may have already
discovered?

http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132

nscd drops a cached name if the TTL expires without it b eing
requested, regardless of the 'reload-count' setting. To effectively
use it for disconnected operations, you need to be reasonably certain
that some local activity will trigger a lookup on each cached name
more often than the TTL time. So basically, you have to set your TTLs
pretty high, or you need to convince Ulrich Drepper to make nscd
smarter.

-Ryan

Re: Re: disconnected nss_ldap

2009-10-24T00:16:42Z

On Sat, Oct 24, 2009 at 01:38, Brian J. Murrell <brian@...> wrote:
> On Sat, 2009-10-24 at 00:34 -0400, Ryan Lynch wrote:
>>
>> My bad, I just realized that you DID mention nscd--I need to learn to read.
>
> Yeah. :-) Oh well. Water under the bridge.

Whatever, man. Free tech support is free tech support, try to loosen
up a little, eh?

> But other than that, my experiments reveal that nss_ldap is called by
> binaries, independently of querying nscd. i.e. I try to log in while
> the LDAP server is unavailable and get scads of messages
> in /var/log/auth from nss_ldap that the ldap server is unavailable.
...
> But as soon as the LDAP server is available again, ssh to the node works
> just fine.

nscd and the name service switch arent' supposed to handle
authenticating users via LDAP binds. Authentication and authorization
are two totally separate chains of events.

You need to set up 'pam_ldap' and 'pam_ccreds', which will run in
parallel with 'nscd' and 'nss_ldap(d)'. nscd caches the group-to-GID
and user-to-UID mappings, and 'pam_ccreds' caches the LDAP creds and
bind results.

>> For example, given your desired scenario of a 10-minute cache TTL, and
>> a 30 day hard timeout, you could set:
>>
>> positive-time-to-live 600 # 10 minutes
>> reload-count 4320 # 30 days / 10 minutes
>>
>> If the cached value is more than 10 minutes old, 'nscd' will try to
>> refresh it. If it fails to connect, it will re-set the 10-minute TTL
>> and increment its reload counter by 1. This cycle repeats until the
>> reload counter reaches 4,320, when it just throws out the cached
>> entry, entirely.
>
> Indeed. My experiments were that even with unlimited, the passwd entry
> for the current, logged in user disappeared. I was going to demonstrate
> on my Ubuntu Karmic laptop but I can't seem to reproduce this here.
> Maybe this was a problem only on the Jaunty laptop that I was trying
> previously.

I can't speak to Ubuntu-specific issues, I don't have a lot of
experience there, but I've seen a decent number of bugs in the PADL
suite and nscd, in the last few years. Maybe Launchpad has a ticket
from between those two releases that explains the difference?

>> I actually use 'reload-count unlimited' to cache LDAP (AD, actually)
>> users and groups. It works fine for laptops with domain accounts. With
>> pam_ccreds, it pretty much works just like a local account would.
>
> That's exactly what I am aiming for as well.
>
> Cheers, and thanks for the update to your last post.
>
> We should probably take this NSCD discussion offline as it's really OT
> here. Although, evidence is that, on Karmic anyway, it's working and
> it's nss_ldap that is giving me grief when I am disconnected.

Can I suggest something? If you haven't already gotten in touch with
someone who's using LDAP authen and authn caching (pam_ldap and
pam_ccreds), it might be worthwhile to re-phrase that issue as a
separate question on the list. I can show you how I do authen, but my
bag is all Kerberos, and it sounds like you're probably headed for an
all-LDAP setup.

-Ryan

Re: Re: Re: disconnected nss_ldap

2009-10-24T00:14:25Z

Brian J. Murrell wrote:
> On Fri, 2009-10-23 at 22:40 -0700, Howard Chu wrote:
>> I have it running
>> on my G1 phone, the process size is only 1.5MB.
>
> I wonder how big it would be on my laptop, with an empty database.

It helps to tweak the config, of course. By default slapd uses up to 16
threads; on my phone I have it configured for only 2 threads. In practice,
unless someone else is querying it remotely, it won't ever receive queries
from more than 1 app at a time.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: Re: disconnected nss_ldap

2009-10-23T23:20:51Z

On Fri, 2009-10-23 at 22:40 -0700, Howard Chu wrote:
> OpenLDAP is probably the least bloated solution you'll find.

Probably so. Probably just a prejudice, with it being a "database"
server that it will become a big footprint.

Maybe just seeing it's footprint on my server (where it's serving up a
smallish NSS data set) is skewing my opinion:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30999 openldap 20 0 98.6m 5796 2676 S 0 0.9 18:26.51 slapd

> I have it running
> on my G1 phone, the process size is only 1.5MB.

I wonder how big it would be on my laptop, with an empty database.

> See how big all those other
> solutions are when configured as well as possible, that still don't solve the
> actual problem. Plus it's remotely configurable, which makes it far more
> manageable than any other approach...

All good points.

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-10-23T23:17:32Z

On Sat, 2009-10-24 at 01:38 -0400, Brian J. Murrell wrote:
>
> But as soon as the LDAP server is available again, ssh to the node works
> just fine.

I fixed this. This is because of pam_unix's account mode. It wants to
verify the shadow entry when the passwd entry contains a "x" for the
password -- hence my previous thread about fixing this in nss_ldap.
Adding broken_shadow to pam_unix's entry in the account mode works
around it.

> Indeed. My experiments were that even with unlimited, the passwd entry
> for the current, logged in user disappeared. I was going to demonstrate
> on my Ubuntu Karmic laptop but I can't seem to reproduce this here.

I spoke too soon/didn't wait long enough.

Witness my laptop, where I am logged in (as brian), have nscd running
with:
reload-count unlimited
positive-time-to-live passwd 60

$ id brian
id: brian: No such user

I also have a user "keith" in my LDAP directory mapped into the NSS
passwd map which I was testing with before when I thought it was
working. All this to say that "keith" should definitely be in nscd's
persistent cache as I was executing "id keith" repeatedly, watching for
it to disappear, and now, like the "brian" entry, it has:

$ id keith
id: keith: No such user

So for whatever reason, NSCD is expiring entries from it's persistent
cache despite the "reload-count unlimited". ~sigh~

b.

signature.asc (204 bytes) Download Attachment

Re: Re: disconnected nss_ldap

2009-10-23T22:40:55Z

Brian J. Murrell wrote:

> On Fri, 2009-10-23 at 20:36 -0700, Howard Chu wrote:
>>
>> Use OpenLDAP's nssov overlay plus your choice of either proxycache or
>> syncrepl. Both will work fine; your choice depends on whether the disconnected
>> machine is a single-user machine (then just use proxycache) or a multi-user
>> machine (then you might want to use syncrepl instead).
>
> So, some googlin' given that this nssov is new to me... it seems that I
> run a full fledged LDAP server (slapd) on every client?
>
> Wow. That seems a might overkill also. Workstations are already so
> overly bloated, adding an LDAP server just to deal with disconnected use
> just seems like over-engineering the problem.

OpenLDAP is probably the least bloated solution you'll find. I have it running
on my G1 phone, the process size is only 1.5MB. See how big all those other
solutions are when configured as well as possible, that still don't solve the
actual problem. Plus it's remotely configurable, which makes it far more
manageable than any other approach...

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: disconnected nss_ldap

2009-10-23T22:38:49Z

On Sat, 2009-10-24 at 00:34 -0400, Ryan Lynch wrote:
>
> My bad, I just realized that you DID mention nscd--I need to learn to read.

Yeah. :-) Oh well. Water under the bridge.

> But I think nscd actually has the feature that you want--are you
> familiar with the 'reload-count' option?

Yup.

> It lets you limit the number
> timeout-cycles that the daemon will tolerate before it throws out a
> cached entry.

Right. But my experience is that even with unlimited, it doesn't take
long before the passwd entries are just gone.

But other than that, my experiments reveal that nss_ldap is called by
binaries, independently of querying nscd. i.e. I try to log in while
the LDAP server is unavailable and get scads of messages
in /var/log/auth from nss_ldap that the ldap server is unavailable.
Such as:

Oct 24 01:26:09 brian-laptop-old sudo: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Oct 24 01:26:09 brian-laptop-old sudo: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
Oct 24 01:26:09 brian-laptop-old sudo: nss_ldap: reconnecting to LDAP server...
Oct 24 01:26:09 brian-laptop-old sudo: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Oct 24 01:26:09 brian-laptop-old sudo: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
Oct 24 01:26:09 brian-laptop-old sudo: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Oct 24 01:26:10 brian-laptop-old sudo: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Oct 24 01:26:10 brian-laptop-old sudo: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
Oct 24 01:26:10 brian-laptop-old sudo: nss_ldap: could not search LDAP server - Server is unavailable

In the case of sshd, I get much the same as the above, but the remote is
disconnected without even attempting an authentication:

Oct 24 01:34:09 brian-laptop-old sshd[20430]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Oct 24 01:34:09 brian-laptop-old sshd[20430]: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
Oct 24 01:34:09 brian-laptop-old sshd[20430]: nss_ldap: reconnecting to LDAP server...
Oct 24 01:34:09 brian-laptop-old sshd[20430]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Oct 24 01:34:09 brian-laptop-old sshd[20430]: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
Oct 24 01:34:09 brian-laptop-old sshd[20430]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Oct 24 01:34:10 brian-laptop-old sshd[20430]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Oct 24 01:34:10 brian-laptop-old sshd[20430]: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
Oct 24 01:34:10 brian-laptop-old sshd[20430]: nss_ldap: could not search LDAP server - Server is unavailable

But as soon as the LDAP server is available again, ssh to the node works
just fine.

> For example, given your desired scenario of a 10-minute cache TTL, and
> a 30 day hard timeout, you could set:
>
> positive-time-to-live 600 # 10 minutes
> reload-count 4320 # 30 days / 10 minutes
>
> If the cached value is more than 10 minutes old, 'nscd' will try to
> refresh it. If it fails to connect, it will re-set the 10-minute TTL
> and increment its reload counter by 1. This cycle repeats until the
> reload counter reaches 4,320, when it just throws out the cached
> entry, entirely.

Indeed. My experiments were that even with unlimited, the passwd entry
for the current, logged in user disappeared. I was going to demonstrate
on my Ubuntu Karmic laptop but I can't seem to reproduce this here.
Maybe this was a problem only on the Jaunty laptop that I was trying
previously.

> I actually use 'reload-count unlimited' to cache LDAP (AD, actually)
> users and groups. It works fine for laptops with domain accounts. With
> pam_ccreds, it pretty much works just like a local account would.

That's exactly what I am aiming for as well.

Cheers, and thanks for the update to your last post.

We should probably take this NSCD discussion offline as it's really OT
here. Although, evidence is that, on Karmic anyway, it's working and
it's nss_ldap that is giving me grief when I am disconnected.

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-10-23T21:55:18Z

On Sat, 2009-10-24 at 00:09 -0400, Ryan Lynch wrote:
>
> Do you know about NSCD (the Name Service Caching Daemon)?

Wow. I'm trying really hard not to be rude here, but did you bother to
read my original posting? I will quote here for you what I said about
NSCD:

> > I realize that caching is what is needed here and I have looked into
> > nscd for this, using it's persistent storage feature, but it just
> > doesn't seem to be thought out well enough from the temporarily
> > disconnected use-case. It seems that nscd needs two timeouts. One
> > at which it will try to refresh a stale entry and a second at which
> > it will expire a stale entry. Reasonable times for the two would be
> > something on the order of 10 minutes and 30 days, respectively.

> It's built
> to handle this kind of thing,

Not really, it seems. In practise anyway. I have tried the recommended
"reload-count = unlimited" but as reported by another, it doesn't seem
to entirely solve the problem. See
http://sourceware.org/bugzilla/show_bug.cgi?id=2132 for details.

The digested summary is that the above option does not appear to prevent
entries from being expired from the cache when the timeout is set
reasonably low (like several minutes). Setting the timeout to some
god-awful huge value, like 30 days leads to nscd having stale data, even
when connected to the network. Hence the proposal for two timeouts in
my original posting as well as in the above mentioned bug.

Do you actually use NSCD to solve this? I'd be interested in your
experience (off-line as this is pretty OT for this list) as popular
experience with a proper configuration seems to be that it doesn't work.

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-10-23T21:37:49Z

On Fri, 2009-10-23 at 20:36 -0700, Howard Chu wrote:
>
> Use OpenLDAP's nssov overlay plus your choice of either proxycache or
> syncrepl. Both will work fine; your choice depends on whether the disconnected
> machine is a single-user machine (then just use proxycache) or a multi-user
> machine (then you might want to use syncrepl instead).

So, some googlin' given that this nssov is new to me... it seems that I
run a full fledged LDAP server (slapd) on every client?

Wow. That seems a might overkill also. Workstations are already so
overly bloated, adding an LDAP server just to deal with disconnected use
just seems like over-engineering the problem.

Maybe I am just mis-understanding it all.

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-10-23T21:34:15Z

On Sat, Oct 24, 2009 at 00:09, Ryan Lynch <ryan.b.lynch@...> wrote:

> On Fri, Oct 23, 2009 at 22:49, Brian J. Murrell <brian@...> wrote:
>> At the risk of asking a FAQ (but in my defence, I have been googling
>> this off and on for the last 2-3 weeks) how does one properly handle
>> computers (i.e. laptops) that should get their NSS information from LDAP
>> while connected to the corporate network and yet still function while
>> away from the corporate network?
> ...
>>
>> Surely others have run into this same problem. How did you solve it?
>>
>> BTW: I am aware of nss_updatedb, but that seems a little clunky and
>> heavy handed with it's "cache everything" and rigid (i.e. time of day
>> driven) update schedule. For such reasons I have read frequently that
>> it really just doesn't scale. An nss_updatedb that is updated as a
>> result of usual lookups seems much more manageable. That way only
>> information the user is likely to use is cached and it's done with the
>> frequency of and as a by-product of existing lookups.
>
> Do you know about NSCD (the Name Service Caching Daemon)? It's built
> to handle this kind of thing, and a lot of distros (Fedora/RH/CentOS,
> at least) include it by default with the Glibc package. But it usually
> isn't running by default.

My bad, I just realized that you DID mention nscd--I need to learn to read.

But I think nscd actually has the feature that you want--are you
familiar with the 'reload-count' option? It lets you limit the number
timeout-cycles that the daemon will tolerate before it throws out a
cached entry.

For example, given your desired scenario of a 10-minute cache TTL, and
a 30 day hard timeout, you could set:

positive-time-to-live 600 # 10 minutes
reload-count 4320 # 30 days / 10 minutes

If the cached value is more than 10 minutes old, 'nscd' will try to
refresh it. If it fails to connect, it will re-set the 10-minute TTL
and increment its reload counter by 1. This cycle repeats until the
reload counter reaches 4,320, when it just throws out the cached
entry, entirely. (I don't actually know whether 'nscd' will
automatically try to refresh the cached entry every 10 minutes, or if
it only tries when the name is requested... That probably deserves an
experiment, because it could have big implications for the actual hard
limit you'd see.)

I actually use 'reload-count unlimited' to cache LDAP (AD, actually)
users and groups. It works fine for laptops with domain accounts. With
pam_ccreds, it pretty much works just like a local account would.

-Ryan