Installing Serendipity on Debian

So I'd been slogging through the process of hardening the new server by stripping out unused services and daemons, setting up the iptables firewall, removing unused Apache modules, etc. Checked the installed packages carefully. Everyone should be like OpenBSD but oh well. Debian packages just up and launch network services, game on baby. I installed git and some supporting packages intending to play with it, and was quite suprised to see it up and running a cgi web app. Hello World!

I downloaded the Serendipity tarball, extracted it, followed the excellent setup instructions at www.s9y.org, and it was very smooth. It gave me advice about updates to the php.ini which I applied. I created the database and db user by hand, and the install script wrapped up nice and tidy.

I futzed with tightening down the permissions a bit, which are loose on install but reasonable since php install scripts have a huge number of cases to consider when they have to work on as many J. Random Host configurations as possible, without root access.

So that was easy breezy pal. Then I have a thought. I wonder if there's a Debian package?

aptitude search serendipity

Gee, there is. I feel dumb. Better use the package, that way I'll get better security updates, and get some unspecified Debian goodness. And just a one line install! So I delete the manual install of Serendipity.

aptitude install serendipity

This draws in about 9 or so automatic packages. The debconf script asks me a few questions. I have to update apache.conf to include the /etc/serendipity/apache.conf and when I run /index.php, I see that the Debian package has written an opening blog entry that says, welcome Joe, log in and configure your server. Note that it bypasses the Beginner/Expert setup options offered by Serendipity and the php.ini config advice.

Great! I'm excited! That was easy too! Now all I need is the password....which is not shown. It's not the postgres password that Debconf asked me for. Debconf didn't ask me for an admin password. huh. Some days your brain doesn't go for the obvious choices, apparently, because a couple hours later I give up on Googling and I'm doing things in psql like:

select md5('guess_password');

trying to match the password to the one in the serendipity authors table. Of course, on about guess 4, I try 'admin', which gives a matching md5 hash to the one in the table. doh.

I mean obviously, once I was in psql I could update the table with a new md5 of my own choosing, but that's not the point.

Fine. That was a total waste of an afternoon, but whatever. These things happen. I Google some more and finally turn up this bug report.

I guess as I become better at administering Debian, I'll get better at searching for package bugs in the right spot.

So, sure enough, in a subdirectory, there is a README.Debian with the default password. I did email the package maintainer with the suggestion that usability could be improved in this regard.

So I'm configuring Serendipity again, and I activate Rewrite URLs. Hey, nice feature, why not use it. Serendipity says: "/path/to/.htaccess updated successfully."

And I lose all my CSS. bah. Ok fine. Now it's time to start grepping the source. See, I'm taking my own advice.

find . | xargs grep htaccess

Eventually this leads me to ./include/functions_installer.inc.php:

function serendipity_installFiles($serendipity_core = '') {

# Debian: these two files are under /etc and not writable by serendipity
return true;

Followed by a bunch of code that is obviously not getting run.

Time to check the upstream tarball against the package.

deb-pkg --extract /var/cache/apt/archives/serendipity_1.2-1_all.deb .
find . | xargs -I{F} diff ~/build/serendipity/include/{F} {F} | grep -v 'Common subdirectories'

The addition of the "return true;" turns out to be the main source change by the package maintainer, in addition to hiding the Serendipity install review page.

The effect of this change is that Serendipity incorrectly believes that it has successfully rewritten .htaccess when it has not. It reports success to the user. But since it does successfully change the setting in the database, it begins using URLs that are not rewritten by Apache, and hence the CSS breaks.

So the user is confused, a feature is disabled incorrectly, and the deliberate disabling of a feature is not documented in the README.

In addition, the Serendipity package is constructed with dependencies on other packages such as Smarty, PEAR, Cache and HTTP. Since the Serendipity team bundles these libraries, and they don't include regression tests, clearly the Serendipity team does not want to support permutations of library versions. The whole trend in software configuration management is away from sharing libraries. (hint: it's called server virtualization). If the upstream team is not testing against permutations of libraries, why would I think that updates from dependencies are more likely to add features than add problems? (and why should any small rational team add complexity to their test matrix, they already have to install on J. Random Host.)

Dynamic linking should be used for optional features in a single app (e.g., plug-ins). Dynamically linked libraries located in standard locations for use by multiple apps is the definition of DLL Hell. That's why running a mixed Stable/Testing environment is highly susceptible to be pushed too far into Testing, because of dependencies that don't have to be there.

Static linking! It's been a good idea since the invention of the gigabyte.

At the moment, the current Debian Serendipity package is harder to install than the upstream source, and it silently disables an important feature. So I think it is fair to avoid it until improvements are made.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448782