Skip to content
This repository has been archived by the owner on Jun 25, 2023. It is now read-only.

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

Closed
jnv opened this issue Nov 21, 2016 · 12 comments
Closed

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

jnv opened this issue Nov 21, 2016 · 12 comments

Comments

@jnv
Copy link
Owner

jnv commented Nov 21, 2016

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
Copy link

veger commented Nov 21, 2016

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
Copy link
Owner Author

jnv commented Nov 21, 2016

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

@veger
Copy link

veger commented Nov 21, 2016

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

@colans
Copy link

colans commented Sep 9, 2019

@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
Copy link

colans commented Sep 9, 2019

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
Copy link

veger commented Sep 15, 2019

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

@dnrce
Copy link
Contributor

dnrce commented Jan 17, 2020

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
Copy link

colans commented Jan 20, 2020

@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
Copy link

@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
Copy link

benjaoming commented Mar 19, 2020

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.

colans added a commit to consensus-enterprises/ansible-role-unattended-upgrades that referenced this issue Jan 27, 2021
…ault_config

CONFLICT (content): Merge conflict in templates/unattended-upgrades.j2
  * Resolution: Added `ansible_controlled` header.
CONFLICT (modify/delete): templates/auto-upgrades.j2 deleted in HEAD and modified in master. Version master of templates/auto-upgrades.j2 left in tree.
  * Resolution: Deleted file again as nothing new had been added (except the `ansible_controlled` header).
@jnv
Copy link
Owner Author

jnv commented May 23, 2022

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

@colans
Copy link

colans commented Aug 16, 2022

This issue has been moved to the new project @ hifis-net/ansible-collection-toolkit#10

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants