Adam Clark wrote:
HI Eric,
Thanks for the reply. I'm using PE 3.3.1 with naive autosigning
which works well, I just assume policy based was working too.
I'm new to Puppet and just doing some proof of concept work.
One thing I haven't got a good grip on is when does facter go out and
gather the facts? Can it gather them independently of or puppet agent
being run? Are they available before puppet agent is run for the
first time?
I can't really answer this question as puppet is always run as part of
the install script.
Puppet runs facter after it pluginsyncs but before it requests the
catalog from the master. It doesn't execute /usr/bin/facter directly but
rather uses facter as a library, so puppet can't easily use a
pre-existing cache of facts. Because custom facts could be
pluginsync'ed, to get the same behavior without actually running the
agent you'd need to run "puppet plugin download" then "facter -p" (both
as root) so it uses the correct config file and directories.
What I would like to do is this:
* Create a website in which takes request that have a vmware uuid (or
ec2 instance id) and certname and returns a csr_attributes.yaml file
with an autogenerated PSK
* the website stores all of this in a DB with a timestamp so I can
age them out.
* Create an autosign script that validates a CSR against the DB and
the cloud provider
This should be totally doable and indeed is exactly the kind of thing I
was hoping to see happen with the autosign policy + cert attributes.
Sounds like an awesome PuppetConf talk in the making, actually :-D
Let me restate your requirements for that web service a bit, to make
sure I understand -- this is the part that's probably the most
complicated. It would...
- provide an endpoint that accepts requests for attributes from unknown
IPs who provide a uuid
- match the uuid against the cloud service api to determine whether a
psk should be issued
- if it should, generate + store a timestamped [uuid,psk] tuple and
return a valid csr_attributes.yaml
- provide a second endpoint whose access is restricted to just your
puppetmasters
- take requests that present a [uuid,psk] tuple, and check whether
there's a matching record *
- if yes, delete the record and reply affirmative to the autosign request
* does this step really also need to call out to the cloud service API?
Vsphere at least is pretty slow/expensive in my experience, and if
there's a valid record in the DB it should be safe to skip a call on
every signing request...
My puppet bootstrap process is:
1 update system
2 download PE tarball and answers file
3 extract tarball
4 run installer with anwsers files
What would be great is if there was an empty hooks directory that
could contain some well-known named scripts that are run at certain
times. pre_agent.sh or something could be downloaded between steps 3
and 4 and placed into the hooks directory.
This would allow me to use facter post install, but pre-agent run to
get my data.
What do you think?
I agree some hooks would be nice; the PE installer is currently under
heavy revision for PE3.2 so I wouldn't want to hack too much into it
just now. But again, if you're relying on custom facts, you need a
certificate in order to get them pluginsync'ed so it wouldn't help this
situation.
However, you can pre-seed the csr_attributes.yaml in step 1, if you can
put a little stand-alone implementation of your fact code and the script
that calls out to the web service in a %post kickstart scriptlet or use
cloud-init. The installer won't flip out if there's already an
/etc/puppetlabs/puppet/ directory in place on the system when it runs.
Pretty interesting!
--
Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/52F3BDB6.7040209%40puppetlabs.com.
For more options, visit https://groups.google.com/groups/opt_out.
