Puppet users - Apr 2010 - is puppet the right tool for me?

Hello,

I''m currently administering a vps running a dozen of php-sites. I use
several scripts for deploying new sites, updating them, taking the
backups and so on. All the system is quite fragile and error-prone.
I''m thinking about some more integrated solution. Can puppet be useful
in my situation? Or is it primarily intended for managing big number
of similarly configured hosts?

Best wishes,
Dmitry

-- 
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, Apr 7, 2010 at 12:10 PM, Dmitry V''yal <akamaus@gmail.com>
wrote:
> Hello,
>
> I''m currently administering a vps running a dozen of php-sites. I
use
> several scripts for deploying new sites, updating them, taking the
> backups and so on. All the system is quite fragile and error-prone.
> I''m thinking about some more integrated solution. Can puppet be
useful
> in my situation? Or is it primarily intended for managing big number
> of similarly configured hosts?
>
What do your scripts do?


>
> Best wishes,
> Dmitry
>
> --
> 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 Wed, Apr 07, 2010 at 12:10:07PM -0700, Dmitry V''yal
wrote:
> Hello,
> 
> I''m currently administering a vps running a dozen of php-sites. I
use
> several scripts for deploying new sites, updating them, taking the
> backups and so on. All the system is quite fragile and error-prone.
> I''m thinking about some more integrated solution. Can puppet be
useful
> in my situation? Or is it primarily intended for managing big number
> of similarly configured hosts?
The latter, but that doesn''t necessarily mean puppet couldn''t
be useful
to you.  After all, puppet lets you define dependencies so that you can
specify that action A is triggered when file B is modified, action C
happens if acion A is successful and so on, which must describe half of
what your scripts do.  It also lets you define templates and then create
multiple instances based on those templates and different
configurations, which must be the other half of what you do.  So I think
it can help you.  And you may find other things about your vps that it
can configure for you.

I would create a definition that describes your site layout.  Each time
you invoke that definition in your script, with different parameters,
it''ll create the site for you and trigger any necessary actions (like
restarting apache).  You can also have the directory hierarchy that
contains your sites managed by puppet in such a way that it will delete
any files that weren''t created by your current puppet config.  That
way,
all you have to do is remove the description of a site from your config
and all the files previously generated for it will be removed the next
time puppet is run.

You don''t need a puppetmaster to run puppet, you can run it on a single
host from local standalone scripts.  So you don''t need to incur the
overhead of running puppetmaster and puppet daemons just for your sites.

Of course, you can do this yourself by choosing your own templating
system and writing scripts to manipulate it, but puppet can make it much
simpler.

-- 
Bruce

If the universe were simple enough to be understood, we would be too
simple to understand it.

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

"Dmitry V''yal" <akamaus@gmail.com> writes:
> I''m currently administering a vps running a dozen of php-sites. I
use
> several scripts for deploying new sites, updating them, taking the backups
> and so on. All the system is quite fragile and error-prone.  I''m
thinking
> about some more integrated solution. Can puppet be useful in my situation?
> Or is it primarily intended for managing big number of similarly configured
> hosts?
Puppet can be useful to you, but you might also have to change the way you
approach things.

Anyway, to answer the specific questions:

Yes, puppet is useful to you.  (IMO, obviously.)

Regardless of if puppet is intended to manage multiple similar hosts, it is
still useful when you have a smaller number of unique hosts.

If every host is completely unique then you get one some benefits of puppet:
 * you have a single place to review your configuration
 * you can make changes without having to do it by hand
 * puppet checks nothing has changed, and puts it back if something has

However, I bet that all your hosts are a *lot* more alike than you think:
 * you probably use the same web server (apache, or so), and *mostly* have it
   set up the same way on each machine, right?
 * you probably use the same MTA on most machines
 * you probably use the same log watching and checking stuff on ''em all
 * you probably have similar needs for installing PHP and some extra PHP
   modules, which are usually configured more or less the same.[1]
 * you probably do a bunch of "install mysql, configure like this"
stuff the
   same on each host.

So, even at the scale you are looking I bet there is a whole lot of
"same"
between the machines you can exploit — and if you actively look for that you
can create a whole lot more same.

(Plus, once your hosts are more similar than different you can spend all your
 time focused on getting the software right rather than working out how you
 set up this particular machine. :)

        Daniel

Footnotes: 
[1]  ...or, perhaps, could be configured more or less the same.

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

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

Nigel Kersten wrote:
> 
> 
> On Wed, Apr 7, 2010 at 12:10 PM, Dmitry V''yal
<akamaus@gmail.com
> <mailto:akamaus@gmail.com>> wrote:
> 
>     Hello,
> 
>     I''m currently administering a vps running a dozen of
php-sites. I use
>     several scripts for deploying new sites, updating them, taking the
>     backups and so on. All the system is quite fragile and error-prone.
>     I''m thinking about some more integrated solution. Can puppet
be useful
>     in my situation? Or is it primarily intended for managing big number
>     of similarly configured hosts?
> 
> 
> What do your scripts do?
> 
One of the typical tasks is deploying the new site.
It involves creating the system user, creating the database and the 
database user, setting up the repository, pushing changes to it, adding 
the customized(domain and path to log files changes) config file for 
nginx, setting awstats config and so on.

Also, I need to remove sites sometimes.

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

Bruce Richardson wrote:
> On Wed, Apr 07, 2010 at 12:10:07PM -0700, Dmitry V''yal wrote:
>> Hello,
>>
>> I''m currently administering a vps running a dozen of
php-sites. I use
>> several scripts for deploying new sites, updating them, taking the
>> backups and so on. All the system is quite fragile and error-prone.
>> I''m thinking about some more integrated solution. Can puppet
be useful
>> in my situation? Or is it primarily intended for managing big number
>> of similarly configured hosts?
> 
> The latter, but that doesn''t necessarily mean puppet
couldn''t be useful
> to you.  After all, puppet lets you define dependencies so that you can
> specify that action A is triggered when file B is modified, action C
> happens if acion A is successful and so on, which must describe half of
> what your scripts do.  It also lets you define templates and then create
> multiple instances based on those templates and different
> configurations, which must be the other half of what you do.  So I think
> it can help you.  And you may find other things about your vps that it
> can configure for you.
> 
> I would create a definition that describes your site layout.  Each time
> you invoke that definition in your script, with different parameters,
> it''ll create the site for you and trigger any necessary actions
(like
> restarting apache).  You can also have the directory hierarchy that
> contains your sites managed by puppet in such a way that it will delete
> any files that weren''t created by your current puppet config. 
That way,
> all you have to do is remove the description of a site from your config
> and all the files previously generated for it will be removed the next
> time puppet is run.
> 
Looks very promising to me :)

One of the problems with my current setup, is what there is no central 
storage of configuration After one ran the script, the only way to see 
what''s is currently served is to manually look at all these config
files
and site directories.

Another problem, is what from time to time after I made some 
enhancements all the configs must be modified a bit. For example, I 
setup a log analyzing utility and now it must be enabled for all the 
sites. Such an operation is extremely painful right now.
> You don''t need a puppetmaster to run puppet, you can run it on a
single
> host from local standalone scripts.  So you don''t need to incur
the
> overhead of running puppetmaster and puppet daemons just for your sites. 
Great )
Some time ago I looked at Chef, but even in it''s minimal configuration 
it looked like an overkill for my needs.
> Of course, you can do this yourself by choosing your own templating
> system and writing scripts to manipulate it, but puppet can make it much
> simpler.
> 
Yeah, I''m already fed up with my current sed-based templates and wanted
to move to ERB, but it reminded my reinventing the wheel the second time 
in a row :)

Thank you very much for all the suggestions

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

Daniel Pittman wrote:
> "Dmitry V''yal" <akamaus@gmail.com> writes:
> 
>> I''m currently administering a vps running a dozen of
php-sites. I use
>> several scripts for deploying new sites, updating them, taking the
backups
>> and so on. All the system is quite fragile and error-prone. 
I''m thinking
>> about some more integrated solution. Can puppet be useful in my
situation?
>> Or is it primarily intended for managing big number of similarly
configured
>> hosts?
> 
> Puppet can be useful to you, but you might also have to change the way you
> approach things.
I''m always ready.
> 
> Anyway, to answer the specific questions:
> 
> Yes, puppet is useful to you.  (IMO, obviously.)
> 
> Regardless of if puppet is intended to manage multiple similar hosts, it is
> still useful when you have a smaller number of unique hosts.
> 
> If every host is completely unique then you get one some benefits of
puppet:
>  * you have a single place to review your configuration
>  * you can make changes without having to do it by hand
>  * puppet checks nothing has changed, and puts it back if something has
> 
> However, I bet that all your hosts are a *lot* more alike than you think:
>  * you probably use the same web server (apache, or so), and *mostly* have
it
>    set up the same way on each machine, right?
>  * you probably use the same MTA on most machines
>  * you probably use the same log watching and checking stuff on
''em all
>  * you probably have similar needs for installing PHP and some extra PHP
>    modules, which are usually configured more or less the same.[1]
>  * you probably do a bunch of "install mysql, configure like
this" stuff the
>    same on each host.
Hmm, you''re right, I didn''t thought about it, but each member
of our
team has a desktop machine he uses for development and testing. And as 
it comes to web related things, the setup is intentionally almost the 
same as on the server.

Also, currently we''re planning to change the geographic location of vps
and to move from gentoo to ubuntu. Looks like a perfect time for big 
changes.

> 
> So, even at the scale you are looking I bet there is a whole lot of
"same"
> between the machines you can exploit — and if you actively look for that
you
> can create a whole lot more same.
> 
> (Plus, once your hosts are more similar than different you can spend all
your
>  time focused on getting the software right rather than working out how you
>  set up this particular machine. :)
Yeah, I''m beginning to understand that :)

Thanks for the ideas.

-- 
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, Apr 08, 2010 at 11:31:18AM +0400, Dmitry V''yal
wrote:
> Also, currently we''re planning to change the geographic location
of vps
> and to move from gentoo to ubuntu. Looks like a perfect time for big  
> changes.
There''s never a perfect time for big changes.  Change one thing at a
time wherever possible.


-- 
Bruce

Hierophant: someone who remembers, when you are on the way down,
everything you did to them on the way up.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Regardless of if puppet is intended to manage multiple similar hosts, it is
> still useful when you have a smaller number of unique hosts.
>
> If every host is completely unique then you get one some benefits of
puppet:
>  * you have a single place to review your configuration
>  * you can make changes without having to do it by hand
>  * puppet checks nothing has changed, and puts it back if something has
>
> However, I bet that all your hosts are a *lot* more alike than you think:
>  * you probably use the same web server (apache, or so), and *mostly* have
it
>   set up the same way on each machine, right?
>  * you probably use the same MTA on most machines
>  * you probably use the same log watching and checking stuff on
''em all
>  * you probably have similar needs for installing PHP and some extra PHP
>   modules, which are usually configured more or less the same.[1]
>  * you probably do a bunch of "install mysql, configure like
this" stuff the
>   same on each host.
>
You forgot a biggy bonus of puppet, no matter what size you support. I
have several small ( as in 1-3) groups  of very different machines,
and with puppet I can rebuild them very quickly on when they need to
be replaced or upgraded. doing it by hand takes most of a day or 2.

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

>
> Hmm, you''re right, I didn''t thought about it, but each
member of our team
> has a desktop machine he uses for development and testing. And as it comes
> to web related things, the setup is intentionally almost the same as on the
> server.
>
> Also, currently we''re planning to change the geographic location
of vps and
> to move from gentoo to ubuntu. Looks like a perfect time for big changes.
>
>
>>
Having migrated a production environment in place ( yeah stupid I
know, but did not have an option) from random scripts to puppet. I
would say the easiest, safest and fastest way to learn puppet and get
the migration done, is to teach puppet how to things the way they are
now. Now this is not the ideal setup for puppet, but once puppet is
talking to all the machines, then you can use puppet to slowly
"rewrite" the machine is to a puppet sanitized way of doing things and
then life just gets better.

Evan

P.S. Luke, puppet is still making life so nice and needs such little
maintaince, I forget to checkup on the list. Thanks for such great
tool.

-- 
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, Apr 07, 2010 at 12:10:07PM -0700, Dmitry V''yal
wrote:
> Hello,
> 
> I''m currently administering a vps running a dozen of php-sites. I
use
> several scripts for deploying new sites, updating them, taking the
> backups and so on. All the system is quite fragile and error-prone.
> I''m thinking about some more integrated solution. Can puppet be
useful
> in my situation? Or is it primarily intended for managing big number
> of similarly configured hosts?
Hi Dmitry,

I''ve been looking at ControlTier to do this kind of thing.  That said,
I
haven''t had a chance to try it yet, so I can''t vouch for it.

http://controltier.org/wiki/Main_Page

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerlach@feds.uwaterloo.ca
w: http://feds.ca/

"To Serve, Empower, and Represent the Undergraduate Students of the
University
of Waterloo"

-- 
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, Apr 8, 2010 at 12:15 AM, Dmitry V''yal <akamaus@gmail.com>
wrote:
> Bruce Richardson wrote:
>
>> On Wed, Apr 07, 2010 at 12:10:07PM -0700, Dmitry V''yal wrote:
>>
>>> Hello,
>>>
>>> I''m currently administering a vps running a dozen of
php-sites. I use
>>> several scripts for deploying new sites, updating them, taking the
>>> backups and so on. All the system is quite fragile and error-prone.
>>> I''m thinking about some more integrated solution. Can
puppet be useful
>>> in my situation? Or is it primarily intended for managing big
number
>>> of similarly configured hosts?
>>>
>>
>> The latter, but that doesn''t necessarily mean puppet
couldn''t be useful
>> to you.  After all, puppet lets you define dependencies so that you can
>> specify that action A is triggered when file B is modified, action C
>> happens if acion A is successful and so on, which must describe half of
>> what your scripts do.  It also lets you define templates and then
create
>> multiple instances based on those templates and different
>> configurations, which must be the other half of what you do.  So I
think
>> it can help you.  And you may find other things about your vps that it
>> can configure for you.
>>
>> I would create a definition that describes your site layout.  Each time
>> you invoke that definition in your script, with different parameters,
>> it''ll create the site for you and trigger any necessary
actions (like
>> restarting apache).  You can also have the directory hierarchy that
>> contains your sites managed by puppet in such a way that it will delete
>> any files that weren''t created by your current puppet config. 
That way,
>> all you have to do is remove the description of a site from your config
>> and all the files previously generated for it will be removed the next
>> time puppet is run.
>>
>>  Looks very promising to me :)
>
> One of the problems with my current setup, is what there is no central
> storage of configuration After one ran the script, the only way to see
> what''s is currently served is to manually look at all these config
files and
> site directories.
>
Or look at the local storage of the catalog.

Volcane put together a nice little script for this.

http://www.devco.net/archives/2010/03/30/puppet_localconfig_parser_-_20100330.php



>
> Another problem, is what from time to time after I made some enhancements
> all the configs must be modified a bit. For example, I setup a log
analyzing
> utility and now it must be enabled for all the sites. Such an operation is
> extremely painful right now.
>
>
>  You don''t need a puppetmaster to run puppet, you can run it on a
single
>> host from local standalone scripts.  So you don''t need to
incur the
>> overhead of running puppetmaster and puppet daemons just for your
sites.
>>
>
> Great )
> Some time ago I looked at Chef, but even in it''s minimal
configuration it
> looked like an overkill for my needs.
>
>
>  Of course, you can do this yourself by choosing your own templating
>> system and writing scripts to manipulate it, but puppet can make it
much
>> simpler.
>>
>>  Yeah, I''m already fed up with my current sed-based templates
and wanted
> to move to ERB, but it reminded my reinventing the wheel the second time in
> a row :)
>
> Thank you very much for all the suggestions
>
>
> --
> 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 Apr 8, 2010, at 7:24 AM, Evan Hisey wrote:
>> Regardless of if puppet is intended to manage multiple similar hosts,
it is
>> still useful when you have a smaller number of unique hosts.
>> 
>> If every host is completely unique then you get one some benefits of
puppet:
>>  * you have a single place to review your configuration
>>  * you can make changes without having to do it by hand
>>  * puppet checks nothing has changed, and puts it back if something has
>> 
>> However, I bet that all your hosts are a *lot* more alike than you
think:
>>  * you probably use the same web server (apache, or so), and *mostly*
have it
>>   set up the same way on each machine, right?
>>  * you probably use the same MTA on most machines
>>  * you probably use the same log watching and checking stuff on
''em all
>>  * you probably have similar needs for installing PHP and some extra
PHP
>>   modules, which are usually configured more or less the same.[1]
>>  * you probably do a bunch of "install mysql, configure like
this" stuff the
>>   same on each host.
>> 
> 
> You forgot a biggy bonus of puppet, no matter what size you support. I
> have several small ( as in 1-3) groups  of very different machines,
> and with puppet I can rebuild them very quickly on when they need to
> be replaced or upgraded. doing it by hand takes most of a day or 2.
> 
+1 to this.  Almost all the computers I manage have pretty simple
configurations, but it''s nice to know that with 4 commands I can wipe
everything and bring it back to a known state.  I use a tftpinstall+preseeding
for ubuntu.  Then puppet finishes the job.  My usecase is probably different
from yours because most of my machines don''t have data that needs to be
saved on them.
-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.

Patrick <kc7zzv@gmail.com> writes:
> On Apr 8, 2010, at 7:24 AM, Evan Hisey wrote:
>
>>> Regardless of if puppet is intended to manage multiple similar
hosts, it is
>>> still useful when you have a smaller number of unique hosts.
>>> 
>>> If every host is completely unique then you get one some benefits
of puppet:
>>>  * you have a single place to review your configuration
>>>  * you can make changes without having to do it by hand
>>>  * puppet checks nothing has changed, and puts it back if something
has
>>> 
>>> However, I bet that all your hosts are a *lot* more alike than you
think:
>>>  * you probably use the same web server (apache, or so), and
*mostly* have it
>>>   set up the same way on each machine, right?
>>>  * you probably use the same MTA on most machines
>>>  * you probably use the same log watching and checking stuff on
''em all
>>>  * you probably have similar needs for installing PHP and some
extra PHP
>>>   modules, which are usually configured more or less the same.[1]
>>>  * you probably do a bunch of "install mysql, configure like
this" stuff the
>>>   same on each host.
>> 
>> You forgot a biggy bonus of puppet, no matter what size you support. I
have
>> several small ( as in 1-3) groups of very different machines, and with
>> puppet I can rebuild them very quickly on when they need to be replaced
or
>> upgraded. doing it by hand takes most of a day or 2.
>
> +1 to this.
*nod*  Thanks, Even, and Patrick: I did miss that, and it *is* really useful.
Even if it isn''t complete it can still be a big help.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

-- 
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, Apr 9, 2010 at 12:32 AM, Patrick <kc7zzv@gmail.com> wrote:
>
> +1 to this.  Almost all the computers I manage have pretty simple
> configurations, but it''s nice to know that with 4 commands I can
wipe
> everything and bring it back to a known state.  I use a
> tftpinstall+preseeding for ubuntu.  Then puppet finishes the job.  My
> usecase is probably different from yours because most of my machines
don''t
> have data that needs to be saved on them.
> -Patrick
>
>
The only way I was sure that I can rebuild my machine at any point in time
is to reinstall it fresh with puppet, so far we were able to do more than
1500 clean installations with puppet.... (and some other tool for
provisioning).

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.

Evan Hisey wrote:
>> Regardless of if puppet is intended to manage multiple similar hosts,
it is
>> still useful when you have a smaller number of unique hosts.
>>
>> If every host is completely unique then you get one some benefits of
puppet:
>>  * you have a single place to review your configuration
>>  * you can make changes without having to do it by hand
>>  * puppet checks nothing has changed, and puts it back if something has
>>
>> However, I bet that all your hosts are a *lot* more alike than you
think:
>>  * you probably use the same web server (apache, or so), and *mostly*
have it
>>   set up the same way on each machine, right?
>>  * you probably use the same MTA on most machines
>>  * you probably use the same log watching and checking stuff on
''em all
>>  * you probably have similar needs for installing PHP and some extra
PHP
>>   modules, which are usually configured more or less the same.[1]
>>  * you probably do a bunch of "install mysql, configure like
this" stuff the
>>   same on each host.
>>
> 
> You forgot a biggy bonus of puppet, no matter what size you support. I
> have several small ( as in 1-3) groups  of very different machines,
> and with puppet I can rebuild them very quickly on when they need to
> be replaced or upgraded. doing it by hand takes most of a day or 2.
> 
That''s great! And what to do with various passwords, private keys and
so
on? Should I put them in manifest?

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

Dmitry V''yal <akamaus@gmail.com> writes:
> Evan Hisey wrote:
>>> Regardless of if puppet is intended to manage multiple similar
hosts, it is
>>> still useful when you have a smaller number of unique hosts.
>>>
>>> If every host is completely unique then you get one some benefits
of puppet:
>>>  * you have a single place to review your configuration
>>>  * you can make changes without having to do it by hand
>>>  * puppet checks nothing has changed, and puts it back if something
has
>>>
>>> However, I bet that all your hosts are a *lot* more alike than you
think:
>>>  * you probably use the same web server (apache, or so), and
*mostly* have it
>>>   set up the same way on each machine, right?
>>>  * you probably use the same MTA on most machines
>>>  * you probably use the same log watching and checking stuff on
''em all
>>>  * you probably have similar needs for installing PHP and some
extra PHP
>>>   modules, which are usually configured more or less the same.[1]
>>>  * you probably do a bunch of "install mysql, configure like
this" stuff the
>>>   same on each host.
>>>
>>
>> You forgot a biggy bonus of puppet, no matter what size you support. I
>> have several small ( as in 1-3) groups  of very different machines,
>> and with puppet I can rebuild them very quickly on when they need to
>> be replaced or upgraded. doing it by hand takes most of a day or 2.
>
> That''s great! And what to do with various passwords, private keys
and so on?
> Should I put them in manifest?
That is a hard call, and there is probably no single answer.

For what it is worth, we decided that this was an acceptable security risk in
some places (database passwords containing unclassified data only), and
unacceptable in others (SSL certificate private keys).

We presently distribute the later set, the keys, only through manual action,
although you can use puppet-specific restrictions to serve them up safely from
external files.

I hope to have some acceptable solution that keeps both my needs (no manual
setup) and the needs of our auditors (keep things secure) in balance, but
don''t presently have one.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

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

>> That''s great! And what to do with various passwords, private
keys and so on?
>> Should I put them in manifest?
>
> That is a hard call, and there is probably no single answer.
>
> For what it is worth, we decided that this was an acceptable security risk
in
> some places (database passwords containing unclassified data only), and
> unacceptable in others (SSL certificate private keys).
>
> We presently distribute the later set, the keys, only through manual
action,
> although you can use puppet-specific restrictions to serve them up  
> safely from
> external files.
>
> I hope to have some acceptable solution that keeps both my needs (no manual
> setup) and the needs of our auditors (keep things secure) in balance, but
> don''t presently have one.
>
we lookup passwords via an external source, which is only located on  
the master. so in the manifests you find only the lookup statement.  
ssl-keys are managed by puppet but stored in a module which is  
seperated from all the other modules and which resists only on the  
master within a local git repository.

so far we see this as comfortable as possible with the best (?)  
possible security you can have in such a centralized setup.

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.

Daniel Pittman writes:
 > Dmitry V''yal <akamaus@gmail.com> writes:
 > > Evan Hisey wrote:
 > >> You forgot a biggy bonus of puppet, no matter what size you
support. I
 > >> have several small ( as in 1-3) groups  of very different
machines,
 > >> and with puppet I can rebuild them very quickly on when they need
to
 > >> be replaced or upgraded. doing it by hand takes most of a day or
2.
 > >
 > > That''s great! And what to do with various passwords, private
keys and so on?
 > > Should I put them in manifest?
 > 
 > That is a hard call, and there is probably no single answer.
 > 
 > For what it is worth, we decided that this was an acceptable security risk
in
 > some places (database passwords containing unclassified data only), and
 > unacceptable in others (SSL certificate private keys).
 > 
 > We presently distribute the later set, the keys, only through manual
action,
 > although you can use puppet-specific restrictions to serve them up safely
from
 > external files.

What we decided to do at our site was create a separate version control
repository for secure data (passwords, certificate keys, private ssh
keys) that is not network-accessible and resides only on the
puppetmaster host.  The repository is checked out under
/etc/puppet/secure and mounted as a separate module in fileserver.conf,
so that manifests can refer to files using specifications like
"puppet:///secure/foo.key".  Then Puppet can automatically distribute
the security-sensitive files but they don''t live in the main repository
which is widely distributed (working copies live on all the admin
workstations, for example).  The minor disadvantage is that you have to
log in to the puppetmaster host to actually change anything in the
secure repository, but things don''t change in there very often.

-- 
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, Apr 08, 2010 at 09:32:44AM -0700, Patrick wrote:
> > You forgot a biggy bonus of puppet, no matter what size you support. I
> > have several small ( as in 1-3) groups  of very different machines,
> > and with puppet I can rebuild them very quickly on when they need to
> > be replaced or upgraded. doing it by hand takes most of a day or 2.
> > 
> 
> +1 to this.  Almost all the computers I manage have pretty simple
> configurations, but it''s nice to know that with 4 commands I can
wipe
> everything and bring it back to a known state.  I use a
> tftpinstall+preseeding for ubuntu.  Then puppet finishes the job.  My
usecase
> is probably different from yours because most of my machines don''t
have data
> that needs to be saved on them.
If you want to keep your data (as we do), put it on a separate partition (all
our data is in /srv, and that''s on a separate partition), then make
sure your
preseed doesn''t nuke that partition.  Keep backups in case you need to
restore
it.  We can restore a host in about 25 minutes if we care to do it quickly.

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerlach@feds.uwaterloo.ca
w: http://feds.ca/

"To Serve, Empower, and Represent the Undergraduate Students of the
University
of Waterloo"

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