Puppet users - Jul 2006 - documentation suggestions: including FQDN seems to

Hi,

I''m new to Puppet, but it looks very good, so far.

We are going to use it for a multi-tier (DEV, QA, staging,
production) environment which is consists of web, app, and database
servers.

I have a couple of suggestions for the Puppet documentation that may
save others some time.

First, it seems node names MUST be FQDNs (hostname and hostname. will
not work).  Since we are not using DNS internally for our servers,
this tripped me up.

I assume this is an OpenSSL requirement.

Anyway, I''ve changed the host and node names to hostname.s (for
staging), and it seems to work fine now.

Perhaps you could mention this in the installation or configuration
documents.

Also, Luke, you have some good docs on your reductivelabs.com site,
but a search engine for the site would make them even more useful.
(Sorry if there already is one, and I somehow missed it).

Thanks,
David Di Gioia

On Jul 26, 2006, at 11:54 AM, David Di Gioia wrote:
> Hi,
>
> I''m new to Puppet, but it looks very good, so far.
>
> We are going to use it for a multi-tier (DEV, QA, staging,
> production) environment which is consists of web, app, and database
> servers.
>
> I have a couple of suggestions for the Puppet documentation that may
> save others some time.
>
> First, it seems node names MUST be FQDNs (hostname and hostname. will
> not work).  Since we are not using DNS internally for our servers,
> this tripped me up.
>
> I assume this is an OpenSSL requirement.
>
> Anyway, I''ve changed the host and node names to hostname.s (for
> staging), and it seems to work fine now.
Hmmm, if that''s the case then it''s a bug.  You definitely
should not
need to specify the fqdn anywhere; in fact, Puppet should be looking
for all iterations it can think of (which is usually just the fqdn
and the short name).

I''m at OSCON right now, so I don''t really have any time to
work on
this, but I''ll file a bug against it and check it out when I get back.
> Also, Luke, you have some good docs on your reductivelabs.com site,
> but a search engine for the site would make them even more useful.
> (Sorry if there already is one, and I somehow missed it).
It''s currently a static site, and most of the content is driven out
of files maintained in Subversion, so I think it would be pretty
difficult to add.

It looks like Google is largely useless for searching since it hits
all of the revisions in the trac site.  I clearly need to work on my
robots.txt file to prevent this from happening.

I''ll see if I can figure something out.  Thank you for the feedback.

--
Luke Kanies
http://madstop.com
615-594-8199

David Di Gioia wrote:
> Hi,
>
> First, it seems node names MUST be FQDNs (hostname and hostname. will
> not work).  Since we are not using DNS internally for our servers,
> this tripped me up.
>
> I assume this is an OpenSSL requirement.
I''ve been hacking cert management in puppet a bit.  As far as I know
(Luke can verify this) none of the SSL internals rely on hostnames other
than the actual file names of the certificates themselves.

Best Regards,
--
Jeff McCune
The Ohio State University
Department of Mathematics
Systems Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3775 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://mail.madstop.com/pipermail/puppet-users/attachments/20060726/9cf42248/attachment.bin

>
> It looks like Google is largely useless for searching since it hits
> all of the revisions in the trac site.  I clearly need to work on my
> robots.txt file to prevent this from happening.
>
Here''s a easy "let Google search my site bit" that fixes that
problem:

http://www.google.com/search?hs=I98&hl=en&lr=&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=site%3Areductivelabs.com+-%22Edgewall%22+types&btnG=Search

It would be possible to add a web form that builds a Google URL via
Javascript that includes the "-trac" bit and then opens it in a new
window.

As another (off topic) web suggestion, having the HREF links be a
different color than the text could prove useful.

Ok, back to work for me :)

--Michael

On Jul 26, 2006, at 12:18 PM, Michael DeHaan wrote:
>
>>
>> It looks like Google is largely useless for searching since it hits
>> all of the revisions in the trac site.  I clearly need to work on my
>> robots.txt file to prevent this from happening.
>>
> Here''s a easy "let Google search my site bit" that fixes
that problem:
>
> http://www.google.com/search?hs=I98&hl=en&lr=&client=firefox-
> a&rls=org.mozilla%3Aen-US%3Aofficial&q=site%3Areductivelabs.com+-%
> 22Edgewall%22+types&btnG=Search
>
> It would be possible to add a web form that builds a Google URL via
> Javascript that includes the "-trac" bit and then opens it in a
new
> window.
Thanks; I''ll add that to the template.
> As another (off topic) web suggestion, having the HREF links be a
> different color than the text could prove useful.
I know, I know.  I plan on taking a look at it.

--
Luke Kanies
http://madstop.com
615-594-8199

On Jul 26, 2006, at 12:07 PM, Jeff McCune wrote:
>
> I''ve been hacking cert management in puppet a bit.  As far as I
> know (Luke can verify this) none of the SSL internals rely on
> hostnames other than the actual file names of the certificates
> themselves.
That is basically correct.  The only quirk is that Puppet uses the
certificate hostname, not the hostname returned from Facter, to look
the host up in the node list.  I would be willing to change this,
since it''s not exactly obvious.

--
Luke Kanies
http://madstop.com
615-594-8199

On Wed, Jul 26, 2006 at 01:51:28PM -0700, Luke Kanies
wrote:
> On Jul 26, 2006, at 12:07 PM, Jeff McCune wrote:
> >
> > I''ve been hacking cert management in puppet a bit.  As far as
I
> > know (Luke can verify this) none of the SSL internals rely on
> > hostnames other than the actual file names of the certificates
> > themselves.
>
> That is basically correct.  The only quirk is that Puppet uses the
> certificate hostname, not the hostname returned from Facter, to look
> the host up in the node list.  I would be willing to change this,
> since it''s not exactly obvious.
<fx: raises eyebrows>  I never realised that -- I always assumed it was
the
facter hostname that was used.

I think the Principle of Least Surprise says "change it".  Using the
certificate hostname for lookups is just going to freak people out, cause
harm to kittens, and cause someone, somewhere, untold hassle.

Please.  Think of the kittens.

- Matt

--
"I''m tempted to try Gentoo, but... I have better things to do with
my CPU
cycles than to compile Python so that it can compile the compiler
so that it can compile the kernel."
		-- Dave Brown, ASR

Luke Kanies wrote:
> On Jul 26, 2006, at 12:07 PM, Jeff McCune wrote:
>> I''ve been hacking cert management in puppet a bit.  As far as
I
>> know (Luke can verify this) none of the SSL internals rely on
>> hostnames other than the actual file names of the certificates
>> themselves.
>
> That is basically correct.  The only quirk is that Puppet uses the
> certificate hostname, not the hostname returned from Facter, to look
> the host up in the node list.  I would be willing to change this,
> since it''s not exactly obvious.
>
Eek.  Yes, this is a *very bad thing* at my site.

In my world, certificates stick with machines.  Machines move around
like crazy and assume the role of many different nodes over relatively
short periods of time.

If I sign a certificate, I''m trying to tell the entire site,
"Look, you
can trust that machine is one of us."

The machine should then say (through facter) "Uh...  It looks like the
rest of the site (trusted) says I''m ford.math.ohio-state.edu.  Could
you
configure me?"

If I swap ford and arthur in ldap and reboot those machines, facter
should then report "Uh, the site says I''m
arthur.math.ohio-state.edu
Could you configure me?"

The signed machine certificate means I can trust that facter isn''t
trying to trick the rest of the site.

Ideally, site configuration developers will starting thinking about
certificate management by imagining there''s a smart card soldered to
the
motherboard of every machine being managed.

This embedded smart card provides the root trust:  "I trust the
*machine*" (Not the host or node).  Ideally, everything in the future
will stem from that root trust.

Make sense?

--
Jeff McCune
The Ohio State University
Department of Mathematics
Systems Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3775 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://mail.madstop.com/pipermail/puppet-users/attachments/20060726/4f6a662c/attachment-0001.bin

On 26/07/06 17:54 -0400, Jeff McCune wrote:
<snip>
> In my world, certificates stick with machines.  Machines move around
> like crazy and assume the role of many different nodes over relatively
> short periods of time.
>
> If I sign a certificate, I''m trying to tell the entire site,
"Look, you
> can trust that machine is one of us."
>
> The machine should then say (through facter) "Uh...  It looks like the
> rest of the site (trusted) says I''m ford.math.ohio-state.edu. 
Could you
> configure me?"
>
> If I swap ford and arthur in ldap and reboot those machines, facter
> should then report "Uh, the site says I''m
arthur.math.ohio-state.edu
> Could you configure me?"
>
Isn''t that a misuse of certificates? You should really not want to
change the hostname, but the roles associated with the host and the
interface IPs and names, if needed.
> The signed machine certificate means I can trust that facter isn''t
> trying to trick the rest of the site.
>
> Ideally, site configuration developers will starting thinking about
> certificate management by imagining there''s a smart card soldered
to the
> motherboard of every machine being managed.
>
> This embedded smart card provides the root trust:  "I trust the
> *machine*" (Not the host or node).  Ideally, everything in the future
> will stem from that root trust.
>
You can''t trust the "machine". It has to be the host. The
"smart card
identifier" in this case is the hostname.

Devdas Bhagat

Devdas Bhagat wrote:
> Isn''t that a misuse of certificates? You should really not want to
> change the hostname, but the roles associated with the host and the
> interface IPs and names, if needed.
Why do you think this is a misuse of certificates?  Keep in mind that
I''m not talking about an SSL certificate identifying a website.

Furthermore, the word "should" is a bit strong...  The hostname is
just
another attribute that needs to be configured as far as I''m concerned.
Why should I have to track what host is currently assigned a roll when I
can just as easily have the host move alongside the roles?

If a machine breaks, I swap it out with a spare.  Problem fixed in under
10 minutes.  Machines break *every day* at my site.  Under your model, I
couldn''t swap machine because the hostname wouldn''t be
portable between
then and the customers need to access their machines through the
hostname they expect.

Best Regards,
--
Jeff McCune
The Ohio State University
Department of Mathematics
Systems Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3775 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://mail.madstop.com/pipermail/puppet-users/attachments/20060727/3e2c03e3/attachment.bin

On Thursday 27 July 2006 15:18, Jeff McCune wrote:
> Furthermore, the word "should" is a bit strong...  The hostname
is just
> another attribute that needs to be configured as far as I''m
concerned.
At the site I''m working, we have had the same problem. We solved it by
defining hostname == hardware name. So when we install a new hardware, it
receives a hostname, which stays with this hardware until it''s
decommissioned. services are almost always referenced via CNAMES.


Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir ?ber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

On Jul 26, 2006, at 4:54 PM, Jeff McCune wrote:
> Luke Kanies wrote:
>> On Jul 26, 2006, at 12:07 PM, Jeff McCune wrote:
>>> I''ve been hacking cert management in puppet a bit.  As far
as I
>>> know (Luke can verify this) none of the SSL internals rely on
>>> hostnames other than the actual file names of the certificates
>>> themselves.
>> That is basically correct.  The only quirk is that Puppet uses
>> the  certificate hostname, not the hostname returned from Facter,
>> to look  the host up in the node list.  I would be willing to
>> change this,  since it''s not exactly obvious.
>
> Eek.  Yes, this is a *very bad thing* at my site.
>
> In my world, certificates stick with machines.  Machines move
> around like crazy and assume the role of many different nodes over
> relatively short periods of time.
Have you run into this problem yet?

I''m fine with switching it back, although it''s been this way
for a
good long time (probably before I started making regular releases).
> If I sign a certificate, I''m trying to tell the entire site,
"Look,
> you can trust that machine is one of us."
>
> The machine should then say (through facter) "Uh...  It looks like
> the rest of the site (trusted) says I''m ford.math.ohio-state.edu.
> Could you configure me?"
>
> If I swap ford and arthur in ldap and reboot those machines, facter
> should then report "Uh, the site says I''m arthur.math.ohio-
> state.edu Could you configure me?"
>
> The signed machine certificate means I can trust that facter isn''t
> trying to trick the rest of the site.
>
> Ideally, site configuration developers will starting thinking about
> certificate management by imagining there''s a smart card soldered
> to the motherboard of every machine being managed.
>
> This embedded smart card provides the root trust:  "I trust the
> *machine*" (Not the host or node).  Ideally, everything in the
> future will stem from that root trust.
That''s actually exactly why I use the hostname from the cert -- I
trust the hostname in the cert more than I trust the hostname
configured on the box.

Strange that our goals are the same but we ended up at opposite places.

Do you not at least agree that it''s a bit odd that you would want
your cert hostnames and your system hostnames to disagree?

--
Luke Kanies
http://madstop.com
615-594-8199

On Jul 27, 2006, at 8:18 AM, Jeff McCune wrote:
>
> Why do you think this is a misuse of certificates?  Keep in mind
> that I''m not talking about an SSL certificate identifying a
website.
>
> Furthermore, the word "should" is a bit strong...  The hostname
is
> just another attribute that needs to be configured as far as I''m
> concerned. Why should I have to track what host is currently
> assigned a roll when I can just as easily have the host move
> alongside the roles?
The hostname is a special attribute in Puppet (and most other config-
mgmt apps), because it''s the key to the rest of the configuration.
> If a machine breaks, I swap it out with a spare.  Problem fixed in
> under 10 minutes.  Machines break *every day* at my site.  Under
> your model, I couldn''t swap machine because the hostname
wouldn''t
> be portable between then and the customers need to access their
> machines through the hostname they expect.
I don''t necessarily agree with that.  It''s pretty easy to gen
new
certs for a host (puppetca --clean <host> removes old certs, then the
host gens new ones), but it does seem like the right option is to use
CNAMEs for basically all services, so the user doesn''t have to know
about it.

Either way, you''re going to spend some significant effort hiding this
information from your users -- either using DNS shenanigans, or using
naming mismatches between certs and hostnames.  I think the DNS route
is cleaner, personally.

--
Luke Kanies
http://madstop.com
615-594-8199

On Jul 26, 2006, at 4:29 PM, Matthew Palmer wrote:
>
> <fx: raises eyebrows>  I never realised that -- I always assumed it
> was the
> facter hostname that was used.
>
> I think the Principle of Least Surprise says "change it".  Using
the
> certificate hostname for lookups is just going to freak people out,
> cause
> harm to kittens, and cause someone, somewhere, untold hassle.
Eh.  $10 says you guys would have never discovered it if I hadn''t
admitted it. :)
> Please.  Think of the kittens.
And the poptarts you could get for them:

http://goats.com/store/item/tshirt_kpt-1.html (check the relevant
strips for details).

--
Luke Kanies
http://madstop.com
615-594-8199

For what it''s worth, I have been using local hostnames (no DNS) like
"app1.s", "app2.s", etc. with Puppet since I ran into this
issue, and
it seems to be working fine in our environment.  The certificate name
= hostname, and if we need to change one, it''s easy to delete the old
certificates using the puppetca command.

So I guess I am saying, it ain''t broke, so please don''t fix
it, if
the fix will be disruptive, but please DO document the requirement
for FQDNs to save time for other people who might be wondering why
they are having a difficult time getting Puppet to work for the first
time.

On Jul 31, 2006, at 11:16 AM, Luke Kanies wrote:
> On Jul 27, 2006, at 8:18 AM, Jeff McCune wrote:
>>
>> Why do you think this is a misuse of certificates?  Keep in mind
>> that I''m not talking about an SSL certificate identifying a
website.
>>
>> Furthermore, the word "should" is a bit strong...  The
hostname is
>> just another attribute that needs to be configured as far as
I''m
>> concerned. Why should I have to track what host is currently
>> assigned a roll when I can just as easily have the host move
>> alongside the roles?
>
> The hostname is a special attribute in Puppet (and most other config-
> mgmt apps), because it''s the key to the rest of the configuration.
>
>> If a machine breaks, I swap it out with a spare.  Problem fixed in
>> under 10 minutes.  Machines break *every day* at my site.  Under
>> your model, I couldn''t swap machine because the hostname
wouldn''t
>> be portable between then and the customers need to access their
>> machines through the hostname they expect.
>
> I don''t necessarily agree with that.  It''s pretty easy to
gen new
> certs for a host (puppetca --clean <host> removes old certs, then the
> host gens new ones), but it does seem like the right option is to use
> CNAMEs for basically all services, so the user doesn''t have to
know
> about it.
>
> Either way, you''re going to spend some significant effort hiding
this
> information from your users -- either using DNS shenanigans, or using
> naming mismatches between certs and hostnames.  I think the DNS route
> is cleaner, personally.
>
> --
> Luke Kanies
> http://madstop.com
> 615-594-8199
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users at madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
Thanks,
David

David Di Gioia
Senior Consultant
Pathfinder Associates, LLC
http://www.pathf.com
ddigioia at pathf.com

voice 312-372-1058 x 6033
mobile 312-479-7174


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.madstop.com/pipermail/puppet-users/attachments/20060731/fe9e5d5a/attachment.htm

\On Jul 31, 2006, at 11:45 AM, David Di Gioia wrote:
> For what it''s worth, I have been using local hostnames (no DNS)
> like "app1.s", "app2.s", etc. with Puppet since I ran
into this
> issue, and it seems to be working fine in our environment.  The
> certificate name = hostname, and if we need to change one, it''s
> easy to delete the old certificates using the puppetca command.
>
> So I guess I am saying, it ain''t broke, so please don''t
fix it, if
> the fix will be disruptive, but please DO document the requirement
> for FQDNs to save time for other people who might be wondering why
> they are having a difficult time getting Puppet to work for the
> first time.
That FQDN problem is a bug.  I don''t use FQDNs in my system and
it''s
not a problem, so there''s something else weird going on, but I
haven''t had time to track it down.

For most cases, it will not matter whether I use the certificate name
or the configured hostname, so I don''t think anyone will notice.

--
Luke Kanies
http://madstop.com
615-594-8199

Luke Kanies wrote:
> On Jul 27, 2006, at 8:18 AM, Jeff McCune wrote:
>> Why do you think this is a misuse of certificates?  Keep in mind
>> that I''m not talking about an SSL certificate identifying a
website.
>>
>> Furthermore, the word "should" is a bit strong...  The
hostname is
>> just another attribute that needs to be configured as far as
I''m
>> concerned. Why should I have to track what host is currently
>> assigned a roll when I can just as easily have the host move
>> alongside the roles?
>
> The hostname is a special attribute in Puppet (and most other config-
> mgmt apps), because it''s the key to the rest of the configuration.
That''s been mostly true to date, except in situations like mine where
the hostname is *not* the key, and the root token of trust (the cert) is
the key to the rest of the configuration.

You''ve got a wonderful framework, I think we should use it to break
this
antiquated notion of hostname-is-the-key.
>> If a machine breaks, I swap it out with a spare.  Problem fixed in
>> under 10 minutes.  Machines break *every day* at my site.  Under
>> your model, I couldn''t swap machine because the hostname
wouldn''t
>> be portable between then and the customers need to access their
>> machines through the hostname they expect.
>
> I don''t necessarily agree with that.  It''s pretty easy to
gen new
> certs for a host (puppetca --clean <host> removes old certs, then the
> host gens new ones), but it does seem like the right option is to use
> CNAMEs for basically all services, so the user doesn''t have to
know
> about it.
Yes, it''s pretty easy to gen a new cert, I don''t dispute that.
What I''m
striving for is *completely unattended site configuration*.  Seriously.
  No human intervention whatsoever.  Furthermore, you''re talking about
service CNAME, which aren''t of much interest to me.  The hundreds of
machines I''m interested in run no services whatsoever. 
They''re
workstations.

Consider a puppet that only requires established trust between two nodes
and nothing else.  In that situation, I can take a machine with an
embedded smart card, sign it''s certificate, put it on a shelf and let
it
sit for months.  At some point, I just ask a student worker with no
authorization to turn the machine on, and the site configuration tool
takes care of the rest.  The site trusts the machine, the machine trusts
the site, and that''s all either should need to do their sole task of
configuration.

Regardless of how easy it is to generate a new cert, why should I be
required to do so by the site configuration tool I use?

--
Jeff McCune
The Ohio State University
Department of Mathematics
Systems Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3775 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://mail.madstop.com/pipermail/puppet-users/attachments/20060731/de996e35/attachment.bin

Luke Kanies wrote:
> On Jul 26, 2006, at 4:54 PM, Jeff McCune wrote:
>
>> Luke Kanies wrote:
>>> On Jul 26, 2006, at 12:07 PM, Jeff McCune wrote:
>>>> I''ve been hacking cert management in puppet a bit.  As
far as I
>>>> know (Luke can verify this) none of the SSL internals rely on
>>>> hostnames other than the actual file names of the certificates
>>>> themselves.
>>> That is basically correct.  The only quirk is that Puppet uses
>>> the  certificate hostname, not the hostname returned from Facter,
>>> to look  the host up in the node list.  I would be willing to
>>> change this,  since it''s not exactly obvious.
>> Eek.  Yes, this is a *very bad thing* at my site.
>>
>> In my world, certificates stick with machines.  Machines move
>> around like crazy and assume the role of many different nodes over
>> relatively short periods of time.
>
> Have you run into this problem yet?
Oh yes, I just haven''t fixed it yet.  My solution right now is to clean
out certs of swapped machines and reissue them.  I don''t think
it''s a
solution and I plan to fix it as soon as I can get my head above water
with end user support requests.
> I''m fine with switching it back, although it''s been this
way for a
> good long time (probably before I started making regular releases).
I''d greatly appreciate it.  =)  Otherwise, I''ll have to patch
puppet
myself at some point in the near future.
>> If I sign a certificate, I''m trying to tell the entire site,
"Look,
>> you can trust that machine is one of us."
>>
>> The machine should then say (through facter) "Uh...  It looks like
>> the rest of the site (trusted) says I''m
ford.math.ohio-state.edu.
>> Could you configure me?"
>>
>> If I swap ford and arthur in ldap and reboot those machines, facter
>> should then report "Uh, the site says I''m
arthur.math.ohio-
>> state.edu Could you configure me?"
>>
>> The signed machine certificate means I can trust that facter
isn''t
>> trying to trick the rest of the site.
>>
>> Ideally, site configuration developers will starting thinking about
>> certificate management by imagining there''s a smart card
soldered
>> to the motherboard of every machine being managed.
>>
>> This embedded smart card provides the root trust:  "I trust the
>> *machine*" (Not the host or node).  Ideally, everything in the
>> future will stem from that root trust.
>
> That''s actually exactly why I use the hostname from the cert -- I
> trust the hostname in the cert more than I trust the hostname
> configured on the box.
Hrm, yeah I trust my DHCP server and DNS server much more than I trust
the cert since certs move around so much at my site.  Puppet hasn''t
ever
failed to restart DHCP and DNS within seconds when I tell the site I''ve
swapped two machine hostnames.
> Strange that our goals are the same but we ended up at opposite places.
I think it''s because I have a unique management strategy of
"swap-and-clone!" as a solution for every problem my customers face.
> Do you not at least agree that it''s a bit odd that you would want
> your cert hostnames and your system hostnames to disagree?
Nope.  I don''t agree.  =)  Cert hostnames are only relevant in SSL/TLS
communication.  They''re saying "This cert identifies this
*hostname*"  I
view certificate use within the site configuration realm as "This cert
identifies this *device*"

Now, if by "strange" you mean it''s rare to think about site
configuration this way, I''ll give you that.

Honestly, my MacBook Pro has a built in TPM chip.  I don''t plan on
resigning it''s certificate in hardware every time I change
it''s
hostname.  All of the workstations I manage will soon have TPM hardware.
  I''m hoping to take advantage of it ASAP.

Best Regards,
--
Jeff McCune
The Ohio State University
Department of Mathematics
Systems Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3775 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://mail.madstop.com/pipermail/puppet-users/attachments/20060731/95ffea3a/attachment.bin

Jeff McCune wrote:
>>
>> The hostname is a special attribute in Puppet (and most other config-
>> mgmt apps), because it''s the key to the rest of the
configuration.
>
> That''s been mostly true to date, except in situations like mine
where
> the hostname is *not* the key, and the root token of trust (the cert) is
> the key to the rest of the configuration.
For the record, I''m changing this as soon as I get a chance, but
I''m
looking for a bit more info.  The change will happen either way.

How are you using the certificate to find a host''s configuration?  I
know I''m not exposing the public key or anything, so you''re
not using
that as a selection mechanism.  You''re still using the hostname, right,
it''s just the hostname as set when the host is built, not the hostname
as set in the certificate?

Seems like either way it''s the hostname; it''s just where that
hostname
derives that you want to change.  If anything, it seems like you''d want
to put a hardware-specific key into the cert, and then use that key as
the key into Puppet configurations.
> You''ve got a wonderful framework, I think we should use it to
break this
> antiquated notion of hostname-is-the-key.
Except that that''s not actually what you''re asking for, is it?
You
still want the hostname as the key (from what I understand), you just
don''t want to derive that hostname from the certificate.

You can currently use whatever information you want to determine a given
host''s configuration in Puppet; I just provide some extra conveniences
for using the hostname.  You can use a big case statement based on IP
address or MAC address, for instance.
> Yes, it''s pretty easy to gen a new cert, I don''t dispute
that.  What I''m
> striving for is *completely unattended site configuration*.  Seriously.
>  No human intervention whatsoever.  Furthermore, you''re talking
about
> service CNAME, which aren''t of much interest to me.  The hundreds
of
> machines I''m interested in run no services whatsoever. 
They''re
> workstations.
 >
> Consider a puppet that only requires established trust between two nodes
> and nothing else.  In that situation, I can take a machine with an
> embedded smart card, sign it''s certificate, put it on a shelf and
let it
> sit for months.  At some point, I just ask a student worker with no
> authorization to turn the machine on, and the site configuration tool
> takes care of the rest.  The site trusts the machine, the machine trusts
> the site, and that''s all either should need to do their sole task
of
> configuration.
I don''t see how that''s different from what you can do now.
> Regardless of how easy it is to generate a new cert, why should I be
> required to do so by the site configuration tool I use?
Heh, for the record, you''re not required to do anything.  It''s
an
if/then:  If you want to rebuild hosts but change names, then you have
to use different certs.

--
The Washington Bullets are changing their name.  The owners no longer
want their team''s name to be associated with crime.  So from now on the
team will be known as The Bullets.
                 -- Paul Harvey, quoting Argus Hamilton
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On Mon, Jul 31, 2006 at 11:18:29AM -0500, Luke Kanies
wrote:
> On Jul 26, 2006, at 4:29 PM, Matthew Palmer wrote:
> >
> > <fx: raises eyebrows>  I never realised that -- I always assumed
it
> > was the
> > facter hostname that was used.
> >
> > I think the Principle of Least Surprise says "change it". 
Using the
> > certificate hostname for lookups is just going to freak people out,
> > cause
> > harm to kittens, and cause someone, somewhere, untold hassle.
>
> Eh.  $10 says you guys would have never discovered it if I hadn''t
> admitted it. :)
I won''t take that bet.  But now that we *do* know, you can guarantee
it''s
going to be a constant problem.  It''s not about to bite me in a hurry,
because I always rebuild from scratch if I''m changing hostname, but
that
whole smartcard-on-the-motherboard thing sounds pretty sweet.
> > Please.  Think of the kittens.
>
> And the poptarts you could get for them:
>
> http://goats.com/store/item/tshirt_kpt-1.html (check the relevant
> strips for details).
I remember Goats.  I kinda gave up on it after a 3 month saga involving
Diablo and Mendel -- ghods he can meander on those...

- Matt