Matt Hyclak
2008-Oct-10 17:56 UTC
[Puppet Users] User provider on RHEL4 and RHEL5 breaks with latest fastrack update
I just wanted to throw this out there to see if it''s a known issue or
not. We have a manifest that looks like:
class auth-OIT-Security {
group {
''OIT-Security'' :
ensure => present,
gid => 5003;
}
user {
''smith'' :
ensure => present,
uid => 119,
gid => 5003,
home => ''/home/smith'',
comment => ''John Smith'',
managehome => true;
}
}
This works on RHEL4 and RHEL5 systems that are not subscribed to the
FasTrack channel. Specifically, shadow-utils-4.0.17-13.el5 works
correctly, but when it is updated to shadow-utils-4.0.17-14.el5,
puppet bombs out with
err: Could not create OIT-Security: Could not find a default provider
for group
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: Could not find a
default provider for group
or
err: Could not create smith: Could not find a default provider for
user
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: Could not find a
default provider for user
(The user and/or group it fails on seems random).
The changelog for shadow-utils-4.0.17-14.el5 indicates:
2008-08-26 22:00:00
Peter Vrabec <pvrabec@redhat.com> 2:4.0.17-14:
- fix the problem when useradd or usermod can give users access
to the root group
Resolves: #450262
Looking at the patch used to fix the problem, they''ve simply added a
check for NULL group names and error out if one is found (e.g. if you
did useradd -g foo -G bar,baz, someuser - previously it would add this
user to the root group because of the trailing comma).
Any thoughts on this? Is it fixable in the user provider in puppet, or
does the fix need to happen in useradd/usermod?
Thanks,
Matt
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Luke Kanies
2008-Oct-13 15:13 UTC
[Puppet Users] Re: User provider on RHEL4 and RHEL5 breaks with latest fastrack update
On Oct 10, 2008, at 12:56 PM, Matt Hyclak wrote:> > I just wanted to throw this out there to see if it''s a known issue or > not. We have a manifest that looks like: > > class auth-OIT-Security { > group { > ''OIT-Security'' : > ensure => present, > gid => 5003; > } > > user { > ''smith'' : > ensure => present, > uid => 119, > gid => 5003, > home => ''/home/smith'', > comment => ''John Smith'', > managehome => true; > } > } > > This works on RHEL4 and RHEL5 systems that are not subscribed to the > FasTrack channel. Specifically, shadow-utils-4.0.17-13.el5 works > correctly, but when it is updated to shadow-utils-4.0.17-14.el5, > puppet bombs out with > > err: Could not create OIT-Security: Could not find a default provider > for group > warning: Not using cache on failed catalog > warning: Configuration could not be instantiated: Could not find a > default provider for group > > or > > err: Could not create smith: Could not find a default provider for > user > warning: Not using cache on failed catalog > warning: Configuration could not be instantiated: Could not find a > default provider for user > > (The user and/or group it fails on seems random). > > The changelog for shadow-utils-4.0.17-14.el5 indicates: > 2008-08-26 22:00:00 > Peter Vrabec <pvrabec@redhat.com> 2:4.0.17-14: > - fix the problem when useradd or usermod can give users access > to the root group > Resolves: #450262 > > Looking at the patch used to fix the problem, they''ve simply added a > check for NULL group names and error out if one is found (e.g. if you > did useradd -g foo -G bar,baz, someuser - previously it would add this > user to the root group because of the trailing comma). > > Any thoughts on this? Is it fixable in the user provider in puppet, or > does the fix need to happen in useradd/usermod?If you run ''puppetdoc -r providers'', or just run puppetd in debug mode, you should see why your provider is suddenly being marked unsuitable. I expect it''s something simple, like /usr/sbin isn''t in your path. -- Health is merely the slowest possible rate at which one can die. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Matthew Hyclak
2008-Oct-13 19:44 UTC
[Puppet Users] Re: User provider on RHEL4 and RHEL5 breaks with latest fastrack update
Yes, I realized after doing some research and turning on debug mode that it happened when running with sudo, not as root. It is the issue indicated in #1631. Sorry about the noise. Matt On Mon, Oct 13, 2008 at 11:13 AM, Luke Kanies <luke@madstop.com> wrote:> > On Oct 10, 2008, at 12:56 PM, Matt Hyclak wrote: > >> >> I just wanted to throw this out there to see if it''s a known issue or >> not. We have a manifest that looks like: >> >> class auth-OIT-Security { >> group { >> ''OIT-Security'' : >> ensure => present, >> gid => 5003; >> } >> >> user { >> ''smith'' : >> ensure => present, >> uid => 119, >> gid => 5003, >> home => ''/home/smith'', >> comment => ''John Smith'', >> managehome => true; >> } >> } >> >> This works on RHEL4 and RHEL5 systems that are not subscribed to the >> FasTrack channel. Specifically, shadow-utils-4.0.17-13.el5 works >> correctly, but when it is updated to shadow-utils-4.0.17-14.el5, >> puppet bombs out with >> >> err: Could not create OIT-Security: Could not find a default provider >> for group >> warning: Not using cache on failed catalog >> warning: Configuration could not be instantiated: Could not find a >> default provider for group >> >> or >> >> err: Could not create smith: Could not find a default provider for >> user >> warning: Not using cache on failed catalog >> warning: Configuration could not be instantiated: Could not find a >> default provider for user >> >> (The user and/or group it fails on seems random). >> >> The changelog for shadow-utils-4.0.17-14.el5 indicates: >> 2008-08-26 22:00:00 >> Peter Vrabec <pvrabec@redhat.com> 2:4.0.17-14: >> - fix the problem when useradd or usermod can give users access >> to the root group >> Resolves: #450262 >> >> Looking at the patch used to fix the problem, they''ve simply added a >> check for NULL group names and error out if one is found (e.g. if you >> did useradd -g foo -G bar,baz, someuser - previously it would add this >> user to the root group because of the trailing comma). >> >> Any thoughts on this? Is it fixable in the user provider in puppet, or >> does the fix need to happen in useradd/usermod? > > If you run ''puppetdoc -r providers'', or just run puppetd in debug > mode, you should see why your provider is suddenly being marked > unsuitable. I expect it''s something simple, like /usr/sbin isn''t in > your path. > > -- > Health is merely the slowest possible rate at which one can die. > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---