Puppet users - Oct 2010 - Solaris 10 Client "Default Provider for User" Woes Again

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 just get:

err: Could not create resources for managing Puppet''s files and
directories in sections [:main, :agent, :ssl]: Could not find a
default provider for user
err: Could not create resources for managing Puppet''s files and
directories in sections [:main, :ssl]: Could not find a default
provider for user
err: Could not create resources for managing Puppet''s files and
directories in sections [:main, :ssl]: Could not find a default
provider for user
warning: peer certificate won''t be verified in this SSL session
info: Caching certificate for ca
err: Could not request certificate: Could not find a default provider
for user


I''d be happy to post whatever, but I''m watching the
puppetmasterd on
the other end and I''m not seeing anything come through so it makes me
think there''s some quirky Solaris nonsense on the client side and
it''s
not even "talking" to the puppetmasterd.  I started the puppetmasterd
on the other end with:

sudo puppetmasterd --no-daemonize --verbose --trace --debug

Any ideas?  I''m absolutely certain all the sbin stuff is in my path
when I launch the puppetd on the client because before launching it I
did a:

export PATH=/usr/sfw/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/csw/bin:/
usr/ccs/bin:/usr/ucb

-- 
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 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 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.

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 <felix.fr...@alumni.tu-berlin.de>
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 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.

Sorry, answered my own question again.  Turns out for some reason on
Solaris if you use the --trace and/or --debug flags (not sure which)
when starting your puppetd it will be "unable" to execute /usr/bin/
passwd.  As soon as you take those off it works fine!

/opt/csw/bin/puppetd --verbose --trace --debug --server
cmsvl01.d1.peapod.com --no-daemonize


On Oct 27, 7:55 am, nickt <ntk...@gmail.com>
wrote:
> 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 <felix.fr...@alumni.tu-berlin.de>
> 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 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 Wed, Oct 27, 2010 at 6:00 AM, nickt <ntkach@gmail.com> wrote:
> Sorry, answered my own question again.  Turns out for some reason on
> Solaris if you use the --trace and/or --debug flags (not sure which)
> when starting your puppetd it will be "unable" to execute
/usr/bin/
> passwd.  As soon as you take those off it works fine!
>
> /opt/csw/bin/puppetd --verbose --trace --debug --server
> cmsvl01.d1.peapod.com --no-daemonize
>

It would be immensely appreciated if you could isolate which of these flags
causes that issue and you bug report it.

We live and die by our bug queue, and issues aren''t likely to get fixed
unless they''re reported.

>
>
> On Oct 27, 7:55 am, nickt <ntk...@gmail.com> wrote:
> > 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
<felix.fr...@alumni.tu-berlin.de>
> > 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 puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
Nigel Kersten
Product Manager, Puppet Labs
http://www.puppetlabs.com
Twitter: @nigelkersten

-- 
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.