APT's cron file missing

chmac commented 9 years ago

Not sure it's really an issue with this role, maybe more the host system, but I'll post it here anyway.

I have 2 systems where /etc/cron.daily/apt does not exist and is instead called /etc/cron.daily/apt.disabled. In this situation, the unattended-upgrades package does not get run.

Maybe there could be a check in this role to make sure that the necessary cron files exist? I'm not sure if they are standard across distributions though, so understand if it's not practical.

jnv commented 9 years ago

Thanks for the report Callum!

This is indeed strange, maybe there is some postinstall configuration required. Could you please specify what distribution and version do you use (and whether you recently did dist-upgrade)? I'd like to check the source package.

chmac commented 9 years ago

It's Ubuntu 14.04 from owned-networks.net. I have a handful of other 14.04 machines and they have apt's cron file enabled by default. I read somewhere that maybe cheap VPS providers disable a load of stuff in cron.daily to save CPU cycles! :-)

It seems like it's an unlikely scenario, not sure if it really makes sense to include a test in the role or not. I added my own test to the playbook to rename the file from apt.disabled to apt if it doesn't exist. Of course that will fail if the disabled version doesn't exist!

jnv commented 9 years ago

I see, this was also reported in here: http://askubuntu.com/questions/530133/cron-jobs-are-disabled-on-clean-installation-of-14-04

I wonder how the provider makes this change: either they provide a modified package through a mirror (which seems unlikely), or it is already in the image – as a preinstalled file, a file diversion or as a separate process which renames these files.

Anyway I don't think we should attempt to fix this edge case through this role. I'd recommend to create a new role for renaming the file which might depend on this role for easier updates and reusability. And also question your provider about their decisions.

Moving the file should be a two phase process, e.g.:

- name: check if apt.disabled exists
  stat: path=/etc/cron.daily/apt.disabled
  register: apt_disabled

- name: reenable apt script for daily cron
  command: mv /etc/cron.daily/apt.disabled /etc/cron.daily/apt
  when: apt_disabled.stat.exists

(see stat module)

I will close this issue, let me know if this is okay.

chmac commented 9 years ago

Ah yes, check if the .disabled version exists first, smart. That's much less likely to fail!

chmac commented 9 years ago

Oh, and sure, I can see that it doesn't make sense to check for this particular edge case in a generic module. Thanks for the feedback and for saving me a load of time by publishing your module. :+1:

Yannik commented 8 years ago

@jnv This doesn't seem to be so rare. I ran into the same thing today.

$ dpkg -S /etc/cron.daily/apt
apt: /etc/cron.daily/apt
$ dpkg -S /etc/cron.daily/apt.disabled
dpkg-query: no path found matching pattern /etc/cron.daily/apt.disabled
$ ls /etc/cron.daily
apache2            bsdmainutils.disabled      logrotate         passwd.disabled  upstart.disabled
apt.disabled       cracklib-runtime.disabled  man-db.disabled   quota.disabled
aptitude.disabled  dpkg.disabled              mlocate.disabled  spamassassin

I guess the provider does this change in their system image they then install on their customers servers. However, I wonder why apt-get --reinstall install apt doesn't fix this.

I agree with your point about keeping this role as small as possible, but in this case, it seems as if it would probably make sense to add it, as it apparantly happens quite regularly.

Btw, this is not a cheap VPS but a quite expensive one with the big german hosting company Strato.

Yannik commented 8 years ago

I created a role which deals with this: https://github.com/Yannik/ansible-role-enable-standard-cronjobs

jnv commented 8 years ago

@Yannik Thanks!