Puppet: comment créer et gérer des utilisateurs et des groupes Unix


12

La semaine dernière, j'ai consacré tous mes efforts à l'apprentissage de la marionnette. Maintenant, je souffre d'un débordement de tampon mental et peu de confiance en moi pour pouvoir apprivoiser cette bête. Je suis tombé sur de nombreux exemples annotés mais en raison de leurs innombrables variations, je n'arrive pas à discerner entre le style et les conventions de marionnettes recommandés (récents) et les approches ad hoc "fonctionne pour moi". Je ne peux pas le supporter car il semble concerner des trucs de base.

Donc. En utilisant Puppet pour gérer les groupes et les utilisateurs, le groupe principal des utilisateurs étant égal à leur propre nom d'utilisateur, d'autres groupes pourraient être lanpour les connexions LAN, wheelpour les administrateurs, shellpour les utilisateurs avec un shell sur des nœuds arbitraires, mailpour les utilisateurs, daemonspour divers démons. Les connexions administrateur seront sur tous les nœuds et pour aggraver les choses, une connexion LAN pourrait également être une connexion shell.

D'après ce que je comprends, il est normal de définir un utilisateur plusieurs fois si vous utilisez des définitions virtuelles qui sont réalisées à un moment donné. Cela semble fabuleux, alors comment cela fonctionne-t-il avec plusieurs groupes pour un utilisateur? Supposons que Bob puisse utiliser à la fois les nœuds LAN et le nœud beastie.wan; sa connexion est-elle thebobalors définie deux fois, dans lanusers.pp avec groups => ["lan"]et dans shellusers.pp avec groups => ["shell"]? Et si Bob veut que son mot de passe LAN soit distinct de son mot de passe shell?

Le code que j'utilise actuellement n'a pas de définitions virtuelles, les utilisateurs sont juste des inclusions simples codées en dur. À un moment donné, je suis tombé sur un exemple utilisant des virtuels et c'est là que je suis resté coincé parce que je ne comprends pas comment développer le code pour que Puppet crée un groupe principal et les groupes requis que j'ai définis en premier, puis rejoint l'utilisateur dans ces groupes .

Droite. S'il vous plaît, sais-moi correctement.

Réponses:


6

Maintenant, je souffre d'un débordement de tampon mental et peu de confiance en moi pour pouvoir apprivoiser cette bête.

Tout d'abord: détendez-vous. J'ai appris que, lorsque vous êtes nouveau dans quelque chose avec une courbe d'apprentissage comme Puppet, il est assez facile de se laisser submerger et de ne pas pouvoir faire grand-chose.

son login thebob est-il alors défini deux fois, dans lanusers.pp avec groups => ["lan"] et dans shellusers.pp avec groups => ["shell"]?

Nan. Définissez-le virtuellement en un seul endroit (peut-être users.pp) avec groups => ['shell', 'lan',].

Sur les nœuds, réalisez les utilisateurs dont vous avez besoin. Par exemple, si pour node beaminnous voulons tous les shellutilisateurs:

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

Et si Bob veut que son mot de passe LAN soit distinct de son mot de passe shell?

Ensuite, Bob devrait probablement obtenir 2 comptes différents avec des noms de connexion différents.


Merci. Vous avez raison sur la première partie, je suis devenu dépassé. Mais votre deuxième réponse a aidé, elle semblait mettre en mouvement d'autres pensées et maintenant j'ai un manifeste qui fonctionne correctement, avec des utilisateurs virtuellement définis qui sont réalisés à leurs emplacements appropriés. Merci de m'avoir aidé avec ça. :)
drumfire

Pas de problème. Avant les déclarations virtuelles, ce problème impliquait une solution très compliquée. Considérez-vous chanceux d'être venu à bord du Puppet express maintenant ;-).
Belmin Fernandez

J'utilise des déclarations virtuelles, mais j'ai besoin que certains utilisateurs soient dans le groupe "sudo" sur certains hôtes et pas sur d'autres. Cela ne résout pas ce scénario (et j'ai du mal à trouver quoi faire: D).
jjmontes

3

Puppet ne fonctionne pas bien avec une gestion compliquée des utilisateurs / groupes. Vous feriez bien mieux de déployer quelque chose comme LDAP - autant que je n'aime pas cela, cela fonctionnera beaucoup mieux que d'essayer de battre Puppet en soumission.


Ou FreeIPA. Puppet est agréable pour les comptes de service qui doivent être sur le système, mais ne gèrent pas les utilisateurs réguliers ...
ewwhite

4
Avec tout le respect que je vous dois (étant que vous êtes l'un des meilleurs membres de SF): Je ne pense pas que cela réponde à la question. Q: "Comment créer et gérer des utilisateurs et des groupes Unix dans Puppet?". R: "LDAP". Je crois que des réponses comme celle-ci correspondent mieux aux commentaires. Bien sûr, si cela a déjà été discuté dans Meta ou quelque chose, peut-être que je ne suis pas informé. Ne me déteste pas :-).
Belmin Fernandez

3
@ BeamingMel-Bin: Il y a un fort esprit de "bon outil pour le travail" sur SF. Si quelqu'un demande "quelle est la meilleure façon de frapper cette vis avec mon marteau pour la faire entrer?", Nous dirons "acheter un tournevis" et ne pas donner de longs traités sur les avantages des différentes techniques de marteau. En effet, la plupart des personnes interrogées ici sont si inexpérimentées ou ignorantes qu'elles ne savent pas qu'il existe de meilleures solutions, ni même que de meilleures solutions pourraient exister (et qu'elles ne savent donc pas demander "existe-t-il une meilleure façon de conduire dans ce domaine)? vis? "ou" quelle est la meilleure façon de conduire dans cette vis? ").
womble

1
@drumfire: Encore une fois, si vous demandez comment faire quelque chose de stupide, la bonne réponse est "ne faites pas ça". C'est comme ça que SF fonctionne. Nous ne sommes pas là pour aider les gens à faire des choses stupides, nous sommes ici pour créer des administrateurs système plus efficaces.
womble

3
SF, faisant partie de la trilogie originale, existe depuis bien plus longtemps et a un "esprit indépendant" beaucoup plus fort que d'autres sites SE plus homogènes. Il y a aussi la composition des utilisateurs à considérer. Les administrateurs système sont grincheux et opiniâtres.
womble
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.