Puppet configuration using augeas fails if combined with notify
I'm having a problem with the following Puppet manifest, which is meant
to enable the passwdqc
pam module on a RHEL-6 system (this is using
Puppet 0.25.5 and 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,
}
If I run this manifest, it appears to complete successfully:
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
But if I examine the target file, the changes have not been applied:
# egrep 'PASSWDQC|CRACKLIB' /etc/sysconfig/authconfig
USECRACKLIB=yes
USEPASSWDQC=no
If I remove the notify => ...
line from the manifest, it works
exactly as intended. That is, given this:
augeas { 'authconfig':
context => '/files/etc/sysconfig/authconfig',
changes => [
'set USEPASSWDQC yes',
'set USECRACKLIB no',
],
}
The changes are successfully saved:
# 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
Any idea what's going on here? Obviously puppet believes that the
change is being made the first time around, but it's not actually
getting saved to disk. We have other configurations using augeas and
notify operations that work just fine; we haven't been able to figure
out why this is failing. Note that the same problem exists if I replace notify
on the augeas operation with subscribe
on the corresponding exec
definition.
My current plan is to build packages out of more recent versions of puppet and augeas and see if the problem will Magically Go Away.
UPDATE: freiheit points out that authconfig
appears to be overwriting this file. Oddly enough, under CentOS 5, modifying /etc/sysconfig/authconfig
and then running authconfig --updateall
was exactly the correct procedure. This is what we're actually using in our legacy Kickstart.
So apparently the RHEL6 upgrade has made authconfig
behave in strange and unhelpful ways.
Solution 1:
Part of the answer is that the behavior of the authconfig
command changed between RHEL5 and RHEL6. In RHEL6, instead of reading /etc/sysconfig/authconfig
and then generating the configuration, authconfig
in RHEL6 appears to parse each individual configuration file that it manages, and then generates /etc/sysconfig/authconfig
as a record of the current state.
This means that one has to edit configuration files directly if one is either (a) trying to avoid running the authconfig
command, or (b) trying to take advantage of features that aren't supported on the authconfig
command line.
This is what I ended up with to enabled the passwdqc
PAM module:
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,
}
If you find yourself reading this answer, I'd love to hear your comments on whether or not this is sane way of handling things. I'm new to Puppet so I'm still feeling my way around the way things work.
Solution 2:
The /usr/sbin/authconfig --updateall
command writes to /etc/sysconfig/authconfig -- You can confirm this with a simple "ls -l". It's overwriting the changes that puppet/augeas makes.
If it were me, I'd handle this by figuring out what the underlying changes you need are and making those, which I believe are all to /etc/pam.d/system-auth-ac
. That would also make it trivial to control the various parameters to the module.