Can we reference/use Custom Fields in server template (Apache site conf)

Virtualmin
1
SYSTEM INFORMATION
OS type and version Ubuntu Linux 24.04.4
Webmin version 2.641 (Installed using .deb package)
Virtualmin version 8.1.0.gpl (Installed using .deb package)
Webserver version 2.4.67
Related packages –

Hello Everyone,

I am trying to use Custom Fields to in Server template to set some custom values in apache virtual host conf file on virtual server creation. But that is not working, it does not expand the variables instead prints as-it-is.

I checked Template Variables | Virtualmin — Open Source Web Hosting Control Panel, which suggests to use $VIRTUALSERVER_FIELD_fieldname format but it is not working. I tried with $FIELD_fieldname too but no luck.

I also looked at custom fields usable in httpd.conf as replacable params - #4 by Joe where Joe suggests the same.

My current template is:

ServerName ${DOM}
ServerAlias www.${DOM}
ServerAlias mail.${DOM}
DocumentRoot ${HOME}/public_html
ErrorLog /var/log/virtualmin/${DOM}_error_log
CustomLog /var/log/virtualmin/${DOM}_access_log combined
ScriptAlias /cgi-bin/ ${HOME}/cgi-bin/
DirectoryIndex index.php index.htm index.html
<Directory ${HOME}/public_html>
    Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch 
    Require all granted
    AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
<Directory ${HOME}/cgi-bin>
    Require all granted
    AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>

mydirectve ${VIRTUALSERVER_FIELD_appport}
mydirectve $VIRTUALSERVER_FIELD_appport
mydirectve ${FIELD_appport}
mydirectve $FIELD_appport
mydirectve ${CUSTOMFIELD_appport}
mydirectve $CUSTOMFIELD_appport
mydirectve ${CUSTOM_FIELD_appport}
mydirectve $CUSTOM_FIELD_appport

I created a test site from the WebUI, assigned value 9090 to the field ‘appport’.

But It does not recognize variable and generates .conf as follows:

cat /etc/apache2/sites-enabled/test.conf 
<VirtualHost 127.0.0.1:80>
    ServerName test
    ServerAlias www.test
    ServerAlias mail.test
    DocumentRoot /home/test/public_html
    ErrorLog /var/log/virtualmin/test_error_log
    CustomLog /var/log/virtualmin/test_access_log combined
    ScriptAlias /cgi-bin/ /home/test/cgi-bin/
    DirectoryIndex index.php index.htm index.html
    <Directory /home/test/public_html>
        Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch
        Require all granted
        AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
        AddType text/plain .php
    </Directory>
    <Directory /home/test/cgi-bin>
        Require all granted
        AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
    </Directory>
    mydirectve ${VIRTUALSERVER_FIELD_appport}
    mydirectve 0UALSERVER_FIELD_appport
    mydirectve ${FIELD_appport}
    mydirectve $FIELD_appport
    mydirectve ${CUSTOMFIELD_appport}
    mydirectve $CUSTOMFIELD_appport
    mydirectve ${CUSTOM_FIELD_appport}
    mydirectve $CUSTOM_FIELD_appport
    ProxyPass /.well-known !
    RemoveHandler .php
    <FilesMatch \.php$>
        SetHandler None
        AddType text/plain .php
    </FilesMatch>
</VirtualHost>

I am doing something wrong? Is this a pro feature? Or the feature is no longer available?

Here Apache is acting just as a proxy, Apps will be running on their own ports. So idea is i will pass a backend application port and Virtualmin will create the site with ProxyPass configured accordingly. Please suggest if there is a native way to do that where I can pass a local port when creating a new Virtual Server like 9090, 9091, 9092 etc.

2

@Ilia @Joe

Could you please help me?

3

It is not a Pro feature. The feature is still available.

None of these do anything anywhere, AFAIK, and none of them are mentioned anywhere in our docs. Not sure where these came from?

I believe you want ${FIELD_fieldname} in this case, as mentioned in that old thread.

So, does this one not do anything?

I’m assuming you have a field named exactly appport (internal name, not the user-visible label)? I think the code actually uppercases all of these variables, as they’re globals (in some files), but I don’t think you need to uppercase it in your usage of it.

4

Hi @Joe Thank for the reply and the UPERCASE hint.

It actually requires field name in UPPER_CASE.

I was using lower-case name as I saw example on Template Variables | Virtualmin — Open Source Web Hosting Control Panel doc. Can we update this doc accordingly.

Also I have tested both formats in the template as follows:

Format Outcome
${VIRTUALSERVER_FIELD_APPPORT} Does not work, exported as-it-is.
${FIELD_APPPORT} It works and get replaced by value.

Now, following is the actual proxypass config which i tested and working for me:

${IF-FIELD_BACKEND_PORT}
ProxyRequests Off
ProxyPreserveHost On
ProxyTimeout 1200
<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>
ProxyPass /.well-known/acme-challenge/ !
ProxyPass / http://localhost:${FIELD_BACKEND_PORT}/
ProxyPassReverse / http://localhost:${FIELD_BACKEND_PORT}/
${ENDIF-FIELD_BACKEND_PORT}

There is a downside, though: it does not update the VHost configuration when a custom field is updated later by editing the virtual server. Instead, it requires manually editing the .conf file. Please direct me to the documentation if there is a built-in feature to handle the ProxyPass configuration.

5

Server Templates apply at domain creation time (or feature enable time), so that’s working as intended. It’s not really possible to safely replace on changes.

Virtualmin does not generate config files from templates, replacing the whole file each time an edit is made (as some control panels do). It reads/parses the config files every time there is an update, so you can modify config files yourself and expect Virtualmin to respect those changes.

You can generally disable/enable the feature to force it to re-apply the template, at least in some cases.

There is a Proxy Paths form for creating proxy rules, but if you want one to always be created as part of the domain creation, you should do it exactly as you’re doing it. Server Templates is the right place to put things that you want to happen automatically on domain creation.

6

Thanks @Joe for all this information.