software

Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!

I've quickly written a demo application to show how it's done.

The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in the first screenshot.

The actual code to the demo application is rather brief. Continue reading "PyGTK/glade object reuse"

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.