I''m just beginning with Puppet. One issue I''ve run into is updates. As my nodes expand, updating each individual node via my manual method becomes daunting. Could someone share their recipe or procedure for using the puppet master to distribute updates of puppet to the client nodes? I would guess using a "gem" would be easier. Updating puppet on the master node isn''t much of a problem via source, though perhaps I should consider the "gem" there as well? 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.
We just use packages:
package { "puppet": ensure => latest }
On Fri, Oct 8, 2010 at 4:15 PM, Forrie <forrie@gmail.com> wrote:
> I''m just beginning with Puppet. One issue I''ve run into
is updates.
> As my nodes expand, updating each individual node via my manual method
> becomes daunting.
>
> Could someone share their recipe or procedure for using the puppet
> master to distribute updates of puppet to the client nodes? I would
> guess using a "gem" would be easier. Updating puppet on the
master
> node isn''t much of a problem via source, though perhaps I should
> consider the "gem" there as well?
>
> 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<puppet-users%2Bunsubscribe@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-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, Oct 8, 2010 at 4:18 PM, Disconnect <dc.disconnect@gmail.com> wrote:> We just use packages: > package { "puppet": ensure => latest }If the rpm/deb script attempts to restart the service, that will stop puppet in the middle of the execution of the pkg manager itself. (Unless there''s special handling of this case implemented somewhere in the toolchain -- see sshd). Seems safer to download the package file and schedule through something that decouples the pkg manager from the puppet client process. m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don''t get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
That''s more of what we''re looking to do. I think it would be
a bad
idea to have puppet automatically updating clients. This would need
to be a one-off, scheduled item you would trigger from the puppet
master server, under the default {} node, I would presume;
Perhaps having the puppet (and facter) gem reside in a puppet://files/
URL and a definition within default {} that would ensure present and
latest (which could entail other dependencies like puppet.conf).
On Oct 8, 4:40 pm, Martin Langhoff <martin.langh...@gmail.com>
wrote:> On Fri, Oct 8, 2010 at 4:18 PM, Disconnect <dc.disconn...@gmail.com>
wrote:
> > We just use packages:
> > package { "puppet": ensure => latest }
>
> If the rpm/deb script attempts to restart the service, that will stop
> puppet in the middle of the execution of the pkg manager itself.
> (Unless there''s special handling of this case implemented
somewhere in
> the toolchain -- see sshd).
>
> Seems safer to download the package file and schedule through
> something that decouples the pkg manager from the puppet client
> process.
>
> m
> --
> martin.langh...@gmail.com
> mar...@laptop.org -- School Server Architect
> - ask interesting questions
> - don''t get distracted with shiny stuff - working code first
> -http://wiki.laptop.org/go/User:Martinlanghoff
--
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.
Martin Langhoff
2010-Oct-08 21:44 UTC
Re: [Puppet Users] Re: Using puppet to update itself
On Fri, Oct 8, 2010 at 4:56 PM, Forrie <forrie@gmail.com> wrote:> That''s more of what we''re looking to do. I think it would be a bad > idea to have puppet automatically updating clients. This would need > to be a one-off, scheduled item you would trigger from the puppet > master server, under the default {} node, I would presume;I don''t think it''s a matter of working on it on the server side of puppet.> Perhaps having the puppet (and facter) gem reside in a puppet://files/ > URLrpm, dpkg or gems, it doesn''t really change the risk, nor the complication. You need something that says: - stop the service - run command X (with no calls to elements of the package itself) -- rollback if it fails - start the service Hard to do right. cheers, m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don''t get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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 Oct 8, 1:18 pm, Disconnect <dc.disconn...@gmail.com> wrote:> We just use packages: > package { "puppet": ensure => latest }Seconded, mostly. We target specific versions, and test in a lab first, but self upgrades work. We''ve gone through up, and down, grades of multiple versions of .24, .25, and 2.6. In every case that I can recall we just let puppet update itself without incident. Typically we''ll fork off a puppetmaster, then update to the target rev & module/manifests. Next all of the regular puppetmasters run against the fork and upgrade. Then clients start checking in and upgrading. Downgrades are pretty much just the opposite. A key point is controlling who upgrades when, typically just needs a case/selector based on role/puppetclass. -- 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 Oct 10, 2010, at 3:29 AM, donavan wrote:> On Oct 8, 1:18 pm, Disconnect <dc.disconn...@gmail.com> wrote: >> We just use packages: >> package { "puppet": ensure => latest } > > Seconded, mostly. We target specific versions, and test in a lab > first, but self upgrades work. We''ve gone through up, and down, grades > of multiple versions of .24, .25, and 2.6. In every case that I can > recall we just let puppet update itself without incident.What packages do you do this with? The three I''ve heard people ask about the most are gems, rpms, and debs. -- 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 10/10/2010 06:28 PM, Patrick wrote:> > On Oct 10, 2010, at 3:29 AM, donavan wrote: > >> On Oct 8, 1:18 pm, Disconnect <dc.disconn...@gmail.com> wrote: >>> We just use packages: >>> package { "puppet": ensure => latest } >> >> Seconded, mostly. We target specific versions, and test in a lab >> first, but self upgrades work. We''ve gone through up, and down, grades >> of multiple versions of .24, .25, and 2.6. In every case that I can >> recall we just let puppet update itself without incident. > > What packages do you do this with? The three I''ve heard people ask about the most are gems, rpms, and debs. >I''ve noticed that deb seems to work fine in this scenario. I''m seeing problems with RPMs in SUSE environments, because the restart using init script doesn''t seem to work (sometimes?). Regards, Felix -- 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.
Thought I''d just post some manifest code for what people have already
described to give you some ideas.
The following is a parameterised class where you can either use the
site default, or pass in any version of Puppet you want:
class puppet($request_version = "") {
#everything needs common!
include common
######################################################################
#
# !!! VERY IMPORTANT VARIABLE !!!
#
#The exact version (including release number) of the Puppet package
#to install. Updating this will upgrade Puppet SITE WIDE!
#
#If you want to upgrade one node, pass the class include the
#''request_version'' variable like so:
# node foo { class {fh_puppet: request_version => "9.8.7" } }
if $request_version == "" {
$puppet_version = "2.6.2-1"
} else {
$puppet_version = $request_version
}
######################################################################
#We build the Puppet RPMs ourselves so we need our internal
repository
realize Managed_yumrepo[internal]
package{"puppet":
ensure => $puppet_version,
}
#The puppetd service, restart when the package changes so we''re not
running
#old versions of the daemon.
service { "puppet":
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
subscribe => Package["puppet"],
}
...
}
I use Ruby Enterprise for Puppet Masters, so have created my own
define to install/upgrade Gems in the Ruby Enterprise environment:
#use the Ruby Enterprise Gem installer for a given Gem name
define entgempackage($version = "") {
$gemcmd = "/opt/ruby-enterprise/bin/gem"
#If no version is specified, attempt to install any version of the
named gem.
#This will not upgrade Gems.
if $version == "" {
$cmd = "$gemcmd install $name"
exec { "$cmd":
unless => "/usr/bin/test `$gemcmd list $name | grep $name | wc -
l` -eq 1",
logoutput => "on_failure",
}
}
#otherwise, install the supplied version. If the gem is already
installed,
#the gem will be updated instead of installed along side the current
version.
else {
$cmd = "/bin/bash -c ''if [[ `$gemcmd list $name | grep $name |
wc -
l` -eq 1 ]]; then if [[ `$gemcmd list $name | grep $version | wc -l` -
eq 0 ]]; then $gemcmd update $name -v $puppet; fi; else $gemcmd
install $name -v $version; fi''"
exec { "$cmd":
unless => "/usr/bin/test `$gemcmd list $name | grep $version |
wc -l` -gt 0",
logoutput => "on_failure",
}
}
}
And then a class for the Puppet Master:
class puppet::master inherits puppet {
include common
include httpd::ssl
include subversion
include ruby_enterprise::passenger
#The puppet version variable can''t come from the parent class as the
RPM version
#contains a release number and this is not handled by Gem (they
don''t have
#release numbers).
$puppet_gem_version = "2.6.2"
entgempackage { "puppet":
version => $puppet_gem_version,
require => Entgempackage["passenger"],
notify => Service["httpd"],
}
...
}
On Oct 8, 9:15 pm, Forrie <for...@gmail.com>
wrote:> I''m just beginning with Puppet. One issue I''ve run into
is updates.
> As my nodes expand, updating each individual node via my manual method
> becomes daunting.
>
> Could someone share their recipe or procedure for using the puppet
> master to distribute updates of puppet to the client nodes? I would
> guess using a "gem" would be easier. Updating puppet on the
master
> node isn''t much of a problem via source, though perhaps I should
> consider the "gem" there as well?
>
> 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.
Thanks for posting the code snippet. We haven''t been building RPMs for internal use; so, I certainly could work on that. I think we might be able to do a filesystem tree copy -- for example, track the files that get installed on the master server, then copy those to the files repository under puppet, replicate from there. For that matter, I still think it would be useful if puppet''s default install script would include a switch for "master" and "client" so that you don''t get the entire distribution installed when it doesn''t need to be. I''m finding that as (being a newbie) I rollout Puppet and these new releases come about, it''s becoming more necessary that I find some cogent means to update puppet through the clients. Doing this manually just simply sucks and wastes time ;-) My process of rolling out ruby is pretty much the same, only I compile it locally then distribute the object/compiled code and install from there on the hosts. 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 Thu, Oct 28, 2010 at 3:15 PM, Forrie <forrie@gmail.com> wrote:> Thanks for posting the code snippet. > > We haven''t been building RPMs for internal use; so, I certainly could > work on that. I think we might be able to do a filesystem tree copy > -- for example, track the files that get installed on the master > server, then copy those to the files repository under puppet, > replicate from there. > > For that matter, I still think it would be useful if puppet''s default > install script would include a switch for "master" and "client" so > that you don''t get the entire distribution installed when it doesn''t > need to be. >We''ve traditionally seen that as part of our distro packaging teams job, and they do a good job at this, but please file a feature request or submit patches if you think you can cleanly do this. I''m concerned people will misunderstand the relationship and think they can install version x of the client and version y of the server when they''re doing it with ad hoc install.rb invocations rather than a proper packaging system.> > I''m finding that as (being a newbie) I rollout Puppet and these new > releases come about, it''s becoming more necessary that I find some > cogent means to update puppet through the clients. Doing this > manually just simply sucks and wastes time ;-) >I''d argue you''re doing it wrong. Why aren''t you building packages? It''s significantly more work to test new versions the way you''re doing it. How are you rolling back if a version doesn''t work for you if you do it all with file copies? It feels like you''re reinventing packaging.> > My process of rolling out ruby is pretty much the same, only I compile > it locally then distribute the object/compiled code and install from > there on the hosts. >I really don''t understand why you''re not using packages.You''re seriously pushing out *files* to roll out Ruby?> > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- 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.