One of our domains is hosted through ISP Config platform. We have been using this domain through ISP for some time now without any issue. Prior to today, this domain was not set up for automatic ssl redirect. Today, I changed the settings within the control panel for that to happen. Since then, I am unable to access the domain through the Control Panel. Prior to it, it took me directly to the login page without any problem. Now, it is showing "File not found". Any assistance to resolve this issue would be appreciated.
Try accessing the domain directly in your browser, both with http and https, and see what you find. You can try a different browser or clear your cache, as old redirects can be long remembered by your browser. If you provide the actual domain name it's a lot easier for others to examine the behavior to help determine what's happening.
Thanks Jesse. Yes, I tried accessing the domain on the browser - various combinations in line with what you suggested prior to reaching out here. With regard to domain, the domain is, comedaddymummy.com. It worked with https included and with the folder path, login. Not anymore. However, other subdomains part of this domain are still functional and accessible, which suggests that clicking on the redirect to SSL button has something to do with this issue.
Redirect http to https seems not working? Have you turned it on in website Redirec tab? Try removing ssl redirect if you added them yourself in panel on in vhost file. I can not see file not found on that website, it shows the default page both http and https (and does not redirect http to https).
Thanks, Taleman. Yes, it was changed through the Control Panel, which is accessed through the comedaddymummy.com domain. I had a bk up vhost file from last month. I switched the current one with that one, but it did not work either. The domain itself appears to show the index page. But the login page was part of a folder, comedaddymummy.com/login, which is not accessible any more. Whereas, the subdomain, drive.comedaddymummy.com/ is fully functional.
See web servre access and error logs for that website when the login page is not found. May show more info on what is happening. And: if you have some website installed there, move the index.html file to some other name so you can access that website files.
If you setup comedaddymummy.com to be the IPSConfig control panel, then /login should access the ISPConfig login page (under /usr/local/ispconfig/interface/web/login/) - it sounds like you're trying to access something else at that path? I'm probably just unclear on what you're doing. What does `apachectl -S` show?
Thanks again. This is what the error file states after I tried to fix AH0058 by adding an additional ServerName line in apache2.conf file. I set the ServerName to Localhost. [Fri Jul 31 00:00:02.860099 2020] [mpm_prefork:notice] [pid 1139] AH00163: Apache/2.4.41 (Ubuntu) configured -- resuming normal operations [Fri Jul 31 00:00:02.860122 2020] [core:notice] [pid 1139] AH00094: Command line: '/usr/sbin/apache2' [Fri Jul 31 01:03:31.034190 2020] [mpm_prefork:notice] [pid 1139] AH00171: Graceful restart requested, doing restart AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message [Fri Jul 31 01:03:31.161092 2020] [mpm_prefork:notice] [pid 1139] AH00163: Apache/2.4.41 (Ubuntu) configured -- resuming normal operations [Fri Jul 31 01:03:31.161109 2020] [core:notice] [pid 1139] AH00094: Command line: '/usr/sbin/apache2'
@jesse: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message VirtualHost configuration: *:80 127.0.1.1 (/etc/apache2/sites-enabled/000-default.conf:1) ServerRoot: "/etc/apache2" Main DocumentRoot: "/var/www/html" Main ErrorLog: "/var/log/apache2/error.log" Mutex mpm-accept: using_defaults Mutex watchdog-callback: using_defaults Mutex proxy: using_defaults Mutex default: dir="/var/run/apache2/" mechanism=default PidFile: "/var/run/apache2/apache2.pid" Define: DUMP_VHOSTS Define: DUMP_RUN_CFG User: name="www-data" id=33 Group: name="www-data" id=33 Please note that this is part of lxc containers.
@jesse: the only change made today was in the Dashboard under Sites section where I selected the http to https box in the SSL tab. Otherwise, nothing else was changed. As shared before, one of the subdomains under this domain is still fully functional. It was somewhat interesting and mind-boggling to see this change, which led to the creation of this thread.
Things don't add up. You said: But that site is not defined according to `apachectl -S` output. I suppose you could have put that subdomain's files under /var/www/html and not set it up within ISPConfig as I thought you were indicating. So the next thing that doesn't add up, that output shows a single default vhost on port 80, it does not have port 443 defined at all, and there are no vhosts for the ISPConfig panel, nor any other websites (do you have any created?). Requesting comedaddymummy.com (port 80) right now I get an ISPConfig placeholder page, which would only be seen if it were setup as a website; it would not be found under /var/www/html. Plus drive.comedaddymummy.com returns different content, so it is served from a different place. Did you run that on the wrong server, maybe?
That explains it. You posted in a forum for the ISPConfig control panel, so in that context you'll receive help for sites managed by the control panel - you'll need to try Linux > Server Operation.
You claim in your new thread again that you use ISPConfig and not a LAMP system. So what's installed on your server now, ISPConfig or LAMP (which means a system without any control panel)?
We have a VPS unit where the LAMP stack is installed. ISPConfig is utilized to manage this LAMP stack.
Still not clear... do you mean you use the (old, and soon to be removed) openvz management module in ISPConfig to create a container in which you run a LAMP stack ? That doesn't make sense, because you say you use lxc containers. Probably need more details, or maybe a picture. (As noted, requesting comedaddymummy.com yesterday returned an ISPConfig website placeholder page, so at least that domain must be on an ISPConfig managed server, not LAMP.)
I guess he means that he uses an ISPConfig apache server. @SSK which tutorial did you use to install your ISPConfig server? And regarding the original problem: My guess is that he enabled the SSL redirect on a website without active SSL in ISPConfig (either no SSL enabled or no valid cert) as this will cause all requests to be redirected to the apache default page. The solution is to login to ispconfig and enable SSL plus take care that you either installed and saved a valid SSL cert on the SSL tab or that Let's encrypt is enabled and stays enabled.
@till: We have a set of lamp servers within containers which is connected to the external world through Linode VPS. In terms of tutorial or reference, it is difficult to pinpoint now as we referred to multitude of sources and built this framework over time. It has also gone through various changes over time, which makes it difficult to point out a specific reference. As you or Jesse pointed out, I also tried to look through the index and login file. Those did not change much, As shared for the Nextcloud error, we have a separate folder path similar to that one set for this domain. In this case, the content is placed within web34. I also scanned through the interface folder under ISPConfig, and could not identify any specific reason for the change. I am not certain whether this information is any more meaningful than before.
