Puppet users - Dec 2007 - Not so complex CompleteConfiguration example of a Complete Configuration?

I am new to Puppet and very eager to apply it to a project.

But I am somewhat stymied by the learning curve. So far I''ve found  
many very simple examples of how to modify a file or add a user and a  
very complex example
http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration
.

I have not been able to find any other examples of a total  
configuration tree (ie /etc/puppet/*) that I can learn from and try as  
an initial deployment that I can then tweak and add too. That would  
allow me to get started and learn by doing.

So my request, is, does anyone have an example complete configuration  
that isn''t tooo complex, or that works pretty much out of the box on  
Fedora and does something useful like deploys a Fedora system with  
apache and maybe mysql?


That would be greatly appreciated!
Thanks
Rob

––––––––––––––––––––––––––––––
Robert J. Berger - Internet Bandwidth Development, LLC.
Voice: 408-838-8896 eFax: +1-408-490-2868
http://www.ibd.com

Hi Robert,

I''m not using Fedora, but I am documenting my journey with Puppet on
my blog: http://plathrop.tertiusfamily.net. I hope to provide a useful
set of articles that works through the process of starting with small,
trivial tasks and moving on into gradually more complex setups. So
far, I''ve only posted the first article, a "Getting Started",
but I
plan on posting the next one today.

Hopefully, despite being documentation of a Debian setup, it will
still be applicable to Fedora.

--Paul

On Dec 13, 2007 11:47 PM, Robert J. Berger <rberger@ibd.com>
wrote:
> I am new to Puppet and very eager to apply it to a project.
>
> But I am somewhat stymied by the learning curve. So far I''ve found
> many very simple examples of how to modify a file or add a user and a
> very complex example
http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration
> .
>
> I have not been able to find any other examples of a total
> configuration tree (ie /etc/puppet/*) that I can learn from and try as
> an initial deployment that I can then tweak and add too. That would
> allow me to get started and learn by doing.
>
> So my request, is, does anyone have an example complete configuration
> that isn''t tooo complex, or that works pretty much out of the box
on
> Fedora and does something useful like deploys a Fedora system with
> apache and maybe mysql?
>
>
> That would be greatly appreciated!
> Thanks
> Rob
>
> ––––––––––––––––––––––––––––––
> Robert J. Berger - Internet Bandwidth Development, LLC.
> Voice: 408-838-8896 eFax: +1-408-490-2868
> http://www.ibd.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

Sorry, that URL is http://plathrop.tertiusfamily.net/blog

On Dec 14, 2007 8:50 AM, Paul Lathrop <paul@tertiusfamily.net>
wrote:
> Hi Robert,
>
> I''m not using Fedora, but I am documenting my journey with Puppet
on
> my blog: http://plathrop.tertiusfamily.net. I hope to provide a useful
> set of articles that works through the process of starting with small,
> trivial tasks and moving on into gradually more complex setups. So
> far, I''ve only posted the first article, a "Getting
Started", but I
> plan on posting the next one today.
>
> Hopefully, despite being documentation of a Debian setup, it will
> still be applicable to Fedora.
>
> --Paul
>
>
> On Dec 13, 2007 11:47 PM, Robert J. Berger <rberger@ibd.com> wrote:
> > I am new to Puppet and very eager to apply it to a project.
> >
> > But I am somewhat stymied by the learning curve. So far I''ve
found
> > many very simple examples of how to modify a file or add a user and a
> > very complex example
http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration
> > .
> >
> > I have not been able to find any other examples of a total
> > configuration tree (ie /etc/puppet/*) that I can learn from and try as
> > an initial deployment that I can then tweak and add too. That would
> > allow me to get started and learn by doing.
> >
> > So my request, is, does anyone have an example complete configuration
> > that isn''t tooo complex, or that works pretty much out of the
box on
> > Fedora and does something useful like deploys a Fedora system with
> > apache and maybe mysql?
> >
> >
> > That would be greatly appreciated!
> > Thanks
> > Rob
> >
> > ––––––––––––––––––––––––––––––
> > Robert J. Berger - Internet Bandwidth Development, LLC.
> > Voice: 408-838-8896 eFax: +1-408-490-2868
> > http://www.ibd.com
> >
> >
> > _______________________________________________
> > Puppet-users mailing list
> > Puppet-users@madstop.com
> > https://mail.madstop.com/mailman/listinfo/puppet-users
> >
>

On 12/14/2007 1:47 AM, Robert J. Berger wrote:
> So my request, is, does anyone have an example complete configuration  
> that isn''t tooo complex, or that works pretty much out of the box
on
> Fedora and does something useful like deploys a Fedora system with  
> apache and maybe mysql?
I''d guess that most people''s "complete
configurations" are going to be
pretty specific to their site. They may be applicable elsewhere, but 
there''s a lot of background experience and decisions that went into 
their current form. David''s stuff posted on the wiki is great, but
I''d
guess starting there would be a bit like learning to swim  by getting 
flung into the middle of a lake. Here''s what I (and I expect many of
us)
did to get started:

- Install puppet and puppetmaster somewhere (duh).

- Build a minimal manifest. I started with the sudoers one in the 
InstallationGuide. I don''t even use sudo on a regular basis, but it was
the most accessible example I could copy/paste for testing.

- Think of a simple administrative task you do all the time, either via 
Kickstart, looped ssh, or whatever. e.g., "I really need to make sure 
all my systems have ntpdate installed."

- Start looking through the TypeReference. Be aware that some types are 
new to 0.24 and may not work on an rpm puppet install if it''s an older 
release. While looking through the type reference, look for things that 
map back to your regular tasks. For the ntpdate example, a Debian box 
would use the package type to install the ntpdate deb, so I have:

   package { ntpdate: ensure => installed }

loaded as part of my manifest [1].

- Gradually work your way up to more complex tasks [2]. At first, it''ll
be a lot of package and file entries. Later, you''ll have to mess with 
exec. Eventually, you''ll want to refactor things and build include-able
classes. Then you''ll start building modules [3]. At some point,
you''ll
make Luke very happy by defining your own custom types that abstract out 
all the low-level work similar to how the builtin types abstract out 
editing cron jobs, installing packages, etc.

[1] http://blogs.cae.tntech.edu/mwr/2007/05/13/time-synchronization/
[2] 
http://blogs.cae.tntech.edu/mwr/2007/08/02/authentication-servers-the-next-generation/
[3] 
http://blogs.cae.tntech.edu/mwr/2007/08/02/the-new-file-server-puppet-and-modules/

-- 
Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

On 12/14/2007 11:29 AM, Mike Renfro wrote:
> - Think of a simple administrative task you do all the time, either via 
> Kickstart, looped ssh, or whatever. e.g., "I really need to make sure 
> all my systems have ntpdate installed."
Forgot one other thing related to this part. The systems I''m developing
manifests for are not mission-critical at the time I''m doing this sort 
of work. So my usual method of development is:

1. Install a needed package on the client manually.
2. Add an equivalent package entry to the manifest.
3. Run puppetd and make sure it doesn''t make other changes to the
system
based off my new manifest instruction.
4. Grab any config files that my manual package installation added, and 
put them in the puppetmaster''s fileserver area.
5. Add file lines to the manifest to copy down the configuration files 
to the client.
6. Rerun puppetd and make sure none of the config files change based off 
what I did in the manifest.

Repeat as needed.

-- 
Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

--On December 13, 2007 11:47:40 PM -0800 "Robert J. Berger" 
<rberger@ibd.com> wrote:
> I am new to Puppet and very eager to apply it to a project.
>
> But I am somewhat stymied by the learning curve. So far I've found
> many very simple examples of how to modify a file or add a user and a
> very complex example
> http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration  .
>
> I have not been able to find any other examples of a total
> configuration tree (ie /etc/puppet/*) that I can learn from and try as
> an initial deployment that I can then tweak and add too. That would
> allow me to get started and learn by doing.
>
> So my request, is, does anyone have an example complete configuration
> that isn't tooo complex, or that works pretty much out of the box on
> Fedora and does something useful like deploys a Fedora system with
> apache and maybe mysql?
>
>
> That would be greatly appreciated!
> Thanks
> Rob
>
> 
––––––––––––––––––––––––⍾ 
To setup the puppetmaster, the two key things to have is the location of 
the site.pp and the path to your modules directory.

puppet.conf:
[puppetmasterd]
manifest=/var/lib/puppet/site.pp
modulepath=/var/lib/puppet/modules

The site.pp is where you want to import any other paths you've setup if 
you're using them.  With PBP 2.0, we'll be recommending that most 
everything go into modules so you probably won't need as many 
subdirectories.  But as present, our site.pp does 2 important things: (a) 
imports our definitions/* (telling it to import all pp files in the 
definitions subdir where we store all our defined types), users/*, 
groups/*, os/*, and our nodes.pp file, and (b) setups up global defaults 
for types:

site.pp:
import "definitions/*"
import "users/*"
import "groups/*"
import "os/*"
import "nodes"

# files headed for file bucket "main" should be sent to server
"puppet"
filebucket { main: server => puppet }

# global defaults
# All files that change, the old copy should go to file bucket "main"
File { backup => main }
# Default paths for all exec types
Exec { path => "/usr/bin:/usr/sbin:/bin:/sbin" }

The nodes.pp is where we assign classes to nodes.  We generally just have
one class per node, and that class then includes or inherits whatever else 
it needs.  We also setup the basenode, which all nodes inherit from.  The 
basenode includes all the classes we want on all of our servers:

nodes.pp:
node basenode {
    include $operatingsystem,
        afs,
        cron,
        [....]
}

node web1 inherits basenode { include webserver }
node web2 inherits basenode { include webserver }
[....]

Now, to setup our webserver module.  In /var/lib/puppet/modules, create the 
following directory structure:

webserver/
         /manifests
         /files
         /templates

In the manifests directory goes our magic init.pp.  Why its magic: when we 
included webserver, since that class hadn't yet been "seen" by the
puppetmaster, it knows to look for an identically named directory under its 
module paths and if it finds one, it will parse the init.pp file.  So, our 
init.pp file will have:

init.pp:
class webserver {
    # We need the apache package
    package { "httpd": ensure => present }
    # Copy over our apache config file
    file { "/etc/httpd/conf.d/local.conf":
        source => "puppet:///webserver/local.conf",
    }
}

The above source for the file uses some magic too.  If there isn't a 
fileserver.conf that defines a [webserver] location, then puppet knows to 
look for a module named identically and look in that modules files subdir. 
So, we add the local.conf file to our modules/webserver/files.

And there we have a basic example.  I just wrote this up and didn't idiot 
check for typos but feel free to ask me any follow up questions or let me 
know if this doesn't work for you (I'm on semivacation so I may be slow 
responding but I want to help you as much as I can).



-- 
Digant C Kasundra, Linux Tech Lead
Information Technology Services, Stanford University
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Thanks, this (and the other responses) have been helpful, but I'm  
still somewhat dazed and confused.

In Digant's nice description below:
> To setup the puppetmaster, the two key things to have is the  
> location of
> the site.pp and the path to your modules directory.
>
> puppet.conf:
> [puppetmasterd]
> manifest=/var/lib/puppet/site.pp
> modulepath=/var/lib/puppet/modules
So is puppet.conf and nothing else is in /etc/puppet/puppet.conf? or  
are you somehow (command line or /etc/sysconfig) telling puppetmasterd  
that puppet.conf is located somewhere in /var/lib/puppet?

And then because of those lines in puppet.conf all of:
> definitions/*"
> users/
> groups/
> os/
> nodes

are in /var/lib/puppet and nothing is in /etc/puppet ?

and as stated modules and their related class declarations are in /var/ 
lib/puppet/modules

So that to keep it all under version control, I just need to put /var/ 
lib/puppet under version control? This is a confusing bit since most  
other examples seem to put all the human configurable configuration  
stuff in /etc/puppet.

And am still a bit hazy on the differences of definitions, modules and  
classes, and why most other examples have a classes directory and no  
definitions directory, but I probably can figure that out over time.

Thanks!

On Dec 15, 2007, at 10:47 AM, Digant C Kasundra wrote:
> --On December 13, 2007 11:47:40 PM -0800 "Robert J. Berger"
> <rberger@ibd.com> wrote:
>
>> I am new to Puppet and very eager to apply it to a project.
>>
>> But I am somewhat stymied by the learning curve. So far I've found
>> many very simple examples of how to modify a file or add a user and a
>> very complex example
>> http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration  .
>>
>> I have not been able to find any other examples of a total
>> configuration tree (ie /etc/puppet/*) that I can learn from and try  
>> as
>> an initial deployment that I can then tweak and add too. That would
>> allow me to get started and learn by doing.
>>
>> So my request, is, does anyone have an example complete configuration
>> that isn't tooo complex, or that works pretty much out of the box
on
>> Fedora and does something useful like deploys a Fedora system with
>> apache and maybe mysql?
>>
>>
>> That would be greatly appreciated!
>> Thanks
>> Rob
>>
>>
> ––––––––––––––––––––––––⍾
> To setup the puppetmaster, the two key things to have is the  
> location of
> the site.pp and the path to your modules directory.
>
> puppet.conf:
> [puppetmasterd]
> manifest=/var/lib/puppet/site.pp
> modulepath=/var/lib/puppet/modules
>
> The site.pp is where you want to import any other paths you've setup  
> if
> you're using them.  With PBP 2.0, we'll be recommending that most
> everything go into modules so you probably won't need as many
> subdirectories.  But as present, our site.pp does 2 important  
> things: (a)
> imports our definitions/* (telling it to import all pp files in the
> definitions subdir where we store all our defined types), users/*,
> groups/*, os/*, and our nodes.pp file, and (b) setups up global  
> defaults
> for types:
>
> site.pp:
> import "definitions/*"
> import "users/*"
> import "groups/*"
> import "os/*"
> import "nodes"
>
> # files headed for file bucket "main" should be sent to server  
> "puppet"
> filebucket { main: server => puppet }
>
> # global defaults
> # All files that change, the old copy should go to file bucket
"main"
> File { backup => main }
> # Default paths for all exec types
> Exec { path => "/usr/bin:/usr/sbin:/bin:/sbin" }
>
> The nodes.pp is where we assign classes to nodes.  We generally just  
> have
> one class per node, and that class then includes or inherits  
> whatever else
> it needs.  We also setup the basenode, which all nodes inherit  
> from.  The
> basenode includes all the classes we want on all of our servers:
>
> nodes.pp:
> node basenode {
>    include $operatingsystem,
>        afs,
>        cron,
>        [....]
> }
>
> node web1 inherits basenode { include webserver }
> node web2 inherits basenode { include webserver }
> [....]
>
> Now, to setup our webserver module.  In /var/lib/puppet/modules,  
> create the
> following directory structure:
>
> webserver/
>         /manifests
>         /files
>         /templates
>
> In the manifests directory goes our magic init.pp.  Why its magic:  
> when we
> included webserver, since that class hadn't yet been "seen"
by the
> puppetmaster, it knows to look for an identically named directory  
> under its
> module paths and if it finds one, it will parse the init.pp file.   
> So, our
> init.pp file will have:
>
> init.pp:
> class webserver {
>    # We need the apache package
>    package { "httpd": ensure => present }
>    # Copy over our apache config file
>    file { "/etc/httpd/conf.d/local.conf":
>        source => "puppet:///webserver/local.conf",
>    }
> }
>
> The above source for the file uses some magic too.  If there isn't a
> fileserver.conf that defines a [webserver] location, then puppet  
> knows to
> look for a module named identically and look in that modules files  
> subdir.
> So, we add the local.conf file to our modules/webserver/files.
>
> And there we have a basic example.  I just wrote this up and didn't  
> idiot
> check for typos but feel free to ask me any follow up questions or  
> let me
> know if this doesn't work for you (I'm on semivacation so I may be
> slow
> responding but I want to help you as much as I can).
>
>
>
> -- 
> Digant C Kasundra, Linux Tech Lead
> Information Technology Services, Stanford University
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
––––––––––––––––––––––––––––––
Robert J. Berger - Internet Bandwidth Development, LLC.
Voice: 408-838-8896 eFax: +1-408-490-2868
http://www.ibd.com


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Dec 15, 2007 1:05 PM, Robert J. Berger <rberger@ibd.com>
wrote:
> And then because of those lines in puppet.conf all of:
> > definitions/*"
> > users/
> > groups/
> > os/
> > nodes
>
> are in /var/lib/puppet and nothing is in /etc/puppet ?
Correct. Depending on how you want to interpret the Filesystem
Hierarchy Standard, you can use /var/lib/puppet, or /srv/puppet.
Digant is one of the authors of the Puppet Best Practices document on
the wiki, and this directory structure follows that document. This is
also what we''re using at my company.

puppet$ find /etc/puppet
/etc/puppet
/etc/puppet/puppet.conf
/etc/puppet/manifests
/etc/puppet/fileserver.conf

Note I never got around to rmdir /etc/puppet/manifests.
> So that to keep it all under version control, I just need to put /var/
> lib/puppet under version control? This is a confusing bit since most
> other examples seem to put all the human configurable configuration
> stuff in /etc/puppet.
We have /var/lib/puppet/master and /var/lib/puppet/modules under
subversion revision control. I set this up using the subversion recipe
on the puppet wiki.
> And am still a bit hazy on the differences of definitions, modules and
> classes, and why most other examples have a classes directory and no
> definitions directory, but I probably can figure that out over time.
A module contains manifests, templates and config files related to a
particular aspect of your configuration. For example, the
''webserver''
module might contain your manifests for installing and configuring
Apache with PHP.

A class is a one-time use collection of resource types to describe
some configuration.

A definition is similar to a class, but can be used multiple times.

Whether you want to separate your manifests out into classes and
definitions directories is up to you. We''re currently only doing that
on our configuration on things that are very complex (ie, long and
hard to browse through one file), or for classes/definitions that are
specific to our site and would otherwise need to be
''sanitized'' before
we make them available to the community. Most of our modules simply
have init.pp in the manifests directory because most of the
configurations are pretty short with only a handful of resources.

-j

--On December 15, 2007 12:05:46 PM -0800 "Robert J. Berger" 
<rberger@ibd.com> wrote:
> Thanks, this (and the other responses) have been helpful, but I''m
> still somewhat dazed and confused.
>
> In Digant''s nice description below:
>
>> To setup the puppetmaster, the two key things to have is the
>> location of
>> the site.pp and the path to your modules directory.
>>
>> puppet.conf:
>> [puppetmasterd]
>> manifest=/var/lib/puppet/site.pp
>> modulepath=/var/lib/puppet/modules
>
> So is puppet.conf and nothing else is in /etc/puppet/puppet.conf? or
> are you somehow (command line or /etc/sysconfig) telling puppetmasterd
> that puppet.conf is located somewhere in /var/lib/puppet?
My /etc/puppet contains only puppet.conf.  The ssl certs are in 
/var/lib/puppet/ssl and my manifests are all in /var/lib/puppet/manifests 
(the tree I discuss below for definitions, etc).  Modules are in 
/var/lib/puppet/modules.
>
> And then because of those lines in puppet.conf all of:
>> definitions/*"
>> users/
>> groups/
>> os/
>> nodes
>
>
> are in /var/lib/puppet and nothing is in /etc/puppet ?
>
> and as stated modules and their related class declarations are in /var/
> lib/puppet/modules
>
> So that to keep it all under version control, I just need to put /var/
> lib/puppet under version control? This is a confusing bit since most
> other examples seem to put all the human configurable configuration
> stuff in /etc/puppet.
Well, puppet.conf is the only human configurable thing, and even that is 
maintained by puppet itself (that''s right, our puppet client maintains
the
puppet.conf on our puppetmaster)
>
> And am still a bit hazy on the differences of definitions, modules and
> classes, and why most other examples have a classes directory and no
> definitions directory, but I probably can figure that out over time.
I''m amazed by the variety of layouts people are using.  There
isn''t any
right way, and the best practice is just based on our experiences at my 
institution.  As I mentioned in an earlier email, we''re changing our
entire
approach to rely as much on modules as possible.  And as for the people 
putting a classes subdir under modules'' file dir makes no sense to me
b/c
then you can''t use the magic namespace stuff.

-- 
Digant C Kasundra, Linux Tech Lead
Information Technology Services, Stanford University

> >
> > And am still a bit hazy on the differences of definitions, modules and
> > classes, and why most other examples have a classes directory and no
> > definitions directory, but I probably can figure that out over time.
> I''m amazed by the variety of layouts people are using.  There
isn''t any
> right way, and the best practice is just based on our experiences at my 
> institution.  As I mentioned in an earlier email, we''re changing
our entire
> approach to rely as much on modules as possible.  And as for the people 
> putting a classes subdir under modules'' file dir makes no sense to
me b/c
> then you can''t use the magic namespace stuff.
> -- 
> Digant C Kasundra, Linux Tech Lead
> Information Technology Services, Stanford University

I don''t think my situation is unique - I don''t have time to
sit down for six hours a day and learn a new language.  At best I can put in an
hour here, two there.

This isn''t ideal - but trying to carve enough time out of our schedule
to master puppet from the ground up - as if it were a new language or operating
system - isn''t going to happen.

Granted that you''re right about best practices but ... a cookbook would
be extremely helpful to get those of us who are newbs over that initial hump.

Brian Dunbar
Systems Administrator
Plexus
Desk: (920) 751-3364
Cell: (920) 716-2027



_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Dec 17, 2007, at 10:27 PM, Brian Dunbar wrote:
> I don''t think my situation is unique - I don''t have time
to sit
> down for six hours a day and learn a new language.  At best I can  
> put in an hour here, two there.
>
> This isn''t ideal - but trying to carve enough time out of our  
> schedule to master puppet from the ground up - as if it were a new  
> language or operating system - isn''t going to happen.
>
> Granted that you''re right about best practices but ... a cookbook
> would be extremely helpful to get those of us who are newbs over  
> that initial hump.
For the record, we''re hoping to be at the point in a year or two  
where you can just download solutions to the most common problems and  
only have to write Puppet code for your unique problems, but the  
product is too young to be there just yet.  It''s just now crossing  
from early adopter to a wider audience, and we''re pushing as fast as  
we can to meet the needs of everyone but it''s going to take a bit of  
time still.

  --
  Aizu''s Second Law:
      What changes the world is communication, not information.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

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

Luke Kanies wrote:
>> Granted that you''re right about best practices but ... a
cookbook
>> would be extremely helpful to get those of us who are newbs over  
>> that initial hump.
> 
One of the chapters in the forthcoming Puppet book does talk about
implementing Puppet and articulates some best practises - mostly in line
with the style used by Stanford in their documentation.

Regards

James Turnbull

- --
Author of:
- - Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
- - Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
- - Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHZ1sc9hTGvAxC30ARAqDkAKDMHYcmiHvXGxqZ8QRtKdNo7eBAOgCeMYuN
0IpY2gshbCxCYw/O4HWu9lk=uiq3
-----END PGP SIGNATURE-----

--On December 17, 2007 10:27:15 PM -0600 Brian Dunbar 
<Brian.Dunbar@plexus.com> wrote:
> I don''t think my situation is unique - I don''t have time
to sit down for
> six hours a day and learn a new language.  At best I can put in an hour
> here, two there.
>
> This isn''t ideal - but trying to carve enough time out of our
schedule to
> master puppet from the ground up - as if it were a new language or
> operating system - isn''t going to happen.
>
> Granted that you''re right about best practices but ... a cookbook
would
> be extremely helpful to get those of us who are newbs over that initial
> hump.
>
I agree.  A cookbook would be nice.  If I can free up some cycles in the 
new year, I''ll see what I can do.

-- 
Digant C Kasundra, Linux Tech Lead
Information Technology Services, Stanford University

" It''s just now crossing  from early adopter to a wider audience,
and we''re pushing as fast as
we can to meet the needs of everyone but it''s going to take a bit of 
time still."
 
I completely understand about the early adopter thing and documentation.  I see
the value in this and I''m more than willing to plow ahead and learn it
the hard way.  In the end I''ll have a broader set of skills than I
would otherwisse and that''s a good thing.
 
I certainly do appreciate y''all''s involvement with this.
Brian Dunbar
Systems Administrator
Plexus
Desk: (920) 751-3364
Cell: (920) 716-2027

________________________________

From: puppet-users-bounces@madstop.com on behalf of Luke Kanies
Sent: Mon 12/17/2007 11:23 PM
To: Puppet User Discussion
Subject: Re: [Puppet-users] Not so complex CompleteConfiguration exampleof a
Complete Configuration?



On Dec 17, 2007, at 10:27 PM, Brian Dunbar wrote:
> I don''t think my situation is unique - I don''t have time
to sit
> down for six hours a day and learn a new language.  At best I can 
> put in an hour here, two there.
>
> This isn''t ideal - but trying to carve enough time out of our 
> schedule to master puppet from the ground up - as if it were a new 
> language or operating system - isn''t going to happen.
>
> Granted that you''re right about best practices but ... a cookbook 
> would be extremely helpful to get those of us who are newbs over 
> that initial hump.
For the record, we''re hoping to be at the point in a year or two 
where you can just download solutions to the most common problems and 
only have to write Puppet code for your unique problems, but the 
product is too young to be there just yet.  It''s just now crossing 
from early adopter to a wider audience, and we''re pushing as fast as 
we can to meet the needs of everyone but it''s going to take a bit of 
time still.

  --
  Aizu''s Second Law:
      What changes the world is communication, not information.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com <http://reductivelabs.com/>  |
http://madstop.com <http://madstop.com/>


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users




_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

" If I can free up some cycles in the
new year, I''ll see what I can do."
 
Us working folks know that you guys in the academic world have all kinds of free
time and unlimited budgets to poke around with stuff like this (grin).
Brian Dunbar
Systems Administrator
Plexus
Desk: (920) 751-3364
Cell: (920) 716-2027

________________________________

From: puppet-users-bounces@madstop.com on behalf of Digant C Kasundra
Sent: Tue 12/18/2007 12:00 AM
To: Puppet User Discussion
Subject: Re: [Puppet-users] Not so complex CompleteConfiguration example of a
Complete Configuration?



--On December 17, 2007 10:27:15 PM -0600 Brian Dunbar
<Brian.Dunbar@plexus.com> wrote:
> I don''t think my situation is unique - I don''t have time
to sit down for
> six hours a day and learn a new language.  At best I can put in an hour
> here, two there.
>
> This isn''t ideal - but trying to carve enough time out of our
schedule to
> master puppet from the ground up - as if it were a new language or
> operating system - isn''t going to happen.
>
> Granted that you''re right about best practices but ... a cookbook
would
> be extremely helpful to get those of us who are newbs over that initial
> hump.
>
I agree.  A cookbook would be nice.  If I can free up some cycles in the
new year, I''ll see what I can do.

--
Digant C Kasundra, Linux Tech Lead
Information Technology Services, Stanford University
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users




_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

>I agree.  A cookbook would be nice.  If I can free up some
cycles in the 
>new year, I''ll see what I can do.
I know that this doesn''t help in the very near term since I
have a lot to get finished up before the campus closes on
Friday, but I have been working on a bunch of
documentation/examples in our internal documentation system
(Confluence Wiki).  Perhaps I will get bored over the holidays
and have some time to extract that information and then post
on the Puppet wiki.  I am working on getting some export
functionality enabled on our wiki so that I can just export
the pretty docs required by our project into an XML or HTML
file for the Puppet wiki.

It took us a while to get over the hump primarily due to
issues getting ldapnodes working.  Now that we have ldapnodes
working, we are moving full speed ahead --- right now the
sudoers file, sudo package, syslog-ng conf file, syslog-ng
package, syslog-ng SMF manifests, etc. are under Puppet
control on several of our Solaris systems (including Solaris
Zones).  After the holidays I will be setting up the
production puppetmaster(s) and beginning a full-scale
implementation.

I just posted the following to the wiki (In a very rough
format for now -- pretty much just the manifest files and an
install doc).  I will go back and elaborate but I don''t have
the time this week and I am sure that this is of interest to
someone in the interim.  

-Solaris 10 Puppet Client Install/Config Guide
http://reductivelabs.com/trac/puppet/wiki/SolarisPuppetClientInstallationGuide

-syslog-ng class manifest
http://reductivelabs.com/trac/puppet/wiki/syslog-ngRecipe

-sudo class manifest (extends the simplest puppet recipe by
managing the Solaris package as well)
http://reductivelabs.com/trac/puppet/wiki/BiggerSudoRecipe