Kivy: canvas.before, canvas.after and canvas

So I have a fair amount of trouble wrapping my head around kivy. The docs aren't great, they're not bad, but it can be hard to find the exact information I'm looking for. So I decided that while I'm programming, I'll use my fairly defunct blog to document the stuff I wasn't able to find explained really easy.

First off, canvas. It took me a little while to figure this out, but as a canvas is an App based thing (not a Widget based thing, as I was expecting when I first started doing something with it), the developers of kivy gave you access to three different canvasses. They are all drawn after another. The first canvas to be drawn is canvas.before. After that, the "normal" canvas is drawn. Lastly, you get the content of canvas.after. Essentially, you have get three layers that you can use to draw upon!

Hope this helped someone! Drop me a note on Twitter if it does, it'll help me to write more.

Review: Driving a Renault Zoë, the Six Months Mark

As I was updating my blog to Nikola, I decided it would be interesting to write a review of my 6 months old car. It's a 100% electric one, so I think people might actually be interested in the experiences we've had with it. To spoil the ending, the electric driving experience is awesome, but Renault's software is shitty. Let's break it all up in details.

Driving Electric

This is most definitely the best part of it all. Driving electric is fun, no doubt about that. The car's acceleration is awesome. The acceleration pedal has two 'levels'. The first one is the normal acceleration mode, which gives you a normal not too slow acceleration to your desired speed. You then hit a barrier, which is strong enough to rest your foot comfortable against when driving with the speed limiter on. Once you press the pedal down, though, things get even more fun, when the car gets a boosts that really pulls you down into the back of your seat. I don't use it often, but it's nice if you need an additional bump to pass a slower driver.

The most heard question I get about the car has to do with the distance limit. Yes, you can only drive about 100 to 120km on a single battery load. But in the last six months, this has been a problem only twice. Once when we were expected a charger at a destination that ended up not fitting the Zoë. The second time was due to bad planning and me forgetting to plug in the car the night before. We generally don't do more that 40-50km per day, which works fine. Most people tend to forget that you start with a full battery every morning. You do not have to plan for stops at a charger, since we have one at home. And that's actually an added luxury by itself, starting with a full 'tank' every morning.

The charging itself can take a while, but since we do not deplete the entire battery most of the time, for us it's generally done in a few hours. That's at the slowest speed, since we have a cheapo charger at home. Most public chargers could charge the entire battery in about 2 to 3 hours, the speed chargers can charge it to 80% in 30 minutes. I haven't had to use that yet, but I can imagine it being a welcome break after you drove 110km. It is something to take into account on longer drives, however. What I generally do is simply not use the Zoë when driving further than 100km. My dad has a normal gasoline based car that we're generally able to borrow. And even if we can't, since electricity is so much cheaper than gas, renting a car for a few days isn't that big of a deal. My total yearly savings are far larger than the rent for a car for a few days.

So no, I do not have any problem at all with the shorter range and the longer charge times. But admittedly, we don't need to drive long stretches.

The car has all kinds of luxury options that I really appreciate. Things like the cruise control (which I hardly use, to be honest) and the speed limiter (which I use all the time) are nice to have. The cruise control can be a boon when driving longer, the speed limiter can allow you to keep your eyes on the road. With the speed limiter, you simply set the maximum speed you want to drive using the steer controls and then press down the acceleration until the first rest. The car will not go faster than what you've set, and thus allows you to keep your eyes on the road. Great feature!

The car radio speakers are good, which is an extra boon because the car is so quiet! Especially when driving slowly, the car is very silent. It makes a zooming sound when you drive slower than 30km/h to warn pedestrians and bikers that you're riding behind them, otherwise they get no warning at all. When you go faster than 30 km/h, the sound that the tires makes will warn people ahead of you. In any case, it's very comfortable to drive an electric car due to the lack of noise. The most sound it makes is the air blower and of course the radio.

Car Build

The car is more or less compact, but with pretty broad bars around the windows. This does impede with the view, especially when you want to look out for bikers on a roundabout (but who wants to do that??? j/k). The doors open easily, but the doors for the back seats have a strange contraption to open them. You need to swivel a plastic part to allow you to lift it and open the door. Not everyone can find it at first. The effect is that the handle is nicely tucked away and doesn't stand out.

The key is a wireless key. As an IT guy, that makes me cringe a bit, but I haven't seen any hacks for it (yet). And I must admit that it's a neat feature, you just need to have the key somewhere in one of your pockets to open the doors. You need to stand pretty close to the car as well, if I'm standing at the front with the key, you cannot open the doors. I'll need to move a little bit more towards the doors for that. I assume this means the range is very limited and this harder to hack. There are four buttons on the key, one to open the charge socket, one to start the preheater and two more for locking and unlocking the doors. The buttons react nicely, but I would've appreciated a little bit more feedback, for example when you start the preheater. I always need to open the front door to check if the signals lights blink once, to make sure the signal reached the car.

For a smallish car, it's spacious enough. The front seats are slightly raised, due to the battery on the car's floor. It makes getting out of the car a little easier on my very pregnant fiancée, though. The digital dashboard is easily viewed and contains the most interesting stuff. It also shows you how much energy you're using, which can be convenient when you're trying to save as much as possible. I miss indicators for the front lights and the wipers though. They have multiple settings, but sometimes it's hard to determine whether they're simply off or on automatic (both the lights as the wipers react to sensors automatically, if they're set to that). You'll need to check around the steering wheel to see at what setting they are. The wipers on auto do not always react the way you expect them too, either wiping too often or to little, so we tend to set them on manual eventually.

The seat belts are fine, nothing to nag about those. Except maybe that the back seat belts are very picky on the lock you put them in. There's a sensor in there that shows you on the dashboard if the back seat belts have been closed and how many of them are closed. Due to the middle seat belt, which uses two locks, you need to make sure you lock yours in the correct one, or else the lock is not registered. Kids do not care about that, so they often simply put the belt in the first lock they get their hands on, which often is the one for the middle belt and this doesn't trigger the message on the dashboard. That feels like it hasn't been designed well enough, since you expect this feature to be most useful for checking on your kids...

On the plus side, the middle seat does have a proper three-point belt, which feels safer if you happen to have three kids on the back seats.

The trunk has enough room. You open it often, since it's the most convenient place to store your charging cable. I would've liked something to easily store away the cable, though. The dealer gave us a bag, but it's too much hassle to roll up the cable tight enough to put it in the bag every day.

The car has a rear viewing camera built in, which is neat (when it works, more on that later). It's not hugely necessary, since you do have a decent view through the back window, but it does help when you try to move in a smaller space. Or when you need to turn on a small road.

Software Hell

The big downer is the R-Link software that comes with the car. It truly, truly sucks. It really feels like someone developed a proof of concept and Renault simply ran with that. I'm getting all kinds of warning regarding subscriptions and the like, I don't want to see those. There's no obvious way to remove them from the interface, so they always stay there requesting attention. The same for updates, which sometimes work, sometimes don't work, but always remove all your settings.

The stuff is exposing problems that also seem to indicate an underpowered system. Things like taking several minutes to get the rear view camera screen working. Even more annoying, the distance detectors respond slowly as well. This can lead to an increase in the frequency of the beeps when you've already hit the breaks. I can see how this may lead to accidents and damage to the car or worse, other people's property. Especially since the rear view camera and the distance sensors give you a sense of finer control of the car when you do these sort of maneuvers.

The interface sometimes takes a very long time to respond at all, which can ben annoying. We've had the thing reboot while driving for no apparant reason. Sometimes when you switch a bit too fast with the on-steer controls, the thing reboots. You can make a bluetooth connection with your phone, which can be nice when you get the connection, but very often it simply cannot find your phone.

There's a Tomtom integrated into the system that reads the map data from an SD card, which it sometimes can't find at all. Luckily, we do not need to use the navigation that often and have Google Maps on our phones, but still, very inconvenient. Especially when it stops being able to read the SD card while you're actually using the navigation and you're almost there.

The Tomtom actually has some additional features for electric cars, mainly it can show you if it thinks you can make it all the way to your endpoint based on the current battery status. It can direct you to chargers, but it also shows you chargers that have no support for the Renault connector. Which it handily notifies you of, but without providing you with an alternative. We've had an instance where we actually had to use it and we were scrolling through two pages of charge points before resorting to the (very excellent!) New Motion App.

There's an outside temperature display that starts blinking when it's at 3 degrees C or lower, without an option to stop the blinking. That can be very annoying, since you constantly see something blink in the corner of your eyes. The display has a very handy night setting, to which it switches automatically when the car determines the light outside is too low. That sensor will also automatically switch on your lights, of course. Interesting idea, but the display seems to lack the manual option to make this switch (I couldn't find it at least), which is very annoying when it's pitch dark outside and the display determines it wants the daylight setting. The display can be very bright then, when everything around you is pretty dark, which is very annoying. I had this happen to me twice now, the second time I simply turned off the entire R-Link (restarting it didn't seem to help) system, so it wouldn't bother my vision.

The thing thinks it's very important to warn you everytime it cannot find your phone, which sounds logically, if there wasn't a color coded phone icon next to it that already shows the status of the phone connection.

All in all, I'm really not happy with that part of the car. It feels like a first generation smart phone that still needs a lot of work. Which I think is very bad for a car, since you want to be able to depend on it. Renault, shame on you. Go get yourself a proper software design department with proper QA and UX designers. Or simply make the entire thing open source and let the hackers solve your problems with this. It really cannot get much worse than what you're already putting out there.

And then I haven't even mentioned the remote app for the car. Which is a very interesting addition, considering the car is making a connection to a central Renault server every so often via it's own phone connection. But the whole thing is pretty badly thought out. The Android app for instance let's you plan a start time for the preheater, but only allows you to enter a time. Sounds reasonable, you probably don't want to plan the preheater three days in advance. However, the time entered has to be today. So it's not possible to plan the preheater for, say, 7:45am on 10pm the night before. The app does send the time, but the server responds with a message indicating that the time entered is in the past... Really, really bad design. And don't get me started about the unstability of the Android app... They must be getting a huge amount of crash reports!

Then there's the browser app which lets you plan the times at which you want your car to charge. This can be convenient when you have a two tiered electricity plan, where electricity used during low hours is cheaper than during peak hours. You can plan one continuous block for an entire day. Our low hours start at 10pm and stop at 6am, but I cannot enter this. I have to choose to either start at 10pm and stop at midnight, or start at midnight and stop at 6am. There's no way to tell it to charge between 10pm and 6am. Again, very bad design, IMHO.

Temperature Control

The car has an automated temperature control. A very interesting one, since it tries to save energy by simply not heating the car. Or at least heat it very slowly. It can take up to 30 minutes before you notice the car getting warmer, even when you started the preheater before you got into the car. I'm used to cars in which you can set the dials on warmest and the car actually gets warm within a few minutes.

The preheater hardly helps, especially because it's hardcoded to stop after 5 minutes. If we start it again two or three times, it does help a little, but it's very annoying that it doesn't do this automatically.

This wouldn't bug me enough generally, since I'm pretty warmblooded. But my finacée has a bun in the oven, so to say, we're expecting our daughter somewhere this week or the next. This makes the lack of proper heating a problem, since you need to take it into account when taking our daughter with us, especially during the winter months. Babies actually need a lot of outside heat, y'know.


I love driving electric. I really do. As long as I can afford the cars, I'll try to keep driving electric for the rest of my life. But probably no longer in a Renault. Their R-link system is so buggy, I'd love to try something else. A Leaf or iMiev would be interesting. But never a Renault again. Which is a shame, because I loved my 2005 Renault Kangoo. It worked great and I rarely had problems with it. The electric system on the Zoë is fine and driving it is really nice, but the R-link frustrates more than it helps. Also, Renault made the decision to rent out the battery for a very steep €75 per month. This negates any savings you'll have by no longer having the pump gasoline in it. Leasing it makes those charges invisible, but the fact that I know they're there keeps nagging in the back of my mind.

So yes to electric, no to Renault. A shame that I'm stuck with the car for another 4.5 years.

Switching from Wordpress to Nikola

For a while now, I haven't really written anything interesting for my blog. It does contain enough stuff to still be interesting and I guess it does contain some stuff that's simply dear to me. Hard to let go of, at least. But that's not really a good reason to have a full blown Wordpress running. Wordpress has a lot of issues, mostly related to security. Don't get me wrong, if you write a lot and often, Wordpress is a nice platform. But for me, it's kind of overkill. I'd be happy with a static site that I can easily expand.

Enter Nikola, a Python-based script that can generate static pages from simple blog posts. Which is a lot more work than you would imagine, I'm sure. One of the nice things is that it can import a Wordpress XML export, which allowed me to keep all the posts I've been writing on and off in the last 10 years. Quite neat.

It works pretty intuitive, you write a blog post in reStructuredText (rst) (or MarkDown, if that's your thing or a lot of other markup languages) in your favourite editor. Then you tell nikola to build your site, after which the system checks what needs to be done and actually does it. It saves the output in a directory called /output, which you can rsync to the documentroot where you actually want to host your site. Quite simple, I'd say.

For the old Wordpress links, nikola creates dummy pages. I didn't really like that solution, so I wrote some rewrite rules in the Apache config for this:

RewriteRule ^/feed/atom/ /rss.xml [R=301]
RewriteRule ^/([1-2][0-9][0-9][0-9]/[0-1][0-9]/[0-3][0-9]/.*)/.*$ /posts/$1.html [R=301]
RewriteRule ^/(tweets/[0-9]+)/.*$ /stories/$1.html [R=301]

I didn't test this very elaborately, but it seems to work for me. Maybe this will help someone else as well.

There was one thing that required me to do some digging, though. Apparantly, for some unknown reason, my Wordpress XML export contained a few ^P characters. No idea why they were there, but I had to go in and remove them manually, otherwise nikola would not import the data.

I also lost all of my old comments. Since nikola creates static sites only, it cannot work with comments by itself. But it does support systems like Disqus, which I decided to use myself as well. I didn't get a whole lot of comments on my site, so I don't think it's very important. Depending on your setup, this might be a problem for you, though.

A lot of info should be gotten from small side scripts, I guess, or Javascript stuff. That needs to be built, but I didn't think it to be very important. I'm also not sure if you can work with multiple users on a nikola site and have it display the correct owner of a text. Both things are not very important for me, though, although I'm considering switching our company blog to this as well, which would require the multi user stuff a bit.

All in all, I'm pretty happy with this system. I can see how this would be interesting for bigger parties as well, if someone would create a dynamic backend for actually creating the posts as well. It would allow you to completely decouple the backend from the frontend. Although I understand that corporate bloggers obviously require some more bloat on their site, I don't think it would be impossible to recreate that in either small javascript code or using SSI or ESI if you have a cache in front of it. It would probable lead to cleaner code as well, not to mention far easier to cache websites and thus responses.

Very interesting stuff, will be looking into this further, I think.

Job Opening: Debian Linux System Administrator at Kumina

Thank you for all the responses and the interest, we are currently evaluating the candidates and we’re hopeful to find our new coworker among them!

We’re growing and are looking for Debian Linux System Administors that would like to grow with us and provide sysadmin services to our customers.

TL;DR: (in random order) Debian Linux / Apache / PHP / MySQL / Python / Puppet / KVM / Qemu / PostgreSQL / Tomcat / GlassFish / Logstash / ElasticSearch / HAProxy / Graphite / Heartbeat / Pacemaker / Postfix / Icinga / NFS / DRBD / OCFS2 / Ext4 / Varnish / Unbound / POSIX File Permissions / Git / Kibana / Docker / Awesomeness

Who We Are

Kumina has been around since 2007, but we’re slow growers. Our ideal is to grow no larger than 10-12 people. Expansion should be done by automating the hell out of our work and making ourself obsolete so we can persue new knowledge and improve our own workflow. We stand behind the ideals of open source software and prefer working with packages from Debian. Our customers are very diverse, from large magazines to stockphoto sellers, from large multinational corporations that cater to telecom companies to a small foundation that helps people who kicked a bad habit back to work. The biggest common denominator between the customers are that they all run webapplications. We want to provide top quality services, whether it’s on our own VM platform, a customer’s own hardware or somewhere else entirely. We’re always innovating and trying to find new solutions to old problems. We take the time to implement proper solutions and tend to dislike workarounds for problems.

Your coworker’s Linux experience range from 15+ years to almost 2 years of experience, so there’s always something to learn or teach.

Who We Are Looking For

The most important quality we’re looking for is someone who fits into our team. We can be pretty chaotic, direct, obnoxious, distracted, distractive, busy and hyperactive, all at the same time, no kidding. You need to be able to work in this environment and although there are lots of moments in which everyone is focussed on their task, it can change in the blink of an eye.

We’re looking for someone with Linux/Unix experience, Debian Linux experience is preferred, but mostly because that’s what we use. If you’re a CentOS person and do not mind switching and learning about Debian, that’s fine too. The top of this post has a list of software we interact with on a regular basis, knowledge and experience with a few of them would be appreciated. We do not have actual LPI certifications (although we have some good books in our bookcase regarding LPI), but having knowledge equivalent to LPI level 2 is definitely preferred.

Currently, we do most of our configuration management via Puppet. But we’re planning massive changes in our workflow, so experience with other configuration systems is appreciated.

Willingness to learn and teach is another important quality we’re looking for. We try to have weekly presentations regarding technology, varying from an explanation about Apache MPMs to building Kibana dashboards. You’re expected to pass on knowledge to your coworkers and document much (and a bit more) as needed. We do consider most of our puppet code documentation as well (and have separate documentation for classes and defines, of course).

We’re not really interested in your formal education or math skill, we do want to see some of your work regarding scripting in Shell script or Python or Ruby. Being fluent in English is a must and speaking/writing excellent Dutch is definitely a pre.

The Job

Most of our time is spent on innovating our own business process and this is a continuous process, expect a lot of changes. We spent time on testing new technologies and integrating that into our processes.

That said, we always make time to help customers. Requests vary from adding serveraliases (which we should automate!) to setting up entire new environments for customers. We tend to work with customers, so expect a lot of communication, but we do prefer email and irc over other forms of contact.

Another part of our work is troubleshooting of problems. We have a 24×7 service for which we operate with rotating weekly shifts. Once you have enough experience with the way we work, you’ll be scheduled into those shifts as well (don’t expect too many calls outside of business hours, tough, one time during a single rotation is considered a lot). Once you’re part of the rotating shifts, you’ll get a phone from us as well.

We work from the office in Eindhoven 4 days a week, generally. Since we prefer traveling by public transit and none of us actually live near Eindhoven, we arrive at the office somewhere between 8:50 and 9:10. Although we try to be flexible in working hours, it’s important that we can depend on you being there at the times we’ve agreed upon!

Lunch is on Kumina when we’re working at the office (we’ve got a grocery store next door, where we simply get bread and cheese and fruits and the like) and we’ve got our own coffee machine which grinds beans and makes awesome coffee. Should problems or projects require us to stay in the office late, dinner is on Kumina as well (but the last time that happened is almost a year ago).

Everything we do is a team effort and we expect you to be a team player. We do not have room for isolated individuals, we need you to complement our team. We expect you to be pro-active and pick up requests and problems from customers when they arrive (or even before) without being told to.

The Location

Our office is situated in the centre of Eindhoven, next to the train station. We’re on the 12th floor of De Groene Toren (The Green Tower, a pretty well known sight in Eindhoven) and its an office space with a nice view.

We expect you to be able to work from our office several days a week so if you live in close proximity to Eindhoven, that’s convenient, but of course it’s up to you how far you’re willing to travel. Working from home is possible (requires an internet connection, which you need to get yourself and a computer, which we can supply) but is not mandatory.

What Do We Offer

We offer a slightly chaotic but very open environment in which your are encouraged to keep exploring new technologies and ideas. Contributing to the open source community is highly encouraged. We are proud of our work and the things we do and we encourage you to improve on our processes so you can be proud as well.

Based on your skills, we can offer you a salary between €35k and €45k, depending on the level of your skills. If you’re truly exceptional, we might be willing to pay you even more, but you’ll have to prove your exceptionality. Your income will grow with the company and pay raises can happen often, depending on our success. If the company is doing well financially, so will you. A 10% increase is not unheard of.

Based on a 40 hour work week, you’ll get 25 days of paid holiday. This excludes national holidays, so those are extra. If you prefer to work less, those 25 days are scaled to match.


Let us know! Mail us at with some details about you. Links to online repository which contains your commits are appreciated, but we recognise that not all sysadmins are programmers. Tell us about you and why you’re interested in the job. A resume is interesting, just like links to your LinkedIn account. If you have questions, you can mail those as well.

Or join us on IRC (channel #kumina on If you type ‘kumina’ in a sentence, we’ll get a highlight, just keep in mind that it might take a little while before we react, depending on who’s online and how busy it is.

We’re looking forward to meet you!

Automated monitoring? Easy!

One of the things we take very serious here at Kumina is our monitoring. We’ve always done so, but even we must admit that during the starting years, we sometimes forgot to include all possible checks for a new service or host. And it sucks when you forget to setup the monitoring for a specific item, because you generally only find out about it when it’s actually down already…

We like to check as much as possible (if not everything). For example, we check if a service is up and running, we check if a vhost is returning the expected response, if an SSL certificate is still valid or if it will expire within 30 days, we check if OpenVPN certificates are close to expiration and if all loaded Apache modules actually come from a Debian package. And we check often, generally every 30 seconds, but we would prefer to do it even more often. However, these are not things you want to configure manually over and over again.

Automate everything

We’re using Icinga in two datacenters in failover mode, the second node takes over if the primary is unreachable. We currently monitor 319 hosts (including some failover virtual hosts) and a grand total of nearly 10000 checks. Although this fluctuates daily, since most changes on a server also adds or removes checks. It is all done automatically. This prevents us from forgetting to setup monitoring for a specific item or host and also allows us to quickly deploy new checks on the entire infrastructure. Consider the Fokirtor check we created last year, it’s very easy for us to simply deploy it on all those machines.

Using the tools at hand

We’re currently pretty heavy Puppet users, so we leverage the infrastructure we already have in place for that.

Since a puppet agent runs on our monitoring hosts every few hours, it’ll deploy new configuration a few times per day. It’s not exactly continuous delivery, but close enough for our needs for now. Equally important, it removes checks we no longer need. For instance, if we’ve create a redirect that was changed into a full-fledged site, the check is automatically changed to no longer expect a 301 response but a 200 with a correct string (that we provided, of course, it’s not that automated).

We started out using the power of puppet’s exported resources but over time as our config grew, it started to take way too long for Puppet to deploy new configuration on the monitoring hosts. We now deploy the configuration for both Icinga instances using a script that reads the stored config from the Puppet database.

Other uses

As you might imagine, we also do this for trending with Munin. We automatically deploy the Munin plugins on the clients when we deploy a new service and we automatically deploy the host configuration on the Munin server. As well as required firewall rules on the client side.

Icinga check for Linux.Fokirtor

We were notified this morning of the specifics of the attack that struck Hetzner at the start of this year. Or rather, the backdoor software that was used to provide access to the machines. It does not detail what vulnerability was exploited to actually install the Trojan. But it’s still a good idea to make sure your current processes are not infected.

So we went ahead and created a check that can detect Linux.Fokirtor, based on the information provided by Hetzner and Symantec.

Checking for Linux/CDorked.A

We’ve been reading a lot about a Linux exploit targeting webservers and since we manage quite a lot of webservers, we’re keeping a close eye on it. We recently already deployed a check for rogue Apache modules (since we mainly use Apache), but now we’ve also created a check from the code provided by ESET on their security blog describing the Linux/CDorked.A exploit. All it does is check shared memory for a segment of a specific size, but it’s still better than nothing.

As usual, the Icinga check can be found in our GitHub repository and if you’re on Debian, you can find the nagios-plugins-kumina package in our repository. This check needs to be run on the local machine, so you need to setup nrpe or ssh access from Icinga for that.

Let us know if this helps you or if we should improve on it! All kudos to ESET, since they provided the actual script (and research!) for this check.

Checking for rogue Apache modules

We’ve read a lot recently about attacks in which an attacker loads a modified module into Apache to insert iframes in outgoing data. Pretty scary, especially since nobody really seems to know how the hacks are performed. Recently, Sucuri wrote a blog article about how to check for rogue Apache modules on Debian. We’ve decided to implement this into an Icinga/Nagios check.

You can find the source for the plugin here. We also publish all our plugins via the ‘nagios-plugins-kumina’ package, provided by our apt repository.

Hope this helps!

Update: I packaged and pushed the wrong version of the script… Silly me. Fixed now!