I recently noticed that I couldn’t view my Bazaar repositories anymore using the Loggerhead/Apache combination. It turns out that my previous post isn’t completely correct anymore as there seems to be a bug in Loggerhead for Ubuntu 12.04 and 12.10. I’ve updated the old post with a work-around and now everything works as expected again.
Tag: Linux (Page 6 of 8)
One of the first things I tried on my Raspberry Pi was to compile ProbABEL and see if it runs. Since the Raspberry Pi has an ARM processor I wasn’t sure whether our code was portable to it. Apparently it is! Compiling ProbABEL (r.1027 from SVN) took 30 minutes (single threaded of course) compared to 34 seconds on my Desktop (4 threads on an Intel Core i3 processor), but hey, it worked :-). Surprisingly it also passed all the checks in make check.
Once I hook up some more storage to device I will try to run ProbABEL on some real data. It will be interesting to see how much time it takes to run a linear regression on e.g. chromosome 22 of HapMap3 imputated data for a few hundred samples…
Will the Raspberry Pi be the next platform for GWAS ;-)?
Related Images:
Two weeks ago I received a Raspberry Pi! The Raspberry Pi is a small computer based not on a “regular” Intel or AMD x86 processor, but on an ARM processor (similar to the ones used in smartphones etc.). The one I ordered is a model B (with ethernet) and 512MB RAM.
The idea behind this nifty little computer is to provide kids with a low-cost but fully functional computer with which they could start learning more about programming. I’m not sure if this goal will be widely met, but for me it worked ;-). Having this little machine (with its case it measures roughly 10 x 6 x 2.5 cm) in my hands and installing Raspbian Linux on an SD card and looking at the terminal as it booted reminded me of the times when I first played with Slackware Linux on a 486. Of course Raspbian (well, Linux in general) is much more advanced than Slackware 7.0 back in 1999/2000 but the not too stellar performance of the graphical desktop is somewhat comparable.
Apart from playing around with it I’m not sure yet what I’m going to use it for. A domotica hub? A small web sserver? Use DosBox to play old games (from even before the 486 era)? We’ll see!
By the way, I order mine on Thursday Novermber 8th and on the Tuesday after that the package landed on my doorstep. Amazing after hearing about people waiting for months for their orders to be shipped. I order mine from New IT. It probably cost a little bit more, but who cares :-).
Related Images:
On November 7th I released version 0.2.2 of ProbABEL, a set of programs that allow scientists (usually geneticists and epidemiologists) to run Genome-wide association studies (GWAS) in a fast and efficient way, even on machines with low amounts of RAM.
ProbABEL is part of the GenABEL suite, wich is a set of open source package for statistical genomics. Its main developer is Yurii Aulchenko, my former supervisor at the Erasmus Medical Centre.
This update contains a few small bug fixes and an update of the probabel.pl wrapper script that enables the use of chunked imputation output files as input. For more detailed changes, check the announcement.
For those of you running Ubuntu Linux (or one of its derivatives and probably also Debian) I have set up the GenABEL PPA (personal package archive) where you can download and install the ProbABEL .deb package and stay up to date with future updates.
ProbABEL is also available for MS Windows, although we don’t have much experience running it on that platform.
Development of ProbABEL (and other members of the GenABEL suite) takes place on this R-forge page. If you are in search of an open source project to contribute to, feel free to contact us!
User support for the GenABEL suite can be found at our forum.
Related Images:
A few days ago I installed Ubuntu 12.10 on a 2009 laptop (a Dell Latitude D820). This laptop has a trackpoint (the little nib between the G, B and H keys on the keyboard that functions as a mouse). The trackpoint has its own set of mouse buttons, but, unlike my present Thinkpad, it doesn’t have a middle mouse button.
From my early Linux years I remembered that you could use a simultaneous click on the left and right buttons of a mouse to emulate the click of a middle mouse button. This option had to be set in the Xorg configuration file. My guess was that by now this was no longer needed, but I couldn’t find the appropriate option anywhere in Ubuntu’s settings. It’s quite a shame to see that Gnome/Unity/others(?) remove settings like that.
Anyway, looking around the web I found the solution. The middle mouse butten emulation can be enabled in the Gnome configuration by running the following in a terminal:
gsettings set org.gnome.settings-daemon.peripherals.mouse middle-button-enabled true
It worked immediately!
As an aside, I also had to install the packages nvidia-current and nvidia-settings in order to use the nVidia drivers. Without them using the Unity interface was dead slow, even though the laptop has an nVidia Geforce Go 7400.
Related Images:
For the ProbABEL project I’m working on I wanted to test for the presence of the Eigen header files using . Eigen is a C++ template library for linear algebra. It basically consists of a bunch of header files. On my PC the Eigen files are installed in /usr/include/eigen3/ since I used the Debian/Ubuntu libeigen3-dev package.
I first tried to test for the headers by simply including
AC_CHECK_HEADERS([eigen3/Eigen/Dense])
in configure.ac, but that didn’t work:
... checking eigen3/Eigen/Dense usability... no checking eigen3/Eigen/Dense presence... no checking for eigen3/Eigen/Dense... no ...
It turns out that you have to add the following lines to configure.ac:
AC_LANG_PUSH([C++]) AC_CHECK_HEADERS([eigen3/Eigen/Dense]) AC_LANG_POP([C++])
Now I get the following output when running ./configure:
... checking how to run the C++ preprocessor... g++ -E checking eigen3/Eigen/Dense usability... yes checking eigen3/Eigen/Dense presence... yes checking for eigen3/Eigen/Dense... yes ...
To go into a bit more detail, these are the errors in config.log without the AC_LANG options:
... configure:4877: checking eigen3/Eigen/Dense usability configure:4877: gcc -c -g -O2 -Wall conftest.c >&5 In file included from /usr/include/eigen3/Eigen/Core:35:0, from /usr/include/eigen3/Eigen/Dense:1, from conftest.c:67: /usr/include/eigen3/Eigen/src/Core/util/Macros.h:188:5: error: unknown type name 'namespace' /usr/include/eigen3/Eigen/src/Core/util/Macros.h:188:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token In file included from /usr/include/eigen3/Eigen/Dense:1:0, from conftest.c:67: /usr/include/eigen3/Eigen/Core:98:12: error: expected identifier or '(' before string constant In file included from /usr/include/eigen3/Eigen/Dense:1:0, from conftest.c:67: /usr/include/eigen3/Eigen/Core:144:18: fatal error: cerrno: No such file or directory ...
It seems to be the case that AC_LANG is set to C instead of C++ and consequently compilation of autoconf’s test programme fails. The AC_LANG_PUSH option forces autoconf to use C++.
Thanks to this post on Stack Overflow I could solve this problem.
Related Images:
Yesterday I was working on ProbABEL, an open source package for running GWAS (genome-wide association studies). We use R-Forge and they provide us with a Subversion (SVN) server for revision control.
Some time ago we created a branch in which one of the co-developers is doing some major refactoring of the code. In the mean time I have been fixing bugs and adding new features to trunk. Now that the work in the refactoring branch comes to an end I thought it was high time to integrate the changes in trunk with the changes in the branch so that we can later promote the branch to trunk.
Since I had never done this before I decided to try the merge in the doc directory first, because I knew that in that directory nothing had changes since the branch was created, so all changes from trunk should be imported. At first I followed the SVN book instructions so I went into the doc dir in the branch and ran
$ svn merge ^/pkg/ProbABEL/doc
Unfortunately that didn’t work out. For some reasons conflicts appeared as wel as files that weren’t supposed to be there at all.
Thanks to Google and this blog post I found a solution. It boils down to explicitly telling SVN which revisions to use for the merge.
First I used
$ svn log | grep -C3 branch
to find out at which revision I created the branch:
------------------------------------------------------------------------ r864 | lckarssen | 2012-03-27 17:38:05 +0200 (Tue, 27 Mar 2012) | 1 line Creating ProbABEL branch for code refactoring
Next I went to trunk and ran
$ svn update At revision 987.
to find out at which revision trunk currently was. Back in the doc directory in the brach I ran
svn merge -r 864:987 ^/pkg/ProbABEL/doc
to merge al the changes since the branch was split off and it worked like a charm! All changes in trunk applied cleanly.
I then id the same for the other directories which also had changes in the branch. It turns out that when SVN find a conflict it is easier to postpone resolving the conflict because Emacs has a great SVN merge minor mode called SMerge! It highlights your changes vs. the incoming ones and allows you to select a resolution and move to the next conflict with a few easy keystrokes. After all conflicts have been resolved Emacs automtically removes the intermediate files SVN created and you are ready to commit.
Related Images:
Yesterday I received a small package I had ordered: the Plugwise Home Start kit. According to the box it is an energy management and control system. The idea is that you insert a sort of adaptor between a power socket and a device and using the Plugwise Source software you can monitor the power usage of the device. Furthermore, you can use the software to create schedule to turn the device on and off at a specific time.
The package contains the following:
- a USB adapter (called the Stick)
- a Circle+, the master adaptor that keeps track of the other devices in the network
- a Circle, the regular members of the Plugwise network
The Circles communicate to each other using the ZigBee protocol in the 2.4GHz range. According to the documentation, the range of each Circle is about 5m.
Unfortunately the Source software only runs on windows. Luckily some people have already analysed the protocol and written some software to control the Plugwise devices (see links below).
First steps
Plugging the USB dongle in gives the following output in /var/log/syslog
:
Nov 19 12:20:37 barabas kernel: [ 182.855742] usb 1-1.6.1.1.3: new full speed USB device number 14 using ehci_hcd Nov 19 12:20:37 barabas mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.1/1-1.6.1.1/1-1.6.1.1.3" Nov 19 12:20:37 barabas mtp-probe: bus: 1, device: 14 was not an MTP device Nov 19 12:20:37 barabas kernel: [ 183.169370] usbcore: registered new interface driver usbserial Nov 19 12:20:37 barabas kernel: [ 183.169389] USB Serial support registered for generic Nov 19 12:20:37 barabas kernel: [ 183.169431] usbcore: registered new interface driver usbserial_generic Nov 19 12:20:37 barabas kernel: [ 183.169434] usbserial: USB Serial Driver core Nov 19 12:20:37 barabas kernel: [ 183.171310] USB Serial support registered for FTDI USB Serial Device Nov 19 12:20:37 barabas kernel: [ 183.171552] ftdi_sio 1-1.6.1.1.3:1.0: FTDI USB Serial Device converter detected Nov 19 12:20:37 barabas kernel: [ 183.171588] usb 1-1.6.1.1.3: Detected FT232RL Nov 19 12:20:37 barabas kernel: [ 183.171591] usb 1-1.6.1.1.3: Number of endpoints 2 Nov 19 12:20:37 barabas kernel: [ 183.171595] usb 1-1.6.1.1.3: Endpoint 1 MaxPacketSize 64 Nov 19 12:20:37 barabas kernel: [ 183.171598] usb 1-1.6.1.1.3: Endpoint 2 MaxPacketSize 64 Nov 19 12:20:37 barabas kernel: [ 183.171602] usb 1-1.6.1.1.3: Setting MaxPacketSize 64 Nov 19 12:20:37 barabas kernel: [ 183.171975] usb 1-1.6.1.1.3: FTDI USB Serial Device converter now attached to ttyUSB0 Nov 19 12:20:37 barabas kernel: [ 183.171998] usbcore: registered new interface driver ftdi_sio Nov 19 12:20:37 barabas kernel: [ 183.172002] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver Nov 19 12:20:37 barabas modem-manager[901]: <info> (ttyUSB0) opening serial port... Nov 19 12:20:49 barabas modem-manager[901]: <info> (ttyUSB0) closing serial port... Nov 19 12:20:49 barabas modem-manager[901]: <info> (ttyUSB0) serial port closed Nov 19 12:20:49 barabas modem-manager[901]: <info> (ttyUSB0) opening serial port... Nov 19 12:20:55 barabas modem-manager[901]: <info> (ttyUSB0) closing serial port... Nov 19 12:20:55 barabas modem-manager[901]: <info> (ttyUSB0) serial port closed |
lsusb
gives:
Bus 001 Device 014: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC |
I couldn’t get the pairing to work under Linux (with the PlugwiseOnLinux scripts), Even though I corrected the MAC address in the python code. I then tried it in Windows where I failed at first also. After resetting the Circle+ and the Circle (removing/inserting them into the power outlet with 3 second intervals, as mentioned in the FAW on the plugwise website) I managed to pair the Circles. Looking back, I think I didn’t wait long enough for the pairing to work under Linux. During the trials in Windows I noticed that the pairing can take up to about 5 minutes…
Back in Linux I used python-plugwise (see links below) to turn the Circles on and off, e.g. this is how I turn my Circle+ off (note that I am a member of the dialout group, which is needed to communicate with /dev/ttyUSB0
):
$ plugwise_util -d /dev/ttyUSB0 -m 000D6F0000B1C117 -s off |
This is what I want! The only minor downside of python-plugwise is that it depends on the crcmod python library, which apparently is not package for Debian/Ubuntu. So installing using the python-setup framework as mentioned in the README is necessary.
Reading out the current power usage of my Circle works also:
$ plugwise_util -d /dev/ttyUSB0 -m 000D6F0000B85134 -p power usage: 2.27W |
So, no that it works, what am I going to do with the Plugwise modules? I’m going to use them in my backup scripts to switch the power to my external hard drives.
Making a .deb
I used checkinstall
to make a package of python-plugwise. In a working directory, first check out the source code of python-plugwise using mercurial, as mentioned on the web site:
$ hg clone https://bitbucket.org/hadara/python-plugwise |
Then run checkinstall
and don’t forget to fill in the details correctly. For example, the package name is ‘python’ by default, which you definitely don’t want, since that would overwrite Ubuntu’s default ‘python’ package. Also make sure that you remove the crcmod python library if you installed python-plugwise before, otherwise it won’t get packaged. The output below shows the final values, after I changed them.
$ sudo checkinstall -D python setup.py install checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran This software is released under the GNU GPL. ***************************************** **** Debian package creation selected *** ***************************************** This package will be built according to these values: 0 - Maintainer: [ lennart@karssen.org ] 1 - Summary: [ python-plugwise is used to control the Plugwise power switches as well as read out information on power usage. ] 2 - Name: [ python-plugwise ] 3 - Version: [ 0.2-hg-20111120 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ amd64 ] 8 - Source location: [ python-plugwise ] 9 - Alternate source location: [ ] 10 - Requires: [ python ] 11 - Provides: [ python-plugwise ] 12 - Conflicts: [ ] 13 - Replaces: [ ] Enter a number to change any of them or press ENTER to continue: |
You can check the contents of the package to make sure the crcmod
files are included using dpkg
:
$ dpkg --contents python-plugwise_0.2-hg-20111120-1_amd64.deb |
An idea for later: make an SNMP module that calls plugwise_util to get the power usage so that I can monitor the power usage of a device using Cacti.
Links
- The software I use: python-plugwise
- The blog of Maarten Damen, the guy that seems to have been the first one to analyse the plugwise protocol
- Another blog, also with info on the protocol
- PlugwiseOnLinux, a set of python scripts for pairing Plugwise and the Circles. Did not work with me at first, didn’t retry later
- PlugWeb, a PHP interface, for those wanting to control their Plugwise network via a web interface
- According to its website DomotiGa can also control Plugwise devices, but I haven’t tried it (yet)
Related Images:
Introduction
Loggerhead is a webfrontend for Bazaar (usually abbreviated as bzr) repositories. Bazaar is a so-called distributed version control system. So, if you have one or more bzr repositories you can use Loggerhead to look at the files, read the change logs and see the differences between revisions from within your web browser.
The main purpose of this post is to document the steps needed to configure Loggerhead and Apache to work together to publish your bzr repos on the web. The need for this post arose when I tried to get this setup to work and found that there isn’t a lot of documentation on how to get this done and most of it is out of date. The folowing steps were performed on a Linux server with Ubuntu 11.04 installed.
Basic Loggerhead configuration
First, let’s install Loggerhead:
$ aptitude install loggerhead |
Although the package is called loggerhead, the actual binary that is run is called serve-branches. The package provides start and stop scripts for the service (/etc/init.d/loggerhead
), but to start successfully the file /etc/serve-branches.conf
needs to exist. Older documentation I found on the web refers to the file /etc/loggerhead.conf
, but that file has become obsolete.
The serve-branches.conf
file contains three lines:
served_branches=/home/bzr prefix= port=8080 |
Here, the line served_branches
points to the directory under which you store your bzr repositories. Each repo needs to be stored in its own directory. So in this example all the repos are in subdirectories of /home/bzr/
.
You have to make sure that loggerhead can read the files in that directory. Loggerhead runs as the loggerhead
user but I made the directories readable and accessible by all users:
$ chmod -R a+rx /home/bzr/ |
If you now start Loggerhead:
$ service start loggerhead |
you should be able to visit http://localhost:8080 in your browser and see your repositories.
NOTE for Ubuntu 12.04 and 12.10: There seems to be a bug in Loggerhead for these Ubuntu releases (see the link to the Launchpad bug report at the end of this post). In order to start the Loggerhead daemon correctly in these Ubuntu releases the file /etc/init.d/loggerhead must be edited. The line
start-stop-daemon -p $PIDFILE -S --startas /usr/bin/serve-branches --chuid loggerhead --make-pidfile --background --chdir $served_branches -- --prefix=$prefix --port=$port --host=$host --log-folder /var/log/loggerhead 2>/dev/null
must be changed to
start-stop-daemon -p $PIDFILE -S --startas /usr/bin/serve-branches --chuid loggerhead --make-pidfile --background -- file://$served_branches --prefix=$prefix --port=$port --log-folder /var/log/loggerhead 2>/dev/null
Once this is done run restart the Loggerhead service as stated above and it should work again (if you run Loggerhead behind an Apache webserver as detailed below, don’t forget to restart Apache also).
How to publish your branch to this shared repository?
Now that our repository browser is set up, how do we publish our branches to it so that there actually is something to browse through? Here is how you publish your branch to the server, assuming that you are in a directory that contains a branch and want to publish it as myTests
:
$ bzr push --create-prefix sftp://username@server.yourdomain.com/home/bzr/myTests |
As you probably suspected, the --create-prefix
option is only necessary the first time you push your branch. Note that we are using sftp here. Loggerhead itself doesn’t allow writes to the published repos. So, every user that want to push his/her changes to this repository needs to have sftp access to the /home/bzr
directory. I solved that problem by adding all people that need to be able to push changes to a Linux group called vcs (for Version Control Systems) and then set the primary group of /home/bzr/
to vcs as well as giving group write permissions to this directory:
$ ls -ld /home/bzr/ drwxrwxr-x 4 root vcs 4096 2011-08-16 23:10 /home/bzr/ |
Adding Apache to the mix
In my case I already have a web server (Apache) running on port 80. Since I’d rather not open yet another port (8080 in this case) on my router, I wanted to use Apache to hand over the requests for bzr page to Loggerhead. For that I needed to install the following packages:
$ aptitude install python-pastedeploy |
Next, I needed to change the contents of the /etc/serve-branches.conf
file to this:
served_branches=/home/bzr prefix=/bzr port=8080 |
The prefix indicates the location in the URL where Apache will serve the repos. In this case that will be http://server.yourdomain.com/bzr/.
And finally I needed to configure Apache. First, make sure that the proxy
and proxy-http
modules are loaded:
$ a2enmod proxy proxy_http |
Next, create a file /etc/apache/conf.d/sites-available/loggerhead
with the following contents:
# Configuration for browsing of Bazaar repos. Make sure loggerhead is running. <Location "/bzr/"> ProxyPass http://127.0.0.1:8080/ ProxyPassReverse http://127.0.0.1:8080/ </Location> |
Note that Loggerhead and Apache run on the same host, that’s why I set the IP to 127.0.0.1.
Finally it’s time to enable the site and restart Apache:
$ a2ensite loggerhead $ service apache2 restart |
Now it should be possible to browse your repos at http://server.yourdomain.com/bzr/. Note the final /
, it’s important.
Securing access with an LDAP connection
I have stored all my Unix user and group information in an LDAP server. To make sure that only people in the Unix group vcs
are allowed access to the loggerhead pages, change the Apache configuration file loggerhead
to the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | # Configuration for browsing of Bazaar repos. Make sure loggerhead is running. <Location "/bzr/"> ProxyPass http://127.0.0.1:8080/ ProxyPassReverse http://127.0.0.1:8080/ # LDAP authentication AuthType Basic AuthName "Karssen.org VCS users" AuthBasicProvider ldap AuthLDAPURL "ldap://ldap.yourdomain.com/ou=Users,dc=yourdomain,dc=com?uid" AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN off Order Allow,Deny Allow From All Require ldap-group cn=vcs,ou=Groups,dc=yourdomain,dc=com </Location> |
Lines 11 and 12 are needed because the vcs
group is not an LDAP group. I store my Unix (POSIX) groups in a separate OU in the LDAP tree (see line 15).
Don’t forget to restart Apache after making these changes.
References
- Bazaar documentation on Apache integration
- Launchpad bug 563118 describing the unexpected change from
loggerhead.conf
toserve-branches.conf
- Apache, LDAP and groups
- Launchpad bug report for Ubuntu 12.04 and 12.10
Related Images:
I recently wanted to add cover art to my collection of FLAC-encoded audio files. I wrote the following simple script to help me automate the process. Running this script in a given directory (I group my music in directories per artist, followed by a subdirectory for each album) with the name of the album art image file name as argument then automatically embeds the image in the FLAC/Vorbis tag.
#!/bin/bash # # This script embeds a given image (usually .jpg) as album art in the # FLAC files in the present directory (and its subdirectories). # # Time-stamp: <2011-07-31 20:43:23 (lennart)> coverart=$1 find . -name "*.flac" -print0 |xargs -0 metaflac --import-picture-from="$coverart" |