Puppet users - Sep 2008 - Potential new puppet user: two questions

Hello,

I am examining whether puppet meets our needs. I can''t find the answer
to two questions I am looking to answer, hopefully someone can help.

1. Can puppet be used to manage different classes of the same
computers, e.g. do something on the apache test farm, if it works then
do it on the apache live farm; and is this done cleanly?
2. How are package updates (e.g. yum update/yum uprade/aptitude
upgrade/etc) pushed/handled/done?

Thanks.

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

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

blunt wrote:
> I am examining whether puppet meets our needs. I can''t find the
answer
> to two questions I am looking to answer, hopefully someone can help.
> 
> 1. Can puppet be used to manage different classes of the same
> computers, e.g. do something on the apache test farm, if it works then
> do it on the apache live farm; and is this done cleanly?
Puppet can do this with a concept called environments.

http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
> 2. How are package updates (e.g. yum update/yum uprade/aptitude
> upgrade/etc) pushed/handled/done?
Packages are defined using the package resource type like:

package { "vim":
   ensure => latest,
}

Puppet detects the appropriate package manager for your platform and
installs the relevant package.

See http://reductivelabs.com/trac/puppet/wiki/TypeReference#package

Regards

James Turnbull

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

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

iD8DBQFIv9l29hTGvAxC30ARAjzUAKC2PwuBWupuXNr1FNDUNpZyfsutxQCeMwSZ
2v8h2DJdqvlxW7bMI+CYWGU=kTiK
-----END PGP SIGNATURE-----

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

> > 2. How are package updates (e.g. yum update/yum uprade/aptitude
> > upgrade/etc) pushed/handled/done?
>
> Packages are defined using the package resource type like:
>
> package { "vim":
>    ensure => latest,
>
> }
>
> Puppet detects the appropriate package manager for your platform and
> installs the relevant package.
So how would this work in real life?

Say all the servers have Apache 2.2.1 and an update is released to
2.2.2.
I want to test on the test servers, and if it works, push to the live
servers.

Is there a clean way of doing this, or do I have to track versions for
all software and update the puppet config version strings?

--~--~---------~--~----~------------~-------~--~----~
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, 04 Sep 2008 22:49:58 +1000
James Turnbull <james@lovedthanlost.net> wrote:
> Puppet can do this with a concept called environments.
Thank you.

You just solved a huge issue in my implementation of Puppet.  I didn''t
see this before...

M.
-- 
Matthew Macdonald-Wallace
matthew@truthisfreedom.org.uk
http://www.truthisfreedom.org.uk

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

> > 2. How are package updates (e.g. yum update/yum uprade/aptitude
> > upgrade/etc) pushed/handled/done?
>
> Packages are defined using the package resource type like:
>
> package { "vim":
>    ensure => latest,
>
> }
(hopefully this doesn''t get posted twice)

Thanks. So if an update to Apache is released, say to 2.2.2, and I
want to test this in my test environment, then update the live
environment later as well, how would I do that?

Would I have to track versions for all current software, apply it to
the test environment, test it, and then do the same for the live
environment? or is there some kind of cleaner way, or wrapper, for
doing this (maybe with templates?)

Thanks again.

--~--~---------~--~----~------------~-------~--~----~
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 9/4/2008 8:28 AM, blunt wrote:
> Say all the servers have Apache 2.2.1 and an update is released to
> 2.2.2.
> I want to test on the test servers, and if it works, push to the live
> servers.
> 
> Is there a clean way of doing this, or do I have to track versions for
> all software and update the puppet config version strings?
If test servers are defined as servers running anything other than 
well-tested packages, then I''d probably set up separate repositories
for
the testing versions and the production versions of packages, similar to 
what Debian does with stable/testing/unstable. Point the test servers to 
the testing repository, the production servers to the stable repository, 
and let them both use ensure => latest.

Then it becomes largely a matter of managing the contents of the 
repositories and adding a periodic cron job to update the list of 
available packages.

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

--~--~---------~--~----~------------~-------~--~----~
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, 04 Sep 2008 09:18:57 -0500
Mike Renfro <renfro@tntech.edu> wrote:
> If test servers are defined as servers running anything other than 
> well-tested packages, then I''d probably set up separate
repositories
> for the testing versions and the production versions of packages,
> similar to what Debian does with stable/testing/unstable. Point the
> test servers to the testing repository, the production servers to the
> stable repository, and let them both use ensure => latest.
We''re going to use apt/preferences for this.

We''ll decide on a release level for our testing servers (probably a
blank preferences file), another for our in-house servers (probably
one-less than "latest") and a third for our customers (either one or
two less than latest unless there''s a major security issue).

This means that we can use the debian.org repos instead of maintaining
our own and we can roll out specific versions of each package as we
need to in given environments.

HTH,

M.
-- 
Matthew Macdonald-Wallace
matthew@truthisfreedom.org.uk
http://www.truthisfreedom.org.uk

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

Some good tips (from everyone). Thanks :)

--~--~---------~--~----~------------~-------~--~----~
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 9/4/08, Mike Renfro <renfro@tntech.edu> wrote:
>  the testing repository, the production servers to the stable repository,
>  and let them both use ensure => latest.
I generally avoid ensure => latest. I''ve seen some very awful
breakage
occur when puppet upgrades a package (or completely fails to),
particularly on CentOS/RHEL.

Manual system administration sucks, but I have better success doing a
manual upgrade of *all* packages at one time.

-- 
Joshua Timberman

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