On Friday, August 10, 2012 9:50:00 AM UTC-5, banjer wrote:
>
>
> If there is a new "foohost" client then you may not need to do anything.
>> If not, then yes, you should clear its configuration out of your
>> storeconfigs DB.
>>
>>
> Its a new hostname as well as a new key. I wasn't clear on that
> earlier. Also, I had run `puppet node clean foohost` before fyi. Lets
> call the old host *foohost* and the new one *newhost.*
>
> My goal is to have 50 hosts with the same ssh_known_hosts file, which will
> contain the keys for the 50 hosts, so from what I understand I need to use
> sshkey as an "exported" resource. Perhaps I'm not understanding local vs
> exported resources though.
>
Exported resources are a good choice for this purpose. They allow each
node to declare its key on behalf of all the others (and it itself), which
can be darn convenient. This is exactly the sort of thing they are
designed for.
The characteristics distinguishing exported resources from ordinary
resources are
1. they are accessible to all nodes, not just the one that declares them,
2. they are added to the catalogs of only those nodes that collect them
(which do not have to include the nodes that declare them), and
3. there is no 3
It is because of (1) that exported resources' (type, title) combinations
should be unique across the site. It is because there is no 3, etc. that
exported nodes' (type, title) cannot duplicate those of resources declared
locally on the nodes that collect them. Ultimately, those both follow from
what I suspect is the key point you're missing: exported resources are no
different from any others once they are collected.
>
> It seems to me that if if the hostnames are different, then there
> shouldn't be a problem with the two resource declarations coexisting in my
> manifest, as the type-title combo should be unique, right?
>
You effectively extend the contents of your manifest to include the
declarations of all the exported resources you collect. So it *is* a
problem if your manifest declares a resource (whether plain, virtual, or
exported) that matches one it collects elsewhere.
> A solution I've come up with is to have ONLY this declared:
>
> # remove key
> @@sshkey { "foohost":
> ensure => absent,
> type => "rsa",
> }
>
>
I'm supposing that the class containing that declaration is assigned to
every node, or at least to every one that in the group that are sharing
keys. So every node is going to export that Sshkey and collect it (or some
other node's copy of it). Why? Every node already knows the key is
supposed to be absent, so it doesn't need any of the others to tell it
that. It would be better, therefore, to make the resource an ordinary
one. Generally speaking, exported resources should always be specific to
the node exporting them.
At this point you may be stuck, however. Making the resource local is a
problem if nodes are going to collect another copy of the same resource.
Ordinarily you would expect cleaning foohost's config from the DB to
resolve that (thus you would do so after decommissioning foohost but before
declaring its key absent on your other nodes), but now that you have all
your other nodes exporting Sshkey['foohost'] you have no easy way to clear
out all those exported records.
> Sshkey <<| |>>
>
> and then let my puppet agents pull down their configs and thus handle the
> removal of foohost from ssh_known_hosts. Later today, I'll remove this
> declaration and put back in:
>
> # add keys
> @@sshkey { $hostname:
> ensure => present,
> type => "rsa",
> key => $sshrsakey,
> }
>
> Sshkey <<| |>>
>
> Not the prettiest solution, but this situation where we rebuild a host
> with a new hostname isn't that common.
>
> Now, with all that said, I can see in my storedconfigs DB which is also
> shared by Foreman, that there are some records for sshkey and foohost that
> still exist. Not sure how to clean this out (is puppet node clean foohost
> the correct way?), other than a postgres query.
>
Since you ran puppet node clean (after foohost was decommissioned, I
presume) I would think that the records you are now seeing for
Sshkey[foohost] are the ones being exported by the other nodes. You are
begging for trouble (and indeed have found some) when you export resources
that are not specific to the nodes for which they are declared.
This is the procedure I would recommend in the future:
1. Decommission a node, "foohost" for example.
2. Once you are confident that foohost will never again contact the
puppetmaster, clean its configuration out of your storeconfig DB by running
"puppet node clean foohost" on the master
3. Declare *local* resources on all your nodes to clean out any of
foohost's exported resources that were previously collected and applied.
That would be very much like what you actually did, but as local resources
instead of exported ones.
The local declarations added to cleaning out resources previously collected
from the late foohost can stay around as long as you wish. That can be
convenient if you have to accommodate the possibility of some nodes not
checking in within a narrow window (e.g. laptops or machines down for
maintenance, or if you use an extended sync interval).
Alternatively, before you decommission a node, you could make it itself
export "ensure => absent" versions of its exported resources. In that case
you would want to *avoid* cleaning those out of the database, at least
until you're confident that all the other nodes have collected and applied
them. It wouldn't be too bad to leave them indefinitely, especially if
you're using thin storeconfigs.
With either of those you would not have to switch from ordinary operations
to cleanup mode and back; instead the cleanup would be a natural part of
your ordinary operations.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/PQ3027jL7dgJ.
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-users?hl=en.
