Package { ensure => latest } behavior?
Richard
to all my servers. After having successfully built and install my
software to my local APT repository I used Puppets package{} directive
to push it to my servers. Next I updated my software to version from
1.0 to 1.0.2. My problem is that all of my servers are still running
the 1.0 package.
Even after updating the repository on my servers (aptitude update),
Puppet still does not seem to want to upgrade the existing packages to
the new version. If I manually run "aptitude upgrade" on my server it
will go ahead and install the 1.0.2 version. My question is: Is this
the way Puppet is supposed to work? If so, how do I force it to
upgrade to the latest version of a package? I've tried using both
{ensure => installed} and {ensure=>latest} in my package directive but
neither one forced the upgrade. Should I use the version number
somehow {ensure=>1.0.2}?
Thanx!
Richard
Luke Kanies
Look at the 'aptitude' provider and see how it determines the 'latest'
version, and then run that on your machine to see what it says.
--
This space intentionally has nothing but text explaining why this
space has nothing but text explaining that this space would otherwise
have been left blank, and would otherwise have been left blank.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Richard
I run it for my package I get this:
kangaroobox-anteater-base:
Installed: 1.0.2
Candidate: 1.0.3
Version table:
1.0.3 0
500 http://update.kangaroobox.com stable/main Packages
*** 1.0.2 0
100 /var/lib/dpkg/status
As you can see, the current version is 1.0.3 but the installed version
is 1.0.2. My package directive is very simple (see below) and uses
ensure=>latest in order to force the package to keep current.
package { "kangaroobox-anteater-base" : provider => aptitude,
ensure => latest, }
The weird thing is that the client log file never mentions looking at
this package at all. Only when I manually remove the package on the
client does Puppet say that its installing it again. It's almost as
if Puppet is ignoring the package unless I specifically say to take
action. Am I missing something? Do I have to 'trigger' the package
updater somehow? Should I open a ticket?
Thanx!
Richard
BTW: This is happening on Debian Etch running either the v0.20.1 & v.
0.24.1 clients.
On Mar 28, 1:08 pm, Luke Kanies <l...@madstop.com> wrote:
> Look at the 'aptitude' provider and see how it determines the 'latest'
> version, and then run that on your machine to see what it says.
Luke Kanies
> The command that it runs is 'apt-cache policy <package name>' and when
> I run it for my package I get this:
>
> kangaroobox-anteater-base:
> Installed: 1.0.2
> Candidate: 1.0.3
> Version table:
> 1.0.3 0
> 500 http://update.kangaroobox.com stable/main Packages
> *** 1.0.2 0
> 100 /var/lib/dpkg/status
>
> As you can see, the current version is 1.0.3 but the installed version
> is 1.0.2. My package directive is very simple (see below) and uses
> ensure=>latest in order to force the package to keep current.
>
> package { "kangaroobox-anteater-base" : provider => aptitude,
> ensure => latest, }
>
> The weird thing is that the client log file never mentions looking at
> this package at all. Only when I manually remove the package on the
> client does Puppet say that its installing it again. It's almost as
> if Puppet is ignoring the package unless I specifically say to take
> action. Am I missing something? Do I have to 'trigger' the package
> updater somehow? Should I open a ticket?
If you run this in debug mode you don't see anything about apt-cache
policy running for this package?
Is anyone else experiencing this behaviour?
Does it work if you use apt instead of aptitude? (I don't really know
if you can test this; I assume their behaviour is similar enough.)
Otherwise, yeah, I guess open a ticket.
--
It's not that I'm afraid to die. I just don't want to be there when it
happens. -- Woody Allen
Richard
It looks like it's not a problem after all, at least with the latest
(v0.24.1) Puppetd. I ran both clients overnight (on separate
machines) just to give them plenty of time to update. According to my
test it looks like the new one does work properly after all, you just
have to give it a bit of time to work. I think I was expecting it to
update on the next cycle but it probably took a couple of cycles,
which is no big deal. The old version never did update and never
mentioned anything in the logs. :(
Well the good news is that the new version is pretty self dependent
and is pretty safe to run in a Debian Stable distribution. So, I can
have my cake and eat it too! :)
Thanx!
Richard
On Mar 31, 12:52 pm, Luke Kanies <l...@madstop.com> wrote:
> On Mar 31, 2008, at 11:29 AM, Richard wrote:
> > The command that it runs is 'apt-cache policy <package name>' and when
> > I run it for my package I get this:
>
> > kangaroobox-anteater-base:
> > Installed: 1.0.2
> > Candidate: 1.0.3
> > Version table:
> > 1.0.3 0
> > 100 /var/lib/dpkg/status
>
> > As you can see, the current version is 1.0.3 but the installed version
> > is 1.0.2. My package directive is very simple (see below) and uses
> > ensure=>latest in order to force the package to keep current.
>
> > package { "kangaroobox-anteater-base" : provider => aptitude,
> > ensure => latest, }
>
> > The weird thing is that the client log file never mentions looking at
> > this package at all. Only when I manually remove the package on the
> > client does Puppet say that its installing it again. It's almost as
> > if Puppet is ignoring the package unless I specifically say to take
> > action. Am I missing something? Do I have to 'trigger' the package
> > updater somehow? Should I open a ticket?
>
> If you run this in debug mode you don't see anything about apt-cache
> policy running for this package?
>
> Is anyone else experiencing this behaviour?
>
> Does it work if you use apt instead of aptitude? (I don't really know
> if you can test this; I assume their behaviour is similar enough.)
>
> Otherwise, yeah, I guess open a ticket.
>
Luke Kanies
> : UPDATE ::
>
> It looks like it's not a problem after all, at least with the latest
> (v0.24.1) Puppetd. I ran both clients overnight (on separate
> machines) just to give them plenty of time to update. According to my
> test it looks like the new one does work properly after all, you just
> have to give it a bit of time to work. I think I was expecting it to
> update on the next cycle but it probably took a couple of cycles,
> which is no big deal. The old version never did update and never
> mentioned anything in the logs. :(
>
> Well the good news is that the new version is pretty self dependent
> and is pretty safe to run in a Debian Stable distribution. So, I can
> have my cake and eat it too! :)
Is it possible that you just needed to run 'apt-get update', and that
was the problem?
It certainly should either work immediately or not work at all,
assuming the apt cache is up to date.
--
In science, 'fact' can only mean 'confirmed to such a degree that it
would be perverse to withhold provisional assent.' I suppose that
apples might start to rise tomorrow, but the possibility does not
merit equal time in physics classrooms. -- Stephen Jay Gould
Richard
I didn't. Either way, I'm running the client cycle every 2 minutes
during testing and it probably took it a couple of cycles to install.
I didn't mean to imply that it was taking hours or anything. :) One
thing that did kind of throw me was that the old client didn't seem to
log the update very well, at least at the default log level. Another
potential problem was that I had the old puppetd.conf lying around and
I think it was trying to use that instead of the recommended
puppet.conf. After a clean reinstall and config it seems to be
working more consistently now.
In short, it looks like I screwed up the config and/or didn't
interpret the results properly. Par for the course... :)
Thanx!
Richard