November 2007 Archives

In http://www.dbmail.org/mantis/view.php?id=655, Mr. Maenaka writes:

MySQL's automatic reconnection is unsafe because of the following reason.First, SET NAMES query is a required arbitration between server and client if both's character encoding is different. This should be done at the time of connection open. (Of course you can issue SET NAMES between every query with the huge overhead though.) By the way, MySQL's automatic reconnection is made transparent to the client. So the client never know that SET NAMES should be issued again. Therefore, if the connection is restored this way, the character encoding mismatch may occur (and some or all data is garbled or lost). 

A problem I've been thinking about for a long time was how to build a backend service for a stateless web frontend. All of the solutions I have seen involve building a daemon that lives on the server and holds the persistent data. Or, in the case of PHP, weird ass service side session cookie things built right into the language.

The solution I want is a hack that is as full featured as building a daemon and does not require modifying the operating environment. And today it hit me: the two request monty.

Here's the setup: you have a script that's running in the web server, it has an execution time limit, you're allowed to create and listen on sockets. Yes, I'm thinking of PHP safe mode here. To create the service, your web app makes a request back to the host web server, spinning up the service script. That script then creates a socket listening to some local port, tries to increase its max execution time, sets a timer for just under whatever that time limit is, writes this information to some common location (typically the database behind your web app) then begins listening on the socket for requests for whatever kind of persistent data you need. When the timer fires, the script makes a request back to the host web server, spinning up a new service script. The new service spins up on some other port, connects to the first service and grabs all of its data, then writes its information to the database and begins serving persistent data to your application.

Total hack beyond hack, but satisfies the requirements: does not require a new daemon, does not require new modules on the server, runs in safe mode, runs with time limits. 

Lately at work a few folks have been batting around possible solutions to the perceived problem of how hard it is to run Perl code from Apache. Of course there are very good solutions, mod_cgi, mod_fastcgi, and best of all mod_perl. But there are very good reasons why web hosts shy away from CGI, and why they're deathly afraid of FastCGI and mod_perl. In a nutshell, it all comes down to persistence. PHP is incredibly popular because there is no persistence!

 Byrne Reese had the idea of taking mod_php and ripping out the calls to the PHP interpreter, replacing them with a Perl interpreter. "I don't think it's quite that simple..." I said. But Byrne was 80% correct. The other 20% is grabbing the Apache - PerlIO layer from mod_perl and using that to shovel data from STDIN and STDOUT in and out of the Perl script. The resulting code is pretty simple!

 mod_perlite is over at the Six Apart open source code repository, and I've been working on it off and on for just a few days. It builds, loads into Apache extremely simply, and returns "Just Another Perl Hacker" anytime you try to get a page that ends in ".pl"

 Fundamentally, mod_perlite tries not to solve all your problems. It is specifically targeted at being 80% good at the 80% problem. With luck, we'll be able to get it onto 64% of web servers like PHP and pals.

 To Do:

• Thrash at the Apache - PerlIO interface some more.
• Develop a script caching model (ala Zend Accelerator or APC).
• Add a script run-timer to kill long-running scripts (ala PHP's max_execution_time limit).

The crux of my SSL management headache is that I have a lot of domains, but only four public IP addresses. I bet that most home-operated sites are like that. I also have a number of different applications running -- HTTPS, SMTPS, and IMAPS in particular. For each HTTPS domain, I need to have an SSL key that is bound to that domain. But since most of the domains are virtual hosts on a single IP, I don't know the domain until after the SSL negotiation. TLS is supposed to solve some of this, I think, but there's enough SSL out there that I need to deal with it. A tool that can tell me that I have { X } number of HTTPS domains but only { X, n > 0 : X-n } IPs, and allow me to pick which ones get keys, then generate the keys for me, would be grand! Furthermore, I often create convenience sub-domains for particular applications to facilitate portable DNS inside and outside of my home firewall. smtp.serendipity.cx, for example, resolves differently inside and outside my firewall. Outside the firewall, it resolves the same as serendipity.cx. Inside the firewall, it does not, since I don't NAT my servers from the inside. So I need separate SSL keys for these two domains. But they're also different apps, so there's no IP conflict. Am I making sense? Yeah, so I need an open source SSL key management app. Or I need to write one ;-)