Puppet users - Aug 2009 - Failed to retrieve current state of resource: Could not find user <username>

Hello all.


We''re running puppet 0.24.4, and have recently started to get this
error:

*"Failed to retrieve current state of resource: Could not find user
<username> "*

I''ve found mail threads with similar issues, where nscd have been
identified
as the cause.

We have a bunch of servers, and pretty much all of the are running nscd.
I''ve picked a puppet client to investigate the issue, and so far
I''ve simply
stopped nscd on this client and on the puppetmaster, but the problem
remains.
First of all, how can I verify that this indeed is a nscd issue? And second:
Shouldn''t stopping nscd on the client and the master resolve the issue
(assumin it is an nscd issue) for the particular client?

Regards,
Kenneth Holter

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Aug 18, 3:46 am, Kenneth Holter <kenneho....@gmail.com>
wrote:
> We''re running puppet 0.24.4, and have recently started to get this
error:
>
> *"Failed to retrieve current state of resource: Could not find user
> <username> "*
>
> I''ve found mail threads with similar issues, where nscd have been
identified
> as the cause.
>
> We have a bunch of servers, and pretty much all of the are running nscd.
> I''ve picked a puppet client to investigate the issue, and so far
I''ve simply
> stopped nscd on this client and on the puppetmaster, but the problem
> remains.
> First of all, how can I verify that this indeed is a nscd issue? And
second:
> Shouldn''t stopping nscd on the client and the master resolve the
issue
> (assumin it is an nscd issue) for the particular client?
Nscd has some interesting behaviors.  Two of the most potentially
vexing are

1) Its caches can be configured to persist across service restarts
(including system reboots).
2) Its caches can be configured so that clients can access them
directly in shared memory, rather than going through the daemon.

I think the combination of those may explain why shutting down the
daemon seems insufficient to immediately terminate caching.

With that being the case, I think the best way to try to attempt to
eliminate nscd as the problem is

a) Turn off the ''persistent'' and ''shared''
flags for the passwd service
in /etc/nscd.conf, and make sure there are no duplicate entries for
these flags.  (I''ve seen duplicate entries in the as-delivered conf
files of some distros.)
b) Start / restart nscd to make it recognize the reconfiguration
c) Stop nscd.  Delete /var/db/nscd/passwd if it exists.  To be 100%
confident, disable nscd and reboot (to cover long-lived nscd clients
that already have the cache mmapped).
d) Run your test

You may also want to read this info on nscd:
http://anusf.anu.edu.au/~djh900/nscd.html.
It''s a bit dated (2006), but seems to still be valid as far as I can
tell.  Of course, there''s also the man pages for nscd(8) and nscd.conf
(5), which may be of some help.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---