Existe-t-il un moyen d'avoir une marionnette pour créer un dossier d'accueil d'un user (managehome), mais ne pas supprimer quand il est «absent»?

Ma première pensée était de faire quelque chose comme ça:

define my_user( $name = $title, $ensure = present, $uid, $gid, $password, $groups, $comment, $shell ) { $managehome = $ensure ? { present => true, default => false, } user { $name: ensure => $ensure, managehome => $managehome, uid => $uid, gid => $gid, password => $password, groups => $groups, comment => $comment, shell => $shell, } } 

Quelques problèmes avec ceci:

  • Si je voulais utiliser un autre atsortingbut de type d' user , je devrais changer my_user en deux endroits.
  • Je devrais changer toutes user déclarations d'user pour utiliser my_user .
  • J'aimerais plutôt utiliser un type embedded puis un type défini.

Peut-être y a-t-il:

  • Une façon d'attraper tous les parameters à un type défini et de le transmettre comme attributes à un type embedded.
  • Une façon encore plus élégante de le faire sans utiliser de types définis.

Quelqu'un a-t-il des recommandations?

2 Solutions collect form web for “Existe-t-il un moyen d'avoir une marionnette pour créer un dossier d'accueil d'un user (managehome), mais ne pas supprimer quand il est «absent»?”

Il existe quelques façons de gérer cela, vous pouvez simplement utiliser votre vérification ternaire directement dans la déclaration de l'user comme suit:

 user { $user: ensure => $ensure, managehome => $ensure ? { present => true, default => false, }, uid => $uid, gid => $gid, password => $password, groups => $groups, comment => $comment, shell => $shell, } 

Cela suppose que vous paramétrer vos valeurs ici, et je suppose que ce n'est pas forcément le cas. Vous auriez toujours le problème de devoir mettre à jour toutes vos references de type qui peuvent être un peu pénibles. Au lieu de cela, vous pouvez utiliser quelque chose de beaucoup plus puissant, la fonction create_resources . Considérons l'extrait suivant d'un file de marionnettes:

 class profile::base { $user_params = { 'user1' => { ensure => absent, managehome => false, uid => '1337', gid => dev, }, 'user2' => { uid => '1338', gid => ops, groups => ['wheel', 'company'], }, } $user_defaults = { ensure => present, managehome => true, groups => ['users', 'company'], comment => 'Managed by puppet', shell => '/bin/bash', } create_resources(user, $user_params, $user_defaults) ... } 

Donc, ce qui se passe ici, c'est que la fonction create_resources prend le hash $ user_params et crée dynamicment une ressource pour chaque input en utilisant les parameters fournis. De plus, tous les parameters non fournis par $ user_params utilisent des valeurs à partir de $ user_defaults hash. Le code ci-dessus évalue efficacement à l'extrait suivant. (Si vous n'êtes pas familier avec la fonction create_resources, je vous recommand vivement de le lire ici )

 class profile::base { user { 'user1': ensure => absent, managehome => false, uid => 1337, gid => dev, groups => ['users', 'company'], comment => 'Managed by puppet', shell => '/bin/bash', } user { 'user2': ensure => present, managehome => true, uid => 1338, gid => ops, groups => ['wheel', 'company'], comment => 'Managed by puppet', shell => '/bin/bash', } ... } 

Cela vous permet d'append rapidement / modifier des attributes sur tous les users que vous souhaitez gérer sans avoir à find toutes les references. Dites que si vous souhaitez passer à l'aide de ksh pour votre entreprise, vous modifiez simplement la valeur dans le hash user_defaults pour le refléter. Il n'y a rien qui vous empêche d'avoir différents groupes de parameters et parameters par défaut (disons $ root_params et $ root_defaults pour vos super-users) et ont un autre appel de fonction create_resources.

En prenant cette idée un peu plus loin, vous pouvez associer ce concept aux données de Hiera. La solution ressemblerait à ceci:

 class profile::base { $user_params = hiera("user-params") $user_defaults = hiera("user-defaults") create_resources(user, $user_params, $user_defaults) ... } 

Beaucoup plus propre et plus facile à lire. Le file de jeradata json correspondant ressemblerait à ceci:

 { "user-params": { "user1": { "ensure": "absent", "managehome": "false", "uid": "1337", "gid": "dev" }, "user2": { "uid": "1338", "gid": "ops", "groups": ["wheel", "company"] } }, "user_defaults": { "ensure": "present", "managehome": "true", "groups": ["users", "company"], "comment": "Managed by puppet", "shell": "/bin/bash" } } 

Personnellement, je préfère JSON pour ma hiérarata, mais YAML est également une option viable ( Hiera Data Sources ). Bonne chose à propos d'Hiera, c'est que vous pouvez utiliser différentes sources de données en fonction des critères que vous décidez et configurez dans le file hiera.yaml (généralement effectué par environnement, mais pourrait être par nœud)

En tant que dernière pensée, vous voudrez peut-être envisager d'écrire un type personnalisé pour envelopper le type d'user qui:

  • Archivez le directory personnel d'un user si assurez-vous => absent
  • Recherchez et rétablissez un directory archivé si assurez-vous => présent
  • Utilisez le type d'user embedded normalement avec managehome => true

Si vous décidez de prendre cette route, vous obtiendrez toujours beaucoup d'avantages en utilisant la fonction create_resources et Hiera

Il existe une approche less élégante pour les parameters facultatifs dans ce scénario.

 my_user($ensure = 'present', $uid = undef) { if $uid != undef { User { uid => $uid } } user { $name: ensure => $ensure } } 

Vous avez simplement assigné des parameters de ressources pour les user dans la scope de la définition. Vous pouvez répéter ce model pour un nombre arbitraire de parameters.

  • Est-ce que IIS peut gérer un deployment d'applications Web sous une charge d'user modérée?
  • migration des users de domaine de Ichain vers UAG
  • Comment restreindre un user linux à lire uniquement un dossier spécifique
  • Utilisateur GPO d'export Active Directory
  • Comment puis-je append un super user MySQL avec des permissions root?
  • Perspectives d'abus de courrier électronique - Guide pour l'label de courrier électronique?
  • Le journal d'access Nginx montre l'user authentifié "admin"
  • MySQL: Réplication de la database MySQL
  • Est-ce que les 50 users de l'aéroport sont les mêmes dans les configurations de points d'access multiples?
  • Authentification de key publique SSH - une seule key publique peut-elle être utilisée pour plusieurs users?
  • Campagnes de sensibilisation à la security
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.