@Jean-Francois I was able to reproduce your error on a Foreman 3.9/Katello 3.11 instance, but then I was able to fix it with a small change to the command I ran, can you try your command as I described in this comment?
Hi,
So I was finally able to create the signing service. Thanks for fixing this.
Now I’m trying to use it with my repository. But I don’t have the “pulp deb” command. Did I miss something ?
If you are using Katello, and there is a signing service named katello_deb_sign in Pulp, then Katello will automatically use it for all future publish actions. So for example, the next time you sync a repo with some new content, and create a new content view version from it, it should be signed. You can test this by creating a small new repo, sync it and look at the link under “Published At” on the repo page.
For existing content views and lifecycle environments you can run Katello’s “republish repository metadata” feature. One way to do this is via Hammer, the following may help:
hammer content-view version republish-repositories --help
Does that answer the question?
And if I don’t use content-views and lifecycles for Ubuntu ?
In that case you can just go to the repository page for the repo in question and select “Republish Repository Metadata” from the drop down “Select Action” menu in the top right. Once the so triggered task has completed, the published repository should be signed. This can also be done via hammer, see:
hammer repository republish --help
When I’m running apt-update from a client, I still get the message :
E: The repository ‘https://path_of_the_repo default Release’ is not signed.
Have you tried creating an entirely new repository and checking if the published repository is signed?
For example, I have just created and synced the following test repo:
If I now open the “Published At” link, and navigate to the /dists/bookworm/ folder I see the following:
The existence of the InRelease and Release.gpg file at this location tells me my signing service was used.
If you don’t have these files for a newly created repo, then your signing service is not being used.
If newly created repos are signed, you can next check the specific repositories your APT hosts are complaining about (In your example https://path_of_the_repo). Navigate to the dists/default/ folder within the repo and look for InRelease and/or Release.gpg files. If those are missing, you have not re-published that publication since adding your signing service.
I think my problem is in the sign_deb_release.sh script.
I used the one from there Signing Service Creation — Pulp deb Support 3.1.1 documentation
but I probably should adapt RELEASE_FILE and OUTPUT_DIR ?
If the signing service is used, and there is a problem with your script, I would expect your Katello sync to fail, so I don’t think the script is the problem. The one you linked to should be fine.
If you want to compare with the one from my working test system see here:
[root@katello ~]# pulp signing-service list
[
{
"pulp_href": "/pulp/api/v3/signing-services/018dc2bd-5663-7506-9de1-59d094e22c0b/",
"pulp_created": "2024-02-19T19:00:04.967494Z",
"name": "katello_deb_sign",
"public_key": "REDACTED",
"pubkey_fingerprint": "MUST_MATCH_THE_FINGERPRINT_USED_IN_THE_SCRIPT",
"script": "/opt/orcharhino/apt_signing_service.sh"
}
]
[root@katello ~]# cat /opt/orcharhino/apt_signing_service.sh
#!/bin/bash
set -eu
# Internal params:
OUTPUT_DIR="$(/usr/bin/mktemp -d)"
DETACHED_SIGNATURE_PATH="${OUTPUT_DIR}/Release.gpg"
INLINE_SIGNATURE_PATH="${OUTPUT_DIR}/InRelease"
# Passed in from Pulp:
RELEASE_FILE="$(/usr/bin/readlink -f "$1")"
# Fingerprint must match the one from the signing service:
FINGERPRINT="INSERT_YOUR_KEY_FINGERPRINT_HERE!"
COMMON_GPG_OPTS=(--batch --armor --digest-algo SHA256)
# Create a detached signature
/usr/bin/gpg "${COMMON_GPG_OPTS[@]}" \
--detach-sign \
--output "${DETACHED_SIGNATURE_PATH}" \
--local-user "${FINGERPRINT}" \
"${RELEASE_FILE}"
# Create an inline signature
/usr/bin/gpg "${COMMON_GPG_OPTS[@]}" \
--clearsign \
--output "${INLINE_SIGNATURE_PATH}" \
--local-user "${FINGERPRINT}" \
"${RELEASE_FILE}"
echo "{ \
\"signatures\": { \
\"inline\": \"${INLINE_SIGNATURE_PATH}\", \
\"detached\": \"${DETACHED_SIGNATURE_PATH}\" \
} \
}"
1 Like
Thanks. My script is ok.
My signing-service is OK too.
When I republish the repo, it creates a tmp/anumber@my hostname directory in /var/lib/pulp, and that’s all.
As user pulp (with su - pulp -s /bin/bash) :
gpg --detach-sign --output “$(/usr/bin/mktemp -d)/Release.gpg” --local-user “MY_KEY_FINGERPRINT” testfile
gpg: signing failed: Permission denied
gpg: signing failed: Permission denied
As root :
chown pulp /dev/pts/1
Then as user pulp the first command works fine. The system ask me the pass for the key and then create this file :
/tmp/tmp.6KZ6w8d8Ej/Release.gpg
Do you think this behaviour is ok ?
I found this in log files :
[27/Feb/2024:15:13:51 +0100] “GET /pulp/api/v3/signing-services/?name=katello_deb_sign HTTP/1.1” 200 52 “-” “OpenAPI-Generator/3.28.11/ruby”
but :
pulp signing-service list --field=name
[
{
“name”: “ubuntu”
}
]
not katello_deb_sign.
Got it !
I recreate a signing-service named “katello_deb_sign” with the same specs and it works.
So I remove my other signing service with
PULP_SETTINGS=/etc/pulp/settings.py pulpcore-manager remove-signing-service --class deb:AptReleaseSigningService ubuntu
And everything seems OK now.
Thanks for your help.
JF
Hi,
It worked once, but I still have problem with this now. I think the problem is because of the password of the GPG key. Can you tell me if it is a problem ?
Because I’ve seen that if I request to sign a file manually, then it ask for password. This works only if pulp user is the owner of the tty. So, the process is :
- login root
- sudo - pulp -s /bin/bash
- as root : chown pulp /dev/pts/
- as pulp : gpg --detach-sign --output “$(/usr/bin/mktemp -d)/Release.gpg” --local-user “MY_KEY_FINGERPRINT” testfile
- as root : hammer repository republish --id 223
And it works… But if i wait a bit, it does’nt anymore.
So is it a problem of the GPG key password of something else ?
Regards
JF
The feature is dependent on the call to the signing script creating the signed files, which can only happen if that script has access to the key at the time of the call. So, yes, I assume your problem is that the script asks for a password instead of creating the signed files.
There is currently no feature for Pulp to pass any kind of password/secret to the script.
You could consider creating a feature request here: Issues · pulp/pulpcore · GitHub
Ok thanks.
I can live with a key with no password.
But I don’t understand why the Release and Release.gpg files presents on the original Ubuntu repository are not downloaded during synchronization process, like it is with apt-mirror/deb-mirror apps.
Regards,
JF
This would be the equivalent of “full mirror” sync mode for yum content. This is not currently implemented for APT content. For technical reasons, we first need to finish with “structured APT for Katello” before we can consider placing a full mirror mode on the roadmap.
In short: This feature may happen one day, but there is currently no ETA, it is some ways off.
1 Like
Having re-read this old thread, I can say apt list --upgradable with subscription-manager will only work once the “structured APT for Katello” story is done.
Sorry, the error msg is the same but the situation is not, because I don’t use subscription-manager with ubuntu. I have a source.list file with the repository configured.
Broot@linuxform3:~# apt update
…
Ign :2 https://MYSERVER/pulp/content/XXX/Library/custom/Ubuntu jammy InRelease
Ign :3 https://MYSERVER/pulp/content/XXX/Library/custom/Ubuntu jammy-updates InRelease
Atteint :4 http://MYSERVER/pulp/content/XXX/Library/custom/Mozilla_Ubuntu-Debian/Mozilla_Ubuntu-Debian jammy InRelease
Ign :5 https://MYSERVER/pulp/content/XXX/Library/custom/Ubuntu jammy-security InRelease
Err :6 https://MYSERVER/pulp/content/XXX/Library/custom/Ubuntu jammy Release
404 Not Found [IP : … 443]
Err :7 https://MYSERVER/pulp/content/XXX/Library/custom/Ubuntu jammy-updates Release
404 Not Found [IP : … 443]
Err :8 https://MYSERVER/pulp/content/CEA/Library/custom/Ubuntu jammy-security Release
404 Not Found [IP : … 443]
lockquote
All the URL referenced here are OK, and the Release files exists (and are signed) .
But the solution is probably the same.