-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Fixing: Acme script breaking during install on Ubuntu with Apache and with configured server FQDN #14527
base: master
Are you sure you want to change the base?
Fixing: Acme script breaking during install on Ubuntu with Apache and with configured server FQDN #14527
Conversation
Work in progress.
This reverts commit c675bd0.
site and disabling / re-enabling it.
No need to change this file
Hi, thanks for your contribution! |
DEFAULT_SITE_CONF="/etc/apache2/sites-enabled/000-default.conf" | ||
if [[ -f "$DEFAULT_SITE_CONF" ]]; then # Checks if the default site is enabled | ||
echo "Default Apache site may conflict with Let's Encrypt process" | ||
a2dissite 000-default.conf && ${RELOAD_CMD} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the jitsi-meet package should be touching that configuration, people maybe using it for some other stuff.
If you think that maybe a problem we should print some warning to inform the user, so the user can decide what to do.
if [[ -n "$ENABLEDEFAULT_CMD" ]]; then | ||
echo "Cleanup: Enabling default Apache site back" | ||
eval "$ENABLEDEFAULT_CMD" | ||
ENABLEDEFAULT_CMD= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum, you enable it back ... why is the 000-default.conf a problem actually?
I have a question about apache and let's encrypt does it work with default jitsi-meet config?
Something like:
? |
Or you just say that it doesn't work because the jitsi-meet cofig is still not active while running the installation? |
Looking back to confirm the answer, I started to have doubts about my earlier statement that the error depends on timing. Revisiting: Experiment 1.
Checkout the config conflict here:
In that state, Experiment 2.
This time Let's Encrypt succeeded.
Note there is no conflict:
Conclusion: It looks like an apache bug. I can not think of a reason why Apache should not resolve a configuration like that in favor of the non-default VirtualHost. If I am right classifying it as an Apache bug, I do not know what is the right way for Jitsi to respond:
If you choose to provide a fix – I tried several working ways to do it. Disabling the default host and then enabling it back seem the most gentle to me, because it does not create any persistent changes in the foreign territory. If anyone thinks of a better way – I will be interested to know. Either way, I will be happy to do a modified pull request. |
Do I understand correctly that the fact that your machine has a hostname j.myserver.com is the reason that this is added as a default domain by apache config when installing it? |
Maybe the problem is that j.myserver.com:80 is handled in two places and which one will be handling it is random, so it work or not randomly :) |
Correct. |
I also have hard time believing that Apache would miss such a glaring thing. If I did not miss anything obvious on my side, and it is indeed apache misbehaving, I would expect it to be specific to some combination of versions, platforms and environments. In my case it is Apache/2.4.52 on aarch64 ubuntu 22.04.4 running inside a parallels vm on macOS Ventura on a Mac Studio. I was able to reproduce it 3 out of 3 times. I will be setting up a fresh Intel host on Monday, will try to reproduce it there. |
During install, when:
:443
:Apache's default host responds to the "FQDN call" and default settings supersede the Jitsi VirtualHost.
As a result, Let's Encrypt challenge is served with Apache default webpage from
/var/www/html
, which does not have the/var/www/html/.well-known/...
response.Proposed solution modifies
install-letsencrypt-cert.sh
to detect this condition and disable default Apache site while Let's Encrypt process is working for the first time.Merging this will address issue #14510.