Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix apt key handling #306

Closed

Conversation

zerwes
Copy link
Contributor

@zerwes zerwes commented Jan 25, 2024

avoid warning on debian 12

W:https://artifacts.elastic.co/packages/8.x/apt/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details

@martialblog martialblog requested a review from widhalmt January 25, 2024 10:19
@widhalmt
Copy link
Member

widhalmt commented Jan 26, 2024

Hi,

Thanks so much for your contribution!

The checks fail due to idempotency tests. Could it be that there's a newer apt_key module that will put it in the right place on Ubuntu? It looks like one task is removing it and the other is putting it back again.

I manually tested the changes on a Debian 12 box. Looks good to me!

@zerwes zerwes closed this Jan 27, 2024
@zerwes
Copy link
Contributor Author

zerwes commented Jan 27, 2024

Hello @widhalmt
Oh, sorry, I have to admit: my mistake.
Usually, while managing all hosts mainly via ansible, the apt warning is hidden. I just stumbled over it while testing some things manually. And I just applied an older fix I had developed for other repositories and took the short way, yolo, and just opened the PR.
But things develop and meanwhile it seems the apt_key task is reading keys from /etc/apt/trusted.gpg.d/ too and removing them if requested ... so for surely the idempotency check will fail, as the key is removed and re-added.
Well meanwhile, the apt_key command ist deprecated in ansible too, so, while thinking about a clean solution, I stumbled over the next issue: storing keys in /etc/apt/trusted.gpg.d/ removes the apt warning, but the keys are still trusted in a global scope. The new an best way to do it is to restict the key trust just for the repo in question. The deb822_repository is available for ansible >= 2.15, so not yet ready for collections in a wider use.
SO I will close this PR and reopen another one (considering the idempotency check)
Sorry for the trouble, thank you for your hint and until the next PR targeting this issue.
Greetings
Klaus

@zerwes zerwes mentioned this pull request Jan 27, 2024
@zerwes zerwes deleted the fix-apt-key-handling branch January 30, 2024 11:58
github-merge-queue bot pushed a commit that referenced this pull request Feb 11, 2024
f/u to #306 
Refactored key and sources list for debian based distros. Use current
state of the art to include 3party repos.

 * avoid apt warning

`W:https://artifacts.elastic.co/packages/8.x/apt/dists/stable/InRelease:
Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see
the DEPRECATION section in apt-key(8) for details`
 * prepare for deb822 format:
* > Entries MUST be added in the /etc/apt/sources.list.d directory using
a shortened repository name
   * > A sources.list entry SHOULD have the signed-by option set.

see: https://wiki.debian.org/DebianRepository/UseThirdParty

PS: this time I have run the checks in question (sorry for my
carelessness in the other PR):
*
https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-collection-elasticstack/actions/runs/7677838360
*
https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-collection-elasticstack/actions/runs/7677869397
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants