Configuring OpenLDAP, or what the @#$% !!!

OpenLDAP 2.3 (released in 2005) introduced a new way for configuring the slapd daemon. The traditional method was a configuration file (/etc/ldap/slapd.conf on Debian) that could simply be edited with a text editor. The new way follows the Eat your own dog food maxim: The configuration is stored in a set of LDIF files (stored under /etc/ldap/slapd.d in Debian) which cannot be edited directly with a text editor. Instead, all changes must be done via LDAP operations. Funny enough: In order to configure the daemon, the daemon must already be running.

slapd-config, as the new configuration method is called, may be a technically cool feature, but from a casual sysadmin's point of view it is nothing but a major pain in the butt! So you want to quickly change slapd's log level to diagnose some authentication problem? OK, first check the documentation to see where the log level option is located in the configuration schema, and how its attribute is called. Then query the running daemon to look at the current value(s). Then write an .ldif file that contains the change. Then issue a complicated ldapmodify command that requires more cryptic options than tar and cpio combined. Of course the .ldif file contains an error, so diagnose & repeat. After maybe 20 minutes the job is done. Phew, only 20 minutes to change the daemon log level, I am such an LDAP wizard!

Actually when I did this just now it took me more like an hour because I am so not used to the procedure (another explanation might be that I'm just stupid, but hey, I think that's not it). Since I don't want to repeat the experience, I have started to write up some recipes on my wiki. Here's the link in case you are interested.

Article Styles: 
Topics: 

Spammers are getting better

Another 19 months have passed since my last report from the spam front. This time the news is not so good.

Although the overall spam rate has dropped again, for the third time in a row, and is now at 11 messages per day (down from 14 messages per day), the other side of the medal is that SpamAssassin's recognition rate has also dropped for the third time in a row. This time the drop has been so marked that it has overcome the benefits of the spam rate drop, causing the average number of spam mails that have made it into my inbox to increase to 1.6 messages/day (up from 1.4 the last time).

This is the first increase of that all-important figure since I switched to greylisting almost 5 years ago! This turnaround is slightly scary because it means that for the first time ever spammers have actually become better in getting their junk into my inbox. I refuse to be overly alarmed at this point, and I hope that this trend will not continue, but if it does I will have to consider new measures, such as starting to use blacklists.

For more statistics details, see this wiki page.

Topics: 

Little Go 1.1.2 released

Little Go 1.1.2 has just been released to the App Store. This is another bugfix release that contains a couple of fixes for potential crashes (#243, #247), one drawing bug (#245) and one regression (#246).

The harmless seeming drawing bug #245 probably was the root cause for the crashes that so many people experienced in version 1.1.0. The quick&dirty bugfix that I shipped in 1.1.1 (#242) merely turned a crashing bug into a drawing bug, but with the release of 1.1.2 the root cause should now be fixed as well. Since I am not 100% sure, I didn't have the stomach to remove the quick&dirty fix yet.

Software Projects: 
Article Styles: 

Little Go 1.1.1 released

Little Go 1.1.1 has been released to the App Store yesterday. This version contains an urgent fix for a crash that sometimes occurs while a stone is dragged around the board (#242). The crash was clearly affecting a lot of people because after merely 3 days I had already received over 400 crash reports - almost double the amount of reports that were sent over the last 6 months.

Fortunately, the crash reports clearly showed me where the crash was happening, and why (initializing an NSArray with a nil object). Unfortunately, the actual root cause that leads to the error condition did not became clear, even after several hours of detailed analysis. Due to the urgency of the problem, in the end I had to implement and ship a quick&dirty fix. I am not proud of this, but at least it seems to be effective: Now that the bugfix release is live on the App Store the crash reports have stopped pouring in.

Software Projects: 
Article Styles: 

Little Go 1.1.0 released

Little Go 1.1.0 has been released to the App Store today. The GitHub issue tracker has a list of all issues that I worked on for 1.1.0, and here is an excerpt of the changelog with the user-visible changes:

  • The app's user interface has been updated to the iOS 7 look & feel (#204).
  • Drawing for Retina displays has been fixed (#205). Many thanks to Eric O. Lebigot for reporting the issue and giving me the necessary KITB to investigate the problem.

In addition to these changes, another two items that are not user-visible turned out to be major time sinks:

  • I decided to adopt Auto Layout as a replacement for manually calculated view frames (#206). After the usual initial learning curve, the real problems that cropped up were always related to the new iOS 7 bar handling (e.g. when to use view controller properties like edgesForExtendedLayout and automaticallyAdjustsScrollViewInsets). In a desperate last minute effort I even wrote my own implementation of a split view controller because I simply could not get UIKit's UISplitViewController to work reliably (issue 236 has the details).
  • In a fit of complete insanity I decided to rewrite the app's board drawing code, with the goal to reduce memory usage when the board is zoomed in (issues 212, issue 214 and issue 215). This took me another month to complete, but the scheme succeeded beautifully - ignoring the memory gobbled up by Fuego, peak memory usage dropped from 170 MB to 67 MB (measuring "dirty size" with the "VM Tracker" instrument). For details check out the Research document, section "Memory usage after adding tiling").

Last but not least, I had a hard time analyzing crash reports. In the 6 months since the 1.0.0 release I received 230 crash reports. Roughly 70% of these seem to originate from the same root cause, which unfortunately I have been unable to pinpoint. A major part of my difficulties was that crash log symbolication provided me with an impossible stack trace, i.e. the last code line in the Little Go source code could not have invoked the UIKit method that was shown by the stack trace. I don't understand the details of the symbolication process, so I can't even guess how something like that is possible (except, of course, a wrong .dSYM file, but I can guarantee that this not the case!). Anyway, very frustrating, and I hope I will find the bug in the next version.

Software Projects: 
Article Styles: 

Pages

Subscribe to herzbube.ch RSS