Custom path for sub-servers?

For reasons that are out of my control we have a main site and 4 subdomains all on the same repo. I’m setting up dev versions of the site and subdomains .
The repo has a public_html and a domains folder and the subdomains are in the domains folder eg. api.mydomain.com which matches the structure of the main virtual server /home/mydomain.com/

I’ve set up a new top-level virual server called dev.mydomain.com and I will want either api.dev.mydomain.com or apidev.mydomain.com (not sure which is better, doesn’t really matter) but the folder in /home/dev.mydomain.com/domains needs to be api.mydomain.com to match the repo but I can’t figure out what setting to change or where I can change it so that I can specify the directory name of a sub-server

SYSTEM INFORMATION
OS type and version: Debian Linux 10
Webmin version: 1.981
Virtualmin version: 6.17-3

When creating the virtual server, under advance options you can specify the directory name and override the default.

I don’t have that option. Only mail username prefixes and default database name

Yes, I checked on my phone and it’s not where I expected it to be, from memory. Sorry I wasted your time.

I’ll try and post the correct answer when I get to my PC.

Under edit server template, settings for sub servers. There are some options under virtual creating and home directory that may help? When you create a new virtual server, sub domain will use the template. System Settings → Server Templates → Settings For Sub-Servers. I dont know if it will help or route you in the right direction.

edit Apache config files for that subdomains?

Just food for thought, though frankly this may not actually be useful the more I think about it (stop thinking, stop thinking)…

I wrote a script which allows me to “sandbox” (test) and publish to a “live” version of a site using a “profile” and “version”…

Basically I run my program like:

Sandbox Upload:
website-upload --profile /path/to/sandbox.json --version 21.11.03

Live Upload:
website-upload --profile /path/to/live.json --version 21.10.31

Basically the “live.json” and “sandbox.json” files are simple JSON configurations which hold information about “hostname” (server to upload to), “l_path” (local path), “r_path” (remote path), and “user” (username used for rsync or scp)… There is no “password” in this file as we use “public/private key” authentication so a password isn’t needed.

“live.json” would publish to say: mydomain.com

Whereas

“sandbox.json” would publish to say: sandbox.mydomain.com

I then am careful about how I write my code so that it works without modification on both “sandbox” and “live” version.

The benefits, I can test new functionality and changes in the “sandbox” then when I’m content publish to the “live” environment… I can even rollback to an earlier “version” as needed if something goes amuck.

My personal versioning model is to use: YYYY.MM.DD which works well for me, though I’ve also been known to extend the version to YYYY.MM.DD.HH if I wanted to make two versions in the same day for some reason.

Just an idea, though like I said the more I think about it, the less likely it will be of use though who knows perhaps it’ll be the start of a revolution!

That is way too much thinking :stuck_out_tongue: :joy:

We already have versioning and deployment/rollbacks sorted through github and DeployHQ, the only issue is that because my boss is being cheap, we’re limited to a single repo and deployment project so the sub-servers need to have the same folder names on the sandbox sites as they do on the live site.
(in the past we had 1 repo and project per site/subdomain and that worked great because we just specified the location of the deployment path when we set it up)

It’s a shame your boss has got this tunnel vision and can’t see your current setup will demand higher maintenance and cost more long term. Not to mention higher risk of errors. Somebody needs to get buy in and present the right solution to him/her.

hi @NancyJ I well understood why your boss done this… perhaps release this for testers under gpl version and give it a shot… I bet you will have tons of response within months not to mention code to be debugged and grown to something actually… your boss is not cheap, he just dont want to take risk which I totally understand. - just think about it.