13

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.

2 Answers 2

6

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.

3
  • 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, 2012 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 ;-). Apr 23, 2012 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, 2012 at 18:53
3

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.

10
  • Or FreeIPA. Puppet is nice for service accounts that need to be on the system, but not managing regular users...
    – ewwhite
    Apr 21, 2012 at 13:01
  • 4
    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 :-). Apr 21, 2012 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, 2012 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, 2012 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, 2012 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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