Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
That is frustrating, because information elsewhere (bugzilla.redhat.com/show_bug.cgi?id=605857#c1) suggested just the opposite. I'm new to Puppet, but it doesn't seem to very good at making edits to a file (other than with augeas), whereas it's very good at replacing files. This makes it difficult to make these changes directly to system-auth-ac, because I only want to make this one change and leave any other user modifications in place. It would be easy with sed. but that's the sort of thing we're trying to avoid... –  larsks Jul 21 '11 at 15:05
    
Hmmm, I see that there is an augeas "lens" for pam configuration files. Maybe I can make that work. –  larsks Jul 21 '11 at 15:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.