Continued from the discussion at https://www.virtualmin.com/node/25431, where we discussed the possibility of a system where all domains are stored under /home/[user]/domains, to avoid the confusing idiosyncrasy of a setup like "/home/ricky/public_html" serving a website called "mygreatwebsite.com", I.e. The current lack of distinction between the admin user and his domains, and how tied we are to having the admin / ftp name match the main website name in order to avoid losing our minds.
You could do a setup something like that already, by creating a top-level "domain" with only a directory, unix user and webmin login enabled. All the actual websites are then created as sub-domains.
I agree that this is kind of a hack though, as it requires that a bogus domain name be created for the top-level server.
Hehe, that is such an intriguing idea! It even gets rid of the undesired main administrator email account that is otherwise created on the main domain.
One could create a bogus domain name matching the admin username, so that it looks less hacky:
for user ricky: main domain: ricky, enabled features: administration user, home directory, webmin login, mysql database (must be enabled to be allowed on subdomains) fully hosted sub-server: greatwebsite.com, enabled features: website, mysql, email, etc fully hosted sub-server: bacon.com, enabled features: website, mysql, etc
I tried it out on a test machine and it works:
Domain name ricky Administration username ricky Administration group ricky Created on 19/Feb/2013 07:11 by root Home directory /home/ricky
This way, the server list-tree in Webmin makes total sense. The admin users are shown as the parent item, and all domains they own are listed one indentation level below that.
ricky bacon.com grandmaspancakes.com myhomeoffice.com
I really, really like this hack, and that's solely thanks to the fact that Virtualmin doesn't sanity-check the first top-level server name, allowing me to drop the ".com" for "ricky" and get this sweet result.
It's a hack, but one of the nicest hacks I have ever seen. It makes it instantly obvious which user owns a domain, and it finally makes it feel less weird when one puts several unrelated sites on a single account.
No more of this confusing hierarchy:
bacon.com - site about bacon, of course! grandmaspancakes.com - that site you set up for your sweet grandmother's new plan to take over the world through people's stomachs myhomeoffice.com - that home business you are trying to get off the ground
(of course, i still limit the number of sites per account and keep them all related to limit the collateral damage if one site gets hacked, but either way, this is a really nice improvement.)
Gosh, I am really tempted to move over to this system. Migration isn't even that difficult! Let's imagine a user named "foo" and the top-level server "foo.com", all one would have to do is turn off internet access to the server (to prevent mail and user connections etc from coming in for a while), move the /home/foo/public_html and /home/foo/homes/[users]/Maildir folders to safe place such as under /migrate, then delete all mail-users under the top-level "foo.com" server, then edit the top-level server to set its features to only having Webmin Login + MySQL database (this deletes the site and such but keeps the user's SQL databases), then rename it to just "foo" (no TLD) to turn it into a dummy server, and then finally add a new sub-server called foo.com, moving all data back over to it (to /home/foo/domains/foo.com/public_html), then creating the required email users and manually moving their emails over (and remembering to chown -R [newuser]:[newgroup] their Maildirs so that they don't lose access rights), and that's it. As long as all of these steps are followed, the migration will go smoothly without any data loss.
All of this makes me think that maybe an additional "create server" type could be added, which simply asks for an admin username and creates the corresponding user, giving you a "server" with a main domain matching the username, and only enables the Webmin login/admin username/home root/mysql database features. It would just need a tiny bit of supporting code here and there such as removing the ability to "rename domain" for the main "domain" for such server types, and not creating the /home/user/public_html folder.
For a hack, it's pretty darn slick (doesn't mess with any config files on the system since no "domain" features are enabled on the bogus domain) and very easy to integrate with Virtualmin with minimal changes, if you wanted to go that path. Funny, for what is essentially a hack.
Edit: thought about this some more in the shower (oh the wild things I do in there, sometimes I even recite PI to 10 decimal places, wild I tell you!), I realized that support would require:
new server type: "server owner" (or whatever). - only enables admin user, home folder, and (optionally) webmin login and mysql database. - only provides a single field to enter an admin username, which also becomes the bogus parent domain name. - lets you set admin contact email to "administrator" or "other address" (the prior deposits signup info in the admin's inbox, as usual) - the autocreated mysql database has the same name as the username (ie login: ricky, 1st db: ricky) - allows no access to "change domain name" for the bogus parent domain - allows no access to "edit users" for the bogus parent domain - allows no access to "edit server features" for the bogus parent domain, apart from disabling/enabling the mysql database account - disabling all the rest of the stuff is automatically taken care of since the various feature modules aren't even active - do not create ~/public_html, ~/homes ~/cgi-bin or ~/logs for such account types, since everything related to domains and users will be under ~/domains or, put another way: only create ~/.bash_*, ~/domains and ~/Maildir statistics-wise: - for server counting purposes, do not include the bogus "server owner" domains in the count api: - some restrictions on what can be done with the bogus domain
I am actually kind of stunned at how surprisingly little needs to be done to support this. Almost every point above already works as described, and it really only needs a tiny bit of supporting structure to protect the bogus domain from editing and excluding it from statistics. Heh, thanks a lot for the idea.