Puppet users - Apr 2012 - how to get ruby-shadow installed before trying to make users,groups

I know I need to have ruby-shadow installed to get puppet to be able
to manage shadow file based passwords.

so tried to code that up in a puppet manifest like this:
======================================class strobenet {

  package { ''ruby-shadow'':
    ensure => ''present'',
  }

  user { ''tuser'':
    ensure           => ''present'',
    comment          => ''Test User'',
    gid              => ''302'',
    home             => ''/home/tuser'',
    password         => ''***'',
    password_max_age => ''99000'',
    password_min_age => ''5'',
    shell            => ''/bin/tcsh'',
    uid              => ''302'',
  }
  group { ''tuser'':
    ensure => ''present'',
    gid    => ''302'',
  }

  Package[''ruby-shadow''] -> User <| |>
}
======================================
the problem is that when it runs the first time the puppet User
provider says it can''t handle manages_passwords and
manages_password_age during init and so clips those attributes.

Then it goes to apply the actual resources and does the package first,
then the user.

But since the provider has already clipped the attributes they don''t
get set in the first run.

when run a second time the attributes do get set correctly, but that
seems a bit kludgy to have to run puppet twice to get the desired
affect.

-- 
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 Mon, Apr 16, 2012 at 4:55 PM, Steve Roberts <strobert@strobe.net>
wrote:
> But since the provider has already clipped the attributes they
don''t
> get set in the first run.
>
> when run a second time the attributes do get set correctly, but that
> seems a bit kludgy to have to run puppet twice to get the desired
> affect.
I''ve run into this too, and worked around it by considering
ruby-shadow as a "prerequisite" for puppet, and therefore taking
responsibility for that package up to my bootstrapping scripts. IOW,
it is one of the short list of packages that need to be there for
puppet to run successfully. In my case, that means adding it to a
Debian pre-seed config.

I''d be curious to know if there''s any other way to work around
provider dependencies like these in a cleaner way though.

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

Hi Steve,

This is a long standing ''chicken and egg'' situation with
Puppet
installing dependencies for it''s own providers. There was an issue I 
thought I was watching, but I can''t find it now to quote it to you.

People do different things: they either put up with the 2 pass approach, 
or for more involved providers they write a Fact to say whether the 
system the Agent is running on has the necessary requirements and then 
selectively defines resources.

-Luke

On 16/04/12 22:55, Steve Roberts wrote:
> I know I need to have ruby-shadow installed to get puppet to be able
> to manage shadow file based passwords.
>
> so tried to code that up in a puppet manifest like this:
> ======================================> class strobenet {
>
>    package { ''ruby-shadow'':
>      ensure =>  ''present'',
>    }
>
>    user { ''tuser'':
>      ensure           =>  ''present'',
>      comment          =>  ''Test User'',
>      gid              =>  ''302'',
>      home             =>  ''/home/tuser'',
>      password         =>  ''***'',
>      password_max_age =>  ''99000'',
>      password_min_age =>  ''5'',
>      shell            =>  ''/bin/tcsh'',
>      uid              =>  ''302'',
>    }
>    group { ''tuser'':
>      ensure =>  ''present'',
>      gid    =>  ''302'',
>    }
>
>    Package[''ruby-shadow''] ->  User<| |>
> }
> ======================================>
> the problem is that when it runs the first time the puppet User
> provider says it can''t handle manages_passwords and
> manages_password_age during init and so clips those attributes.
>
> Then it goes to apply the actual resources and does the package first,
> then the user.
>
> But since the provider has already clipped the attributes they
don''t
> get set in the first run.
>
> when run a second time the attributes do get set correctly, but that
> seems a bit kludgy to have to run puppet twice to get the desired
> affect.
>

-- 
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bigum@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.

-- 
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 Mon, Apr 16, 2012 at 9:52 PM, Paul Hinze <paul.t.hinze@gmail.com>
wrote:
> On Mon, Apr 16, 2012 at 4:55 PM, Steve Roberts <strobert@strobe.net>
wrote:
>> But since the provider has already clipped the attributes they
don''t
>> get set in the first run.
>>
>> when run a second time the attributes do get set correctly, but that
>> seems a bit kludgy to have to run puppet twice to get the desired
>> affect.
>
> I''ve run into this too, and worked around it by considering
> ruby-shadow as a "prerequisite" for puppet, and therefore taking
> responsibility for that package up to my bootstrapping scripts. IOW,
> it is one of the short list of packages that need to be there for
> puppet to run successfully. In my case, that means adding it to a
> Debian pre-seed config.
>
> I''d be curious to know if there''s any other way to work
around
> provider dependencies like these in a cleaner way though.
>
Much of this depends on *how* you install puppet.  If you use yum or
apt, I think shadow is pulled in as a dep (I know it is for rpm).  If
you use gems, I''m quite sure it''s not. If you''re on
mac or Windows you
can use the native packages and get password management without
shadow.

What platforms are you on?

> --
> 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.
>
-- 
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 Apr 17, 7:08 am, Michael Stahnke <stah...@puppetlabs.com>
wrote:
> Much of this depends on *how* you install puppet.  If you use yum or
> apt, I think shadow is pulled in as a dep (I know it is for rpm).  If
> you use gems, I''m quite sure it''s not. If you''re
on mac or Windows you
> can use the native packages and get password management without
> shadow.
>
> What platforms are you on?
cents5 and rhel5

the EPEL rpms do require ruby-shadow.  but the ones from
yum.puppetlabs.com do not.

we are using the puppetlab ones for two reasons:
1) they are 2.7 (EPEL is 2.6)
2) puppetlabs HIGHLY recommended we go with theirs and not EPEL rpms.

-- 
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 Apr 16, 9:52 pm, Paul Hinze <paul.t.hi...@gmail.com>
wrote:
> I''ve run into this too, and worked around it by considering
> ruby-shadow as a "prerequisite" for puppet, and therefore taking
> responsibility for that package up to my bootstrapping scripts. IOW,
> it is one of the short list of packages that need to be there for
> puppet to run successfully. In my case, that means adding it to a
> Debian pre-seed config.
>
> I''d be curious to know if there''s any other way to work
around
> provider dependencies like these in a cleaner way though.
probably what I am going to end up doing as well.  in my cause just
add to my anaconda list (for physical and VMware based machines) or to
my openVZ post deployment.

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