Proposed virtual_host2_sub.conf template change

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,158
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
 
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.
 
I'm trying to do exactly this right now. Is there any ETA on when this change would be made? The process here definitely seems too involved:

Not sure but i think it might already be done.

 
That seems like it should address it, but I have no idea how to implement it. It seems to be both a combination of template modifications/copies and httpd.conf additions.

I feel like there is a typo right at the start as DOMAIN.COM.subdomains.docroot.override seems like there should be a / after DOMAIN.COM . It is hard to evaluate without understanding more of what is going in in the templating system.
 
That seems like it should address it, but I have no idea how to implement it. It seems to be both a combination of template modifications/copies and httpd.conf additions.

I feel like there is a typo right at the start as DOMAIN.COM.subdomains.docroot.override seems like there should be a / after DOMAIN.COM . It is hard to evaluate without understanding more of what is going in in the templating system.
The change simply uses
Code:
DocumentRoot |SDOCROOT|
instead of the old
Code:
DocumentRoot |DOCROOT|/|SUB|

The override bit is correct. This is the config file that stores the info
Code:
/usr/local/directadmin/data/users/username/domains/domain.com.subdomains.docroot.override
If a given sub-domain has an override, DA will simply set it in the "SDOCROOT" token internally. This overrides what the template tries to set, so what DA set SDOCROOT to internally takes priority... thus SDOCROOT from the override file is used as the DocumentRoot in the apache VH.

John
 
The change simply uses
Code:
DocumentRoot |SDOCROOT|
instead of the old
Code:
DocumentRoot |DOCROOT|/|SUB|

The override bit is correct. This is the config file that stores the info
Code:
/usr/local/directadmin/data/users/username/domains/domain.com.subdomains.docroot.override
If a given sub-domain has an override, DA will simply set it in the "SDOCROOT" token internally. This overrides what the template tries to set, so what DA set SDOCROOT to internally takes priority... thus SDOCROOT from the override file is used as the DocumentRoot in the apache VH.

John
ah, okay. I think that's a little more clear. I missed the fact that the override was in /usr/local/... instead of /home/USER/domains/...

Is the doc here in line to get updated to reference the new technique?

 
Okay, I tried a few things and none of them seemed to work as expected. Adding the file:

Code:
/usr/local/directadmin/data/users/username/domains/domain.com.subdomains.docroot.override

Didn't seem to have any effect. I tried restarting Apache and rebuilding confs, but I didn't see anything change.

Using the SDOCROOT method moves the folder, and the proper files show up, but the files aren't being processed as PHP files, so the handler for that path isn't getting set correctly.

Ideas?

I just noticed that DocumentRoot has the right path, but the <Directory> line still points to the original domain path. The DocumentRoot and Directory lines should match, shouldn't they? This is what I see:

Code:
DocumentRoot /home/user/domains/example.com/subdomain
ScriptAlias /cgi-bin/ /home/user/domains/example.com/subdomain/cgi-bin/

<Directory /home/user/domains/example.com/private_html>
 
Last edited:
Back
Top