Puppet users - Jan 2012 - Another hostnames best-practice question

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 <steph@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

You must be getting the real hostname from somewhere programmatically. I
would either override $hostname and $fqdn or create a $realname custom fact
using that info. The override might be cleaner, otherwise you may want to
use either run stages or a deployment-specific environment to make sure the
hostname takes effect before the rest of your resources are instantiated.
On Jan 2, 2012 10:32 AM, "Steph Gosling" <steph@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 <steph@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+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.