Felix,

Given the constraint to not delete keys from the file until all managed keys are instantiated, how about using concat_fragment to generate the authorized_keys file in the case of purge management? My understanding is that this will change the file atomically (eliminating the empty file problem in the PUP).

Apologies if that's far behind where you're at now,

Jeff

On 01/03/2014 07:35 PM, Felix Frank wrote:
Hi,

TL;DR version: Implementing the design in [2] is quite hard apparently.
Ideas welcome.

I'm working on a proof of concept of a solution for PUP-1174 [1]. .
Possible designs were discussed on the user list [2]. John came up with
a scheme that was silently consented as desirable. It's based around a
new parameter to the user type, working title 'purge_ssh_keys'. Its
value can be a list of paths to files from which purging should happen.

Implementing this is trickier than I thought. I pushed a shy attempt
(including some obnoxious printf debugging) to github [3]. The idea is
to generate fake key resources to make puppet touch the files in
question. So far so good.

The trouble is this: Even though puppet will consider additional
authorized_keys files in question during a transaction, their contents
are not included in Ssh_authorized_keys::ProviderParsed.instances (which
would be the requirement for purging from them).

The instances method for ParsedFile providers is based on its targets
method. This method returns (from what I gathered)
1. the default target for the provider
2. the files corresponding to any files opened during the current
transaction
3. if present, the targets of all resources passed as arguments

Since the instances method never passes any existing resources, and
ssh_authorized_key has no default target, the only viable source is (2),
which I hoped would be amended by my fake resources. However, the
resources type (resources { "ssh_authorized_keys": purge => true })
calls the instances method very early during the transaction. The fake
key resources have not come into play at this point yet. No dice.

A different idea I'd had was to extend the
Ssh_authorized_keys::ProviderParsed as well. (Example code has already
been obliterated, sorry.) If the additional targets could be kept in a
member variable, the targets method could be overridden to include them
in its return (list) value. The User type would add to this member
variable instead of generating actual resources.

The issue with this approach (I believe) is that User#generate is called
during compilation, and hence cannot send signals to the
Ssh_authorized_keys::ProviderParsed class (which does its work during
the transaction). In master/agent mode, these things actually happen in
separate ruby processes.

I thought of moving the signal passing to User#eval_generate instead,
but that appears to happen later than the generating of additional
resources for purging anyway.

Yet another idea is to generate additional ssh_authorized_key (with
ensure => absent) resources during User#eval_generate by grepping the
key names from the very files specified. But that seems unspeakably ugly
to me, because it duplicates (a subset of) the parsing logic implemented
in the Ssh_authorized_key::ProviderParsed.

As always, any input is greatly appreciated. But you already have my
thanks for even reading this far ;-)

Cheers,
Felix

[1] https://tickets.puppetlabs.com/browse/PUP-1174
[2]
https://groups.google.com/forum/#!msg/puppet-users/AgvUwA9RMLM/pNkDFpqaTdkJ
[3]
https://github.com/ffrank/puppet/tree/ticket/master/1581-purge-all-ssh-keys


--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/52C879ED.1050409%40bericotechnologies.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to