Issue #1531 has been updated by rgsteele.
I had a conversation with Luke on this topic, included below. Essentially, we both feel that having the 'target' attribute support arrays is the easiest fix for this, as it won't require composite keys, won't require 50 resources for 50 different authorized_keys files (only ONE, a huge savings), and code-wise should be much simpler to implement. <pre> <rgsteele||work> lak: Don't suppose you've had a chance to take a gander at http://projects.reductivelabs.com/issues/show/1531 at all today? If not, no worries. <lak> what would the name of the key be if it's not the comment? <rgsteele||work> lak: The key hash itself. <rgsteele||work> The comment is way too likely to cause collisions. <rgsteele||work> The key itself will almost always be unique. <lak> rgsteele||work: why would the comment have collisions? <lak> and if so, why not just use a comment w/out them? <rgsteele||work> For example, if you create a dsa and rsa key at the same time, they'll both have the same comment. <rgsteele||work> It seems to me that the easy way around this is to have the key be the unique name, instead of trying to dream up comment naming schemes like "dan_rootkey_somebox", "dan_dankey_somebox", "dan_dankey_someotherbox". <rgsteele||work> And just provide an array of 'target' files. <rgsteele||work> This way, you can have multiple files for one key, without elaborate naming schemes. <rgsteele||work> And, you don't have to worry about a composite key. <rgsteele||work> lak: It seems the advantages here over composite keys is that it's simpler to implement, still allows you to have multiple key files per key, and does so using a single resource instead of many. <lak> if you have multiple keys per comment, then the solution should be to refactor the type to support that, i would think <lak> but maybe not <rgsteele||work> lak: Well, this solution does allow multiple keys per comment, without a huge code overhaul. All that really needs to happen is for the 'target' attribute to support arrays, and behind the scenes, the ssh_authorized_key type could assign the comment to a 'comment' attribute, instead of the current (admittedly poorly) method of assigning it to 'name'. <rgsteele||work> Maybe it's just me, but if the user's key belongs in 50 authorized_keys files, it makes way more sense to have one resource with an array of 50 targets, than 50 wholly separate resources. <rgsteele||work> Especially if they accomplish the same thing. <lak> rgsteele||work: i agree that target should support arrays <rgsteele||work> lak: Then, in that case, can we remove the blocking on #1531 by the ticket assigned to composite keys? <rgsteele||work> This way, we can hopefully get it out sooner, since the implementation is simpler. <lak> can you open a different ticket for the target being an array? <lak> that's essentially orthogonal to what the namevar is <rgsteele||work> lak: I'm still not sure we really need composite keys to solve #1531. The key alone is all we really need if target supports arrays. <rgsteele||work> It really makes the big chunk of that ticket moot. <lak> i guess you're right <lak> the key still really feels like an attribute rather than the namevar, but i guess, generally, it's unique in a given file </pre> ---------------------------------------- Bug #1531: ssh_authorized_keys should not use the key 'comment' as a unique identifier (name) http://projects.reductivelabs.com/issues/show/1531 Author: PaulBoven Status: Accepted Priority: Normal Assigned to: ctrlaltdel Category: Target version: Complexity: Unknown Affected version: 0.24.4 Keywords: Currently the ssh authorized keys provider uses the 'comment' section from an SSH public key as the 'name'. However, this implies that these comment strings must be unique, while SSH itself imposes no such restriction: in fact, it often happens that users generate both an RSA and a DSA key, which by default will have the same comment. A better 'name' for a key would perhaps be its fingerprint. There is a very small chance of collisions, but using the comment as 'name' is certain to generate collisions (for me it already has). Otherwise, the key-string itself should perhaps be the 'name' as this is certainly unique. If a user just changes the 'name' of the key in the Puppet manifest, then the other problem is that Puppet (only looking at the 'name', not the contents of the key) fails to realize that a key is already in place so you end up with duplicates. The current implementation doesn't really manage authorized_keys, it only manages the comment section and has no knowledge of the actual key. Using the key fingerprint would require Puppet to be able to actually extract the fingerprint from the key and would be a non-trivial change. ---------------------------------------- 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://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
