Puppet users - May 2010 - Problems with apt package installs

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

Matt Southerden <southerdenmw@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            ✉ daniel@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-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 Mon, May 24, 2010 at 7:07 AM, Daniel Pittman <daniel@rimspace.net>
wrote:
> Matt Southerden <southerdenmw@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            ✉ daniel@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-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

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

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

-- 
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 Mon, May 24, 2010 at 8:17 AM, Gabriel - IP Guys <
Gabriel@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-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

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

"Gabriel - IP Guys" <Gabriel@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            ✉ daniel@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-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 Mon, May 24, 2010 at 6:10 PM, Daniel Pittman <daniel@rimspace.net>
wrote:
> "Gabriel - IP Guys" <Gabriel@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            ✉ daniel@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-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

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