Home / user-21628

Nate's questions

Martin Hope
Nate
Asked: 2014-11-22 09:10:20 +0800 CST
  • 2

I'm running an SSL-required web service and planning to switch hosting providers. To avoid downtime for our users while DNS caches clear, I'm planning to proxy requests from our old server to the new one for a few days. Both the old and new site are running nginx and openssl.

I have a setup that appears to work perfectly in Chrome and Firefox, but fails in Safari and curl.

The proxy config section in my old server's nginx (1.6.2) config is pretty simple:

upstream droplet {
    server zin.droplets.gimlet.us:443;
}

server {
    listen   80;
        listen   443 ssl;
        server_name demo.gimlet.us;
#   proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#   proxy_ssl_session_reuse off;
    proxy_set_header Host       $host;
    location / {
        proxy_pass https://droplet;
    }
    error_log /tmp/proxy_error.log;
    access_log /tmp/proxy_access.log;
}

(changing proxy_ssl_protocols and proxy_ssl_session_reuse doesn't seem to make a difference)

Interestingly, the requests from Safari and curl don't generate log entries in my /tmp logs. However, in the main error.log, I get an entry like:

2014/11/21 17:02:08 [alert] 2937#0: worker process 13634 exited on signal 11

The output from curl -v suggests a good SSL handshake happens and then something goes awry:

$ curl -v https://demo.gimlet.us/favicon.ico
* About to connect() to demo.gimlet.us port 443 (#0)
*   Trying 74.50.48.201...
* connected
* Connected to demo.gimlet.us (74.50.48.201) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: description=e08NImA1P8R1ukwA; C=US; ST=Wisconsin; L=Madison; O=Nathanael Vack; CN=*.gimlet.us; [email protected]
*    start date: 2014-04-10 16:59:37 GMT
*    expire date: 2016-04-11 09:29:37 GMT
*    subjectAltName: demo.gimlet.us matched
*    issuer: C=IL; O=StartCom Ltd.; OU=Secure Digital Certificate Signing; CN=StartCom Class 2 Primary Intermediate Server CA
*    SSL certificate verify ok.
> GET /favicon.ico HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8z zlib/1.2.5
> Host: demo.gimlet.us
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host demo.gimlet.us left intact
curl: (52) Empty reply from server
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

Also notably, doing

$ curl http://demo.gimlet.us/favicon.ico

works fine.

I feel like I'm missing something very basic here. Any suggestions as to where I can look for more ideas?

nginx
Martin Hope
Nate
Asked: 2014-08-16 18:50:43 +0800 CST
  • 0

I'm looking to replace an aging and decidedly suboptimal mysqldump-based database backup strategy with Percona's Xtrabackup. This all looks pretty straightforward, except that I'm wondering: how many incremental backups should I keep between full backups?

I realize that restoring from a long set of incrementals would be somewhat tedious, but it looks like it'd be pretty easy to script.

I also imagine that if I somehow lose an incremental that's part of a backup set, I would lose everything from that point on. That seems like it'd be unlikely (these guys will be headed to S3), but still a bad day.

Are there rules of thumb about this sort of thing? Would hourly incrementals with a complete backup a week (so, 168 files per backup set) be insane, or normal for some workloads?

FWIW, we're looking at a ~10M row database, growing at ~20k rows a day, very few changed rows (ie, append-mostly). So the incrementals would be pretty small.

mysql
Martin Hope
Nate
Asked: 2012-04-26 17:00:08 +0800 CST
  • 6

So, I'm working on an upstart init script for mysql. Should be trivial, right? My stop stanza looks like:

kill timeout 30
stop on runlevel [016]

I shutdown now -r, and mysql yells about my MyISAM tables being crashed, just like I'd kill -9'd my mysql process. Boo. Upstart doesn't seem to be waiting for mysql to quit before restarting. Some searching on Google finds me this link suggesting I do, instead:

stop on starting rc RUNLEVEL=[016]

and indeed, that seems to fix the problem.

But: WFT? Essentially, I want to make sure mysql is stopped before trying to unmount the local filesystems. Is this the right way to do this? Why is my stop on runlevel stanza not waiting for mysql to stop before switching runlevels?

And: is this y'know, documented anywhere?

ubuntu upstart runlevel
Martin Hope
Nate
Asked: 2009-10-01 08:36:58 +0800 CST
  • 1

I'm trying to get a Django + mod_fcgid setup working (mod_wsgi is tricky as I have a statically-linked Python. Don't ask.) While this was trivial on my Mac OS X development box, getting it running on the server has, so far, proven impossible.

With this configuration

LoadModule fcgid_module modules/mod_fcgid.so

FCGIDSocketPath run/mod_fcgid
FCGIDSharememPath run/mod_fcgid/fcgid_shm

ScriptAliasMatch  /apps/([^/]+)(/.*)? /var/www/apps/$1/apache/dispatch.fcgi$2

<DirectoryMatch ^/var/www/apps/([^/]+)/apache>
  SetHandler fcgid-script
  Order allow,deny
  Allow from all
  Options +ExecCGI
</DirectoryMatch>

and this example dispatch.fcgi:

#!/usr/bin/python
import sys

sys.path.insert(0, '/var/www/lib/python2.5/site-packages/flup-1.0.2.egg')

def myapp(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return ['This is my hello world test!\n']

if __name__ == '__main__':
    from flup.server.fcgi import WSGIServer
    WSGIServer(myapp).run()

Browsing to my test page yields a 500 error and in my Apache error logs, I get:

WSGIServer: missing FastCGI param REQUEST_METHOD required by WSGI!
WSGIServer: missing FastCGI param SERVER_NAME required by WSGI!
WSGIServer: missing FastCGI param SERVER_PORT required by WSGI!
WSGIServer: missing FastCGI param SERVER_PROTOCOL required by WSGI!
Status: 200 OK
Content-Type: text/plain
Content-Length: 29

This is my hello world test!
[Wed Sep 30 11:09:18 2009] [notice] mod_fcgid: process /var/www/apps/test/apache/dispatch.fcgi(31043) exit(server exited), terminated by calling exit(), return code: 0

There's my output, looking great -- except in Apache's error log, not my browser window.

When I remove my SetHandler directive, the output goes right where I want it; obviously, it's running in ordinary CGI mode. That's not high-performing enough for my Django app, which gets 1-2 second page load times in that configuration.

So far, I have tried:

  • flup 1.0.2, flup 1.0.3 development version, and a random fcgi.py written by flup's author
  • threaded and prefork versions of my FastCGI server
  • An RPM version of mod_fcgid and Apache's SVN version
  • Python 2.4 and Python 2.5 (py2.4 isn't a realistic deployment option, but for testing...)
  • AliasMatch / ScriptAliasMatch / mod_rewrite

Nothing seems to make any difference, except that using AliasMatch shows me the source, which is rather as I'd expected.

Again, this was absolutely trivial on Mac OS X. It Just Works with a comparable configuration.

Other than getting a better Python and using mod_wsgi (which is possible, if a pain), how do I make it work?

apache-2.2