I've done some work in this area.
sudo puppetd --server puppet.mydomain.com --certname
dbs02.sfo.mydomain.com -t
::certname is available as the fact ::clientcert in the Puppet run. I
use ::clientcert instead of ::fdqn in these cases and then use this in
templates as a replacement for hostname, <%=
scope.lookupvar('::clientcert').split(".")[0..-3].join('.') %>. You
could turn that into a custom fact or just deal with it in templates
as needed.
You'll need to make sure that certname is written to the puppet.conf
to make sure it's propagated from the original run. Also certname/
clientcert is only available in 2.6 or later which might be an issue
depending on which distros you support. I run a few servers through a
boot strap environment to deal with that.
<% if puppetversion =~ /0.25(.*)/ then -%>
[puppetd]
<% else -%>
[agent]
certname = <%= clientcert %>
<% end -%>
If you can automate setting certname on the first Puppet run you
should be mostly set.
Ramin
On Jan 2, 10:31 am, Steph Gosling <st...@chuci.org> wrote:
> Hi all,
>
> In the process of converting a largish installation (around 150 hosts,
> mixed cloud and physical) to Puppet and I have a question about how
> folks manage hostnames.
>
> The TL; DR version:
>
> On first run, I can't use $hostname from facter as it's 'wrong'; for
> things like doing host { $certname: ...} that's fine as it gets
> corrected but for other things it's not. What's the best way to
> have a client set it's hostname correctly, first time?
>
> The long version:
>
> My plan has been to base all node names on $certname as provided on
> the clients by puppet.conf. Ideally, puppet will manage everything
> beyond initially being told where the puppetmaster is, then it's just
> cert, sign, let the agent do it's thing and life is all good.
>
> Some of our configurations rely on having the short hostname explicitly
> specified on the client and I initially was setting this via $hostname
> from facter. These are RH style boxes so I'm
> setting /etc/sysconfig/network via a template, /etc/hosts via the host
> resource and the hostname in the kernel either by hostname(1) or
> echo'ing to /proc/sys/kernel/hostname.
>
> That's all well and good but facter runs before the first puppet run so
> even if I set the FQDN everywhere $hostname is still the original one
> at boot. For most things this is OK as puppet corrects them on the
> second run but other things then end up with obsoleted names kicking
> around or incorrect configs for the length of the run interval.
>
> How is everyone else managing this? as so far I can't think of
> an elegant solution:
>
> * Set the hostname by hand/whatever sets certname in puppet.conf (seems
> ugly to me and potentially error-prone)
>
> * split() $certname and use $certname[0] (seems like a kludge, and I
> think also will have scoping issues)
>
> * Create a custom fact that basically does the split() on the client?
>
> * Would stages help? is there anyway to force facter to re-evaluate its
> variables (overriding them also seems kludgey)?
>
> Is there anything else I've missed? how do you all manage it? I've seen
> folks talking about Kickstart/Cobbler but that's not going to work for
> my environment.
>
> Thoughts, pointer and discussion welcome.
>
> --
> Steph Gosling <st...@chuci.org>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
