QA (public) » openQA Project (public)

Certificate data: o3 says: Issued On Tuesday, March 18, 2025 at 12:51:08 AM (CET?) Expires On Monday, June 16, 2025 at 1:51:07 AM
The cronjob ran at 18 Mar 2025 00:00:10 GMT

Looking into the crontab, the cronjob will run every day.
So this run must have succeeded, so maybe it is doing a retry itself already?

I see retry-after: 7 in the request header. I will look at the code again. i thought I didnt see any restart in a request function of dehydrated

Also:

/etc/dehydrated/certs/openqa.opensuse.org
-rw------- 1 dehydrated dehydrated  288 Jan 17 00:00 privkey-1737072003.pem
-rw------- 1 dehydrated dehydrated  288 Jan 17 00:08 privkey-1737072484.pem
-rw------- 1 dehydrated dehydrated  288 Mar 18 00:00 privkey-1742256003.pem
-rw------- 1 dehydrated dehydrated  288 Mar 18 00:49 privkey-1742258973.pem
lrwxrwxrwx 1 dehydrated dehydrated   22 Mar 18 00:49 privkey.pem -> privkey-1742258973.pem

So it definitely succeeded on the same day, but the second privkey file suggests that there was some kind of retry

There is an active dehydrated.service on o3. Just remove the crontab entry.

there are services in both o3 and osd.
the services files are different tho.
So i will close the PR as it doesnt seem to be of any use.
And I will try to find info about those services on the servers.

tinita wrote in #note-11:

There is an active dehydrated.service on o3. Just remove the crontab entry.

yes, I wanted to ask this. but also what should I do with the configuration of the existing services. open question is https://github.com/os-autoinst/scripts/pull/385#discussion_r2016297436

ok I deleted the crontab row in O3. and seems like someone else did the same on OSD

grepping salt-states-openqa there are some results coming up about dehydrated. checking there now

I suggested https://github.com/os-autoinst/scripts/pull/386 after the following considerations and actions (some explanation exists in the PR too).

But overall the filtering seems to not be needed as there are ways to get those, with the most direct from the dehydrated itself.
What i have done to keep notification on dehdrated errors is to modify the hook.sh.
Specifically I have editted the /etc/dehydrated/hook.sh, with the following changes

invalid_challenge() -> uncomment printf "Subject: Validation of ${DOMAIN} failed!\n\nOh noez!" | sendmail root
request_failure() -> uncomment printf "Subject: HTTP request failed failed!\n\nA http request failed with status ${STATUSCODE}!" | sendmail root
exit_hook() ->``if -n $ERROR ; then printf "Subject: dehydrated exits with error: ${ERROR}!" | sendmail root fi

I have tested it injecting _exiterr in some line and I got mail from exit_hook which looks like
From dehydrated@ariel.dmz-prg2.suse.org Fri Mar 28 09:07:21 2025
Return-Path: <dehydrated@ariel.dmz-prg2.suse.org>
X-Original-To: ybonatakis
Delivered-To: ybonatakis@ariel.dmz-prg2.suse.org
Received: by ariel.dmz-prg2.suse.org (Postfix, from userid 473)
id 1FCC319295; Fri, 28 Mar 2025 09:07:21 +0000 (UTC)
Subject: failed with error unchanged_cert hook returned with non-zero exit code!
Message-Id: <20250328090721.1FCC319295@ariel.dmz-prg2.suse.org>
Date: Fri, 28 Mar 2025 09:07:21 +0000 (UTC)
From: dehydrated <dehydrated@ariel.dmz-prg2.suse.org>

I dont really know for sure if we need the entry in exit_hook

the question is whether we want to do this also in OSD? (which I havent checked just yet).
Also I dont know what happens if the system updates.

I just want to let a reference to the link Oli shared related to osd https://gitlab.suse.de/search?search=dehydrated&nav_source=navbar&project_id=743&group_id=39&search_code=true&repository_ref=master for future ref

Oli the thing I couldnt remember in the meeting and the reason it was in feedback is because:

1. to someone check the changes in the /etc/dehydrated/hook.sh
   1.1 waiting someone to answer how do we ensure that the changes persist

2. OSD do not have those changes. Waiting for confirmation whether are needed there

1. to someone check the changes in the /etc/dehydrated/hook.sh

If dehydrated fails and if the retries are exhausted, I would assume that the systemd service is marked as failed.
And for that we would be alerted by munin.
So I think extra emails via hook.sh are not wanted.

ybonatakis wrote in #note-20:

Oli the thing I couldnt remember in the meeting and the reason it was in feedback is because:

1. to someone check the changes in the /etc/dehydrated/hook.sh 1.1 waiting someone to answer how do we ensure that the changes persist

what tinita wrote

1. OSD do not have those changes. Waiting for confirmation whether are needed there

We don't need further changes there