After 10/18 webmin/virtualmin module update, multiple things seem broken with virtualhost creation

hoogs · October 22, 2019, 2:47am

First: How can I down-rev to version N-1 ? (I want to test to see if my issues actually were caused by last weekend’s webmin/virtualmin module updates.)

There seems to be something broken with setting up SSL sites after the updates. (ERR_TOO_MANY_REDIRECTS.)

Second: I just created another domain (without SSL), but Virtualmin seems to think it doesn’t exist. (All traffic for new v-host goes to the “default” domain.)

Pls help…

Dibs · October 22, 2019, 2:12pm

Look in the Apache VirtualHosts blocks for the *:80 and IP:443 lines.

https://www.virtualmin.com/comment/803214#comment-803214 should have a resolution.

hoogs · October 22, 2019, 3:40pm

@Dibs, I had previously posted this as an issue, and got a frustrating response to the effect that “Oh it can’t be anything that we broke”, when the only thing that had changed on the server was in fact the updated webmin / virtualmin modules.

It’s especially frustrating since I’m not doing anything unusual … these are plain-vanilla virtualhost configs. (There’s nothing about IP:80 / IP:443, vs. *:80 / *:443) I hadn’t touched httpd.conf until this issue showed up.

I already looked in the VirtualHost blocks, but didn’t see anything different other than (obviously) the domain / account names, and a couple of php directives. (I changed those to be identical but it didn’t fix anything.) Here’s my original extended post, with the relevant Virtualhost blocks – insights would be hugely appreciated…

https://www.virtualmin.com/comment/818489

hoogs · October 22, 2019, 3:47pm

Is there a way to back out the webmin / virtualmin module updates, down to rev N-1 ?

If I can do that, at least it would let me prove / disprove the source of the problem.

Dibs · October 22, 2019, 3:59pm

Have you tried disabling SSL for the non-working domain\s to see traffic stops going to the default domain?

hoogs · October 22, 2019, 4:17pm

Yes: https://www.virtualmin.com/comment/818496#comment-818496

There seem to be distinct issues going on but I can’t untangle them, exactly. (Again, noting that this started after the 10/18 webmin & virtualmin module updates.)

I originally had configured Virtualmin to always create an SSL site along with the standard webhost. Never had any problem with that, until after the updates.
On 10/19, created NewDomain1, and immediately started seeing ERR_TOO_MANY_REDIRECTS. I removed SSL site, and ERR_TOO_MANY_REDIRECTS went away.
On 10/21, created NewDomain2 (no SSL), and now just basic surfing to NewDomain2 sends browser to totally-unrelated DefaultDomain.
VirtualMin devs seem to prefer denying that there’s a problem, rather than looking into it, despite that these issues only showed up after 10/18 module updates.
Nobody seems to have any input for my plaintive request to back out the module updates, just to prove / disprove if they are, in fact, the source of the problems.

Does that provide any useful data? :’(

Dibs · October 22, 2019, 4:21pm

Cheers for posting that up.

In the new domain with no SSL have you created a noddy html page (hello world or something) and placed it in the public_html directory (or whatever it’s called)? Just so the site has some “content”?

There’s a few things going on possibly & I think it’s best to work through them.

Apologies - I can’t help with downgrading Virtualmin, never done it and the way I’m wired - I’d view that as a last resort (for myself) and probably beat Apache into submission at some point.

hoogs · October 22, 2019, 4:33pm

Yep. :’(

Under Construction

All web traffic goes to DefaultDomain.

I’ve removed the virtualhost for NewDomain2 and recreated it several times. Same behavior.

I’m afraid to create NewDomain3 to see what happens there. Arrgghhh… I came to VirtualMin because it had the rep of being the most stable of all the admin / configuration apps … I really don’t want to have to trash everything and rebuild with some other webhost manager just because the devs don’t want to tell me how I can simply back out these updates to do a stupid test to prove/disprove whether the 10/18 module updates are in fact the source of these issues.

Dibs · October 22, 2019, 4:38pm

can you put a php file in the public root with


<?php
phpinfo();
?>

call it say myphp.php

and then go to http://www.newDomain2.com/myphp.php and see what it does? Just to see if all content is not being recognised or just certain types.

EDIT: stop and start Apache as well (just to be sure it’s using the current config)

hoogs · October 22, 2019, 4:45pm

OK, NewDomain2/myinfo.php does get reached – yay, a small win. (sip of beer for everyone)

Now what?

Dibs · October 22, 2019, 4:50pm

I would suggest “stripping” things back to basics. Take

.htaccess, cloudfare out of the equation.

Stop & start Apache - is the sample html page still going to the default domain?

EDIT: Before stopping and starting Apache - in Virtualmin, Edit Virtual server, Enabled Features: remove everything apart from “Apache website enabled”. To strip your VirtualHosts block to the bare minimum.

hoogs · October 22, 2019, 6:04pm

OK, no .htaccess, Cloudflare proxy removed (checked via nslookup), stripped “extra” virtualmin features, and restarted Apache.

index.html perms 644

… still redirects to DefaultDomain.

D’oh! :’(

Dibs · October 22, 2019, 7:04pm

What do your Apache logs state around the time of the “click”?

Cloudfare proxy removal - is there any DNS propagation involved?

EDIT: Is the default site the 1st Apache VirtualHost?

Dibs · October 22, 2019, 7:29pm

Have you tried stripping the VirtualHosts block right down to a minimum like:



    ServerAdmin admin@NewDomain2.com
    ServerName NewDomain2.com
    ServerAlias www.NewDomain2.com
    DocumentRoot /var/www/NewDomain2/public_html
    DirectoryIndex index.html index.htm index.php index.php4 index.php5
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

then doing


sudo a2ensite NewDomain2.com.conf

then restart Apache?

In all fairness - nothing jumps out in the VirtualHost blocks you posted but I find it out that a .php file shows and a .html one doesn’t. So maybe stepping back to a very basic VirtualHost’s block and then adding sections back in might show what’s misbehaving.

adamjedgar · October 22, 2019, 8:15pm

Can you post your <Virtual Host *:443> for the new virtual server you setup that is causing the error.

Also, you mention that if you create a non ssl vhost it’s loading default site…what is your dns configuration? Are you running Bind dns or is that being hosted elsewhere?

Dibs · October 22, 2019, 8:18pm

It’s in the original post of https://www.virtualmin.com/comment/818496

Eric · October 22, 2019, 8:20pm

Just to be super sure it’s not related to an IP config issue like Dibs mentioned above, can you post the output of this command:


grep -i '<virtualhost' /etc/apache2/sites-enabled/*.conf`

That will rule out a few common issues.

Also, what is the output of this command:

dpkg -l apache2

adamjedgar · October 22, 2019, 8:24pm

I only see the port 80 Virtual host… not his SSL one (which is producing the too many redirects error)

Dibs · October 22, 2019, 8:31pm

The OP’s non-working VirtualHost

Port 80



SuexecUserGroup "#1022" "#1022"
ServerName DOMAIN_NOT_WORKING
ServerAlias www.DOMAIN_NOT_WORKING
ServerAlias mail.DOMAIN_NOT_WORKING
ServerAlias webmail.DOMAIN_NOT_WORKING
ServerAlias admin.DOMAIN_NOT_WORKING
DocumentRoot /home/ACCOUNTNAME/public_html
ErrorLog /var/log/virtualmin/DOMAIN_NOT_WORKING_error_log
CustomLog /var/log/virtualmin/DOMAIN_NOT_WORKING_access_log combined
ScriptAlias /cgi-bin/ /home/ACCOUNTNAME/cgi-bin/
ScriptAlias /awstats/ /home/ACCOUNTNAME/cgi-bin/
DirectoryIndex index.html index.htm index.php index.php4 index.php5

Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted
AddType application/x-httpd-php .php
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
AddHandler fcgid-script .php7.2
FCGIWrapper /home/ACCOUNTNAME/fcgi-bin/php7.2.fcgi .php
FCGIWrapper /home/ACCOUNTNAME/fcgi-bin/php5.fcgi .php5
FCGIWrapper /home/ACCOUNTNAME/fcgi-bin/php7.2.fcgi .php7.2


allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted

RewriteEngine on
RewriteCond %{HTTP_HOST} =webmail.DOMAIN_NOT_WORKING
RewriteRule ^(.*) https://DOMAIN_NOT_WORKING:20000/ [R]
RewriteCond %{HTTP_HOST} =admin.DOMAIN_NOT_WORKING
RewriteRule ^(.*) https://DOMAIN_NOT_WORKING:10000/ [R]
RemoveHandler .php
RemoveHandler .php5
RemoveHandler .php7.2
php_admin_value engine Off
FcgidMaxRequestLen 1073741824
RedirectMatch ^/(?!.well-known)(.*)$ https://DOMAIN_NOT_WORKING/$1

AuthName "DOMAIN_NOT_WORKING statistics"
AuthType Basic
AuthUserFile /home/ACCOUNTNAME/.awstats-htpasswd
require valid-user

Alias /dav /home/ACCOUNTNAME/public_html

DAV on
AuthType Basic
AuthName "DOMAIN_NOT_WORKING"
AuthUserFile /home/ACCOUNTNAME/etc/dav.digest.passwd
Require valid-user
ForceType text/plain
Satisfy All
RemoveHandler .php
RemoveHandler .php5
RemoveHandler .php7.2
RewriteEngine off

and his 443 host



SuexecUserGroup "#1022" "#1022"
ServerName DOMAIN_NOT_WORKING
ServerAlias www.DOMAIN_NOT_WORKING
ServerAlias mail.DOMAIN_NOT_WORKING
ServerAlias webmail.DOMAIN_NOT_WORKING
ServerAlias admin.DOMAIN_NOT_WORKING
DocumentRoot /home/ACCOUNTNAME/public_html
ErrorLog /var/log/virtualmin/DOMAIN_NOT_WORKING_error_log
CustomLog /var/log/virtualmin/DOMAIN_NOT_WORKING_access_log combined
ScriptAlias /cgi-bin/ /home/ACCOUNTNAME/cgi-bin/
ScriptAlias /awstats/ /home/ACCOUNTNAME/cgi-bin/
DirectoryIndex index.html index.htm index.php index.php4 index.php5

Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted
AddType application/x-httpd-php .php
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
AddHandler fcgid-script .php7.2
FCGIWrapper /home/ACCOUNTNAME/fcgi-bin/php7.2.fcgi .php
FCGIWrapper /home/ACCOUNTNAME/fcgi-bin/php5.fcgi .php5
FCGIWrapper /home/ACCOUNTNAME/fcgi-bin/php7.2.fcgi .php7.2


allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted

RewriteEngine on
RewriteCond %{HTTP_HOST} =webmail.DOMAIN_NOT_WORKING
RewriteRule ^(.*) https://DOMAIN_NOT_WORKING:20000/ [R]
RewriteCond %{HTTP_HOST} =admin.DOMAIN_NOT_WORKING
RewriteRule ^(.*) https://DOMAIN_NOT_WORKING:10000/ [R]
RemoveHandler .php
RemoveHandler .php5
RemoveHandler .php7.2
php_admin_value engine Off
FcgidMaxRequestLen 1073741824
SSLEngine on
SSLCertificateFile /home/ACCOUNTNAME/ssl.cert
SSLCertificateKeyFile /home/ACCOUNTNAME/ssl.key
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

AuthName "DOMAIN_NOT_WORKING statistics"
AuthType Basic
AuthUserFile /home/ACCOUNTNAME/.awstats-htpasswd
require valid-user

Alias /dav /home/ACCOUNTNAME/public_html

DAV on
AuthType Basic
AuthName "DOMAIN_NOT_WORKING"
AuthUserFile /home/ACCOUNTNAME/etc/dav.digest.passwd
Require valid-user
ForceType text/plain
Satisfy All
RemoveHandler .php
RemoveHandler .php5
RemoveHandler .php7.2
RewriteEngine off

SSLCACertificateFile /home/ACCOUNTNAME/ssl.ca

Dibs · October 22, 2019, 8:40pm

In all fairness - I think it needs stripping down to basics. Disable all confs for Apache VirtualHosts, then re-enable only the troublesome one but with a basic VirtualHosts block, restarting Apache afterwards.

Something is amiss in that he can see a .php file but not a .html file in the public root of that host.

I’d then refer to the Apache docs and add back in sections at a time. Mind you I’d be tempted to run an

apachectl configtest

command once every VirtualHost has been disabled, enable the troublesome one enable (but prior to swapping it for a basic one) and restart Apache - then do the configtest. Not expecting anything to jump out as Apache is running - but it might show something about the troublesome one. But then again, I am not sure what would happen if all VirtualHost blocks were syntactically correct with the exception of one. So if you disabled all of them expect the one - slightly more than curious what warnings\errors that would spit out.