jnv / ansible-role-unattended-upgrades

[DEPRECATED] Setup unattended-upgrades on Debian-based systems
https://github.com/jnv/ansible-role-unattended-upgrades/issues/98
GNU General Public License v2.0
272 stars 94 forks source link

Override configuration in a separate apt.conf.d file #32

Closed jnv closed 2 years ago

jnv commented 7 years ago

Follow-up to #31.

Since there is apt.conf.d directory, configuration files are applied in order and the file with higher number overrides previous. Therefore we don't need to modify original files; we just generate a new file with a high number, say 90-ansible-unattended-upgrades. Apt will happily manage defaults and no ucf-dist files will be generated.

Now, the question is how to handle the transition. Ideally we want to put 20auto-upgrades and 50unattended-upgrades files into a pristine state. Perhaps, like with 10periodic file, there can be a one-shot command to reinstall the package.

veger commented 7 years ago

I am willing to create a PR which merges all apt configuration(s) into a new file/template called 90-ansible-unattended-upgrades.

Let me know, if this is what you want.

jnv commented 7 years ago

@veger Thanks, that would definitely help! However, I would like to create some proper tests first, perhaps to catch regressions: #29.

veger commented 7 years ago

Seems a good idea to do that first, let me know when you are ready to implement this issue

colans commented 5 years ago

@veger Looks like tests are in place now. I think you can create a PR. If you're no longer interested, let us know so that someone else can do it.

colans commented 5 years ago

This was a quick one so I just did it myself. I don't believe we need to bother unwinding changes to the default settings with code; I've handled it with documentation in a new note. Please review; it's included in my PR above.

veger commented 5 years ago

I am not using ansible for work anymore as I changed jobs in the meantime. So no problem you did the PR yourself! :+1:

dnrce commented 4 years ago

I don't know if I even have $.02 here but I'll cast a vote in the other direction -- I think modifying the standard file continues to be the least surprising behavior. If I wanted to inspect a system's unattended-upgrades configuration, I would look at 50unattended-upgrades. It would be both unexpected and opaque to have this configuration live in two places with inheritance and overrides.

This issue is really a cosmetic problem (the message is N for "notice") that is not unique to the ansible case. One would get the same notice from any customization to this file, including manual ones.

FWIW apt in Ubuntu ignores ucf files since 18.04: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1645687

colans commented 4 years ago

@dnrce It's not just cosmetic. On OS upgrades, users will be asked if they should overwrite the file or leave as-is, and won't be able to continue without input. This is a barrier to automation. While, yes, it would be nice to have all configuration in the same file (that's cosmetic, I would say), it's less important (IMHO) than having fully unattended upgrades, which I believe is the goal here.

benjaoming commented 4 years ago

@dnrce it's true what @colans notes that this is not just cosmetic. See my report in #68 -- the other thing is that you note:

If I wanted to inspect a system's unattended-upgrades configuration, I would look at 50unattended-upgrades.

This is also not true. The file lives in a conf.d structure, so it would be natural to assume that all these files in /etc/apt/apt.conf.d/ are numbered for a reason and override each other according to the order that they are numbered. If this file is named 90-ansible-unattended-upgrades as is proposed in the PR description, then it would only be very very expected and not surprising that the behavior was defined there, and as a bonus the file name would give away that some ansible role placed it there :)

benjaoming commented 4 years ago

Now, the question is how to handle the transition.

It's possible to prompt users during playbook runtime: https://www.reddit.com/r/ansible/comments/cgpgpt/vars_prompt_in_a_role/eul7srs/

[ edit: vars_prompt is not the solution, need pause and prompt https://docs.ansible.com/ansible/latest/modules/pause_module.html ]

Suggestion 1 (unfinished)

  1. Check if 90-ansible-unattended-upgrades does NOT exist
  2. When it does not exist, use a prompt to ask the user of the playbook if they want to reinstall unattended-upgrades to re-instate the packaged versions of 20auto-upgrades and 50unattended-upgrades.

I don't know which dpkg-related command to use to restore the file. I have tried to run sudo apt install --reinstall -o Dpkg::Options::="--force-confask,confnew,confmiss" unattended-upgrades on a system (16.04) with the role applied. The modified files stay put... but the ucf-dist files are there.

Suggestion 2

So maybe it's fine to just look at files and copy .ucf-dist files back in place? They are there for a reason?

  1. Check if 50unattended-upgrades.ucf-dist or 20auto-upgrades.ucf-dist exist and if 90-ansible-unattended-upgrades does not exist.
  2. When the condition is satisfied, use a prompt to ask the user of the playbook if they want to reinstate the packaged versions of 20auto-upgrades and 50unattended-upgrades. In this case, we just copy back the .ucf-dist files.
jnv commented 2 years ago

I am closing this issue since this role has been deprecated. Feel free to suggest alternatives in #98.

colans commented 2 years ago

This issue has been moved to the new project @ https://github.com/hifis-net/ansible-role-unattended-upgrades/issues/10