Puppet: Récupère le répertoire personnel des utilisateurs


12

Je crée un utilisateur comme suit

user { $username:
    comment => "$name",
    shell   => "$shell",
    managehome => false,
    password  => "$password",
    groups => $groups
}

Maintenant, comme vous pouvez le voir, je fais un managehome est faux Maintenant, plus tard dans la voie, je dois pousser un fichier vers le répertoire personnel de l'utilisateur.

$key = "${homedir}/${name}/file"

    file { $key:
    ensure => present,
    owner  => $username,
    group  => $username,
    mode   => 600,
    content => "$keyvalue",
    subscribe => User[$username],
}

Comment puis-je obtenir le répertoire personnel de l' utilisateur pour cela?

Réponses:


11

Hm, je pense que vous aurez besoin d'un module facter pour le faire et d'un petit fichier manifeste hacky ...

module facter: il enregistrera les variables facter pour tous les utilisateurs. comme "home_root" ou "home_apache".

require 'etc'

Etc.passwd { |user|

   Facter.add("home_#{user.name}") do
      setcode do
         user.dir
      end
   end

}

puis vous pouvez les utiliser dans votre fichier manifeste comme ceci:

$username = "root"
$home = "home_$username"
$home_path = inline_template("<%= scope.lookupvar('::$home') %>")

file { "$home_path/test.txt":
   content => "huhu",
}

Il y a peut-être une meilleure façon, mais je n'en ai pas peur.


Pouvez-vous me donner des indications sur l'endroit où mettre ces manifestes? J'ai ma classe de base dans init.pp et où dois-je aller?
Quintin Par

1
@QuintinPar je viens de commencer à télécharger des exemples de marionnettes ou des meilleures pratiques sur github. vous trouverez cet exemple (classe facter) ici: github.com/drandor/puppet-examples/tree/master/modules/user dont vous avez besoin pour avoir pluginsync activé sur votre maître et votre agent. le deuxième code peut être utilisé n'importe où dans vos fichiers * .pp. La configuration des marionnettes et les manifestes de nœuds (avec étapes) peuvent être trouvés ici: github.com/drandor/puppet-config
jfried

1
Si l'utilisateur n'existe pas encore sur la machine (un nouvel utilisateur est ajouté), le fait home_user n'est pas disponible. La création de nouveaux utilisateurs peut nécessiter deux exécutions de marionnettes. Lors de la première exécution, $ home_path est vide, ce qui peut entraîner des résultats indésirables.
Mikko

3

J'ai essayé de trouver une solution pour le même problème, et il s'est avéré préférable d'adopter une approche légèrement différente.

Définissez le répertoire personnel de manière explicite, par exemple:

user { $username:
    comment    => "comment",
    home       => "/home/${username}",
    managehome => false,
    # ...
}

Quand managehomeest faux, le répertoire personnel n'est même pas créé. Vous devez donc le définir spécifiquement. Il est souvent préférable de créer une définition personnalisée pour l'ensemble de l'utilisateur:

define custom_user($username, $password) {
    user { $username:
        home     => "/home/${username}",
        password => $password,
        # etc.
    }
    file { "/home/${username}":
        ensure  => directory,
        owner   => $username,
        require => User[$username],
        # etc.
    }
}

Vous pouvez ajouter d'autres paramètres, par exemple $keyvalue, et créer un fichier de clés si ce paramètre est donné.

Vous pouvez également définir une variable globale $home = "/home"(spécifique au système d'exploitation, si nécessaire) et obtenir le répertoire d'accueil avec "${home}/${username}".

Modifier: utiliser le hachage pour définir des répertoires de départ spécifiques à l'utilisateur

Les versions plus récentes de Puppet (> = 2.6) prennent en charge les hachages. Il serait possible de définir un hachage contenant des username => /path/to/homemappages pour chaque utilisateur:

$home = {
    normal_user => '/home/normal_user',
    backup      => '/var/backup',
    mysql       => '/var/lib/mysql'
}

Pour n'importe quel nom d'utilisateur, il est alors facile d'obtenir le répertoire personnel avec $home['username'].

Hachage du répertoire personnel avec repli

La plupart du temps, il serait préférable d'avoir un "défaut de secours" si l'utilisateur n'existe pas dans le hachage. En théorie, cela est possible, bien que la syntaxe devienne un peu cryptique et gonflée:

$home = { ... }
$default_home = '/home'

user {$username:
    home => has_key($home, $username) ? {
                true => $home[$username], 
                false => "${default_home}/${username}" 
            }
    # ...
}

2
Cela ne fonctionne pas lorsque / home n'est pas la valeur par défaut. say / var / lib / psql
Quintin Par

@Barry: Avez-vous lu le reste de la réponse, "répertoires personnels spécifiques à l'utilisateur"? (La réponse a été modifiée après le commentaire de Quintin Par)
Mikko

@Mikko Yeap, et j'ai essayé de voter pour la bonne réponse (acceptée). Il était verrouillé.

0

Cette question est ancienne, mais toujours d'actualité. Il y a en fait une meilleure façon maintenant. Ajoutez un fait personnalisé à [module] /lib/facter/home_dirs.rb contenant les éléments suivants:

require 'etc'

Facter.add(:home_dirs) do
  setcode do

    home_dirs = {}   
    Etc.passwd { |user|
      home_dirs[user.name] = user.dir
    }

    home_dirs

  end
end

Ensuite, vous pouvez accéder ainsi aux données du manifeste:

$facts['home_dirs']['some_username']

Gardez à l'esprit que cela ne fonctionne que si l'utilisateur existe déjà avant l'exécution de la marionnette. Si l'utilisateur est créé pendant l'exécution, le répertoire personnel doit être déjà connu ou au moins prévisible. La marionnette est conçue pour créer de l'ordre, après tout.

J'espère que cela aide quelqu'un.

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.