Niles the LG HomBot Repaired — RTFM Helps

Niles, our LG HomBot robot vacuum cleaner, would clean our house going in a couple of circles and in under 3 minutes, declare the job done — you know, with that triumphant tune that it makes — and return to its home station.

That almost got Niles to be out of a job, especially since when I tried to navigate it through the house manually (well, with the remote control), it would not move forward — instead it would move backward slowly.

The smart diagnosis reported some sensors were blocked, which I believed I had cleaned, so imagine my surprise when the manual illustrated more sensors… Niles has been bumping in to things occasionally (nothing disastrous) and had residue on the sides of the front (just a tiny little bit further down the sides from the outer infra-red sensors) and the back — like what you get on your car if you bump in to another car. Funny, because these are collision sensors — yet that’s where it collided apparently.

Another day, Another fix

Today sees another important fix for Kolab — in the SASL authentication daemon we ship, to be precise.

Our version of the SASL authentication daemon is a necessity for multi-domain environments. john@example.org may need to be authenticated against ldap://ldap.example.org/?dc=example,dc=org, while john@company.com may need to be authenticated against ldap://ldap.company.com/?o=company,c=ch.

The Kolab SASL authentication daemon performs this task based on discovery — but to discover time and time again for every single authentication request creates too many connections, too many searches and basically overloads the LDAP servers for larger deployments.

The chicken way out would be to cache the username and a one-way hash of the password — but Kolab is no chicken. We like LDAP to remain completely authoritative for authentication (so you can apply account suspension policies in a centralized manner).

So, instead, for each search we have performed in the past, save a base dn, filter and the resulting object entry DN. This makes us quick to resolve what root dn is used for @example.org, namely dc=example,dc=org, and which one is used for @company.com, namely o=company,c=ch. We do the actual search for john@example.org once, and we save (&(objectclass=kolabinetorgperson)(mail=john.doe@example.org)) having previously resulted in uid=doe,ou=People,dc=example,dc=org. We can then perform a fast bind using the object entry DN to verify the password, and update the timestamp on the cache entry every time it is successful.

So far, so good. However:

For a user however (a particularly volatile object), the position in the tree might change. When the object entry DN changes, the cached entry (that holds the bind DN) is no longer valid, and the cache would first need to expire before a new search is executed, and authentication would start to succeed once more — not good.

I originally implemented the cache for a particular use-case in which the object entry DN could not change, but repeated searches were too expensive, and had not taken the volatile object entry DN use-case — most other organizations running Kolab, probably.

The fix includes a couple of items, including only purging a cached entry before re-attempting authentication if the actual response to the original authentication attempt (against the cached bind DN) failed with a NO_SUCH_OBJECT error (code 32).

Welcome to the complexities of doing a little bit of coding on the side.

latexdiff — how hard can it be?

Screaming and shouting, cursing and other French — as in … pardon my French …

All it took was:

  • sudo yum -y install texlive-latexdiff
    (This is the result of “yum search latexdiff”)
  • latexdiff /path/to/old.tex /path/to/new.tex > diff.tex
  • latexpdf diff.tex
  • xdg-open diff.pdf

Ne c’est pas si difficile, non?

Upgraded Domicile; We are Back!

I’ve upgraded my domicile, by relocating from the not-at-all privacy-friendly United Kingdom to the ever so neutral Switzerland.

I finally got around to restoring some of the functionality that used to be on my co-located server, with help of a friend, so slowly but surely we should be seeing http://puppetmanaged.org get back up again (the git repositories are back already).

Naturally this Puppet server (of puppetmanaged.org) is itself managed by Puppet (the puppet module).

Naturally it runs Kolab Groupware. We could be seeing a kolab module for Puppet soon ;-)