Puppet users - May 2012 - forcing user resource provider to be local files only?

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.

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.

On Fri, May 4, 2012 at 1:18 AM, Luke Bigum <Luke.Bigum@lmax.com>
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.

On May 4, 8:55 am, Philip Brown <p...@bolthole.com>
wrote:
> On Fri, May 4, 2012 at 1:18 AM, Luke Bigum <Luke.Bi...@lmax.com>
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.

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.

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.

On May 7, 11:16 am, Philip Brown <p...@bolthole.com>
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.

On May 7, 11:04 am, Philip Brown <p...@bolthole.com>
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.

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.

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 <phil@bolthole.com> 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.

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.

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.

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 <phil@bolthole.com> 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.

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.

On Thu, May 10, 2012 at 4:30 PM, Philip Brown <phil@bolthole.com> 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.

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.

On Thu, May 10, 2012 at 4:57 PM, Philip Brown <phil@bolthole.com> 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.