One one of my new vmware guests... puppetd -v spits out a bunch of err & warnings about "State group failed"... what does this mean? <snip> info: Caching configuration at /var/lib/puppet/localconfig.yaml err: Could not create root: Could not find a default provider for group warning: file=/etc/yum.repos.d/: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/pki/rpm-gpg/RPM-GPG-KEY-gadmin: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/sshd_config: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_config: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/moduli: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_host_key: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_host_key.pub: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_host_rsa_key: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_host_rsa_key.pub: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_host_dsa_key: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/ssh/ssh_host_dsa_key.pub: State group failed: Could not find a default provider for group err: Could not create root: Could not find a default provider for group warning: file=/etc/sudoers: ": Could not find a default provider for group ... </snip> --jason
I also tried setting provider => useradd (and groupadd for group), which then spits out: <snip> err: Could not create jdillon: Provider ''groupadd'' is not functional on this platform err: Could not create jdillon: Provider ''useradd'' is not functional on this platform </snip> This is a FC5 host... not sure why groupadd or useradd would not be funcitonal, since those are the commands I used to make users and groups. This host is running puppet-0.19.3-1.fc5, where the others are running puppet-0.19.1-1.fc5. facter on the new hosts appears to detect this is Fedora: operatingsystem => Fedora This host was running puppet-0.19.1-1.fc5. when it first ran, which did install a user and group just fine... but after a `yum update` puppet was upgraded and now user installs do not work. Any ideas whats up? --jason On Sep 27, 2006, at 9:55 PM, Jason Dillon wrote:> One one of my new vmware guests... puppetd -v spits out a bunch of > err & warnings about "State group failed"... what does this mean? > > <snip> > info: Caching configuration at /var/lib/puppet/localconfig.yaml > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/yum.repos.d/: State group failed: Could not find > a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/pki/rpm-gpg/RPM-GPG-KEY-gadmin: State group > failed: Could not find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/sshd_config: State group failed: Could not > find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_config: State group failed: Could not > find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/moduli: State group failed: Could not find a > default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_host_key: State group failed: Could not > find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_host_key.pub: State group failed: Could > not find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_host_rsa_key: State group failed: Could > not find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_host_rsa_key.pub: State group failed: > Could not find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_host_dsa_key: State group failed: Could > not find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/ssh/ssh_host_dsa_key.pub: State group failed: > Could not find a default provider for group > err: Could not create root: Could not find a default provider for > group > warning: file=/etc/sudoers: ": Could not find a default provider > for group > ... > </snip> > > --jason
Okay, I found it... looks like when puppet is searching for commands to find providers it is not using a "reasonable" search path, but expects the commands to exist in the current users search path... :-( --jason On Sep 27, 2006, at 10:49 PM, Jason Dillon wrote:> I also tried setting provider => useradd (and groupadd for group), > which then spits out: > > <snip> > err: Could not create jdillon: Provider ''groupadd'' is not > functional on this platform > err: Could not create jdillon: Provider ''useradd'' is not functional > on this platform > </snip> > > This is a FC5 host... not sure why groupadd or useradd would not be > funcitonal, since those are the commands I used to make users and > groups. > > This host is running puppet-0.19.3-1.fc5, where the others are > running puppet-0.19.1-1.fc5. facter on the new hosts appears to > detect this is Fedora: > > operatingsystem => Fedora > > This host was running puppet-0.19.1-1.fc5. when it first ran, which > did install a user and group just fine... but after a `yum update` > puppet was upgraded and now user installs do not work. > > Any ideas whats up? > > --jason > > > On Sep 27, 2006, at 9:55 PM, Jason Dillon wrote: > >> One one of my new vmware guests... puppetd -v spits out a bunch of >> err & warnings about "State group failed"... what does this mean? >> >> <snip> >> info: Caching configuration at /var/lib/puppet/localconfig.yaml >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/yum.repos.d/: State group failed: Could not >> find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/pki/rpm-gpg/RPM-GPG-KEY-gadmin: State group >> failed: Could not find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/sshd_config: State group failed: Could not >> find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_config: State group failed: Could not >> find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/moduli: State group failed: Could not find >> a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_host_key: State group failed: Could not >> find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_host_key.pub: State group failed: Could >> not find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_host_rsa_key: State group failed: Could >> not find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_host_rsa_key.pub: State group failed: >> Could not find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_host_dsa_key: State group failed: Could >> not find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/ssh/ssh_host_dsa_key.pub: State group failed: >> Could not find a default provider for group >> err: Could not create root: Could not find a default provider for >> group >> warning: file=/etc/sudoers: ": Could not find a default provider >> for group >> ... >> </snip> >> >> --jason >
Jason Dillon a écrit :> Okay, I found it... looks like when puppet is searching for commands > to find providers it is not using a "reasonable" search path, but > expects the commands to exist in the current users search path... :-( > > --jason > >seems reasonable to me as you can this way easely make it work on any custom system by changing the path of the user it run as. The user should have the path setup accordingly no ? :) regards, Ghislain. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
I guess I would expect that the calling script should prepend /sbin:/ usr/sbin to the path as a sanity check... --jason On Sep 27, 2006, at 11:44 PM, Adnet Ghislain wrote:> > > Jason Dillon a écrit : >> Okay, I found it... looks like when puppet is searching for >> commands to find providers it is not using a "reasonable" search >> path, but expects the commands to exist in the current users >> search path... :-( >> >> --jason >> > > seems reasonable to me as you can this way easely make it work on > any custom system by changing the path of the user it run as. The > user should have the path setup accordingly no ? :) > > regards, > Ghislain. > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users
Jason Dillon wrote:> Okay, I found it... looks like when puppet is searching for commands > to find providers it is not using a "reasonable" search path, but > expects the commands to exist in the current users search path... :-(Could you submit this as a bug? It''s true that puppetd at least should set a reasonable path, although the definition of "reasonable" varies considerably by platform. I''ll probably end up making it a configuration parameter. -- Progress isn''t made by early risers. It''s made by lazy men trying to find easier ways to do something. --Robert Heinlein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 9/28/06, Luke Kanies <luke@madstop.com> wrote:> Jason Dillon wrote: > > Okay, I found it... looks like when puppet is searching for commands > > to find providers it is not using a "reasonable" search path, but > > expects the commands to exist in the current users search path... :-( > > Could you submit this as a bug? It''s true that puppetd at least should > set a reasonable path, although the definition of "reasonable" varies > considerably by platform. I''ll probably end up making it a > configuration parameter.That would be nice to try and help "lock" down a configuration system. Making sure that you can say things from the central user (path, umask, capabilities) can help point better where a problem occurs if a script changes all that and screws up stuff. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"
Stephen John Smoogen wrote:> > That would be nice to try and help "lock" down a configuration system. > Making sure that you can say things from the central user (path, > umask, capabilities) can help point better where a problem occurs if a > script changes all that and screws up stuff.Added as #307: https://reductivelabs.com/cgi-bin/puppet.cgi/ticket/307 -- Venter''s First Law: Discoveries made in a field by some one from another discipline will always be upsetting to the majority of those inside. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Wednesday, September 27, 2006 10:56 PM -0700 Jason Dillon <jason@planet57.com> wrote:> Okay, I found it... looks like when puppet is searching for commands > to find providers it is not using a "reasonable" search path, but > expects the commands to exist in the current users search path... :-( >So what''s the solution to this? -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University
>> Okay, I found it... looks like when puppet is searching for commands >> to find providers it is not using a "reasonable" search path, but >> expects the commands to exist in the current users search path... :-( >> > > So what''s the solution to this?Nvm, solution is just to make sure the path is set correctly in the environment calling puppet. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University
Digant C Kasundra wrote:>>> Okay, I found it... looks like when puppet is searching for commands >>> to find providers it is not using a "reasonable" search path, but >>> expects the commands to exist in the current users search path... :-( >>> >> So what''s the solution to this? > > Nvm, solution is just to make sure the path is set correctly in the > environment calling puppet.As of 0.20.0, you can set Puppet''s path using the ''path'' configuration setting. Note that if you use this setting it will clobber the default setting, not be used in addition. -- SELF-EVIDENT, adj. Evident to one''s self and to nobody else. -- Ambrose Bierce --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Seemingly Similar Threads
- [PATCH node-image] Add ability to set persistent ssh_host_keys on the node, usefull if you run diskless instance of ovirt-node
- OpenSSH 7.3p1 can't be build on Solaris 10
- unexpected behaviour in OpenSSH_3.7.1
- server host keys for kvm clones
- server host keys for kvm clones