7 votes

Eric Noob avatar

La configuration de Puppet utilisant augeas échoue si elle est combinée avec notify

Demandé el 20 de Juillet, 2011
Quand la question a-t-elle été
2894 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai un problème avec le manifeste Puppet suivant, qui est censé d'activer le passwdqc pam sur un système RHEL-6 (en utilisant le module Puppet 0.25.5 et augeas 0.7.2) :

augeas { 'authconfig':
        context => '/files/etc/sysconfig/authconfig',
        changes => [
                'set USEPASSWDQC yes',
                'set USECRACKLIB no',
                ],
        notify  => Exec['authconfig-all'],
}

exec { 'authconfig-all':
        command         => '/usr/sbin/authconfig --updateall',
        refreshonly     => true,
}

Si j'exécute ce manifeste, il semble se terminer avec succès :

info: Applying configuration version '1311189237'
notice: //Augeas[authconfig]/returns: executed successfully
info: //Augeas[authconfig]: Scheduling refresh of Exec[authconfig-all]
notice: //Exec[authconfig-all]: Triggering 'refresh' from 1 dependencies

Mais si j'examine le fichier cible, les modifications n'ont pas été appliquées :

# egrep 'PASSWDQC|CRACKLIB' /etc/sysconfig/authconfig
USECRACKLIB=yes
USEPASSWDQC=no

Si je retire le notify => ... de la ligne du manifeste, cela fonctionne exactement comme prévu. C'est-à-dire, étant donné ceci :

augeas { 'authconfig':
        context => '/files/etc/sysconfig/authconfig',
        changes => [
                'set USEPASSWDQC yes',
                'set USECRACKLIB no',
                ],
}

Les modifications sont enregistrées avec succès :

# puppet /path/to/manifest.pp
info: Applying configuration version '1311189502'
notice: //Augeas[authconfig]/returns: executed successfully

# egrep 'PASSWDQC|CRACKLIB' /etc/sysconfig/authconfig
USECRACKLIB=no
USEPASSWDQC=yes

Une idée de ce qui se passe ici ? Évidemment, Puppet croit que le changement est effectué la première fois, mais il n'est pas réellement enregistré sur le disque. Nous avons d'autres configurations utilisant des augeas et des opérations de notification qui fonctionnent très bien ; nous n'avons pas été en mesure de comprendre pourquoi cette configuration échoue. Notez que le même problème existe si je remplace notify sur l'opération augeas avec subscribe sur les exec définition.

Mon plan actuel est de construire des paquets à partir de versions plus récentes de Puppet et d'augeas et voir si le problème disparaît par magie.

UPDATE Le président : freiheit fait remarquer que authconfig semble écraser ce fichier. Bizarrement, sous CentOS 5, la modification de /etc/sysconfig/authconfig et ensuite exécuter authconfig --updateall était exactement la procédure correcte. C'est ce que nous utilisons actuellement dans notre ancien Kickstart.

Donc apparemment la mise à jour de RHEL6 a fait authconfig se comportent de manière étrange et peu utile.

Demandé el 20 de Juillet, 2011 par Eric Noob

Réponses

Trop de publicités?

7voto

Eric Noob avatar
Eric Noob Points 531

Une partie de la réponse est que le comportement des authconfig a changé entre RHEL5 et RHEL6. Dans RHEL6, au lieu de lecture /etc/sysconfig/authconfig et ensuite générer la configuration, authconfig dans RHEL6 semble analyser chaque fichier de configuration individuel qu'il gère, puis génère /etc/sysconfig/authconfig comme un enregistrement de l'état actuel.

Cela signifie que l'on doit modifier les fichiers de configuration directement si l'on (a) essaie d'éviter d'exécuter la commande authconfig ou (b) en essayant de tirer parti de fonctionnalités qui ne sont pas prises en charge par la commande authconfig ligne de commande.

C'est ce que j'ai obtenu pour permettre à la passwdqc Module PAM :

augeas { 'pam_passwdqc':
    context => '/files/etc/pam.d/system-auth-ac/',
    changes => [
        'rm *[module="pam_cracklib.so"]',
        'ins 9999 before *[type="password"][module="pam_unix.so"]',
        'set 9999/type password',
        'set 9999/control requisite',
        'set 9999/module pam_passwdqc.so',
        'set 9999/argument enforce=everyone',
    ],
    onlyif  => 'match *[module="pam_passwdqc.so"] size == 0',
    notify  => Exec['authconfig-update-all'],
}

exec { 'authconfig-update-all':
    command     => '/usr/sbin/authconfig --updateall',
    refreshonly => true,
}

Si vous lisez cette réponse, j'aimerais que vous me disiez si cette façon de faire est saine ou non. Je suis nouveau dans le monde de Puppet et je suis encore en train de me familiariser avec la façon dont les choses fonctionnent.

Répondu el 22 de Juillet, 2011 par Eric Noob (531 Points )

1voto

freiheit avatar
freiheit Points 14144

En /usr/sbin/authconfig --updateall écrit dans /etc/sysconfig/authconfig -- Vous pouvez le confirmer avec un simple "ls -l". Il écrase les changements effectués par Puppet/augeas.

Si c'était moi, je m'occuperais de ce problème en déterminant les changements sous-jacents dont vous avez besoin et en les effectuant, ce qui, à mon avis, est tout à fait possible. /etc/pam.d/system-auth-ac . Cela rendrait également trivial le contrôle des différents paramètres du module.

Répondu el 21 de Juillet, 2011 par freiheit (14144 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X