Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

getpwnam LDAP cache problem

by mandog (Curate)
on Dec 12, 2004 at 05:36 UTC ( #414199=perlquestion: print w/replies, xml ) Need Help??
mandog has asked for the wisdom of the Perl Monks concerning the following question:

We run Debian Sarge, our current account script:

  1. Uses getpwnam to check if an account exists
  2. If not, adds account info to LDAP
  3. Uses getpwnam to get the $uid and $gid to chown mail spool
  4. While the script is running, the second getpwnam fails. This behavior does not occur with file (/etc/passwd) based accounts.

    The problem also occurs with User::pwent

    If it turns out that this isn't a problem with my understanding, I can think of a few (ugly) ways to work around the problem. If it is a real problem, any thoughts on the best way to report the bug to the OpenLDAP (?) Pam (?) glibc (?) people would be helpful.

    #!/usr/bin/perl -w getpwnam("test") or warn "account doesn't exist yet... (expected)"; # code to add LDAP account here brings out problem # code to add to /etc/passwd account doesn't getpwnam("test") or warn "shouldn't see this but we do\n $!"; (system("chown test.test /tmp/file")==0) or warn "this also fails" # this works but is ugly warn `getent passwd | grep test`,"\n"; # $! eq 'No such file or directory'

Replies are listed 'Best First'.
Re: getpwnam LDAP cache problem
by sgifford (Prior) on Dec 12, 2004 at 08:33 UTC
    nscd(8) says:
    Nscd provides cacheing for the passwd(5) ... databases through standard libc interfaces, such as getpwnam(3), getpwuid(3), ... and others. Each cache has a separate TTL (time-to-live) for its data; modifying the local database (/etc/passwd, and so forth) causes the cache to become invalidated within fifteen seconds.

    So one possibility is that after changing the LDAP directory, waiting 15 seconds will give you the right data. Another possibility is that touching /etc/passwd (or another file configured in nscd.conf) after making the change will cause the cache to be invalidated, at least after 15 seconds.

    You could also consider getting the UID directly from LDAP.

    And, the reason your run of getent avoids the cache is that it doesn't call getpwnam or getpwuid, but instead goes through the entire passwd database, probably with getpwent. You could probably get the same effect without running a seperate utility by just calling that function repeatedly from within Perl.

    It looks like you can control how long nscd caches data in /etc/nscd.conf; see nscd.conf(5).

    As to whether it's a bug, that depends on what you expect from your system. Caching is a trade-off of speed for accuracy; if you don't want that trade-off, you can avoid running nscd, or configure it for very short timeouts.

      Thank you sgifford ! or perhaps should I say sgifford

      nscd does indeed seem to be the "problem" When I apt-get install nscd on a non LDAPified system, the "problem" begins to occur.

      An interesting bit, getent does actually seem to be going to the LDAP directory --at least it is listing things that aren't in /etc/passwd

      For what it is worth, We'll probably be talking directly to the LDAP directory for our getpwnam purposes. Caching is a "feature" for 86370 seconds in our day.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://414199]
Approved by monkfan
[marioroy]: I also have a Hobo driver for Forklift allowing folks to use in multiple classes, no conflicts with one another. That's not possible for P::FM.
[Discipulus]: congrats marioroy!
[marioroy]: CORE::wait works well eventhough multiple instances or classes using Hobo::Manager.
[Corion]: marioroy: I'm not sure what the normal use for the PID is in P:FM, but I guess that most programs just ignore or log it
[Corion]: Oh, yes, programs could call wait $pid, but if your $pid is an object, then you could add a ->wait method to it and wait $pid would call that automatically "thanks" to indirect object notation
[marioroy]: Just documentation edits is all that remains. Hobo::Simple provides foreach and forseq with identifier capability -- all transparently supporting array, hash, file handle, and seq 1 .. N.
[marioroy]: Corion Regarding PID, that's great. So will leave it so compatible with MCE::Hobo. e.g. ->create returns a Hobo object. Folks can get ->pid from it. So, that's not a problem.
[choroba]: ad readdir: 5.12 needed
[marioroy]: CORE::wait can block if another process reaps a worker from another class. MCE::Hobo takes care of that and transparently.

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2017-05-26 08:44 GMT
Find Nodes?
    Voting Booth?