Holding packages on providers with holdable feature

482 views
Skip to first unread message

sjr

unread,
May 15, 2013, 8:24:47 PM5/15/13
to puppet...@googlegroups.com
Hi Puppet Users :-)

I've been looking for information on how to hold packages on Debian because we maintain a bunch of package that are either part of our products or they are not available in Debian repos.

The thing is we would like to be able to specify a version for the package and tell dpkg to hold it to prevent unwanted upgrades (mainly because human errors). As I haven't been able to get it working with current APT provider I would like if with its current status this is possible...

i.e:

package {['puppet', 'puppet-common']:
  ensure => '2.7.21-1puppetlabs1',
  hold    => true,
}

I know I could get around having a defined type or other kind of trick but I really would like to do it with the provider as I think it's part of package management.

Would this be a feature of interest for Puppet users in Debian/Ubuntu? I know Debian is quite conservative about package versions so I can imagine many platforms that are in no need for this feature but I also think has to be quite some people in similar situation...

The puppet version we are currently using is 2.7.21-1puppetlabs1 and for now it's not running in daemon mode.

Cheers,
sjr

Gabriel Filion

unread,
May 16, 2013, 1:25:57 AM5/16/13
to puppet...@googlegroups.com
Hey there,

On 15/05/13 08:24 PM, sjr wrote:
> The thing is we would like to be able to specify a version for the
> package and tell dpkg to hold it to prevent unwanted upgrades (mainly
> because human errors). As I haven't been able to get it working with
> current APT provider I would like if with its current status this is
> possible...

if you provide a version in the "ensure" parameter, then puppet will
install this specific version..

but the way we do it where I work is to have puppet drop a file in
/etc/apt/preferences.d and pin it. See [0] for more info on pinning (it
doesn't talk about preferences.d, but everything that can go in
/etc/apt/preferences can be split in different files in
/etc/apt/preferences.d)

[0]: http://wiki.debian.org/AptPreferences

this way, you're sure that no operation, should it be puppet or manual
interventions will upgrade the package.

--
Gabriel Filion

signature.asc

sjr

unread,
May 16, 2013, 3:28:18 AM5/16/13
to puppet...@googlegroups.com
Hi Gabriel,

first of all thanks for your comment much appreciated.

Take a look to the example I wrote, I know writing the version in ensure puppet will do that...but let's imagine someone puts a new version of one of our services in the repository and another someone comes and makes the mistake of upgrading without noticing that new version, the service will be restarted twice ... for the upgrade and next time puppet will run, also notice we're not running  puppet agent in daemon mode so either a human or Nagios will have to find out about the upgrade. We would like to avoid this kind of situations.

About the preferences file, I also know...that's what we are currently doing and also would like to get rid of them, less files to maintain, less work when upgrading things and less chances of forgetting them :-)

We think holding the packages is the right option for us.


Thanks!
sjr

Gabriel Filion

unread,
May 16, 2013, 10:20:16 PM5/16/13
to puppet...@googlegroups.com, sjr
On 16/05/13 03:28 AM, sjr wrote:
> Take a look to the example I wrote, I know writing the version in ensure
> puppet will do that...but let's imagine someone puts a new version of
> one of our services in the repository and another someone comes and
> makes the mistake of upgrading without noticing that new version, the
> service will be restarted twice ... for the upgrade and next time puppet
> will run, also notice we're not running puppet agent in daemon mode so
> either a human or Nagios will have to find out about the upgrade. We
> would like to avoid this kind of situations.

oh! I just went back to the puppet documentation and learned something.
I didn't know puppet was able to hold packages..

according to documentation you should set "ensure" to the value "held"
to have puppet use "dpkg --set-selections $package hold",

but then reading the "package" type and its "apt" provider,
unfortunately I don't think it's possible to mix holding and enforcing a
particular version since both use the ensure parameter..
signature.asc

sjr

unread,
May 17, 2013, 3:45:27 AM5/17/13
to puppet...@googlegroups.com, sjr
Hi Grabriel,

yes, that's the point ... it's not currently possible so I wanted to know what the community is doing for overcoming this "problem" ... and whether it could be a useful feature.

I have done a quick&dirty hack to the APT provider and it works when installing a new package I can enforce a version and hold it. But from my minor mod to a proper patch...there is still much work to do, so that's why I was looking for comments, opinions, and so on about this feature....

I probably didn't explain myself well enough in my first email :-)


sjr.

Gabriel Filion

unread,
May 17, 2013, 7:18:07 PM5/17/13
to puppet...@googlegroups.com, sjr
On 17/05/13 03:45 AM, sjr wrote:
> I have done a quick&dirty hack to the APT provider and it works when
> installing a new package I can enforce a version and hold it. But from
> my minor mod to a proper patch...there is still much work to do, so
> that's why I was looking for comments, opinions, and so on about this
> feature....

well I can't really think of why both features should be exclusive (the
current state).

"holding" a package doesn't ensure a particular version other than the
one that's already currently installed, which is not particularly precise.

so it'd be interesting to make them separate (maybe just have a "hold"
parameter to the type)

the best place to discuss your patch and implementation/design details
would probably be on the puppet-dev list. and maybe open up an issue on
redmine first and refer to it on the list. that way you can get people
to vote on the issue to show support ;)

--
Gabriel Filion

signature.asc

sjr

unread,
May 20, 2013, 10:45:06 AM5/20/13
to puppet...@googlegroups.com, sjr
Thanks!

I'll continue the discussion there after opening the issue :-)

sjr.
Reply all
Reply to author
Forward
0 new messages