Puppet users - Dec 2006 - Problem with user type on 0.20.1... uses group "absent"

Hi, I''m running into a problem with the user type with puppet  
0.20.1... this worked before with 0.19.x at least, not sure about 0.20.

But I''ve got adduser.pp:

<snip>
define adduser($uid, $gid, $groups="users",
$membership="minimum") {
     group {
         $name:
             gid => $gid,
             allowdupe => false,
             ensure => present
     }

     user {
         $name:
             uid => $uid,
             gid => $gid,
             allowdupe => false,
             ensure => present,
             groups => $groups,
             membership => minimum
     }
}
</snip>

And then in another class I have:

<snip>
adduser {
         anthill:
             uid => 505,
             gid => 505;
     }
</snip>

I see it creating the group, but then the useradd fails:

<snip>
notice: //gbuild-slave-node/anthill/adduser[anthill]/group=anthill/ 
ensure: created
err: //gbuild-slave-node/anthill/adduser[anthill]/user=anthill/ 
ensure: change from absent to present failed: Could not create user  
anthill: Could not execute ''/usr/sbin/useradd -G
''users'' -u ''505'' -g
''absent'' -M anthill 2>&1'': useradd: unknown
group absent
</snip>

Why is it using -g ''absent'' ?

This is on a FC5 box... and as I said, this worked asis before.  Only  
just noticed it now as I was bringing new hosts under puppet control.

Any ideas?

Thanks,

--jason

It also appears that use of the "-M" flag might be new too, as I also
see permission related errors when trying to ensure directories exist  
with the right permissions after I ran the corrected useradd command:

     /usr/sbin/useradd -G ''users'' -u ''505''
-g ''505'' -M anthill

Subsequent puppet runs will puke out:

<snip>
err: //gbuild-slave-node/anthill/file=/home/anthill//ensure: change  
from absent to directory failed: Could not set directory on ensure:  
Permission denied - /home/anthill in file /etc/puppet/manifests/ 
classes/anthill.pp at line 31
</snip>

After nuking the anthill user and groups, then running:

     /usr/sbin/groupadd -g "505" anthill
     /usr/sbin/useradd -G ''users'' -u ''505''
-g ''505'' anthill

Then puppet runs will work again as they used to.

So, why was -M added?  And why when its present does the following  
complain (as above):

<snip>
     File {
         owner => "anthill",
         group => "anthill"
     }

     file {
         "/home/anthill/":
             mode => 755,
             ensure => directory;
     }
</snip>

:-(

--jason


On Dec 2, 2006, at 4:34 PM, Jason Dillon wrote:
> Hi, I''m running into a problem with the user type with puppet  
> 0.20.1... this worked before with 0.19.x at least, not sure about  
> 0.20.
>
> But I''ve got adduser.pp:
>
> <snip>
> define adduser($uid, $gid, $groups="users",
$membership="minimum") {
>     group {
>         $name:
>             gid => $gid,
>             allowdupe => false,
>             ensure => present
>     }
>
>     user {
>         $name:
>             uid => $uid,
>             gid => $gid,
>             allowdupe => false,
>             ensure => present,
>             groups => $groups,
>             membership => minimum
>     }
> }
> </snip>
>
> And then in another class I have:
>
> <snip>
> adduser {
>         anthill:
>             uid => 505,
>             gid => 505;
>     }
> </snip>
>
> I see it creating the group, but then the useradd fails:
>
> <snip>
> notice: //gbuild-slave-node/anthill/adduser[anthill]/group=anthill/ 
> ensure: created
> err: //gbuild-slave-node/anthill/adduser[anthill]/user=anthill/ 
> ensure: change from absent to present failed: Could not create user  
> anthill: Could not execute ''/usr/sbin/useradd -G
''users'' -u ''505'' -
> g ''absent'' -M anthill 2>&1'': useradd:
unknown group absent
> </snip>
>
> Why is it using -g ''absent'' ?
>
> This is on a FC5 box... and as I said, this worked asis before.   
> Only just noticed it now as I was bringing new hosts under puppet  
> control.
>
> Any ideas?
>
> Thanks,
>
> --jason

Jason Dillon wrote:
> Hi, I''m running into a problem with the user type with puppet  
> 0.20.1... this worked before with 0.19.x at least, not sure about 0.20.
> 
> But I''ve got adduser.pp:
> 
> <snip>
> define adduser($uid, $gid, $groups="users",
$membership="minimum") {
>      group {
>          $name:
>              gid => $gid,
>              allowdupe => false,
>              ensure => present
>      }
> 
>      user {
>          $name:
>              uid => $uid,
>              gid => $gid,
>              allowdupe => false,
>              ensure => present,
>              groups => $groups,
>              membership => minimum
>      }
> }
> </snip>
> 
> And then in another class I have:
> 
> <snip>
> adduser {
>          anthill:
>              uid => 505,
>              gid => 505;
>      }
> </snip>
> 
> I see it creating the group, but then the useradd fails:
> 
> <snip>
> notice: //gbuild-slave-node/anthill/adduser[anthill]/group=anthill/ 
> ensure: created
> err: //gbuild-slave-node/anthill/adduser[anthill]/user=anthill/ 
> ensure: change from absent to present failed: Could not create user  
> anthill: Could not execute ''/usr/sbin/useradd -G
''users'' -u ''505'' -g
> ''absent'' -M anthill 2>&1'': useradd:
unknown group absent
> </snip>
> 
> Why is it using -g ''absent'' ?
> 
> This is on a FC5 box... and as I said, this worked asis before.  Only  
> just noticed it now as I was bringing new hosts under puppet control.
> 
> Any ideas?
My guess is that you''ve run into this bug:

https://reductivelabs.com/cgi-bin/puppet.cgi/ticket/350

What happens if you specify the user/group relationship manually?

-- 
I never did give anybody hell. I just told the truth, and they thought
it was hell.       -- Harry S Truman
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

Jason Dillon wrote:
> It also appears that use of the "-M" flag might be new too, as I
also
> see permission related errors when trying to ensure directories exist  
> with the right permissions after I ran the corrected useradd command:
> 
>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' -M anthill
> 
> Subsequent puppet runs will puke out:
> 
> <snip>
> err: //gbuild-slave-node/anthill/file=/home/anthill//ensure: change  
> from absent to directory failed: Could not set directory on ensure:  
> Permission denied - /home/anthill in file /etc/puppet/manifests/ 
> classes/anthill.pp at line 31
> </snip>
> 
> After nuking the anthill user and groups, then running:
> 
>      /usr/sbin/groupadd -g "505" anthill
>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' anthill
> 
> Then puppet runs will work again as they used to.
> 
> So, why was -M added?  And why when its present does the following  
> complain (as above):
I know the -M stuff isn''t new; it''s been there for a while. 
It''s
supposed to stop useradd from creating the home directory.

-- 
Take the utmost trouble to find the right thing to say, and then say it
with the utmost levity.     -- George Bernard Shaw
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

Okay... well, then why is puppet tweaking out when trying to make / 
home/anthill then?

Also, why not just let the dir be created?  I know in some cases you  
don''t want a dir, but so far all of the usage of the user type I need  
that directory, and really would rather let adduser do the default  
thing.

--jason


On Dec 4, 2006, at 7:03 AM, Luke Kanies wrote:
> Jason Dillon wrote:
>> It also appears that use of the "-M" flag might be new too,
as I also
>> see permission related errors when trying to ensure directories exist
>> with the right permissions after I ran the corrected useradd command:
>>
>>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' -M anthill
>>
>> Subsequent puppet runs will puke out:
>>
>> <snip>
>> err: //gbuild-slave-node/anthill/file=/home/anthill//ensure: change
>> from absent to directory failed: Could not set directory on ensure:
>> Permission denied - /home/anthill in file /etc/puppet/manifests/
>> classes/anthill.pp at line 31
>> </snip>
>>
>> After nuking the anthill user and groups, then running:
>>
>>      /usr/sbin/groupadd -g "505" anthill
>>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' anthill
>>
>> Then puppet runs will work again as they used to.
>>
>> So, why was -M added?  And why when its present does the following
>> complain (as above):
>
> I know the -M stuff isn''t new; it''s been there for a
while.  It''s
> supposed to stop useradd from creating the home directory.
>
> -- 
> Take the utmost trouble to find the right thing to say, and then  
> say it
> with the utmost levity.     -- George Bernard Shaw
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users

Well, my feelings on this one are that not all the platforms that
Puppet runs on create a user''s home directory and in doing so you need
to extend the adduser functionality beyond what Puppet should be
doing.  The default thing is different over different systems, and I
would argue that the ''default thing'' is to NOT create home
directory
and that such behavior is some vendor-specific extension to the
''default''.  Also, this ''default thing''
typically copies an unknown and
difficult to determine amount of file, typically from /etc/skel/, to
the new home directory.  Managing user accounts and their contents is
one of my goals, getting sideswiped by some ''default thing'' on
a
particular OS that''s adduser script put something in there that I had
no idea about isn''t.  And I don''t think we would expect puppet
to add
the -h flag to all the programs under Solaris; to me adding the
functionality of creating home directories to platforms that do not
natively support such behavior is the same.

Looking at a random passwd file, the bulk of the ''users'' are
system
accounts which don''t need home directories.  Creating the user
directory is a trivial reusable bit of code that probably exists in
your manifests in some form already.


.r''


On 12/4/06, Jason Dillon <jason@planet57.com>
wrote:
> Okay... well, then why is puppet tweaking out when trying to make /
> home/anthill then?
>
> Also, why not just let the dir be created?  I know in some cases you
> don''t want a dir, but so far all of the usage of the user type I
need
> that directory, and really would rather let adduser do the default
> thing.
>
> --jason
>
>
> On Dec 4, 2006, at 7:03 AM, Luke Kanies wrote:
>
> > Jason Dillon wrote:
> >> It also appears that use of the "-M" flag might be new
too, as I also
> >> see permission related errors when trying to ensure directories
exist
> >> with the right permissions after I ran the corrected useradd
command:
> >>
> >>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' -M anthill
> >>
> >> Subsequent puppet runs will puke out:
> >>
> >> <snip>
> >> err: //gbuild-slave-node/anthill/file=/home/anthill//ensure:
change
> >> from absent to directory failed: Could not set directory on
ensure:
> >> Permission denied - /home/anthill in file /etc/puppet/manifests/
> >> classes/anthill.pp at line 31
> >> </snip>
> >>
> >> After nuking the anthill user and groups, then running:
> >>
> >>      /usr/sbin/groupadd -g "505" anthill
> >>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' anthill
> >>
> >> Then puppet runs will work again as they used to.
> >>
> >> So, why was -M added?  And why when its present does the following
> >> complain (as above):
> >
> > I know the -M stuff isn''t new; it''s been there for a
while.  It''s
> > supposed to stop useradd from creating the home directory.
> >
> > --
> > Take the utmost trouble to find the right thing to say, and then
> > say it
> > with the utmost levity.     -- George Bernard Shaw
> > ---------------------------------------------------------------------
> > Luke Kanies | http://reductivelabs.com | http://madstop.com
> >
> > _______________________________________________
> > Puppet-users mailing list
> > Puppet-users@madstop.com
> > https://mail.madstop.com/mailman/listinfo/puppet-users
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

That is fine... but then wtf is puppet puking about not being able to  
make the directory that I asked?  I explicitly ensure that the  
directory is there.  This used to work fine... now its broke, as well  
as user creation due to this group absent muck.

I''m not really sure that the "default" on systems it not not
create a
home dir though... mac os creates one, fedora and redhat create one,  
last I checked debian does too... and irix... solaris might not, but  
its been ages since I''ve used that.

Anyways, my point was more like... make it configurable... but more  
so the ensure directory muck should not have failed.  I was only able  
to get it to work (all of the puppet bits which add dirs and other  
files to a user''s home), by creating the groups and users by hand NOT  
using -M (so the dir has the right perms).

And this used to work ASIS before... I did not change any of this  
config, though automated yam/yum updates have pulled in new versions  
of puppet.

I tend to like the automated updates for most things, but I don''t  
really like it for puppet, as it tends to break my installs or start  
behaving really differently.

--jason


On Dec 4, 2006, at 3:44 PM, RijilV wrote:
> Well, my feelings on this one are that not all the platforms that
> Puppet runs on create a user''s home directory and in doing so you
need
> to extend the adduser functionality beyond what Puppet should be
> doing.  The default thing is different over different systems, and I
> would argue that the ''default thing'' is to NOT create
home directory
> and that such behavior is some vendor-specific extension to the
> ''default''.  Also, this ''default thing''
typically copies an unknown and
> difficult to determine amount of file, typically from /etc/skel/, to
> the new home directory.  Managing user accounts and their contents is
> one of my goals, getting sideswiped by some ''default
thing'' on a
> particular OS that''s adduser script put something in there that I
had
> no idea about isn''t.  And I don''t think we would expect
puppet to add
> the -h flag to all the programs under Solaris; to me adding the
> functionality of creating home directories to platforms that do not
> natively support such behavior is the same.
>
> Looking at a random passwd file, the bulk of the ''users''
are system
> accounts which don''t need home directories.  Creating the user
> directory is a trivial reusable bit of code that probably exists in
> your manifests in some form already.
>
>
> .r''
>
>
> On 12/4/06, Jason Dillon <jason@planet57.com> wrote:
>> Okay... well, then why is puppet tweaking out when trying to make /
>> home/anthill then?
>>
>> Also, why not just let the dir be created?  I know in some cases you
>> don''t want a dir, but so far all of the usage of the user type
I need
>> that directory, and really would rather let adduser do the default
>> thing.
>>
>> --jason
>>
>>
>> On Dec 4, 2006, at 7:03 AM, Luke Kanies wrote:
>>
>>> Jason Dillon wrote:
>>>> It also appears that use of the "-M" flag might be
new too, as I
>>>> also
>>>> see permission related errors when trying to ensure directories
>>>> exist
>>>> with the right permissions after I ran the corrected useradd  
>>>> command:
>>>>
>>>>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' -M anthill
>>>>
>>>> Subsequent puppet runs will puke out:
>>>>
>>>> <snip>
>>>> err: //gbuild-slave-node/anthill/file=/home/anthill//ensure:
change
>>>> from absent to directory failed: Could not set directory on
ensure:
>>>> Permission denied - /home/anthill in file
/etc/puppet/manifests/
>>>> classes/anthill.pp at line 31
>>>> </snip>
>>>>
>>>> After nuking the anthill user and groups, then running:
>>>>
>>>>      /usr/sbin/groupadd -g "505" anthill
>>>>      /usr/sbin/useradd -G ''users'' -u
''505'' -g ''505'' anthill
>>>>
>>>> Then puppet runs will work again as they used to.
>>>>
>>>> So, why was -M added?  And why when its present does the
following
>>>> complain (as above):
>>>
>>> I know the -M stuff isn''t new; it''s been there
for a while.  It''s
>>> supposed to stop useradd from creating the home directory.
>>>
>>> --
>>> Take the utmost trouble to find the right thing to say, and then
>>> say it
>>> with the utmost levity.     -- George Bernard Shaw
>>>
--------------------------------------------------------------------
>>> -
>>> Luke Kanies | http://reductivelabs.com | http://madstop.com
>>>
>>> _______________________________________________
>>> Puppet-users mailing list
>>> Puppet-users@madstop.com
>>> https://mail.madstop.com/mailman/listinfo/puppet-users
>>
>> _______________________________________________
>> Puppet-users mailing list
>> Puppet-users@madstop.com
>> https://mail.madstop.com/mailman/listinfo/puppet-users
>>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users

Jason Dillon wrote:
> That is fine... but then wtf is puppet puking about not being able to  
> make the directory that I asked?  I explicitly ensure that the  
> directory is there.  This used to work fine... now its broke, as well  
> as user creation due to this group absent muck.
This is clearly a bug, I agree, especially if it used to work and it 
does not now.
> I''m not really sure that the "default" on systems it not
not create a
> home dir though... mac os creates one, fedora and redhat create one,  
> last I checked debian does too... and irix... solaris might not, but  
> its been ages since I''ve used that.
Overall, RijilV is correct -- Puppet disables directory creation because 
if it doesn''t then you''re basically guaranteed inconsistent
operation.
Solaris, at least, does not create the directory by default, and OS X 
definitely does not when you create a user with NetInfo.
> Anyways, my point was more like... make it configurable... but more  
> so the ensure directory muck should not have failed.  I was only able  
> to get it to work (all of the puppet bits which add dirs and other  
> files to a user''s home), by creating the groups and users by hand
NOT
> using -M (so the dir has the right perms).
I would like to make it configurable, but I have not yet had the time to 
do so.
> And this used to work ASIS before... I did not change any of this  
> config, though automated yam/yum updates have pulled in new versions  
> of puppet.
> 
> I tend to like the automated updates for most things, but I don''t
> really like it for puppet, as it tends to break my installs or start  
> behaving really differently.
I would agree with this; automated updates of your automated tools are 
seldom a good idea.

-- 
The easiest way to figure the cost of living is to take your income and
add ten percent.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On Dec 4, 2006, at 7:01 AM, Luke Kanies wrote:
>> <snip>
>> define adduser($uid, $gid, $groups="users",
$membership="minimum") {
>>      group {
>>          $name:
>>              gid => $gid,
>>              allowdupe => false,
>>              ensure => present
>>      }
>>
>>      user {
>>          $name:
>>              uid => $uid,
>>              gid => $gid,
>>              allowdupe => false,
>>              ensure => present,
>>              groups => $groups,
>>              membership => minimum
>>      }
>> }
>> </snip>
>>
>> And then in another class I have:
>>
>> <snip>
>> adduser {
>>          anthill:
>>              uid => 505,
>>              gid => 505;
>>      }
>> </snip>
> My guess is that you''ve run into this bug:
>
> https://reductivelabs.com/cgi-bin/puppet.cgi/ticket/350
>
> What happens if you specify the user/group relationship manually?
I don''t follow what you mean by this... I am specifying both, or do  
you mean to unroll the adduser type?

 From the bug listed above it suggests that listing ensure first is  
some way to resolve it.  Is that really a bug?  config elements are  
order specific?

--jason

On Dec 5, 2006, at 5:30 AM, Luke Kanies wrote:
>> I''m not really sure that the "default" on systems it
not not create a
>> home dir though... mac os creates one, fedora and redhat create one,
>> last I checked debian does too... and irix... solaris might not, but
>> its been ages since I''ve used that.
>
> Overall, RijilV is correct -- Puppet disables directory creation  
> because
> if it doesn''t then you''re basically guaranteed
inconsistent operation.
> Solaris, at least, does not create the directory by default, and OS X
> definitely does not when you create a user with NetInfo.
Aight, fair enough ;-)

>> And this used to work ASIS before... I did not change any of this
>> config, though automated yam/yum updates have pulled in new versions
>> of puppet.
>>
>> I tend to like the automated updates for most things, but I
don''t
>> really like it for puppet, as it tends to break my installs or start
>> behaving really differently.
>
> I would agree with this; automated updates of your automated tools are
> seldom a good idea.
I have been meaning to figure out how to config yum to ignore it, but  
have not had time... and the updates were relatively infrequent.  Oh  
well :-(

--jason

On 5 Dec 2006, at 19:48, Jason Dillon wrote:
> On Dec 5, 2006, at 5:30 AM, Luke Kanies wrote:
>>> I''m not really sure that the "default" on
systems it not not
>>> create a
>>> home dir though... mac os creates one, fedora and redhat create
one,
>>> last I checked debian does too... and irix... solaris might not,
but
>>> its been ages since I''ve used that.
>>
>> Overall, RijilV is correct -- Puppet disables directory creation
>> because
>> if it doesn''t then you''re basically guaranteed
inconsistent
>> operation.
>> Solaris, at least, does not create the directory by default, and OS X
>> definitely does not when you create a user with NetInfo.
>
> Aight, fair enough ;-)
I also prefer consistency across platforms. I’ll now nag about my  
feature request for this to apply to whether or not the accounts are  
created locked:
http://mail.madstop.com/pipermail/puppet-users/2006-October/000551.html

:)

Gary Law
gary.law@gmail.com





_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Gary Law wrote:
> 
> I also prefer consistency across platforms. I’ll now nag about my 
> feature request for this to apply to whether or not the accounts are 
> created locked:
> http://mail.madstop.com/pipermail/puppet-users/2006-October/000551.html
Patches always accepted. :)

I'd like to get this done, but my workload is far too high right now to 
spend the time on it, unfortunately.

-- 
Reality is that which, when you stop believing in it, doesn't go
away.    -- Philip K. Dick, "How to Build a Universe"
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Jason Dillon wrote:
> 
> I don''t follow what you mean by this... I am specifying both, or
do
> you mean to unroll the adduser type?
> 
>  From the bug listed above it suggests that listing ensure first is  
> some way to resolve it.  Is that really a bug?  config elements are  
> order specific?
No; the problem is that Puppet is not correctly ordering the resources 
themselves.  Try specifying an explicit relationship between the user 
and group, so that the group will be created before the user is.

-- 
The trouble with the rat race is that even if you win, you''re still a
rat.  -- Lily Tomlin
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com