FAQ
I see that there are an assorted bunch of "provider" types for resource
type user. Are there not any "local file" providers for it?

I have need of ensuring that certain local user accounts get created on all
machines, reguardless of what the system "/bin/password" and "useradd"
type mechanisms are set to.
It would be really nice to find a pre-written way of handling this cleanly?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ixsSwBulpnIJ.
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 May 4, 2012 at 8:19 am
    Hi Philip,

    What's wrong with letting Puppet decide on the provider automatically?

    user { "luke": ensure => present, home => '/home/luke', password =>
    'zzzzzzzzzzzzzzz' }
    On 04/05/12 01:33, Philip Brown wrote:
    I see that there are an assorted bunch of "provider" types for
    resource type user. Are there not any "local file" providers for it?

    I have need of ensuring that certain local user accounts get created
    on all machines, reguardless of what the system "/bin/password" and
    "useradd" type mechanisms are set to.
    It would be really nice to find a pre-written way of handling this
    cleanly?

    --
    You received this message because you are subscribed to the Google
    Groups "Puppet Users" group.
    To view this discussion on the web visit
    https://groups.google.com/d/msg/puppet-users/-/ixsSwBulpnIJ.
    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 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.
  • Philip Brown at May 4, 2012 at 1:55 pm

    On Fri, May 4, 2012 at 1:18 AM, Luke Bigum wrote:
    Hi Philip,

    What's wrong with letting Puppet decide on the provider automatically?

    user { "luke": ensure => present, home => '/home/luke', password =>
    'zzzzzzzzzzzzzzz' }
    We use NIS compat mode.
    we have 32,000 users through NIS.
    Puppet tries to go through all of them.
    It's not usable that way.
    Besides which, it would give us false positives.
    Some users we care about are in NIS, but we specifically want them to
    have local definitions as well.


    On 04/05/12 01:33, Philip Brown wrote:

    I see that there are an assorted bunch of "provider" types for resource
    type user.  Are there not any "local file" providers for it?

    I have need of ensuring that certain local user accounts get created on
    all machines, reguardless of what the system "/bin/password"  and "useradd"
    type mechanisms are set to.
    It would be really nice to find a pre-written way of handling this
    cleanly?
    --
    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.
  • Jcbollinger at May 7, 2012 at 2:01 pm

    On May 4, 8:55 am, Philip Brown wrote:
    On Fri, May 4, 2012 at 1:18 AM, Luke Bigum wrote:
    Hi Philip,
    What's wrong with letting Puppet decide on the provider automatically?
    user { "luke": ensure => present, home => '/home/luke', password =>
    'zzzzzzzzzzzzzzz' }
    We use NIS compat mode.
    we have 32,000 users through NIS.
    Puppet tries to go through all of them.
    It's not usable that way.
    Besides which, it would give us false positives.
    Some users we care about are in NIS, but we specifically want them to
    have local definitions as well.

    I wrote a custom "nisuser" User provider to handle exactly that
    situation. I add "provider => 'nisuser'" to User declarations that I
    want to leverage it. For example:

    user { 'alice':
    ensure => present,
    provider => 'nisuser'
    }

    ensures the /etc/passwd contains the line

    +alice::::::

    Those properties that make sense to override locally are also
    supported. Unfortunately, I'm not at liberty to share, but I can try
    to offer advice if you choose to go that way.


    John

    --
    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.
  • Philip Brown at May 7, 2012 at 4:04 pm

    On Monday, May 7, 2012 7:01:11 AM UTC-7, jcbollinger wrote:

    user { 'alice':
    ensure => present,
    provider => 'nisuser'
    }

    ensures the /etc/passwd contains the line

    +alice::::::

    Those properties that make sense to override locally are also
    supported. Unfortunately, I'm not at liberty to share, but I can try
    to offer advice if you choose to go that way.

    Please do.
    I'm interested in basically "the minimum" here :)
    What's the minimum I can get away with supporting?
    I'm thinking of going with something really stupid-dumb like requiring
    username, uid, and gid, and supporting nothing else :)


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ZOCmY0waBBkJ.
    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.
  • Philip Brown at May 7, 2012 at 4:16 pm
    Hmm.. after reading the solaris manpage, it seems that the "useradd"
    command, allegedly only adds to local /etc/files stuff.
    So that part could theoretically be fine for me... it's the "does user
    already exist?" detection that is non-desired.

    But... I am not tracking how Puppet detects that.
    provider/useradd.rb does not have any "exists?" definition that I can see
    (and yet type/user.rb, references "provider.exists?", so... whats up with
    that??)

    Side question:
    Does ruby have a nice clean builtin, for

    echo Some:line:here >> file

    (note that is "append-only" mode)


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6ogRU2wGG08J.
    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.
  • Jcbollinger at May 7, 2012 at 6:04 pm

    On May 7, 11:16 am, Philip Brown wrote:
    Hmm.. after reading the solaris manpage, it seems that the "useradd"
    command, allegedly only adds to local /etc/files stuff.
    So that part could theoretically be fine for me... it's the "does user
    already exist?" detection that is non-desired.

    But... I am not tracking how Puppet detects that.
    provider/useradd.rb does not have any "exists?" definition that I can see
    (and yet type/user.rb, references "provider.exists?", so... whats up with
    that??)

    I'm not sure where it is in the latest version of Puppet, but it used
    to be in provider/nameservice.rb. Following the chain of parent
    providers and superclasses can get you there from useradd.rb.
    Basically, though, a variety of providers implement variations on a
    collection of named OS objects, all using the NameService front-end.
    It's tricky to follow how all the pieces interact.

    Side question:
    Does ruby have a nice clean builtin, for

    echo Some:line:here >> file

    (note that is "append-only" mode)
    You mean something like

    new File.open("/tmp/myfile", "a") { |file|
    file.write("Some:line:here\n")
    }

    ? That opens the named file for writing in append mode, executes the
    block (in which a line is written to the newly-opened file), and
    closes the file at the end of the block.

    Ruby is far from my favorite language, but it does have some appealing
    features, and this sort of thing is one of them.


    John

    --
    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.
  • Jcbollinger at May 7, 2012 at 6:39 pm

    On May 7, 11:04 am, Philip Brown wrote:
    On Monday, May 7, 2012 7:01:11 AM UTC-7, jcbollinger wrote:

    user { 'alice':
    ensure => present,
    provider => 'nisuser'
    }
    ensures the /etc/passwd contains the line
    +alice::::::
    Those properties that make sense to override locally are also
    supported.  Unfortunately, I'm not at liberty to share, but I can try
    to offer advice if you choose to go that way.
    Please do.
    I'm interested in basically "the minimum" here :)
    What's the minimum I can get away with supporting?
    I'm thinking of going with something really stupid-dumb like requiring
    username, uid, and gid, and supporting nothing else :)

    Well then I've got good news for you: to the best of my knowledge, NIS
    does not support overriding UIDs or GIDs (or passwords; these three
    always come from the map), so that leaves you with just presence /
    absence of the name. Your provider does need to deal with the fact
    that other properties can be specified, but you don't need explicit
    code for them, and just ignoring them will at least get you off the
    ground.

    The place to start is probably: http://docs.puppetlabs.com/guides/custom_types.html.
    That will eventually lead you to http://docs.puppetlabs.com/guides/provider_development.html.
    I would recommend also reading http://docs.puppetlabs.com/guides/complete_resource_example.html.
    For my work, I depended most on the second of those three.

    You may be able to base your provider on the ParsedFile general-
    purpose base provider, though I did not do that with mine.

    Don't forget that you will need to support both "ensure => present"
    and "ensure => absent", and that you probably want to avoid creating
    duplicate records.

    That's all the general advice I have at the moment, but if you run
    into trouble with specifics of the implementation then there are
    several of us around here who can probably help.

    For what it's worth, my provider is about 350 lines of Ruby code,
    about a third of which are whitespace or comments, and the vast
    majority of that is related to prefetching and / or flushing
    instances. It should be possible to do a simple-minded version
    supporting just present / absent with a lot less code if it doesn't
    need to prefetch and flush.


    John

    --
    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.
  • Philip Brown at May 9, 2012 at 6:46 pm

    On Monday, May 7, 2012 11:39:37 AM UTC-7, jcbollinger wrote:


    You may be able to base your provider on the ParsedFile general-
    purpose base provider, though I did not do that with mine.
    *Sounds* promising. But... no documentation on using this either, that I
    can find?

    K.I.S.S.
    At this point, I feel like just going with the approach of treating
    /etc/passwd like a generic config file, and using a "make sure this line is
    present in this file" resource.
    That sounds like a nice generic thing to...
    Wait.. there isnt one already? ! ???
    Seriously? I havent just missed one somewhere?
    Otherwise, I guess I know what my next puppet back-end coding project is :-/

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/m68k0VOG__UJ.
    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.
  • Gary Larizza at May 9, 2012 at 6:55 pm
    Philip,

    You can use Augeas to do this, or look at a custom file_line type in the
    Puppetlabs-stdlib module -->
    https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/type/file_line.rb

    On Wed, May 9, 2012 at 11:46 AM, Philip Brown wrote:


    On Monday, May 7, 2012 11:39:37 AM UTC-7, jcbollinger wrote:



    You may be able to base your provider on the ParsedFile general-
    purpose base provider, though I did not do that with mine.
    *Sounds* promising. But... no documentation on using this either, that I
    can find?

    K.I.S.S.
    At this point, I feel like just going with the approach of treating
    /etc/passwd like a generic config file, and using a "make sure this line is
    present in this file" resource.
    That sounds like a nice generic thing to...
    Wait.. there isnt one already? ! ???
    Seriously? I havent just missed one somewhere?
    Otherwise, I guess I know what my next puppet back-end coding project is
    :-/

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    https://groups.google.com/d/msg/puppet-users/-/m68k0VOG__UJ.

    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.


    --

    Gary Larizza
    Professional Services Engineer
    Puppet Labs

    --
    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.
  • Philip Brown at May 9, 2012 at 7:10 pm

    On Wednesday, May 9, 2012 11:55:01 AM UTC-7, Gary Larizza wrote:

    Philip,

    You can use Augeas to do this,

    Install a whole new C library/util/ thingie, just to do something trivial?
    no thanks...


    or look at a custom file_line type in the Puppetlabs-stdlib module -->
    https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/type/file_line.rb
    Aha, thanks, this sounds appropriate.
    Soooo.. what's the way to "officially" use or acquire this thing?

    $ puppet-module search stdlib
    returns puppetlabs/stdlib (2.3.1)

    so... use that?
    Is there a corresponding best-fit simple resource type already written to
    go along with it?
    Hmm.. I'm kinda leery of just typing "puppet-module install xyz", without
    knowing everything thats in it.
    Is there some undocumneted puppet-module command to show what will be
    installed, before actually installing it?
    Something named "stdlib" seems quite large.

    and how do I know it will work with my version of puppet? is the number
    in (), the version of the module, or the required version of puppet?

    puppet-module --help does not mention this sort of information.


    On Wed, May 9, 2012 at 11:46 AM, Philip Brown wrote:


    On Monday, May 7, 2012 11:39:37 AM UTC-7, jcbollinger wrote:



    You may be able to base your provider on the ParsedFile general-
    purpose base provider, though I did not do that with mine.
    *Sounds* promising. But... no documentation on using this either, that I
    can find?

    K.I.S.S.
    At this point, I feel like just going with the approach of treating
    /etc/passwd like a generic config file, and using a "make sure this line is
    present in this file" resource.
    That sounds like a nice generic thing to...
    Wait.. there isnt one already? ! ???
    Seriously? I havent just missed one somewhere?
    Otherwise, I guess I know what my next puppet back-end coding project is
    :-/
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ZhG7AAZx2FUJ.
    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.
  • Philip Brown at May 10, 2012 at 10:52 pm

    On Wednesday, May 9, 2012 11:55:01 AM UTC-7, Gary Larizza wrote:

    Philip,

    You can use Augeas to do this, or look at a custom file_line type in the
    Puppetlabs-stdlib module -->
    https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/type/file_line.rb

    A followup to this hint:
    I managed to get a test box, to install newer puppet, and get this module,
    and try it out.
    Tests look not so good.

    $ more tests/file_line.pp
    # This is a simple smoke test
    # of the file_line resource type.
    file { '/tmp/dansfile':
    ensure => present
    }->
    file_line { 'dans_line':
    line => 'dan is awesome',
    path => '/tmp/dansfile',
    }

    ## Okay, looks good, lets try it out...

    $ puppet apply tests/file_line.pp
    notice: /Stage[main]//File[/tmp/dansfile]/ensure: created
    notice: Finished catalog run in 0.04 seconds

    ##okay, this test file created, but..

    $ cat /tmp/dansfile
    $

    It does not have any content!!


    (it would seem that the provided test, needs some testing :-/ Adding
    ensure=>present seems to make it happen. but shouldnt that already be in
    the "test/file_line.pp" file? )


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/o-L4mfgshu0J.
    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.
  • Gary Larizza at May 10, 2012 at 10:59 pm
    You'll want to add "ensure => present" to the file_line resource and then
    run it again. That should help you out!

    On Thu, May 10, 2012 at 3:52 PM, Philip Brown wrote:


    On Wednesday, May 9, 2012 11:55:01 AM UTC-7, Gary Larizza wrote:


    Philip,

    You can use Augeas to do this, or look at a custom file_line type in the
    Puppetlabs-stdlib module --> https://github.com/**
    puppetlabs/puppetlabs-stdlib/**blob/master/lib/puppet/type/**file_line.rb<https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/type/file_line.rb>

    A followup to this hint:
    I managed to get a test box, to install newer puppet, and get this module,
    and try it out.
    Tests look not so good.

    $ more tests/file_line.pp
    # This is a simple smoke test
    # of the file_line resource type.
    file { '/tmp/dansfile':
    ensure => present
    }->
    file_line { 'dans_line':
    line => 'dan is awesome',
    path => '/tmp/dansfile',
    }

    ## Okay, looks good, lets try it out...

    $ puppet apply tests/file_line.pp
    notice: /Stage[main]//File[/tmp/dansfile]/ensure: created
    notice: Finished catalog run in 0.04 seconds

    ##okay, this test file created, but..

    $ cat /tmp/dansfile
    $

    It does not have any content!!


    (it would seem that the provided test, needs some testing :-/ Adding
    ensure=>present seems to make it happen. but shouldnt that already be in
    the "test/file_line.pp" file? )


    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    https://groups.google.com/d/msg/puppet-users/-/o-L4mfgshu0J.

    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.


    --

    Gary Larizza
    Professional Services Engineer
    Puppet Labs

    --
    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.
  • Philip Brown at May 10, 2012 at 11:31 pm

    On Thursday, May 10, 2012 3:59:36 PM UTC-7, Gary Larizza wrote:
    You'll want to add "ensure => present" to the file_line resource and then
    run it again. That should help you out!

    yup, I noticed :)

    isnt this technically a bug in puppetlabs-stdlib:file_line, though?

    shouldnt it be updated so that either the test file has that already, OR
    (better yet), the type, automatically defaults to it?

    Actually, given the example usage In the Code Itself, I think I can answer
    that yes, it is a bug.

    guess I'll go file a bug report :-/

    Erm... except that theres no directions in the module on where to file bug
    reports, nor does there seem to be any mechanism on forge.puppetlabs.com
    itself either.


    Ummm . . . ?


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/971J_25RJTkJ.
    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.
  • Gary Larizza at May 10, 2012 at 11:37 pm
    On Thu, May 10, 2012 at 4:30 PM, Philip Brown wrote:
    On Thursday, May 10, 2012 3:59:36 PM UTC-7, Gary Larizza wrote:

    You'll want to add "ensure => present" to the file_line resource and then
    run it again. That should help you out!

    yup, I noticed :)

    isnt this technically a bug in puppetlabs-stdlib:file_line, though?

    shouldnt it be updated so that either the test file has that already, OR
    (better yet), the type, automatically defaults to it?

    Actually, given the example usage In the Code Itself, I think I can answer
    that yes, it is a bug.

    guess I'll go file a bug report :-/

    Erm... except that theres no directions in the module on where to file bug
    reports, nor does there seem to be any mechanism on forge.puppetlabs.comitself either.


    Ummm . . . ?
    Our main Redmine server is located here -->
    http://projects.puppetlabs.com/projects and you can use that to track all
    the projects for which we accept bugs. You'll probably notice a standard
    library project -->
    http://projects.puppetlabs.com/projects/stdlib/issues for which you'll
    also notice a specific bug -->
    http://projects.puppetlabs.com/issues/13530 that mentions an open pull
    request --> https://github.com/puppetlabs/puppetlabs-stdlib/pull/65 that
    might help you out :)



    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    https://groups.google.com/d/msg/puppet-users/-/971J_25RJTkJ.

    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.


    --

    Gary Larizza
    Professional Services Engineer
    Puppet Labs

    --
    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.
  • Philip Brown at May 10, 2012 at 11:57 pm

    On Thursday, May 10, 2012 4:37:14 PM UTC-7, Gary Larizza wrote:

    On Thu, May 10, 2012 at 4:30 PM, Philip Brown wrote:


    Erm... except that theres no directions in the module on where to file
    bug reports, nor does there seem to be any mechanism on
    forge.puppetlabs.com itself either.


    Ummm . . . ?
    Our main Redmine server is located here -->
    http://projects.puppetlabs.com/projects and you can use that to track
    all the projects for which we accept bugs. You'll probably notice a
    standard library project -->
    http://projects.puppetlabs.com/projects/stdlib/issues for which you'll
    also notice a specific bug --> http://projects.puppetlabs.com/issues/13530
    Ah, thank you Gary. I did actually look at
    http://projects.puppetlabs.com/projects, but I somehow missed the link to
    the stdlib project :-/

    Nice to know that's in the works at least.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/bUDT8VoYlDAJ.
    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.
  • Jeff McCune at May 11, 2012 at 5:31 am

    On Thu, May 10, 2012 at 4:57 PM, Philip Brown wrote:
    Ah, thank you Gary. I did actually look at http://projects.**
    puppetlabs.com/projects <http://projects.puppetlabs.com/projects>, but I
    somehow missed the link to the stdlib project :-/

    Nice to know that's in the works at least.
    It was a pretty quick fix and I think I reviewed the patch that broke it in
    the first place. =( I went ahead and released stdlib-2.3.2 [1] which makes
    ensure => present the default behavior. It should install easily with
    puppet module install puppetlabs-stdlib.

    @duritong sorry your pull request sat there for so long... I haven't done
    a good job of reviewing the stdlib pull requests these past couple of
    weeks. The fix to file_line has already been merged up from the 2.3.x
    maintenance branch into master so you might want to close the pull request.

    [1] http://forge.puppetlabs.com/puppetlabs/stdlib/2.3.2

    Cheers,
    -Jeff

    --
    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
postedMay 4, '12 at 12:34a
activeMay 11, '12 at 5:31a
posts17
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase