Virtualmin natively supports the management of multiple domains by a single user: this is done using sub-servers in combination with a virtual server. If a user has multiple domains, you simply create a virtual server with any one of the domains that the user needs to manage and the other domains can be associated with the corresponding number of sub-servers that you create under that virtual server. It is quite trivial to do so with Virtualmin.
But if you donât want to use a domain name as the âmain accountâ, Vrtualmin will accept, say, vending_makina as a login name and well as the virtual serverâs domain name (yeah, I know, vending_makina is not a domain name but Virtualmin will accept it as one - letâs call it a pseudo domain) and you can then use all the domains that you want the user vending_makina to manage as sub-servers of vending_makina pseudo domain.
Both approaches outlined above will also fulfill your requirement of a user being able to login with a single set of credentials to manage multiple domains in Virtualmin.
Yup i use that also in other panels , so Maindomain (âFakeâ) user / admin / resellers makes it easier afterwards to move / sell the domains to other server / users und no need to make changes for the main default domain for such âusersâ
Backup restore or moving users to other server you have to take care.
I use for pseudo ( if own ip adress ipv6 for user) also often extra subdomains from vps/ server domainname , so if server hostname is hst1.domain.com then fake1.domain.com ( other user then fake2.domain.com then dns and with those (ipâs) and handy for the ptr reverse records. So then the domainnames are yes real but easy to handle switch / moves from the important WEB domains themself while not as a maindomain connected to useraccount. Separating here is handy.
Yes you can go the way with renaming , i donât like that, sometimes not working or rests of it stay somewhere.
Virtualmin Pro includes a reseller account type which has the ability to create and manage top-level domains (and the admin user can move domains from one reseller to another or dis-associate them from a reseller). We figure if youâve got resellers, youâre making money with Virtualmin, and weâd like to see a little bit of that money.
There are other ways to achieve the feel of a âuser that creates vhostsâ rather than a âvhost that has associated vhostsâ though, and Iâve talked about it in the past. You can create your first domain as username.yourdomain.com. e.g. joe.virtualmin.com, and then I login as joe.virtualmin.com and create my sub-servers. A sub-server can have all of the features of a top-level server (mail and everything else), it just lives within the home directory of the âparentâ server.
History tells us our user model is a little confusing for folks. We were trying to make âI want a website->I have a websiteâ as short as possible. But, turns out a lot of folks donât think of it that way, and would rather the workflow start with a âcreate a website manager accountâ step, and then get to the websites later.
As we go more cloud native in Virtualmin 7 and 8, we are going to have to rethink the user model. Itâll have to be in a database (LDAP or SQL or whatever), since services will no longer all run in one place. The complexity of this is dangerous, and I think itâll scare a lot of Virtualmin users off, though, so I donât know the right thing. Our users are not, by and large, people that need a dozen servers to run their websites, so I donât know exactly what a cloud native Virtualmin looks like (though weâve already added a lot more awareness of cloud-based services like DNS, with more of that coming). But, users definitely get a rethink, and I guess that probably means they get abstracted away from the website they manage.
But how about with permissions at file-system if we do this kind of setup?
Can subserver 1 see and access data of subserver 2.
If so, it might be a security-risk.
Exaggerated example:
You have 20 Wordpress Installation under this fake-user-account.
One is pretty old and was hacked⊠this way⊠how high is a high risk, that hacker can access all other 19 WP in opposite to a config, where each domain has an separate Login?
Yep. Iâm not recommending it. Iâm saying itâs a way to have everything owned by the same user.
Reseller created domains do not have this characteristic. They can each be top-level domains with their own user account. (But the reseller account does not have ssh/FTP access to the domains it manages, so you will need separate account details in your deployment process. But, best practices dictate an automated deployment via a revision control system or something where youâd only need to set it up once.)
Then I also would not do it this way. Everybody who ever had to re-secure an hacked webspace knows, that the needed effort extremely raise by the number of each software installed on it.
@calport If you recommend / describe this way to archive âone-login for all Subserversâ, you better should add a disclaimer to your recommendation so that the users can decide if itâs worth the risk to use this workaround.
I donât consider it âdangerousâ, but itâs also not really best practice. Itâs a balancing act. Some people really donât want to have multiple logins, which is the only way to do it âsafelyâ by this definition. If you only have a bunch of simple sites, all running the same software in the same versions, the risk is not significantly elevated by having them owned by one user (they were all gonna be exploitable in the same ways, if any one was exploitable, anyway).
We use it for static and âparkedâ or 301 redirect domains for example.
And for tests from versions and updates from some software before going live on main this then on subs with ip access protection.
I will try it next year 
