Nginx baseline 0.1

[NoahKunin]

Includes a written guideline and a sample nginx.conf file. The conf file was based off the current stable nginx version (1.4.4.)

I reviewed everything we're doing at the Linux kernel level for conflicts or duplications. Everything is cleaned up.

[polastre]

You should be including the gzip compression into your nginx config for performance (especially mobile). The gzip_min_length is up to you.

gzip on;
gip_disable "msie6";
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js;
gzip_min_length 1000;
gzip_vary on;

[arowla]

A few questions. Do we want to include nginx config (even if just a sample) in the public repo? In my experience it has been kept separate, but I am learning as I go about best devops and security practices.

There is a bit in the middle of the sample conf about PHP... I think PHP has been completely removed from our app, so I'm assuming we don't need that, unless it's there for some other reason.

[NoahKunin]

Thanks for the sample setting! I did noticed gzip was commented out in the default vanilla .conf you get. I didn't know if @aaronsnow and @arowla have come to a consensus on these values for the version already in development. Gzip has no security issues currently, as long as you're using ≥ 1.4, which should be there version on Ubuntu 12 LTS.

@polastre: are these values you're using?

@arowla: the PHP stuff is commented out - it's part of the vanilla nginx.conf you get. I can delete out all the comments once we do a compare with whatever you're currently using. As for putting it part of the repo, that can go a few ways. Ultimately, users wanting to take advantage of our FOSS should be able pull down the repo, issue a single command, and have a fully running application on their environment of choice - along with a secure web server. If it's good enough for government security, then it's something we want to share.

Whether or not this will stay with the application repo in the medium -> term, probably not. It makes sense that for common parts of our stack (the OS baseline, the web server baseline, etc) that we pull manifests or cookbooks from a separate centralized repo. But since we haven't set that up yet, we need to check it in somewhere.

[arowla]

Re: gzip, I don't think it's ever been discussed on this project. Let's go ahead and include it.

I tested the config locally on nginx and it checked out, so when you get the gzip checked in, I'll merge the pull request and deploy to dev.

[NoahKunin]

Gzip is on now.

FYI: Did some research re: min length. It's all over the place. At some point < ~ 1000-1500, CPU time vs network delivery gains become a wash. But since that's dependent on so many factors, let's leave it at 1000 and then do some testing later to see if there is a more optimal value.

@polastre If you copied and pasted this from a .conf you're using, there's a typo on line 2, gzip is missing the "z".

Ready for merge!