Issue #1644 has been updated by rgsteele.
ctrlaltdel wrote: > rgsteele wrote: > > > For one, the resource title is used as the comment (and, I see no obvious > > way to change that). So, if I wanted to use something unique such as the > > key itself as the resource title, I'd end up with two separate copies of > > the key on the same line - once for the key, and again for the comment. > > Additionally, there is no way to add the same key to multiple files, unless > > I start coming up with creative naming schemes like > > "jsmith_rootkey_somehost", "jsmith_jsmithkey_somehost", > > "jsmith_jsmithkey_someotherhost", etc. It seems that a workaround like > > that is just a band-aid for a very limited mechanism. > > I agree but this point is definitely a duplicate of bug #1531. Agreed, sorry I missed that. I've taken this point to that ticket, and made some design suggestions on that point there. > > > In my opinion, the proper design would be to have ONE ssh_authorized_key > > resource per user, and that you should be able to provide an array for both > > the "target" and "key" attributes. This way, all the user's specified keys > > would be added to all the specified authorized_keys file for the host in > > question. In it's current state, ssh_authorized_keys offers me only a > > fraction of the functionality needed to satisfy what I believe are normal > > use cases. > > I cannot agree on this one, it is IMHO necessary to be able to manage each > key independently. If you want to manage the authorized_key file as a single > resource, why not use the file type ? I don't want to use the 'file' type to manage the authorized_keys file as a whole because I don't want to have to manage many authorized_keys files per server for every server I manage; in that regard, managing the keys and targets associated with a user is much less cumbersome. And on one side of the coin, I think that making the key fingerprint (or they key itself) the unique resource makes it harder to identify who it belongs to, and makes the manifests much more verbose when compared to having a single resource per user. If I could instead specify one ssh_authorized_key resource per user, it would be easy for me to see all the keys, types, and targets associated with that user all in one block, instead of many independent blocks (with a lot of redundant information, such as 'user', 'ensure', 'comment', etc). But on the flip side of the coin, I submit that it would be hard to associate a 'type', 'ensure', and other key-specific attributes to keys contained in an array, which lends strength to your argument that all keys must be managed independently. So maybe we do in fact have to just live with providing some redundant information if it makes more sense in the big picture. All that being said, I think this ticket can probably be closed. Although I think having one ssh_authorized_key resource per user would make the configs more concise and logically grouped, in the design sense it might not be the right way to go, and difficult to achieve. And, I've taken my first point to #1531. ---------------------------------------- Refactor #1644: ssh_authorized_keys needs to be completely refactored http://projects.reductivelabs.com/issues/show/1644 Author: rgsteele Status: Duplicate Priority: Normal Assigned to: ctrlaltdel Category: ssh Target version: unplanned The current implementation of ssh_authorized_keys seems to me to have several glaring design flaws. Take, for example, this following sample use case, as demonstrated by bartc from the IRC channel on Freenode: $ cat test.pp #!/usr/bin/env puppet ssh_authorized_key { "test": user => "bart", key => "foo", type => "ssh-rsa"; "bla": user => "bart", key => "bla", type => "ssh-rsa"; } $ ./test.pp notice: //Ssh_authorized_key[test]/ensure: created notice: //Ssh_authorized_key[bla]/ensure: created $ tail -2 /home/bart/.ssh/authorized_keys ssh-rsa foo test ssh-rsa bla bla For one, the resource title is used as the comment (and, I see no obvious way to change that). So, if I wanted to use something unique such as the key itself as the resource title, I'd end up with two separate copies of the key on the same line - once for the key, and again for the comment. Additionally, there is no way to add the same key to multiple files, unless I start coming up with creative naming schemes like "jsmith_rootkey_somehost", "jsmith_jsmithkey_somehost", "jsmith_jsmithkey_someotherhost", etc. It seems that a workaround like that is just a band-aid for a very limited mechanism. In my opinion, the proper design would be to have ONE ssh_authorized_key resource per user, and that you should be able to provide an array for both the "target" and "key" attributes. This way, all the user's specified keys would be added to all the specified authorized_keys file for the host in question. In it's current state, ssh_authorized_keys offers me only a fraction of the functionality needed to satisfy what I believe are normal use cases. ---------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
