When I go to add a Virtual Server (VS) to my system, I am give the following choices: - Top-level server - Sub-server - Alias of mydomain.com - Sub-domain of mydomain.com
Initially I presumed, partially from reading in the Webmin books (I got both!) that these were basically the Apache "virtual hosts". But clearly they are much richer than that, having system level logins, sftp, svn, mail and so on.
They also are imbedded in the file hierarchy of my Solaris zone. Some VS's end up making entry in /home. Others end up in /home/mydomain/domains. I believe the users are always in a .../homes/ subdir, depending on the type of VS.
So HELP! Where do I find out about what these VSs actually ARE in terms of the top level zone I have. I'm also not clear exactly how DNS gets into the act, other than needing a *.mydomain.com wildcard in my name server.
I really couldn't find this in the docs, but feel free to shout noob! .. and then point me in the right direction in the docs and or books!!
Thanks!<br><br>Post edited by: backspaces, at: 2008/03/28 19:06
OK, I found a start -- your documentation really is great.
http://www.virtualmin.com/documentation/id,definitions_for_virtualmin_te...
Virtual Server: A Virtual Server in Virtualmin means a combination of a system user, a home directory, a VirtualHost in Apache, a set of entries in the virtual map database in Postfix, an administrative account in Webmin, a database and database user in MySQL and/or PostgreSQL, and all of the necessary records in BIND.
We've had a a lot of discussion with our hosting service about this and from my ancient computing history (worked at Xerox, Apple, Sun) it seemed to me that a VS had to be a collection of services, not just apache. I'm *amazed* you could pull this off -- coordinating Web, Mail, Unix/Linux User(s), sftp/ssh login, database and all.
I'll look further, but I'd like to know a bit more like the use of the ~/domains/ dir and how subdomains are really managed, apparently without the name registrar/nameservice taking part (other than enabling a wildcard for subdomans). Maybe by using BIND?
I presume ~/homes is users of the VS?
VM is just stunning! Wouldn't have thought it possible.
Well, I like the good definition of a Virtual Server mentioned in earlier posts, but could someone clarify the difference between the *kinds* of VSs, and where one is more limited than another?
- Top-level server
- Alias of mydomain.com
- Sub-server
- Sub-domain of mydomain.com
I'll take a stab at it from looking at my shared Joyent account:
- Top-level: Used for different IP addresses. Lives in /home/VSname.
- Alias: acts like an identical version of the VS it is pointed to, but has a different IP. Lives in /home/VSname/domains/aliasdomain.tld/. Oddly, has some structure such as its own mail and web directories, which I believe do not function.
- Sub-domain: A separate VS for subdomains of a top level VS like wiki.mydomain.tld. Again, has its own file structure.
- Sub-server: I don't know!
Is this close?
I've updated the definitions page to give a bit more data.
And I'll just add a few comments here:
<div class='quote'>I'll take a stab at it from looking at my shared Joyent account:
- Top-level: Used for different IP addresses. Lives in /home/VSname.</div>
IP addresses don't matter. A virtual server may have its own IP or not. Virtualmin configures name-based virtual hosting in all of the relevant services, and so IP addresses are mostly irrelevant.
<div class='quote'>- Alias: acts like an identical version of the VS it is pointed to, but has a different IP. Lives in /home/VSname/domains/aliasdomain.tld/. Oddly, has some structure such as its own mail and web directories, which I believe do not function.</div>
Yeah, that is a bit odd. ;-)
I believe it is partly historical, and partly optional services. Aliases actually can make use of those directories...I think independent mail service can be enabled for an alias, for example. But I think that'd be kinda dumb. The thing is, we've been building Virtualmin as an Open Source project for so long that sometimes some weird/dumb ideas have made it in based on strenuous requests of one or two users. We've been pruning it down a bit over the past couple of years, since simplicity has value, too, but it's value that no one ever points to and says, "If Virtualmin were just simpler, it would be a killer app." People instead say, "If Virtualmin only managed the frobnosticator widget in addition to all of this other stuff, it would be a killer app." If we don't pause to ask, "How many people would actually use this frobnosticator widget with Virtualmin?" the feature ends up in the product and nobody but that one guy ever uses it...and it complicates usage of the whole product for everybody else. It's a hard life having more features than any other product on the market by an order of magnitude. ;-)
Anyway, aliases definitely don't need IP addresses. Merely another name.
<div class='quote'>- Sub-domain: A separate VS for subdomains of a top level VS like wiki.mydomain.tld. Again, has its own file structure.</div>
Yes, but we don't recommend use of sub-domains. They were added to satisfy cPanel users who didn't want to use sub-server accounts. sub-domains are merely a limited subset of the functionality of the sub-server account type. By default, we actually hide the sub-domain account type on new systems for this reason (and because it confuses people into thinking that they need to make sales.example.com a sub-domain of example.com, even though they want a different administrator to manage it...somehow once they see that there is a sub-domain account type, they assume how you have to make an account named with a sub-domain of some existing domain...when really it's all just names to Virtualmin). Confused yet?
<div class='quote'>- Sub-server: I don't know!</div>
A virtual server owned by a pre-existing one. It can have most of the same features...but can be created/deleted/managed by a virtual server administration user. This is so that a system administrator can allow a virtual server owner to create their own virtual server domains. There are lots of options for restricting the virtual server administrator--like how many they can create, how many databases they can have, whether the sub-server must reside within the same DNS zone (e.g. must have a sub-domain name of the parent virtual server, or can be any name you like).
These live in /home/example/domains, and have a directory structure within that subdirectory that is roughly identical to the structure of a virtual server.
Sub-servers, in my humble opinion, should always be used instead of sub-domains. But, we aim to please, and sometimes folks point us towards the same stupid target our competitors pointed at a few years ago. ;-)
--
Check out the forum guidelines!
Thanks! Just what I need, and its stuff outside of the two great books, AFAIK. I've just pointed our Santa Fe Complexity community to the terminology page so they can understand what we're saying. Sweet!
One related question arises from your answers: IP vs Name.
Lets suppose I have two DNS names, Name1.com and Name2.com, registered with a Registrar and managed by a name server. And lets suppose I point these two names to the same IP address 1.2.3.4 in my name server. I never thought about it but I guess that's OK, there needn't be a 1-1 mapping between a name and an IP. Cool.
So on my VM Hosted server, who's IP is the 1.2.3.4 above, I create two VSs, you guessed it, named Name1.com and Name2.com. Because most protocols we care about somehow include a name (urls, mail addresses for example), the clever VM software can correctly select the right VS.
Is that the basic way the VSs with different names but the same IP sort things out?
Conversely, I suppose one could have two IP addresses assigned to a single VS, but only at the top level .. because possibly Solaris zones can have more than one IP?
But regardless, as far as possible, its the name that matters, and the names are part of the VSs.
I'm getting dizzy!