Thanks, Felix! I figured it out. Turns out it was because when I copied my shadow.so (from ruby-shadow lib build) I'd not changed permissions on it to be world read/execute. So, anyone who's trying the Solaris client, hope that helps!
Now if only I can figure out how to "let" puppetd execute /usr/bin/ passwd to set passwords for users I'll be all set! :) Let me ask a related question, what is the "best" way to add lines to / etc/passwd and /etc/shadow with puppet? I'm setting things up to initialize LDAP support on the same Solaris box and need to add lines to allow login for specific LDAP groups. The only answer I've found so far is to use a module like concat, but I've not gotten that to work right so far. On Oct 27, 7:46 am, Felix Frank <[email protected]> wrote: > On 10/27/2010 02:36 PM, nickt wrote: > > > Hopefully I'm just missing something simple, but I'm having trouble > > getting just the absolute bare-bones puppet set up on a new, clean > > Solaris 10 install. > > > When I try to run: > > > /opt/csw/bin/puppetd --verbose --no-daemonize --server > > puppet.mydomain.com > > I may be wrong, but adding a --debug should give you more hints as to > what providers are being considered. This is what one of my Linux > vservers has to say: > debug: Puppet::Type::User::ProviderLdap: feature ldap is missing > debug: Puppet::Type::User::ProviderPw: file pw does not exist > debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not > exist > debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl > does not exist > > Not at all pertinent to you, but that kind of message is what will help > you, I hope. > > HTH, > Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
