On Aug 31, 4:06 pm, Andrew Shafer wrote:
> git blame
>
> I am the culprit.
>
> The only provider that does passwords this way is user_role_add on
> Solaris. If you are not using Solaris, you are not running that code.
>
> The rational at the time was, useradd/mod do not support the password
> p
On Aug 31, 5:06 pm, Andrew Shafer wrote:
[...]
> The rational at the time was, useradd/mod do not support the password
> parameter on Solaris and libshadow for Ruby is an unmaintained
> project, difficult to build and without upstream support as a package
> on the platform.
Fair enough.
[...]
On Aug 31, 4:11 pm, James Turnbull wrote:
> 2009/8/28 Kyle Mallory :
>
>
>
> > The problem is, the User type (w/ manage_passwords enabled and ruby-
> > shadow installed) will only set the password in /etc/shadow, but it
> > doesn't manage any of the other shadow parameters, namely the
> > sp_ls
git blame
I am the culprit.
The only provider that does passwords this way is user_role_add on
Solaris. If you are not using Solaris, you are not running that code.
The rational at the time was, useradd/mod do not support the password
parameter on Solaris and libshadow for Ruby is an unmaintain
2009/8/28 Kyle Mallory :
>
> The problem is, the User type (w/ manage_passwords enabled and ruby-
> shadow installed) will only set the password in /etc/shadow, but it
> doesn't manage any of the other shadow parameters, namely the
> sp_lstchg parameter). As a result, after our 90-day period, all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
jcbollinger wrote:
> Puppet's resource model involves having a common front end for each
> resource type that defines the available parameters, properties, and
> features, plus one or more "providers" for that type that interact
> with specific host e
>> Actually, these the passwords for the 3 system administrators. We
>> have to have an expiration policy to meet our security guidelines.
> I took a different and more hacky approach.
> I wrote a function that fetches the complete shadow line from the
> shadow file then pushes that line to the
On Aug 28, 10:15 am, Kyle Mallory wrote:
[...]
> I think I made some minor progress, as it appears that the password
> handing is actually done by 'lib/puppet/provider/user/
> user_role_add.rb' (which makes so sense to me whatsoever), and despite
> everything to the contrary, doesn't actually u
On Fri, Aug 28, 2009 at 8:15 AM, Kyle Mallory wrote:
>
> On Aug 28, 8:18 am, jcbollinger wrote:
>>
>> It seems a bit strange to me that you are managing users' passwords
>> for them in the first place. It is usually users' responsibility to
>> manage their own passwords. If you really do want t
On Aug 28, 8:18 am, jcbollinger wrote:
>
> It seems a bit strange to me that you are managing users' passwords
> for them in the first place. It is usually users' responsibility to
> manage their own passwords. If you really do want to manage passwords
> centrally, however, then why do you need
On Aug 27, 2:05 pm, Kyle Mallory wrote:
> We have a policy that requires all user passwords to expire after 90
> days. We also use puppet for managing all users on our machines. Our
> hope was, when our passwords expire, we could update the puppet
> manifest which would propogate to all our s
Probably not.
In theory, this would actually update the date every time the 'user'
type successfully runs.
I ended up hacking together my own function that would do what I
wanted it to do.
Hoping to roll it back into the main user type someday
Trevor
On Thu, Aug 27, 2009 at 21:24, Len Rug
Just thinking could the password change use notify of a "usermod -e
new--dd-mm" command?
On Thu, Aug 27, 2009 at 2:05 PM, Kyle Mallory wrote:
>
> We have a policy that requires all user passwords to expire after 90
> days. We also use puppet for managing all users on our machines. Our
>
13 matches
Mail list logo
