Tag Archives: Debian

Moving to HGKeeper


So, where do we come from? I started using the Mercurial version control system around 2009 if I remember correctly. Had used Subversion and SVK (does anyone remember that?) before and was curious about distributed version control. Back then Mercurial was better suited for platform independent use on Linux and Windows, and I still had to use the latter at work. Mercurial’s user interface was very much the same as Subversion’s and basically just push and pull were added, switching from Subversion to Mercurial was easy. Git was weird at the time, at least for me. Meanwhile we use Git at work exclusively and it got a lot better on Windows over time. However for nostalgic reasons and to stay somewhat fluent in other VCS I kept most of my private projects on Mercurial.

For “hosting” my own repos I used the Debian package mercurial-server, at least up to Debian 9 (stretch), but after upgrading that server to Debian 10 (buster) things started falling apart, and I looked out for a new hosting solution. For the record: I thought about converting all those repos to Git, but opted for not doing that, because I have accumulated quite a number of repos and although I did convert one or two already, I supposed it would be easier to switch the hosting instead of each repo.

Speaking of hosting: I don’t need a huge forge for myself, just some rather simple solution for having server side “central” repos so I can easily work from different laptops or workstations. So I scanned over MercurialHosting in the Mercurial wiki and every self hosting solution seemed like cracking a nut with a sledgehammer, except HGKeeper.

Introducing HGKeeper

HGKeeper introduces itself like this in its own repo:

HGKeeper is an server for mercurial repositories. It provides access control for SSH access and public HTTP access via hgweb.

It was originally designed to be run in a container but recently support has been added to run it from an existing openssh-server.

SSH and simple HTTP is all I need and running in a container suits me right, especially after I had started deploying things with Docker and Ansible and could a little more practice with that. Running in a container is especially helpful when running things implemented in those fancy new languages like Go or Rust on an old fashioned Linux like Debian. (For reference see for example Package managers all the way down on lwn about how modern languages create a dependency hell for classical Linux distributions.)

Running the HGKeeper Docker container itself was easy, however SSH access would go through a non-standard port, at least if I wanted to keep accessing the host machine through port 22.

The README promised HGKeeper can also be run together with OpenSSH running on default port. But is it possible to do both or all of this? Run in a container, access HGKeeper through port 22 and keep access to the host on the same port? I reached out to Gary Kramlich, the author of HGKeeper and that was a very nice experience. Let’s say I nerd sniped him somehow?!

Installing HGKeeper

So the goal is to run HGKeeper in a Docker container and access that through OpenSSH. While doing the setup I decided to go through an SSH server on a different machine, the one that’s exposed to the internet from my local network anyways, and where mercurial-server was installed before. So access from outside goes through OpenSSH on standard port 22 hg.example.com which is an alias for the virtual machine falbala.internal.example.com. That machine tunnels the traffic to another virtual machine miraculix.internal.example.com where HGKeeper runs on in the Docker container, with SSH port 22022 exposed to the local network.


We follow the HGKeeper README and prepare things on the Docker host (miraculix) first. I created a directory /srv/data/hgkeeper where all related data is supposed to live. In the subfolder host-keys I created the SSH host keys as suggested in section “SSH Host Keys”:

$ ssh-keygen -t rsa -b 4096 -o host-keys/ssh_host_rsa_key

The docker container itself needs some preparation, so we run it once manually like suggested in section “Running in a Container”. The important part here is to pass the SSH public key of the client workstation you will access the HG repos first from. I copied that from my laptop to /srv/data/hgkeeper/tmp/ before. The admin username passed here (alex) should also be adapted to your needs:

cd /srv/data/hgkeeper
docker run --rm \
    -v $(pwd)/repos:/repos \
    -v $(pwd)/tmp/id_rsa.pub:/admin-pubkey:ro \
    -e HGK_ADMIN_USERNAME=alex \
    -e HGK_ADMIN_PUBKEY=/admin-pubkey \
    -e HGK_REPOS_PATH=/repos \
    docker.io/rwgrim/hgkeeper:latest \
    hgkeeper setup

Setting up OpenSSH

As stated before, I tried to setup as much things as possible with Ansible. The preparation stuff above could probably also done with Ansible, but I had that in place from playing around and did not bother at the time. It depends on your philosophy anyways if you want to automate such sensitive tasks as creating crypto keys. However from here on I have everything in a playbook, and will show that snippets to illustrate my setup. The OpenSSH config is for the host falbala and thus in falbala.yml so see the first part here:

- hosts: falbala
 become: true

   hg_homedir: /var/lib/hg

   - name: Add system user hg
       name: hg
       comment: Mercurial Server
       group: nogroup
       shell: /bin/sh
       system: yes
       create_home: yes
       home: "{{ hg_homedir }}"

That system needs a local user. You can name it as you like, but it was named hg on my old setup and I wanted to keep that, so I don’t have to change my working copies. The user needs to have a shell set, otherwise OpenSSH won’t be able to call commands needed later. I use the $HOME dir to put the SSH known_hosts file in it, so it does not clutter my global settings. Doing this manually on Debian would look like this:

% sudo adduser --system --home /var/lib/hg --shell /bin/sh hg

Next step is that known_hosts file. You can do this manually by logging into that hg user once and do a manual connection to the SSH server on the other machine like this:

$ sudo -i -u hg
$ ssh -p 22022 hg@miraculix.internal.example.com

For Ansible I prepared a known_hosts file and that was somewhat tricky due to the different port used. You can not just look into your present files for reference, because host and port are hashed in there, and the documentation (man 8 sshd) does not cover that part. I had to guess from ssh -v output. The file I came up with is named pubkeys/hgkeeper in my Ansible project and it looks like this:

[miraculix.internal.example.com]:22022 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDD8hrAkg7z1ao3Hq1w/4u9Khxc4aDUfJiKfbhin0cYRY7XrNIn3mix9gwajGWlV1m0P9nyXiNTW4E/Z

With that in place, it’s straight forward in the playbook:

   - name: Ensure user hg has .ssh dir
       path: "{{ hg_homedir }}/.ssh"
       state: directory
       owner: hg
       group: nogroup
       mode: '0700'

   - name: Ensure known_hosts entry for miraculix exists
       path: "{{ hg_homedir }}/.ssh/known_hosts"
       name: "[miraculix.internal.example.com]:22022"
       key: "{{ lookup('file', 'pubkeys/hgkeeper') }}"

   - name: Ensure access rights for known_hosts file
       path: "{{ hg_homedir }}/.ssh/known_hosts"
       state: file
       owner: hg
       group: nogroup

For the SSH daemon configuration two things are needed. First, if you use domain names instead of IP addresses, you have to set UseDNS yes in sshd_config. This snipped does it in Ansible:

   - name: Ensure OpenSSH does remote host name resolution
       path: /etc/ssh/sshd_config
       regexp: '^#?UseDNS'
       line: 'UseDNS yes'
       validate: /usr/sbin/sshd -T -f %s
       backup: yes
       - Restart sshd

The second, and most important part is matching the hg user, authenticating against the HGKeeper app running on the other host and tunneling the traffic through. This is done with the following snippet, which contains the literal block to be added to /etc/ssh/sshd_config if you’re doing it manually:

   - name: Ensure SSH tunnel block to hgkeeper is present
       path: /etc/ssh/sshd_config
       marker: "# {mark} ANSIBLE MANAGED BLOCK"
       insertafter: EOF
       validate: /usr/sbin/sshd -T -C user=hg -f %s
       backup: yes
       block: |
         Match User hg
             AuthorizedKeysCommand /usr/bin/curl -q --data-urlencode 'fp=%f' --get http://miraculix.internal.example.com:8081/hgk/authorized_keys
             AuthorizedKeysCommandUser hg
             PasswordAuthentication no
       - Restart sshd

You might have noticed two things. curl has to be installed, and sshd should be restarted after its config has change. Here:

   - name: Ensure curl is installed
       name: curl
       state: present

    - name: Restart sshd
        name: sshd
        state: reloaded

Running HGKeeper Docker Container with Ansible

Running a Docker container from Ansible is quite easy. I just translated the call to docker run and its arguments from the HGKeeper documentation:

- hosts: miraculix
  become: true

    data_basedir: /srv/data
    hgkeeper_data: "{{ data_basedir }}/hgkeeper"
    hgkeeper_host_keys: host-keys
    hgkeeper_repos: repos
    hgkeeper_ssh_port: "22022"

   - name: Setup docker container for HGKeeper
       name: hgkeeper
       image: "docker.io/rwgrim/hgkeeper:latest"
       pull: true
       state: started
       detach: true
       restart_policy: unless-stopped
         - "{{ hgkeeper_data }}/{{ hgkeeper_host_keys }}:/{{ hgkeeper_host_keys }}:ro"
         - "{{ hgkeeper_data }}/{{ hgkeeper_repos }}:/{{ hgkeeper_repos }}"
         HGK_SSH_HOST_KEYS: "/{{ hgkeeper_host_keys }}"
         HGK_REPOS_PATH: "/{{ hgkeeper_repos }}"
         HGK_EXTERNAL_HOSTNAME: "miraculix.internal.example.com"
         HGK_EXTERNAL_PORT: "{{ hgkeeper_ssh_port }}"
         - "8081:8080"   # http
         - "{{ hgkeeper_ssh_port }}:22222"   # ssh
       command: hgkeeper serve

Client Settings

Almost done, after trivially copying over my old repos from the old virtual machine to the new, the server is ready. For the laptops and workstations nothing in my setup has to be changed, but one thing. The new setup needs Agent Forwarding in the SSH client config. But is simple, see the lines I added to ~/.ssh/config here:

Host hg.example.com hg
HostName hg.example.com
ForwardAgent yes

After all this was a pleasant endeavor in both working on the project itself as well as the outcome I have now.

Running EAGLE 9.6 on Debian 10 (buster)

For some side project I wanted to look at the schematics of the Adafruit PowerBoost 500C, which happened to be made with Autodesk EAGLE.

Having run EAGLE on Debian 9 (stretch) for a while now without great hassle, I did not expect much difficulties, I was wrong. First I downloaded the tarball from their download site. Don’t worry, there’s still the “free” version for hobbyists, however it’s not Free Software, but precompiled binaries for amd64 architecture, better than nothing.

After extracting, I tried to start it like this and got the first error:

alex@lemmy ~/opt/eagle-9.6.0 % ./eagle
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
[1]    20775 abort      ./eagle

There’s no verbose or debug option. And according to the comments on the blog post “How to Install Autodesk EAGLE On Windows, Mac and Linux” the problem also affects other users. I vaguely remembered somewhere deep in the back of my head, I already had this problem some time ago on another machine, and tried something not obvious at all. My system locale is German, looked like this before:

alex@lemmy ~ % locale

alex@lemmy ~ % locale -a

As you can see, no English locale, so I added one. On Debian you do it like this. Result below:

% sudo dpkg-reconfigure locales

alex@lemmy ~/opt/eagle-9.6.0 % locale -a

This seems like a typical “works on my machine” problem from an US developer, huh? Next try starting eagle, you’ll see the locale problem is gone, the next error appears:

alex@lemmy ~/opt/eagle-9.6.0 % ./eagle 
./eagle: symbol lookup error: /lib/x86_64-linux-gnu/libGLX_mesa.so.0: undefined symbol: xcb_dri3_get_supported_modifiers

That’s the problem if you don’t build from source against the libraries of the system. In that case EAGLE ships a shared object libxcb-dri3.so.0, which itself is linked against the libxcb.so.1 from my host system, and those don’t play well together. I found a solution to that in a forum thread “Can’t run EAGLE on Debian 10 (testing)” and it is using the ld_preload trick:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 ./eagle

This works. Hallelujah.

Performance Analysis on Embedded Linux with perf and hotspot

This is about profiling your applications on your embedded Linux target or let’s say finding the spots of high CPU usage, which is a common concern in practice. For an extensive overview see Linux Performance by Brendan Gregg. We will focus on viewing flame graphs with a tool called hotspot here, based on performance data recorded with perf. This proved to be helpful enough to solve most of the performance issues I had lately.

Installing the Tools

We have two sides here: the embedded Linux target and your Linux workstation host. For your computer you need to install hotspot. In Debian it is available from version 10 (buster). You can build from source of course, I did that with Debian 9 (stretch) a while ago. IIRC there are instructions for that upstream. Or you build it from the deb-src package from Debian unstable (sid) by following this BuildingTutorial.1

The embedded target part needs basically two parts. You have to set some options in the kernel config and you need the userland tool perf. For ptxdist here’s what I did:

  • Add -fno-omit-frame-pointer to global CFLAGS and CXXFLAGS

Note: I had to update my kernel from v4.9 to v4.14, otherwise I got build errors when building perf.

Configuring the Kernel

I won’t quote the whole kernel config here, but I have a diff on what I had to set to make perf record useful things. These options are probably important, at least I had those on in my debug sessions (others might also be needed):


Using it

For embedded use, I basically followed the instructions of upstream hotspot. You might however want to dive a little into the options of perf, because it is a very powerful tool. What I did to record on the target was basically this to get samples from my daemon application mydaemon for 30 seconds:

perf record --call-graph dwarf --pid=$(pgrep mydaemon) sleep 30

This can produce quite a lot of data, so use it with short times first to not fill your filesystem. Luckily I had enough space on the flash memory of the embedded target available. Then just follow what the hotspot README says: copy the file and your kernel symbols to your host and call hotspot with the right options to your sysroot. This was the call I used (from a subfolder of my ptxdist BSP, where I copied those files to):

hotspot --sysroot ../../../platform-ncl/root --kallsyms kallsyms perf.data

Happy performance analysing!

  1. I did not test that with hotspot []

Getting CDash to work on Debian 9 (stretch) with lighttpd and MariaDB

After reading It’s Time To Do CMake Right and The Ultimate Guide to Modern CMake I stumbled about the slides of Effective CMake by Daniel Pfeifer. (I did not watch the related video C++Now 2017: Daniel Pfeifer “Effective CMake” though.)

What attracted my attention where the commands ctest_coverage() and ctest_memcheck() from the slide about CTest which comes with CMake and which I already use. In libcgi and some non free projects I create additional tests to be run with valgrind if that tool is found on the build host, but when using CTest/CDash I don’t need to do that and also get coverage tests on top, so I set up a local CDash server on my workstation, which was painful in multiple ways.

After extracting the CDash archive and configuring lighttpd to server its PHP files the install.php came back with the following error message:

Specified key was too long; max key length is 767 bytes

It was not easy to find the cause. The web says this is fixed in MariaDB 10.2.x while my Debian stable still has 10.1.x … and I found only some workarounds on that problem for other projects than CDash. I could “solve” that by changing the database collation from utf8mb4_unicode_ci to utf8_unicode_ci in phpMyAdmin on the still empty database cdash before running install.php.

The more challenging problem was to actually submit results to the CDash server when calling CTest. The webserver always responded with HTTP Status Code 417. That was only partly fault of CDash, which seems to call curl with some strange (?) headers for submission. That turned out to trigger some (from my side) unexpected behavior in lighttpd, for which several tickets exist, I found #1017 eventually, which led me to the lighttpd 1.4.21 release info giving the hint I needed. I added this somewhere in my lighttpd config files:

server.reject-expect-100-with-417 = "disable" 

In the end I have a local CDash instance now and could already submit some helpful coverage and memcheck results. Best thing: This way I can remove the error prone additional tests from my CMakeLists.txt and still run the tests with valgrind, even more flexible than ever.

HowTo: ownCloud mit lighttpd auf Debian Jessie

Der Fortschritt macht nicht halt und dass jemand™ sich jetzt ein Fairphone mit Android drauf gekauft hat, war eine willkommene Gelegenheit sich mal eine eigene ownCloud-Instanz aufzusetzen. Debian Jessie ist zwar derzeit noch »testing« aber schon ganz gut nutzbar und da es dort fertige Pakete für ownCloud 7 gibt und eine passende VM auf dem Server zu Haus bereits lief, fiel die Wahl darauf. Ein lighttpd mit PHP lief auch schon und der Rest war auch so schwer nicht.

Im derzeitigen Stand des Paktes muss man die Datenbank für ownCloud noch selbst anlegen. Ich hab das mit phpmyadmin gemacht, wo das Debian-Paket sich selbst schon einfach in lighttpd integriert. Die Zugangsdaten gibt man später beim Einrichtungswizard vom ownCloud an.

Im ownCloud Paket ist eine Möglichkeit dokumentiert, das Paket mit lighttdp zu nutzen, die automatische Integration wie bspw. bei phpmyadmin gibt es so nicht. Der falsch vorgeschlagene Pfad in der Doku, wurde von mir gemeldet und ich hab noch ein paar Dinge ergänzt:

$HTTP["host"] == "owncloud.example.com" {
        url.redirect = (
                "^/.well-known/caldav$" => "/remote.php/caldav/",
                "^/.well-known/carddav$" => "/remote.php/carddav/"

        alias.url += ( "" => "/usr/share/owncloud" )

        $HTTP["url"] =~ "^/data/" {
                url.access-deny = ("")

        $HTTP["url"] =~ "^($|/)" {
                dir-listing.activate = "disable"
} else $HTTP["host"] =~ "" {
        url.redirect = ( 
                "^/owncloud/.well-known/caldav$" => "/owncloud/remote.php/caldav/",
                "^/owncloud/.well-known/carddav$" => "/owncloud/remote.php/carddav/"
        # Make ownCloud reachable under /owncloud
        alias.url += ( "/owncloud" => "/usr/share/owncloud" )
        # Taken from http://owncloud.org/support/distro-notes, section "lighttpd":
        # As .htaccess files are ignored by lighttpd, you have to secure the /data
        # folder by yourself, otherwise your owncloud.db database and user data is
        # puplicly readable even if directory listing is off.
        $HTTP["url"] =~ "^/owncloud/data/" {
                url.access-deny = ("")
        $HTTP["url"] =~ "^/owncloud($|/)" {
                dir-listing.activate = "disable"

Der untere Teil ist aus dem Vorschlag vom Paket übernommen, nur der alias-Pfad korrigiert. Der obere Teil ist für den direkten Zugriff über eine andere Subdomain statt über den hostname des Servers und einen Unterordner. An sich steht da aber das gleiche drin. Besonderes Augenmerk sei noch auf die redirects für die sogenannten well-known URLs nach RFC 5785 gelegt, die den Zugriff mit bestimmten Kalenderprogrammen deutlich vereinfachen.

Nachtrag: Dieses Mini-HowTo unterschlägt die Einrichtung von verschlüsseltem Zugriff über HTTPS. Ich habe das weggelassen, weil es a) an anderer Stelle gut beschrieben ist und b) ich hier noch einen nginx als Reverse Proxy vor dem lighty habe, der mit diesem HowTo rein gar nichts zu tun hat. ;-)

Auth required on KDE

Debian Wheezy, KDE und ab und zu funktioniert das Einspielen von Updates nicht oder das Mounten von Datenträgern. Manchmal hilft Reboot, manchmal nervt’s und manchmal schaut man warum. Also heute, eine NTFS-Partition auf einer eingebauten Platte, die nicht in /etc/fstab steht, über Dolphin einbinden. Normalerweise wird da nach dem Passwort gefragt und dann macht er das. Heute nicht, stattdessen:

An error occurred while accessing ‘DATEN’, the system responded: An unspecified error has occurred.: Authentication is required

Rumsuchen im Netz ist da nicht ganz leicht, aber folgendes ließ sich rausfinden. Es gibt ein Programm namens udisks mit dem man die selbe Fehlermeldung provozieren kann und das auch ansonsten interessante Dinge ausgibt. Und es gibt ein Programm pkexec welches Teil von polkit ist und wenn man es so aufruft, kann man testen, ob da alles stümmt:

pkexec --disable-internal-agent /bin/true

Stimmte hier nicht, aber das brachte mich dahin, dass anscheinend ein Programm names polkit-kde-authentication-agent-1 laufen muss. Das lief hier nicht. Ob das abgestürzt war, oder nicht gestartet wurde, und warum, hab ich nicht mehr rausgefunden, aber das Ding einfach nochmal starten, behob mein Problem:


Sachdienliche Hinweise nehme ich gern entgegen.

HowTo: gitolite auf Debian Wheezy

Das Netz ist natürlich voll von HowTos zum Thema gitolite, in diesem hier nutze ich aber nicht die bleeding edge Version von upstream sondern das Debian-Paket. Eine gewisse Hilfe für’s Verständnis und bei der Installation war die Dokumentation für gitolite 2.x, denn in Wheezy ist Version 2.3 verpackt.


Geht los mit Installation des Pakets gitolite. Wenn der bei der Installation dpkg nichts konfiguriert haben will, dann gibt man danach nochmal ein:

dpkg-reconfigure gitolite

Dort wird dann ein SSH public key abgefragt für den Admin-Nutzer. In meinem Fall hab ich hier für die Testinstallation auf dem selben Rechner den folgenden Pfad angegeben, ansonsten kopiert man seinen public key ins Eingabefeld:


Damit liegt jetzt hier unterhalb von /var/lib/gitolite1 folgendes:

% ls -la /var/lib/gitolite
insgesamt 28
drwxr-xr-x  5 gitolite gitolite 4096 Jun 17 13:51 ./
drwxr-xr-x 58 root     root     4096 Jun 17 13:47 ../
drwx------  8 gitolite gitolite 4096 Jun 17 13:47 .gitolite/
-rw-r--r--  1 gitolite gitolite 4217 Jun 17 13:47 .gitolite.rc
-rw-------  1 gitolite gitolite    0 Jun 17 13:47 projects.list
drwx------  4 gitolite gitolite 4096 Jun 17 13:47 repositories/
drwx------  2 gitolite gitolite 4096 Jun 17 13:47 .ssh/

Da mein public key bereits hinterlegt ist, kann ich direkt zum nächsten Schritt übergehen und das Admin-Repo clonen, welches bei der Installation angelegt wurde:

git clone gitolite@localhost:gitolite-admin

Wie man sieht, hatte ich den dedizierten Nutzer gitolite genannt, für Produktionsumgebung ist vielleicht git eine bessere Wahl.

Ganz wichtig: beim Ändern der Config muss man stets drauf achten, dass man sich nicht selbst aussperrt. Für das Repository gitolite-admin muss man Schreibrechte für irgendeinen Key behalten, auf den man auch Zugriff hat und der unterhalb von keydir im Repo liegt, sonst hat man keine Möglichkeit mehr ohne große Schmerzen diese Rechte wiederzuerlangen.


Als nächstes habe ich die Datei /var/lib/gitolite/.gitolite.rc angepasst. Berücksichtigt sind hier bereits, dass ich sowohl git-daemon als auch gitweb einsetzen und die Repos auf einen anderen Rechner spiegeln will. D.h. ich habe folgende Einträge geändert:

$REPO_UMASK = 0027;
$GL_GITCONFIG_KEYS = "gitolite.mirror.*";

Der letzten Zeile ist erhöhte Beachtung zu schenken. Die bereits angelegten Repositories gitolite-admin und testing aus /var/lib/gitolite/repositories müssen nämlich in den geänderten Pfad verschoben werden.2 Damit der Zugriff über gitweb funktioniert, habe ich den Nutzer www-data der Gruppe git hinzugefügt und die Rechte des Repository-Verzeichnisses gelockert:3

sudo addgroup www-data git
sudo chmod g+rx /var/lib/gitolite/repositories

Die eigentliche Konfiguration erfolgt dann wie bei gitolite üblich über das admin-Repository nachdem man es geklont hat:

git clone gitolite@myfancyserver:gitolite-admin

Wie man das im Einzelnen macht, kann man in der Doku zu gitolite v2 nachlesen. Das ist nicht Debian-spezifisch.

gitweb mit lighttpd

Für einen schnellen Überblick mit dem Webbrowser ist das Paket gitweb installiert. Als Webserver kann vermutlich irgendein Webserver dienen. Für lighttpd habe ich eine Datei /etc/lighttpd/conf-available/80-gitweb.conf angelegt und mit den für diesen Browser üblichen Mechanismen aktiviert. Der Inhalt sieht so aus:4

# -*- depends: cgi -*-
server.modules += ("mod_setenv")
setenv.add-environment = ("GITWEB_CONFIG" => "/etc/gitweb.conf")
alias.url += ( "/gitweb" => "/usr/share/gitweb" )

$HTTP["url"] =~ "^/gitweb/" {
        server.indexfiles = ("gitweb.cgi")
        cgi.assign = ( ".cgi" => "" )

Es ist außerdem das Modul 10-cgi.conf zu aktivieren:

sudo lighty-enable-mod cgi
sudo lighty-enable-mod gitweb

In der /etc/gitweb.conf sind auch noch Anpassungen zu tätigen. Hier meine geänderten Zeilen:

$projectroot = "/var/lib/gitolite/repositories";
$projects_list = "/var/lib/gitolite/projects.list";
@diff_opts = ('--find_renames', '--minimal');

Urspünglich war jetzt hier noch eine Beschreibung zum Mirroring, ich verschiebe das auf später und tu es in einen separaten Artikel … O:-)

  1. auch den Pfad kann man beim dpkg-reconfigure angeben. []
  2. Dieser Schritt kann natürlich entfallen, wenn man die Repositories im Standard-Pfad belässt. []
  3. Die Rechte der bei der Installation angelegten Repositories sind allerdings immernoch so restriktiv, dass sie nicht über gitweb angezeigt werden können. Bei <code>gitolite-admin</code> will man das sowieso nicht und statt <code>testing</code> legt man sich vielleicht ein weiteres Testrepository an, um zu sehen, ob das mit den Rechten beim neu anlegen richtig klappt. []
  4. Siehe auch gitweb im ArchWiki. []

Debian GNU/kFreeBSD in Xen HVM DomU mit Verschlüsselung und ZFS

Ich will Backup und ich will ZFS, da brauch ich glaube ich in beiden Fällen nicht drauf eingehen warum. Auf dem Server läuft ein Debian Wheezy (amd64) und mit Xen werden diverse virtuelle Maschinen ausgeführt. Für’s Backup sind vier Platten vorgesehen und da soll ZFS drauf und die Daten sollen verschlüsselt werden.

Wie ich jetzt darauf gekommen bin das ganze mit Debian GNU/kFreeBSD zu realisieren, sei mal nicht in Frage gestellt, ist jetzt so und es gibt eine VM, die mittels Hardware-Virtualisierung der CPU installiert wurde, hatte ich ja hier schon erwähnt wie. Probleme mit der I/O-Performance hab ich dank der passenden Mailingliste auch beheben können.

Bevor wir jetzt ZFS installieren, soll noch Crypto drunter. Das könnte man auch anders schichten, aber so rum scheint empfohlen zu sein. Ebenfalls empfohlen ist es Crypto nicht auf die nackte Platte zu tun (auch wenn das ginge) sondern die Platten noch zu partitionieren. Bei BSD scheint da mittlerweile GPT der Standard zu sein und das passende Tool bei FreeBSD wäre gpart. Beim Debian GNU/kFreeBSD haben wir aber Debian Userland und da gibt’s dieses Tool nicht. Partitioniere ich also mit gdisk, dachte ich mir, aber das ist dann auch wieder nicht so einfach, weil gdisk sich beschwert, dass /dev/da0 ein character device sei. Ist es auch, scheint bei BSD so zu sein, bedeutet aber, dass ich die Platten nicht in der VM partitionieren kann, sondern das bereits im Wirt tun muss. Mit gdisk war das kein Problem und als Partitionstyp hab ich mal FreeBSD ZFS benutzt aka 0xA504.

Nächster Schritt: Verschlüsselung. Da benutzt man bei FreeBSD das Tool geli und das ist dann wieder Kernel Space genug, dass es auch verfügbar ist. Befehle hier:

% sudo geli init -s 4096 -l 256 /dev/da0p1
Enter new passphrase:
Reenter new passphrase: 

Metadata backup can be found in /var/backups/da0p1.eli and
can be restored with the following command:

        # geli restore /var/backups/da0p1.eli /dev/da0p1

Und dann:

% sudo geli attach /dev/da0p1
Enter passphrase:

Beim Initialisieren kann man auch noch Keydateien angeben und alle möglichen Optionen setzen. Details dazu hat das FreeBSD-Handbuch. Analog wird mit den anderen Platten verfahren und es stehen einem dann die aufgeschlossenen Devices zur Verfügung, für die erste verschlüsselte Partition der ersten Platte hier /dev/da0p1.eli welches dann gleich einem zpool hinzugefügt wird.

Den zpool namens tank erzeugte ich dann so:

sudo zpool create tank raidz2 da0p1.eli da1p1.eli da2p1.eli da3p1.eli

Das entspricht de facto einem RAID-6 und ist auch bereits unter /storage gemountet. Für den nächsten Systemstart fehlt also nur noch ein Skript, was mir die Crypto-Devices aufmacht. Bei Debian GNU/kFreeBSD kann man da mal in /etc/default/geom schauen. Das darauf liegende ZFS wird dann automatisch gefunden und eingebunden.

Alles weitere ist dann Anwendung von ZFS, das wäre thematisch aber was für einen anderen Artikel. ;-)


Auf dem neuen Rechner im Büro ist (natürlich) Debian installiert, mit KDE, so wie auf allen meinen Rechnern. Flotte Kiste und ich hab mir nichts weiter dabei gedacht, dass nach dem Einloggen kein Splash Screen erschien, schnell halt die Mühle. Durch einen Zufall bin ich aber heute nochmal bei den Einstellungen der Splash-Screens gelandet und stellte fest, dass »Default« zwar funktionierte, das von mir bevorzugte »joy« des aktuellen Debian-Release Wheezy jedoch nicht. Warum? Gar nicht so leicht rauszufinden, aber was aufgerufen wird, ist wohl sowas wie das hier:

adahl@ada ~ % ksplashx joy --test     
libpng error: Read Error
Failed to load: background.png

Huch, was ist da denn das Problem? Mein Monitor läuft in keiner der Auflösungen, wo im Paket desktop-base Bilder mitgeliefert werden, also mal mit strace geschaut, was er da öffnen will:

open("/home/adahl/.kde/cache-ada/ksplashx/joy-1680x1050-background.png", O_RDONLY) = 5

Hmm, da hat wohl wer umgerechnet und abgelegt, und …

adahl@ada ~ % ls -l ~/.kde/cache-ada/ksplashx/
insgesamt 2028
-rw-r--r-- 1 adahl adahl 2076229 Jun  1  2012 Default-1680x1050-background.png
-rw-r--r-- 1 adahl adahl       0 Aug 23  2012 joy-1680x1050-background.png

Na sowas?! Also kurzerhand die leere Datei gelöscht und schon geht das! :-)

Wireshark als normaler Nutzer ausführen

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

sudo dpkg-reconfigure wireshark-common

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

sudo addgroup adahl wireshark

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.