Howto

Beamer i LaTeX

Jeg er blevet opfordret til at skrive en lille introduktion til LaTeX – nærmere betegnet Beamer klassen.

Beamer er en præsentations-dokumentklasse der kan bruges til at lave slides med.

Først og fremmest skal du have latex-beamer og pdflatex installeret:

# apt-get install latex-beamer texlive-latex-base

Burde kunne klare opgaven på et Debian (men sikkert også Ubuntu) system. Herfter har du dokumentklassen beamer tilgængelig, så vi kan starte dokumentet således:

documentclass[presentation]{beamer}
\usepackage[T1]{fontenc} % Sørger for danske tegn

Herefter begynder vi dokumentet og giver lidt information om os selv.

\begin{document}
 
\author{Mig!}
\title{Fed titel\\
\small{Endnu bedre undertitel}}
\institute[]{ Et herligt sted }

Nu kan vi bruge den information vi har indtastet til at lave en titelside og dernæst en indholdsfortegnelse.

\begin{frame}
  \maketitle
\end{frame}
 
\begin{frame}
  \frametitle{Indhold}
  \tableofcontents
\end{frame}

Nu kan vi så reelt starte med at lave indholdssider. Disse består typisk af et antal punkter som her:

\section{Første slide}
\begin{frame}
  \frametitle{Fantastisk titel}
  \framesubtitle{- snart}
  \begin{itemize}
    \item Detter er et punkt med en pause
    \pause 
    \item Og endnu en
    \pause
    \item Det er den sidste - på ære
  \end{itemize}
\end{frame}

Hvis man ønsker et billede i sin præsentation kan man inkludere det på samme måde som ved andre LaTeX dokumenter. Husk at der gælder de samme billedformatbegrænsninger som ellers ved brug af pdflatex.

\section{Et billede}
\begin{frame}
  \frametitle{Et billede}
  \framesubtitle{}
\begin{figure}[h]
 \centering
 \includegraphics[width=120pt]{database.pdf}
 \label{fig:database}
\end{figure}  
\end{frame}

En af de helt store styrker ved LaTeX er jo den matematiknotation – som der selvfølgelig også er til at integere en præsentation.

\begin{frame}
  \frametitle{Lad os \emph{} lave matematik}
  \framesubtitle{}
  \begin{equation}
    \displaystyle\sum\limits_{i=1}^{n} \frac{C_i}{T_i} \leq n \left( 2^{\frac{1}{n}} - 1 \right) 
  \end{equation}
\end{frame}

Til slut kan man jo indsætte klassikeren:

\begin{frame}
  \frametitle{}
  \framesubtitle{}
  \centering
  Spørgsmål?
\end{frame}
 
Og huske at slutte dokumentet
<pre lang="latex">
\end{document}

Du kan nu bygge din præsentation med

$ pdflatex presentation.tex

Hvis man ønsker at skifte tema, kan man gøre det med følgende kommandoer i starten af dokumentet.

\usepackage{listings}
\usetheme{Pittsburgh}
\usecolortheme{dove}

Der kan findes en fantastisk oversigt over de forskellige temaer med farvekombinationer på http://www.hartwork.org/beamer-theme-matrix/.

Du kan hente et fuldt eksempel (med billedfil) her:

Persistant enumeration of network interfaces across hardware addresses

If you’ve ever created a Linux virtual machine image for distribution, you have probably encountered this problem. The Virtualization is not really important – the problem exists on VirtualBox, VMWare, KVM, Xen and others supporting Linux guests.

So, what is the issue exactly?

The problem is that when you recreate a a virtual machine using an existing image, a new MAC address is generated. Udev sees this new address and creates a static name for it – e.g. eth1. Keeping the original – now removed – eth0 in the persistant naming file.

This interface typically does not exist in the /etc/network/interfaces file, and therefore is never “upped”. This leaves you with a machine that has no network connection out of the box.

Well, how do I fix it then?

The simple solution is to remove the /etc/udev/rules.d/70-persistent-net.rules file and reboot.
This means you have to remove the file as the last thing you do before shipping the image. I you make changes to the image, and reship it – you must do this every time. Plus it prevents easy redistribution of your image.

So, I’ve placed a small bash script at /usr/local/bin/reenumerate_interfaces and called it from /etc/rc.local.

This script also have the advantage, that you do not have to reboot the machine for the changes to take effect.

#! /bin/sh
 
echo Re-enumerating the network interfaces...
 
# Stop networking
/etc/init.d/networking stop
<pre lang="bash">
# Get the drivers and bounce the NICs
lspci -nnv | awk '{
if ($0 ~ /^$/) { getDriver = 0; }
if (getDriver == 0 && $0 ~ /.*Ethernet controller.*/) { getDriver=1; }
if (getDriver == 1 && $0 ~ /.*Kernel driver.*/) { printf ("%s\n", $5); }
}' | sort | uniq | while read a; do
 
echo Unloading network module $a from kernel space
rmmod $a
done
 
# Remove the static enumerations
rm /etc/udev/rules.d/70-persistent-net.rules
 
echo Reloading driver via udev
# Tickle udev
/sbin/udevadm trigger
 
# Start networking
/etc/init.d/networking start

Migrating Dovecot 1.2 Maildir to Dovecot 2.0 dbox

I am in the process of migrating to a new mail server. Therefore I need to, as painlessly as possible, move users. The details about the setup is another story for another day – promise.

This guide is targeted for Debian systems, but the concepts apply for all other systems as well.

Dovecot 2.0 comes with a nice tool called dsync which eases migration by a great deal. Unfortunately, my current mail server runs Dovecot 1.2 and therefore does not have the tool.

What to do, then.

Basically I have thought up three options for migrating.

  1. Using dsync on both sides
  2. Using rsync, then dsync
  3. Using dsync over sshfs

This post will serve as documentation for my experiments with mailbox migration.

If you are in a hurry, you can skip to the conclusion.

Using dsync on both sides

Being that I run Dovecot 1.2 and thus do no have dsync available I will need to pull down the sources and compile them myself. (I do not want to use dpkg’s as they may intervene with the existing installation.)

I got as far as getting the source compiled, but have not investigated further. Some paths were wrong – I cowardly quitted.

Later experiments with the two other approaches have shown that this, most likely, will not prove successful.

Using rsync then dsync

Next solution was to create a two step migration solution. First I used rsync to copy my Maildir mailboxes to the new server.

rsync -poazuHK -e ssh \ 
     root@oldmailserver.tld:/var/spool/postfix/virtual/ \ 
     /var/vmail.migrate/

You can log in as root here, as the -o (preserve ownership) maps the uname to the uid on the target system. Clever :-)

Then, run dsync for each user in order to import the new emails.

dsync -R -u myaddress@mydomain.tld backup \
maildir:/var/vmail.migrate/mydomain.tld/myaddress/Maildir/

Mirroring does not really make sense here as we have a local copy of the mailbox

This approach is by far the fastest and easiest.

Using dsync over sshfs

Notice: This only works with backup and not mirror.

Why? Dovecot2 log format is incompatible with Dovecot1’s that will timeout with a message about an unknown record type (0x8000) after a mirror operation.

# apt-get install sshfs
sshfs -o uid=`id -u vmail` -o allow_other \
vmail@oldmailserver:/var/spool/postfix/virtual/ \
/var/vmail.lucretia/

Remember the -o allow_other or the dsync will fail because the vmail user will not have access to the mount point.

Then, run dsync for each user in order to import the new emails.

dsync -R -u myaddress@mydomain.tld backup \
maildir:/var/vmail.oldhost/mydomain.tld/myaddress/Maildir/

Ownerships is of the essence here. Do not use root as this user will take ownership of dovecot metadata files causing your source mail server to coredump or just stall.
vmail is not the best option either – but I was lazy. You should take advantage of the fact that the vmail folders are (usually) gid vmail. Putting a migration user in this group and chmodding will probably be preferred, security-wise.

This approach works well when refined (eg. usíng the right uid on both sides), but is pretty slow – about 100kb/s sync. This not really acceptable for 1GB+ mailboxes. But as always, your milage may vary.

Your remote Dovecot will keep on running as nothing has happened – if you get the permissions correct. Unfortunately there are problems with the dovecot transaction log resulting in problems with uid of the Mailbox being inconsistent, resulting in something like this:

Error: Corrupted transaction log file /var/vmail/domain.tld/username/dbox/mailboxes/INBOX/dbox-Mails/dovecot.index.log seq 4: indexid changed 1313910265 -> 1313868319 (sync_offset=0)

Conclusion

My previous attempts have lead me to one conclusion: I need to move the mailbox once.

I chose the rsync+dsync approach and then did the following:

  1. Migrated all users to the new server
  2. Updated DNS
  3. rsync’ed first time
  4. Stopped the Dovecot and Postfix service on the old server
  5. rsync’ed second time
  6. dsync’ed the mailboxes
  7. Turned virtual_mailbox_maps and domains into relay_recipient_maps and domains respectively

If you decrease the TTL for you domain up until the move, you can minimize downtime. If you maintain a local DNS – even better.

This is not the fancy minimal down-time approach I had hoped for, but it has been sufficient for my needs. Feel free to contribute feedback.

Troubleshooting

I got a:

dsync(root): Fatal: Mail locations must use the same virtual mailbox
hierarchy separator (specify separator for the default namespace)

Some google-ing revealed that I needed to setup a namespace separator. The technical explanation for this left to the more Dovecot-savy.

In short, add the following to /etc/dovecot/conf.d/10-mail.conf (or uncomment the relevant ones).

namespace {
  separator = /
  inbox = yes
}

An now it works. migration is just a matter of setting up a cron job now, lower the TTL on the domain and move in day or two.

I got some

Error: Can't rename mailbox INBOX to
INBOX_ff3e01082bcf4e4e352c00002b747e8a:
Renaming INBOX isn't supported.

Using rsync->dsync which I haven’t been able to solve yet. Maybe shutting down the Dovecot service on the remote side would help. Race conditions are likely to occur.

Proftpd and LDAP on Debian Squeeze

This is a short howto (hopefully) providing enough information to install Proftpd and use LDAP as user database.

Background

I have become obsessed with LDAP – at least for the time being. It seem to be the answer to my redundancy and distribution plans.

A production server is in the process of being converted (migrated actually) to have a single SSO LDAP structure.

A virtualization host crash (thank you Linode) forced me to move a couple of sites onto this new fancy LDAP server. Shortly after, a user prompted me about the lack of FTP on the new webhost.

Now the shoe needs to fit.

Installing the required packages

This is the easy part.

# apt-get install proftpd-mod-ldap

The LDAP module will depend on the proftpd server so this is really the only thing you need to install.

Requirements for the LDAP server

The LDAP module for Proftpd is hard coded to lookup only users of objectClass: posixUsers which in my opinion is less intuitive than having a specified schema for proftpd.

An example .ldif is shown below. I have added objectClass: domain, which is unnecessary.

The uidNumber and the gidNumber maps the uid and gid on the system. 115 is proftfd user and 65534 is group nobody. From a ftp client owner will appear as domain.tld or whatever you specify as uid.

version: 1

dn: dc=domain.tld,ou=webhosting,dc=example,dc=com
objectClass: domain
objectClass: top
objectClass: posixAccount
cn: domain.tld
dc: domain.tld
gidNumber: 65534
homeDirectory: /var/www/domain.tld/www
uid: domain.tld
uidNumber: 115
loginShell: /bin/false
userPassword::

Configuring the authentication

First you need to edit /etc/proftpd/ldap.conf to match you LDAP setup. Somthing like this is appropriate.

<IfModule mod_ldap.c>
  LDAPServer ldap://example.com/??sub
  LDAPDNInfo "cn=proftpd,dc=example,dc=com" "password"
  LDAPDoAuth on "ou=webhosting,dc=example,dc=com"
</IfModule>

notice the ??sub after the ldap. This is very important as it specifies the search scope. The configuration parameter LDAPSearchScope is apparently ignored.

Again, a sour comment; the bind should have been done as the user logging in, and not as a dedicated user. Admin is a bad choice – create a dedicated user. Besides, the /etc/proftpd/ldap.conf is world readable!

Next you have to tell proftpd to load the module.
Uncomment the line

LoadModule mod_ldap.c

in /etc/proftpd/modules.conf.

Now you have to uncomment the line.

Include /etc/proftpd/ldap.conf

in /etc/proftpd/proftpd.conf to load the Ldap configuration.

Finally:

While editing proftpd.conf you should also lift the RequireValidShell restriction (or give the user a valid loginShell parameter. If do not do this, you will not be able to log in.

Now is the time to take a look at the standard proftpd configuration and make sure that anonymous login is disabled and ditto /etc/passwd users.

HD time-lapse movies with Motion and Linux

NSLU2 with webcam
The system

Background

I have previously experimented with time lapse videos, but wanted a more dedicated platform which could be set up, and run pretty much anywhere.

This is the first iteration, where the the purpose is to get the system up and running with headless operation.

Components

The original idea was to use a PC Engines alix1d system board in a box1c enclosure, but unfortunately the board I had was running very unstable – so I brought in an old friend of mine:

The Linksys NSLU2 aka. “slug”. The one I had ran Debian 5.0 Lenny, but had to be upgraded in order to get the webcam to work.

I recklessly tried doing a dist-upgrade, but ended up with bricked slug. Guess a fresh installation was the right answer indeed.

Debian Squeeze on a NSLU2

Due to a required proprietary firmware, the official Debian 6.0 installer does not ship with support for the on board Ethernet controller – which is bad because this is the only way of communicating the the device. Well, technically you can use the serial pin header or an USB Ethernet device, but I think I have burned the circuit for the serial port in a previous modding attempt :-\

There is a few guides that  give you directions on how to add the proprietary firmware to the installer image, and after about 5 reflashes I finally had one that worked.

Before starting the installation, I checked around for known installation errors. The installation takes about 5 hours, so you really want to get i right the first time.

I learned that others had experienced out of memory errors during the installation. Though luck.

To the rescue came Martin Michlmayr. He has the answer to all my quarrels; a compiled guide, with a complete Debian 6 userspace and kernel. This saved me a lot of time.

 Install and configure Motion

You can install motion by

apt-get install motion

as root or via sudo.

On Debian (Squeeze in my case), Motion is disabled by default – as many other services. Enable it, as mentioned in the notice:

Not starting motion daemon, disabled via /etc/default/motion ... (warning).

Setting the value start_motion_daemon to yes in /etc/default/motion as such:

start_motion_daemon=yes

 

The trick to disable motion detection in Motion, is to set the threshold to 0 in the config file:

threshold 0

Enabling time-lapse by setting the following in /etc/motion/motion.conf:

# Use ffmpeg to encode a timelapse movie
# Default value 0 = off - else save frame every Nth second
ffmpeg_timelapse 10

In this case, I take a pictures every ten seconds.

You should also adjust the width and height parameters, and the target_dir.

You can also get a copy of my preconfigured motion.conf by running the following set of commands

/etc/init.d/motion stop
mv /etc/motion/motion.conf /etc/motion/motion.conf.orig
wget http://retrospekt.dk/files/motion.conf -O /etc/motion/motion.conf
mkdir /home/motion
chown motion:motion /home/motion
chown root:motion /etc/motion/motion.conf
chmod g+r /etc/motion/motion.conf
/etc/init.d/motion start

An example can be seen here: http://retrospekt.dk/files/timelapse.mpg

Budget-friendly FreeNAS raid-z

When I wrote my previous post, I did not want to too much into detail about my NAS setup.  But, I still had an urge to tell about the splendid configuration.

My motivation for setting up my own freenas server, was my very positive previous experience with the software. And, by having my own configuration, I would be better able to provide both usability and technical troubleshooting.

These sort of posts are usually only of interest of potential buyers googling a specific product – and likewise software product.

But, without further adieu here is:

Yet another hardware configuration blog post

FreeNAS logo

The NAS consists of the following components

  • Jetway NC9C-550-LF motherboard
  • 2GB DDR3 1333 SODIMM I bought along with the motherboard
  • Jetway 4x SATA daughterboard
  • 4x WD20EARS harddisks
  • Lian Li 6070 Scandinavian edition chassis
  • An old usb key (2Gb .. I think)
  • An old pci ethernet adaptor

Lian li has apparently taken the chassis off their site, but Anandtech still has a nice review of the case.

The main reason I used this chassis is because I had it laying around, so to speak. The same goes for the motherboard, as it was a surplus from my previous NAS building experience.

The motivation for building the was the horrible near-datadeath experience I recently  had.So, I thought the time was ripe for a fault-tolerant storage medium.

As I had previously had a positive experience with both FreeNAS and zfs, the choice naturally fell on these. The installation is so very very easy: Download the the embedded gzipped image, put in an empty (or with non-precious content) usb key, and run the following (on a Linux box):

gunzip -c <path>/FreeNAS-amd64-embedded-xxx.img | dd of=/dev/sdx

Replacing the x’s and <path> with the relevant parameters.

Getting the RTL8111E to work

Note: This only applies to FreeNAS 7. The interface is supported in the FreeBSD 8.0 branch, and hereby FreeNAS 8.

The two onboard Realtek interfaces is not supported by the FreeBSD 7.3-RELEASE kernel.  This is also where the old pci network adapter comes in play. I used an older 3com 10/100 card, these are well supported.

However, you can get the onboard NIC’s up and running by downloading and installing the appropriate driver.

You can download the driver here: Realtek RTL8111E FreeBSD 7.3 64-bit driver

Remount /cf as read-write

# mount -o rw /cf

And place the driver in /cf/boot/kernel/

Lastly, you need to update /cf/boot/loader.conf to include the line if_rl_load=”YES” – and your’re done.

Now you can reboot, or remount /cf as read-only and use kldload to load the new driver.

You can follow a related discussion about the driver here.

The filesystem for the disks is zfs, and the raid-z pool is created manually as described in this previous post.

To finish it off: here are some photo’s of the current setup:

The 120mm fan is almost as large as the mainboard
A mini-ITX board looks kind of lonely in an ATX case :-)

Some words about performance

The embedded Atom CPU is definitely not a speed demon in any way. SSH transfer speeds peaks at 5 MB/s but are usually around 3-4 MB/s.
Sequential FTP uploads are about 25 MB/s. CPU usage is about 70% across all “cores”

As far as i can remember, the whole system uses about 50W.

The price of the system is not really represented here – as I have used spare parts, but similar components can be bought for about 450€

All in all a good, stable and robust system.

How to install LabVIEW on a Debian Machine

Labview ships prepackaged to install on rpm based Linux machines (Redhat, Mandrake and so on). But it is quite simple to convert and install it on a Debian machine instead.

The machine I will be using is a Thinkpad T40 with Debian Lenny installed, it should be the same for the current stable (Etch) but this is yet to be confirmed.

First we need to install alien

# aptitude install alien

The conversion process is quite simple, all you have to is to type

# alien -d *.rpm

And after some time (about 15 minutes or so on my laptop) you should be left with a bunch of .deb files.

You might have guessed it.. to install:

# dpkg -i *.deb

Now for the hacking part, when you try to run Labview all you get is this error:

/usr/local/natinst/LabVIEW-8.2/labview: symbol lookup error: /usr/local/natinst/LabVIEW-8.2/linux/libOSMesa.so.4: undefined symbol: _glapi_add_entrypoint

To work around this you need to install libosmesa (of current writing libosmesa6)

# aptitude install libosmesa6

and relink

# (cd /usr/local/natinst/LabVIEW-8.2/linux; rm libOSMesa.so.4; ln -s /usr/lib/libOSMesa.so.6 libOSMesa.so.4)

And it works! If you feel like it, you can also put a little icon on your desktop or in your Applications menu (this part is for gnome), this is the contents of the labview.desktop file with my corrections. It originates from /usr/local/natinst/LabVIEW-8.2/linux/gnome/gnome/apps/Applications/labview82.desktop and there is a similar file for KDE in the /usr/local/natinst/LabVIEW-8.2/linux/kde folder for those who want to make a KDE shortcut.
Contents of labview82.desktop

[Desktop Entry]
Name=LabVIEW 8.2
Comment=LabVIEW Graphical Dataflow Programming Environment
Exec=/usr/local/natinst/LabVIEW-8.2/labview
Icon=/usr/local/natinst/LabVIEW-8.2/linux/icons/labview-3d.xpm
Terminal=false
Type=Application
Categories=Application;Development;X-Red-Hat-Base

This file can be placed either in ~/.local/share/applications/ or in /usr/share/applications

Fjern Thumbs.db filer fra dit system

Windows genererer som standard en thumbnail database i en mappe med billeder, disse bliver så distribueret med når mapperne efterfølgende bliver brændt ned på skiver, komprimeret eller bare distribueret via nettet.

Der findes en kur

$ find ~ -name 'Thumbs.db' -print0 | xargs -0 rm -v >> rm.log

Find terminierer hver linie med en null karakter, og xargs bygger en argumentliste sepereret ved null karakteren, og sender listen til rm. -v argumentet beder rm om output som vi så skriver til rm.log