SysAdmin Adventures

I use Kronolith all over the place. It’s part of the Horde application suite. It is basically a very featureful calendar server and I like it a lot. Having said that, I use it pretty much exclusively from Sunbird/Lightning because the web-interface still needs a little work in my opinion. Nonetheless it’s very good.

The Problem.
I recently rolled it out at work along with the rest of the Horde webmail suite (and some extras and tweaks), and immediately ran into a problem. I imported the CEO’s calendar without a hitch, but as soon as I tried to access it via the RPC .ics file link (i.e. via Sunbird) I discovered the problem – it was taking forever to spit the file out. I discovered I could duplicate the problem from anywhere and it always took about 50 seconds between asking for the .ics file and actually receiving it.

After MANY hours trying to debug the problem, finally resulting in using the Zend xdebug extension to produce a call-graph with time information that I could view in KCacheGrind I discovered that those 50 seconds were pretty much ALL spent in php::iconv_substr, from calls made in Horde’s String.php.

The bottom line is, in order to wrap strings to conform to the .ics file standard specification, the developers created their own wordwrap function instead of using PHP’s own wordwrap function because the latter wouldn’t do line-folding in the way required by the specification. The problem is, the Horde developers’ version is extremely inefficient in comparison to the PHP version. This hasn’t really cropped up before because (I guess) not a lot of people put much information in the “Description” section of events. Thing is, the CEO’s PA had been filling out the Description field with a duplicate of the Location and Date information along with anything else that was relevant and a long end-line that was just symbols. With all of this text to wordwrap into .ics file standard using an inefficient wordwrap function, it took forever – well 50 seconds anyway.

The Solution.
Solution the first: get the PA to stop duplicating information that was already a core part of the event object anyway and try to limit the use of the Description field. Obviously that’s not much of a solution, but I’m certain it will make a good amount of difference.

The actual solution, is simply to dump the Horde developers’ wordwrap function in favour of the native PHP function. This does make for .ics files that are not quite standards compliant, but so far I haven’t had any clients complain or fail to function properly with them. I don’t like it, but if I have to choose between standards compliance with a 50s load time and very slight non-compliance with a 3s load time, I know which I’m going to pick every time.

The change itself is tiny. Find lib/Horde/iCalendar.php and head to around line 1055. It’s line 1055 in Horde Groupware Webmail Edition v1.2.3, but it may be slightly different in your version.

Remove or comment out the lines:

and replace with:

et voilá.

I don’t believe the developers plan on fixing this problem in the Horde H3 (version 3) tree, but I am assured that they are refactoring the code for Horde 4 which should take care of it.

I wish I understood why LDAP support is so unbelievably piss-poor in so many software products. So many organisations use LDAP as their core user directory (whether OpenLDAP, Active Directory or some other LDAP implementation) or have a directory service that will provide its data via an LDAP interface. I see people screaming for LDAP support in everything, but so little support from software coders/vendors; I can only assume because they personally don’t have much LDAP experience. Just about every F/OSS software project claims to have LDAP support, but because someone who didn’t totally understand the application itself wrote some add-on code to make it work. This leaves everyone else following poor instructions for adding-in support to an application that really should be supporting LDAP natively from day one.

For Request Tracker from BestPractical, I ended up re-writing the very limited user-contributed code that already existed into a fully-fledged extension for LDAP support. But it’s still not easy for RT administrators because my extension is not part of the core RT code; it is tacked-on over the top and, while I try to make it as easy as possible, people still run into problems with implementation. Also, when they need new features and I don’t have the time to implement them (which I don’t), they’re left up the creek with no paddle because the core development team didn’t write it and don’t intend to pick it up and code new features into it. In the case of RT, there is the suggestion that the LDAP code will be integrated into the next big version (RT4), but it is literally years too late.

At the moment I am having intense headaches over Foswiki, the fork of TWiki. This is the type of system that was born for use in organisations with existing user databases, but still getting it to take its user information out of LDAP is a NIGHTMARE. The basic principle is simple: have some perl code do an LDAP bind when a user tries to login, and if successful, do a search on their information and then map that information into the application based on a simple variable map. It’s how LDAP works in every app I’ve ever come across. But, to get this working in Foswiki you have to install four extensions (LdapContrib, LdapNgPlugin, GluePlugin & NewUserPlugin), you have to go through activating and configuring each plugin, and telling the login system which one of the three (confusing and not well documented) options it should use for each of the processes, then you have to go into the Wiki pages themselves and start again. You have to write (in a special Wiki code you won’t be familiar with) your own templates for gathering the LDAP information and then code up how you’re going to pass this to the NewUserPlugin so that during auto-registration some magical process can take place to update the user’s information. And I’m willing to bet that if I want the information to stay up to date with the LDAP database I will need a fifth plugin to check for changes during login as Login doesn’t normally handle user information, that’s a registration thing.

It’s the same all over. Pick pretty much any F/OSS web-app you like that requires a user database and you will find that LDAP support is either not-present, tacked on haphazardly, or is available only via user-contributed code of varying quality and documentation.

DEVELOPERS: PLEASE FOR THE LOVE OF GOD GET YOUR ACTS TOGETHER!!


When you design an application like these, your user authentication and information systems need to be able to handle an LDAP (or sql for that matter) back-end. It’s really not difficult. In most languages the template code for the ldap searches and binds has been done for you, you just have to use it. I do what I can to provide good code to help people get LDAP working in their apps but it is not easy and there’s only one of me.

LDAP is easy, but each individual application has its own way of doing user authentication. If I want to put LDAP code into an app, it means I have to understand the nuances of the code and then write around it. In systems such as RT and Foswiki, the authentication systems are so complex it can take weeks to get up to speed with how they work, even with direct input from the developers themselves. I just don’t have the time to learn every authentication system ever written. If the developers themselves took a moment to realise how simple it is to add LDAP support to code they already understand, and then to get off their arses and *do* it, life would be a lot easier for everyone and it wouldn’t be so hard to implement these systems in company networks. That means we could finally start pulling away from “pay someone else to do it” mentality that has companies throwing thousands of pounds at piss-poor software vendors just to save from spending the time working out how to do it themselves.

If you are running an apache web server and serving content to the public, you are either running AWStats, or you are an idiot.

I used to be an idiot. Now I am running AWStats.