Python is an interpreted language, so: no.
So I thought.
What would I be looking for in Apache logs? And in which one? Restarts are normally in error_log
Python is an interpreted language, so: no.
So I thought.
What would I be looking for in Apache logs? And in which one? Restarts are normally in error_log
I dunno, anything out of the ordinary.
I'd try them all ![]()
Looking now....
I found it.
I have two separate httpd services/instances running on my system:
[root@cmp-l2p-web-qa-04 wtl.d]# systemctl --type=service --state=running --no-pager | grep httpd
jbcs-httpd24-httpd.service loaded active running The Apache HTTP Server
jbcs-httpd24-wtl.service loaded active running The Apache HTTP Server
I need the certbot on the second server, jbcs-httpd24-wtl.service, but instead the first one gets restarted. That's why there were no errors in logs. All the command line parameters are specified for the "wtl" service.
How do I specify this?
I have no idea.. This is above my pay grade.. Oh wait, I'm a volunteer ![]()
LOL
Thanks for your support, and prompting. It helped!
Should I expect anyone else chime in here?
Possibly! Perhaps there are users on this Community with systemd experience (there probably are) and hopefully someone who would know how to manage two Apaches on the same host using systemd..
OK, thanks again. At least I know what's wrong - and it is already more than a half of the problem - and can start thinking about a solution. Worse comes to worse I will have to separate the servers...
Once you've managed to figure out how to reload the two separate Apaches from the command line, we probably can figure out how to fix Certbot to reload the correct one more easily.
Or, as already noted, don't use the Apache plug-in and instead use webroot validation. This means you configure Apache on your own but that seems to be already done now. Something like:
sudo certbot certonly --webroot -w /path/to/DocumentRoot -d (domain) ...
Or, just let run what you have and add a daily cron to reload (graceful) your wtl Apache. It will pickup a new cert if one was created.
You'd still need to know how to reload Apache afterwards ![]()
Sure. Should have been more verbose but mainly pointing out it is not necessary to have certbot do every bit. Might be clearer and easier to have your own script(s) augment certbot in some fashion.
Had they followed Rudy's same post #9 advice much debugging may have been avoided ![]()
Although, knowing about the second Apache earlier would have been helpful too.
True true. All roads lead to Rome ![]()
Then we'd have seen OP back again after 90 days with "Why is my renewed cert not recognised by Apache"
I'd rather debug an issue properly than use a workaround.
Actually I do not need, and do not want to reload both, only the one that is used by certbot. And by specifying the whole bunch of configuration options on the command line I thought that the correct one will be reloaded.
Re:webroot I think I tried it before and it did not work - possibly for the very same reason, two servers. Will look into it again.
You'd still need to know how to reload Apache afterwards
This is also not an issue - having been doing this for a while. It is only during certbot-introduced configuration change for authentication that I had the problem - still do. Not after receiving the new or updated certificate.
Hm, so Certbot does reload your Apache properly after receiving the certificate? Are you using a specific --deploy-hook for that? Or is it all Certbot?
No, sorry I was not clear. Since by that time the certbot process is over, I have no issues restarting the correct instance by an outside script. It is only while the certbot is running, as when it authenticates, that I cannot (or, possibly, don't know how to) utilize an external script.
Are you already using an outside script which runs Certbot? I.e., is it really only the reloading for the challenge that is the issue? If so, changing to the webroot plugin would indeed make sense. Note that you could also use a --deploy-hook to reload the appropriate Apache. A script is not really necessary.
It would probably take some Certbot hacking to get your dual-Apache stack working with the certbot-apache plugin, so although I disagree with @MikeMcQ sentiment "if OP had listened earlier, everything would have been fixed already" due to it, at the time, being a workaround (IMO), I do agree that using the webroot plugin is probably the best approach with the current knowledge.
Thanks for everyone's advice, I really feel supported here.
I will experiment with webroot. The most valuable notion is that yes, indeed, certbot does try to reload apache to re-read the configuration for authentication. It is never explicitly stated anywhere in documentation or comments, but then it should've been obvious, and the fact that it did not happen - or I did not notice it happening - was infuriating. And it seems that the reloading works in stock situations.
My configuration is highly customized, but I have a path to move forward now.
Cheers. It is probably not the last you hear from me.
Ha-ha
I manually stopped the first instance, then started the certbot, and lo and behold, it started the first instance back after making changes for authentication (correctly, in the second instance's DocumentRoot, as requested on the command line) instead of restarting the running one (wtl, second). So it means that it does not look at running processes and restarts the first PID it finds, as I thought, and does not use the configuration options that I provide on the command line either, but goes to some default configuration files folder and starts whatever if finds there.
How inconvenient... Any ideas? All it needs to do is use the command line options I provide... anything else, additional, that I can provide on the command line?
I found the problem. The apachectl that I specify on the command line refers to the only service it knows about, the one installed by default: jbcs-httpd24-httpd.service
When I created another separate service jbcs-httpd24-wtl.service by copying and renaming the default configuration files I should have copied and renamed the apachectl file, too.
So I created apachectl-wtl and changed all the references in it from jbcs-httpd24-httpd.service to jbcs-httpd24-wtl.service.
I also have to specify it on the command line (--apache-ctl /opt/rh/jbcs-httpd24/root/usr/sbin/apachectl-wtl):
/bin/certbot -vvv --apache --apache-server-root /opt/rh/jbcs-httpd24/root/etc/httpd-wtl --apache-logs-root /opt/rh/jbcs-httpd24/root/var/log/httpd-wtl --apache-challenge-location /opt/rh/jbcs-httpd24/root/etc/httpd-wtl/conf.d --apache-ctl /opt/rh/jbcs-httpd24/root/usr/sbin/apachectl-wtl --apache-bin /opt/rh/jbcs-httpd24/root/usr/sbin/httpd --force-renewal -d xxx.pmt-tiny.io
Works now.
Thanks everyone. Hopefully it will save someone else time in the future.