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

Discussion in 'General' started by Acsilaa, Oct 2, 2023.

  1. Acsilaa

    Acsilaa New Member

    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:
    [​IMG]

    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/
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  3. Acsilaa

    Acsilaa New Member

    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
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  5. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    This should be fixed too.
    And this too.
     
  6. Acsilaa

    Acsilaa New Member

    Thank you for the notice, I will get to that too:D
     
  7. Acsilaa

    Acsilaa New Member

    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)?
     
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
    Acsilaa likes this.
  9. Acsilaa

    Acsilaa New Member

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

    Acsilaa New Member

    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!
     
    ahrasis likes this.
  11. Rimas

    Rimas New Member

    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.
     
    Acsilaa likes this.
  12. Rimas

    Rimas New Member

    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?
     
  13. AndyPL78

    AndyPL78 New Member

    The same could be used for the Nginx configuration as some sites require /public to be set
     
    Rimas likes this.
  14. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    Why and how do you suggest we do that?

    Indeed but it is there already via the directives field.
     
    Last edited: Oct 27, 2023
  15. Rimas

    Rimas New Member

    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.
    upload_2023-10-27_8-10-5.png
     
    Last edited: Oct 27, 2023
  16. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
    Last edited: Oct 27, 2023
    Th0m likes this.
  17. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    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.
     
  18. Rimas

    Rimas New Member

    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.
     
  19. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
    ahrasis likes this.
  20. Rimas

    Rimas New Member

    What do you mean?
     

Share This Page