Re: [Puppet Users] is puppet the right tool for me?

[Dmitry V'yal]

Nigel Kersten wrote:



On Wed, Apr 7, 2010 at 12:10 PM, 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?


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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Dmitry V'yal]

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Dmitry V'yal]

Daniel Pittman wrote:

"Dmitry V'yal"  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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Bruce Richardson]

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File Size

[Thomas Bellman]

Trevor Vaughan wrote:


Mainly sugar around the call with the ability to twiddle all of the
useful rsync flags in a platform-agnostic manner where possible.

That would be truly awesome.


I have such a define in my module "nsc-puppet-utils" (available at
http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git).  You use it
like this:

rsync_mirror {
epel-5-x86_64:
source => "rsync://mirrorhost/fedora-epel/5/x86_64/./",
target => "/pkg/epel-5.x86_64",
rsyncflags => ['--exclude', 'repoview', '--exclude', 'debug'],
creates => "/pkg/epel-5.x86_64/repodata/repomd.xml",
hour => 3, minute => 25;
}

This does two things: when run the first time, it actually does
an rsync of a directory tree.  And then it creates a cron job
for keeping the tree synchronized with the source.  You use the
'creates' parameter to indicate a file that you expect to exist
in the tree, so Puppet itself doesn't have to run rsync every
time.  If you mirror a large tree that could take a long time,
even if no files actually need to be transferred (I use it to
keep a mirror of CentOS and EPEL on a cluster, so we can re-install
our nodes anytime without being dependant on external servers).

Is this what you want?  Any suggestions for improvements?


/Bellman

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

Re: [Puppet Users] File Size

[Dan Bode]

On Thu, Apr 8, 2010 at 2:15 AM, Thomas Bellman  wrote:

> Trevor Vaughan wrote:
>
>  Mainly sugar around the call with the ability to twiddle all of the
>> useful rsync flags in a platform-agnostic manner where possible.
>>
>> That would be truly awesome.
>>
>
> I have such a define in my module "nsc-puppet-utils" (available at
> http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git).
>  You use it
> like this:
>
>rsync_mirror {
>epel-5-x86_64:
>source => "rsync://mirrorhost/fedora-epel/5/x86_64/./",
>target => "/pkg/epel-5.x86_64",
>rsyncflags => ['--exclude', 'repoview', '--exclude', 'debug'],
>creates => "/pkg/epel-5.x86_64/repodata/repomd.xml",
>hour => 3, minute => 25;
>}
>
> This does two things: when run the first time, it actually does
> an rsync of a directory tree.  And then it creates a cron job
> for keeping the tree synchronized with the source.  You use the
> 'creates' parameter to indicate a file that you expect to exist
> in the tree, so Puppet itself doesn't have to run rsync every
> time.  If you mirror a large tree that could take a long time,
> even if no files actually need to be transferred (I use it to
> keep a mirror of CentOS and EPEL on a cluster, so we can re-install
> our nodes anytime without being dependant on external servers).
>
> Is this what you want?  Any suggestions for improvements?
>

I would prefer if puppet ran the sync. It would be nice to receive puppet
events for any changes made via rsync (essentially reports of which files
change, this would require that it is implemented in ruby).

I can see from reading the man page that there is a --dryrun call that could
be used to determine rather rsync should be run or not. Is this reasonable
to run this to determine if Puppet should run? or is that too slow?


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

[Puppet Users] Re: Possible options to transfer information from nodes to master?

[Tore]

Hi,

Thanks again for the answers. I've haven't got to much time to play
with puppet, but I always seems to forget that puppet compiles the
code at the master, and sends this code to the nodes. The only thing
that is transferred from the nodes regarding information, is facter
information. Hence the variable ($ifconfig = generate("/usr/sbin/
ifconfig", "eth0") will be equal on all nodes when they get the
compiled configuration.

The only simple way I can think of is creating a manifest which uses
curl to POST a file to a HTTP server (or some other protocol). It can
be quite time consuming to compare 30 httpd.conf just to verify that
they are equal (they should be, but you never know without checking
it) before managing them with puppet.

Thanks for your help

/Tore


On 7 apr, 16:36, Daniel Pittman  wrote:
> Tore  writes:
> > What options does puppet provide to transfer information back to
> > puppetmaster?
>
> Facter, as was already pointed out, and the option of exported and imported
> resources if you have storeconfig enabled.  However...
>
> [...]
>
> > I have a few cases where just retrieving file X from all nodes would
> > be excellent, e.g. httpd.conf, just to diff them locally to verify
> > that no differences is present, before adding a manifest for handling
> > that file.
>
> > Does puppet have anything in stock for me here?
>
> ...this is not something that puppet is really designed to do, as far as I am
> aware.  So, it doesn't really offer many tools to support this sort of
> discovery.
>
> I tend to use 'noop' on the specific resource and 'puppetd --test' on the
> servers, or to use our ad-hoc change tools to fetch the appropriate files back
> to my central system for me.
>
>         Daniel
> --
> ✣ Daniel Pittman            ✉ dan...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] How to set variables for groups of computers

[Kenneth Holter]

Hi.


I'm in need of setting a few variables for groups of nodes/computers, and
could use some advice on how to set this up. I'm just about to start using a
extlookup.rb setup, which in the default setup enables me to set variables
based on facter information (plus the "common" default file). I need,
however, to set variables based on wether a computer belongs to
group "testbed-1", "testbed-2", "qass-1", and so forth. How have others
implemented this type of thing - have you used extlookup.rb, or some other
method of grouping computers? I guess I could on a per node basis (in
nodes.pp) set "$computer_group = testbed-1" and so forth, but I'm sure there
are better ways of defining which group a computer belongs to.


Best regards,
Kenneth Holter

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

Re: [Puppet Users] How to set variables for groups of computers

[Dan Bode]

On Thu, Apr 8, 2010 at 4:48 AM, Kenneth Holter wrote:

> Hi.
>
>
> I'm in need of setting a few variables for groups of nodes/computers, and
> could use some advice on how to set this up. I'm just about to start using a
> extlookup.rb setup, which in the default setup enables me to set variables
> based on facter information (plus the "common" default file). I need,
> however, to set variables based on wether a computer belongs to
> group "testbed-1", "testbed-2", "qass-1", and so forth. How have others
> implemented this type of thing - have you used extlookup.rb, or some other
> method of grouping computers? I guess I could on a per node basis (in
> nodes.pp) set "$computer_group = testbed-1" and so forth, but I'm sure there
> are better ways of defining which group a computer belongs to.
>


this is one of the basic functions of an external node classifier. Check out
the Puppet Dashboard.


>
> Best regards,
> Kenneth Holter
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to set variables for groups of computers

[Ohad Levy]

Hi,

http://theforeman.org/projects/foreman/wiki/External_Nodes#Host-Groups

Hopefully this helps :)

Ohad

On Thu, Apr 8, 2010 at 7:48 PM, Kenneth Holter wrote:

> Hi.
>
>
> I'm in need of setting a few variables for groups of nodes/computers, and
> could use some advice on how to set this up. I'm just about to start using a
> extlookup.rb setup, which in the default setup enables me to set variables
> based on facter information (plus the "common" default file). I need,
> however, to set variables based on wether a computer belongs to
> group "testbed-1", "testbed-2", "qass-1", and so forth. How have others
> implemented this type of thing - have you used extlookup.rb, or some other
> method of grouping computers? I guess I could on a per node basis (in
> nodes.pp) set "$computer_group = testbed-1" and so forth, but I'm sure there
> are better ways of defining which group a computer belongs to.
>
>
> Best regards,
> Kenneth Holter
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File Size

[Trevor Vaughan]

That's definitely reasonable and probably worthwhile.

And having this be an internal puppet type that could parse the output
of rsync and report errors, etc... would be ideal.

Trevor

On Thu, Apr 8, 2010 at 6:22 AM, Dan Bode  wrote:
>
>
> On Thu, Apr 8, 2010 at 2:15 AM, Thomas Bellman  wrote:
>>
>> Trevor Vaughan wrote:
>>
>>> Mainly sugar around the call with the ability to twiddle all of the
>>> useful rsync flags in a platform-agnostic manner where possible.
>>>
>>> That would be truly awesome.
>>
>> I have such a define in my module "nsc-puppet-utils" (available at
>> http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git).  You use it
>> like this:
>>
>>    rsync_mirror {
>>        epel-5-x86_64:
>>            source => "rsync://mirrorhost/fedora-epel/5/x86_64/./",
>>            target => "/pkg/epel-5.x86_64",
>>            rsyncflags => ['--exclude', 'repoview', '--exclude', 'debug'],
>>            creates => "/pkg/epel-5.x86_64/repodata/repomd.xml",
>>            hour => 3, minute => 25;
>>    }
>>
>> This does two things: when run the first time, it actually does
>> an rsync of a directory tree.  And then it creates a cron job
>> for keeping the tree synchronized with the source.  You use the
>> 'creates' parameter to indicate a file that you expect to exist
>> in the tree, so Puppet itself doesn't have to run rsync every
>> time.  If you mirror a large tree that could take a long time,
>> even if no files actually need to be transferred (I use it to
>> keep a mirror of CentOS and EPEL on a cluster, so we can re-install
>> our nodes anytime without being dependant on external servers).
>>
>> Is this what you want?  Any suggestions for improvements?
>
> I would prefer if puppet ran the sync. It would be nice to receive puppet
> events for any changes made via rsync (essentially reports of which files
> change, this would require that it is implemented in ruby).
>
> I can see from reading the man page that there is a --dryrun call that could
> be used to determine rather rsync should be run or not. Is this reasonable
> to run this to determine if Puppet should run? or is that too slow?
>
>>
>>        /Bellman
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@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-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

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

[Puppet Users] erb syntaxe IF OR

[smain kahlouch]

Hi all,

I would like to specify a condition, what is the wright syntax for
<% if hostname == 'some' or 'someother' then %>

Thanks again,
Grifith

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

Re: [Puppet Users] erb syntaxe IF OR

[Peter Meier]

I would like to specify a condition, what is the wright syntax for
<% if hostname == 'some' or 'someother' then %>


erb is plain ruby, so have a look at the ruby language, how the right  
syntax would be. I assume you would like to do something like:


<% if (hostname == 'some') || (hostname == 'someother') then %>

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Evan Hisey]

> 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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Evan Hisey]

>
> 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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Eric Gerlach]

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: egerl...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Nigel Kersten]

On Thu, Apr 8, 2010 at 12:15 AM, Dmitry V'yal  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-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File Size

[Patrick]

On Apr 8, 2010, at 2:15 AM, Thomas Bellman wrote:

> Trevor Vaughan wrote:
> 
>> Mainly sugar around the call with the ability to twiddle all of the
>> useful rsync flags in a platform-agnostic manner where possible.
>> That would be truly awesome.
> 
> I have such a define in my module "nsc-puppet-utils" (available at
> http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git).  You use it
> like this:
> 
>rsync_mirror {
>epel-5-x86_64:
>source => "rsync://mirrorhost/fedora-epel/5/x86_64/./",
>target => "/pkg/epel-5.x86_64",
>rsyncflags => ['--exclude', 'repoview', '--exclude', 'debug'],
>creates => "/pkg/epel-5.x86_64/repodata/repomd.xml",
>hour => 3, minute => 25;
>}
> 
> This does two things: when run the first time, it actually does
> an rsync of a directory tree.  And then it creates a cron job
> for keeping the tree synchronized with the source.  You use the
> 'creates' parameter to indicate a file that you expect to exist
> in the tree, so Puppet itself doesn't have to run rsync every
> time.  If you mirror a large tree that could take a long time,
> even if no files actually need to be transferred (I use it to
> keep a mirror of CentOS and EPEL on a cluster, so we can re-install
> our nodes anytime without being dependant on external servers).
> 
> Is this what you want?  Any suggestions for improvements?
> 

It sounds like we have very different ideas how this should work.
For me, an ideal module would use the the schedule argument, and not have 
anything to do with cron.


I wouldn't use use any of these tags, but here are more ideas while you are 
asking:
require
depends
subscribe
notify
onlyif
unless
refreshonly

-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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] is puppet the right tool for me?

[Patrick]

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] erb syntaxe IF OR

[smain kahlouch]

2010/4/8 Peter Meier 

> I would like to specify a condition, what is the wright syntax for
>> <% if hostname == 'some' or 'someother' then %>
>>
>
> erb is plain ruby, so have a look at the ruby language, how the right
> syntax would be. I assume you would like to do something like:
>
> <% if (hostname == 'some') || (hostname == 'someother') then %>
>
> 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-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
Thanks it works perfectly, i'll take a look to the ruby language.

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

Re: [Puppet Users] File Size

[Thomas Bellman]

Dan Bode wrote:

I would prefer if puppet ran the sync. It would be nice to receive 
puppet events for any changes made via rsync (essentially reports of 
which files change, this would require that it is implemented in ruby).


I can see from reading the man page that there is a --dryrun call that 
could be used to determine rather rsync should be run or not. Is this 
reasonable to run this to determine if Puppet should run? or is that too 
slow?


Problem is, once you get file trees that have several tens of thousands
of files in them, just traversing the tree to see which files are there
and ought to be transfered can take a while.  When the target tree is
already up to date, rsync --dry-run doesn't go any faster than without
--dry-run.

The time taken doesn't matter much when Puppet is doing its automatic,
unattended runs, but when you have made a change to your manifests and
want to make a manual test run from an interactive shell, you don't want
to wait an extra ten or fifty seconds just to see that you misspelled a
package name...


/Bellman

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

Re: [Puppet Users] File Size

[Paul Lathrop]

On Thu, Apr 8, 2010 at 10:45 AM, Thomas Bellman  wrote:
> Dan Bode wrote:
>
>> I would prefer if puppet ran the sync. It would be nice to receive puppet
>> events for any changes made via rsync (essentially reports of which files
>> change, this would require that it is implemented in ruby).
>>
>> I can see from reading the man page that there is a --dryrun call that
>> could be used to determine rather rsync should be run or not. Is this
>> reasonable to run this to determine if Puppet should run? or is that too
>> slow?
>
> Problem is, once you get file trees that have several tens of thousands
> of files in them, just traversing the tree to see which files are there
> and ought to be transfered can take a while.  When the target tree is
> already up to date, rsync --dry-run doesn't go any faster than without
> --dry-run.
>
> The time taken doesn't matter much when Puppet is doing its automatic,
> unattended runs, but when you have made a change to your manifests and
> want to make a manual test run from an interactive shell, you don't want
> to wait an extra ten or fifty seconds just to see that you misspelled a
> package name...

True, but this is one place where --tags really shines. Our manifest
have reached the level of complexity where we *need* to use --tags for
iterative debugging.

--Paul

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

Re: [Puppet Users] File Size

[Nigel Kersten]

On Thu, Apr 8, 2010 at 10:50 AM, Paul Lathrop wrote:

> On Thu, Apr 8, 2010 at 10:45 AM, Thomas Bellman 
> wrote:
> > Dan Bode wrote:
> >
> >> I would prefer if puppet ran the sync. It would be nice to receive
> puppet
> >> events for any changes made via rsync (essentially reports of which
> files
> >> change, this would require that it is implemented in ruby).
> >>
> >> I can see from reading the man page that there is a --dryrun call that
> >> could be used to determine rather rsync should be run or not. Is this
> >> reasonable to run this to determine if Puppet should run? or is that too
> >> slow?
> >
> > Problem is, once you get file trees that have several tens of thousands
> > of files in them, just traversing the tree to see which files are there
> > and ought to be transfered can take a while.  When the target tree is
> > already up to date, rsync --dry-run doesn't go any faster than without
> > --dry-run.
> >
> > The time taken doesn't matter much when Puppet is doing its automatic,
> > unattended runs, but when you have made a change to your manifests and
> > want to make a manual test run from an interactive shell, you don't want
> > to wait an extra ten or fifty seconds just to see that you misspelled a
> > package name...
>
> True, but this is one place where --tags really shines. Our manifest
> have reached the level of complexity where we *need* to use --tags for
> iterative debugging.
>

So I rarely use tags for iterative debugging, simply because I dislike the
behavior when Resource A is tagged "foo" and requires Resource B which is
not tagged "foo"

I'd use them a lot more if we could have an optional flag for automatically
pulling in requires that aren't tagged with the specified tag.

I guess I should feature request that.

Anyhow, for iterative debugging I instead have development servers set up
that allow easy patching of a pending changelist into their config, and this
can include switching off large chunks of the config.




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

Re: [Puppet Users] File Size

[Thomas Bellman]

Patrick wrote:


On Apr 8, 2010, at 2:15 AM, Thomas Bellman wrote:



This does two things: when run the first time, it actually does
an rsync of a directory tree.  And then it creates a cron job
for keeping the tree synchronized with the source.  You use the
'creates' parameter to indicate a file that you expect to exist
in the tree, so Puppet itself doesn't have to run rsync every
time.  If you mirror a large tree that could take a long time,
even if no files actually need to be transferred (I use it to
keep a mirror of CentOS and EPEL on a cluster, so we can re-install
our nodes anytime without being dependant on external servers).



It sounds like we have very different ideas how this should work.
For me, an ideal module would use the the schedule argument, and
not have anything to do with cron.


Luckily, what I have implemented actually supports that mode of
operation as well. :-)  Just don't specify the 'hour' and 'minute'
parameters, and don't use the 'creates' parameter.

Using the schedule metaparameter might not be what you really want.
If you do something like:

rsync_mirror {
mymirror: ..., schedule => nightly;
}

sometype {
foo: ..., require => Rsync_mirror[mymirror];
}

where Sometype[foo] needs some files from the rsync, if you run
your manifests on a fresh machine, and it isn't in the middle of
the night, then Sometype[foo] will fail.



I wouldn't use use any of these tags, but here are more ideas while
you are asking:

require
depends
subscribe
notify
onlyif
unless
refreshonly


Luke implemented 'require' and 'subscribe' for me long before I
started using Puppet, so I got that for free...  But 'subscribe'
probably doesn't make much sense without 'refreshonly'; should
be easy to implement, so I might do that.  I don't think it is
something I would use, though.

I suppose you would want 'notify' to send a notification when there
has been some files actually changed by the rsync.  That would only
make sense when you don't use cron to offload the work from Puppet.
But I don't think that can be done from a define with exec, so it
would need to be implemented in Ruby.  If someone can come up with
a good use case I'll think about it.

'Onlyif' and 'unless' is already implemented.

I don't know what 'depends' would do.  Explanation?


/Bellman

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

[Puppet Users] Puppet commands giving nothing but a stack trace

[Rob McBroom]

I suspect this has more to do with Ruby than Puppet, but I know little about 
Ruby and Google has failed me, so I'm asking here.

I'm finally getting some of our older systems brought into Puppet. I installed 
it on several this morning without incident, but there are two (more or less 
identical RHEL 5.3 systems) that throw horrible errors. These systems did not 
have Puppet or Ruby installed prior to today.

# puppet --version
/usr/lib/ruby/1.8/sync.rb:214:in `sync_unlock': stack level too deep 
(SystemStackError)
from /usr/lib/ruby/1.8/sync.rb:231:in `synchronize'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:290:in `name'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:288:in `each'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:288:in `name'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:825:in 
`each_source'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:823:in `each'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:823:in 
`each_source'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:667:in 
`uninterpolated_value'
 ... 10 levels...
from /usr/lib/ruby/site_ruby/1.8/puppet/application/puppet.rb:1:in 
`require'
from /usr/lib/ruby/site_ruby/1.8/puppet/application/puppet.rb:1
from /usr/bin/puppet:70:in `require'
from /usr/bin/puppet:70

It seems that `facter` also poops its pants:

  # facter
  Could not retrieve kernel: stack level too deep
  /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:31:in `exec': stack 
level too deep (SystemStackError)
from /usr/lib/ruby/site_ruby/1.8/facter/kernel.rb:6
from /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:118:in `call'
from /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:118:in 
`value'
from /usr/lib/ruby/1.8/timeout.rb:48:in `timeout'
from /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:116:in 
`value'
from /usr/lib/ruby/site_ruby/1.8/facter/util/fact.rb:75:in `value'
from /usr/lib/ruby/site_ruby/1.8/facter/util/loader.rb:73:in `inject'
from /usr/lib/ruby/site_ruby/1.8/facter/util/fact.rb:71:in `each'
 ... 16 levels...
from /usr/lib/ruby/site_ruby/1.8/facter/util/loader.rb:30:in `load_all'
from /usr/lib/ruby/site_ruby/1.8/facter/util/collection.rb:90:in 
`load_all'
from /usr/lib/ruby/site_ruby/1.8/facter.rb:91:in `to_hash'
from /usr/bin/facter:138

Ruby itself seems to run:

# ruby --version
ruby 1.8.5 (2006-08-25) [x86_64-linux]

But that's not much of a challenge and I don't know how to do anything more 
complicated. Perhaps there's some boring Ruby one-liner I could try to see if 
it's working?

-- 
Rob McBroom


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

[Puppet Users] Re: Puppet commands giving nothing but a stack trace

[Ken]

I don't suppose its your stack size? Whats the output of 'ulimit -a'
on your box (as the user you were trying to run those command as of
course). Mine is 8192 kb.

Can you try it with a later version of Ruby from RHEL 5.4?

On Apr 8, 9:50 pm, Rob McBroom  wrote:
> I suspect this has more to do with Ruby than Puppet, but I know little about 
> Ruby and Google has failed me, so I'm asking here.
>
> I'm finally getting some of our older systems brought into Puppet. I 
> installed it on several this morning without incident, but there are two 
> (more or less identical RHEL 5.3 systems) that throw horrible errors. These 
> systems did not have Puppet or Ruby installed prior to today.
>
>     # puppet --version
>     /usr/lib/ruby/1.8/sync.rb:214:in `sync_unlock': stack level too deep 
> (SystemStackError)
>         from /usr/lib/ruby/1.8/sync.rb:231:in `synchronize'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:290:in `name'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:288:in `each'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:288:in `name'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:825:in 
> `each_source'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:823:in `each'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:823:in 
> `each_source'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/util/settings.rb:667:in 
> `uninterpolated_value'
>          ... 10 levels...
>         from /usr/lib/ruby/site_ruby/1.8/puppet/application/puppet.rb:1:in 
> `require'
>         from /usr/lib/ruby/site_ruby/1.8/puppet/application/puppet.rb:1
>         from /usr/bin/puppet:70:in `require'
>         from /usr/bin/puppet:70
>
> It seems that `facter` also poops its pants:
>
>       # facter
>       Could not retrieve kernel: stack level too deep
>       /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:31:in `exec': 
> stack level too deep (SystemStackError)
>         from /usr/lib/ruby/site_ruby/1.8/facter/kernel.rb:6
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:118:in 
> `call'
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:118:in 
> `value'
>         from /usr/lib/ruby/1.8/timeout.rb:48:in `timeout'
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/resolution.rb:116:in 
> `value'
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/fact.rb:75:in `value'
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/loader.rb:73:in `inject'
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/fact.rb:71:in `each'
>          ... 16 levels...
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/loader.rb:30:in 
> `load_all'
>         from /usr/lib/ruby/site_ruby/1.8/facter/util/collection.rb:90:in 
> `load_all'
>         from /usr/lib/ruby/site_ruby/1.8/facter.rb:91:in `to_hash'
>         from /usr/bin/facter:138
>
> Ruby itself seems to run:
>
>     # ruby --version
>     ruby 1.8.5 (2006-08-25) [x86_64-linux]
>
> But that's not much of a challenge and I don't know how to do anything more 
> complicated. Perhaps there's some boring Ruby one-liner I could try to see if 
> it's working?
>
> --
> Rob McBroom
> 
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] dependencies

[Christopher Johnston]

What is the best way to map out all my depencies (is there a way to chart
them somehow?)  I am finding no matter how many places I put notifies,
requires, etc.  I still end up having to two 2-3 runs of puppet.  Very
frustrating.

On Thu, Mar 18, 2010 at 11:57 AM, Nigel Kersten  wrote:

> On Thu, Mar 18, 2010 at 8:49 AM, Christopher Johnston
>  wrote:
> > Yup the yum manifest sets up my configuration files for the various repos
> > (ie, we have a development repos for our lab that only goes on lab
> systems
> > and production hosts the production repo).
> >
> > Package { require => Class["yum::base"] }
> >
> > I guess I could put that in every manifest at the top that is doing
> package
> > installs.  Is there one place I could put this so it applies to ALL
> modules,
> > perhaps site.pp?
>
> Yep. Either put it in site.pp (although you may want to match
> $operatingsystem or something) or some parent class that includes your
> other classes.
>
> Our site.pp looks like:
>
> node default { include base }
>
> and our base module/class includes all the other ones, so we set it in
> modules/base/manifests/init.pp
>
> (actually we set it in class base::debian and base::mac and
> base::solaris for our different platforms)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] dependencies

[James Turnbull]

On 9 April 2010 08:35, Christopher Johnston  wrote:
> What is the best way to map out all my depencies (is there a way to chart
> them somehow?)  I am finding no matter how many places I put notifies,
> requires, etc.  I still end up having to two 2-3 runs of puppet.  Very
> frustrating.
>

>From the FAQ (which is a little in flux at the moment):

How do I use Puppet’s graphing support?

Puppet has graphing support capable of creating graph files of your
Puppet client configurations. The graphs are created by and on the
client, so you must enable the graph option. This will create files in
dot format in the client’s graphdir directory; these files are text
files and need to be interpreted by another application to get turned
into images. The easiest way to do this is to use OmniGraffle, since
it automatically converts them to attractive graphs, but it only runs
on OS X. You can also install graphviz, which comes with the dot
application, which you can use to turn the text files into images:

dot -Tpng /var/puppet/state/graphs/resources.dot -o /tmp/configuration.png

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Strange order dependency

[Jesús M. Navarro]

Hi, list:

I'm a rookie on his first tests with Puppet and I found something that it's 
probably obvious but that still don't understand.

I have some modules that manage some files under /etc/ 
(say, /etc/resolv.conf, /etc/ntp.conf, etc.) and then, since I "inherited" 
quite a lot of files managed by hand under Subversion, a lot of files that go 
directly under the "private" resource in order to be moved 'as is' from the 
puppetmaster to its clients.

The thing is that if I have a client that calls any module that "touches" any 
file under /etc, the "private" resource seems to go unnoticed unless I first 
run the puppetd client without any module so the client "notices" the files 
under "private".  Once the client "sees" once the "private" section 
everything goes OK from there on.

An example: let's say I have a "node" definition like this:
node "somehost.example.com" inherits myCompanyBasic {
file { "/etc":
recurse => "true",
source  => "puppet:///private/etc";
}
}

...where "private" is defined within fileserver.conf as...
[private]
path /etc/puppet/private/%d/%h

..and there exists within the puppetmaster a file like:
/etc/puppet/private/example.com/somehost/etc/foo/bar

...and myCompanyBasic is defined like this:
node myCompanyBasic {
# NTP client
include ntp::client
}

All that ntp::client does is this (the parent ntp class is just a "noop" by 
now):
class client inherits ntp {
File["/etc/ntp.conf"] {
source => "puppet:///ntp/ntp-client.conf",
}
}

The file "ntp-client.conf" is properly sent to the client as /etc/ntp.conf but 
neither /etc/foo/bar is sent to the client nor the logs show nothing (even 
when running as puppetd --no-daemonize --debug).

I can tell that /etc/puppet/example.com/somehost/etc is somehow managed since 
if I delete it on the server I'll get a client-side error:
(//Node[somehost.example.com]/File[/etc]) Failed to retrieve current state of 
resource: No specified source was found from puppet:///private/etc
...although if /etc/puppet/example.com/somehost/etc exists on the server no 
file within it will be sent to the client.

Now, if I change my host definition *not* to depend on the global class, like 
this (see there's no "inherits myCompanyBasic" here):
node "somehost.example.com" {
file { "/etc":
recurse => "true",
source  => "puppet:///private/etc";
}
}

Then /etc/puppet/example.com/somehost/etc/foo/bar is properly sent to the 
client as /etc/foo/bar and if I make a change 
to /etc/puppet/example.com/somehost/etc/foo/bar on puppetmaster it will be 
properly managed *even* if I return afterwards to the original definition for 
somehost.example.com inheriting myCompanyBasic and I restart both 
puppetmaster and puppetd: it will then and afterwards properly manage *both* 
the files (and templates) managed by modules and those from the "private" 
resource.

Is this a known bug, something I misunderstood or what?

I'm using puppet 0.24.5 from Debian Stable ("Lenny") both on server and 
client.

TIA.

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

Re: [Puppet Users] File Size

[Trevor Vaughan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hmm...perhaps both modes could be supported.

Have one way to schedule and another to run inline.

That would be quite useful.

Trevor

On 04/08/2010 01:45 PM, Thomas Bellman wrote:
> Dan Bode wrote:
> 
>> I would prefer if puppet ran the sync. It would be nice to receive
>> puppet events for any changes made via rsync (essentially reports of
>> which files change, this would require that it is implemented in ruby).
>>
>> I can see from reading the man page that there is a --dryrun call that
>> could be used to determine rather rsync should be run or not. Is this
>> reasonable to run this to determine if Puppet should run? or is that
>> too slow?
> 
> Problem is, once you get file trees that have several tens of thousands
> of files in them, just traversing the tree to see which files are there
> and ought to be transfered can take a while.  When the target tree is
> already up to date, rsync --dry-run doesn't go any faster than without
> --dry-run.
> 
> The time taken doesn't matter much when Puppet is doing its automatic,
> unattended runs, but when you have made a change to your manifests and
> want to make a manual test run from an interactive shell, you don't want
> to wait an extra ten or fifty seconds just to see that you misspelled a
> package name...
> 
> 
> /Bellman
> 

- -- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaug...@onyxpoint.com
 phone: 410-541-ONYX (6699)
 pgp: 0x6C701E94

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

iEYEARECAAYFAku+dQMACgkQyWMIJmxwHpRULQCeMWxZcFB2/EwM+m+LxLGwULSl
LVkAoLTU8x1F9YNKf+bz6uS0BgOWhCGx
=RB47
-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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

<>

Re: [Puppet Users] is puppet the right tool for me?

[Daniel Pittman]

Patrick  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✉ dan...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Possible options to transfer information from nodes to master?

[Daniel Pittman]

Tore  writes:

> Thanks again for the answers. I've haven't got to much time to play with
> puppet, but I always seems to forget that puppet compiles the code at the
> master, and sends this code to the nodes. The only thing that is transferred
> from the nodes regarding information, is facter information. Hence the
> variable ($ifconfig = generate("/usr/sbin/ ifconfig", "eth0") will be equal
> on all nodes when they get the compiled configuration.

Yes, it would, because it would run ifconfig on master on each node.

> The only simple way I can think of is creating a manifest which uses curl to
> POST a file to a HTTP server (or some other protocol). It can be quite time
> consuming to compare 30 httpd.conf just to verify that they are equal (they
> should be, but you never know without checking it) before managing them with
> puppet.

*nod*

For what it is worth, I would suggest that you set up a suite of ad-hoc change
tools to work alongside puppet (or, in fact, alongside any tool that works
like puppet.)

For those ad-hoc tools the ability to run a shell command, as an arbitrary
user, and to transfer files to and from the systems is invaluable.

It is also ideal if you can easily say "only these systems" to the tool.


Then you can use that to drag down the httpd.conf on all the machines, or
sha1sum them and find what is identical, or...


You don't want to use ad-hoc change tools often, but when you need them they
are invaluable.  This is *especially* true when you have a one-shot job like
"compare these files before we take 'em over" to do.

Daniel

-- 
✣ Daniel Pittman✉ dan...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Strange order dependency

[chakkerz]

I think i had a similar problem some time ago. The best way around it
(whoa that's a loaded statement : ) ) is to:

Move your recursive etc pushout into a module, and tell anything that
also wants to write into /etc to do so with a
require => File["/etc"],

That way your /etc/ from your preferred source is there, and
subsequent files can write into it.

Now ... i don't recall if the recursive replace removes everything
first, but i think it does, which really isn't what you want.
The way i worked around that (best way version 2.0) i found was to use
a tarball that injects the contents into the directory you want, for
example i deploy private keys into home directories as follows:

define homedir_deployment($filename)
{
file
{ "/tmp/$filename":
owner   => root,
group   => root,
mode=> 600,
replace => true,
source  => "puppet:///shared-home_directories/
$filename",
before  => Exec["extract_$filename"],
}

exec
{ "extract_$filename":
command => "${variables::tar_cmd} xzpf /tmp/
$filename",
cwd => "/",
before  => Exec["remove_$filename"],
}

exec
{ "remove_$filename":
command => "${variables::rm_cmd} -f /tmp/$filename",
cwd => "/",
}
}

So it transfers to /tmp/tarball; then extracts tarball (which is tared
so it extracts /home); and then it removes the temp file.
The same can work for your /etc directory, and that way when you
deploy your ntp configuration whenever you want.

Hope that helps
chakkerz




On Apr 9, 9:44 am, "Jesús M. Navarro" 
wrote:
> Hi, list:
>
> I'm a rookie on his first tests with Puppet and I found something that it's
> probably obvious but that still don't understand.
>
> I have some modules that manage some files under /etc/
> (say, /etc/resolv.conf, /etc/ntp.conf, etc.) and then, since I "inherited"
> quite a lot of files managed by hand under Subversion, a lot of files that go
> directly under the "private" resource in order to be moved 'as is' from the
> puppetmaster to its clients.
>
> The thing is that if I have a client that calls any module that "touches" any
> file under /etc, the "private" resource seems to go unnoticed unless I first
> run the puppetd client without any module so the client "notices" the files
> under "private".  Once the client "sees" once the "private" section
> everything goes OK from there on.
>
> An example: let's say I have a "node" definition like this:
> node "somehost.example.com" inherits myCompanyBasic {
>         file { "/etc":
>                 recurse => "true",
>                 source  => "puppet:///private/etc";
>         }
>
> }
>
> ...where "private" is defined within fileserver.conf as...
> [private]
> path /etc/puppet/private/%d/%h
>
> ..and there exists within the puppetmaster a file like:
> /etc/puppet/private/example.com/somehost/etc/foo/bar
>
> ...and myCompanyBasic is defined like this:
> node myCompanyBasic {
> # NTP client
>         include ntp::client
>
> }
>
> All that ntp::client does is this (the parent ntp class is just a "noop" by
> now):
>         class client inherits ntp {
>                 File["/etc/ntp.conf"] {
>                         source => "puppet:///ntp/ntp-client.conf",
>                 }
>         }
>
> The file "ntp-client.conf" is properly sent to the client as /etc/ntp.conf but
> neither /etc/foo/bar is sent to the client nor the logs show nothing (even
> when running as puppetd --no-daemonize --debug).
>
> I can tell that /etc/puppet/example.com/somehost/etc is somehow managed since
> if I delete it on the server I'll get a client-side error:
> (//Node[somehost.example.com]/File[/etc]) Failed to retrieve current state of
> resource: No specified source was found from puppet:///private/etc
> ...although if /etc/puppet/example.com/somehost/etc exists on the server no
> file within it will be sent to the client.
>
> Now, if I change my host definition *not* to depend on the global class, like
> this (see there's no "inherits myCompanyBasic" here):
> node "somehost.example.com" {
>         file { "/etc":
>                 recurse => "true",
>                 source  => "puppet:///private/etc";
>         }
>
> }
>
> Then /etc/puppet/example.com/somehost/etc/foo/bar is properly sent to the
> client as /etc/foo/bar and if I make a change
> to /etc/puppet/example.com/somehost/etc/foo/bar on puppetmaster it will be
> properly managed *even* if I return afterwards to the original definition for
> somehost.example.com inheriting myCompanyBasic and I restart both
> puppetmaster and puppetd: it will then and afterwards properly manage *both*
> the files (and templates) managed by modules and those from the "private"
> resource.
>
> Is this a known bug, something I misunderstood or what?
>
> I'm using puppet 0.24.5 from Debian Stable ("Lenny") both on server and
> 

Re: [Puppet Users] is puppet the right tool for me?

[Ohad Levy]

On Fri, Apr 9, 2010 at 12:32 AM, Patrick  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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] excluding modules from filebucketing

[chakkerz]

G'day all

I've got the following two lines in my site.pp:

# Define the bucket
filebucket { main: server => puppet }

# Specify it as the default target
File { backup => main }

Which I added based on something in the best practices page. Thing is,
I've got a couple of servers that are getting larger files (quite
large actually) and they are constantly changing and i really don't
care about the files being different, causing their clientbucket
directory to get largish.

Is there a way to exclude the modules where i don't care about
changes, short of nuking the current destination file before i
transfer the new copy (i figure that might do the trick, haven't
checked though).

Cheers
chakkerz

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

Re: [Puppet Users] Re: Strange order dependency

[Patrick]

On Apr 8, 2010, at 11:03 PM, chakkerz wrote:

> I think i had a similar problem some time ago. The best way around it
> (whoa that's a loaded statement : ) ) is to:
> 
> Move your recursive etc pushout into a module, and tell anything that
> also wants to write into /etc to do so with a
> require => File["/etc"],
> 
> That way your /etc/ from your preferred source is there, and
> subsequent files can write into it.
> 
> Now ... i don't recall if the recursive replace removes everything
> first, but i think it does, which really isn't what you want.

Only if you set purge => true
-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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] excluding modules from filebucketing

[Patrick]

On Apr 8, 2010, at 11:11 PM, chakkerz wrote:

> G'day all
> 
> I've got the following two lines in my site.pp:
> 
> # Define the bucket
>filebucket { main: server => puppet }
> 
> # Specify it as the default target
>File { backup => main }
> 
> Which I added based on something in the best practices page. Thing is,
> I've got a couple of servers that are getting larger files (quite
> large actually) and they are constantly changing and i really don't
> care about the files being different, causing their clientbucket
> directory to get largish.
> 
> Is there a way to exclude the modules where i don't care about
> changes, short of nuking the current destination file before i
> transfer the new copy (i figure that might do the trick, haven't
> checked though).

This probably isn't exactly what you want, but you can always set the value of 
"backup" for individual files.  Just set it to "false" for the individual 
files.  

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

[Puppet Users] Re: excluding modules from filebucketing

[chakkerz]

No, that is exactly what i wanted :)

Thanks for that!
Christian

On Apr 9, 4:32 pm, Patrick  wrote:
> On Apr 8, 2010, at 11:11 PM, chakkerz wrote:
>
>
>
> > G'day all
>
> > I've got the following two lines in my site.pp:
>
> > # Define the bucket
> >        filebucket { main: server => puppet }
>
> > # Specify it as the default target
> >        File { backup => main }
>
> > Which I added based on something in the best practices page. Thing is,
> > I've got a couple of servers that are getting larger files (quite
> > large actually) and they are constantly changing and i really don't
> > care about the files being different, causing their clientbucket
> > directory to get largish.
>
> > Is there a way to exclude the modules where i don't care about
> > changes, short of nuking the current destination file before i
> > transfer the new copy (i figure that might do the trick, haven't
> > checked though).
>
> This probably isn't exactly what you want, but you can always set the value 
> of "backup" for individual files.  Just set it to "false" for the individual 
> files.  

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