Christian Reis lives here

I know you know. But well, just in case you forgot..

Since 2004, I've been actively involved in development of Launchpad, and in 2005 I became application manager for the project, together with Steve Alexander. These days I lead a team of over 30 people at Canonical working on building a platform for the future of open source development and collaboration.

In 2003, I somehow managed an MSc degree from USP São Carlos, where I wrangled out my dissertation on defining a Process Model for Free Software Projects. My MSc project is described in two long documents (in portuguese). I graduated in Computer Engineering from UFSCar in 1997, though most of that time evaporated into swimming pools and bike trails.

A couple of years ago (just as I had decided I wanted nothing to do with computers) I discovered Free Software and Unix, and I've been working on both ever since then. I've contributed to dozens of free software projects, and I am currently an active developer for Bugzilla, PyGTK, ZODB, Kiwi and IndexedCatalog. I've worked with Web development (who hasn't?) and Usability, additionally, in the past years.

I am a partner at Async Open Source, a company that provides development and consulting services focused on on Free Software. I helped found Async in early 1999.

When I'm not pretending to be a software engineering manager I engage in outdoor sports, travelling, language and vain philosophy. I've raced mountain bikes for a couple of years now, and from 1999 to 2003 I raced a number of national-level adventure races, including the multi-day EMA 2000 and 2001.

Getting in touch with me

Online: Homepage (~kiko)
<kiko at>
Phones: +55 16 3376 0125 work
+55 16 9112 6430 mobile
Home: (map) Rua Rui Barbosa 1977
Sao Carlos, SP
Brazil 13560-330

What he's been up to

29.06.2016 Mailman errors
  • Happen. In doubt, actively check /var/log/mailman/errors, and use unshunt liberally.
23.05.2016 LXC, delays and ordering
  • I spent some time today trying to figure out why my Gerrit LXC would never start up correctly after a system reboot. The container would come up, but Gerrit wasn't running. But if you started or restarted the container manually, it would all work fine. What the hell?
  • It turns out that the problem was a dependency on another container running PostgreSQL, but what's funny is that getting the containers to start in the right order was not at all trivial.
  • First, I thought of using lxc.start.delay to delay starting the Gerrit container itself. However, it turns out that lxc.start.delay delays initializations of containers started AFTER this one; a more appropriate name might be lxc.start.postdelay or lxc.start.delayafter. So that won't help me here.
  • Given we can't delay starting the Gerrit container itself, the trick is to start the PostgreSQL container earlier, which involves using lxc.start.order (and then lxc.start.delay to block containers starting after that). But again, there's a gotcha; lxc.start.order in LXC 1.x is actually in descending order, so 99 starts before 1. That was changed in LXC 2.0 after somebody spotted the inconsistency: []
  • The final piece of gotcha is that I was kind of hoping to set the default order for *every* container in /etc/lxc/default.conf, but that file is actually only used to seed new container configs (so seed.conf might have been more appropriate) -- the place where you can drop in defaults that are used for all containers is actually in /usr/share/lxc/config/common.conf.d. I ended up modifying the configs manually, and it all works as expected. Phew!
13.04.2016 SASL PAM auth with Sendmail is hard
  • For a very long time we've wanted to use PAM authentication to enable users to relay through our mailservers, but never managed to get it working. The workaround was to define a sasldb2 file and manually maintain passwords, but that was not very practical and for new users required extra setup. Well, today I finally managed to get it working.
  • The first hint was that, in order to avoid needing a separate sasldb2 file, you need to use the LOGIN and PLAIN authentication mechanisms. I found this in a footnote at [] that goes into it in more detail; specifically:
    Adding support for CRAM-MD5 and DIGEST-MD5 complicates password-management greatly. CRAM-MD5 and DIGEST-MD5 can not authenticate against the regular password system, be it saslauthd talking to PAM (the default system the above setup uses for sendmail) or straight from local system passwords. Keeping plain-text passwords in files is just a Bad Thing, plus password synchronization becomes a problem when you have to maintain three separate passwords.
  • Getting AUTH and LOGIN enabled in took a bit of digging as is a bit confusing, but in the end I managed to get it working, including only allowing these over TLS. Reading [] would have helped.
  • The final piece was equally tricky; I edited Sendmail.conf but was a bit too eager to specify configuration, and ended up including saslauthd_path, but without the trailing "/mux" named pipe. The most annoying thing is that Sendmail just silently fails if you get that wrong -- nothing is logged. In fact, no SASL activity is logged at all by Sendmail AFAICT. The hint that this was wrong comes from here: [] and the actual documentation is here: []
  • Bonus learning for today, part 1: what dnl in the file actually means: "delete through newline", courtesy of [] It ensures that whatever comes after it never shows up in the file. Contrast with a line that starts with #, which is copied into but will become a comment there.
  • Part 2: when forwarding using .forward, a backslash prior to the name avoids further expansion, and you can use that to deliver a copy of your mail locally along with whatever else you are doing. Courtesy of []
  • Part 3: when testing sendmail in STARTTLS mode, gnutls-cli is really easy to set up, and [] describes it perfectly.
04.04.2016 Windows Backup Sucks
02.12.2015 rdiff-backup and UpdateError/UpdateErrorOne
  • While the rdiff-backup wiki has been offline for months, the [] copy is still valid. It doesn't really give great ideas, though perhaps cloning (or snapshotting, yay ZFS) the log directory would not be a bad solution to the problem.
08.09.2015 DKMS, CH9200 and LTS backported kernels
  • So to handle the server disaster I ended up replacing the board with one with only 2 ethernet ports, and our router needs 3, so I also went out and bought a USB Ethernet device. This is what I got:
     [    4.356423] usb 6-2: New USB device found, idVendor=1a86, idProduct=e092
     [    4.356434] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
     [    4.356443] usb 6-2: Product: CH9200 USB Ethernet Adapter
    Of course, is it just my luck that the device doesn't work without an out-of-tree driver?
  • DKMS to the rescue! Googling led me to a site with some debs for this device that have already been DKMS-ified: []
  • The only remaining piece was that I was missing the 3.13 kernel headers as I use a backported kernel, as [] hinded. I installed the linux-headers-generic-lts-trusty package, dpkg-reconfigure'd dkms to build the module, tweaked the interface name in /etc/udev/rules.d/70-persistent-net.conf and all was well. Phew!
  • (I say wll was well except our ADSL modem is still dead. Yuck!)
(Read older diary entries)

Complain to me if anything's broken, please?