Entries by Filip Van Raemdonck

While performing some research on the article about lighttpd, PHP and SSL I wrote a few days ago, I found out about a practical joke in Google's search results for the phrase “Once in a blue moon”.
The first result returned is an answer from Google Calculator, and the result they give is “1.16699016 × 10^-8 hertz”.

While this was obviously not a `serious´ answer, it had to make sense somehow — but it didn't immediately occur to me what it might mean. When I found out how often a “blue moon” actually occurs, every 2.7 years approximately, it seemed obvious that the above number had to be the frequency of that event. A little math confirmed this; inverse the above number and you get a number in seconds which is approximately 2.7 and then something.

Nice easter egg from the Google crew.

Mid august, “responsability” will get a new meaning: my wife is into the 15th week of our third pregnancy.
We actually already should've become parents last november, but almost halfway through the first pregnancy the child had stopped growing and was diagnosed with trisomy 13, because of a hereditary Robertsonian translocation that Veerle turned out to be having. Short of waiting for the pregnancy to spontaneously abort, the only way to deliver the child was induced labour. We already knew from the karyogram that had uncovered the trisomy syndrome that it was a boy, though it was impossible to see that. The little fellow was about two thirds the length he should've been, and weighed about one third the normal weight.

We visited a fertility clinic a few weeks afterwards, but were told that the actual chance of us getting a healthy baby was a lot higher when we would naturally conceive than through in vitro fertilization. The only advantage of the latter method would be near elimination of the 50% chance to a failed pregnancy of natural conception. (For clarification: due to the translocation, there's a two-in-four chance that a conceived child carries an incorrect number of chromosomes; such embryos have a near-zero chance of making it through the pregnancy)

By the end of summer, Veerle was pregnant again. This time however it lasted for only seven weeks, after which the foetus died. Examination of a tissue sample again uncovered trisomy 13 syndrome. And it was again a boy.

Now it's the third pregnancy, and almost three weeks ago a chorionic villus sampling was performed to determine if this time the child would be healthy. Although a FISH (“fluorescent in situ hybridization”) test performed in the first two days showed no sign of problems, it was only after the liberating phonecall that came in yesterday that we could take a deep breath and smile. The baby has inherited the Robertsonian translocation though, but that doesn't lessen our joy.

As a side effect of the karyogram, we also know the gender weeks before ultrasound might reveal it. However, I haven't secured the necessary permit to disclose this information. I'll tell everyone in half a year from now...

First, a question: dear lazyweb, how do I completely disable non-SSL access with lighttpd? I can't seem to find how to have a lighttpd SSL-only configuration. (and only binding port 80 on localhost does not count for an answer)

On to the subject. While it's easy to add SSL to lighttpd and enable PHP (through fastcgi) — and Debian makes it even easier with it's lighty-enable-mod tool — if you only do it once in a blue moon then it's not exactly resident knowledge. So here are the steps to do it, on Debian Etch:

1. apt-get the lighttpd, php4-cgi or php5-cgi, and openssl packages
2. lighty-enable-mod fastcgi
3. if using php5, update the path to the cgi binary in /etc/lighttpd/conf-available/10-fastcgi.conf (it's preconfigured for php4)
4. lighty-enable-mod ssl
5. update the path to the SSL certificate in /etc/lighttpd/conf-available/10-ssl.conf
6. restart the lighttpd server

That's all there is to it. Well, strictly speaking there's a step 4a: install a certificate; but that's arguably not a part of the configuration process.
(for reference: openssl req -new -x509 -keyout /etc/lighttpd/selfcert.pem -out /etc/lighttpd/selfcert.pem -days 365 -nodes will generate a self-signed certificate)

A little utility that has been collecting dust on my harddrive over the past two years is an enhanced version of a PyGTK exception handling module that was originally posted to the PyGTK mailing list by Gustavo Carneiro. I've now uploaded it to the sysfs download area; it is essentially unlicensed, considered public domain by Gustavo according to his email message.

Besides fixing a API incompatibility with recent PyGTK releases, there are two main differences with the original functionality.
First, I've modified the traceback formatting to include two lines of context to each line in the traceback, one before and one after the called line. Also included is a printout of the identifiers referenced in the traceback lines — variables, usually. On my personal wishlist was also syntax coloring in the debug window, but this was both non-trivial to implement, and it would likely add considerably to the complexity of the error handler, thus increasing the chances that the error handler itself would fail.
The other main functionality change is possibility to email feedback to a predefined address — mainly meant for deployment and debugging of company-internal applications. To enable this feature, two identifiers feedback and smtphost must be set on the module. This can be either by modifying the code, or, better, by adding them after module import:

import gtkexcepthook
gtkexcepthook.feedback = 'valid@email.address.here'
gtkexcepthook.smtphost = 'relay.smtp.hostname'

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.

Recently I've been debugging a SQL Server 2005 replication setup, where the "Distribution clean up" job for the distributor database was failing. The error message in the agent history was:

Executed as user: <sqlagent_serviceuser>. Could not remove directory <UNC_path_to_snapshot_directory>.
Check the security context of xp_cmdshell and close other processes that may be accessing the directory.
[SQLSTATE 42000] (Error 20015).  The step failed.

The “<sqlagent_serviceuser>” was the Windows user that the SQL Server Agent service was running under, while the “<UNC_path_to_snapshot_directory>” was the network path to the directory where snapshots where created.

Looking around on some discussion forums, I found the same message reported several times but without any real solution; at least no solution that would work when I tried to apply it to this particular setup. Most answers to the problem focused on the xp_cmdshell procedure mentioned in the error, and how it would require certain configuration at the server end.

However, one answer on the MSDN forums did give a useful clue — it pointed to the SQL Books Online article about Securing the Snapshot Folder (which I should've read right away, really). In a note, this page reads:

If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. [...]

It's the SQL Server service account reference which is essential: even though the SQL Agent service account may be the one mentioned in the error message, the actual account that is used to try and delete the snapshot directories is the SQL Server service account instead. Giving that service account the necessary access rights fixed the problem; as in the Task Scheduler case, accurate error reporting on Microsoft's side might go a long way towards people disliking their software less.

John, don't get too excited.
I hate to disappoint you, but I got #1 for “mysql takeover” on the very day I wrote about it. I also seem to be #1 for “CEST software”, simply because these are appearing next to each other whenever I post something about software, during CEST months. And I was on top for “converting from metres per seconds to metres per days”, too, but my silly post about it from two days ago already took over. For all I know, there are a few more like these, though none are obvious from search referrals yet.

I guess being on a few planets might be very good to your Google karma. (or should I say, pagerank?)

To the people looking for a way of converting from metres per seconds to metres per days: multiply your value by 86400 (60 for seconds in a minute, times 60 for minutes in an hour, times 24 for hours in a day).

One of the disadvantages of using dynamic web pages, is that you might end up serving pages (depending on how the application works) that basically say: "I can't find what you're looking for". Over the last hour I've kept half an eye onto the webserver logs for this weblog, and noticed that the Google crawler tried to index pages which simply aren't there, like for example an archive view for the year 2083. But the underlying PHP script happily returns a HTTP 200 status, with the message that filters don't match anything. Hardly useful.
I also ran trough a large part of the site, checking if any page could refer to such 2083 archive, but haven't found any links to it. Which leaves me wonder why Google came to it.

On faulty pages; for the last couple of days I've also been updating the script code to some extent, and through the log following of the server logs I noticed that some links were broken (and did not return 200 but 404 instead, or, in case of the comment code, made it impossible to post anything at all). Largely due to modification of a global in some code path, which variable was used later to build up these broken links.
I think I've covered all faulty links; but if I oversaw any please let me know, I can be reached by email at mechanix on rack66.net.