Puppet users - Feb 2010 - Making the new users experience easier

Just one more email and I''ll let you go for a few hours :)

One of the things I like to see in apps is that they are immediately 
intuitive and easy to use for new users.  I think Puppet is really good 
here, but there''s opportunity to make everything better.   We want 
everyone to love Puppet from their first few minutes using it, all the 
way through to datacenter nirvana.

With Puppet, if you''re just learning it, what were some of your 
stumbling blocks?   If you are an existing user, think back to that 
time, or times when you were talking with new users?

One of the ideas I had from cobbler was "cobbler check" which was a
tool
you could run to identify some of these problems.   I''m not sure if it 
makes sense for Puppet, but it may do some things like say "you appear 
to have DNS problems resolving this, you should try..." and so forth.   
What else might there be?   Obviously one of the things I''m going to be
looking for are what questions keep coming up on IRC ... Are there 
mainly questions around puppetca?   Should scaling be easier to set up 
out of the box and in the default configuration (right after RPM or deb 
install)?

Are there easy additions or changes to the software we can make to make 
error messages clearer and self-resolving?   Obvious things in the 
documentation/manpages we can clean up?    (Aside:  I think Puppet 
Dashboard has a LOT of opportunity to help with this too, so watch this 
space!)

I''m going to be looking into this myself, but I''d love to hear
from
you.   Any and all data is welcome.   (If you''d prefer to reply 
personally or talk over IRC, that''s fine too.)

Thanks!

--Michael

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

> With Puppet, if you''re just learning it, what were some of your  
> stumbling blocks?   If you are an existing user, think back to that  
> time, or times when you were talking with new users?
* ssl
* ssl
* dns
* ssl certificates
* language details
* the whole puppet-doesn''t-execute-things-philosophy
* getting an idea where to start
* did I mention ssl?
> One of the ideas I had from cobbler was "cobbler check" which was
a
> tool you could run to identify some of these problems.   I''m not  
> sure if it makes sense for Puppet, but it may do some things like  
> say "you appear to have DNS problems resolving this, you should  
> try..." and so forth.
something like that would be a great idea. especially for things like  
dns and ssl certs. It could provide errors if something is obvious  
wrong and warnings if something is not aligned to the conventions but  
could work if you set certain config options, like the master cert  
doesn''t contain puppet.$domain and so on.
> What else might there be?
James already did a great job in providing first steps examples, like  
the recent "write your own fact". However something that people like  
is to have something to start with, like a first distribute your  
ssh-auth key.
And then what maybe might also be nice is to provide  
standalone-manifests (which require no master) which would configure  
the master in a certain manner. Like the manifests to configure  
puppetmaster as a rack application. So something like  
master_webrick.pp, master_mongrel_nginx.pp,  
master_mongrel_passenger.pp and so on.  These would configure the  
master in a standard way that works. If still people like to tweak  
(destroy?) the config, they can do it, but most people could have a  
safe environment with that to start. It would also be nice to have  
something like: puppet_master_standalone.pp, which would configure the  
master for a desktop try and test setup, where a /etc/hosts entry for  
"puppet" would be created and so on. Simply that people don''t
have to
crawl through documentation if they missed something during setup. Oh  
and for sure the obvious ::destroy classes to remove things again.

Actually the setup of puppet is more or less already  quite  
straightforward, however there are some corner points which shouldn''t  
be missed. People however still often miss them and as they are  
required to get puppet successfully running, they fail and might get  
frustrated.
In combination with puppetcheck this might help to nail down the  
remaining bootstraping problems.

cheers pete

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

Peter Meier wrote:
>> With Puppet, if you''re just learning it, what were some of
your
>> stumbling blocks?   If you are an existing user, think back to that 
>> time, or times when you were talking with new users?
>
> * ssl
> * ssl
> * dns
> * ssl certificates
Definitely understand this whole confusion point.   "Bad DNS" 
experiences equated for a lot of the confusion with previous projects 
I''ve worked on, and also in trying Puppet.    I think there are
probably
ways to make this more clearer to the user and more troubleshootable, 
though if anyone has suggestions on that, please pass them
along.
> * language details
> * the whole puppet-doesn''t-execute-things-philosophy
> * getting an idea where to start
Absolutely.    This is one of the big things I want to address, making 
sure we make that argument very obviously and that there''s a clear 
learning tree to total mastery that doesn''t drown you in information 
initially or give you too many rabbit holes to chase down.

Part of that start is a simple writeup outlining our approach and why we 
think it is the way to go.   I think there''s a lot of good work in 
cleaning up the docs too, and you''ll see alot more of that going 
forward.   

Part of the where to start can also be influenced by having a more 
common library of examples, and yes, more tips about migrating to Puppet 
on the site.   Thanks!

> * did I mention ssl?
>
I think you did!
>> One of the ideas I had from cobbler was "cobbler check" which
was a
>> tool you could run to identify some of these problems.   I''m
not sure
>> if it makes sense for Puppet, but it may do some things like say
"you
>> appear to have DNS problems resolving this, you should try..." and
so
>> forth.
>
> something like that would be a great idea. especially for things like 
> dns and ssl certs. It could provide errors if something is obvious 
> wrong and warnings if something is not aligned to the conventions but 
> could work if you set certain config options, like the master cert 
> doesn''t contain puppet.$domain and so on.
>
>> What else might there be?
>
> James already did a great job in providing first steps examples, like 
> the recent "write your own fact". However something that people
like
> is to have something to start with, like a first distribute your 
> ssh-auth key.
> And then what maybe might also be nice is to provide 
> standalone-manifests (which require no master) which would configure 
> the master in a certain manner. Like the manifests to configure 
> puppetmaster as a rack application. 
One of the things I definitely want to do is make the scaled scenarios 
(ex: rack, passenger, etc) work better out of the box.   I really like 
this idea.   Presumably we''d want to start with just the most popular 
cases and tend to suggest which ones to try -- I don''t think all users 
of a puppetmaster want to be an expert in Ruby webserver internals and 
how to choose the right one.
> So something like master_webrick.pp, master_mongrel_nginx.pp, 
> master_mongrel_passenger.pp and so on.  These would configure the 
> master in a standard way that works. If still people like to tweak 
> (destroy?) the config, they can do it, but most people could have a 
> safe environment with that to start. It would also be nice to have 
> something like: puppet_master_standalone.pp, which would configure the 
> master for a desktop try and test setup, where a /etc/hosts entry for 
> "puppet" would be created and so on. Simply that people
don''t have to
> crawl through documentation if they missed something during setup. Oh 
> and for sure the obvious ::destroy classes to remove things again.
>
> Actually the setup of puppet is more or less already  quite 
> straightforward, however there are some corner points which
shouldn''t
> be missed. People however still often miss them and as they are 
> required to get puppet successfully running, they fail and might get 
> frustrated.
> In combination with puppetcheck this might help to nail down the 
> remaining bootstraping problems.
Right, exactly the point of all of this -- thanks very much for the 
feedback.   If anyone else has any such pointers, please share.   
There''s obviously a fair amount in the archives and so forth about this
as well, but I''m very open to ideas on how to make it all even smoother
(like the web server setup examples).
>
> cheers pete
>
Yep.   Thanks very much!

--Michael


-- 
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
>> * did I mention ssl?
>>
> I think you did!
Well I think this point is/was anyway obvious, unfortunately. SSL Certs
can be get complicated and they are very strict. But this is how they
work and it is good that they work that way. And that''s exactly why
Luke
(dunno who else was involved at that time) built puppetca and I remember
you et. al. doing certmaster for the same reasons. Unfortunately there
are still some corner points missing. But I think another 50-90% (?) of
them might be nailed down having something like puppetcheck present. So
what''s left would be some very exotic cases.
I have to admit that I never encountered any serious problems. But
people in IRC support a lot of people having problems and as SSL is a
central part it can get very frustrating if you don''t get immediately
some test manifests running on your master/client setup.

People even asked/suggested that it might be nice to have something like
a non-ssl way to communicate with the puppetmaster. But I don''t think
that this is an idea that should be considered at all; at least I like
it to know that there is no possibility at all that my manifests could
be transported un- or only weak-encrypted.

Ok, I didn''t want to look it like another SSL rant, so I thought to add
a few more words than only SSL ;)

cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktor1wACgkQbwltcAfKi38ovQCdGWYL179qSgEGRpB+bdPuNfcs
M+0An3WH+sEfrI1NeB3w+REEIwP+HM1x
=6s6a
-----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.

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

On 3/02/10 10:03 AM, Peter Meier wrote:
>>> * did I mention ssl?
>>>
>> I think you did!
+1 SSL although I wonder how this could be implemented?

Time/NTP.

Regards

James Turnbull

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS2ixryFa/lDkFHAyAQI4Uwf8C661+5tH5/NcTSrhmQidNEI0OWsCpVCI
Dv4yRGThMMd/xfNCMVIPR/BO6Jx1rgkt3AHdFFXyyYgR9FMLQUu0E1KnjN9YVHVi
1LdNs4VJVPhIMfa0anGteDdDfdbEw3Cx2a7MDymplVTeNTOs9ct0QBKKH3lKjbml
0orEza7fk7NuAwosVaXe5w5aDyYrQD8Hd+d+BdEkdNeyLfJeGpUDL4+7ai7c4nGB
cuZXeTdyLPtNi11Ww2Q65t0bkI9VSeIhRIeSRo0faZKuwZSFKGvFcPGgCmQtYBa9
4t6zU09DEerKBqFqkn84X55IqdNc0VeScSUezcJA01ILyMAPFuHMcw==L8j3
-----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.

On Tue, 02 Feb 2010 12:08:29 -0500, Michael DeHaan
<michael@reductivelabs.com> wrote:
> With Puppet, if you''re just learning it, what were some of your 
> stumbling blocks?   If you are an existing user, think back to that 
> time, or times when you were talking with new users?
First and foremost on my list is the ability to trigger puppet runs
manually.  In a lot of environments, you don''t want puppet updating
things
automatically in the middle of the day.  In our company (and many like it),
there are strict change management rules dictating when things can be run. 
It''d be nice if puppet didn''t assume that I wanted it to run
immediately
upon startup.  As is, we''ve created a schedule called
"never", and we use
--ignore-schedules to force updates.

I''ve found the puppetrun utility to be very lacking, in many ways, and
have
resorted to my own scripts to trigger runs.  This script runs using ssh to
hit servers, which is unfortunately not ideal right now since it operates
in a serial fashion, and it creates a chicken/egg problem (puppet is used
to deploy the user/sudoers/ssh key...).

The issues I have with puppetrun are:
1) LDAP support is required for triggering individual servers.  Why?
2) Doesn''t pass all options on to the remote server (--noop is ignored,
for
instance)
3) Probably others, but I haven''t messed with it in a while so
I''ve
forgotten them

If either #1 or #2 has been resolved lately, my apologies and I''ll plan
to
upgrade soon :)

Another issue I''ve found is that many of the directories in
/var/lib/puppet
aren''t created until puppetd is started in daemon mode at least once,
so
when we''re building new systems we have to start the service and then
immediately stop it, just so we can run puppetd manually.  Again, if
there''s a work around for that, I''d appreciate hearing it.

Those have been my primary stumbling blocks, if I think of any others
I''ll
let you know.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
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 3, 2010 at 9:27 AM, James Cammarata <jimi@sngx.net> wrote:
> I''ve found the puppetrun utility to be very lacking, in many ways,
and have
> resorted to my own scripts to trigger runs.  This script runs using ssh to
> hit servers, which is unfortunately not ideal right now since it operates
> in a serial fashion, and it creates a chicken/egg problem (puppet is used
> to deploy the user/sudoers/ssh key...).
>
> You might want to have a look at puppetlist/puppetrun in the ext directory,
it could provide some of the functionality you are looking for.

-- 
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, Feb 2, 2010 at 9:02 PM, Ohad Levy <ohadlevy@gmail.com> wrote:
>
>
> On Wed, Feb 3, 2010 at 9:27 AM, James Cammarata <jimi@sngx.net>
wrote:
>
>> I''ve found the puppetrun utility to be very lacking, in many
ways, and
>> have
>> resorted to my own scripts to trigger runs.  This script runs using ssh
to
>> hit servers, which is unfortunately not ideal right now since it
operates
>> in a serial fashion, and it creates a chicken/egg problem (puppet is
used
>> to deploy the user/sudoers/ssh key...).
>>
>> You might want to have a look at puppetlist/puppetrun in the ext
> directory, it could provide some of the functionality you are looking for.
>
As an aside -- I see puppetd and /usr/sbin/puppet share many common options,
but not quite all of them.   Possibly these could be unified.

Some evolution of puppetrun should be in the main distribution, IMHO, as
part of puppetmaster.    We''ve talked a little bit about staged (timed)
rollouts of new manifests and so forth, and environments, and I can see that
playing a role.

This is another conversation we should have too -- how to roll all the
scripts (in ext, or in the community on git somewhere, like the ones you
have created) into the main core, versus having folks have to learn about it
the hard way :)

--Michael

-- 
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 3 February 2010 14:05, Michael DeHaan <michael@reductivelabs.com>
wrote:
> As an aside -- I see puppetd and /usr/sbin/puppet share many common
options,
> but not quite all of them.   Possibly these could be unified.
>
The plan is to unify all the binaries (in fact I think the code is
written and is planned for Rowlf) in the style of git so,

$ puppet ca
$ puppet master
$ puppet client
$ puppet doc
etc, etc

(So puppt check fits).

Obviously existing binaries will continue for a while but ultimately
be deprecated.

Regards

James Turnbull

-- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-- 
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 2/2/10 7:57 PM, James Turnbull wrote:
> The plan is to unify all the binaries (in fact I think the code is
> written and is planned for Rowlf) in the style of git so,
>
> $ puppet ca
> $ puppet master
> $ puppet client
> $ puppet doc
> etc, etc
>
> (So puppt check fits).
>
> Obviously existing binaries will continue for a while but ultimately
> be deprecated.
>
How about symlinks?

puppetd -> puppet
puppetdoc -> puppet

etc..?

-scott

-- 
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, 02 Feb 2010 20:14:50 -0800, Scott Smith <scott@ohlol.net>
wrote:
> On 2/2/10 7:57 PM, James Turnbull wrote:
>> The plan is to unify all the binaries (in fact I think the code is
>> written and is planned for Rowlf) in the style of git so,
>>
>> $ puppet ca
>> $ puppet master
>> $ puppet client
>> $ puppet doc
>> etc, etc
>>
>> (So puppt check fits).
>>
>> Obviously existing binaries will continue for a while but ultimately
>> be deprecated.
>>
> 
> How about symlinks?
> 
> puppetd -> puppet
> puppetdoc -> puppet
> 
> etc..?
> 
> -scott
Symlinks wouldn''t work, I''d just make them shell scripts.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
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 2/2/10 8:18 PM, James Cammarata wrote:
>
> Symlinks wouldn''t work, I''d just make them shell scripts.
>
Wait, what? Checking $0 and loading client, server or doc code would work just
fine. :)

-scott

-- 
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 3 February 2010 15:14, Scott Smith <scott@ohlol.net>
wrote:
> On 2/2/10 7:57 PM, James Turnbull wrote:
>>
>> The plan is to unify all the binaries (in fact I think the code is
>> written and is planned for Rowlf) in the style of git so,
>>
>> $ puppet ca
>> $ puppet master
>> $ puppet client
>> $ puppet doc
>> etc, etc
>>
>> (So puppt check fits).
>>
>> Obviously existing binaries will continue for a while but ultimately
>> be deprecated.
>>
>
> How about symlinks?
>
> puppetd -> puppet
> puppetdoc -> puppet
>
> etc..?
Sure - doesn''t matter to me overly much how it''s done.

Regards

James Turnbull

-- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-- 
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, 02 Feb 2010 20:25:35 -0800, Scott Smith <scott@ohlol.net>
wrote:
> On 2/2/10 8:18 PM, James Cammarata wrote:
>>
>> Symlinks wouldn''t work, I''d just make them shell
scripts.
>>
> 
> Wait, what? Checking $0 and loading client, server or doc code would work
> just fine. :)
> 
> -scott
Heh yeah, you''re right, I hadn''t considered doing it that way.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Am Wednesday 03 February 2010 schrieb mir James
Cammarata:
> On Tue, 02 Feb 2010 20:25:35 -0800, Scott Smith <scott@ohlol.net>
wrote:
> > On 2/2/10 8:18 PM, James Cammarata wrote:
> >> Symlinks wouldn''t work, I''d just make them shell
scripts.
> >
> > Wait, what? Checking $0 and loading client, server or doc code would
> > work just fine. :)
> >
> > -scott
> 
> Heh yeah, you''re right, I hadn''t considered doing it that
way.
That is standard[tm] style for that kind of problem, see busybox for 
example.

regards
Oli

What about a screencast series?

On Feb 2, 6:08 pm, Michael DeHaan <mich...@reductivelabs.com>
wrote:
> Just one more email and I''ll let you go for a few hours :)
>
> One of the things I like to see in apps is that they are immediately
> intuitive and easy to use for new users.  I think Puppet is really good
> here, but there''s opportunity to make everything better.   We want
> everyone to love Puppet from their first few minutes using it, all the
> way through to datacenter nirvana.
>
> With Puppet, if you''re just learning it, what were some of your
> stumbling blocks?   If you are an existing user, think back to that
> time, or times when you were talking with new users?
>
> One of the ideas I had from cobbler was "cobbler check" which was
a tool
> you could run to identify some of these problems.   I''m not sure
if it
> makes sense for Puppet, but it may do some things like say "you appear
> to have DNS problems resolving this, you should try..." and so forth.
 
> What else might there be?   Obviously one of the things I''m going
to be
> looking for are what questions keep coming up on IRC ... Are there
> mainly questions around puppetca?   Should scaling be easier to set up
> out of the box and in the default configuration (right after RPM or deb
> install)?
>
> Are there easy additions or changes to the software we can make to make
> error messages clearer and self-resolving?   Obvious things in the
> documentation/manpages we can clean up?    (Aside:  I think Puppet
> Dashboard has a LOT of opportunity to help with this too, so watch this
> space!)
>
> I''m going to be looking into this myself, but I''d love to
hear from
> you.   Any and all data is welcome.   (If you''d prefer to reply
> personally or talk over IRC, that''s fine too.)
>
> Thanks!
>
> --Michael
-- 
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 Thu, Feb 4, 2010 at 5:34 PM, Daniel Kerwin <d.k3rwin@googlemail.com>
wrote:
> What about a screencast series?
We will most definitely be doing this.   I can see this as a set of
content about various different tips, as well as some basics.

(Also using Dashboard)

--Michael

-- 
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, Feb 2, 2010 at 5:08 PM, Michael DeHaan
<michael@reductivelabs.com> wrote:
> With Puppet, if you''re just learning it, what were some of your
stumbling
> blocks?   If you are an existing user, think back to that time, or times
> when you were talking with new users?
#1 has to be variable scope and the inability to redefine variables.
     That and the knock on impact on things like inheritance,
     and the need for storeconfigs to ''know about'' the
variables of
another node.
#2 is the difficulty to test manifests reliably (the reliance on Facts
makes it tricky to even syntax
     check recipes without actually running it on a node). Makes #1
more of an issue.
     I keep getting bitten by interactions between modules, so it
needs to be some sort of integration
     test.
#3 is a best practice guide - e.g. is it best to have a separate class
heirarchy per OS / role, or fill
     your modules with case statements?

There are solutions/mitigations to all of these issues, the trouble is
there seem to be several solutions to all these issues :)

Oh, and while I''m posting, congratulations on the new job, Michael :)
of these :)

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

Le mardi 02 février 2010 à 12:08 -0500, Michael DeHaan a écrit
:
> Just one more email and I''ll let you go for a few hours :)
Hello puppeters

> One of the things I like to see in apps is that they are immediately 
> intuitive and easy to use for new users.  I think Puppet is really good 
> here, but there''s opportunity to make everything better.   We want
> everyone to love Puppet from their first few minutes using it, all the 
> way through to datacenter nirvana.
> 
> With Puppet, if you''re just learning it, what were some of your 
> stumbling blocks?   If you are an existing user, think back to that 
> time, or times when you were talking with new users?
To join Peter : SSL. SSL is just a pain in the a**. As you said, some
don''t want to know about ruby webservers in detail, some don''t
want to
know about SSL.

Tell more in the beginner''s guide about DNS, and the need to have a
clean DNS for puppet to work fine.

A place to share manifests. To me the wiki is not the right way to do
this. A kind of puppet github would be nice : you push your classes into
it, other people get them.

A "common errors" list that beginners can search through to find
error.
The poptop project has some pages like this that ease debugging. BTW,
some error messages would need to be a little "user friendly"

My 0.02€

Nico.

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

On 5/02/10 11:06 PM, Nicolas Szalay wrote:
> A "common errors" list that beginners can search through to find
error.
> The poptop project has some pages like this that ease debugging. BTW,
> some error messages would need to be a little "user friendly"
Nico

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

See the Troubleshooting and areas below.  Please feel free to add to
this!

Thanks

James Turnbull

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS2wKriFa/lDkFHAyAQIlYAgAxdMGrbdU9D6pX0wFMmocwkQ9+CRYN2l3
QoLd/GK7JjdNYqwX0ON+E+loWzipgpbZNFQDtw3Y3jdej0LXdWpHaBbe7ifRCu+2
G+1PnU7amp04FDjXYsa8xJPRo4Sa/Fp0S6hFizBfPKza9dLVdbPIlbRWswjTtp/i
+BuYYjO9ZUa4jw6se92UWuTVdKWG3h83hAXUqSNh3RKm+OdC1uY0mq5sUtYhgUdq
QY62dUB09+eXRcb0scF8zMkt72/o21TMgtX5/xIW2tc8kDIYY9mbB0QzyNXGuJtk
Zge5w0Vas2Y5GQfOZxiotQ/is6MeCClUu01cJ60HS9kXRHW8VwjznA==zt7D
-----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.

Le vendredi 05 février 2010 à 23:10 +1100, James Turnbull a écrit
:
> http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions
> 
> See the Troubleshooting and areas below.  Please feel free to add to
> this!
I did not remember this one :) I added a few lines :)

Nico.

On Feb 5, 2010, at 4:06 AM, Nicolas Szalay wrote:
> Le mardi 02 février 2010 à 12:08 -0500, Michael DeHaan a écrit :
>> Just one more email and I''ll let you go for a few hours :)
> 
> Hello puppeters
> 
> 
>> One of the things I like to see in apps is that they are immediately 
>> intuitive and easy to use for new users.  I think Puppet is really good
>> here, but there''s opportunity to make everything better.   We
want
>> everyone to love Puppet from their first few minutes using it, all the 
>> way through to datacenter nirvana.
>> 
>> With Puppet, if you''re just learning it, what were some of
your
>> stumbling blocks?   If you are an existing user, think back to that 
>> time, or times when you were talking with new users?
> 
> To join Peter : SSL. SSL is just a pain in the a**. As you said, some
> don''t want to know about ruby webservers in detail, some
don''t want to
> know about SSL.
> 
> Tell more in the beginner''s guide about DNS, and the need to have
a
> clean DNS for puppet to work fine.
While getting started I had some problems.

1) I couldn''t find a simple skeleton puppet configuration.  I tried the
tutorial, but there''s lots of things that can go wrong, and figuring
out what''s wrong can be be a pain if you don''t know what
you''re doing.  A sample.tar.gz that has a module that does nothing but
create a file in /tmp would be really helpful.  Just getting a configuration
that works and does something can be rather hard.


2) DNS: My setup was small and simple, so I''ve been using dnsmasq for
DNS and DHCP.  Dnsmasq doesn''t support cnames so the auto-generated
cert name on the puppetmaster doesn''t work.  I suggest that all
autogenerated certificates have an alias of "puppet" to make setup
easier.


3.1) SSL: Adding another server to an existing puppet setup is rather difficult
if you don''t know much about SSL.  Here''s something that would
be helpful although it might be too hard to be feasible:
Make it possible to have a new puppetmaster get a signing certificate from an
existing puppetmaster.  Then you''d use a command on the master server
that''s something like this "puppetca --sign --puppet-server
newservername.localhost".

and/or

3.2) Allow the generation of server certificates on the server like this
"puppetca --generate --puppet-server newserver.localhost"

In either of these cases I''d ask that the default is to give the
certificate an alias of "puppet".


4) Something nearly as good as 3 would be a shell script that uses ssh to login
to the server as root and does the same thing using the openssl command.


5) Error ambiguity: sometimes it''s hard to tell if an error is
happening on the client-side or server-side.
-Patrick

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

Michael DeHaan wrote:
> Just one more email and I''ll let you go for a few hours :)
>
> One of the things I like to see in apps is that they are immediately 
> intuitive and easy to use for new users.  I think Puppet is really 
> good here, but there''s opportunity to make everything better.   We
> want everyone to love Puppet from their first few minutes using it, 
> all the way through to datacenter nirvana.
>
> With Puppet, if you''re just learning it, what were some of your 
> stumbling blocks?   If you are an existing user, think back to that 
> time, or times when you were talking with new users?
>
> One of the ideas I had from cobbler was "cobbler check" which was
a
> tool you could run to identify some of these problems.   I''m not
sure
> if it makes sense for Puppet, but it may do some things like say "you 
> appear to have DNS problems resolving this, you should try..." and so 
> forth.   What else might there be?   Obviously one of the things
I''m
> going to be looking for are what questions keep coming up on IRC ... 
> Are there mainly questions around puppetca?   Should scaling be easier 
> to set up out of the box and in the default configuration (right after 
> RPM or deb install)?
>
> Are there easy additions or changes to the software we can make to 
> make error messages clearer and self-resolving?   Obvious things in 
> the documentation/manpages we can clean up?    (Aside:  I think Puppet 
> Dashboard has a LOT of opportunity to help with this too, so watch 
> this space!)
>
> I''m going to be looking into this myself, but I''d love to
hear from
> you.   Any and all data is welcome.   (If you''d prefer to reply 
> personally or talk over IRC, that''s fine too.)
>
> Thanks!
>
> --Michael
>
Hey Mike, SSLSSLSSLSSLSSL... SSL, it ''makes my brain bleed'' as
plathrop
of digg once said.

SSL has probably caused more suicides than drugs, first semester at MIT, 
and chronic depression combined. I''m not sure anything can be done
about
it though, that is the sucky part. I''m not sure any programmatic check 
is going to solve the difficulties associated with SSL auth. Maybe 
better error messages such as CN does not match DNS name, rather than 
whatever it says now (can''t even remember).

Everything has already been mentioned in this thread that stumps 
beginners, but as far as troubleshooting, RI Pienaar (Volcane) wrote up 
the best puppet troubleshooting doc I have seen yet as a blog post over 
at devco.net. I think maybe RL should ask him if they can throw it on 
the wiki or something.

-- 
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
L''ennui est contre-révolutionnaire

-- 
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 Fri, Feb 5, 2010 at 2:38 PM, Patrick <kc7zzv@gmail.com>
wrote:
>
Great info everyone, thanks for all the feedback.    Look for a lot of
improvements, especially in the documentation/example space soon.

--Michael

-- 
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 Feb 5, 2010, at 11:38 AM, Patrick wrote:
> 
> 2) DNS: My setup was small and simple, so I''ve been using dnsmasq
for DNS and DHCP.  Dnsmasq doesn''t support cnames so the auto-generated
cert name on the puppetmaster doesn''t work.  I suggest that all
autogenerated certificates have an alias of "puppet" to make setup
easier.
> 
It looks like I was wrong on this point, and that puppet already does this. 
Thanks for fixing this.

-Patrick Mohr

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

Late to the party here. I thought Gepetto looked useful for new puppet
users.  Similar to the Chef Repository on GitHub that new Chef users
are encouraged to clone:

http://wiki.opscode.com/display/chef/Chef+Repository

I have a hunch that the Chef users are more likely to be Ruby
developers and hence be used to git.  Gepetto will let the new user
create a well-structured repository without needing to be a git/github
user.

J.


On 6 February 2010 01:16, Michael DeHaan <michael@reductivelabs.com>
wrote:
> On Fri, Feb 5, 2010 at 2:38 PM, Patrick <kc7zzv@gmail.com> wrote:
>>
>
> Great info everyone, thanks for all the feedback.    Look for a lot of
> improvements, especially in the documentation/example space soon.
>
> --Michael
>
> --
> 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.
>
>


-- 
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com
http://twitter.com/builddoctor

-- 
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 honestly think the most important thing for new users is to clean up the
documentation.

Not a lot of the existing docs on the wiki read as being particularly
authoritative. They''re full of lines like:

"Exporting and collecting resources is an extension of virtual
resources<http://reductivelabs.com/trac/puppet/wiki/VirtualResources>.
Puppet provides an experimental superset of virtual resources, using a
similar syntax."  <- are exported resources really
"experimental" anymore?

Something that has been noted in the past as being problematic was the fact
that it''s not always clear what version of puppet given functionality
appeared in. This was a much bigger problem in the 0.24.x series where new
features were being added, and the new approach to releases should make this
easier, but it was definitely a problem in the past.

I like having a community contributed wiki, but wikis are prone to producing
documentation that isn''t authoritative ( "I managed to get foo to
work by
doing blah") without a clear sense of direction.




On Sat, Feb 6, 2010 at 4:38 AM, Julian Simpson
<simpsonjulian@gmail.com>wrote:
> Late to the party here. I thought Gepetto looked useful for new puppet
> users.  Similar to the Chef Repository on GitHub that new Chef users
> are encouraged to clone:
>
> http://wiki.opscode.com/display/chef/Chef+Repository
>
> I have a hunch that the Chef users are more likely to be Ruby
> developers and hence be used to git.  Gepetto will let the new user
> create a well-structured repository without needing to be a git/github
> user.
>
> J.
>
>
> On 6 February 2010 01:16, Michael DeHaan <michael@reductivelabs.com>
> wrote:
> > On Fri, Feb 5, 2010 at 2:38 PM, Patrick <kc7zzv@gmail.com>
wrote:
> >>
> >
> > Great info everyone, thanks for all the feedback.    Look for a lot of
> > improvements, especially in the documentation/example space soon.
> >
> > --Michael
> >
> > --
> > 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> > For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> >
> >
>
>
>
> --
> Julian Simpson
> Software Build and Deployment
> http://www.build-doctor.com
> http://twitter.com/builddoctor
>
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
nigel

-- 
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, Feb 9, 2010 at 11:15 AM, Nigel Kersten <nigelk@google.com>
wrote:
> I honestly think the most important thing for new users is to clean up the
> documentation.
> Not a lot of the existing docs on the wiki read as being particularly
> authoritative. They''re full of lines like:
> "Exporting and collecting resources is an extension of virtual
resources.
> Puppet provides an experimental superset of virtual resources, using a
> similar syntax."  <- are exported resources really
"experimental" anymore?
> Something that has been noted in the past as being problematic was the fact
> that it''s not always clear what version of puppet given
functionality
> appeared in. This was a much bigger problem in the 0.24.x series where new
> features were being added, and the new approach to releases should make
this
> easier, but it was definitely a problem in the past.
> I like having a community contributed wiki, but wikis are prone to
producing
> documentation that isn''t authoritative ( "I managed to get
foo to work by
> doing blah") without a clear sense of direction.
Yeah, I like Wiki''s too... I think there''s a bit of "best
practices"
kind of stuff we''ll want as well, in those docs, so we don''t
lead
people too far astray and get them frustrated.

So we''ll still have a Wiki for those things, because that''s
really
great info to capture as well.    Gotta have that.

I believe the docs are all in SVN now, and I realize the idea of
submitting a bug to change a page is suboptimal, though you can check
them all out in github.   Patches and help reviewing would be *VERY*
welcome.

If anyone wants to just send me email about portions that suck (in the
static docs), let me know, and I''ll get those cleaned up.

--Michael

-- 
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 Feb 9, 2010, at 10:40 AM, Michael DeHaan  
<michael@reductivelabs.com> wrote:
> On Tue, Feb 9, 2010 at 11:15 AM, Nigel Kersten <nigelk@google.com>  
> wrote:
>> I honestly think the most important thing for new users is to clean  
>> up the
>> documentation.
>> Not a lot of the existing docs on the wiki read as being particularly
>> authoritative. They''re full of lines like:
>> "Exporting and collecting resources is an extension of virtual  
>> resources.
>> Puppet provides an experimental superset of virtual resources,  
>> using a
>> similar syntax."  <- are exported resources really
"experimental"
>> anymore?
>> Something that has been noted in the past as being problematic was  
>> the fact
>> that it''s not always clear what version of puppet given
functionality
>> appeared in. This was a much bigger problem in the 0.24.x series  
>> where new
>> features were being added, and the new approach to releases should  
>> make this
>> easier, but it was definitely a problem in the past.
>> I like having a community contributed wiki, but wikis are prone to  
>> producing
>> documentation that isn''t authoritative ( "I managed to
get foo to
>> work by
>> doing blah") without a clear sense of direction.
>
> Yeah, I like Wiki''s too... I think there''s a bit of
"best practices"
> kind of stuff we''ll want as well, in those docs, so we
don''t lead
> people too far astray and get them frustrated.
>
> So we''ll still have a Wiki for those things, because
that''s really
> great info to capture as well.    Gotta have that.
>
> I believe the docs are all in SVN now, and I realize the idea of
> submitting a bug to change a page is suboptimal, though you can check
> them all out in github.   Patches and help reviewing would be *VERY*
> welcome.
I think patches & tickets are probably the best way to manage  
community contributions to the curated docs, which need to be kept to  
a much higher standard of quality than the "wild west" of wiki docs.

>
> If anyone wants to just send me email about portions that suck (in the
> static docs), let me know, and I''ll get those cleaned up.
This sounds great, but please keep feedback going through tickets.

Bruce

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

> This sounds great, but please keep feedback going through tickets.
>
Totally, I''ll file tickets for any comments we recieve.   
There''s
sometimes a bit of a barrier to people opening a ticket (might not
have an account, etc).

Obviously if folks can file tickets directly that''s better :)

--Michael

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

>
> While getting started I had some problems.
>
> 1) I couldn''t find a simple skeleton puppet configuration.  I
tried the tutorial, but there''s lots of things that can go wrong, and
figuring out what''s wrong can be be a pain if you don''t know
what you''re doing.  A sample.tar.gz that has a module that does nothing
but create a file in /tmp would be really helpful.  Just getting a configuration
that works and does something can be rather hard.
gepetto has some good ideas here.   I think the module library (puppet
common modules) will help too.


... snip (good comments) ...
>
> 5) Error ambiguity: sometimes it''s hard to tell if an error is
happening on the client-side or server-side.
> -Patrick

One idea I had here is just prefixing the errors with "[Client]" or
["Server"] ... though that could be a little verbose.  Any better
ideas on how we might handle this?  I am thinking we need to use more
magenta and orange :)  </kidding>

-- 
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 Fri, Feb 5, 2010 at 4:53 AM, Dick Davies <rasputnik@hellooperator.net>
wrote:
> On Tue, Feb 2, 2010 at 5:08 PM, Michael DeHaan
> <michael@reductivelabs.com> wrote:
>
>> With Puppet, if you''re just learning it, what were some of
your stumbling
>> blocks?   If you are an existing user, think back to that time, or
times
>> when you were talking with new users?
>
> #1 has to be variable scope and the inability to redefine variables.
>     That and the knock on impact on things like inheritance,
>     and the need for storeconfigs to ''know about'' the
variables of
> another node.
Lexical scope is in work here, so that should help immensely.

> #2 is the difficulty to test manifests reliably (the reliance on Facts
> makes it tricky to even syntax
>     check recipes without actually running it on a node). Makes #1
> more of an issue.
>     I keep getting bitten by interactions between modules, so it
> needs to be some sort of integration
>     test.
> #3 is a best practice guide - e.g. is it best to have a separate class
> heirarchy per OS / role, or fill
>     your modules with case statements?
Very much so.   We are totally doing this.   The common modules pool
will also enforce those best practices so we can have examples.
Definitely looking to all of you to help define and evolve what these
best practices are along with things that Teyo has picked up, among
others.

-- 
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 Feb 9, 2010, at 2:28 PM, Michael DeHaan <michael@reductivelabs.com>  
wrote:
>> This sounds great, but please keep feedback going through tickets.
>>
>
> Totally, I''ll file tickets for any comments we recieve.   
There''s
> sometimes a bit of a barrier to people opening a ticket (might not
> have an account, etc).
>
> Obviously if folks can file tickets directly that''s better :)
Agreed; there''s also the Feedback tab directly from the docs site,  
using GetSatisfaction; a little less formal than Redmine tickets, at  
least.

The more communication paths the merrier, provided there''s a canonical
backlog.

Cheers,
Bruce

--
Bruce Williams
http://reductivelabs.com
>
> --Michael
>
> -- 
> 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.