Ngnix integration

20 posts / 0 new
Last post
#1 Mon, 04/02/2007 - 10:27

Ngnix integration

Hi all,

Ive been looking at dropping Apache and going with another alternative server, to drive my managed cms. It's a thoroughly battle-worn and stable Russian HTTP(S) server, HTTP(S) reverse proxy and IMAP/POP3 proxy server written by Igor Sysoev, running on many heavy-traffic Russian sites for more than two years. See English wiki:

Also very interesting is Cherokee: "Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, TLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly encoding, Apache compatible log files, and much more."

Im wondering how viable/probably/possible it would be to get WebMin working with the above servers; what it would take? could I outsource this work? would Joe even consider it? why is everyone staring at me? am i going insane!? - y'know the usual questions.

Your feedback is appreciated.



Mon, 04/02/2007 - 14:13
Joe's picture

Howdy Morgan,

You're clearly going insane.

That said, if somebody writes a good Webmin module for any alternative server (good is defined as one that has roughly similar API functionality to the Apache module), we'll probably add support for it to Virtualmin within a few weeks.

If I had my druthers, that alternative would probably be lighttpd. It's all the rage with the Web 2.0 kids...and some of those kids are pretty smart. YouTube, WikiPedia and Meebo all run it, so it definitely scales. And while I have personally chatted with the Boa and Cherokee developers some over the years (I even tried to hire a couple of them a few years ago for a contract job), and am very impressed with their code...lighty has the momentum right now, and as Ruby on Rails shows, having momentum is really quite good for progress in a project. But any of those would be good choices. I don't know enough about nginx to say anything about it.

But, there's a reason Apache is the worlds most popular webserver, by far. Actually, a lot of reasons. Nothing else comes close on flexibility. Apache just has so many module and so many developers working on it. And for the vast majority of deployments it is fast enough. (Sure, some others are faster...but faster than "fast enough" is still just "fast enough".)


Check out the forum guidelines!

Mon, 04/16/2007 - 11:18

Thanks for reply, and apologies for my slow as mollases follow-up.

Re: Lighty/RoR - yeah, but it's not as relevant to other frameworks as Nginx can be, i.e. mine.
Point of note: RoR is responsible also for the increasing interest and development of Nginx, and a LOT of people are saying good things:

Re: 'Fast Enough' - Im not at *all* plussed by the 'go faster' conundrum, im more than happy with 'slow and steady wins the race'. BUT I do have numerous memory issues arising with Apache/Webmin on our Xen VPS which runs our test deployment of our customised Pylons CMS.
The intention is for our system to scale *A LOT* and presently im not confident Apache can go for a jog down the street, let alone take on the barbarian hordes of the www. Im saying this after paying someone to troubleshoot and resolve the (mystery) memory conflicts of Apache, which resolved about 90% of them.

We've considered spending more time to resolve, but at the mo' its ok 98% of the time, until the 2% when RAM wildly bloats at unforseen intervals. We're up because the VPS has been kind enough to increase our ram for free. What with our 1 client site; apache, meh.
Just a taste of non-definitive similiar issues:

Sure we could resolve, but considering our (long-term) needs, we'd prefer to have a trouble free, non-bloated, simplified server running the stack.

Methinks that in-roads to getting a Nginx module running for Webmin, would simplify similiar.

Would you be interested in developing this in-house our out, joe? Perhaps a shared expense?
Can you give me some specifics of how to go about this?

Kind Regards,

Morgan Newall

Mon, 04/16/2007 - 17:47 (Reply to #3)
Joe's picture

Hey Morgan,

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 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 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:

<i>Would you be interested in developing this in-house our out, joe? Perhaps a shared expense?</i>

Definitely out if it doesn't support suexec. Probably out even if it does. We've got a really long todo list. ;-)

<i>Can you give me some specifics of how to go about this?</i>

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 &quot;cheat&quot; 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 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.


Check out the forum guidelines!

Tue, 04/17/2007 - 01:07

Hi Again Joe,

Thanks for your detailed reply, gives insight into your position, and I can appreciate your points.

Re: SuEXEC; im assuming you mean (similiar) within NGinx, and NOT Nginx running as CGI in Apache (which wld completely defeat the point).
By no stretch do I claim to KNOW either Apache or NGinx, but I did do the same extensive research (um . . . google) as you. And then I stopped and thought 'SuEXEC is an Apache feature - of crs Nginx wouldnt have it'. But Im pretty sure it has similiar.

A bit of clarity around this would be appreciated before I start doing some research of my own; as i'm unclear exactly what your requirements re: suEXEC are:
- Pls confirm you DONT mean running as CGI (pls!)
- Is having suEXEC a security requirement?
- NGinx running as a Webmin module wouldnt require Apache at all would it?
- Does a wiki/tut re: Webmin module creation exist?

Thanks again Joe!


Tue, 04/17/2007 - 01:41 (Reply to #5)
Joe's picture

<i>- Pls confirm you DONT mean running as CGI (pls!)</i>

No, FastCGI is fine. (This still means you have a separate process spawned for each domain. This is just a fact of life in virtual hosting.)

<i>- Is having suEXEC a security requirement?</i>

Yes. It means that user scripts can't look at other users data. If everything runs as user &quot;apache&quot;, then everyone can see everyones data, including database passwords and other crap.

<i>- NGinx running as a Webmin module wouldnt require Apache at all would it?</i>

I'm not sure, but I think you're asking if Webmin uses Apache for anything, and the answer is no. Webmin uses its own web server called It is not related to Apache at all and you don't need Apache installed to run Webmin.

<i>- Does a wiki/tut re: Webmin module creation exist?</i>

Yes, quite a bit of docs exist, with more being added as we speak.

There's the docs here:

And we've just launched a documentation wiki for Webmin and Usermin docs at You can see the developer section here:


These are the development chapters out of Jamie's book, and we'll be adding to it over time. (It's a wiki, anyone can add to it.)


Check out the forum guidelines!

Tue, 04/17/2007 - 01:10

A quick post of a suEXEC summary which confirmed my points:

&quot;suexec is used by the Apache HTTP Server to switch to another user before executing CGI programs. In order to achieve this, it must run as root. Since the HTTP daemon normally doesn't run as root, the suexec executable needs the setuid bit set and must be owned by root. It should never be writable for any other person than root.

For further information about the concepts and and the security model of suexec please refer to the suexec documentation (;

Sat, 04/28/2007 - 22:06

mod_suexec isn't needed for fastcgi. Nginx doesn't spawn fastcgi processes like Apache does. Fastcgi processes must be started outside Nginx (much like you'd do with a proxied backend). Apache only needs this module because it tries to spawn the fastcgi if it isn't already running and hence has to do the switch user dance.

The simple solution is to simply run the fastcgi as the user you want it run as, no suexec required.

We use this on our shared hosting boxes and frankly, it's more secure and far less of a headache than mod_suexec (which we were using previously) ever was. It has the added bonus of allowing the user who owns the process to easily control it.

Ironically, we use the spawn_fcgi utility from Lighttpd to spawn our fastcgi's (PHP included).

As far as Nginx vs Lighttpd, well, I think you'll find that *a lot* of those smart kids are jumping the lighty bandwagon real fast these days. The development model of that project is overly focused on features and not nearly enough on bug fixes (a huge memory leak in the proxy module went unfixed for months after being reported - the user reporting it was experiencing 20Mb/hour leaks, but no one cared). If you doubt this, just check their Trac tickets ;-)


Sat, 04/28/2007 - 22:11

One more thing: Nginx has such a small memory footprint and low CPU utilization, that it's entirely reasonable to give every virtual host their own Nginx instance. This was actually our original reason for moving away from a monolithic Apache setup (we tried Lighty first for several months before being tipped off about Nginx). We wanted to give our customers a lot of control and flexibility w/o a lot of headaches for ourselves.

If you are a hoster, this is a really flexible setup for your clients (not as good as a VM, but next to it). Let them run their own webserver and proxy to it from a global Nginx instance. Works great.

Sat, 04/28/2007 - 22:27

Hey Cliff,

Thanks for those points, youve pointed out the way that I knew was possible, with zilch experience with NGinx.

Joe - Would this simplify integration with WebMin/VirtualMin?
Cliff - Are you also interested in integration with VM/WM? Have you done this already?



P.s. I still haven't found anything definitive or responses re: Memory spikes with Apache/Webmin on a Xen VPS.

Sun, 04/29/2007 - 00:07

I can't speak with much authority on your Apache memory spikes, but I can offer a theory:

Apache uses two models: process per request and thread per request. These models are very similar and share a fundamental flaw (versus the async approach used by Nginx and Lighttpd): each request consumes a relatively large amount of memory *for the duration of the request*. This might sound like a &quot;duh&quot; prospect (and proponents of the async method will certainly agree), but you have to consider what this means in the context of slow clients or large downloads: if you have 1000 simultaneous requests, there will be 1000 threads/processes alive handling them. If these requests are handled quickly then it's not much of an issue (and this is typical for a webserver). However, if the client connections are slow, or Apache is proxying to a backend that is slow (frameworks such as Rails, TurboGears, Pylons, Wordpress can only handle around 30 req/s on typical hardware), then these processes will be alive much longer than expected. It's sort of like an unintentional DoS attack, consuming memory and resources such as TCP sockets.
In a VPS situation, these resources are already quite limited compared to a dedicated server, so what you're probably seeing is this:

1. lots of requests come in, Apache starts consuming memory
2. because the VPS has limited memory, swapping starts earlier than expected
3. swapping causes further slowdown in the VPS and in handling client connections, causing more processes to exist simultaneously, hence using more memory and further exacerbating the problem.

This is all speculation, but I think you'll agree it's a quite likely scenario.


Sun, 04/29/2007 - 00:24

Just as an FYI, here's a couple quotes from Nginx users running moderately large sites. In fact the quote from Bob Ippolito was from a conversation on the TurboGears list that convinced me to try Nginx in the first place (I was previously using Pound to proxy to Apache and Lighttpd):

I don't have first-hand knowledge, but I believe Bob's site is running on a single, fairly modest server, if that matters.

Also, the note on the wiki about Nginx &quot;running on many heavily loaded Russian sites&quot; is something of an understatement: Nginx powers the largest hosting company in Russia (and I believe it was originally commissioned by them). It's a bit like saying that AOLserver powers some heavily loaded US sites ;-) The fact that it's barely known outside of Russia has been (until recently) mostly due to the fact that the documentation was all in Russian.

Of course, the fact that I was able to replace Apache, Lighty and Pound for around 60 customers in one night without any English documentation (relying on only a few examples I found in blogs) speaks volumes about how sane Nginx' configuration is. Imagine having almost no Apache documentation and doing the reverse ;-) Sometimes simpler is better. If you need esoteric modules (e.g. mod_svn), then there's probably nothing to match Apache. If you just need to serve up a typical website (i.e. 80% of what's out there), then Nginx wins hands down on almost every count.


Wed, 10/14/2009 - 09:25

any news about Ngnix integration ?

Wed, 10/14/2009 - 09:36

Nothing new on this front yet, sorry!

I'll forward your post to both Joe and Jamie to make sure they both know you're asking :-)


Fri, 11/06/2009 - 01:24
Joe's picture

It's been a while, but nginx support is now planned for an upcoming release of Virtualmin.

Our focus for Virtualmin going forward is primarily on the following couple of areas:

  1. Reducing memory footprint, by making many more parts of the stack optional or remote-able (e.g. able to run on a different host, but still under the control of Virtualmin), and by careful paring back of functionality (like running a lightweight webserver like nginx instead of Apache).

  2. Improving UX and UI. Eric's going to be spending some time in this area over the next couple of months.

Functionality-wise Virtualmin is mostly complete. It's already got way more features than any other product in its space...but in some ways that's a liability. So, a lighter-weight, simpler, version of the Virtualmin stack seems like a really good way forward.

I don't know exactly how long it will be before we get nginx support's a major project, requiring a Webmin module, a ton of modifications to Virtualmin, installer modifications, packages in the repos, and a whole lot of testing and development across all of our supported platforms (this one cannot be underestimated; cross-platform support is a huge time sink). But, I do know that once Jamie starts writing code, he tends to progress at a blinding pace.


Check out the forum guidelines!

Fri, 11/06/2009 - 01:41


Wed, 03/10/2010 - 02:02

NGinx will never support run-as-user and thus a security issue still. I have had more problems with hackers and nginx then apache ever had.

That said I still have a client that insists on using nginx and wants to know the status of nginx integration.

Sat, 08/07/2010 - 13:44

I would be interested in ngnix in Webmin, too. I had performance problems with my modest virtual server, which I managed to solve partly by somehow amateurishly managing to set up Apache worker mode + PHP via FastCGI, but ngnix or Lighttpd sounds better.

Is there any news on this one?

Thu, 10/27/2011 - 07:35


Just a follow-up to see when will Virtualmin support Nghinx or Lighttpd webservers? Thanks.

Thu, 10/27/2011 - 08:19

Jamie is currently working on Nginx support -- and while we don't have a date for when exactly it will be supported, development is progressing well :-)


Topic locked