Puppet users - Dec 2008 - select node to use from the client side?

I want to run puppet in the cloud.  The trouble is, the fqdn fact is
quite random and looks something like "domU-12-32-19-01-B8-D1".

I''m OK with deploying the cert pair and configuring puppetd to use the
same cert on every box.  However, I need to be able to select which
node configuration in the puppet master to use on the client side,
without changing the hostname (or adding a new node every time we
bring up a new server).

Is this possible?  Do I have to over-ride the fqdn fact some how on the client?

Thanks :)

Tim

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 22, 2008 at 3:47 PM, Tim Harper <timcharper@gmail.com> wrote:
>
> I want to run puppet in the cloud.  The trouble is, the fqdn fact is
> quite random and looks something like "domU-12-32-19-01-B8-D1".
>
> I''m OK with deploying the cert pair and configuring puppetd to use
the
> same cert on every box.  However, I need to be able to select which
> node configuration in the puppet master to use on the client side,
> without changing the hostname (or adding a new node every time we
> bring up a new server).
>
> Is this possible?  Do I have to over-ride the fqdn fact some how on the
> client?
>
> Thanks :)

If I understand what you''re asking, I think you want to instead
override the
certname property on the clients.

The certs don''t have to use hostnames for their name. They can be
completely
arbitrary.


-- 
Nigel Kersten
Systems Administrator
Tech Lead - MacOps

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 22, 2008 at 4:52 PM, Nigel Kersten <nigelk@google.com> wrote:
>
>
> On Mon, Dec 22, 2008 at 3:47 PM, Tim Harper <timcharper@gmail.com>
wrote:
>
>>
>> I want to run puppet in the cloud.  The trouble is, the fqdn fact is
>> quite random and looks something like
"domU-12-32-19-01-B8-D1".
>>
>> I''m OK with deploying the cert pair and configuring puppetd to
use the
>> same cert on every box.  However, I need to be able to select which
>> node configuration in the puppet master to use on the client side,
>> without changing the hostname (or adding a new node every time we
>> bring up a new server).
>>
>> Is this possible?  Do I have to over-ride the fqdn fact some how on the
>> client?
>>
>> Thanks :)
>
>
> If I understand what you''re asking, I think you want to instead
override
> the certname property on the clients.
>
> The certs don''t have to use hostnames for their name. They can be
> completely arbitrary.
>
That''s half of the battle.  The other half is getting the puppet master
to
select the appropriate node configuration.

I''d like to create the following nodes:

general
|- www-server
|- db-server
|- sb-server
|- memcache-server

When I boot up a fresh image, I''d like it to apply the
"general"
configuration.  Then, I''m going to save the image for future use.

Later, I''m when I boot up one of the more specialized machines (like
www-server), I''d like it to restore the general configuration, switch
mode
to "www-server", and apply the configuration.

(the need for this approach has been created by us deploying to a cloud and
a static environment during a transitory phase)

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Dec 22, 2008, at 3:59 PM, Tim Harper wrote:
> That''s half of the battle.  The other half is getting the puppet  
> master to select the appropriate node configuration.
>
> I''d like to create the following nodes:
>
> general
> |- www-server
> |- db-server
> |- sb-server
> |- memcache-server
>
> When I boot up a fresh image, I''d like it to apply the
"general"
> configuration.  Then, I''m going to save the image for future use.
>
> Later, I''m when I boot up one of the more specialized machines
(like
> www-server), I''d like it to restore the general configuration,  
> switch mode to "www-server", and apply the configuration.
>
> (the need for this approach has been created by us deploying to a  
> cloud and a static environment during a transitory phase)
You can do a couple of things.

One, you can integrate puppet with your EC2 management scripts - that  
way you know the names of the nodes you launch (via the EC2 API) and  
can apply configurations normally.  This is particularly easy if you  
have an external node tool - just have your EC2 scripts update the  
configruation puppet users from external nodes, and move on.

If you want to avoid external nodes, I would still tie this in to your  
EC2 managment - although instead of update an external node tool, just  
have it update a node.pp file with the correct configuration.

Either of these approaches will probably let you use a puppetmasterd  
that''s totally external to EC2 - just have the management scripts  
verify the SSL cert on demand.

Adam

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Dec 22, 2008, at 3:59 PM, Tim Harper wrote:
> When I boot up a fresh image, I''d like it to apply the
"general"
> configuration.  Then, I''m going to save the image for future use.
>
> Later, I''m when I boot up one of the more specialized machines
(like
> www-server), I''d like it to restore the general configuration,  
> switch mode to "www-server", and apply the configuration.
>
> (the need for this approach has been created by us deploying to a  
> cloud and a static environment during a transitory phase)
Two examples:

* EC2, Puppet and Capistrano
http://github.com/adamhjk/ec2-cap/tree/master

* Gentoo, EC2, Portage
http://github.com/dysinger/gec2/tree/master

Adam

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 22, 2008 at 04:47:53PM -0700, Tim Harper
wrote:
> 
> I want to run puppet in the cloud.  The trouble is, the fqdn fact is
> quite random and looks something like "domU-12-32-19-01-B8-D1".
> 
> I''m OK with deploying the cert pair and configuring puppetd to use
the
> same cert on every box.  However, I need to be able to select which
> node configuration in the puppet master to use on the client side,
> without changing the hostname (or adding a new node every time we
> bring up a new server).
> 
> Is this possible?  Do I have to over-ride the fqdn fact some how on the
client?
The simplest way I''ve found to tackle this problem is by utilising the
user-data portion of the API. When you start the EC2 instance you can
attach a file which will be available via http after boot.

I use the ubuntu images created by Eric Hammond http://alestic.com/.
If you look at the script used to create them you can see how it saves
the user data in a particular location on the disk and then if it
begins with #! it executes it.

So you can put info in there which another script uses to configure
the box.

My preference however is to send a script which configures the server.
My particular script does the following.

- Puts VPN keys embedded in the script to the disk
- Installs and starts openvpn to connect to my puppet server
- Places puppet certificates on the disk
- Installs puppet
- Sets the hostname of the server
- restarts puppet

That way the puppetmaster knows which server it''s supposed to be.

Hope that helps.

Cheers,

-- 
John
Blog                        http://www.inodes.org/blog
OLPC Friends                     http://olpcfriends.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
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 22, 2008 at 5:05 PM, Adam Jacob <adam@hjksolutions.com>
wrote:
>
> On Dec 22, 2008, at 3:59 PM, Tim Harper wrote:
>> When I boot up a fresh image, I''d like it to apply the
"general"
>> configuration.  Then, I''m going to save the image for future
use.
>>
>> Later, I''m when I boot up one of the more specialized machines
(like
>> www-server), I''d like it to restore the general configuration,
>> switch mode to "www-server", and apply the configuration.
>>
>> (the need for this approach has been created by us deploying to a
>> cloud and a static environment during a transitory phase)
>
> Two examples:
>
> * EC2, Puppet and Capistrano
> http://github.com/adamhjk/ec2-cap/tree/master
>
> * Gentoo, EC2, Portage
> http://github.com/dysinger/gec2/tree/master
>
> Adam
Thank you so much everybody for taking and thought time to respond.  I
looked in to the git / iClassify / puppet that you mentioned, Adam.
That looks very applicable, and at some point we may pursue that
route.

In light of all suggestions, I think they may be more than I need.
What if I developed a custom fact, called it "server_role", stored the
value to a yaml filed under /etc/puppet/custom_facts.yml, and then had
a default node with a case statement that included the bits of
functionality needed for a said role?

Has anybody done that before?  Am I crossing into illegal territory?

Thanks,

Tim

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Tue, Dec 23, 2008 at 12:28 PM, Tim Harper <timcharper@gmail.com> wrote:
>
> On Mon, Dec 22, 2008 at 5:05 PM, Adam Jacob <adam@hjksolutions.com>
wrote:
> >
> > On Dec 22, 2008, at 3:59 PM, Tim Harper wrote:
> >> When I boot up a fresh image, I''d like it to apply the
"general"
> >> configuration.  Then, I''m going to save the image for
future use.
> >>
> >> Later, I''m when I boot up one of the more specialized
machines (like
> >> www-server), I''d like it to restore the general
configuration,
> >> switch mode to "www-server", and apply the
configuration.
> >>
> >> (the need for this approach has been created by us deploying to a
> >> cloud and a static environment during a transitory phase)
> >
> > Two examples:
> >
> > * EC2, Puppet and Capistrano
> > http://github.com/adamhjk/ec2-cap/tree/master
> >
> > * Gentoo, EC2, Portage
> > http://github.com/dysinger/gec2/tree/master
> >
> > Adam
>
> Thank you so much everybody for taking and thought time to respond.  I
> looked in to the git / iClassify / puppet that you mentioned, Adam.
> That looks very applicable, and at some point we may pursue that
> route.
>
> In light of all suggestions, I think they may be more than I need.
> What if I developed a custom fact, called it "server_role",
stored the
> value to a yaml filed under /etc/puppet/custom_facts.yml, and then had
> a default node with a case statement that included the bits of
> functionality needed for a said role?
>
> Has anybody done that before?  Am I crossing into illegal territory?

We don''t use nodes at all here.

Our default node imports a module called "base" and then all logic
that
works out what classes should apply to which hosts is done there using
custom and built-in facts.

This plays better with environments for us.

Your suggestion looks fine to me.

-- 
Nigel Kersten
Systems Administrator
Tech Lead - MacOps

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

+1 external nodes

http://reductivelabs.com/trac/puppet/wiki/ExternalNodes

What do you use for starting the EC2 instances?  Just start the node and
associate the host name with the class you want in some format that that
external node executable can look up.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Tue, Dec 23, 2008 at 7:19 PM, Andrew Shafer
<andrew@reductivelabs.com>wrote:
> +1 external nodes
>
> http://reductivelabs.com/trac/puppet/wiki/ExternalNodes
>
> What do you use for starting the EC2 instances?  Just start the node and
> associate the host name with the class you want in some format that that
> external node executable can look up.
>
I didn''t want to go down the external nodes / iClassify route quite
yet. As
for using host names, we''re using rightscale and the hostnames are
quite
ugly: "domU-22-39-19-31-85-B2". I think they''re important
that they stay
that way, not exactly sure what would happen if I changed them but have a
feeling it may effect server monitoring and possibly other system processes.
For future journeymen, here''s approach I came up with to solve the
problem:
http://gist.github.com/41551 Thanks,  Tim

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---