SSL Support?

[benjaminws]

This is more like a feature request.. I've started down the road of making this work, but I'd wondered if you had already tackled it or could give me some pointers :)

[cep21]

You mean you want to health check an SSL connection: the health check should be over SSL? You should be able to health check over non SSL, but still make the user use SSL. Is that good enough?

[benjaminws]

I'd much prefer the check to actually be over SSL, mainly because the upstreams are SSL only. I'm working on this, when I get it working I'll notify you.

[cep21]

Sounds interesting. The current healthcheck module uses its own HTTP implementation in order to do health checks, so it could be difficult to use SSL while checking the backends.

Let me know if you make any progress!

[benjaminws]

I noticed that ;). We'll see how it goes. So far, it's been pretty difficult.

[kgray]

I was also looking for the same functionality, if you get anything created Benjamin, I'd be happy to help test out. Jack, when you mentioned in your first response about a way to have the health check go over non-SSL while still requiring a user to use SSL, can you elaborate? At least in our setup, that would be ok. Thanks for your time.

[benjaminws]

kgray; I'll let you know. I will be working on it this week.

[cep21]

@benjaminws: I tried for a bit to integrate nginx's internal stuff to do the health checking, so I wouldn't have to implement HTTP myself. I couldn't figure out how, but that could be the easiest way to do SSL.

@kgray: The health checking module is pretty independent. If you have an upstream anywhere in your config and put inside it healthcheck directives you should start to see health checking. Does SSL work with upstreams? If so, it should work with the healthcheck plugin.

[benjaminws]

@cep21: I've abandoned the SSL support for now. It's hairy and I don't have the time to sit down with it. I'm working another angle using a specific port for the check (set by a config variable healthcheck_port). Basically it temporarily modifies the port on the sockaddr for the check, then sets it back. My concern is a request coming into that upstream during the time I have set the port for the check. I see you have some locking logic, but it looks to be just to keep the workers from stepping on each other for the checks. Will that also keep a worker from sending other requests during the check? My fear is that it wont, but I'm not sure.

[cep21]

Yea my locking is only for the health check framework. If you wanted to use your own data without worrying about messing other stuff up, you could malloc it and put it somewhere only the health check module uses.

[benjaminws]

@cep21: cool. I'll work that out. Basically keep it in it's own memory space, not the shared nginx memory pool?

Also, here's something else I was working on..

http://dpaste.de/X1TN/

Basically output's the lb stats in json (could do json or html). I chose json because it's easy and ultra portable. Below the output is a python session showing how easy it is (with no external libs) to use json for this in python.

[cep21]

That's neat. I was thinking about using json instead of HTML when I wrote the endpoint. One thing I did was make it valid XML so that you could similarly parse it out with an XML library. Still, XML libraries are harder to use than JSON ones.

[yaoweibin]

I add the feature of ssl_hello check, but it's changed a lot. This is my fork: https://github.com/yaoweibin/nginx_upstream_check_module