Welcome to my blog. Have a look at the most recent posts below, or browse the tag cloud on the right. An archive of all posts is also available.

I've also (finally) imported my old posts from my previous blog at livejournal to archived blog entries

RSS Atom Add a new post titled:

I've been working on setting up OpenERP for my needs and today I decided it was time to work on backing up the beast. Since I've been running bacula at home to backup my environment, it was time to tweak it so that it made reasonable backups of OpenERP too.

In the end I was able to build a really elegant solution for backing it all up. I decided to go for the bpipe plugin that allows one to pipe programs directly to the bacula file daemon. This allowed me to do a live dump of the database with pg_dump and store it directly to the backup set without writing it to the disk.

Since the other examples in bacula wiki define methods that either use files or FIFO to do the backup, I documented my setup there too.

The only thing that was left was to add the directories specific for OpenERP to the backup and I was all set.

Posted Mon Jun 14 21:13:05 2010 Tags:

I'm not quite sure if I should start worrying, but I've had increasingly odd dreams lately.

Some time back I had a dream that we(?) were hiking on a path and came across a low hanging high-power powerline. To get past the powerline, one had to couch under it. At the time, this felt like the natural thing to do.. although I remember being worried that someone might get zapped. Later on in the dream I was living in an apartment which had the same(?) powerline going right through the kitchen in such a way that you had to crawl under them to get in and out of the apartment.

A few nights back I had a dream that we(?) were escorting a tractor (or something of the sorts) and all of a sudden there was this ball of fur coming out of my (or someone elses) pants, which was quickly identified as a raccoon, not to mention a flying raccoon. These nasty critters would destroy anything in their path. All of a sudden we were in a space shuttle heading to a space station and the outer hull was crawling with these raccoons. We made it to the space station and so did the raccoons. After getting out of the hangar and the (oh so classic) sliding doors closing behind us, the raccoons started eating through the (steel) door. Just as the raccoons got through some soldiers came around the corner and started shooting at the raccoons saying "Oh, not those nasty buggers again".

What strikes me as odd is that none of these situations felt odd at the time. Usually these kinds of dreams tend to be nightmares and you just keep running away..

Oh well. Now it's time to return to the normal unscheduled programming.

Posted Fri Mar 19 22:16:17 2010 Tags:

I modified the livejournal import script so that it's capable of handling comments as well. There are better instructions on the script page on how to export comments.

Now I'm done with livejournal and I can finally delete my account there. All the relevant data has been migrated over. YAY!

Posted Sat Mar 6 18:57:33 2010 Tags:

I finally converted my old blog posts from Livejournal to ikiwiki. They have no real value to anyone but me and it hasn't been a real priority to me anyway.

Livejournal is capable of exporting the blog posts in an xml format with html markup inside, so it's rather simple procedure to compile markdown pages for ikiwiki to consume. This is mostly because you can use plain HTML inside markdown pages.

I did the conversion with XSLT, which started with a simple template and grew up a bit once I added some cleanup features (like filenames and metadata). The script itself is available for download and the archive is available for browsing.

Posted Sun Feb 28 15:26:02 2010 Tags:

Once in a while I get this urge to use SELinux on some of the servers I manage, but almost always run in to something that puts me back enough to never finish the project. This time I managed to figure out the last few glitches. In the end, SELinux still has a really steep learning curve, so it's not for the impatient ones. Even though enabling SELinux in Debian has become a lot easier since the first time I tried to get things running, it's still just the tip of the iceberg. In Debian it is just a matter of installing the right packages and running a few commands, but that's just where the troubles start.

Most of the howtos focus on single user or shared installations where all users are created locally. Also most howtos fail to mention that you need to relabel files in certain cases.

One of the most annoying problem I ran in to was changing all non-system users away from the unconfined_u class. This is of course done like this (found here):

semanage -m -s user_u __default__

The problem here is that it changes the existing user as well and you start to get errors like these:

denied  { read } for  pid=32258 comm="bash" name=".profile" dev=dm-5 ino=185474 scontext=user_u:user_r:user_t:s0 tcontext=unconfined_u:object_r:unconfined_home_t:s0 tclass=file

The problem here is that the home directory for the user is still labeled for the wrong class. The fix is to relabel the home. Sadly this is something that you just need to know, it's not explained anywhere. At least I haven't found an explanation anywhere. Another good thing to do before you continue is to change the already existing user to the staff class. Staff class has a bit more relaxed security controls and you get to change the security roles (details here).

semanage login -m -s staff_u myuser
fixfiles relabel /home/myuser

This gets you a semi working setup, next problem usually is that some daemons are denied access to parts of your system. For me, this was postfix trying to access my home directory that was mounted over NFS. For such cases, you should persuade the maker of the module package to update the global policy if it's a common use case. Or you need to create a policy package that allows access to the given files.

The process itself is documented in the audit2access manual page. In general you should study the audit2why and audit2allow packages. The former tells you if there is an easier way to fix something (like enable a boolean) and latter will create the required policy lines. Only problem is to compile the policy and load it. The only problem here was to find the right tool and the right lines from the manual.

In general the SELinux learning curve is way too steep. It's a system that works pretty well once you learn all the tricks and start to completely understand the toolset. The community should continue working on lowering the bar for new users. There has been some major improvements since I first tried SELinux, so it's the right direction.

Posted Mon Jul 13 00:04:02 2009 Tags:

Yesterday I went out to map an unmapped area in Rauma for OSM. Mapping the area was less painful than what I expected. In part I expected to collapse on the street or something since I'm in terrible shape...

There were couple lessons that I learned from the trip and since it's all about sharing information, I decided to share the these pieces of information as well.

  • First thing I realized while heading out was that you really need a proper GPS unit. Initially I planned on using an iPhone and a Garmin Colorado 300 to collect redundant tracks for the whole trip. Since GPS signal varies quite a bit due to various reasons, it's good to have 2 tracks so you can use the average of those tracks. The problem turned out to be the iPhone, which for some reason started acting up almost immediately as I headed out. I don't know if it was the heat or something else. But if it had been my only GPS for the trip, my whole day would have been ruined.
  • Get a map! Yes, even though you should never copy from other maps to OSM, it's a good idea to grab a map of the area and do some light planning on the order you are going to visit the streets. I didn't plan beforehand and I ended up running up and down streets twice or more. It's not a bad idea to draw out your planned route on a map, but keep your eyes open! Most maps lack areas and have streets that don't exist anymore. Those are the ones you are there to catch. That is what makes OSM so important.

  • Take a camera with you. Sure, this is something that most people say anyway, but even though I knew that a camera would be handy, I never expected it to be this handy. It's quite easy to snap pictures of the street signs even on the run. So instead of writing anything down or using any other method, try a camera.

  • You should always carry something to drink. I didn't have anything and it was a hot day. In the end I was exhausted and rather dehydrated. I was planning on heading out to a nearby gas station to get something to drink, but never got there.
  • Take a picture of your GPS with the time and date visible. This helps you synchronize the pictures on the track you created. I always forget to do this...

There you go. I had a good time and will most likely do this again, but first I need to fix my bike.

Posted Thu Jul 2 10:51:02 2009 Tags:

Since I enabled comments in this blog, I finally needed to configure a split DNS for my network.

There are various reasons why one needs a split DNS and as it's usually pointed out, the reasons are usually non-technical. In my case the reasons are technical: I have a NAT in my local network that allows me to host this website locally. What causes problems is that the domain name ressukka.net points to the external IP address and that doesn't work from the inside. So split DNS it is.

There are various ways of building a split DNS, one can use the views feature in bind9 or you can set up 2 separate DNS servers that provide different information (and redirect your local resolver to use the internal server). The latter is more secure if the internal zone is sensitive.

I decided to use a hybrid solution. I already knew that PowerDNS Recursor was capable of serving authoritative zones (think pre-cached) so I decided to leverage on that. Setting this up turned out to be simpler than I expected.

First I made a copy of the existing zone and edited it to fit my needs. I changed the IP address of ressukka.net to point to the IP address on the local network. I also adjusted some other entries that pointed to the local network.

Next I modified bind to listen on the external IP address. This can be accomplished by adding a listen-on {; }; to the options in the configuration. I also disabled the resolver by adding recursion no;, this forces the bind to work as authoritative only.

Then I installed the PowerDNS Recursor (pdns-recursor package in debian) and configured it to listen on the internal address only (local-address= and added the pre-cached zone to the configuration with auth-zones=ressukka.net=/path/to/internal-zone

Now, after restarting both daemons, I had a working split DNS with minimal configuration. I was also able to change the external DNS to authoritative only mode, which is a good idea in any case.

Posted Mon Mar 23 22:38:37 2009 Tags:

It was way over due already, but I finally enabled comments in my ikiwiki installation. What this means is that you can now comment on my blog posts. I also enabled blogspam module so hopefully I get to avoid spamming.

In any case, have fun commenting.

Update: I also enabled anonymous commenting, so OpenID isn't required.

Posted Mon Mar 23 22:18:03 2009 Tags:

For some time I've suffered from the infamous clocksource problem with all Linux hosts that aren't running the Citrix provided kernels. I'm bit old fashioned and I want to run Debian provided kernels instead the Citrix ones, mostly because the Debian kernel receives security updates.

During the fight with my own server last night, it finally dawned to me.

The clocksource problem appears after you suspend a Linux host and the kernel in the virtual machine starts spewing this:

Mar  5 09:24:17 co kernel: [461562.007153] clocksource/0: Time went backwards: ret=f03d318c7db9 delta=-200458290723043 shadow=f03d1d566f4a offset=143675d9

I've been trying to figure out what is different with Citrix and Debian kernels, because the problem doesn't occur with the Citrix provided kernel.

The final hint to solving this problem came from Debian wiki. The same issue is mentioned there, but the workaround is not something I like. I perfer making sure that the host server has the correct time and the virtual machine just follows that time.

But the real clue was the clocksource line. It turns out that the Citrix kernel uses jiffies as the clocksource per default, while Debian uses the xen clocksource. It would make sense that the xen clocksource is more accurate since it's native to the hypervisor.

So by just running this on the domU fixes the problem:

echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource

There is no need to decouple the clock from the host, which is exactly what I needed. To make this change permanent, you need to add clocksource=jiffies to the bootparameters of your domU kernel.

You can do this by modifying grub configuration and adding clocksource=jiffies to the kopt line and running update-grub. Or you can use XenCenter and modify the virtual machine parameters and clocksource=jiffies to boot parameters.

It's also worth noting that this problem does apply to plain vanilla Debian installations as well, so reading that whole wiki page is a good idea.

Posted Thu Mar 5 17:26:28 2009 Tags:

I finally decided that it's time for me to upgrade my Xen installation. It used to run etch with backported Xen, because the etch version was increasingly difficult to work with.

I also acknowledge that some of the issues I've been having are simply caused by yours truly, but even still the Debian Xen installation is way too fragile to my taste. I've already considered installing XenServer Express locally and running the hosts on it. The big drawback has been that XenCenter (the tool that is used to manage XenServer) is windows only and it doesn't work with wine.

So you can imagine my desperation...

Anyway, the latest upgrade from etch to lenny was painful as usual. The first part went smoothly, bit of sed magic on sources.list and a few upgrade commands (carefully picking the Xen packages out of the upgrade set). So in the end I had a working lenny installation with backported Xen.

Next I made sure that there was nothing major going on in my network (one of the virtual machines acts as my local firewall) and took a deep breath before upgrading the rest of the packages. I knew to be careful about xendomains -script which has reliably restored my virtual machines after reboot to a broken host so I had always ended up restarting my virtual machines after reboot.

I carefully cleared XENDOMAINS_AUTO and set XENDOMAINS_RESTORE to false in /etc/default/xendomains so that the virtual machines would be saved but not restored or restarted on reboot.

After the normal pre-boot checks I went for it.

Oddly enough everything worked normally and the system came up after a bit of waiting. I checked the bridges and everything appeared normal, so it was time to try and restore a single domain to see that everything actually did work as planned.

Hydrogen:~# xm restore /var/lib/xen/save/Aluminium
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

Oof, Googling for the issue revealed that there were others that had suffered from the same problem on various different platforms the problems were caused by different things. One would assume that the problem is in the vif-bridge script that is mentioned in the xend-config.sxp file as the script that brings up the vif, but after many hours of tial and error and pointless googling (over gprs connection), I couldn't find any solution to the problem. It was time to call it a day (it was almost 3 am already...)

During the night I had a new idea about the possible cause. What if the problem isn't in xend, but somewhere else. I fired up udevadm monitor to see what udev saw and it wasn't much. I'm not an expert with udev, but from previous encounters I had a vague feeling that there was supposed to be more events flying around.

I wasn't able to pinpoint what was wrong so I decided to purge xen-utils, of which I had 2 versions installed: 3.2-1 and 3.0.2. I also removed everything related to xenstore. After reinstalling the current versions and restoring my configuration files the first host came up just fine.

I still had problems resuming the virtual machines and I ended up rebooting them again, which was nothing new, but at least they were running again.

In the end I don't know what was the actual cause for udev not handling the devices properly, but I'm happy to have them all running again. And I learned a valuable lesson of all this: udev is an important part of Xen, make sure it works properly.

Posted Thu Mar 5 17:11:39 2009 Tags: