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.
Jamie wrote:
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.
Comments
Submitted by aitte on Fri, 02/22/2013 - 06:26 Comment #1
After an initial test run on a dev server, I've now spent the whole day migrating every domain on all of my production servers, and this system is really neat. Just, wow.
For instance, I can now have a user like:
instead of:
In the latter (old) setup, imagine the scenario of wanting to delete tempsite1 but keeping the rest... Not fun.
Under the new system, all domains are sub-servers of the "dummy server" at the top, which just sits there as a neat parent entry.
The file hierarchy is also extremely logical; /home/[user]/domains/mysite.com/public_html.
Having every domain under "domains" is extremely nice for organization and consistency and users understand it better when all of their domains are in one place.
Even if you don't add this to the core, I just have to say that this is the best thing that has happened to my Virtualmin setup, and it's all thanks to your initial workaround idea. I want to give you my sincere thanks.
I'm finally able to give administrators any name and just throw a bunch of domains in there, without ever having weird (illogical) parent/child domain hierarchies, and I'm able to freely delete any domain since none are the "parent" anymore, and the home directories are super neat and logical:
Just... Wow. This was one of those things that you don't know how much you've missed it until you've tried it.
Submitted by JamieCameron on Tue, 02/19/2013 - 20:50 Comment #2
This kind of setup is fully supported in Virtualmin already, in the sense that you can create "users" who don't have a real domain. I'm not sure if I want to complicate the UI by making creation of users like this a separate menu item, but Virtualmin has an extensive API that you could call from your own web frontend or scripts.
The only downside is that for a user with a single domain (which is the most common use case), the directory layout is a little more complicated.
Submitted by aitte on Fri, 02/22/2013 - 06:26 Comment #3
Yeah as you could see from my followup post, the deployment was a huge success. Thanks a lot for the fantastic idea. The freedom and decoupling that this system gives me is great.
You're of course right that 1 domain is the most common usage case and that the directory layout becomes less optimal with the /home/[user]/domains/[domain]/public_html instead of /home/[user]/public_html, in that one-domain case.
Except, not so fast: ~/public_html could be a symlink to the 1st-created subserver. One simple symlink would make it just as easy as the old layout, while giving all of the decoupling benefits of the new system.
Don't you just hate how I have workaround ideas for everything? :p
Anyway, no matter what happens, I know exactly how to deploy Virtualmin in this way now, and there's no way I am going back. Thanks so much for explaining the concept earlier and kicking off the revolution. ;)
Submitted by phantom.force on Wed, 01/27/2016 - 10:02 Comment #4
@attie can you provide the guidelines how to implement it.
thanks