[SOLVED] ISPConfig setting DocRoot in Apache Directives doesn't work

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/

 

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

 

This should be fixed too.

And this too.

 

Thank you for the notice, I will get to that too

 

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)?

 

Thank you very much! I'll look into it.

 

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?

 

The same could be used for the Nginx configuration as some sites require /public to be set

 

Why and how do you suggest we do that?

Indeed but it is there already via the directives field.

 

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.

 

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.

 

What do you mean?