software

Last week I needed a way of converting a two-dimensional array, in perl, into a tree-like datastructure.
While seemingly trivial, the convoluted use of references when passing around arrays and hashes between perl function calls -- recursive calls, in this case -- made this a mind-boggling exercise to me. (the fact that I hadn't seriously used perl in the last eight years might have had part in that, too)

Below the jump is my implementation, debugging info left in and all. If it's useful for someone, that's great; if not, ... well, except for my mental sanity no harm was done in writing this, either :) Continue reading "Perl hash tree helper"

One annoyance with the lilo bootloader that I've ran into a few times recently, is that it apparently turns any root configuration arguments into a device number. Which is then passed to the kernel at boot.
So if the kernel decides to assign a different device number to the supposed root device, your system may no longer boot.

Yesterday I once again ran into this: when I added an additional disk to a system, the LVM volumes which were on that new disk got assigned device numbers before the existing system LVM volumes.
Giving the problem a little thought, I realized that the solution — though silly — is really simple: add an “append="root=/dev/yournode"” directive to lilo.conf, and this boot-time argument will always override the root device set by lilo.

No more changing root devices for me…

For a while now I had been planning to move this blog a different server and URL; a URL that I would have full control over instead of the user directory it was deployed in.

I also had been longing for a different blog platform some time. While the primary reason for choosing Blosxom.PHP, that it did not depend on a database server, still held, I also had gotten tired of having to dig into it's code (usually in several places) for things that in my opinion should not require having to make changes all over the place.

So when the ageing server that held the old blog had temporary IO problems last weekend, I considered the time ready for making the move. Continue reading "Blog migration"

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

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.

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.