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

Search Discussions

  • Luke Bigum at Apr 17, 2012 at 8:00 am
    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.
  • Paul Hinze at Apr 17, 2012 at 10:38 am

    On Mon, Apr 16, 2012 at 4:55 PM, Steve Roberts 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.
  • Michael Stahnke at Apr 17, 2012 at 2:09 pm

    On Mon, Apr 16, 2012 at 9:52 PM, Paul Hinze wrote:
    On Mon, Apr 16, 2012 at 4:55 PM, Steve Roberts 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.
  • Steve Roberts at Apr 17, 2012 at 8:55 pm

    On Apr 17, 7:08 am, Michael Stahnke 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.
  • Steve Roberts at Apr 17, 2012 at 8:57 pm

    On Apr 16, 9:52 pm, Paul Hinze 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 16, '12 at 9:58p
activeApr 17, '12 at 8:57p
posts6
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase