Closed dafyddj closed 9 months ago
Betting Debian 12 too will have issues, currently doing https://github.com/saltstack/salt-bootstrap/issues/1940, and will fix Debian 11 & 12, probably ought to add support for Ubuntu 24.04 given that will be here so soon
closing this in favor of #1940, since it is getting added under that PR, along with massive cleanup
Out of curiosity, why was this closed and merged into #1940? That seems to be a different issue with a much wider scope; this is more of an issue where the two lines of link changes here caused a regression by updating the legacy repository installation codepath with links to the new, incompatible onedir
release hierarchy.
http://repo.saltproject.io/py3/debian/11/amd64/latest/salt-archive-keyring.gpg
http://repo.saltproject.io/salt/py3/debian/11/amd64/SALT-PROJECT-GPG-PUBKEY-2023.gpg
http://repo.saltproject.io/py3/debian11/amd64/latest/SALT-PROJECT-GPG-PUBKEY-2023.gpg
Subsequently, the release of v2024.04.03 has broken all Debian 11 VM provisioning at my workplace, since it's now what Vagrant's salt provisioner pulls by default (also Debian 10, looks like... but that's our fault for still being on versions that old :wink:).
Was surprised to see those novel failed tests were just kind of ignored... Furthermore, the PR itself also changed code that doesn't seem like it could have even been the culprit of the quoted issue, since __install_saltstack_debian_repository
was updated instead of __install_saltstack_debian_onedir_repository
, and the former has no ability to generate the problematic https://repo.saltproject.io/salt/py3/debian/12/amd64/latest/salt-archive-keyring.gpg
link without a custom repo URL being passed in with -R
.
What seems more likely is that the latter function attempts to download from legacy before trying the onedir repository. The PR submitter never actually demonstrated anywhere that their bootstrapping failed. In fact, right after the error line in their terminal we see "Hit: ...", indicating that execution continued into the fallback where the SALT-PROJECT-GPG-PUBKEY-2023.gpg
filename is tried instead. And looking at this issue we can see exactly that, resulting in a successful bootstrapping. The only "issue" here is that the script should more clearly explain that it's a soft failure and it's moving on to a different method OR send that initial command's STDERR to the void.
Would it be possible to re-open this ticket and work on an expedited fix? I'd be happy to submit a PR if it would speed things up. It seems like the original PR just needs to be reverted, full-stop. If my hunch above is correct, it caused a regression and fixed nothing. Let me know if I'm sorely mistaken.
Sorry for the long post, @dmurphy18, I hope you enjoy your upcoming vacation! From that huge PR I can see you certainly deserve it! :laughing:
EDIT: Submitted a revert PR!
@dafyddj Will be across the Irish Sea, so soon, Dublin, bye Utah - thanks for the wishes on vacation. The problem here is
Doesn't Work: http://repo.saltproject.io/py3/debian11/amd64/latest/SALT-PROJECT-GPG-PUBKEY-2023.gpg
http://repo.saltproject.io/py3 implies classic packaging which uses the SHA-1 key, and not the SALT-PROJECT-GPG-PUBKEY-2023.gpg SHA-256 key.
Bootstrap, once I dug into it, was a rats-nest and mess, hence the large amount of re-work and removal of kitchen-salt (why ruby based stuff with a python house :( ), Kitchen-salt is no longer supported (at least by Salt team), was a pet project from a previous team member back in 2017.
So closed, because wrong and classic packaging is not longer supported, and massive cleanup being done.
Description of Issue/Question
Problem seems related to https://github.com/saltstack/salt-bootstrap/pull/1983
Setup
(Please provide relevant configs (Be sure to remove sensitive info).)
Building a Docker image starting from
debian:11
Steps to Reproduce Issue
(Include debug logs if possible,
bootstrap-salt.sh -D
.)See https://gitlab.com/dafyddj/salt-image-builder/-/jobs/6084961965
Versions and Systems
(
salt --versions-report
,bootstrap-salt.sh -v
, system type and version, cloud/VM provider as appropriate.)