Scripts Installed Per-Domain vs. Server-Wide

5 posts / 0 new
Last post
#1 Sun, 10/30/2005 - 19:05
ADobkin

Scripts Installed Per-Domain vs. Server-Wide

This isn't exactly a feature request, but it seems like the most appropriate forum anyway. I am really questioning an existing feature instead of suggesting/requesting a new feature.

My question is, why would the average server administrator want to offer programs/scripts like Horde/IMP, SquirrelMail, phpMyAdmin, etc. to be installed per-domain? Instead, they can be installed once globally for the entire server and then made available to all domains automatically. Of course, some scripts need to be available per-domain so they can be customized. But at least in the case of the webmail clients and phpMyAdmin, there is hardly any need to customize them. Also, it is much easier to support and maintain a single instance and a single version rather than multiple copies and different versions spread out in a bunch of domain home directories, not to mention the extra server and backup resources that requires.

In addition, I don't want my clients to have to set up their own webmail clients after their account is created. This should be done for them automatically as part of the hosting package setup. Practically everyone uses webmail, so why not just offer it to them all by default? With SquirrelMail in particular, once it is configured with the[A HRef="http://www.SquirrelMail.org/plugin_view.php?id=47">vlogin plugin</A> (and several others for useful feature additions), it is 100% ready for everyone to use.

As an analogy, I see providing some of these script installers similar to providing a script installer for Usermin, which doesn't make much sense.

Maybe I am missing the point, but I just don't see any strong reason to offer these installers to my clients, and several strong reasons[Strong><Em>not</Em></Strong> to.

Thanks, Alan

Mon, 10/31/2005 - 01:18
FaisalMehmood

Hi.

I kind of agree here, especially in the case of PHPmyadmin and webmail. A case example would be cPanel where they come installed.

Thanks.
Faisal.

Mon, 10/31/2005 - 04:24
Joe
Joe's picture

Hi Alan,

The original goal was to address the needs of folks who wanted to help website maintainers with installation of a lot of common scripts, and as you've pointed out, customization of a lot of scripts is very important and can't be done for a server-wide install. The original vision of the Script Installer did not include webmail at all--Usermin is the official webmail client of Virtualmin Professional, and if some feature is missing, the GUI is less attractive, or if users find it harder to use than the other webmail clients out there, we'd like to fix it. That said, it was clear that a lot of users wanted their favorite webmail client. So we added it in the most expeditious and flexible way possible using the Script Installers API.

Installing server-wide is a wholly different sort of task, and would probably need to happen at installation time. It also has quite a few limitations over using Usermin (Usermin is clever about usernames, has integration with many other modules of Webmin/Virtualmin, and will soon have quite a bit more integration features that other webmail clients will never have). I'll certainly consider adding some of these in a server-wide configuration to the installation process, or possibly adding a new module to set them up.

There is also an alternative to phpMyAdmin and phpPgAdmin in the form of the MySQL and PostgreSQL modules of Webmin (and Usermin), and they are (I think) enabled by default for domain owners that have databases enabled. Again, users wanted the phpXadmin versions, so we dropped them into the Script Installers. I haven't spent any time on configuring these for server-side use, but I'll trust that you know of what you speak, so I'll look into what it would take to get them available in that way.

You can, of course, disable any of the scripts in the Script Installers that you don't want users to be able to install, so that if you do set one of these up server-wide and don't want users to be able to create their own instances, just disable it.

So, to sum up:

Webmail <i>is</i> enabled by default on every Virtualmin installation in the form of Usermin. Browse to port 20000 on your server (accessing it on any domain configured on the system) and your users will have a lot of powerful features in addition to webmail with a lot of nice features (though perhaps not your favorite feature from X webmail--but let us know what it is and it won't be missing for long), like password changes, database administration (optional), File Manager access, uploads and downloads, fetchmail configuration, SpamAssassin per-user configuration, mail forwarding and auto-response, quota usage reports, etc. It is also customizable with new modules and Custom Commands, so if there's something you need to provide to all of your users--like a &quot;news&quot; gateway, or whatever--you can do it without a whole lot of work and without having to customize anybody elses code (it would live in a module, so you don't have to worry if an upgrade of your webmail client will break things). And, of course, if you only want users to have webmail and nothing else, it's easy to configure Usermin to bounce the user right into the mail client on login and provide no other modules at all.

Database administration is available universally via Webmins MySQL and PostgreSQL modules. These modules are similar to the phpXadmin scripts in functionality, though the way they present the data is a little different. They developed independently of those scripts over the same general period of time, so they are equally mature and featureful but behave quite differently. Of course, if one is only familiar with the phpXadmin tools, then those are the better choice, so they're included via Script Installers.

So, what it comes down to is that my original vision didn't include any of these scripts at all (webmail, phpXadmin), which I viewed as a big weakness of our competitors (their reliance on these tools means a wholly un-cohesive user experience and disparate ways of doing things based on what task you're trying to accomplish), and replaced them with the cohesive single GUI of Webmin/Usermin. There is much to be said for a universal, &quot;one way to do a given thing, and it is as close to the same as doing any other thing as possible&quot;...this is the beauty of the Macintosh, of course. But then, I don't want to limit the possibilities of Virtualmin to only those choices. It all comes back to the whole &quot;Golden Path&quot; idea I've been shooting for, wherein if you accept the choices we make, everything will Just Work and if it doesn't we'll fix it as fast as possible. If the majority of our users are on this &quot;Golden Path&quot; (which admittedly isn't as golden as it needs to be, but we're working on it) then the product will be significantly easier to use (because all parts work the same), better documented (because we understand every aspect of the system in very deep detail), and more fun to use (because the Right Way to do something is closer to obvious).

I'm beginning usability testing next week, and I expect a lot of UI changes to occur during that time. Things that seem cryptic now will become more obvious, the GUI will get more responsive through a few AJAX touches here and there (with graceful fall-back to a non-CSS/non-JS browser always being required of those touches), and features that you didn't know were there at all (and I know there are a lot of them, because there is a pretty wide-spread impression that Usermin mail is simplistic and under-powered, just to name one example) will become easier to see and easier to use.

But, after all of that rambling, I hope it is already apparent that we aren't insisting on anyone following this Golden Path. We are providing the tools to ease creation of your own path, as well, and will continue to add new ones as quickly as we become aware of what it is you'd like to do. This one is a new one and so we haven't even thought about it. Now that we're aware of it, we'll get to work on it.

I think this also brings up the need for better presentation of our vision of what Virtualmin Professional should be. The flexibility aspect is well-known from our years of the Open Source version (Jamie, in particular, is well-known for diffusing religious wars on the Webmin list by implementing the wishes of <i>both</i> sides before they even have a chance to get to hollering good!), but this idea of a single coherent interface to all things virtual hosting, wherein the path is pre-paved for your convenience as much as possible, is new to Virtualmin Professional.

Hope this helps you understand the <i>why</i> you've asked for above, while also easing your mind that we are at your beck and call even if we happen to have wishes of our own about how it all ought to fit together. ;-)

--

Check out the forum guidelines!

Mon, 10/31/2005 - 08:29 (Reply to #3)
ADobkin

Joe,

Thank you for your very thorough response. I just wanted to clarify that I prefaced my post with &quot;This isn't exactly a feature request&quot; because I wasn't really asking you to change anything at first. I was just trying to understand the rationale if and why anyone would want to install multiple copies of SquirrelMail, Horde/IMP, etc. on their systems. But from the responses so far, it sounds like there is no good reason for having these packages as Script Installers, other than providing a quick way to implement them into Virtualmin using an existing feature set.

Incidentally, I am aware that I can disable the Script Installers that I don't want to use, but the purpose of my question to the forum was to see if there is *any* reason to have them enabled per-domain. If there is not, then I think they should be removed by default rather than requiring site administrators to manually turn them off on each installation. Virtualmin is designed to make virtual hosting easier and more efficient, but in this regard there is now an extra step (disabling) that administrators have to perform on each of their servers if they want these scripts to be installed server-wide, which seems to be the preferred method.

I agree with and support everything you said about Usermin, but that still doesn't negate the requirements to have SquirrelMail, Horde/IMP, etc. easily accessible. Some users like to stick with what they know, and others like to have choices and flexibility. The great thing about most webmail clients is that they are interchangeable, so they can interoperate just fine. One user can read their mail with Usermin, while another can use SquirrelMail, and yet another can use Horde/IMP, all at the same time on the same server.

Regarding the phpXAdmin scripts, I only have limited experience with phpMyAdmin and the MySQL module, but I know that phpMyAdmin only shows the user those databases which they have access to. Assuming phpPgAdmin does the same thing, then they are both ready out-of-the-box for server-wide deployment. Granted, the Webmin DB modules are very good and should definitely be recommended as the &quot;Golden Path&quot; for most users, but DBA-types will find much more advanced features in the phpXAdmin scripts. So, there is no harm, and much potential benefit, to having these scripts available server-wide.

So, after giving this a little more thought, it seems like the best long-term direction would be to move at least these four packages out of the Script Installers menu, and build them into the main installer script, possibly as optional components. Then, they can be available for those who want to use them by default, and those who don't can ignore them. With SquirrelMail in particular, it is already built-in as a core RPM on all Fedora and Red Hat-based distributions, and the source RPM is freely available from the SquirrelMail site, so that is a no-brainer to install. The others may require a little more work, but it seems like a worthy endeavor, since Virtualmin users obviously want these packages to be included (since their clients will want them from their hosting provider), and it would save a lot of administrator and user headaches for them to be installed server-wide rather than per-domain.

BTW, the UI changes, especially AJAX touches, sound very interesting, and I anxiously look forward to seeing the results!

Sun, 12/04/2005 - 15:31
himagain

Speaking more as one of those mysterious people: an End User:
As an industrial psychologist by training and inclination - it means I don't like learning new things but understand why I don't! :-)

I tend to resolve most dilemmas by reduction to what my old colleagues used to call reductio ad absurdum. This one is a classic, but my 2 cents worth is:
Preaching to the converted is always unnecessary. (Real Tech-heads here).
Preaching to the mass is a waste of time.(Users of CPanel)

My humble solution is to have two distinct install structures:
1. Super User Version for Experienced Server Administrators.
2. SIMPLE STANDARD SETUP Version for Ex-WHM/Cpanel Users (=Newbies)which &quot;does a CPanel&quot; - a STANDARD install in a familiar way.

Where I come from a lot of people still buy 4 Wheel Drives to do work with. They buy Diesels with MANUAL Gearboxes. We don't have a lot of tarmac - we do have a lot of dirt/mud tracks. They have REAL (ugly) winches fitted to the front and real ugly bullbars. No chromed fishing pole holders

BUT: ALL the rest buy automatics, delivered without those noisy type tyres, too. They only drive to the shopping Centre or down the expressway and back. Never leave the tarred road.

Sorry I have to be so allegorical, people, but a tech-head I ain't. In the middle, I am.
80% of the future success for Webmin/Virtualmin is going to be converting WHM/CPanel types. They just want to save money and not have the lousy support of the former. They do not want a learning curve. Not at first...
They NEED to bring their clients with them without fuss or the bother of trashed mailing lists because of incompatibilities between the lousy CPanel choice and the superior program choice of WV. :-)
(LIKE ME!)
Even the 20% of those that come in cold - no clients - will only basically have CP exposure. AND little OS grasp.
The remaining 20% - the tech-heads - should have no trouble once they grasp the intentions of such esoteric ideas of the founder, like using OpenACS, which nobody in the wetworld has ever heard of.... and it seems marvellous.

IN CONCLUSION may I remind you:
THe vast majority of Browser users still use Internet EXplorer - even though the amazing Firefox is free. But[b&gt;BECAUSE&lt;/b&gt; it offers so much more, it is a bit confusing to the tyro...and skipped.

Cheers!

Topic locked