Proposed virtual_host2_sub.conf template change

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
8,937
Hello,

We're proposing a default change to the 2 templates:
Code:
virtual_host2_sub.conf
virtual_host2_secure_sub.conf
to use the SDOCROOT token, similar to nginx and openlitespeed:
Code:
|?DOCROOT=`HOME`/domains/`DOMAIN`/public_html|
...
|CUSTOM|
|?SDOCROOT=`DOCROOT`/`SUB`|
DocumentRoot |SDOCROOT|
this would allow full subdomain overrides far easier.

We are planning on adding adding the ability to point subdomain folders to custom paths, hence the need to line up the templates across all webserver-types.

There are downsides for anyone who's using customization of |DOCROOT| in the Custom Httpd Config area in that some changes may be needed to your customization setup, hence the decision on how we should proceed.



  1. I'm proposing to move the setting of the |?SDOCROOT=..| to after the |CUSTOM| token, so if you do override the DOCROOT in the |CUSTOM| token, you'll still be able to inherit that for subdomains.
    This means the nginx/openlitespeed tokens will have that moved lower in the template, which can affect the order of things for those servers.
    This should affect Apache setups who override DOCROOT in Custom Httpd Config as little as possible, but likely not zero depending on how it was done. This could also affect nginx/OLS setups, again, depending on how they've done it.
  2. Subdomains will use private_html/sub/cgi-bin[/c] instead of public_html.
    Since the DOCROOT/SDOCROOT path can be changed, the cgi-bin folder needs to follow it. For the the change is that the |?CGI=..| path for subdomains, which used to only be in the public_html folder, will now be set to the `SDOCSROOT`/cgi-bin, wherever that is: aka: private_html/sub/cgi-bin, and no longer public_html/sub/cgi-bin. As many people use private_html -> public_html anyway, this shouldn't be an issue.
    So this may be a deciding factor on how we move forward... as anyone using https://sub.domain.com/cgi-bin/test where they do NOT have private_html->public_html would get a 404 if they don't have private_html/sub/cgi-bin/test, where it lives at public_html/sub/cgi-bin/test. I can skip the CGI change, meaning altering the subdomain path wouldn't have the cgi-bin follow it. I prefer to make the change, but needs everyone to be aware of the change, should it affect them.
    If we feel the need, we could auto-symlink cgi-bin from private_html/sub/cgi-bin to public_html/sub/cgi-bin, if the conditions are right.
    [*]We could apply the same to parent domains while we're at it: Allowing the cgi-bin path to live in the private_html, to keep things unified, but this isn't explicitly "needed" now.. but if we're making significant changes, this might be the time. We also don't want to break anyone's setup.


The webserver templates behave in such a manner that if you set |?SDOCROOT=...| in the |CUSTOM| token at Custom Httpd Config, it's loaded into the global tokens passed back to the template, so the template's setting of "|?SDOCROOT=`DOCROOT`/`SUB`|" has no effect, allowing you to override it in |CUSTOM|, before the template itself tries to set it. In short: any global token passed to template cannot be overridden with "|?". DA already uses this to set DOCROOT to ~creator/domains/suspended, preventing the template from setting it to the User's path.

----

For anyone that uses custom/virtual_host* templates, this makes no difference, so for example if you're using this guide:
https://help.directadmin.com/item.php?id=199
and you have custom copied templates, these changes won't affect you at all.

----

In any case, we're looking for any feedback or concerns you may have with this change.
I'll be testing in the pre-release area, should anyone wish to try the template changes to see how it affects them.
If needed, re-download the production binaries to revert back to the old templates.

John
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,902
Location
GMT +7.00
Hello,

We're already using SDOCROOT for Apache when we need to customize document root for subdomains. Good to know you are in the direction already. So I hope it won't break existing installations for others and we will get the native support of custom locations for subdomains.
 
Top