Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This last week I spent all effort into learning Puppet. Now I suffer from a mental buffer overflow and little confidence of ever being able to tame this beast. I came across many annotated examples but due to their countless variations I fail to discern between recommended (recent) Puppet style and conventions, and ad hoc "works for me" approaches. I can't stand it because it seems to be about basic level stuff.

So. Using Puppet to manage groups and users, users' primary group equal to their own username, other groups could be lan for lan logins, wheel for admins, shell for users with a shell on arbitrary nodes, mail for users, daemons for various daemons. Admin logins will be on all nodes and to make things worse a lan login could be a shell login too.

From what I understand it's okay to define a user multiple times if you make use of virtual definitions that are realised at some point. Sounds fab, so how does that work with multiple groups for a user? Say Bob can use both LAN nodes and node beastie.wan; is his login thebob then defined two times, in lanusers.pp with groups => ["lan"] and in shellusers.pp with groups => ["shell"]? What if Bob wants his lan password to be separate from his shell password?

The code I currently use has no virtual definitions, users are just hard coded single inclusions. At one point I came across an example using virtuals and this is where I got stuck because I don't understand how to expand the code so that Puppet creates a primary group and the required groups I defined first and then joins the user in those groups.

Right. Please cluebat me properly.

share|improve this question
add comment

2 Answers 2

up vote 5 down vote accepted

Now I suffer from a mental buffer overflow and little confidence of ever being able to tame this beast.

First: Relax. I've learned that, when you're new to something with a learning curve such as Puppet, it is pretty easy to become overwhelmed and not be able to get much done.

is his login thebob then defined two times, in lanusers.pp with groups => ["lan"] and in shellusers.pp with groups => ["shell"]?

Nope. Virtually define it in one place (maybe users.pp) with groups => ['shell', 'lan',].

On the nodes, realize the users you need. For example, if for node beamin we want all shell users:

node beamin {
    Account <| groups == 'shell' |>
}

What if Bob wants his lan password to be separate from his shell password?

Then Bob should probably get 2 different accounts with different login names.

share|improve this answer
    
Thanks. You're right about the first part, I did become overwhelmed. But your second answer helped, it seemed to set other thoughts in motion and now I have manifest that works properly, with virtually defined users that are being realised at their proper locations. Thanks for helping me with that. :) –  drumfire Apr 22 '12 at 21:20
    
Not a problem. Before virtual declarations, this problem involved a very convoluted solution. Consider yourself lucky that you came on-board the Puppet express now ;-). –  Belmin Fernandez Apr 23 '12 at 21:57
    
I'm using virtual declarations, but I need some users to be in the "sudo" group on some hosts and not in others. This doesn't solve that scenario (and I'm having a hard time figuring out what to do :D). –  jjmontes Nov 15 '12 at 18:53
add comment

Puppet does not do well with complicated user/group management. You'd be far better off deploying something like LDAP -- as much as I dislike it, it'll work a lot better than trying to beat Puppet into submission.

share|improve this answer
    
Or FreeIPA. Puppet is nice for service accounts that need to be on the system, but not managing regular users... –  ewwhite Apr 21 '12 at 13:01
3  
With all due respect (being that you are a top SF member): I don't think this answers the question. Q: "How should I create and manage unix users and groups in Puppet?". A: "LDAP". I believe answers like this fit better as comments. Of course, if this has been discussed before in meta or something, maybe I'm just uninformed. Please don't hate me :-). –  Belmin Fernandez Apr 21 '12 at 17:42
3  
@BeamingMel-Bin: There's a strong spirit of "the right tool for the job" on SF. If someone's asking "what's the best way to hit this screw with my hammer to get it to go in?", we'll say "buy a screwdriver" not give lengthy treatises on the benefits of different hammer techniques. This is because most questioners here are either so inexperienced or ignorant that they're not aware that better solutions exist, nor even that better solutions could exist (and hence they don't know to ask "is there a better way to drive in this screw?" or "what is the best way to drive in this screw?"). –  womble Apr 21 '12 at 22:57
1  
@drumfire: Again, if you're asking how to do something stupid, the correct answer is "don't do that". It's how SF works. We're not here to help people do stupid things, we're here to make more effective sysadmins. –  womble Apr 22 '12 at 23:19
3  
SF, being part of the original trilogy, has been around a lot longer, and has a much stronger "independent spirit" than other, more homogeneous, SE sites. There's also the make-up of the users to consider. Sysadmins are cranky and opinionated. –  womble Apr 25 '12 at 4:46
show 5 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.