My Nginx config complete or sort of with an appendix on TLS/SSL

Nice! Thanks for sharing your config. I learned quite a bit.

Looks good, thanks.

I don't turn off logging for robots.txt. I'm pretty sure that awstats uses that info to help decide who is a spider.

I think that

Really nice! Some neat tricks I hadn't seen before.

Only one small correction:
limit_conn arbeit 10; on lines 17 and 57 in sites-available/example.com... "arbeit" isn't a common zone name as far as I know ;)

I appreciate the great compilation and well documented config. It's helped me learn quite a bit.

I'm very new to nginx and stuck. On a fresh Ubuntu 10.4, I used Brian Mercer's PPAs for nginx and php-fpm. I cloned your config and changed example.com to my domain (both the filename and occurrences in the file). I also verified the correct socket path in your config as well as Brian's php5-fpm.config

All services are running, however nothing is getting served and there are no entries in nginx's /var/log/nginx/access.log. I'm assuming one of the 444 responses?

My server isn't nameserved yet, only accessible by IP - would that complicate matters? Could anyone point me in right direction?

Thanks!

What are your thoughts concerning

I'm wondering since nginx.conf includes everything in sites-enabled, isn't it loading all the non-server files also like blacklist.conf, drupal.conf, etc. It would load them on the http level and then overwrite them on the server level? Do they need to be in another directory?

My setup is a little different.

It was working fine with Drupal7-beta1, but I tried installing with Drupal7-beta3 today and it's giving errors while installing the modules during the initial install. Did you install beta3?

With beta1 I made no alterations to the settings.php. It's using the default without base_url defined.

Drupal 7-beta3 works without issues with Nginx and SSL enabled/forced in Aegir. I'm using standard Octopus Aegir install and the result is: https://skitch.com/omega8cc/rnnq2/fullscreen#lightbox

There is no need for base_url set at all. But of course you should have fastcgi_param  HTTPS  on;. Compare how it is done in the Nginx config for Aegir.

This site runs on Nginx and has rating 93: https://www.ssllabs.com/ssldb/analyze.html?d=www.governmentexchange.com so it is possible, however they probably enabled ONLY TLSv1 (SSLv3 has to be disabled) to receive FIPS-ready and are using patched (or older) Nginx with newer openssl, since it shows: "Secure Renegotiation Supported". The 88 rating is a standard result with default SSL Nginx settings.

if in php.ini cgi.fix_pathinfo != 0

rewrite in location ~ .php$

Hi,

I'm really new to nginx - so I might be doing something wrong here.
I've followed your instructions closely but when I try to start Nginx, I get this error:

I understand that the port Nginx usually listens to is already in use, but I have no idea by what. Apache does not run on my server...

Any advice appreciated :)

Thank you

in config file use

listen 80;

not

listen [::]:80;

What do the logs say? Have you tried it with another browser or using curl or wget? That's a very anomalous situation. Nginx can handle much more load than Apache and consumes much less resources.

I haven't used Safari ever, so I can't relate to that. But there are people on the list complaining about Safari and Keep Alive connections. By default Nginx disables it, there's now a patch, included in 0.9.0 and later, that allows you to control that setting.

That symptom seems to be nothing new: E.g., http://forum.nginx.org/read.php?2,4743,4744

How are you controlling the PHP CGI? Are you using an init script? Have you stated that the process must (re)spawn when serving requests?

AFAIK, there are two ways of controlling the PHP CGI:

1. Using php-cgi and an init script.

2. Using php-fpm that has its own controlling layer.

I use 1. because I'm too lazy to rebuild the gazillion of debian packages with the php-fpm patch for 5.2.14. I had no problems with php-cgi so far. I use monit for monitoring the php-cgi process and doing a restart if needed.

Brian and Grace can chime in on their experience with php-fpm.

I want to know what may be causing problems.

Can you post the config you're using here or in any pastebin kind of service?

Thanks,
António

Can you provide an example of an URL that exposes the modulesdirectory?

Unfortunately you can't restrict the module directories because modules have their own .css and .js in there, and those must be publicly accessible.

Perusio's config and mine does block access to .inc, .txt, .module, .info files in there (and anything else that's not css/js/jpg), but it's really not a big deal since they don't contain any sensitive stuff, just the stock modules from drupal.org. Most configs don't restrict that stuff.

If you've put sensitive stuff into module directories you're doing something wrong.

Hello perusio,

Thanks for this nginx conf; I haven't digested everything but I already picked up some good practices. I saw that Brian Mercer is contributing to Nginx documentation over at nginx.org and there's an nginx conf in the boost issue queue modified by him, another one in groups by Grace, and this one. I've started with a D6 conf from the nginx.org site by another author, and am in the process of merging the various confs for my environment.

Grace's conf is probably the most comprehensive, Brian's modification seems easier to start with, and I'm looking through the lines of this one.

Some questions/comments/nitpicking/appreciation:

I know you use Debian, but I'm thinking perhaps you built from source. I've installed from squeeze packages, but have yet to determine if that has modules such as upload support. It comes with a conf.d directory, and git doesn't allow empty directories? Anyway, I put everything aside from nginx.conf into that directory.

The auth basic support, ssl conf lines, and nginx_ensite are a nice touch. Here's my suggestions.

Script support doesn't carry over for all Oses I think, perhaps limit support for Debian/Ubuntu and wait for a module.

There are two server blocks. There are some wildcard options .example.com can be used with domain access/dns wildcards to redirect. Not the best way to redirect if performance is a top concern and if you rely on domain access, but I'm using memory based apc. You can also do: server_name example.com www.example.com; Not sure why rewrites are a concern to change to the www subdomain, unless robots.txt and seo comes into play. If people type in www.example.com as opposed to example.com more, you can switch the order. I'm in the middle of figuring out how to get rid of the trailing slash for the frontpage url.

Put the disable all methods directive (HEAD, GET and POST) and put that inside blacklist.conf and rename the file. Also include a directive to stop image hijacking in the renamed file.

What is : # location ^~ /progress {

report_uploads uploads;

} ? I'll also take a look at your documentation.

Since nginx loads stuff sequentially into memory, I try to do the same, and also alphabetically for regex matching. For regex of nginx, I don't see the value of multiple locations to avoid regex, and would rather spend time on comments and not having to scroll. Nginx probably does it's own form of regex at the location level anyway or doesn't have specialized indexes available, like in a relational database. I would think that using combining locations would be fine, since it should be loaded in memory, unless it can be proved otherwise. An understanding of how nginx handles regex would help. Like some regex implementations still try to match after a match hasn't been found, or cannot be found, ex: regex /pat, and the uri is bat. Some implementations would stop immediately after the first letter, if it's a character literal. If Igor put the same care in location based matching as he did with his regex implementation, I think using character literals in order, restraining matches (any type of checks), and using wildcards would be fine. It probably just depends on the order the regex is done. So if locations are in order, the regex matches should also be done in order. That also goes for the nginx.conf file directives, where I'm blindly putting stuff in order of how I think it loads, and how I group the lines to manage them.

I'm going to take a look at Grace's config after this, since I noticed it has og directives. Afterwards, the fastcgi_params directives. I didn't see a need for additional files either, like fastcgi.conf, since I put that stuff at the bottom of the fastcgi_params file.

I've made changes to my files, and a lot of it looks good so far, thanks. =)