Hi Felix, thanks for you reply :)
2009/1/19 Felix Schäfer <[email protected]> > > Am 19.01.2009 um 03:14 schrieb Paul Johnson: > > > Yeah, I read that documentation, but this still seems not so clear > > to me. > > I thought someone using gentoo would have a little more insight in ssl > certificate matters, but anyway, here it goes :-) > I understand how ssl certs work in general, but was not sure how they work in puppet :) > > > Here is my situation: > > I installed puppet on several hosts and signed certificates for them > > on master with puppetca some time ago. Recently I decided to rewrite > > my manifests and deny all servers to retrieve configs from master > > for that time. > > Why not just shut down the master, or shut down all the clients, or > use environments for a 2- or 3-tiered release process? Trying to > revoke certificates just to disable all hosts for a limited period of > time is not what the certificates were designed for. > I see, just wanted to know if I can use certs in puppet for temp disabling access to master > > > So I did puppetca --clean --all. This deleted all certificates from > > master as I wanted, but hosts are still fetching configs and I can't > > stop this now. I can't revoke them as well because puppetca says > > there is no certificate for any host on master. > > I don't think --clean --all deleted the certificates from the master, > if I understood you correctly, you deleted them by hand? I used --clean --all and it deleted the certs, here is one more try for one server, but with --all it deletes all certs as well: # puppetca --clean mysql.update.test Removing /var/lib/puppet/ssl/ca/signed/mysql.update.test.pem I would urge > you to let puppetca manage the certificates, it should have switches > to handle 99,9% of all conceivable situations, I think meddling "by > hand" with the certificates should only be done if you understand why > you can't do this meddling with puppetca. Anyway, you won't be able to > revoke the certificates if they are not present any more on the server > (basic ssl). Yep, it's pretty clear > > > > Probably I can generate the certificates on master for all the hosts > > and then revoke them, but this solution looks not right to me (and > > I'm not sure this will work ok), is there any more proper way to do > > this? If no, how can I let the hosts to continue to retrieve configs > > after revoking certificates from them? > > > I'm quite sure you'll be getting different certificates, so that won't > be any good. If you really want to stop the clients from checking with > the server at the ssl level, you could either erase the certificates > on the clients, or make the clients upload their certificates to the > server so that the server can revoke them, but you'll have to do that > by hand, and you'll have to remove the certificates on the clients if > you want them to check in again with the server, as the "old" > certificates will have been revoked. Got it, so will remove certs from clients. > > > All in all: the certification mechanism wasn't designed to "stop the > clients from checking in on the server while I meddle with the > recipes". To do that, you should use environments, check the wiki for > more info on that, but basically, you can have many sets of recipes on > the server (unstable/stable, or testing/production, or whatever you > want to call them), and define on the client which set they'll get, > and define the "default" environment on the server. > Ok, all is clear now, thank you very much for the nice explanation! > > Felix Schäfer > -- Paul Johnson > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
