1

I am trying to run apt-get dist-upgrade via chef cookbook. I am aware that running apt-get upgrade in cookbook is not generally recommended (https://stackoverflow.com/questions/15080876/apt-get-update-and-apt-get-upgrade-in-chef#15093460), but we control our ubuntu mirrors and any packages will get into that mirror only after thorough testing, so running dist-upgrade is fine.

What I have currently in my cookbook is 

execute "apt update" do command "apt-get -y update" end execute "apt dist-upgrade" do command 'DEBIAN_FRONTEND=noninteractive apt-get -fuy -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade' end execute "apt autoremove" do command "apt-get -y autoremove" end

which looks more like a shell script rather than a chef cookbook. Adding apt cookbook will run apt-get update but I didn't find a better way of doing things for apt dist-upgrade.

Even this https://supermarket.chef.io/cookbooks/apt-upgrade-once cookbook does in the same fashion.

How can this be done in a better manner via chef cookbook?

I am looking for answers via cookbooks only not by cron/unattendedupgrades (As I am aware doing things via cron/unattendedupgrades).

Update:

apt update can be better run by 

apt_update 'update' do action :update end

Reference

Improve this question
5
  • So, I know you put a caveat there that you do not wish to do cron/unattended upgrades, but I must ask why? If you limit upgrades to non-API/ABI and security-related updates, you will be taking good advantage of the hundreds of QA engineers Linux distributions have, on top of the work the upstream devs themselves do. This is part of the point of having "distributions" in the first place - you trust their developers and engineers so you don't have to do QA on hundreds of software components. I have other Chef-y ideas, too, but this is a more fundamental question for your use-case. :) Commented Jul 28, 2017 at 21:07
  • @JesseAdelman There is nothing wrong in running the upgrade via cron/unattended upgrades, it's just that I am aware of how to do the same. Will edit the question to explain about the same Commented Aug 1, 2017 at 6:29
  • 1
    @JesseAdelman I am trying to run them on bunch of laptops, so I can't guarantee uptime of them so can't use cron (I can run cron for every 10 minutes, but looking for something better than a hard-coded value), Unattended upgrades basically is cron run at random time of day Commented Aug 1, 2017 at 6:46
  • @JesseAdelman adding cookbook in the run-list of the node will avoid the interval period being hard-coded and will make sure that the system will be on the latest (approved) stable version once chef-client checks in with the chef server. I might be just nitpicking here but cron with 10 to 30 min interval should do the job Commented Aug 1, 2017 at 6:56
  • 1
    Ah ha! You might actually be looking for a better cron! The choice which immediately comes to my mind is "fcron". fcron.free.fr/description.php One design goal of fcron is that it should work well on hosts that are not up continuously. See fcron.free.fr/doc/en/fcrontab.5.html for the crazy amount of flexible timing options. OK, I've hijacked this question enough. :) Good luck. Commented Aug 1, 2017 at 15:34

1 Answer 1

Reset to default
2

This is not an idempotent action so what you have is the best you can do, maybe with some more guards or something to only run once a day or whatnot.

Improve this answer
4
  • 1
    Why isn't it? Neither the update nor the upgrade or autoremove part should change your system if you run them a second time. Commented Aug 1, 2017 at 14:57
  • Chef has no way to know that though. And if you run them twice at different times it will have different results. Commented Aug 1, 2017 at 16:17
  • 2
    @allo for example think bash version on your system is 1.0 bash current stable version is 1.1 and you do a upgrade the version changes to 1.1 but in five minutes bash released 1.2 version if you do a upgrade second time the bash version will be upgraded to 1.2 so the upgrade is not idempotent. Commented Aug 2, 2017 at 7:04
  • That's true. But it may depend on how you define your target state. for example ansible has an apt module, which has "state=upgraded" and the invariant after a run is, that the state is always "fully upgraded" (but not always the same bash version). This cookbook here looks more imperative than declerative, so it's probably not the best way. Commented Aug 2, 2017 at 15:47

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.