Hi,
I''m thinking about
Package {
ensure => "latest",
}
in my site.pp. However I''d like to be in control on when puppet
actually updates packages. One option I see would be to mirror the
package repository from my upstream distro (just managing debian at
the moment but I guess RH and others also have an option of mirroring
yum and then just update after testing the packages).
So I could use reprepro to mirror the stable tree of debian make that
my internal_testing and just propagate to internal_stable when I''m
done with testing. Since that uses quite some storage I''d rather like
to have some option of still using >>ensure =>
"latest",<< but only on
triggered runs (puppetrun is configured).
Any options you see besides mirroring upstream packages and doing
internal propagation from testing to what I consider stable?
thanks
martin
--
http://www.xing.com/profile/Martin_Marcher
http://marcher.it
You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
hello,> Hi Martin, we''re trying to achieve exactly the same thing here (see > previous posts in the last couple of weeks from me) and the answer > appears to be "maintain your own repo that has all the packages that > you want to install, then use ''ensure => latest''". > > I''m looking into writing my own plugin/module for puppet that will > allow fine-grained control over the package management however as I''m > only just learning ruby, it could take a while! :o)As an exercise in learning ruby and puppet I wrote a simple lookup method using CSV files after someone on IRC suggested something, the basic idea is: package{"zsh": ensure => hostlookup($name, "present") } this will lookup against a CSV file values for the host this gets executed against: your.box.com,zsh,latest or you.box.com,zsh,1.0 if nothing is present in the file, it simply returns "present" meaning it will install whats available but not do anything automagically when updating. This should give you the flexibility to at least manage updates going out a bit closer, you can keep current repos but decide when to push out a specific version to all your machines. I don''t use this in my environment - as I said I was more after learning how to write parser functions - but the code might at least give you a place to start from, shout if this sounds like something you might find useful and I can put the code up somewhere. -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Am 29.07.2008 um 10:56 schrieb Martin:> I''m thinking about > > Package { > ensure => "latest", > } > > in my site.pp. However I''d like to be in control on when puppet > actually updates packages. One option I see would be to mirror the > package repository from my upstream distro (just managing debian at > the moment but I guess RH and others also have an option of mirroring > yum and then just update after testing the packages). > > So I could use reprepro to mirror the stable tree of debian make that > my internal_testing and just propagate to internal_stable when I''m > done with testing. Since that uses quite some storage I''d rather like > to have some option of still using >>ensure => "latest",<< but only on > triggered runs (puppetrun is configured). > > Any options you see besides mirroring upstream packages and doing > internal propagation from testing to what I consider stable?Wouldn''t that be possible with tags? Say you have: package { "somesoft": ensure => "present", tag => "production"; "somesoft": ensure => "latest", tag => "update-somesoft"; } I haven''t tested it and am aware that puppet would complain about somesoft being managed twice, so you''d need to tweak it with some ''name =>'' stuff. Second caveat: you can''t define that with a ''Package {}" in the site.pp, a define might work though. BR, Felix Schäfer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
This may not be exactly what you''re trying to accomplish, but it might
spark some ideas.
We''re a Debian shop, and we do have an internal mirror that most
machines pull from, but we still have machines that pull directly from
the net, as I believe you desire.
To manage this, I''ve setup weekly cron jobs (via puppet of course) that
first updates the package list then does a dry run upgrade. The output
is then emailed to me so I can decide when I might want to actually
perform the upgrade.
To perform the upgrade, the unattendedupgrade package has been installed
and is run when the appropriate file (manged via puppet) is touched on
the puppetmaster. The class file follows.
Hope this helps.
- Jeff
class unattendedupgrade {
file { "/etc/update_initiator":
backup => false,
source => $hardwarenode_name ? {
openvz01 =>
"puppet:///unattendedupgrade/update_initiator.openvz01",
openvz02 =>
"puppet:///unattendedupgrade/update_initiator.openvz02",
default =>
"puppet:///unattendedupgrade/update_initiator.default",
}
}
exec { unattendedupgrade_default:
command => "aptitude -q=2 -y update &&
/usr/bin/unattended-upgrade &&
/usr/local/bin/apt_upgrade_status.sh",
logoutput => false,
refreshonly => true,
subscribe => File["/etc/update_initiator"],
require => Package["unattended-upgrades"],
}
package { "unattended-upgrades":
provider => aptitude,
ensure => present,
}
}
Martin wrote:> Hi,
>
> I''m thinking about
>
> Package {
> ensure => "latest",
> }
>
> in my site.pp. However I''d like to be in control on when puppet
> actually updates packages. One option I see would be to mirror the
> package repository from my upstream distro (just managing debian at
> the moment but I guess RH and others also have an option of mirroring
> yum and then just update after testing the packages).
>
> So I could use reprepro to mirror the stable tree of debian make that
> my internal_testing and just propagate to internal_stable when I''m
> done with testing. Since that uses quite some storage I''d rather
like
> to have some option of still using >>ensure =>
"latest",<< but only on
> triggered runs (puppetrun is configured).
>
> Any options you see besides mirroring upstream packages and doing
> internal propagation from testing to what I consider stable?
>
> thanks
> martin
>
--~--~---------~--~----~------------~-------~--~----~
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/29 Martin <martin@marcher.name>:> > Hi, > > I''m thinking about > > Package { > ensure => "latest", > } >So one problem I see with this is that you will only be updating the packages that are directly included in your manifests and those they depend on. You might end up getting a false sense that your system is running the current software when infact there are some stray packages that haven''t been updated. I think a better approach is to control your own repository and just do system wide updates when it is appropiate to. .r'' --~--~---------~--~----~------------~-------~--~----~ 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 Tue, Jul 29, 2008 at 10:55 AM, RijilV <rijilv@gmail.com> wrote:> > 2008/7/29 Martin <martin@marcher.name>: >> >> Hi, >> >> I''m thinking about >> >> Package { >> ensure => "latest", >> } >> > > So one problem I see with this is that you will only be updating the > packages that are directly included in your manifests and those they > depend on. You might end up getting a false sense that your system is > running the current software when infact there are some stray packages > that haven''t been updated. > > I think a better approach is to control your own repository and just > do system wide updates when it is appropiate to. > > .r''I tend to agree with this approach. It is basically the right tool for the right job thinking. Puppet is awesome at making sure your network and server infrastructure is setup and in place like you want it. It is not so hot on things that do rapid dynamic changes nor should it really be. Likewise puppet is a terrible backup/restore solution by itself, but is an excellent part of the toolset you need to have, to be able to quickly over haul or restore parts of your infrastructure. I use puppet to maintain my repos and tell the server/clients where to find the repos and to tell the distro supplied tools how often and when to do the updates. this has the add bonus of letting me use the distro built systems for things like pinning, or excluscions. 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 -~----------~----~----~----~------~----~------~--~---