Manage multiple domains with one user in Virtualmin

SYSTEM INFORMATION
OS type and version: any
Webmin version: all
Virtualmin version: all

I have good news for you @vending_makina.

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.

2 Likes

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.

Thank you for the details :slight_smile: I will try it next year :wine_glass:

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.

4 Likes

No i was writing about also other panel there reselllers :wink:

good 2022

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).

Yep, that’s also true.
Definitely a solution I’ll keep in mind for simple HTML-Pages.

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.