Help me with a local Linux account management module

[David Reagan]

I'm pretty much brand new to Puppet. I've read the tutorials on puppet labs, and most of Pro Puppet. But there's still a lot I don't get. So I figured I'd learn by doing.

My current goal is to write a user account wrapper. It would only be for local Linux accounts only, only on Ubuntu for now.

I'm not just using the user type because I want to manage ssh authorized keys as well.

I did find https://github.com/dcsobral/puppet-users, and a few others. But I'm not fond of the use of csv files, and it seems like a simple enough module to learn with.

Wrapping user and ssh_authorized_key is simple, just pass in the information. But I do have a couple questions I couldn't find answers to in the docs, here, or Google.

Questions: 

• What happens when a group listed in the user type does not exist on the server?
  
• How do I figure out what hash to use for the password when creating a new user?
• Do I just copy the hash directly into the password property? No need to tell puppet what kind of hash it is?
• ssh_authorized_key: name has to be unique. So how do I add a key to more than one user?
• I'd like to simply pass in an array of links(?) to pub key files to my wrapper instead of the actual ssh key. How would I tell Puppet to split the contents at the spaces so I can get the key, type, and name properties out of it?

Future plans would be to manage shell configuration as well. But for now, all I need is what I've described above. 

Oh, when implementing this, does making a /etc/puppet/manifests/accounts/username.pp file per user, then including that file on the nodes that need that user, raise any "bad idea" flags for you?

[Ashley Penney]

On Fri, Apr 26, 2013 at 4:08 PM, David Reagan <jer...@gmail.com> wrote:

I'm pretty much brand new to Puppet. I've read the tutorials on puppet labs, and most of Pro Puppet. But there's still a lot I don't get. So I figured I'd learn by doing.

My current goal is to write a user account wrapper. It would only be for local Linux accounts only, only on Ubuntu for now.

I'm not just using the user type because I want to manage ssh authorized keys as well.

I did find https://github.com/dcsobral/puppet-users, and a few others. But I'm not fond of the use of csv files, and it seems like a simple enough module to learn with.

Wrapping user and ssh_authorized_key is simple, just pass in the information. But I do have a couple questions I couldn't find answers to in the docs, here, or Google.

Questions: 

• What happens when a group listed in the user type does not exist on the server?
  

Generally speaking you shouldn't let that happen!  The user resource will fail because it wants the group to exist first.  Create a group{} resource and in the user{} resource add something like require => Group['users'], or whatever, so that this doesn't happen.

 

• How do I figure out what hash to use for the password when creating a new user?

There's several ways to handle this.  Generally the way it's done is via a "custom function" that executes on the puppetmaster and injects the results of that run into the catalog for the client.  This way you can use a hash generator.  Something like https://github.com/kwilczynski/puppet-functions/blob/master/lib/puppet/parser/functions/random_password.rb

 

• Do I just copy the hash directly into the password property? No need to tell puppet what kind of hash it is?

It basically takes the contents of password and shovels it into the appropriate /etc/shadow column.

• ssh_authorized_key: name has to be unique. So how do I add a key to more than one user?

You'd want to structure this as a kind of custom_user{} define that was able to take keys as a parameter and those can be an array or hash of info.  This way you're basically listing all the keys per user rather than trying to assign keys to multiple users.

Because you'll have custom_user{ 'blah': } you'll be able to refer to the blah as $name in the define and then you can make your ssh_authorized_key names like:

ssh_authorized_key { "${name}-key": } so that they have unique names, I'll leave the rest of this up to your imagination as you'd need a unique -key bit per key you pass in.  That's one reason I suggested the keys param be a hash, so that you can have a name and then value and use that to build up the name cleanly.

 

• I'd like to simply pass in an array of links(?) to pub key files to my wrapper instead of the actual ssh key. How would I tell Puppet to split the contents at the spaces so I can get the key, type, and name properties out of it?

This stuff is tricky with the language as it stands.  The way I've solved this (and seen others solve this) in the past is that rather than trying to pass in arrays you build a hash in hiera for your users and then pass the entire hash to create_resources('mycustomusersdefine', hashname) to have it create a call to the define for each element of the hash.  If you google create_resources you should find some examples.

 

Future plans would be to manage shell configuration as well. But for now, all I need is what I've described above. 

Oh, when implementing this, does making a /etc/puppet/manifests/accounts/username.pp file per user, then including that file on the nodes that need that user, raise any "bad idea" flags for you?

It does, but only because even at this early stage you should start thinking "is this how to do a task, or the data the task needs?"  if it's data you should be thinking of 'hiera' and how you can use that to seperate your data from your manifests.

Good luck!

[David Reagan]

>There's several ways to handle this. Generally the way it's done is via a "custom function" that executes on the puppetmaster and injects the results of that run into the catalog for the client. This way you can use a hash generator. Something like https://github.com/kwilczynski/puppet-functions/blob/master/lib/puppet/parser/functions/random_password.rb

I meant, how do I tell what hash the server will know how to use? I
suppose it shouldn't matter much. I'll just copy the hash out of the
/etc/shadow file. If I get more than 10 users I'll want to figure out
how to use LDAP anyway.

I hadn't realized the ssh_authorized_key name wasn't limited to what's
in the users .pub file. So making those unique shouldn't be too hard.

>This stuff is tricky with the language as it stands. The way I've solved this (and seen others solve this) in the past is that rather than trying to pass in arrays you build a hash in hiera for your users and then pass the entire hash to create_resources('mycustomusersdefine', hashname) to have it create a call to the define for each element of the hash. If you google create_resources you should find some examples.

Haven't googled it yet. But it seems a bit more complicated than what
I want. I just want to read the .pub file, grab the type and key, then
use that to create an ssh_authorized_key. That way, when someone adds
or changes their .pub file, it's as simple as uploading the pub file
to the puppetmaster and we're done. Thus avoiding potential mistakes
that could occur if I (or they) formatted the key into json or yaml.

I would think I could do something like that with Ruby. But I'm not
sure how to integrate that into my module...

--David Reagan

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/YG0LpyzkzUo/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users...@googlegroups.com.
> To post to this group, send email to puppet...@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[David Reagan]

So, I just mocked up what I'm thinking of doing. 

How do I deal with loops? From what I can Puppet doesn't let you loop through arrays. 

See https://gist.github.com/jerrac/5543893 for a very very very rough draft of what I'm imagining this could look like.

How would you deal with multiple authorized keys, and only adding groups that exist on the server already?

--David Reagan