David Kavanagh
2011-Feb-22 15:47 UTC
[Puppet Users] 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.
Trevor Vaughan
2011-Feb-22 16:04 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
-----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.
Jonathan Gazeley
2011-Feb-22 16:15 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
Mohit Chawla
2011-Feb-22 16:27 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
Brian Gallew
2011-Feb-22 16:42 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
David Kavanagh
2011-Feb-22 16:51 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
vagn scott
2011-Feb-22 17:31 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
James A. Peltier
2011-Feb-22 18:14 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
----- 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.
Thomas Bellman
2011-Feb-22 19:50 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
Russell Jackson
2011-Feb-22 20:05 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
Jonathan Gazeley
2011-Feb-23 09:17 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
On 22/02/11 16:51, David Kavanagh wrote:> I thought about DHCP for static addresses. I''d need the MAC for each > machine thoughThis 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.
Ohad Levy
2011-Feb-23 09:50 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
Jennings, Jared L CTR USAF AFMC 46 SK/CCI
2011-Feb-23 15:37 UTC
RE: [Puppet Users] provisioning bare metal (best practices)
+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.
David Kavanagh
2011-Feb-23 16:45 UTC
Re: [Puppet Users] provisioning bare metal (best practices)
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.
Jennings, Jared L CTR USAF AFMC 46 SK/CCI
2011-Feb-23 20:41 UTC
RE: [Puppet Users] provisioning bare metal (best practices)
> Jared, > Are you suggesting separate physical subnet, or simply a logicalsubnet> 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.