Puppet users - Jul 2008 - Package Management on multiple Debian Systems

Hi All,

I''m relatively new to Puppet, so please be gentle... :oP

I''ve looked back through the archives and read some of the recipes
however I am unable to work out exactly what I need to do to resolve
an issue I am having with setting up Puppet.

The main reason I am using puppet is to maintain system updates within
Debian using Aptitude.

What I want to achieve is this:

1) Testing and Development servers are updated to the latest packages
automatically (it''s what they are there for!)

2) In-House servers are updated a week after the Testing and
Development servers by which point any issues should have been noted
with the upgrades.

3) Servers that are on Customer sites are upgraded _only_ when we
request it and not before

Is there a simple way of creating this kind of scenario, or am I
approaching this from the wrong direction?! :o)

Thanks in advance,

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

2008/7/18 Matthew Macdonald-Wallace
<lists@truthisfreedom.org.uk>:
>
> 1) Testing and Development servers are updated to the latest packages
> automatically (it''s what they are there for!)
>
> 2) In-House servers are updated a week after the Testing and
> Development servers by which point any issues should have been noted
> with the upgrades.
>
> 3) Servers that are on Customer sites are upgraded _only_ when we
> request it and not before
Maintain three repositories.  It''s not the cleanest method, but it
guarantees that only packages in the repo can ever be deployed to a
machine.

For 2, using a separate repository means you have to migrate the
packages over by hand.  This ensures that if you find a problem on day
7, the In-House servers don''t automatically upgrade on the 7th day
(and I''m not sure how to express the time delay in Puppet anyway).

For 3, use version pinning in the recipes/classes (ensure =>
"1.3-4").
 They can use any repository set, but unless the manifest changes, no
upgrade should happen.  What -can- happen is if you pin a package, and
then run a generic <packagemanager> update, the manager is unaware of
the pinning, does a mass upgrade, then gets told by puppet to
downgrade various packages.  Moral of the story - don''t use
upgrade-dist or equivalent if using pinning in recipes.

--~--~---------~--~----~------------~-------~--~----~
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, Jul 18, 2008 at 6:50 AM, Matthew Macdonald-Wallace
<lists@truthisfreedom.org.uk> wrote:
>
> Hi All,
>
> I''m relatively new to Puppet, so please be gentle... :oP
>
> I''ve looked back through the archives and read some of the recipes
> however I am unable to work out exactly what I need to do to resolve
> an issue I am having with setting up Puppet.
>
> The main reason I am using puppet is to maintain system updates within
> Debian using Aptitude.
>
> What I want to achieve is this:
>
> 1) Testing and Development servers are updated to the latest packages
> automatically (it''s what they are there for!)
>
> 2) In-House servers are updated a week after the Testing and
> Development servers by which point any issues should have been noted
> with the upgrades.
>
> 3) Servers that are on Customer sites are upgraded _only_ when we
> request it and not before
>
> Is there a simple way of creating this kind of scenario, or am I
> approaching this from the wrong direction?! :o)
>
> Thanks in advance,
>
This sounds more like and apt-get solveable problem than a puppet
solvable problem. For 1 you just use the auto updater that comes with
the distro, works great and not redesign needed. For 2 you use a cron
job that updates every 7th day from an approved repo that you maintain
in house (this one gets trick to do with full automation). The 3rd one
is again back to using the auto updater from the distro with a blessed
repo that only has the packages you want in it when you want them, or
a shell script that is used to run the specific updates you want.

The real PITA in this senario you have laid out is teh fact that you
are trying to run a repo with at least a a 7 day lag behind the
upstream.  You will almost have to create a rolling repo structure to
keep the 7 day lag window. This is where puppet could come in handy.
USe puupet to maintain the rolling repos and keep the In-house servers
pointed to the correct repo for the right set of updates.

Evan

--~--~---------~--~----~------------~-------~--~----~
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, Jul 18, 2008 at 01:59:34PM +0100, Duncan Hill wrote:
> For 3, use version pinning in the recipes/classes (ensure =>
"1.3-4").
>  They can use any repository set, but unless the manifest changes, no
> upgrade should happen.  What -can- happen is if you pin a package, and
> then run a generic <packagemanager> update, the manager is unaware of
> the pinning, does a mass upgrade, then gets told by puppet to
> downgrade various packages.  Moral of the story - don''t use
> upgrade-dist or equivalent if using pinning in recipes.
> 
If you use puppet to maintain pin data in /etc/apt/preferences, you
can use the dist-upgrade tools.

I favor the internal repository idea.



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

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