We are handling the certs in our kickstarts by grabbing a tarball of certs from the puppetca via a web interface. This assumes that DNS is setup for the host.
Cheers, -g =========kickstart snippet====================================== %post # delete junk puppet cert find /var/lib/puppet/ssl/ -type f |grep localhost | xargs rm -f # setup puppet cert curl -k https://puppetca | tar xC / ================================================================ =========gencert.php============================================ <?php # don't assume we have a path $gencert = "/usr/sbin/puppetca -g"; $tar = "/bin/tar"; $sudo = "/usr/bin/sudo"; # set some paths up. $cabase = "/var/lib/puppet/ssl/"; $certdir = "$cabase/certs"; $private = "$cabase/private_keys"; # yeah, its reverse DNS, but don't assume its safe. $host = escapeshellarg(gethostbyaddr($_SERVER['REMOTE_ADDR'])); # create the certs exec("$sudo $gencert $host", $out, $ret); $ret && error_log("Error creating cert for $host: $out\n"); # tar up the three files we need to make the client work. exec("$sudo $tar -c $certdir/$host.pem $private/$host.pem $certdir/ca.pem 2>/dev/null", $certs, $ret); $ret && error_log("Error tar'ing cert for $host: $certs\n"); # most of this is useless, but it will give curl an idea of what to expect in terms of content header("Content-Description: File Transfer"); header('Content-disposition: attachment; filename='.$host.'tar'); header("Content-Type: application/octet-stream"); header("Content-Transfer-Encoding: binary"); # and the content goes here. print join("\n", $certs); ?> ================================================================ Fabien Dupont wrote: > > > 2009/5/1 Christian Horn <[email protected] <mailto:[email protected]>> > > On Fri, May 01, 2009 at 02:27:56PM -0400, Michael DeHaan wrote: > > Christian Horn wrote: > > > On Fri, May 01, 2009 at 08:15:16PM +0200, Fabien Dupont wrote: > > > > > >> As far as the Puppet instance is on the > > >> same server it wouldn't be difficult to call puppetca and we > could think of > > >> downloading certificates from Cobbler SVC during installation > time through a > > >> snippet. > > >> > > > > > > I wouldnt want the cert including the needed private key beeing > trans- > > > ferred over the net in the clear. > > > Letting cobbler doing the signing of the cert (with accompanying > > > private key beeing only on the newly deployed box) sounds fine > thou. > > > > > > A bit better than autosigning since cobbler will only sign the > > > certs of cobbler-deployed boxen and not some rogue new box on the > > > network. > > > > If I understand this correctly, this would be something like having > > cobblerd periodically check puppetca to see if any hostnames it new > > about where in the list? > > > > I'm not sure this is a good job for cobblerd (we don't even do > this for > > Func), but it could be done pretty easily as a Cobbler-XMLRPC-API > using > > script, I think, that you could put on cron. > > Just signing could be done by cron or by puppets autosigning. > Just heard a nice speech yesterday with a nice puppet deployment, > but not autosigning since everyone on the net could then set > up a box with puppet, have the cert autosigned and fetch maybe > data that only puppet-clients should get. > > The cobbler-server would know the new box was deployed with > puppet, so the cert-request could be trusted more than random > new certs. > Thats the additional use i had in mind reading the post. > > > Yes, certificate download could be limited to the host by ACLs based > upon IP/MAC address (as it's stored in Cobbler). Spoofing this is not > that trivial... > > > Christian > _______________________________________________ > cobbler mailing list > [email protected] <mailto:[email protected]> > https://fedorahosted.org/mailman/listinfo/cobbler > > -- Garrett Honeycutt Sr. Systems Engineer www.speakeasy.net _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
