forcing user resource provider to be local files only?

82 views
Skip to first unread message

Philip Brown

unread,
May 3, 2012, 8:33:56 PM5/3/12
to puppet...@googlegroups.com
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?

Luke Bigum

unread,
May 4, 2012, 4:18:57 AM5/4/12
to puppet...@googlegroups.com
Hi Philip,

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

user { "luke": ensure => present, home => '/home/luke', password =>
'zzzzzzzzzzzzzzz' }
> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@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....@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.

Philip Brown

unread,
May 4, 2012, 9:55:42 AM5/4/12
to puppet...@googlegroups.com
On Fri, May 4, 2012 at 1:18 AM, Luke Bigum <Luke....@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.

jcbollinger

unread,
May 7, 2012, 10:01:11 AM5/7/12
to Puppet Users


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

Philip Brown

unread,
May 7, 2012, 12:04:12 PM5/7/12
to puppet...@googlegroups.com


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 :)
 

Philip Brown

unread,
May 7, 2012, 12:16:04 PM5/7/12
to puppet...@googlegroups.com
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)


jcbollinger

unread,
May 7, 2012, 2:04:06 PM5/7/12
to Puppet Users


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

jcbollinger

unread,
May 7, 2012, 2:39:37 PM5/7/12
to Puppet Users
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

Philip Brown

unread,
May 9, 2012, 2:46:54 PM5/9/12
to puppet...@googlegroups.com


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 :-/

Gary Larizza

unread,
May 9, 2012, 2:55:01 PM5/9/12
to puppet...@googlegroups.com

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


--
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@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

Philip Brown

unread,
May 9, 2012, 3:10:00 PM5/9/12
to puppet...@googlegroups.com


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.


Philip Brown

unread,
May 10, 2012, 6:52:51 PM5/10/12
to puppet...@googlegroups.com


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? )


Gary Larizza

unread,
May 10, 2012, 6:59:36 PM5/10/12
to puppet...@googlegroups.com
You'll want to add "ensure => present" to the file_line resource and then run it again.  That should 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/-/o-L4mfgshu0J.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Philip Brown

unread,
May 10, 2012, 7:30:57 PM5/10/12
to puppet...@googlegroups.com


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


Gary Larizza

unread,
May 10, 2012, 7:37:14 PM5/10/12
to puppet...@googlegroups.com
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Philip Brown

unread,
May 10, 2012, 7:57:53 PM5/10/12
to puppet...@googlegroups.com


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.

Jeff McCune

unread,
May 11, 2012, 1:30:18 AM5/11/12
to puppet...@googlegroups.com
On Thu, May 10, 2012 at 4:57 PM, Philip Brown <ph...@bolthole.com> wrote:

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.

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.


Cheers,
-Jeff 

Reply all
Reply to author
Forward
0 new messages