I'm not sure if this is a bug. It seems to be, but it may just be something I can't find reference to in any of the docs/forums.
Since I've created this setup on EC2 - I wanted the vhosts to be not be bound to the internal IP (which changes every time you launch a new instance).
In light of this, I've set Virtualmin . system Settings Virtualmin Config > Defaults for new domains > Address format for vhosts: always *.
I also have Redirect http to https by default: yes
I start off before adding any virtual servers with an httpd.conf entry something like this:
COMPARED TO #
Listen: Allows you to bind Apache to specific IP addresses and/or ports, instead of the default. See also the directive.#
Change this to Listen on specific IP addresses as shown below to prevent Apache from glomming onto all bound IP addresses.#
Listen 12.34.56.78:80Listen 80
I start adding vhosts, setting the hostname, adding Let's encrypt certificates, and all the normal things to get virtualmin going, and somewhere along the way it ends up changing that Listen directive to:
#
Listen: Allows you to bind Apache to specific IP addresses and/or ports, instead of the default. See also the directive.#
Change this to Listen on specific IP addresses as shown below to prevent Apache from glomming onto all bound IP addresses.#
Listen 12.34.56.78:80Listen 80 Listen :443
I've been logging and diffing httpd.conf files for 2 days now - adding, removing, re-adding virtual hosts. re-launching EC2 instances from AMis, updating the incorrect IPaddress that happens when launching a new instance from an image. And for the life of me, I can't figure out where/how that Listen :443 entry is getting added in along the way.
Since I have the virtualmin config set to set to always use * for new domains, I can't see how that would be the cause, and all of the vhosts that get created are all named entries (not bound to any IP).
I'm honestly not sure if I'm reporting a bug here, or if I'm just missing something in either the webmin config, virtualmin config, or SSL/Let's encrypt config that is causing this Listen entry.
The net result ends up being that on port 80, whatever virtual server is set as the default for unknown (such as IP access) get's directed to whatever virtual server I have set as the default, but any https request to the server (say via the IP, or serer hostname ends up loading the /var/www/html directory and throwing certificate errors.
If this is not a bug, I'm very sorry for reporting it here. Maybe things are working as designed, and I just haven't found the setting or documentation that points to the cause of this. But in the end, the crux of the issue is the private IP for the instance changes any time it's re-launched. So - the end goal is to have everything be named virtual hosts. And whatever magic combination is going on here leaves me with http:// or getting redirected automaticly to https:// and then throwing a cert error. And if I disable the setting to serve SSL by default, then I end up with http:// or properly loading the virtualhost I have set as the default, and any https:// or address load /var/www/html.
P.S. I'm happy to continue debugging this, and finding exactly what's going wrong and where. But any help to point me in the direction of what is adding that new "Listen" directive to the httpd.conf is greatly appreciated. I've just had no luck using debug mode or even manually diffing the httpd.conf file each step of the way (possible from burnout logging far too many hours this week)
Thanks.
Comments
Submitted by andreychek on Sat, 06/17/2017 - 09:18 Comment #1
Howdy -- it sounds like the issue you're seeing, is that when adding a new domain with SSL enabled, it's adding a "Listen x.x.x.x:443" to your Apache config?
And you want that to be a "Listen *:443" instead?
Is there perhaps another x.x.x.x:443 directive in the APache config now?
For example, what is the output of the command "grep -i virtualhost /etc/httpd/conf/httpd.conf"?
Submitted by h2ojunkie on Sat, 06/17/2017 - 15:25 Comment #2
I've wiped this, and rebuilt it so many times trying to find what combination of settings is triggering it, that right now I don't have a conf file with the issue present to share. I'll reply back when I replicate it. Not sure if it's in any way related, but I did notice I've run into some combination of settings, virtual servers and SSL certs that end up leaving behind the ssl.conf.lock after I add a let's encrypt cert to the virtual server that is set to be the default virtual server. At some point after that, I ended up with the IP bound 443 entry - I just need to re-trace my steps again and diff the files each step of the way in more detail to find out.
So far I know this much. 1) start clean (no virtual servers) 2) create the first virtual server 3) set hostname of server to same domain of that first virtual server (which will remain the default for the server) - it doesn't have to be that way. it just happens that was the order i was going in 4) add let's encrypt cert to the virtual server (this is the point when the ssl.conf.lock file ends up created)
some point after this, while adding other virtual servers is when the IP bound Listen entry ended up in the config. I just have to go click happy, diffing ever step of the way until i find out where/how that ended up in there.
Submitted by h2ojunkie on Tue, 06/20/2017 - 01:51 Comment #3
I tried all weekend, and no matter what I did I could not reproduce the combination of settings, SSL certs, virtual servers, etc to get that entry to appear in the httpd.conf file again.
Somewhere, there's some combination of settings that inserted that Listen entry to be added and bound to the internal IP....but for the life of me I just can't reproduce it. I've enabled full webmin debug logging, and I'm just going to forge ahead for now and if it appears again I'll retrace the debug logs and report back what caused it. Sadly, I didn't have the detailed logging enabled at the time it happened. (won't make that mistake again).
Submitted by andreychek on Tue, 06/20/2017 - 09:27 Comment #4
Thanks for the update!
Just to clarify -- are things working okay for you at the moment?
It sounds like you're having trouble reproducing the problem, which may mean that it's working properly for you currently?
Submitted by h2ojunkie on Tue, 06/20/2017 - 14:13 Comment #5
I seem to have it working for the most part. The only thing I haven't figured out yet isn't a huge deal. The only issue I have left is redirecting the https hostname to the default virtual server. It was when I was trying to adjust settings to fix this when I originally triggered that Listen directive. Basically: http:// or http:// both redirect to the first (default) virtual server as expected.
https:// or https:// don't redirect - and just load the /var/www/html directory.
That's what I was trying to fix when I hit some combination of settings and SSL certificates that resulted in the unexpected Listen entry. So - in reality the virtual servers are all working just fine. The only thing I ended up left with is /var/www/html loading for https:// or https://. So, it's mostly a non-issue. Anyone that happens to try and access the hostname or IP address directly just get's nothing (empty directory index).
Submitted by andreychek on Tue, 06/20/2017 - 15:31 Comment #6
Hmm, what if you set a different domain as the default domain for the IP address?
For example, if you go into Server Configuration -> Website Options, you can set that particular domain as the default.
Does that cause it to be loaded, in place of what's in /var/www/html?
Submitted by h2ojunkie on Tue, 06/20/2017 - 22:21 Comment #7
I'm stuck for a couple days. Too much testing (while forgetting to hit the "test" mode on Let's Encrypt. So I got sent to the corner for 7 days...lol.
I'll reply back as soon as I have a minute to fire up a new temporary instance, and do as you suggested with a different domain for the hostname.
Submitted by h2ojunkie on Wed, 06/21/2017 - 03:07 Comment #8
I posted a question in the Virtualmin forum, but I think it's stuck waiting moderators approval. I was wondering if I could make a donation or buy a support package for a little advice on that topic?
I've got to migrate a few hundred thousand images and 200gb of databases by the end of the month. Id be happy to buy a support plan or make a donation for a touch of advice on that subject. If I get it done it saves my me paying another month of double hosting fees at my old Colo and my new aws setup. Considering just moving the files and dbs are a 10 hour project each time, I really don't have enough time left to move than one last test run,
Submitted by h2ojunkie on Wed, 06/21/2017 - 03:08 Comment #8
I posted a question in the Virtualmin forum, but I think it's stuck waiting moderators approval. I was wondering if I could make a donation or buy a support package for a little advice on that topic?
I've got to migrate a few hundred thousand images and 200gb of databases by the end of the month. Id be happy to buy a support plan or make a donation for a touch of advice on that subject. If I get it done it saves my me paying another month of double hosting fees at my old Colo and my new aws setup. Considering just moving the files and dbs are a 10 hour project each time, I really don't have enough time left to move than one last test run,
Submitted by andreychek on Wed, 06/21/2017 - 08:54 Comment #9
Do you have a link to your Forum question? Is it this one here:
https://www.virtualmin.com/node/52592
If so, that's Joe lending a hand, he's one of the folks who works for Virtualmin.
If that's not what you're referring to, do you happen to have a link to the topic in question? I don't believe we have any moderation setup currently though, so in theory it shouldn't be hung up anywhere.