On Jun 15, 8:24 pm, Gus F. gus.fer...@gmail.com wrote:
It is happening on 0.25.5-1 server, but so far I have only seen the
problem on 0.24.X clients. I don't have an 0.25.4 master to test
against, but at any rate I am unable to reproduce the problem. The
problem seems to have occurred in a
Yeah, it's nasty.
Running the puppet commands you listed doesn't show any problems. The
logs show the password being set correctly, but it isn't really. Once
I manually change the password, then puppet can make those password
changes again.
It looks like the problem may be limited to my clients
On Jun 15, 2:39 pm, Gus F. gus.fer...@gmail.com wrote:
I am using puppet (version 0.25.5-1.e15 for redhat) for password
management for non-system users. This morning, users on some of my
puppet clients had their encrypted password strings in /etc/shadow
replaced with the following string:
On Tue, Jun 15, 2010 at 6:32 PM, donavan dona...@desinc.net wrote:
On Jun 15, 2:39 pm, Gus F. gus.fer...@gmail.com wrote:
I am using puppet (version 0.25.5-1.e15 for redhat) for password
management for non-system users. This morning, users on some of my
puppet clients had their encrypted
if this happens on a 0.25.5 server (and maybe client), it might be happening
because of the zaml implementation, can you reproduce this problem with
0.25.4 master?
in anycase, it sounds like a bug :)
Ohad
On Wed, Jun 16, 2010 at 9:35 AM, Nigel Kersten nig...@google.com wrote:
On Tue, Jun
It is happening on 0.25.5-1 server, but so far I have only seen the
problem on 0.24.X clients. I don't have an 0.25.4 master to test
against, but at any rate I am unable to reproduce the problem. The
problem seems to have occurred in a relatively small time across the
affected clients, and
Well, I've worked around this for now by:
- uninstalling puppet and facter with mac ports (so there's no
puppetfoo executables under /opt/local/sbin or /opt/local/bin anymore
- used gem to install puppet and facter into the system ruby, so now
the executables are under /usr/bin/puppetfoo
This
