Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx 1.6.0 stable released

nginx.org

Post reply on HN
Print view View original

71–80 of 114 posts

Re: Nginx 1.6.0 stable released

#71

Post by DrJ »

cheald wrote: post #21
marshallford wrote: post #19

I figure this is as good of place as any to ask my question: Where can I find someone to hire that is able to write Nginx cofigs well. I have spent literally 40ish hours trying to create a Nginx conf that holds up to my OCD. I have been told numerous times on IRC that I am too picky and clean urls are a challenge to write. I am college student and System Administration isn't even my job! Help!

I'm pretty sure the best way to accomplish this is to jump into IRC and declare that it is impossible to be done. You will have 6 answers in 3 minutes.

this is literally happening in this thread

Re: Nginx 1.6.0 stable released

#72

Post by bithive123 »

feld wrote: post #68
omh wrote: post #56

Earlier quoted context omitted.

In some cases it would be useful to perform session handling like this in nginx. I like the idea of building a reverse proxy which handles authentication and sessions, in front of a backend web page which wasn't designed to handle it. Something like giving access to an old internal intranet without having to change the app.

this reminds me of a government agency that permits access by IP addresses whitelisted in IIS. Can't put fancy caching or load balancing in front because it can't understand X-Forwarded-For, etc. tl;dr build your authentication into your app, not the web server layer.

There are plenty of upsides to decoupling authentication from your app codebases. For instance, in an enterprise where you have a single sign-on solution implemented as a web server module and a mix of third party and bespoke web apps.

Re: Nginx 1.6.0 stable released

#73

Post by nilsbunger »

marshallford wrote: post #57
nilsbunger wrote: post #41

Earlier quoted context omitted.

Try odesk? If you have a clear spec for what you want you can probably get a fixed-price bid.

Even the word "odesk" leaves a bad taste in my mouth. I have heard a lot of bad things about these kinds of freelance sites.

Have you used them? Like anything, odesk/elance/etc require an investment on your side to make successful.

We've found good people through odesk to take on tasks we weren't good at -- front-end javascript, document translation, audio transcription, to name a few.

Re: Nginx 1.6.0 stable released

#74

Post by mixedbit »

clarkevans wrote: post #45

I wish there were better authentication options with Nginx. The ngx_http_auth_request_module is limited: First, it assumes that the authentication agent doesn't need to talk to the user. Second, it doesn't cache the authentication. Perhaps nginx might instead check all requests for a particular signed cookie, verify the signature, if the signature matches, verify that the cookie isn't too old, and then unpack variabl…

This isn't correct, you can use auth_request when authentication agent needs to talk to the user. I can't even see how it could be used without such communication.

Re: Nginx 1.6.0 stable released

#75

Post by X-Istence »

clarkevans wrote: post #45

I wish there were better authentication options with Nginx. The ngx_http_auth_request_module is limited: First, it assumes that the authentication agent doesn't need to talk to the user. Second, it doesn't cache the authentication. Perhaps nginx might instead check all requests for a particular signed cookie, verify the signature, if the signature matches, verify that the cookie isn't too old, and then unpack variabl…

That signed cookie scheme you are talking about exists in Apache as AuthTkt...

Re: Nginx 1.6.0 stable released

#76

Post by richardjs »

jcampbell1 wrote: post #70
richardjs wrote: post #47

Earlier quoted context omitted.

Your specs look a lot like ours (we have a CMS that adds a trailing /index to every page that is part of the core navigation, and we don't want that). Here's the three primary rewrite rules we use for the issue; they don't match your spec exactly, but they might help you get started: # - Remove trailing slashes (except root /) # e.g. /foo/bar/ -> /foo/bar # ([^^] matches every character but the start of the string) r…

I have had problems using rewrite in this way. The URL that rewrite analyses may have already been changed by `index` or some other command, and this will lead to redirect loops. To avoid that problem, I have used: if ($request_uri ~* "^(.*)\.html?$") { return 301 $1; } The above is a safe use of "if", and can be helpful since it operates on the actual uri, not the internal uri.

That's a good suggestion. Yeah, index directives will cause a redirect loop in my above configuration. The try_files directive is effectively taking the place of an index.

Re: Nginx 1.6.0 stable released

#77

Post by atom7 »

Afforess wrote: post #63
pedrogk wrote: post #27

Waiting for package for Ubuntu 12.04 and crossing my fingers that it comes with SPDY enabled so I don't have to compile it. I know, I am lazy :P.

Nginx has an Ubuntu PPA. http://wiki.nginx.org/Install#Ubuntu_PPA

It hasn't. "This PPA is maintained by volunteers and is not distributed by nginx.org."

Re: Nginx 1.6.0 stable released

#79

Post by e12e »

porker wrote: post #44
e12e wrote: post #36

Earlier quoted context omitted.

Having managed a fairly complex apache based web site (lots of rewriting to maintain various legacy url schemes, a few cgi bin apps -- lots of cruft) -- I do think Apache is more flexible than nginx. Traffic server is probably more flexible still. On the other hand, you could say if you take a routing problem, and you attempt to fix it via mod_rewrite -- you now have (at least) two problems! ;-) There was a fairly re…

> I would normally advice an architecture where you have a reverse proxy in front of application servers My understanding too is that as we containerize more applications (whether this be Jails, Zones or Docker) then for shared-IP addresses (e.g. VirtualHosts) we need a reverse proxy to do the mapping to the correct container. Do you know anything about this, as my research hasn't found anything?

Well, if you're not using ipv6 it can be a bit tricky to map a (public) ip to each application server/container/whatnot. For web services you need a front-end router/proxy that understands http host headers and/or SNI (for ssl). If you have that, you can map stuff in DNS, and still use just port 80/443 on the "user facing" side:

client sends "host: some.service.example.com" -> proxy (alias for some.service.example.com) routes -> internal-ip:port

If you have enough public ips (be that ipv4 or ipv6) the "proxy" can just be a firewall rule that maps/NATs public-ip:80 to service:80 (or whatever). Not that that is necessarily a good idea.

Virtualhosting and proxying are related to containerizing (containing?) services -- but you could for example set up your reverse proxy in one container, map all traffic there, and then after deciphering host-headers and/or SNI route traffic to different back-ends.

It depends on what your needs are. For low traffic services, simply having the container answer on an external ip might be fine.

If you want to do more sophisticated load-balancing some system needs to take care of that, typically between the client and the back-end server (DNS only allows for round-robin distribution, barring tricks like giving different replies depending on who (from where) is asking).

Personally I'm leaning towards moving my "internal" ip-related stuff to ipv6 and only multihoming my outward facing points to ipv4 -- for simplicity. It does mean I actually have to set up firewall rules again, as most "internal" systems are now technically exposed. I guess it depends on how one draws the line -- does the container manage its own SSL/TLS termination (if applicable)?

Re: Nginx 1.6.0 stable released

#80

Post by FooBarWidget »

pedrocr wrote: post #5

I'm currently running apache 2.2.22 on my Ubuntu 12.04 servers. It works fine. I'll be moving them to 14.04 and thus getting apache 2.4.7. I mostly use it for mod_passenger webapps and static sites. 14.04 includes nginx 1.4.6 but I'm sure the phusion guys will package 1.6 soon so I can easily upgrade to that. Is there any killer feature in nginx that I'm missing, staying with apache 2.4?

> 14.04 includes nginx 1.4.6 but I'm sure the phusion guys will package 1.6 soon so I can easily upgrade to that.

Yup. We're working on 14.04 packages too.

Post reply on HN