[Puppet Users] Problems with apt package installs

[Matt Southerden]

Hi,

I'm new to puppet, and I have a couple of apt related problems I'm
struggling to find solutions to.

Firstly, we'd like to run an apt-get upgrade the very first time a
node goes under puppet's control. Is there a good way to do this? I
thought that maybe touching a 'lock' file after running the command,
and only running if that file doesn't exist. Obviously, if this file
gets removed the packages would be upgraded again.

Secondly, I'm having trouble with outdated packages when trying to
install apache (and others). If some of the package details have
changed since apt update, then apt-get install xxx fails. If I
manually go onto the server and run an apt-get update, then kick
puppet again, the package installs fine. I have seen a number of
places where people have a similar issue on deb machines, and some
people recommend doing the following as defaults:

exec { "apt-get-update":
refreshonly => true,
command => "apt-get update"
}

Package {
ensure => installed,
require => Exec["apt-get-update"]
}

But reading the docs (and trying this out manually) the require
parameter doesn't trigger the exec (so I have no idea how all these
people are getting it to work *shrug*, or maybe they just think it's
working...)

Any help would be massively appreciated.

Thanks,
Matt. :)

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

[Daniel Pittman]

Matt Southerden <southe...@googlemail.com> writes:

> I'm new to puppet, and I have a couple of apt related problems I'm
> struggling to find solutions to.
>
> Firstly, we'd like to run an apt-get upgrade the very first time a
> node goes under puppet's control. Is there a good way to do this?

No. The next release will be easier, but for now you need to be very, very
careful to get ordering right. We have, roughly, this structure:

class apt::config {
# install sources.list, and other *files* required for apt
}

class apt {
exec { "/usr/bin/aptitude update": require => Class["apt::config"]
}

Package { require => Class["apt"] }

That helps ensure that the aptitude update runs before any package install in
puppet, but is ugly. The next release (as I understand the roadmap) will
improve this by having "stages" where you can arrange it with less trouble.

[...]


[...]

> But reading the docs (and trying this out manually) the require parameter
> doesn't trigger the exec (so I have no idea how all these people are getting
> it to work *shrug*, or maybe they just think it's working...)

Drop the 'refreshonly' in the apt update 'exec', and it will work. :)

Daniel

--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons

[Nigel Kersten]

On Mon, May 24, 2010 at 7:07 AM, Daniel Pittman <dan...@rimspace.net> wrote:

Matt Southerden <southe...@googlemail.com> writes:

> I'm new to puppet, and I have a couple of apt related problems I'm
> struggling to find solutions to.
>
> Firstly, we'd like to run an apt-get upgrade the very first time a
> node goes under puppet's control. Is there a good way to do this?

No.  The next release will be easier, but for now you need to be very, very
careful to get ordering right.  We have, roughly, this structure:

class apt::config {
 # install sources.list, and other *files* required for apt
}

class apt {
 exec { "/usr/bin/aptitude update": require => Class["apt::config"]
}

Package { require => Class["apt"] }

That helps ensure that the aptitude update runs before any package install in
puppet, but is ugly.  The next release (as I understand the roadmap) will
improve this by having "stages" where you can arrange it with less trouble.

It's not actually that bad.  I tend to create a whole class just for the update commands and set a global resource default require as Daniel has shown.

Another option is to create your own defined type, say "apt_package" that takes into account the local customizations at your site that wraps a normal package type with all the right dependencies.

I'm finding this is more flexible, simply because you can set the require/before however you like on individual resources without having to worry about overriding the global resource default, or know what it is.

 

[...]


[...]

> But reading the docs (and trying this out manually) the require parameter
> doesn't trigger the exec (so I have no idea how all these people are getting
> it to work *shrug*, or maybe they just think it's working...)

Drop the 'refreshonly' in the apt update 'exec', and it will work. :)

       Daniel

--
✣ Daniel Pittman            ✉ dan...@rimspace.net            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons

--

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

[Gabriel - IP Guys]

I'm still very new to puppet, and I've been away for the last few days,
so please forgive me if my answer is old. But if you want to ensure that
your repos are upto date, do what you would do on a normal box, and that
is run apt-get update fairly often - once a day at 20 past midnight
maybe. For that, maybe setup a cron job via puppet?

Then, all you have to do, is wait 24 hours after a system has come under
your control, and you should have an up to date system.

I know it's a band aid idea, but it's a start :) Anyone want to expand
on this?


The Puppet Apprentice :- http://puppetnewbie.blogspot.com/
Follow me on twitter :- http://twitter.com/mritguru
Puppet #tag on twitter :- #puppet
IRC :- itguru ON irc.freenode.org (feel free to say
hi!)

[Nigel Kersten]

On Mon, May 24, 2010 at 8:17 AM, Gabriel - IP Guys <Gab...@impactteachers.com> wrote:

I'm still very new to puppet, and I've been away for the last few days,
so please forgive me if my answer is old. But if you want to ensure that
your repos are upto date, do what you would do on a normal box, and that
is run apt-get update fairly often - once a day at 20 past midnight
maybe. For that, maybe setup a cron job via puppet?

Then, all you have to do, is wait 24 hours after a system has come under
your control, and you should have an up to date system.

I know it's a band aid idea, but it's a start :) Anyone want to expand
on this?

Here's how we do it.

We have a class, "package::apt::update"

This contains the commands:

apt-get update

apt-get -f install

dpkg --configure -a

apt-get dist-upgrade

basically in that order with requires.

We initially started off with a global resource default defined:

Package { require => Class["package::apt::update"] }

The problem with this is that if you have an individual resource that also needs its own require, you're overriding the global default, so you need to remember to add it, like:

package { "foo":

  ...

  require => [ Class["package::apt::update"], File["something_else"], ],

}

So we've instead started moving towards a wrapped defined type:

define apt_package($ensure="latest") {

  package { $name:

    ensure  => $ensure,

    require => Class["package::apt::update"],

  }

}

which means you can simply do:

apt_package { "foo":

  require => File["something_else"],

}

and both requires are automatically applied.

We've also set up a similar define for repositories, "apt_repo", which is guaranteed to run *before* Class["package::apt::update"], so everything comes out in the right order.

 

The Puppet Apprentice   :- http://puppetnewbie.blogspot.com/
Follow me on twitter    :- http://twitter.com/mritguru
Puppet #tag on twitter  :- #puppet
IRC                     :- itguru ON irc.freenode.org (feel free to say
hi!)

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

[Daniel Pittman]

"Gabriel - IP Guys" <Gab...@impactteachers.com> writes:

> I'm still very new to puppet, and I've been away for the last few days, so
> please forgive me if my answer is old. But if you want to ensure that your
> repos are upto date, do what you would do on a normal box, and that is run
> apt-get update fairly often - once a day at 20 past midnight maybe. For
> that, maybe setup a cron job via puppet?
>
> Then, all you have to do, is wait 24 hours after a system has come under
> your control, and you should have an up to date system.

FWIW, we used to rely on this, and it got painfully old when our requirements
changed and we needed an update applied sooner rather than later to our
internal software deployments.

The same would be true of an emergency security patch from upstream, though,
so I certainly feel happier having puppet ensure the resources it depends on
are up to date.

Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons

[Nigel Kersten]

On Mon, May 24, 2010 at 6:10 PM, Daniel Pittman <dan...@rimspace.net> wrote:

"Gabriel - IP Guys" <Gab...@impactteachers.com> writes:

> I'm still very new to puppet, and I've been away for the last few days, so
> please forgive me if my answer is old. But if you want to ensure that your
> repos are upto date, do what you would do on a normal box, and that is run
> apt-get update fairly often - once a day at 20 past midnight maybe. For
> that, maybe setup a cron job via puppet?
>
> Then, all you have to do, is wait 24 hours after a system has come under
> your control, and you should have an up to date system.

FWIW, we used to rely on this, and it got painfully old when our requirements
changed and we needed an update applied sooner rather than later to our
internal software deployments.

The same would be true of an emergency security patch from upstream, though,
so I certainly feel happier having puppet ensure the resources it depends on
are up to date.

Absolutely.

While I've got apt people reading this thread... :) How do you think Puppet could best model pinning?

I keep thinking I want to make it part of a repository type, but then wonder whether it's best expressed as a separate resource.... 

 

       Daniel
--
✣ Daniel Pittman            ✉ dan...@rimspace.net            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons

--

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