What exactly is it and where can we read up on it?

Sounds like hooking Nginx to Apache. How about config? Separate interface? etc. etc. etc.

Thats exactly what it is:
http://atomicorp.com/company/blogs.html

Tried it out and there are some issues
1. It creates both a domain.com .conf and www. domain.com .conf file. Only the former is needed and the latter just creates a conflict.

2. @fallback location should not be commented out since it is being called under "location /"

3. No matter how many times you type "yum remove", it always comes up saying it has been removed. conversely, if you remove and reinstall, you get a message saying it is already install. IOW, "yum remove" does not work.

4. Consider other plesk events such as deletion of domains and subdomains. Similarly, domain alias creation, deletion and updating (particularly mail on or off) would be nice

5. Consider making PHP 5.2.13-3 with the php-fpm fix posted in the forum and then adding commented out fastcgi configs to the vhost template so users can decide to use nginx for php instead of proxying to apache. Not a plug and play option though

6. The article needs expansion so that users know what they are getting.

7. The blog rejected my comments as too long even though the counter said I still had 20 characters left.

this proto is 100% worth future development

I agree, we've been testing it out on the gotroot server for the last month.

Some updates were put out on this yesterday, and I'll add a few notes:

1) the fallback 404 code, the configuration tokens dont seem right. They definitely fail on nginx 0.76 as invalid. That being said, without them 404 custom error codes are working.

2) On a test system with 122 domains nginx would fail to start, and we had to modify these settings:
server_names_hash_max_size 512;
server_names_hash_bucket_size 128;

The documentation is kind of cryptic on this, but my guess is that the latter bucket_size setting would have to be greater than the number of server directives in the config. That could pose problems with plesk integration, since now we have to calculate it.

3) If a domain configured in the configs does not resolve, then nginx will fail hard. Again that means some kind of lint code to detect that condition. Or maybe there is a way to make nginx soft-fail when this comes up

4) Applications like mediawiki, and phpbb will pick up the PORT variable and use it in their code internally. So as of right now some application level code has to be changed, otherwise your URL's look like: http://domain.com:8080/index.php. So far Ive seen this happen with mediawiki in general, and with the phpBB code used to mail a user that a thread has been responded to.

One thought here might be to bind apache to a different IP instead of a port. Maybe an RFC 1918 IP.

Last note is more of a success report, we added atomic-accelerator to a system with very very high load issues (100+), and low (1G) of ram. Adding atomic-accelerator to the environment knocked that down below 1, performance was also improved considerably. Stellar success in its part, so clearly this is something worth continued development.

The 404 Fallback only works under "location" it seems. I put it in the wrong part (directly under "Server") in the example I gave before. BTW, a lot of the stuff in the docs saying where things work ("http", "server", location") are wrong.

This actually deals with the length of domain names and not the number of domains. One of the 122 domains has a long name that meant it couldn't be handled by the hash table. I gather that a bucket size value of 64 will handle most long names. A value of 128 will put things on the safe side and there should be no need to do calculations. The max size should be equal to, or a multiple of the bucket size. Note though that the Nginx Developer says the smaller the better for this.

Dunno about this. What does "not resolve" mean? Domain does not exist on the sever or DNS related? If not found on the server, then there should be code in the config as defaut server to show boiler plate page (my earlier nginx.conf did not have this). If it does not resolve due to DNS problems then the request wouldn't hit the server in the first place. Clarification needed.

You may try to set the port_in_redirect parameter to "off" or "on" if already "off". Funny though. If it simply proxies to Apache, then a simple php app should not have anything to do with such things. Whenever I start seeing the port in urls, it means something is not configured properly.

As a general thing, you need to watch caching as the way it is set up for this forum means people will have problems logging in as they will always get served a cached non logged in state page unless they tick the "always log me in" box. Looks to me like the cache keys need looking at.

I gave the port_in_redirect a shot, it might help on the phpBB code (Im waiting for the test data now) but no luck with mediawiki. Its apparently hard coded:

"$SERVER_PORT" is available to Nginx and it might be possible to manipulate it. If so, then this can be done in an 'if' or 'location' section specific to mediawiki.

Read up on the 3rd party NginxHttpHeadersMoreModule and the standard proxy_set_header.

You will have to rebuild nginx to include the third party module if it proves useful.

*****
ps. It seems the main nginx site uses mediawiki (http://wiki.nginx.org/NginxMediaWiki) and don't seem to have the same issue although they are running nginx direct and not proxying to apache. Running php on nginx does mean proxying to fastcgi though.

mike had a clever idea for this, run nginx on port 8080, then use a firewall rule to transparently redirect traffic to it, which then hands it back to apache.

Oh also, nginx doesn't support mod_security. Thats the real reason why its being used as a proxy.

We do not recommend you use nginx as your web server, if you do you will have NO protection from web threats. There is no plug in WAF for nginx (like mod_security), so if you do this understand that you're probably going to get owned. We only recommend you use it as a proxy to apache, and let apache handle everything else.

If you do use nginx as your web server, make sure you have a WAF running in front of it.

Saying one will have NO protection from web threats and will get "owned" is a bit OTT but then, not wishing to be snarky, I wouldn't expect Turkeys to endorse Christmas either.

Mod_Sec is a very useful tool and may indeed be critical to some but is certainly not the only way to protect a server from web threats. Otherwise this means the 10 million or so sites using Nginx including some of the world's busiest websites such as wordpress.com are totally naked and on their way to getting "owned". Anyway, I have no wish to turn this into something else as I myself am back to proxying to Apache (albeit without Mod_Sec and the rules due to resource reasons) and have to say I hold you guys in high regard.

Back on track with Scott, I think you need to look at your cache settings for this forum. It needs to be set so that when you visit and then log in, you don't get served the page from before you logged in. This is what is happening to me and probably others who don't know how to get around it as well. You might be able to see a drop in the number of posts in your records.

You need to look at your cache keys. If you have not explicitly set "proxy_cache_key" then it defaults to "$scheme$proxy_host$request_uri" which would be the reason for this issue as I will guess that for this site, it needs to be "$scheme$proxy_host$request_uri$cookie_SID". Obviously you'll need to have "proxy_pass_header Set-Cookie;" set.

This might be part of the "8080 appearing problem" which by the way still exists and I can see it right now. Personally, I don't believe using ip rules is the answer as it is not addressing the real cause of the issue which is a misconfiguration ... such as the one with your cache pointed out above.

By the way Scott, any chance of doing a build of Cherokee? Seems a very interesting project. Ubuntu users can "apt-get" it but can find a repo on Fedora, RHEL or Centos with it.

Uhm... I'd say about 80% of the value of ASL is in modsec and modsec doesn't work with nginx (yet). While saying you probably would get owned using it is overstated, it's certainly far less secure than Apache with modsec and ASL rules. Really it's not the web server but the underlying apps you have to be worried about. Modsec just tries to stop it before it gets that far.

1) Ok proxy cache key is set in /etc/nginx/nginx.conf, I was never experiencing a problem with this so your in a better place to measure the effectiveness for this.

2) Custom 404's work on all the test environments I've looked at so far. Looking back at the fallback 404 stuff this seems to make it not necessary. Or did I miss something?

3) Ive tried changing between redirect, proxy_pass and a few other settings to catch the 8080 effect. All to no effect, do you have a test environment where you can help me debug it? Given your first comment you've relegated yourself to resident nginx fanboi status, so lets get this to a state where everybody can use it without having to think about it. I think thats going to be the real secret to success, if Plesk users have to make modifications on their own its going be a very high barrier to adoption.

4) On cherokee, maybe. Do you know if a) what its license is (We've got to be allowed to redistribute it) and b) does it support mod_security, ioncube, zend, etc.

OK, this is a little OT, but for the benefit of anyone that follows this thread from a search engine I need to respond to this.

And you're welcome to ignore my advice on this, I don't want anyone to think I'm saying you have to protect your systems, etc. If you choose not to, so be it, I'm just passing my advice and experience, do with it as you will.

So, first of all I am not saying you can not run nginx securely. What I said was that you have to run a WAF in front of it. There is no plug in WAF for nginx, so how do the big sites do it? The put a WAF in front of it. So, to repeat, if you run nginx or ANY web server alone you should expect to get compromised. Thats not OTT, thats a fact. I'll go on to explain.

IMHO, running a web server these days without input validation protection is asking for trouble. Unless you can know that your box and all its web applications are vulnerability free sooner or later you will see applications, databases and probably even the server get compromised if you don't have some kind of input validation in place to protect it. Since its very very hard to know if something is vulnerability free (lets just say its essentially an undoable thing, lots of time and energy is spent making some software more secure, and so far no one has been able to prove an application does not have any vulnerabilities), we should assume our applications probably have some vulnerabilities.

Because there is no plug in solution for nginx to detect web attacks and to protect you from it, using nginx alone to protect your web applications won't do it for you. So, unless you run a WAF in front of it or know your apps are vuln free, sooner or later you're going to get owned.

So, the big sites that run nginx put WAFs in front of it. So, if you are not going to use mod_security as built into apache, and you're going to run nginx as your web server then you need to go buy a nice big expensive WAF appliance and plop it front of your web server.

Why is input validation important? Programmers are human beings and they make mistakes (I do it all the time). Input validation helps to protect you from the consequences of those mistakes. Applications are swiss cheese. I've written over 10K virtual patches alone in the last few years just for the major web apps. Its very very hard to write an application thats completely vulnerability free just as its hard to write a really complicated application to do lots of complicated stuff. Now compound that with all the people writing web apps, multipled by all the web apps out there, now compound that with all the apps using libraries written by someone else (and lets all be honest, thats what modern OSes do for us, we have no idea whats in those libraries no one has the time to read every last line of code their CPU is processing), now add in all the other code written by someone else thats all used, linked in, and relied upon and you are guaranteed to be running some web app that has a hole in it somewhere.

So, running a web server without input validation is like sky diving without a reserve, sooner or later something will go wrong, and then you have nothing to fall back on and its game over. I am a skydiver, I pack my own chute. I would *never* jump without a reserve packed by someone else licensed by the FAA as a rigger. I might make a mistaken with my main, and I might make the same mistake with my reserve. So I need something to make up for my imperfections.

The problem is worse for web applications than it is for skydivers because its not just a failure or a simple mistake you want to prevent, its intelligent malicious actions by human beings you must prevent. Imagine someone deliberately sabotaged my chutes, or was shooting at me as I dropped. I need some kind of security system to protect my chutes and myself, I need to lock up my chute between jumps, I need some checks on who packed my reserve. I need something to make sure my chute hasnt been sabotaged, and I need some protection from those bullets. Thankfully, no one is shooting at me when I jump for fun (it might have been different when I was in the Army, which is a different story) but web applications are not as lucky, and they need that kind of protection. They get attacked all day and all night.

nginx is not a security system, it was not built to stop web attacks - its just a web server. Don't expect it to protect you. Its a GREAT web server, there just isn't anything to protect it standing alone. If you want to use nginx as your web server you need to run a WAF in front of it or you run a very real risk of your web applications getting compromised, and more often than not, that will also them to compromise the server and whats on it.

So is it OTT to say you will get owned, I don't think so, but don't take my word for it just ask around.