Puppet users - Feb 2011 - provisioning bare metal (best practices)

I''m about to start playing with Kickstart. I never really had to
provision
bare servers beyond a normal OS install, so I need something to use along
with Puppet. Is there a general consensus on what the best option is?
I''d need to set up the node with IP/hostname/role. (I have a custom
fact for
role). I figured I''d simply ssh in to write the role file, but if
I''d rather
not use dhcp, I suppose I''ll need to get the network interface
configured in
another way. What do folks generally do here?

David

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Why not use DHCP? This is what it''s for.

The general standard that I''ve seen is DHCP + KS + modification
scripts/puppet/whatever

Trevor

On 02/22/2011 10:47 AM, David Kavanagh wrote:
> I''m about to start playing with Kickstart. I never really had to
provision bare servers beyond a normal OS install, so I need something to use
along
> with Puppet. Is there a general consensus on what the best option is?
> I''d need to set up the node with IP/hostname/role. (I have a
custom fact for role). I figured I''d simply ssh in to write the role
file, but if I''d
> rather not use dhcp, I suppose I''ll need to get the network
interface configured in another way. What do folks generally do here?
> 
> David
> 
> -- 
> 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.
- -- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaughan@onyxpoint.com
 phone: 410-541-ONYX (6699)
 pgp: 0x6C701E94

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNY96DAAoJECNCGV1OLcyp6FoH/1LoCtKepX82ACa2MsAPeUOB
hp+72RZUq6cfUgdiN3JlJWYMqZr2whFmzyPLeqbvNLdRcg2QMdNL5l6lQ5d3Tbt9
q/C4GXJRKTLGUAWBxRu/ij9gAx3ZL77779zaUi6CJ411ftSZuRjjRGYc7v0eo6R0
gXfthQJB8E/jWEFeWhOAhSrfyiLn9uHg8ZjRPz3M3povVBHtk76s1hLMssQbPDsI
SsRcnO016n3dOTul4PcLAPati2pKo32+Md67wI/cqiq+ZOnVXbq925Q0KVbLdyYn
L6faHGe9s1GcrLsH1IDvbFpjMxQiBzXT00uDOsZ7ici4BPYoJoSCxfHM5V6/I7k=esai
-----END PGP SIGNATURE-----

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

We have a small pool of DHCP IP addresses for use only in the build 
process. This is our process:

1. We boot the servers from PXE network boot

2. They get one of the temporary IPs

3. They start a CentOS network install using a kickstart file with the 
bare minimum of packages selected, including puppet

4. The last stage of the kickstart is to set puppet running

5. At this stage, human intervention is required to authorise the new 
machine in puppetca. I''m aware that it is possible to have this step 
done automatically, but it can be a security risk.

6. Once the server is authorised in puppet, it receives a basic
"common"
config from puppet, which gives it the proper static IP that it should 
have, disables DHCP, sets the hostname, sets up NTP, etc.

7. From now on, it''s dead easy to use puppet to install and configure 
everything else.

Cheers,
Jonathan

----------------------------
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
----------------------------

On 22/02/11 15:47, David Kavanagh wrote:
> I''m about to start playing with Kickstart. I never really had to
> provision bare servers beyond a normal OS install, so I need something
> to use along with Puppet. Is there a general consensus on what the best
> option is?
> I''d need to set up the node with IP/hostname/role. (I have a
custom fact
> for role). I figured I''d simply ssh in to write the role file, but
if
> I''d rather not use dhcp, I suppose I''ll need to get the
network
> interface configured in another way. What do folks generally do here?
>
> David
>
> --
> 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.

Foreman could come in handy.

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

Never forget the DHCP does NOT necessarily mean "dynamic addresses". 
Depending upon your corporate culture, it may be perfectly acceptable for DHCP
to hand out statically assigned addresses to your hosts.  This would allow your
build process to be easy, and you can have the host never DHCP again after
it''s up and running (until you rebuild it!).


On Feb 22, 2011, at 8:15 AM, Jonathan Gazeley wrote:
> We have a small pool of DHCP IP addresses for use only in the build
process. This is our process:
> 
> 1. We boot the servers from PXE network boot
> 
> 2. They get one of the temporary IPs
> 
> 3. They start a CentOS network install using a kickstart file with the bare
minimum of packages selected, including puppet
> 
> 4. The last stage of the kickstart is to set puppet running
> 
> 5. At this stage, human intervention is required to authorise the new
machine in puppetca. I''m aware that it is possible to have this step
done automatically, but it can be a security risk.
> 
> 6. Once the server is authorised in puppet, it receives a basic
"common" config from puppet, which gives it the proper static IP that
it should have, disables DHCP, sets the hostname, sets up NTP, etc.
> 
> 7. From now on, it''s dead easy to use puppet to install and
configure everything else.
> 
> Cheers,
> Jonathan
> 
> ----------------------------
> Jonathan Gazeley
> Systems Support Specialist
> ResNet | Wireless & VPN Team
> IT Services
> University of Bristol
> ----------------------------
> 
> On 22/02/11 15:47, David Kavanagh wrote:
>> I''m about to start playing with Kickstart. I never really had
to
>> provision bare servers beyond a normal OS install, so I need something
>> to use along with Puppet. Is there a general consensus on what the best
>> option is?
>> I''d need to set up the node with IP/hostname/role. (I have a
custom fact
>> for role). I figured I''d simply ssh in to write the role file,
but if
>> I''d rather not use dhcp, I suppose I''ll need to get
the network
>> interface configured in another way. What do folks generally do here?
>> 
>> David
>> 
>> --
>> 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.
> 
-- 
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 thought about DHCP for static addresses. I''d need the MAC for each
machine
though. For now, I''m worrying about plugging some media or doing
network
boot on machines by hand. I suppose I''ll need to do something on the
host to
indicate what the machine role will be. In any case, I could simply use a
small pool of dynamic addresses as temporary addresses, and ping for
machines in that range from the server, then let the user know there''s
a new
machine waiting and to designate a purpose (role). Then, assign static
address and restart it in it''s new location, letting puppet finish
provisioning. I''ll have a look at Foreman. Need to think about my use
case,
which probably isn''t so uncommon.

David

On Tue, Feb 22, 2011 at 11:42 AM, Brian Gallew <geek@gallew.org> wrote:
> Never forget the DHCP does NOT necessarily mean "dynamic
addresses".
>  Depending upon your corporate culture, it may be perfectly acceptable for
> DHCP to hand out statically assigned addresses to your hosts.  This would
> allow your build process to be easy, and you can have the host never DHCP
> again after it''s up and running (until you rebuild it!).
>
>
> On Feb 22, 2011, at 8:15 AM, Jonathan Gazeley wrote:
>
> > We have a small pool of DHCP IP addresses for use only in the build
> process. This is our process:
> >
> > 1. We boot the servers from PXE network boot
> >
> > 2. They get one of the temporary IPs
> >
> > 3. They start a CentOS network install using a kickstart file with the
> bare minimum of packages selected, including puppet
> >
> > 4. The last stage of the kickstart is to set puppet running
> >
> > 5. At this stage, human intervention is required to authorise the new
> machine in puppetca. I''m aware that it is possible to have this
step done
> automatically, but it can be a security risk.
> >
> > 6. Once the server is authorised in puppet, it receives a basic
"common"
> config from puppet, which gives it the proper static IP that it should
have,
> disables DHCP, sets the hostname, sets up NTP, etc.
> >
> > 7. From now on, it''s dead easy to use puppet to install and
configure
> everything else.
> >
> > Cheers,
> > Jonathan
> >
> > ----------------------------
> > Jonathan Gazeley
> > Systems Support Specialist
> > ResNet | Wireless & VPN Team
> > IT Services
> > University of Bristol
> > ----------------------------
> >
> > On 22/02/11 15:47, David Kavanagh wrote:
> >> I''m about to start playing with Kickstart. I never really
had to
> >> provision bare servers beyond a normal OS install, so I need
something
> >> to use along with Puppet. Is there a general consensus on what the
best
> >> option is?
> >> I''d need to set up the node with IP/hostname/role. (I
have a custom fact
> >> for role). I figured I''d simply ssh in to write the role
file, but if
> >> I''d rather not use dhcp, I suppose I''ll need to
get the network
> >> interface configured in another way. What do folks generally do
here?
> >>
> >> David
> >>
> >> --
> >> 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.
> >
>
> --
> 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.

Oh, great timing!

I''m working on pretty much the same question. I have used FAI and 
Opsware, and homebrewed scripts to do provisioning in the past.  I have 
never been all that happy with any of them, and am taking another look 
at the problem to try to get to as simple and portable a solution as 
possible.

I am planning to ask the list to criticize the classes that implement 
the various bits. (Is this the right list for that?)  I would like the 
classes to be ''state of the art''.  My own competence with
puppet leans
heavily towards ''exec { "some script I wrote": }''
and I would like to
get past that.

I intend to create a completely worked out example that addresses 
installing to
  VirtualBox  VMs and real hardware.


The programs I will use are:

         dnsmasq for DNS, DHCP, and BOOTP
         apache as file server (preseed.cfg, kickstart.cfg, random scripts)
         apt-cacher-ng for local apt-proxy
         gpxe, undionly.kpxe, pxeboot.0 for booting
         redhat kickstart and debian preseed capable kernel/initrd for 
install

And the slightly clever bit:

         wget or curl to throw triggers into log files
         swatch on the logs to trigger state changes, including signing 
certs
         puppet for configuration beyond the basic install

So how is this a simplification?

         1. dnsmasq is much better suited to provisioning than
            the combination of named, dhcpd, and tftpd (IMHO)

         2. no giant frameworks in sight

         3. each component is familiar.

         4. modular, none of the components know or care about
            the others so they can be versioned or replaced without 
problems.

The thinking behind this is:

         1. dnsmasqd provides mac/ip/hostname assignments
                 dnsmasqd configured by puppet class
                 after provisioning these will show up as facts

         2. boot config provides OS and Disk partitions
                 boot configuration configured by puppet classes
                 after provisioning these will also show up as facts

         3. puppet takes over after the first reboot
                 puppet bootstrapping set up during install (%post or 
last.sh)
                 puppet style can be nodeless, masterless, whatever

         4. flipping a symlink (manually or through a frontend)
            configures a client install for the next time it boots.




On 02/22/2011 10:47 AM, David Kavanagh wrote:
> I''m about to start playing with Kickstart. I never really had to 
> provision bare servers beyond a normal OS install, so I need something 
> to use along with Puppet. Is there a general consensus on what the 
> best option is?
> I''d need to set up the node with IP/hostname/role. (I have a
custom
> fact for role). I figured I''d simply ssh in to write the role
file,
> but if I''d rather not use dhcp, I suppose I''ll need to
get the network
> interface configured in another way. What do folks generally do here?
>
> David
> -- 
> 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.

----- Original Message -----
| I thought about DHCP for static addresses. I''d need the MAC for each
| machine
<snip>

This is not necessarily true.  If you configure the client to send a requested
hostname it will not require you to register the MAC address, although, as per
the usual this is a security risk since anyone on the network could pose as a
machine if they knew that was the setup. ;)

-- 
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax     : 778-782-3045
E-Mail  : jpeltier@sfu.ca
Website : http://www.sfu.ca/itservices
          http://blogs.sfu.ca/people/jpeltier


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

James A. Peltier wrote:
> This is not necessarily true.  If you configure the client to send
> a requested hostname it will not require you to register the MAC
> address, although, as per the usual this is a security risk since
> anyone on the network could pose as a machine if they knew that
> was the setup. ;)
Not that that is any different from when using the MAC address
to key your DHCP server, since that is just as easily faked.
Or when using static IP addresses configured directly on the
machines themselves.

If you are afraid someone will pose as another machine by
"stealing" their IP address, then you need physical security
on your network.


	/Bellman

-- 
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 02/22/2011 10:14 AM, James A. Peltier wrote:
> 
> 
> ----- Original Message ----- | I thought about DHCP for static
> addresses. I''d need the MAC for each | machine <snip>
> 
> This is not necessarily true.  If you configure the client to send a
> requested hostname it will not require you to register the MAC
> address, although, as per the usual this is a security risk since
> anyone on the network could pose as a machine if they knew that was
> the setup. ;)
> 
Only if you have a flat network. A host can''t get an address for a
subnet they''re not in.

-- 
Russell A Jackson <raj@csub.edu>
Network Analyst
California State University, Bakersfield

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

Hi 

I use Cobbler for provisioning and it can handle dhcp and dns if you want. It is
a bit light on debian support but I run mainly RH severs.

The other that is mentioned already, foreman, maybe better as an integrated
solution.

On 23/02/2011, at 7:05, Russell Jackson <raj@csub.edu> wrote:
> On 02/22/2011 10:14 AM, James A. Peltier wrote:
>> 
>> 
>> ----- Original Message ----- | I thought about DHCP for static
>> addresses. I''d need the MAC for each | machine <snip>
>> 
>> This is not necessarily true.  If you configure the client to send a
>> requested hostname it will not require you to register the MAC
>> address, although, as per the usual this is a security risk since
>> anyone on the network could pose as a machine if they knew that was
>> the setup. ;)
>> 
> 
> Only if you have a flat network. A host can''t get an address for a
> subnet they''re not in.
> 
> -- 
> Russell A Jackson <raj@csub.edu>
> Network Analyst
> California State University, Bakersfield
> 
> -- 
> 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.

On 22/02/11 16:51, David Kavanagh wrote:
> I thought about DHCP for static addresses. I''d need the MAC for
each
> machine though
This is why we have a small pool fully dynamic IP addresses for our 
build system that doesn''t require any MAC registration. The subnet is 
only able to talk to the PXE server, our CentOS mirror and the puppet 
server, so it doesn''t really matter if someone else did get one of the
IPs.

-- 
----------------------------
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
----------------------------

-- 
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 Wed, Feb 23, 2011 at 11:17 AM, Jonathan Gazeley <
jonathan.gazeley@bristol.ac.uk> wrote:
> On 22/02/11 16:51, David Kavanagh wrote:
>
>> I thought about DHCP for static addresses. I''d need the MAC
for each
>> machine though
>>
>
> This is why we have a small pool fully dynamic IP addresses for our build
> system that doesn''t require any MAC registration. The subnet is
only able to
> talk to the PXE server, our CentOS mirror and the puppet server, so it
> doesn''t really matter if someone else did get one of the IPs.
>
> --
I find it easier not to flip flop ip addresses during
provisioning/configuration, really, if you set it up upfront, reinstallation
is a breeze.

Ohad

-- 
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 for Cobbler.
 
At my site, we don''t kickstart on the production network, in order to
avoid the case where a not-fully-secured machine is exposed to network
attacks. My kickstart network is all in one room, and so is easier to
secure, logically and physically. On such a network, automatic
certificate signing would likely be suitably secure, and assigning roles
by MAC is easy using Cobbler.

While you may not be subject to the same regulatory restraints, David, I
suggest a separate kickstart network as a best practice.

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

Jared,
Are you suggesting separate physical subnet, or simply a logical subnet on
the same physical network (using netmask)?

David

On Wed, Feb 23, 2011 at 10:37 AM, Jennings, Jared L CTR USAF AFMC 46 SK/CCI
<jared.jennings.ctr@eglin.af.mil> wrote:
> +1 for Cobbler.
>
> At my site, we don''t kickstart on the production network, in order
to
> avoid the case where a not-fully-secured machine is exposed to network
> attacks. My kickstart network is all in one room, and so is easier to
> secure, logically and physically. On such a network, automatic
> certificate signing would likely be suitably secure, and assigning roles
> by MAC is easy using Cobbler.
>
> While you may not be subject to the same regulatory restraints, David, I
> suggest a separate kickstart network as a best practice.
>
> --
> 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.

> Jared,
> Are you suggesting separate physical subnet, or simply a logical
subnet
> on the same physical network (using netmask)?
Mine''s physically separate. I think it''s what is required
(google UNIX
STIG; see section 12.6), and it simplifies configuration and usage (this
network does this thing; the other doesn''t).

Also once kickstarting is over, I''m going to trust the new host and
allow it access to a bunch of things, calm in knowing that I caused
every formative change to its configuration. I don''t want to be wrong
about that.

And there''s no effort wasted on this in our office: the IT team
receives
all the new systems, and we have to configure the BIOS anyway before
letting one out on the floor, so just drop it in the inner sanctum for
an hour or two to kickstart.
	

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