1.710 domain-level custom httpd |?DOCROOT=| now silently overrides per-subdomain document roots — please add a check like create-subdomain-www-aliases

[castris]

Hi,

After updating to 1.710/1.711 and the subsequent config rewrite, every subdomain of some domains started serving the parent domain's application. Nothing was edited by hand; it took us a while to find the cause, so I'm sharing it here and asking for a safeguard.

Setup (all native DirectAdmin mechanisms):

• nginx + Apache reverse proxy (nginx_apache).
• Domain example.com has a Custom HTTPD Configuration (Apache) with a single line, the usual Laravel /public pattern:
  

  |?DOCROOT=`HOME`/domains/example.com/public_html/public|

• Its subdomains have their own document root set from the panel (the per-subdomain document root override, stored in example.com.subdomains.docroot.override), e.g. sub.example.com -> /domains/sub.example.com/public_html/public.

Before 1.710: each subdomain's Apache VirtualHost used its own document root from the panel setting. This had worked for over a year.

After 1.710: the 1.710 changelog says:

The DOCROOT token will be used for both domains and subdomains. Previous releases used the SDOCROOT token for subdomain document root.

The stock virtual_host2_sub.conf / virtual_host2_secure_sub.conf now have DocumentRoot "|DOCROOT|" after |CUSTOM|, so the domain-level |?DOCROOT=| overrides the panel's per-subdomain document root. Result for every subdomain:

<VirtualHost x.x.x.x:8081 127.0.0.1:8081 >
    ServerName sub.example.com
    DocumentRoot "/home/user/domains/example.com/public_html/public"   <- parent's docroot

nginx still had the correct per-subdomain root, so static files looked fine while PHP (proxied to Apache) ran the parent's app. Nothing logged an error, and the panel still shows the correct document root for each subdomain.

Scale: a sweep across our fleet found 10 affected domains (21 subdomains) on 2 servers, plus around 50 domains carrying the same unconditional |?DOCROOT=| that will break as soon as someone adds a subdomain to them.

Fix we applied (from your own docs, https://docs.directadmin.com/webservices/apache/customizing.html):

|*if !SUB|
|?DOCROOT=`HOME`/domains/example.com/public_html/public|
|*endif|

What I'd like to ask:

1. I know the docs already said a domain-level |?DOCROOT=| applies to subdomains too. In practice, though, a panel-native per-subdomain document root used to win, and now it silently loses. A setting the user made in the panel UI being overridden without any warning is what hurts here.
2. For the www. subdomain alias change in the same release you shipped create-subdomain-www-aliases (check + fix). Could you add the same kind of maintenance check for this one? It would list domains whose custom httpd/nginx config sets DOCROOT without |*if !SUB| while they have subdomains, or have subdomains with a document root override, and optionally wrap the line automatically.
3. Even a warning in the "Custom HTTPD Configurations" page when |?DOCROOT=| is used without !SUB on a domain with subdomains would prevent this.

Thanks.

 

[zEitEr]

Hello,

I don't like these changes either. Already posted some thoughts about it. Sure you already found the changelog:

Related: https://docs.directadmin.com/changelog/version-1.710.html-all-web-server-templates-use-docroot-token

Core changes:

• The DOCROOT token will be used for both domains and subdomains. Previous releases used the SDOCROOT token for subdomain document root.

Special care should be taken if the token DOCROOT is being changed in the CUSTOM[N] sections. It is still possible to change the document root by changing this token value. However, since subdomains are now using the token DOCROOT instead of SDOCROOT, a customised main document root can leak into the subdomain configuration.

 

[castris]

Thanks zEitEr, good to know I'm not the only one.

Yes, I read that changelog note. My point is that it is written for people changing the DOCROOT token from now on. The configs that broke were written years ago, when |?DOCROOT=| only affected the main domain because subdomains used SDOCROOT. They were correct then, and the upgrade changed their meaning without touching them. Nothing broke at upgrade time either: it broke later, the next time the account's httpd.conf was regenerated, and with nginx in front everything looked fine except the content.

That is exactly the situation the www-aliases change was in, and that one got a maintenance task (create-subdomain-www-aliases check/fix). This one deserves the same: a check that lists domains whose custom httpd sets DOCROOT outside |*if !SUB| and that have subdomains.

Until then, in case it helps someone, this lists the affected domains on a server:

for f in /usr/local/directadmin/data/users/*/domains/*.cust_httpd; do
  grep -q 'DOCROOT=' "$f" && ! grep -q '!SUB' "$f" && [ -s "${f%.cust_httpd}.subdomains" ] && echo "$f"
done

Each result needs the DOCROOT line wrapped like this:

|*if !SUB|
|?DOCROOT=`HOME`/domains/example.com/public_html/public|
|*endif|

Best regards