The gold linker
The gold linker is a new ELF included in the binutils package since version 2.19. It was implemented by Ian Lance Taylor so I leave the technical introduction to him. And of course Diego wrote some nice things about it.
So what we can gain from its usage compared to the bfd linker:
1. faster and more efficient linking (5 times have been estimated)
2. Detection of underlinking. I won't go into details, but read this post post for more details
So if you like to try it, use following little hack. But BE WARNED, things are likely to get broken, so don't use this on system packages and the kernel.
_gold() {
pushd /usr/bin
ln -sf x86_64-pc-linux-gnu-ld.${1} ld
ln -sf /usr/x86_64-pc-linux-gnu/bin/ld.${1} x86_64-pc-linux-gnu-ld
cd /usr/x86_64-pc-linux-gnu/bin/
ln -sf /usr/x86_64-pc-linux-gnu/binutils-bin/2*/ld.${1} ld
popd
}
setgold() {
_gold gold
}
unsetgold() {
_gold bfd
}
Pushing static routes with ISC DHCP server
Pushing static routes to your dhcp clients with pfsense was tricky because you have to specify the network and router informations as the raw hex values. Accomplishing the same task with the ISC DHCP server is easier. First of all, we have to declare the dhcp option in the global scope to the server:
option rfc3442-classless-static-routes code 121 = array of integer 8; option ms-classless-static-routes code 249 = array of integer 8;
The second line is for Windows clients, because MS decided to use the dhcp option 249 instead of the existing 121. The next step is to declare these options in our subnet definition:
subnet 192.168.1.0 netmask 255.255.255.0 {
... other options ....
option rfc3442-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2;
option ms-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2;
}The format of the options is:
<netmask>, <network-byte1>, <network-byte2>, <network-byte3>, <router-byte1>, <router-byte2>, <router-byte3>
where bytes with the value 0 are omitted. Again, you should include the default route in the options because dhcp clients are allowed to ignore the option routers x.x.x.x option. So, the line option rfc3442-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2 specifies the following routing informations:
24, 192, 168, 123, 10, 10, 10, 1: 192.168.123.0/24 via 10.10.10.1 0, 192, 168, 1, 2: 0.0.0.0 via 192.168.1.2 (default route)
Samsung Q330 Hotkeys
Emerge app-laptop/samsung-tools (more precise app-laptop/easy-slow-down-manager) for the samsung-backlight module, or try the SAMSUNG_LAPTOP option in the staging drivers area.
Put
{
/* Samsung Q330 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME, "Q330"),
},
.callback = atkbd_setup_forced_release,
.driver_data = atkbd_samsung_forced_release_keys,
}
in the /usr/src/linux/drivers/input/keyboard/atkbd.c file around line 1675. Recompile and reboot.
Use
setkeycodes e008 225 setkeycodes e009 224
to make this keys known.
Advanced DHCP Options: Pushing static routes to clients
The DHCP protocol contains several more or less options to configure the clients (e.g. PAC-Files, NTP-Servers, etc.). One of these cool options is the ability to push static routes to clients. This can be done in two different ways:
- Single route (DHCP Option 33)
- Classless Static Route (DHCP Option 121)
Single route
Pushing a single route is very easy. The configuration value consists of two ip address pairs in hex. The first address is the destination host, the second is the router.
Example:
Destination: 192.168.123.234 (Hex: C0:A8:7B:EA)
Router: 10.34.72.42 (Hex: 0A:22:48:2A)
The value is: C0:A8:7B:EA:0A:22:48:2A
If you configure a pfsense box, go to Services -> DHCP Server and add the value to the box "Additional BOOTP/DHCP Options". Its important to choose the type "String"!

Classless Static Routing
The DHCP option 121 follows a slightly different format. The format is <width of the subnetmask>:<netaddress>:<router address> (again, in hex).
Example:
Destination: 192.168.123.0 (Hex: C0:A8:7B:0)
Router: 10.34.72.42 (Hex: 0A:22:48:2A)
Subnet mask width: 24
Value: 24.192.168.123.10.34.72.42, in hex 18:C0:A8:7B:0A:22:48:2A

To provide multiple static routes, just concat all encoded values. According to RFC 3442, you should include the default route in the DHCP option 121, since clients are allowed to ignore the "default route" DHCP option if the server provides a value for the classless static routing option. The default route option is: 00:0A:0A:0A:02 (the routers ip is 10.10.10.2, the last 4 bytes), combined: 00:0A:0A:0A:02:18:C0:A8:7B:0A:22:48:2A.
Note: Windows systems up to Windows XP/Windows Server 2003 do not request the dhcp option 121 (they have to be tweaked manually to request this option). The linux dhcp client "dhcpcd" requests this option per default (if not, set option classless_static_routes in /etc/dhcpcd.conf).
Gentoo on Alix: Installing Gentoo
I decided to run a gentoo with uclibc, because it has a really small memory footprint (only 8 MB after boot). Due to the limit resources on the alix i set up a KVM Virtual Machine wich acts as the buildhost for the alix. The buildhost creates binary packages for the alix (shared via NFS).
Settings for make.conf:
CFLAGS="-march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
CHOST="i486-gentoo-linux-uclibc"If you wonder why i have a i486 CHOST not a i586 one, read this post. The installation of gentoo is basically the same as described in the Gentoo Handbook. I've used the PXE Boot option of the alix board.
Kernel Configuration
There a several important settings in the kernel configuration for the Alix boards. Here is the kernel configuration for sys-kernel/gentoo-sources-2.6.36-r5.
Configuring grub
To get input/output on the serial console, add these lines to your /boot/grub/grub.conf:
serial --unit=0 --speed=38400 --word=8 --parity=none --stop=1 terminal --timeout=3 console serial
To redirect the input/output of your kernel, add console=ttyS0,38400 to the kernel command line.
Gentoo on Alix: Serial console setup
Yesterday i finally got my PCEngines Alix 2d13 for my newest geek project. Its a small embedded board, perfect for running a linux distribution and acting as a firewall.
Connecting the serial console
Since the board has no vga/hid connector, you have to use a serial console connection to actually interact with your alix. Since none of my other boxes has a serial connector i ordered a USB to Serial Adapter. You have to enable the right kernel module for the cable. In my case it was a Prolific 2303:
Device Drivers USB support (USB_SUPPORT [=y]) USB Serial Converter support (USB_SERIAL [=y]) <*> USB Prolific 2303 Single Port Serial Driver
After connecting the cable to your USB Port dmesg tells you the device name:
pl2303 1-1.6:1.0: pl2303 converter detected usb 1-1.6: pl2303 converter now attached to ttyUSB0
Now, connect to the box with your favourite serial terminal program (e.g. net-dialup/minicom) using the following settings:
Device: /dev/ttyUSB0 (or /dev/ttyS0 for a real serial connection) Bps: 38400 Parity: None Data: 8 Stop: 1
Power on the alix. You should see the alix booting. If the console show weird characters, try varying the Bitrate. To boot from the CF card, i had to set the harddisk mode to LBA in the BIOS (To enter the BIOS, press S during the memtest).
Now, let us install Gentoo Linux on the alix.
Partitionstabelle clonen
Damit ich das nicht wieder vergesse:
sfdisk -d /dev/sda > layout_sda
sfdisk /dev/sdb < layout_sda
How to boot a gentoo LiveCD via PXE
Today i will show you how to boot a Gentoo LiveCD via PXE (aka network boot).
- Download a minimal install iso
- Prepare a TFTP Server
- Mount the ISO file as a loopback device (
mount -o loop /path/to/install-x86-minimal-20100216.iso /mnt/cdrom/) - Copy the Kernel (/mnt/cdrom/isolinux/gentoo) to your TFTP-Root
- Copy the InitramFS and the squash'ed root fs to a temp dir (/mnt/cdrom/isolinux/gentoo.igz and /mnt/cdrom/image.squashfs)
- Unpack the initramfs (
gunzip -c gentoo.igz | cpio -idv) - Patch the init script with this patch.
- Copy the RootFS to mnt/cdrom inside the initramfs (
mkdir -p mnt/cdrom; cp image.squashfs mnt/cdrom/) - Repack the initramfs (
find . -print | cpio -o -H newc |gzip -9 -c - > /path/to/tftp/root/initramfs.gz) - Edit your pxelinux.cfg/default file:
kernel gentoo append initrd=initramfs.gz root=/dev/ram0 init=/linuxrc loop=/image.squashfs looptype=squashfs cdroot=1 real_root=/
How to update a x86-uclibc stage tarball on an amd64 gentoo system
I recently needed a up-to-date stage for a Via Epia 5000 system. Since the hardware is very limited, and the processor is an i486 system (basicly a pentium pro with some missing features) i tried the uClibc stage. The update process of the somewhat out-of-date stage3 tarballs was really pain in the ass, so here is a guide to update the tarball to a recent portage/uclibc:
The Goal
- A current portage (read: EAPI=2 capable)
- A current udev
- baselayout-2 and openrc
- python 2.6
- gcc 4.3+
Requirements
- Some free disk space
- Time, many time
- Strong nerves
- A lot of coffee
Step 1: Prepare the build environment
For this guide i use the following paths:
/mnt/work/chroots/gentoo32-i486-uclibc: The directory for the chroot
Now, lets get to work:
# change to working directory
cd /mnt/work/chroots/gentoo32-i486-uclibc
# fetch the most recent uclibc stage3 tarball
wget http://gentoo.j-schmitz.net/mirror/experimental/x86/embedded/stages/stage3-x86-uclibc-2008.0.tar.bz2
# Extract the tarball
tar xjpf stage3-x86-uclibc-2008.0.tar.bz2
# Remove the old tarball
rm stage3-x86-uclibc-2008.0.tar.bz2
# Mount some dirs for the chroot
mount -o bind /dev/ dev/
mount -t proc /proc/ proc/
mkdir usr/portage
mount -o bind /usr/portage/ usr/portage/
# now, chroot (remove linux32 if your host system is x86)
linux32 chroot . /bin/bash
env-update && source /etc/profile
export PS1="(uclibc-chroot) $PS1"
Step 2: Update the stage
The most important thing is to get a recent portage, since many ebuilds use EAPI-2. First, we have to update python. But python does not like the old gcc. So a newer gcc is required for python. But hey, gcc-4.3.4 fails due to a missing header file. So updating uclibc first....
# Unmask the latest uclibc
mkdir /etc/portage
echo "=sys-libs/uclibc-0.9.30.1-r1 ~x86" >> /etc/portage/package.keywords
emerge uclibc -av
# Now update gcc to 4.3.4
emerge gcc -va
# switch to the new gcc
gcc-config i386-gentoo-linux-uclibc-4.3.4
source /etc/profile
export PS1="(uclibc-chroot) $PS1"
# due to a bug in the python ebuild emerge python without docs
FEATURES="nodoc noinfo noman" emerge =dev-lang/python-2.4.6 -av
# update python to 2.5. You may have to update automake to 1.10.3. See bug #317705
# emerge -1va =sys-devel/automake-1.10.3
MAKEOPTS="-j1" emerge python -va
# run the python-updater and update all packages.
python-updater -p
# Make sure that you have updated all python libs before un-emerging the old python version!
emerge -C '<dev-lang/python-2.5'
# update python to 2.6.
emerge python -va
# run the python-updater
python-updater -p
# Make sure that you have updated all python libs before un-emerging the old python version!
emerge -C '<dev-lang/python-2.6'
# Finally, we can update portage
emerge portage -av1
# Emerge app-portage/gentoolkit to be able to run revdep-rebuild. You need an
# updated version of app-misc/realpath to get that work with uclibc (see
# http://bugs.gentoo.org/show_bug.cgi?id=300657)
# The new ebuild is in our overlay!
emerge -1va =app-misc/realpath-1.15-r1
emerge gentoolkit -va
# run a revdep-rebuild
revdep-rebuild -i -vp
# Now, update all we have:
emerge --newuse --update --deep world -va
# remove the old gcc
emerge -Cav '<sys-devel/gcc-4.3.4'
# and build the whole bunch again
for x in linux-headers uclibc binutils-config binutils gcc-config gcc uclibc binutils gcc system world; do emerge -v1 $x; done
# clean up the environment
revdep-rebuild -i -vp
emerge --depclean -vp
revdep-rebuild -i -vp
Step 3: Install newer versions of openrc/baselayout
Now we have an up-to-date system, but we want a newer openrc and baselayout. Unmask these packages in /etc/portage/package.keywords:
=sys-apps/baselayout-2.0.1 ~x86 =sys-apps/openrc-0.6.1-r1 ~x86
After that, emerge them and update the config files:
emerge openrc -av
dispatch-conf
Step 4: Cleanup and creating a new tarball
At last, clean up all the temp directories leave the chroot and create a new tarball:
rm -rf /var/tmp/portage/*
rm /tmp/*
# (leave the chroot)
umount dev/ proc/ usr/portage/
# create the new tarball
tar cjf /tmp/gentoo-x86-uclibc-20100429.tar.bz2 .
And thats it! The updated stage3-tarball can be downloaded here.
Update: udev needs some extra work to run with uclibc. See comment #7 and #8 of Bug #272199
PXE-Boot
Ich habe mich ein wenig mit PXE-Boot und initramfs auseinander gesetzt, und ich muss sagen: das macht echt Spass!
Damit ich das nicht wieder vergesse, hier eine Step-by-Step-Anleitung wie man einen Rechner mit einem selbstgebauten Kernel und initramfs per PXE booten lässt:
Kernel-Konfiguration
Diese Konfiguration bezieht sich auf den Kernel der über das Netzwerk geladen und auf dem Client gestartet wird. Der Kernel muss alle Treiber beinhalten, die der Client zum booten und laden des initramfs braucht. Die Treiber müssen dabei einkompiliert werden; Module können zu diesem Zeitpunkt logischerweise noch nicht verwendet werden.
Die einzig wichtige Option in dem Kernel ist:
General Setup --> Initial RAM filesystem and RAM disk (initramfs/initrd) support (=y)
Initramfs erstellen
Für das initramfs legen wir uns ein paar Verzeichnisse an:
mkdir /usr/src/initramfs
cd /usr/src/initramfs
mkdir -p bin lib dev etc mnt/root proc root sbin sys
In dieses root-fs kopieren wir jetzt einfach alle Programme die wir
in unserer initrd benötigen. Idealerweise baut man die Programme mit
+static/+livecd so dass man nur das Executable kopieren muss. Falls das
Ebuild das USE-Flag nicht bereitstellt, muss man entweder schauen ob
das (hoffentlich vorhandene) configure-Script eine solche Option
bereitstellt, oder mittels ldd <executable> herausfinden welche
Dateien noch benötigt werden.
Anschliessend müssen wir nur noch das eigentliche Init-Script (PID=1) anlegen. Dieses Script wird nach dem mounten des initramfs gestartet und ist dafür verantwortlich, das neue Root zu mounten und den Init-Prozess an jemand anderen abzugeben.
#!/bin/busybox sh
# Mount the /proc and /sys filesystems.
mount -t proc none /proc
mount -t sysfs none /sys
# Mount the root filesystem.
mount -o ro /dev/sda1 /mnt/root
# Clean up.
umount /proc
umount /sys
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
Das init-Script mountet momentan einfach /dev/sda1 und startet den
normalen Init-Prozess. Sicherlich nichts wildes, aber der Fantasie sind
da keine Grenzen gesetzt :) Anschliessend noch +x setzen und fertig.
Das initramfs-File ist ein gzip-komprimiertes cpio-Archiv. Ein find . -print0 | cpio -ov -0 --format=newc | gzip -9 > /tmp/initramfs.cpio.gz erstellt das passende Archiv.
TFTP-Server konfigurieren
Ich habe hier als TFTP-Server net-ftp/atftp verwendet.
In /etc/conf.d/atftp stellt man ein beliebiges Verzeichnis ein, das als
Root des TFTP dienen soll. In diese Verzeichnis kopiert man den
gebauten Kernel, das initramfs-Image und /usr/share/syslinux/pxelinux.0 (PXE Bootloader aus sys-boot/syslinux). Weiterhin legt man ein Verzeichnix pxelinux.cfg
an, das die Configs für die Clients behinhalten wird. Der Bootloader
sucht automatisch nach einer Datei mit seiner MAC-Adresse in dem
Verzeichnis. Falls er die nicht findet, nimmt der die Datei default.
Das ist ganz praktisch, da man so Client-spezifische Konfigurationen
anlegen kann.
Die default-Datei beinhaltet folgendes:
prompt 0 timeout 30 label linux menu label Freaky PXE kernel bzImage append initrd=initramfs.cpio.gz vga=0x307
DHCP-Server konfigurieren
Während eines PXE-Boots stellt der Client eine DHCP-Anfrage. Daher müssen wir noch dem DHCP-Server sagen, was er denn einem Client antworten soll. Für dnsmasq gibt man folgendes an:
dhcp-boot=pxelinux.0,,192.168.0.123
Dies weist den Client an von dem Server 192.168.0.123 den Bootloader in pxelinux.0 zu laden.
Durchkicken
Nun kann man den Client neustarten. Wenn man im BIOS das booten vom Netz aktiviert hat, sollte der Rechner nun vom Netz sich das initramfs holen, und danach lokal weiterbooten. Je nachdem was noch in init steht, kann man hier noch die abgefahrensten Sachen machen.
Zum weiterlesen:
muCommander ebuild aktualisiert
Da habe ich doch glatt den Versionsbump beim muCommander auf Version 0.8.5 verpennt. Daher habe ich gerade die bin-Version im last-hope Portage Overlay auf Version das aktuelle nightly-build aktualisiert. Was alles neu ist kann man in den Release Notes zu Version 0.8.5 sowie der Readme zu den Nightlies nachlesen.
Wenn ich es nicht vergesse, werde ich das bin-Ebuild ab jetzt up-to-date halten.
Rsync über SSH
Um ein lokales Verzeichnis per Rsync über SSH auf einen anderen Rechner zu pusten, kann man dem rsync Kommando einen Tunnel mitgeben:
rsync -r -v -z --progress -t -e "ssh -i <YOUR-PRIVATE-KEYFILE> -l <REMOTEUSER>"
<LOCAL-DIR> <REMOTE-USER>@<REMOTE-HOST>:<REMOTE-DIR>
Loopback Filesystem
dd if=/dev/zero of=/root/loopfile bs=1024k count=20 losetup /dev/loop0 /root/loopfile mkfs -t ext2 -m 0 /root/loopfile mount -t ext2 /root/loopfile /mnt/sonstwohin
Das legt ein 20MB Loopfile an.
http://www.linux-magazin.de/heft_abo/ausgaben/2004/03/lese_schutz/(offset)/2
PPPoE-Konfiguration für T-DSL
Benötigt werden die Pakete
- ppp
- rp-pppoe
Konfiguration in /etc/conf.d/net (wenn eth1 mit dem Modem verbunden ist):
config_eth1=null
config_ppp0=ppp
link_ppp0=eth1
plugins_ppp0=pppoe
username_ppp0="<ANSCHLUSSKENNUNG><T-ONLINE-NUMMER>#0001@t-online.de"
password_ppp0="password"
pppd_ppp0=( debug
defaultroute
usepeerdns
)
Mehrere IPs
Um mehrere IPs an eine NIC zu binden muss man in der /etc/conf.d/net folgendes eintragen:
config_ethN=(
"192.168.0.1 netmask 255.255.255.0 brd 192.168.0.255"
"192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
"192.168.0.3 netmask 255.255.255.0 brd 192.168.0.255"
"192.168.0.4 netmask 255.255.255.0 brd 192.168.0.255"
)
routes_ethN=( "default gw 192.168.0.1" )
Dann nur noch das Netzwerkinterface neustarten und fertig.
Es ist noch nicht vorbei
Inspiriert von der Python-Hackerei und den Möglichkeiten die das Yahoo! Developer Network bieten, habe ich direkt das World-Heatmap Script von Simon Willison aus seinem Vortrag von den StackOverflow DevDays mit dem Yahoo Developer Network gekreuzt und herausgekommen ist diese Karte der Welt mit den Herkunftsländern der gebannten IPs der aktuellen Welle (rot ist böse):

Und weil ich gerade dabei war, habe ich auch noch eine für die am meisten abgelehnten Mails am Mailserver erstellt:

Hacking the Firefox history database
Hier habe ich ja bereits geschrieben, wie man einzelne URLs aus der Firefox History löschen kann (btw: funktioniert auch mit Formulardaten). Wenn man allerdings ganze Domains aus der History entfernen will, ist dieses Vorgehen zumindest mühsam.
Zum Glück speichert Firefox die History in einer Sqlite-Datenbank. Mit dem Tool SQLitebrowser kann man dir Datei ~/.mozilla/firefox/<profile>/places.sqlite öffnen, und in der Datenbank SQL-Befehle absetzen. Z.B. löscht ein
DELETE FROM moz_places WHERE url LIKE 'http://www.google.%'
alle auf Google besuchten Seiten. Praktisch, praktisch.
IPSEC-VPN Server unter Gentoo
Diese kurze Anleitung zeigt, wie man einen VPN-Server auf Basis von IPSEC/OpenSwan und Preshared-Keys via PPTP aufbaut.
Der Server hat folgendes Netzwerk-Setup:
- eine Netzwerkkarte richtung WAN: IP, bspw. 1.1.1.1
- eine Netzwerkkarte richtung LAN: IP, bspw. 10.0.1.1, der VPN-Server wird später auf einer anderen, freien LAN-IP laufen.
Benötigte Einstellungen im Kernel
Loadable module support --->
[*] Enable loadable module support
[*] Module unloading
[*] Forced module unloading
[*] Module versioning support
[*] Source checksum for all modules
[*] Automatic kernel module loading
Networking --->
Networking options --->
<*> Packet socket
<*> Unix domain sockets
<M> IPsec user configuration interface
<M> PF_KEY sockets
[*] TCP/IP networking
[*] IP: multicasting
[*] IP: advanced router
[*] IP: TCP syncookie support (disabled per default)
<M> IP: ESP transformation
<M> IP: IPComp transformation
<M> IP: tunnel transformation
<M> INET: socket monitoring interface
[*] Network packet filtering (replaces ipchains) --->
Device Drivers --->
Network device support --->
[*] Network device support
<M> PPP (point-to-point protocol) support
<M> PPP support for async serial ports
<M> PPP support for sync tty ports
<M> PPP Deflate compression
<M> PPP BSD-Compress compression
Cryptographic options ---> --- Cryptographic API --- HMAC support <M> MD5 digest algorithm <M> DES and Triple DES EDE cipher algorithms <M> AES cipher algorithms <M> AES cipher algorithms (i586) <M> SHA1 digest algorithm
Benötigte Pakete
- net-misc/openswan
- net-firewall/ipsec-tools
- net-dialup/xl2tpd
Konfiguration
Zunächst konfigurieren wir IPSEC mittels der /etc/ipsec/ipsec.conf:
# /etc/ipsec/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.15.2.6 2006/10/19 03:49:46 paul Exp $
# This file: /usr/share/doc/openswan-2.4.15/ipsec.conf-sample
#
# Manual: ipsec.conf.5
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# plutodebug / klipsdebug = "all", "none" or a combation from below:
# "raw crypt parsing emitting control klips pfkey natt x509 private"
# eg: plutodebug="control parsing"
#
# ONLY enable plutodebug=all or klipsdebug=all if you are a developer !!
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
nat_traversal=yes
# virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
#
# enable this if you see "failed to find any available worker"
nhelpers=0
## added
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
overridemtu=1410
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.0.1.0/24
conn %default
keyingtries=3
compress=no
disablearrivalcheck=no
keyexchange=ike
ikelifetime=240m
keylife=60m
conn VPN-Clients
leftprotoport=17/1701
rightprotoport=17/%any
rekey=no
authby=secret
pfs=no
type=tunnel
left=<EXTERNE-IP-DES-SERVERS>
leftnexthop=<GATEWAY-DES-SERVERS>
right=%any
rightsubnet=vhost:%no,%priv
auto=add
# Add connections here
# sample VPN connections, see /etc/ipsec.d/examples/
#Disable Opportunistic Encryption
include /etc/ipsec/ipsec.d/examples/no_oe.conf
Die letze Angabe in der Option virtual_private im Abschnitt setup muss auf das LAN-Netz des Servers zeigen, sprich das Netz aus dem die Clients nachher ihre IPs beziehen.
Als nächstes konfigurieren die Preshared-Keys (PSK) für die IPSEC-Ebene ind /etc/ipsec/ipsec.secrets.
<externe-ip-des-servers> %any: PSK "testpsk123"
Das hier eingegebene Password wird für die IPSEC-Konfiguration beim Client benötigt, und ist hier der Einfachheit halt für alle Clients gleich. Alternativ kann man für jeden Client einen eigenen Key anlegen, indem man das %any durch den Client ersetzt.
Im nächsten Schritt werden wir den Tunnel konfigurieren. Zuerst passen wir dafür die /etc/xl2tpd/xl2tpd.conf an:
; l2tpd.conf ; [global] port = 1701 [lns default] ip range = 10.0.1.200-10.0.1.210 local ip = 10.0.1.123 require chap = yes refuse pap = yes require authentication = yes name = MyVPN ppp debug = yes pppoptfile = /etc/ppp/options length bit = yes
Wichtig sind hier die Einstellungen ip range welche die von den Clients zu verwendende IP-Range festlegt (sollte sich nicht mit bestehenden IP-Adressen oder DHCP-Ranges überschneiden!), sowie local ip welche die IP des VPN-Servers festlegt. Letztere ist nicht die LAN-IP unseres Servers, sondern eine weitere, freie IP im LAN!
Die Datei /etc/ppp/options:
ipcp-accept-local ipcp-accept-remote ms-dns 1.1.1.2 noccp auth crtscts mtu 1400 mru 1400 +mschap-v2 nodefaultroute debug lock proxyarp connect-delay 5000
Die Option ms-dns sollte auf euren DNS-Server zeigen.
In der Datei /etc/ppp/chap-secrets werden nun noch abschliessend die Benutzer konfiguriert:
# Secrets for authentication using CHAP # client server secret IP addresses user1 * "pass1" 10.0.1.0/24 * user1 "pass1" 10.0.1.0/24
Die Angabe 10.0.1.0/24 legt fest, das der Client eine IP aus dem Bereich, den wir oben konfiguriert haben, bekommen soll. Die Angabe eine IP an dieser Stelle legt fest, das der Client immer die gleich IP bekommt.
Abschliessend noch die Daemons xl2tpd und ipsec starten.
Konfiguration der Clients
Unter Windows
- Über die Netzwerkumgebung eine neue VPN-Verbindung anlegen
- Eigenschaften der Verbindung -> Security -> IPSec Settings
- Use pre-shared key for authentication. Hier den PSK aus der ipsec.secrets angeben
- Unter Networking jetzt noch den Typ auf L2TP IPSec VPN stellen

Anschliessend kann man sich dann mit den Benutzern aus der chap-secrets am VPN anmelden.
Links
Today I fixed my HDD breakdowns
Since half a year I have had a nasty breakdown of my HDDs. I did alot of debugging but didn't find a solution until today. I will describe in short what happened and what I did. I have two Samsung HD403LJ in my box. They aren't the same age some the firmware differs but physically they should be the same. So from time to time randomly one the two quit to work. Following error shows up:
[ 719.004117] ata1: EH in SWNCQ mode,QC:qc_active 0x7FFFFFFF sactive 0x7FFFFFFF
[ 719.004329] ata1: SWNCQ:qc_active 0x1 defer_bits 0x7FFFFFFE last_issue_tag 0x0
[ 719.004331] dhfis 0x0 dmafis 0x0 sdbfis 0x0
[ 719.005861] ata1: ATA_REG 0x40 ERR_REG 0x0
[ 719.007651] ata1: tag : dhfis dmafis sdbfis sacitve
[ 719.007654] ata1: tag 0x0: 0 0 0 1
[ 719.007667] ata1.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen
[ 719.007673] ata1.00: cmd 61/48:00:cc:1d:e2/01:00:00:00:00/40 tag 0 ncq 167936 out
[ 719.007675] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007678] ata1.00: status: { DRDY }
[ 719.007682] ata1.00: cmd 61/c8:08:4c:1f:e2/01:00:00:00:00/40 tag 1 ncq 233472 out
[ 719.007684] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007686] ata1.00: status: { DRDY }
[ 719.007690] ata1.00: cmd 61/08:10:4c:21:e2/00:00:00:00:00/40 tag 2 ncq 4096 out
[ 719.007691] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007694] ata1.00: status: { DRDY }
[ 719.007698] ata1.00: cmd 61/08:18:dc:15:e0/00:00:00:00:00/40 tag 3 ncq 4096 out
[ 719.007699] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007702] ata1.00: status: { DRDY }
[ 719.007706] ata1.00: cmd 61/c0:20:54:21:e2/01:00:00:00:00/40 tag 4 ncq 229376 out
[ 719.007707] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007709] ata1.00: status: { DRDY }
....
[ 719.007882] ata1.00: cmd 61/a8:d8:ec:77:dc/03:00:00:00:00/40 tag 27 ncq 479232 out
[ 719.007884] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007886] ata1.00: status: { DRDY }
[ 719.007890] ata1.00: cmd 61/30:e0:54:55:e2/00:00:00:00:00/40 tag 28 ncq 24576 out
[ 719.007891] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007894] ata1.00: status: { DRDY }
[ 719.007898] ata1.00: cmd 61/80:e8:ac:7b:dc/00:00:00:00:00/40 tag 29 ncq 65536 out
[ 719.007899] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007901] ata1.00: status: { DRDY }
[ 719.007905] ata1.00: cmd 61/60:f0:34:7c:dc/00:00:00:00:00/40 tag 30 ncq 49152 out
[ 719.007907] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 719.007909] ata1.00: status: { DRDY }
[ 719.320779] ata1: soft resetting link
[ 719.473300] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 724.496619] ata1.00: qc timeout (cmd 0x27)
[ 724.496820] ata1.00: failed to read native max address (err_mask=0x4)
[ 724.496987] ata1.00: HPA support seems broken, skipping HPA handling
[ 724.500109] ata1.00: revalidation failed (errno=-5)
[ 724.809942] ata1: soft resetting link
[ 724.963301] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 724.977604] ata1.00: configured for UDMA/133
[ 724.977663] ata1: EH complete
[ 754.976619] ata1: EH in SWNCQ mode,QC:qc_active 0x7FFFFFFF sactive 0x7FFFFFFF
[ 754.976640] ata1: SWNCQ:qc_active 0x1 defer_bits 0x7FFFFFFE last_issue_tag 0x0
[ 754.976642] dhfis 0x0 dmafis 0x0 sdbfis 0x0
[ 754.976659] ata1: ATA_REG 0x40 ERR_REG 0x0
[ 754.976667] ata1: tag : dhfis dmafis sdbfis sacitve
[ 754.976677] ata1: tag 0x0: 0 0 0 1
[ 754.976695] ata1.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen
[ 754.976710] ata1.00: cmd 61/60:00:34:7c:dc/00:00:00:00:00/40 tag 0 ncq 49152 out
[ 754.976711] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 754.976730] ata1.00: status: { DRDY }
[ 754.976741] ata1.00: cmd 61/80:08:ac:7b:dc/00:00:00:00:00/40 tag 1 ncq 65536 out
[ 754.976742] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 754.976760] ata1.00: status: { DRDY }
[ 754.976770] ata1.00: cmd 61/30:10:54:55:e2/00:00:00:00:00/40 tag 2 ncq 24576 out
[ 754.976772] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 754.976790] ata1.00: status: { DRDY }
[ 754.976801] ata1.00: cmd 61/a8:18:ec:77:dc/03:00:00:00:00/40 tag 3 ncq 479232 out
[ 754.976802] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 754.976820] ata1.00: status: { DRDY }
[ 754.976831] ata1.00: cmd 61/e8:20:2c:75:dc/01:00:00:00:00/40 tag 4 ncq 249856 out
[ 754.976832] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
And so on. I googled alot but didn't find any solution. The problem was that I had no way to force this error so that I could go for real bug finding. Interestingly two days ago I did a
dd if=/dev/sda of=/dev/null dd if=/dev/sdb of=/dev/null
in two windows of a screen session and after around 20 seconds the disks crashed. From there I started to reproduce it with different live cds with different kernels but with no success. Only my latest working kernel (gentoo-sources-2.6.27-gentoo-r8) did it. So I started over took the livecd kernel from the latest minimal cd from gentoo and started round by round modifying the kernel towards what I had running. Long story short (I did built 11 different kernels, reboot, dded, reboot, built kernel, reboot...) it was the in kernel irq-balancing in combination with my nforce chips. Disabling the irq-balancing dropped the throughput by 10% but my disks are running stable again! (Beside the fact that the internal speed difference of the disk are 25%. So if anyone can give me new firmware for samsung disks, please drop a line) Happy day!!!
Prefering a package from the tree over a package from an overlay
You will all probably have come across the problem wishing to install a package from the tree but having an overlay with the same version of the package, but different code. And you will all have hit google with keywords "mask package overlay". But there is no solution straight. You cannot mask packages on an overlay basis. One thing I always did is copying the ebuild to my own overlay and being happy. But what if there are some improvements, bugfixes introduced in the maintree ebuild, you won't notice them. This morning a simple but brilliant idea came up my mind, why don't use symlinks. Hey, sometimes clever brains need a longer time!! The only thing you have to be careful with is that in the /etc/make.conf your overlay dir must be the last in the ${PORTDIR_OVERLAY}.
