You could also have two custom types, one that creates keys and one that purges. The ones that create/manage, can be autorequired by the one that purges.
Alternatively, you can use 'flush' to only purge when the last key management type is executed on the system. It's a bit cumbersome, but the general idea can be found at https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/ . Trevor On Sat, Jan 4, 2014 at 4:15 PM, Jeff Bachtel < [email protected]> wrote: > 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 [email protected]. > 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. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWa9GbsiAiWb9wZyb-Qn__FNmftd6FfcCyWXYo2pp%3DzUw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
