unattended-upgrades and debconf

[rmoriz]

If the unattended_upgrades package is already installed, the debconf seed never gets seeded and auto-updates will never get enabled:

https://github.com/chef-cookbooks/apt/blob/master/recipes/unattended-upgrades.rb#L27

Systems initially provisioned by cloud-init (like recently at DigitalOcean) already have unattended_upgrades installed and auto-update disabled.

[fabn]

+1 for this issue, is not working when package is already installed.

[tas50]

@rmoriz / @fabn Can you elaborate on this a bit more. I'm trying to understand exactly what wouldn't work here. I was under the impression from reading the Debian docs that all you needed was the proper config in the 20auto-upgrades file to get the contents of the 50unattended-upgrades to be respected. If the user has the attribute set to enable upgrades they're getting true set in the seed file, but also APT::Periodic::Unattended-Upgrade set as well in 20auto-upgrades.

[rmoriz]

I don't really remember the details, but the chef seed file is ignored if the package is already installed.

Even when the /etc/apt/apt.conf.d/20auto-upgrades file now gets created using chef, the next update of the unattended-upgrades package will disable it again because of running the postinstall: https://sources.debian.net/src/unattended-upgrades/0.93.1%2Bnmu1/debian/postinst/#L41

[gwimpey]

I believe that this is a problem with the implementation of the :reconfig action in the package provider. Idempotency is enforced only by checking that the seed file has not changed. The actual state of the configuration database is not checked. Thus, the :reconfig action is not actually enforcing compliance.

The relevant code seems to be here; https://github.com/chef/chef/blob/4332122132da81eac1f3ab0f28f3cbce365b85a4/lib/chef/provider/package.rb#L197-L220

[rmoriz]

In the case of https://github.com/chef-cookbooks/apt/blob/master/recipes/unattended-upgrades.rb#L28 the install action is used, not reconfig.

installwill not seed if the package is already there, as explained in the OP.

If, after a successfull seed+install, something changes the config db (as you describe), it will not fix and reconfigure. But IMO this is a rare case because it requires active "destruction" after chef took over the management of the node. In my case, the problem starts before Chef is bootstrapped and run.

Here is some in-house hack I'm using to deal with the situation:

auto_updates_enabled = !node['apt']['unattended_upgrades']['enable'].nil?

execute 'debconf_seeding_unattended_upgrades' do
  command "echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean #{auto_updates_enabled}' | debconf-set-selections"'
  cwd '/tmp'
  not_if "debconf-show unattended-upgrades | grep 'enable_auto_updates: #{auto_updates_enabled}'"

  notifies :run, 'execute[reconfigure_unattended_upgrades]', :immediately
end

execute 'reconfigure_unattended_upgrades' do
  command 'dpkg-reconfigure unattended-upgrades'
  environment(
    'DEBIAN_FRONTEND' => 'noninteractive'
  )
  action :nothing
end