In theory, the dependancy of the ssh_authorized_key upon the user makes sense, but in practice it fails.
You can’t create the ssh_authorized_key until the user exists, check. You can’t remove the ssh_authorized_key unless the user fails… fail.
There’s no simple way to order this such that an ssh key is removed when the user is removed.
The only way around this problem is the rather ugly:
if $ensure == 'absent' {
ssh_authorized_key{ "system-$username":
ensure => absent,
name => "system-$username",
target => "/etc/ssh/keys/$username",
user => $username,
type => $keytype,
key => $key,
before => User[$username],
}
}
user { $username:
ensure => $ensure,
comment => $comment,
home => $home,
shell => $shell,
uid => $uid,
gid => $groupname,
managehome => true,
system => false,
require => Group[$groupname]
}
if $ensure == 'present' {
ssh_authorized_key{ "system-$username":
ensure => present,
name => "system-$username",
target => "/etc/ssh/keys/$username",
user => $username,
type => $keytype,
key => $key,
}
}
That seems a long bit unpuppet-like.
You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account
I’d also like to point out that this problem isn’t just a quiet annoyance. Unless the double-ifed syntax above is used, removal of the user causes a puppet agent run failure report every $runinterval.
As the 2.7.x line is winding down, I am removing the target at 2.7.x from tickets in the system. The 2.7 line should only receive fixes for major problems (crashes, for instance) or security problems.