I actually intended to get back to this thread but forgot about it. The day after I responded, I talked to a couple of people at the Y Combinator dinner (where I suspect everyone is smarter than I am) who were raving about nginx. I’d never heard of it one day, and then within two days, I’m hearing about it from a lot of smart people. So, obviously, I started researching it.
The only thing I came up with as a deal-breaker for having us involved directly in any such development is that it doesn’t appear to support suexec. I’ve grepped the code, googled the web, and found no mention of how to configure it to work with suexec. It may just be a failing of the English docs, but without suexec, it just isn’t suitable for the vast majority of our customers. (suexec+fastcgi is obviously preferred)
Do you know if there’s anything going on with suexec in nginx? Without it, it’d only be useful for maybe 10% of our current users and going forward by an even smaller percentage (right now, most of our users are savvy developer-types that are operating individual servers with a few users, or maybe even just one or two sites…by this time next year, Virtualmin will be running on high volume hosting servers with hundreds of untrusted users, so we’re spending a lot of time thinking about those issues).
We can’t allow the brave, smart, and cutting edge, Early Adopter users to steer us into uncharted territory that isn’t suitable for the mass-market–you guys are way cool, but there’s only a few hundred of you…we can’t live on revenues from just selling to you guys. As you may have noted, we’ll go that direction as long as it doesn’t get in the way of the core product…so we support crazy crap like Subversion repositories, Ruby Gems, mobile access, lots of scriptability, with more being added all the time. But new web servers are a lot of work and add some huge support burdens. We like the cool cutting edge stuff as much as anyone, but we also like to eat.
That said, I’m not at all opposed to getting a lighter webserver into the mix, if one exists that is suitable and safe for virtual hosting on a large scale (i.e., supports: suexec, fastcgi, some level of aliases and redirects, sane Open Source license so we can distribute it via our repos, reasonable security history, and probably some other stuff).
Apache’s memory usage can be shrunken quite a bit, but admittedly not as much as some of the ultra-light servers out there. I’ll try to write up some docs on shrinking Apache memory usage soon. I’ve covered it a little bit here in the forums, but not in any serious depth. Googling for “Apache low memory” brings up some pretty good results.
You can also turn off preloading of libraries in Webmin, which drops Webmin from ~100MB to ~10MB. It also makes Webmin slower on systems that have plenty of memory, so it isn’t the default. To do that, edit /etc/webmin/miniserv.conf and comment out the preload= line.
So, to answer this one specifically:
Would you be interested in developing this in-house our out, joe? Perhaps a shared expense?
Definitely out if it doesn’t support suexec. Probably out even if it does. We’ve got a really long todo list.
Can you give me some specifics of how to go about this?
As I mentioned, if a Webmin module for nginx were developed that provided an API similar to Apache’s, we’d be willing to abstract the webserver code to allow support for other servers, much the way the mail server code is already abstracted. Even with a good Webmin module, it’d still be a lot of work in Virtualmin, as there’s a lot more to configuring the web server than a mail server, so we’re not gonna be able to commit to a timeline…but going forward I’m certain it’s going to happen that we get that abstraction. There’s just too much momentum behind alternative servers to ignore them. (But, again, our todo list is already HUGE.)
Building a new Webmin module isn’t actually very hard…but the actual bits that connect up to the service being configured can become very complex. No configuration file is alike, unfortunately, so you pretty much have to write a new parser and generator for every service being configured. There’s ways to “cheat” and generate the configuration via templates or whatever, which is very very easy to do, but that’s not the sort of thing we’re gonna allow in Webmin (most of our competitors, who shall remain nameless, are guilty of this crime…but we aren’t willing to stoop to that level…so the module has to understand the configuration file, both for reading and writing, and has to respect comments, file order, etc.).
Once there’s a reasonably full-featured and well-implemented Webmin module for the server (one that’s high enough quality to be integrated into Webmin, and is licensed under the BSD license, so we can integrate it), we’d then work on abstracting out the web server calls in Virtualmin. This is probably a week or two of Jamie’s time (which is in short supply), but we’d be willing to divert him to work on it, if the module existed.