server tempalte substitution not working


I found server tempalte substitution not working for server templates.

For MySQL password, I tried all of these variations I found across multiple old & new virtualmin support pages.


None of them work. I never get a password substituted for any of those.

Is there a fix for this?





Howdy -- which field in the Server Templates are you trying to use those variables in?


These are used into /etc/skel/file.txt (for example) with option "Substitute variables in contents" enabled. Then, I'm creating a new domain or subdomain.

All other variables I've used yet work just fine. But the MySQL password.

Any help would be appreciated.




I was just wondering if there were any follow-ups on this bug report.

Thanks in advance.


Marc Arbour

I assume that the domain that this problem happens for has MySQL enabled?

Hello Jamie.

Yes indeed it has. Sorry. I should have mentioned it.

New information : when creating a domain, variable ${PASS} outputs 1_PASS. All 3 others are outputting an empty string. In the case of a subdomain, all four output an empty string.

Thanks for your help.



Can you post the actual template here, or at least the parts that reference those variables? ${PASS} being replaced by 1_PASS seems like it might be caused by an error in the substitution.

Sorry to ask : how can I post the template? It's part of virtualmin and I haven't found any options to export it.

If you mean the file in which I'v placed the variable to be replaced, Here it is:

In this first example, there are 4 different variables. 3 of them work fine.

timetolock=$(mysql -u${MYSQL_USER} -p${MYSQL_PASS} -se "select option_value from ${DB}.siteinfo__options where option_name='filesystem_unlocker_plugin_options'");
isitlockedalready=$(mysql -u${MYSQL_USER} -p${MYSQL_PASS} -se "select option_value from ${DB}.siteinfo__options where option_name='filesystem_unlocker_plugin_lock_state'");
if [ $timetolock -gt 0 ] && [ $isitlockedalready -eq 1 ]
find ${HOME}/public_html/ -type d -exec chmod 755 {} \; && find ${HOME}/public_html/ -type f -exec chmod 644 {} \;
mysql -u${MYSQL_USER} -p${MYSQL_PASS} -se "update ${DB}.siteinfo__options set option_value = 0 where option_name='filesystem_unlocker_plugin_lock_state'";

if [ $timetolock -eq 0 ] && [ $isitlockedalready -eq 0 ]
find ${HOME}/public_html/ -type d -exec chmod 555 {} \; && find ${HOME}/public_html/ -type f -exec chmod 444 {} \;
mysql -u${MYSQL_USER} -p${MYSQL_PASS} -se "update ${DB}.siteinfo__options set option_value = 1 where option_name='filesystem_unlocker_plugin_lock_state'";

if [ $timetolock -gt 0 ] && [ $isitlockedalready -eq 0 ]
mysql -u${MYSQL_USER} -p${MYSQL_PASS} -se "update ${DB}.siteinfo__options set option_value = option_value-1 where option_name='filesystem_unlocker_plugin_options'";

domaine=$(mysql -u${MYSQL_USER} -p${MYSQL_PASS} -se "select option_value from ${DB}.siteinfo__options where option_name='siteurl'");
echo ${domaine:7} > ${HOME}/domaine.txt
echo $timetolock > ${HOME}/timetolock.txt

and part of another one is

define('DB_NAME', '${DB}');
define('DB_USER', '${MYSQL_USER}');

As you can see in the second, I've tried all variations of the variable I've found on all virtualmin forums pages from the past.

Thank you in advance.


Jamie, just to clarify -- the variables he's using aren't in the Server Template config itself.

He has files in /etc/skel/ containing those variables, and the option "Substitute variables in contents" is enabled.

Other variables are working, it's only the password related ones he's having trouble with.


Good summation andreychek.

Have a nice week end!



Are you using hashed passwords there (in which Virtualmin doesn't store the domain's plain-text password)? You can check by running grep hashpass /etc/webmin/virtual-server/config - if the output is hashpass=1 , then you are.

Jamie, he was mentioning that he wasn't able to use MySQL passwords either though, using ${MYSQL_PASS}.

Is there another MySQL password variable he should be using if hashed passwords are in use?

I just checked, and there's a bug that prevents MYSQL_PASS from being available during /etc/skel file copying :-( This will be fixed in the next release though.

Hello Jamie.

Thanks for the heads up.

I will await the next release.

Have an excellent day.



That next release will be out soon! We're actually putting the final touches on a release to support the new Ubuntu version, but that same release will resolve the issue you're experiencing.