Using puppet to update itself

[Forrie]

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.

[Disconnect]

We just use packages:
 package { "puppet": ensure => latest }

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

[Martin Langhoff]

On Fri, Oct 8, 2010 at 4:18 PM, Disconnect <dc.dis...@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....@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

[Forrie]

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

[Martin Langhoff]

On Fri, Oct 8, 2010 at 4:56 PM, Forrie <for...@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/
> URL

rpm, 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....@gmail.com

[donavan]

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.

[Patrick]

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.

[Felix Frank]

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

[luke.bigum]

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"],
}
...

[Forrie]

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

[Nigel Kersten]

On Thu, Oct 28, 2010 at 3:15 PM, Forrie <for...@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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@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