[1]
So there is no way to assign a server to an existing user?
Of course there is. But they’d have to be Webmin users (system users don’t have any information about Webmin capabilities…we can’t just automatically make all system users into Webmin users, as Webmin is an administrative level tool with root-level powers, by default). So, turn those users into Webmin users, and you can then assign virtual servers in Virtualmin to them.
That said, you might be on the wrong track for what you’re actually trying to do (I’m not sure).
Virtualmin always creates and manages the user account?
I own the boxes, my account already exists.
I guess I save my stuff, delete my account, log in as root and then let Virtualmin re-create it?
Maybe what you actually want are additional root-level users? In many situations when someone says, “staff”, they’re talking about system administrators within the company who should have access to everything. If that’s the case, you’d want to make all of your staff into Webmin users with root-level permissions, including Virtualmin. Which makes them “owners” of all virtual servers.
What I said was I wanted to name it the SAME. Not different. The parent domain exists live elsewhere.
That’s not the same. Every sub-domain is a different name. Virtualmin doesn’t care about names. That’s what I’m trying to explain. Virtualmin does not care what you name things (though there are the automatic aliases that might get in the way, if you wanted to have separate virtual servers for, say, svn.domain.tld, www.domain.tld, and ftp.domain.tld that actually pointed to different virtual server homes–that seems rather an unintuitive use of things, but I guess it could happen).
But, joe.virtualmin.com is not the same as jamie.virtualmin.com. And neither is the same as virtualmin.com. Names don’t matter to Virtualmin. joe.virtualmin.com is as different from virtualmin.com as it is from joe.webmin.com. None of these names are the same, and I could have a virtual server or a sub-server or an alias named each of these things. All would work. None have to be a special “sub-domain” type of account for this to work.
That said:
Code will come from SVN into either box, and the folder structure had better match. The point here is to avoid "fancy" apache aliasing, rewriting, symlinks and additional levels of complexity.
I don’t understand what this means.
What is “fancy apache aliasing”? I haven’t suggested any aliasing.
Question remains. Once you start fiddling around OUTSIDE Virtualmin, what damage will you do eighteen months down the road...? What are the traps?
I don’t recommend you mess around outside of Virtualmin.
/domains/mysite/public_html (mysite.com on server X)
/domains/mysite/public_html/foo (foo.mysite.com on server Y)
/domains/mysite/public_html/fie (fie.mysite.com on server Y or Z...)
This is a cPanel style “sub-domain” account layout. I can’t think of a single benefit to this way of doing things. There used to be such an account type in Virtualmin, but it was deprecated because it confused way too many people.
It's that simple.
Virtual servers so that software can pick apart HTTP_HOST to determine where it is.
Every single virtual server in Virtualmin is a virtual hosted server. Everything uses name-based virtual hosting. Virtual servers use it, sub-servers use it, and aliases use it. There is no way to make a website in Virtualmin that does not pick apart HTTP_HOST to determine where it is. What you’re talking about is whether we do things the cPanel way, or not. And the answer is, “We don’t.” And the reasons are explained on the document linked by sfatula earlier.
So, all that said, I’m confused about why the concept of sub-servers is making you feel so frustrated…but sub-domain style accounts would not? A sub-server is simply a virtual server owned by an existing virtual server owner. It can be named with a sub-domain name (you can even enforce that naming requirement…so you can create a virtual server “virtualmin.com” and make it so that he can only create sub-servers named “something.virtualmin.com”).
The only difference from what you’ve said you want is a slightly different directory structure.
cPanel style sub-domains look like:
/home/domainname/public_html/ ("domainname" domain)
/home/domainname/public_html/foo ("foo.domainname" domain)
Virtualmin sub-servers look like:
/home/anyname/public_html/
/home/anyname/domains/othername/public_html
Sub-servers can be named anything, as can the parent domain (again, Virtualmin doesn’t care about names). Sub-servers are owned by an existing virtual server admin, and that’s all that “sub-server” really means–a domain owned by an existing account and living within the home of that existing account. This directory structure describes a site named anyname, with a sub-server named othername that is owned by anyname.
Note that this can be:
/home/domainname/public_html ("domainname" domain)
/home/domainname/domains/foo/public_html ("foo.domainname" domain)
Which mirrors the cPanel style subdomain account type…with the exception that in Virtualmin each sub-server can have it’s own everything because it’s not cramming the subdomain into the web directory of the parent; meaning, you can run different PHP environments, have different mailboxes, have different SVN repos, have different configurations for pretty much any feature (but you don’t have to).
The thing is that I think we’re talking past one another here. What is it that you’re trying to accomplish that requires your additional sites to live within the public_html of the higher level domain? I just can’t think of any benefits to that (not to mention it makes “foo” visible on domainname.com/foo/, which means Google is going to see two copies of your site foo, which is a spammy characteristic and costs you ranking).
But, I’m thinking it just comes down to getting past the idea that names matter to Virtualmin (or Apache, or BIND, etc.), or that foo.domain.com and fie.domain.com has some deep unbreakable connection to domain.com. They don’t. It’s all just names, and everything is a subdomain of something (virtualmin.com is a subdomain of the .com TLD…this doesn’t mean I have to have it live in /home/com/public_html/virtualmin).
Again, maybe I’m just completely missing why you want this particular directory layout. But, I do want to make clear we are talking about directory layout here, and nothing else. All of these things are VirtualHost sections in the Apache config file (except aliases, which are ServerAlias directives).