Hey everyone! I have aproblem that is quite unusual to me, since all this time I have used ISPConfig it was never an issue. When I set the DocumentRoot for a domain as the following: The folder is correct, and I know that because it has worked before. When I save the settings and go to check domain.tld after uploading the correct files, I get the default message: But when I use domain.tld/[foldername above]/public it shows what I want the DocRoot to show, meaning the file IS there and is readable. What am I doing wrong? Here are the general informations about the server that all of this is running on: PHP: Code: PHP 7.4.33 (cli) (built: Sep 4 2023 08:15:35) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies OS: Code: No LSB modules are available. Distributor ID: Raspbian Description: Raspbian GNU/Linux 10 (buster) Release: 10 Codename: buster The big scary logfile: Code: ##### SERVER ##### IP-address (as per hostname): ***.***.***.*** [WARN] could not determine server's ip address by ifconfig [INFO] OS version is Raspbian GNU/Linux 10 (buster) [INFO] uptime: 19:21:34 up 16 min, 1 user, load average: 0.17, 0.44, 0.58 [INFO] memory: total used free shared buff/cache available Mem: 3.7Gi 1.5Gi 1.4Gi 17Mi 880Mi 2.1Gi Swap: 99Mi 0B 99Mi [INFO] systemd failed services status: 0 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. [INFO] ISPConfig is installed. ##### ISPCONFIG ##### ISPConfig version is 3.2.11 ##### VERSION CHECK ##### [INFO] php (cli) version is 7.4.33 [INFO] php-cgi (used for cgi php in default vhost!) is version 7.3.33 ##### PORT CHECK ##### ##### MAIL SERVER CHECK ##### ##### RUNNING SERVER PROCESSES ##### [INFO] I found the following web server(s): Apache 2 (PID 31128) [INFO] I found the following mail server(s): Postfix (PID 1346) [INFO] I found the following pop3 server(s): Dovecot (PID 748) [INFO] I found the following imap server(s): Dovecot (PID 748) [INFO] I found the following ftp server(s): PureFTP (PID 1101) ##### LISTENING PORTS ##### (only () Local (Address) [anywhere]:465 (1346/master) [anywhere]:21 (1101/pure-ftpd) ***.***.***.***:53 (736/named) [localhost]:53 (736/named) [anywhere]:22 (778/sshd) [anywhere]:25 (1346/master) [localhost]:953 (736/named) [anywhere]:993 (748/dovecot) [anywhere]:995 (748/dovecot) [localhost]:10024 (1479/amavisd-new) [localhost]:10025 (1346/master) [localhost]:10026 (1479/amavisd-new) [localhost]:10027 (1346/master) [anywhere]:587 (1346/master) [localhost]:11211 (734/memcached) [anywhere]:110 (748/dovecot) [anywhere]:143 (748/dovecot) *:*:*:*::*:8080 (31128/apache2) *:*:*:*::*:80 (31128/apache2) *:*:*:*::*:8081 (31128/apache2) *:*:*:*::*:465 (1346/master) *:*:*:*::*:21 (1101/pure-ftpd) *:*:*:*::*:53 (736/named) *:*:*:*::*:22 (778/sshd) *:*:*:*::*:25 (1346/master) *:*:*:*::*:953 (736/named) *:*:*:*::*:443 (31128/apache2) *:*:*:*::*:993 (748/dovecot) *:*:*:*::*:995 (748/dovecot) *:*:*:*::*:10023 (530/postgrey) *:*:*:*::*:10024 (1479/amavisd-new) *:*:*:*::*:10026 (1479/amavisd-new) *:*:*:*::*:3306 (877/mysqld) *:*:*:*::*:587 (1346/master) [localhost]10 (748/dovecot) [localhost]43 (748/dovecot) ##### IPTABLES ##### Chain INPUT (policy ACCEPT) target prot opt source destination f2b-sshd tcp -- [anywhere]/0 [anywhere]/0 multiport dports 22 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-sshd (1 references) target prot opt source destination REJECT all -- ***.***.***.*** [anywhere]/0 reject-with icmp-port-unreachable RETURN all -- [anywhere]/0 [anywhere]/0 ##### LET'S ENCRYPT ##### [WARN] You have both certbot and acme.sh installed. This can lead to problems. Certbot: /usr/bin/letsencrypt acme.sh: /root/.acme.sh/acme.sh The server is running on a Raspberry Pi 4, and I followed this tutorial to set it up: howtoforge.com/perfect-server-debian-10-buster-apache-bind-dovecot-ispconfig-3-1/
Either the folder name you used is wrong, or Apache did not accept the change (or another custom setting you made) and the vhost was therefore written with .err file ending in the apache sites-available folder to avoid that you loose access to ISPConfig GUI and other websites.
Hi, Till! Thank you for replying. There has been no changes made outside of ISPConfig, and there are no vhost files ending with .err. What else can I do? Once I tried changing it manually in the vhost files (not this server install, but I was trying to fix the same issue), but that gives an HTTP ERROR 500
Check the vhost file, it must contain a second DocumentRoot line with your new path toward the end. This second line overrides the first one. Do not manually edit vhost files created by ISPConfig. You can find the reason for a 500 error in the error.log of the website.
I checked and it isn't there. Should it be? It worked for me a few months before, why is it doing this now? Should I reinstall the whole server (again)?
See read before posting "ISPConfig not writing changes to sisk" on how to find out why your system stopped writing changes to disk: https://forum.howtoforge.com/threads/please-read-before-posting.58408/ The likely reason for your issue is that you changed something on your system which now causes the system to fail. No, why would you want to do that? You simply have to track down the problem, find out what you changed that causes this now and undo that change. That#s all.
It is solved somehow. All I did was reinstall and reconfigure ISPConfig, resinstall Certbot, and update php-cgi. It was most likely the php-cgi, since I did already do the 2 steps mentioned before that and it made no difference. Thanks for all the help!
Hi, I had a similar problem that the customized DocumentRoot did not appear in vhost config. In my case, this apparently happened because you can't have both a custom Apache config snippet and a predefined one on the same vhost, and if you configure both, only the predefined snippet is used. I wonder if this is by design.
It would be great if a customized webroot could be enabled without resorting to adding custom Apache Directives. @till, would you consider this as a feature request?
I already explained the "why" part, and I'm sure you know why, but if you want me to say it explicitly, here it goes: modern PHP frameworks (Symfony, Yii and Laravel, to name a few) tend to place only a single entry PHP file (index.php) and static assets in a publicly accessible directory, while placing all other PHP files in a separate non-public directory. This practice helps reduce possible attack vectors by preventing unauthorized direct access to PHP files which are only supposed to be included and not called directly. Additionally, in case of server misconfiguration, it prevents exposing sensitive data to the visitors, such as database credentials, if, for example, you somehow accidentally disable PHP on a PHP-based website and your scripts become effectively open-source for a while. As a sidenote, I would love if WordPress employed this practice too. I had to clean up a hacked WP website yesterday, and with pretty much anything and everything in WordPress being publicly accessible, this wasn't easy. This actually almost works even now (with web/ being only one subdirectory in a vhost directory structure), but only almost, because 1. ISPconfig enforces a certain directory structure (e.g. your public dir is always web/ and can't be called not public/), and 2. not all directories within said vhost directory structure are writable to the vhost user (notably, /var/www/clients/clientX/webY/ itself isn't) . Then again, even if these two points weren't true, it's probably not a very good idea to mix ISPConfig-managed directories with webapp-managed ones. Now, regarding the "how", that's easy. There's already a 'Document Root' label (which in fact does not indicate document root) in the website's Domain tab. It could be changed into an editable field, or a new one could be added below it.
You can configure the docroot on Nginx servers as well in ISPConfig using Nginx directives field. The problem with a configurable docroot is not to add a field for it, the problem is that it imposes quite a few security issues for your server and other clients when clients are allowed to choose a folder that they can change or even remove themself. And thats's why we have not implemented such a function, but I know that some cms and frameworks like to have access to folders outside of the docroot now and are not flexible enough to use the private folder for that, so we might add such a feature as a configurable docroot in future, but admins must be aware that they take their systems at risk with enabling it then. E.g. it might even be enough to take all sites and ISPConfig UI down on a system when the customer removes this custom docroot folder, which he can do as this folder is owned by his user and must be in a folder that is writable by his user to allow the upload of other components of the framework and there are other potential issues which are even worse than bringing down the whole web server.
That is what the directives are meant for and doing now in either apache2 or nginx, and they are working fine so far. Adding it up as you suggested, on the other hand, though seems fine to me if security issues as said above can be overcome, but will surely require some extra work on the part of the developers, and unless you or others are willing to contribute to that, I don't see why the default need to be upgraded to such a feature.
I suppose ISPConfig could 1. automatically prefix the value of that field with the current docroot (/var/www/clients/clientX/webY), 2. impose some restrictions on what that field would be allowed to contain (e.g. no ../ components, or it could even be limited to just letters), and 3. create the directory automatically if it doesn't exist when the vhost is being saved. This of course wouldn't make the setup 100% bulletproof/foolproof, but would make it good enough, I think. Additionally, this whole functionality could be made toggleable somewhere in admin settings and/or dependable on the user role, so that e.g. if you're dealing with resellers, you could disallow them and their customers to edit this field, but you could have more freedom if you're using ISPConfig to conveniently manage a single server or two within an organization and you know what you're doing. It can also be solved via config snippets, but I do think this is becoming common enough to deserve a prefabricated solution. Especially considering how config snippets may not be combined with each other or with custom directives.
This is obvious that but it will not prevent any of the issues I mentioned. This won't help as well because the risk is not that someone enters a path in ISPConfig, the risk is that a website uses this path. So even if you would allow just Resellers to enter a custom path, any user of a website would be able to exploit it, there not even access to ISPConfig required for that. If you use a custom docroot, then you must know that you have put your server at risk. And the risk is not on the input side of the path in ISPConfig. That#s why this option is available via apache directives only, so any admin must be aware of the risks he has taken for his server when he does such manual configs.
