On Aug 28, 10:15 am, Kyle Mallory <jesuswasir...@gmail.com> 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 user ruby-libshadow, but
> rather hand-writes the shadow file itself (which makes even less sense
> to me!). I'm in the testing whether this actually does what I think
> it does.
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 environments to evaluate and update resource
instances on those environments. user_role_add.rb is one of the
providers for the User type. It is the default for Solaris, so if
you're running on Solaris then that's probably what you're using, and
if not then not.
I agree that the password management in that provider is rather
strange. It is usual for the User providers to rely on the host OS's
utilities to do work (e.g. user_role_add uses useradd, usermod, etc.),
so it is odd that password management is an exception. Moreover, it
is surpassingly strange that having rejected OS utilities for this
job, the provider does not rely on the Ruby shadow password library.
The code even contains comments complaining about manipulating the
shadow file directly!
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
