Tag Archive for 'debian'

Deploying Perl Web-Apps with Puppet

Since I was asked for I’d like to show one way of how you can deploy your perl web apps using debian packages and puppet.

This post assumes that you want to install some Plack webapps, e.g. App::Standby, Monitoring::Spooler and Zabbix::Reporter.

Those are pretty straight-forward Plack Apps built using Dist::Zilla.

cd Monitoring-Spooler
dzil build

I’ve built debian packages of these CPAN modules. Using dh-make-perl this is reasonably easy, although you’ll need some switches to make dh-make-perl a little less picky:

dh-make-perl --vcs rcs --source-format "3.0 (native)" Monitoring-Spooler-0.04

After building and uploading these packages to my repository I continue to use Puppet to install and configure those.

For each of these packages there is a custom puppet module, e.g. app_standby for managing App::Standby. This module create all necessary directories, manages the configuration and installs the package from my repository. It does not, however, set up any kind of webserver or runtime wrapper. This is done by another module: starman.

For running my Plack apps I use Starman which is managed by it’s own puppet module. It will install the starman package, manage it’s config and create an apache config. The interesting part is that I use puppet to automatically create an apache config and a simple Plack/PSGI multiplexer app that allows me to handle requests to all three (or more) of these apps using a single starman instance.

If these apps were rather busy I’d use a separate starman instance for each one, but as it is I’m more than happy to avoid the overhead of running multiple starman instances.

My starman module is invoked from one of my service classes like this:

  class { 'starman':
    configure => {
      mounts    => {
        'zreporter'     => '/usr/bin/zreporter-web.psgi',
        'monspooler'    => '/usr/bin/mon-spooler.psgi',
        'monapi'        => '/usr/bin/mon-spooler-api.psgi',
        'standby'       => '/usr/bin/standby-mgm.psgi',

The starman module itself is pretty straight-forward, but below are the templates for the apache config and the PSGI multiplexer.


<IfModule mod_proxy.c>
<% if @configure.has_key?("mounts") -%>
<% @configure["mounts"].keys.sort.each do |mount| -%>
   <Location /<%= mount %>>
      Allow from all
      ProxyPass           http://localhost:<%= @configure.has_key?('starman_port') ? @configure["starman_port"] : '5001' %>/<%= mount %>
      ProxyPassReverse    http://localhost:<%= @configure.has_key?('starman_port') ? @configure["starman_port"] : '5001' %>/<%= mount %>
<% end -%>
<% end -%>


use strict;
use warnings;

use Plack::Util;
use Plack::Builder;

my $app = builder {
<% if @configure.has_key?("mounts") -%>
<% @configure["mounts"].keys.sort.each do |mount| -%>
   mount '/<%= mount %>'  => Plack::Util::load_psgi('<%= @configure["mounts"][mount] %>');
<% end -%>
<% end -%>
   mount '/'           => builder {
        enable 'Plack::Middleware::Static', path => qr#/.+#, root => '/var/www';
        my $app = sub { return [ 302, ['Location','/index.html'], [] ]; };


VBoxAdm 0.0.16: Debian package and translation updates

The latest release of VBoxAdm features Debian Packaging and translation updates. Several new translations are now available. Please note that most of these are machine translations, so I’d gladly accept any suggestions for improvements.

debsign: clearsing failed: secret key not available

Have you ever had the problem that you could not build and sign a debian package because gpg/debsign/dpkg-buildpackage did claim that your secret key was not available although the key was there and you used the -k option to tell dpkg which key to use and the environment variable DEBFULLNAME and DEBEMAIL were set?

Well, dpkg does something very stupid: It takes the Name and Email from the last changelog entry (Ok, so far) and does a full string match (Ouch!!!)! Why is this stupid? Because my key contains an alias, and if you’re reading this yours probably, too.

I don’t want my alias in the changelog entry, but until now this is the only solution I’ve found for this issue.

So, if you get errors like this:

Now signing changes and any dsc files…
signfile package_0.1-1.dsc Firstname Lastname <user@domain.tld>
gpg: skipped “Firstname Lastname <user@domain.tld>”: secret key not available
gpg: /tmp/debsign.XdvV0Yi2/package_0.1-1.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting….
debuild: fatal error at line 1246:
running debsign failed
debuild -i -I returned 29
Couldn’t run ‘debuild -i -I’

Then you should look at the output of gpg -K and the last debian/changelog entry:

sec   2048D/DEADBEEF 2010-01-01
uid                  Firstname Lastname (nickname) <firstname.lastname@domain.tld>

package (0.0.1-1) unstable; urgency=low

* Initial release

– Firstname Lastname <user@domain.tld>  Mon, 06 Dec 2010 18:22:40 +0100

The problem here was the last line of the latest changelog entry. After changing it to

– Firstname Lastname (nickname) <user@domain.tld>  Mon, 06 Dec 2010 18:22:40 +0100

everything worked.

If you ask me: This is a bug with dpkg which should be fixed.

KDE4.4: Getting rid of Akonadi-MySQL Startup Errors

Since upgrading to KDE4.4 I’ve got startup errors each time Akonadi was started due to some missing MySQL system tables.

It’s easy to fix this:

akonadictl stop
mysql_install_db  --datadir=$HOME/.local/share/akonadi/db_data
akonadictl start

And don’t forget to install akonadi-kde-resource-googledata. Thanks to Trumpton.

udev Notes

udevinfo was renamed to/replaced by udevadm in Debian sid. Must tutorials still refer to udevinfo.

A udev rule that works on sid w/o warnings would be something like this for a garmin gps device:

# cat /etc/udev/rules.d/51-garmin.rules
ATTR{idVendor}=="091e", ATTR{idProduct}=="0003", MODE="666", SYMLINK+="GarminGPS"

Voyage Linux on an ALIX.2D13

I’ve just spent far too much time trying to install voyage linux on my new ALIX.2D13. Everything was fine, the only problem was that I did try to use GRUB and that wasn’t working. After changing to LILO it works like a charm. The problem is probably caused by a huge version gap between etch and sid. Etch has some something like 0.9x and sid 1.9x. I thought that the Voyage installer would use the shipped grub inside a chroot. Anyway, LILO works and this is fine. I have no special requirements for this box’s bootmanager. As soon as everything is set up and tested the box is going to be deployed.

The installation of voyage linux itself is covered in detail in the Getting Started guide.

Very usefull information can be found at networksoul and this chaos wiki.

I recommend picocom to connect to the serial console:

picocom –baud 38400 –flow n –databits 8 /dev/ttyUSB0

If your computer doesn’t have a serial port anymore, like mine, I recommend the LogiLink “USB2.0 to Serial Adapter” (UA0043 v.2.0). It’s cheap and works flawlessly. Another great LogiLink product I can reommend in this context is the LogiLink “USB2.0 Aluminum All-in-one Card Reader” (CR0001B v.2.0). Why I mention these two here? I find it hard to find cheap linux compatible adapters of which I know that they work on linux, so here is the information I would have like had before I bought those. The USB-Serial-Adapter is recognized as “Prolific Technology, Inc. PL2303 Serial Port”. The Card-Reader is shown as four separate drives.

Qt 4.6.2 ready to upload

It looks like Qt 4.6.2 is ready to upload. That means the upload of KDE 4.4 to Debian unstable should be very close.

The nasty libjpeg8 transition

I looks like some major confusion on the debian-release and debian-devel lists led to the upload of broken version of libjpeg8, the successor of libjepeg62. This could delay the freeze of squeeze further and lead to some breakage in unstable. Be warned and alert.

Moving Root-FS to Crypto-Raid

Have you ever tried to move your Debian root filesystem to a RAID? Ok, no problem so far. What about LVM-on-RAID? Still no trouble? Then what about Root-on-LVM-on-Crypto-on-RAID? Sounds funny. Debian has several helpscripts which are able to create a suitable initrd file for this kind of setup. This is good and bad at the same time. The good thing is that they can detect a correct setup and create an appropriate initrd. The bad about this is that it won’t work if you just moving your system to this kind of setup. Imagine you’re still on an ordinary partition without all this fancy crypto, raid and LVM stuff. If you just execute update-initramfs -k <kernel> -u/-c the initramfs tools and the supplied hook scripts won’t know about your intentions. So you’ll have to create a full equipped chroot, set everything up like it would be on a realy Root-on-LVM-on-Crypto-on-RAID-System and run update-initramfs there. Of course you could build the initrd by hand, but I’m not going this Gentoo way.

So, what do you have to do? First you’ll have to create your RAID, luks Volume and LVM on top of each other. See the Gentoo tutorial above for these steps. This should be pretty straight forward. The interesting part starts as soon as you try to boot from your new root. If you did follow the tutorial you should have a working Grub but it won’t be able to boot your system since it can’t unlock your root fs.

So, after you’re back into your good ol’ system setup the chroot. This includes assembling the RAID, unlocking your luks Volume and mounting the LV. So these are the steps, assuming sane defaults for folders, partitions and device names:

mdadm --assemble /dev/md2 /dev/sdc2 /dev/sdd2
cryptsetup luksOpen /dev/md2 cryptoroot
vgchange -ay vg
mount -t ext3 /dev/mapper/vg-root /mnt
mount -t ext2 /dev/sdc1 /mnt/boot
mount -t proc proc /mnt/proc
mount --bind /dev /mnt/dev
LANG=C chroot /mnt /bin/bash

So, now you’re inside your proper chroot. You could just run update-initramfs, but that’ll probably fail. You need to setup mdadm first and create your crypttab.

Your /etc/mdadm/mdadm.conf should at least contain the partitions to scan and your array.

The command mdadm –detail –scan >>  /etc/mdadm/mdadm.conf should do it. But verify the file yourself!

Next you have to tell the mdadm-initramfs-script to start this array on boot. This is set in the file /etc/default/mdadm. Insert the full name of your array (e.g. /dev/md2) into the INITRDSTART variable in this file.

Now define a proper crypttab and you should be ready to create a working initrd. Make your crypttab look something like this:

cryptoroot   /dev/md2  none  luks,tries=3

Just generate a new initramfs, update grub (if necessary) and reboot.

update-initramfs -k all -u

In case you encounter any error let me know, I’ll try to help.

KDE 4.4 is ready!

A few minutes ago KDE 4.4 was tagged in the SVN. Soon the package maintainers will start building binary packages and hopefully they will arive in Debian sid soon. I can’t wait to try out the new Akonadi-powered KDE-PIM packages and the improved plasma shell.

Let’s see which other features will be presented in the release notes.

Update: The Announcement on dot.kde.org is out:  KDE Software Compilation 4.4.0 Introduces Netbook Interface, Window Tabbing and Authentication Framework