Posts tagged: arch

iptables init-script für Arch

Ja, das vom Paket iptables mitgebrachte init-script leistet wunderbare Dienste. Nein, es besteht kein akuter Grund, eine Alternative zu schreiben…
Einen Nachteil hat es schon: die Konfiguration wird in einem nicht kommentierbaren Format hinterlegt, was bei mir in letzter Zeit ständig zur Frage “WTF hat doch gleich dieser Port da verloren? Was lässt die rule da nochmal durch?” geführt hat.

<bash-addicted>Yep, eindeutige Notwenigkeit für ein selbst gehämmertes, kommentierbares  Script!</bash-addicted> Wie in guten alten Debian-Zeiten übernimmt jetzt also bei mir ein einfaches, aber für den Job völlig ausreichendes init-script den Job. Wer es verwenden mag:

#!/bin/bash
 
#
#   easy-to-edit iptables init script for Arch
#           2010 by Alexander Koch
#
 
 
# TCP services: ssh
SERVICES_TCP=( 22 )
# UDP services:
SERVICES_UDP=( )
 
. /etc/rc.conf
. /etc/rc.d/functions
 
if [ -e "/etc/conf.d/iptables" ]; then
    . /etc/conf.d/iptables
fi
if [ -z "$IPTABLES" ]; then
    IPTABLES="/usr/sbin/iptables"
fi
if ! [ -x "$IPTABLES" ]; then
    echo "unable to execute iptables binary: $IPTABLES"
    exit 1
fi
 
function reset_tables() {
    ERR=0
    $IPTABLES -F || ERR=1
    $IPTABLES -X || ERR=1
    $IPTABLES -P INPUT ACCEPT || ERR=1
    $IPTABLES -P OUTPUT ACCEPT || ERR=1
    if [ $IPTABLES_FORWARD -eq 1 ]; then
        $IPTABLES -P FORWARD ACCEPT || ERR=1
        echo 1 >/proc/sys/net/ipv4/ip_forward || ERR=1
    else
        $IPTABLES -P FORWARD DROP || ERR=1
        echo 0 >/proc/sys/net/ipv4/ip_forward || ERR=1
    fi
 
    return $ERR
}
 
function setup_tables() {
    ERR=0
 
    # setup prevention chain against common attacks
    $IPTABLES -N preventions || ERR=1
    $IPTABLES -A preventions -f -j DROP || ERR=1                           # frags
    $IPTABLES -A preventions -p tcp --tcp-flags ALL ALL -j DROP || ERR=1   # XMAS
    $IPTABLES -A preventions -p tcp --tcp-flags ALL NONE -j DROP || ERR=1  # null
 
    # setup services chain
    $IPTABLES -N services || ERR=1
    for PORT in ${SERVICES_TCP[@]}; do
        $IPTABLES -A services -p tcp --dport $PORT -j ACCEPT || ERR=1
    done
    for PORT in ${SERVICES_UDP[@]}; do
        $IPTABLES -A services -p udp --dport $PORT -j ACCEPT || ERR=1
    done
 
    # allow incoming ping requests
    iptables -A services -p icmp --icmp-type echo-request -j ACCEPT || ERR=1
 
    # setup main chains
    $IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT || ERR=1
    $IPTABLES -A INPUT -i lo -j ACCEPT || ERR=1
    $IPTABLES -A INPUT -j preventions || ERR=1
    $IPTABLES -A INPUT -m state --state NEW -j services || ERR=1
    $IPTABLES -A INPUT -p tcp -j REJECT --reject-with tcp-reset || ERR=1
    $IPTABLES -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable || ERR=1
    $IPTABLES -P INPUT DROP || ERR=1
 
    return $ERR
}
 
case "$1" in
    start)
        stat_busy "Loading IP Tables"
        reset_tables
        if ! setup_tables; then
            stat_fail
            exit 1
        else
            add_daemon miptables
            stat_done
        fi
        ;;
    stop)
        stat_busy "Flushing IP Tables"
        if reset_tables; then
            rm_daemon miptables
            stat_done
        else
            stat_fail
            exit 1
        fi
        ;;
    restart)
        if ! ck_daemon miptables; then
            rm_daemon miptables
        fi
        $0 start
        exit $?
        ;;
    *)
        echo "usage: $0 {start|stop|restart}"
        ;;
esac
 
exit 0

Gefiltert werden nur eingehende Pakete; related und established Pakete werden ebenfalls ohne weitere Beachtung durchgelassen, ebenso alles über loopback. Für neue Pakete werden zuerst ein paar Vulnerability-Checks durchgeführt. Nach Außen wird ein Verhalten wie ohne iptables emuliert (z.B. REJECTs mit tcp-reset).

Bugreports wie immer willkommen, und Benutzung auf eigene Gefahr!

Update 31.07.10: Bugfixed :)

Netbook Screeny

XFCE mit AWN statt xfce4-panel

Back on KDE

Im Zuge meines Wechsels vom Notebook auf eine Workstation als Hauptrechner bin ich wieder auf KDE umgestiegen. Dabei entbrennt natürlich auch gleich mal wieder der übliche Toolkitwechsel und damit verbundene “iiieh, GTK!”-Wahn ^^

Für Mails bin ich wieder bei KMail, als Browser und lange gesuchte, mittlerweile ernstzunehmende Firefox-Alternative teste ich Arora.

KDE 4.4 auf Thor

Arch rc.sysinit: LUKS parallel

Im Arch Bootscript /etc/rc.sysinit werden u.A. die per /etc/crypttab definierten verschlüsselten Volumes geöffnet und gemountet – sequentiell. Da ein luksOpen-Aufruf generell schon recht lange dauert, kommen bei mehreren solcher Volumes schnell einige Sekunden zusammen.

Auf einer Kiste mit fünf LUKS-Volumes kam mir die Idee, die entsprechende Funktion mal per “&” zu forken und das Ganze so ein wenig zu parallelisieren.

In wie fern das jetzt tatsächlich im messbaren Bereich liegt, sei mal dahingestellt. Ich bilde mir jedenfalls erfolgreich einen Geschwindigkeits-zuwachs ein, und da der Patch meines Erachtens recht unkritisch ist, bleibe ich dabei :)

Wer es ausprobieren mag:

--- /etc/rc.sysinit.backup      2010-01-24 15:35:12.000000000 +0100
+++ /etc/rc.sysinit             2010-05-04 18:57:53.380890577 +0200
@@ -149,7 +149,7 @@
                        cpass="$3"
                        shift 3
                        copts="$*"
-                       stat_append "${cname}.."
+                       #stat_append "${cname}.."
                        # For some fun reason, the parameter ordering varies for
                        # LUKS and non-LUKS devices.  Joy.
                        if [ "${cpass}" = "SWAP" ]; then
@@ -188,15 +188,16 @@
                        fi
                        if [ $? -ne 0 ]; then
                                csfailed=1
-                               stat_append "failed "
+                               stat_append "${cname} failed "
                        else
-                               stat_append "ok "
+                               stat_append "${cname} ok "
                        fi
                fi
        }
        while read line; do
-               eval do_crypt "$line"
+               eval do_crypt "$line" &
        done </etc/crypttab
+       wait
        if [ $csfailed -eq 0 ]; then
                stat_done
        else

Arch ramdisk-script 1.4

In meinem Arch Ramdisk-Script <1.4 hatte sich ein dämlicher Bug eingeschlichen: bei sämtlichen rsync-Aufrufen fehlte das --delete.

Das bewirkt z.B. bei Verwendung mit Firefox, dass der Cache nie geleert wird und (streng) monoton wächst – unschön.

Hier die gefixte Version :)

#!/bin/sh
 
#
# Manages outsourcing of specified directories into memory on bootup and
# takes care of synchronization/backup on system shutdown.
#
# Version 1.4, 2010-04-26, by Alexander Koch
#
 
# includes
 
. /etc/rc.conf
. /etc/rc.d/functions
 
 
# configuration (syntax is: [persist. storage]:[mountpoint]:[mount options])
 
DISKS=('/home/alex/.ramdisks/_mozilla:/home/alex/.mozilla:size=100M,uid=1000,gid=100' \
	   'empty:/home/alex/.adobe:size=10M,uid=1000,gid=100' \
	   'empty:/home/alex/.macromedia:size=10M,uid=1000,gid=100')
 
 
# helper functions
 
function activate_rd() {
	[ -d "$1" ] || [ "$1" = "empty" ] || return 1
	[ -d "$2" ] || return 1
	mount | grep "$2" &>/dev/null && return 1
	MNT="mount -t tmpfs"
	[ -z "$3" ] || MNT="$MNT -o $3"
	$MNT none "$2"
	[ $? -gt 0 ] && return 1
	if [ "$1" != "empty" ]; then
		for D in $1/.* $1/*; do
			[ "$(basename "$D")" == "." ] && continue
			[ "$(basename "$D")" == ".." ] && continue
			rsync -axq "$D" "$2" &>/dev/null
			if [ $? -gt 0 ]; then
				umount "$2"
				return 1
			fi
		done
	fi
	return 0
}
 
function backup_rd() {
	mount | grep "$1" &>/dev/null || return 0
	if [ "$2" != "empty" ]; then
		for D in $1/.* $1/*; do
			[ "$(basename "$D")" == "." ] && continue
			[ "$(basename "$D")" == ".." ] && continue
			rsync -axq --delete "$D" "$2" &>/dev/null
			if [ $? -gt 0 ]; then
				tar -cf "/root/$(basename "$2")-failed.tar" "$1"
				return 1
			fi
		done
	fi
	umount "$1" || return 1
	return 0
}
 
 
# main logic
 
case $1 in
	start)
		stat_busy "Mounting ramdisks"
		error=0
		for M in ${DISKS[@]}; do
			FROM="$(echo "$M" | cut -d ':' -f 1)"
			TO="$(echo "$M" | cut -d ':' -f 2)"
			OPTS="$(echo "$M" | cut -d ':' -f 3)"
			activate_rd "$FROM" "$TO" "$OPTS" || error=1
		done
		if [ $error -eq 0 ]; then
			add_daemon ramdisks
			stat_done
		else
			stat_fail
			exit 1
		fi
		;;
	stop)
		stat_busy "Saving ramdisks"
		error=0
		for M in ${DISKS[@]}; do
			FROM="$(echo "$M" | cut -d ':' -f 2)"
			TO="$(echo "$M" | cut -d ':' -f 1)"
			backup_rd "$FROM" "$TO" || error=1
		done
		if [ $error -eq 0 ]; then
			rm_daemon ramdisks
			stat_done
		else
			stat_fail
			echo -n "WARNING: failed to save ramdisk(s), tried to make "
			echo "backup(s) under /root."
			echo "Hit enter to proceed shutdown."
			read DUMMY
			exit 1
		fi
		;;
	restart)
		if ! ck_daemon ramdisks; then
			"$0" stop && sleep 3
		fi
		"$0" start
		;;
	*)
		echo "usage: $0 {start|stop|restart}"
		;;
esac
 
exit 0

Dynamic DNS-Caching with PDNSd and DHCP

(I write this in English because I was asked to do so by some people on the Arch forums. Anyway, I think this should be no problem as if you hack on configs you normally understand enough to get this done as well.)

I’ve been using pdnsd for DNS caching for quite a while now and I can feel the speed up while browsing the web (at least I can go on believing so ;) ) or checking for updates in the AUR.
The problem with pdnsd in conjunction with mobile devices (like the netbook I’m typing this on) is that in the basic setup, it only uses static DNS servers, described in /etc/pdnsd.conf. So if you happen to get behind some firewall that doesn’t permit DNS queries to other nameservers than the ones advertised by DHCP, you have to change your setup manually – and switch back when you’re out.
It would be great if pdnsd took the DNS your machine got from DHCP and use it as primary source for cache-misses. This also uses the eventually existing DNS infrastructure and local caches, instead of bypassing them. Here’s how I implemented that, using pdnsd and dhcpcd:

  1. Setup pdnsd as described in the Arch Wiki article, but do not create a /etc/resolv.conf.head. Create a primary DNS source entry, mine looks like this:
    server {
    	label="maindns";
    	ip=8.8.8.8, 8.8.8.4;  # I use Google dns as fallback
    	proxy_only=on;        # Do not query any other name servers
    	timeout=4;            # Server timeout
    	uptest=none;          # No uptest
    	purge_cache=off;      # Keep stale cache entries in case the ISP's
    			      # DNS servers go offline.
    }
  2. In /etc/resolv.conf, the only nameserver should be your local machine:
    # /etc/resolv.conf
    nameserver 127.0.0.1
  3. In /etc/dhcpcd.conf, disable the resolv.conf-hook to prevent dhcpcd from changing the resolving scheme:
    [...]
    nohook resolv.conf
  4. In /usr/lib/dhcpcd/dhcpcd-hooks, we create a hook script (e.g. 21-pdnsd.conf) that uses pdnsd-ctl to override the nameserver IPs defined in /etc/pdnsd.conf with the ones received by DHCP:
    # Set the IP of "maindns" entry for pdnsd
     
    case "$reason" in
    	BOUND|INFORM|REBIND|REBOOT|RENEW|TIMEOUT|STATIC)
    		SRVS=""
    		for X in $new_domain_name_servers; do
    			if [ -z "$SRVS" ]; then
    				SRVS="$X"
    			else
    				SRVS="${SRVS},$X"
    			fi
    		done
    		pdnsd-ctl server 0 up $SRVS
    		;;
    	PREINIT|EXPIRE|FAIL|IPV4LL|NAK|NOCARRIER|RELEASE|STOP)
    		# reset to values in /etc/pdnsd.conf
    		pdnsd-ctl config
    		;;
    esac

That’s it, no big deal ;)
If you find any problems or disadvantages with this setup, feel free to post them in the comments!

Arch ramdisk-script 1.3

Mein Arch ramdisk-script hat ein weiteres Update erfahren, die Konfiguration ist nun mehr nach KISS und dot-Ordner werden korrekt behandelt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
#!/bin/sh
 
#
# Manages outsourcing of specified directories into memory on bootup and
# takes care of synchronization/backup on system shutdown.
#
# Version 1.3, 2010-03-15, by Alexander Koch
#
 
# includes
 
. /etc/rc.conf
. /etc/rc.d/functions
 
 
# configuration (syntax is: [persist. storage]:[mountpoint]:[mount options])
 
DISKS=('/home/alex/.ramdisks/_mozilla:/home/alex/.mozilla:size=100M,uid=1000,gid=100' \
	   'empty:/home/alex/.adobe:size=10M,uid=1000,gid=100' \
	   'empty:/home/alex/.macromedia:size=10M,uid=1000,gid=100')
 
 
# helper functions
 
function activate_rd() {
	[ -d "$1" ] || [ "$1" = "empty" ] || return 1
	[ -d "$2" ] || return 1
	mount | grep "$2" &>/dev/null && return 1
	MNT="mount -t tmpfs"
	[ -z "$3" ] || MNT="$MNT -o $3"
	$MNT none "$2"
	[ $? -gt 0 ] && return 1
	if [ "$1" != "empty" ]; then
		for D in $1/.* $1/*; do
			[ "$(basename "$D")" == "." ] && continue
			[ "$(basename "$D")" == ".." ] && continue
			rsync -axq "$D" "$2" &>/dev/null
			if [ $? -gt 0 ]; then
				umount "$2"
				return 1
			fi
		done
	fi
	return 0
}
 
function backup_rd() {
	mount | grep "$1" &>/dev/null || return 0
	if [ "$2" != "empty" ]; then
		for D in $1/.* $1/*; do
			[ "$(basename "$D")" == "." ] && continue
			[ "$(basename "$D")" == ".." ] && continue
			rsync -axq "$D" "$2" &>/dev/null
			if [ $? -gt 0 ]; then
				tar -cf "/root/$(basename "$2")-failed.tar" "$1"
				return 1
			fi
		done
	fi
	umount "$1" || return 1
	return 0
}
 
 
# main logic
 
case $1 in
	start)
		stat_busy "Mounting ramdisks"
		error=0
		for M in ${DISKS[@]}; do
			FROM="$(echo "$M" | cut -d ':' -f 1)"
			TO="$(echo "$M" | cut -d ':' -f 2)"
			OPTS="$(echo "$M" | cut -d ':' -f 3)"
			activate_rd "$FROM" "$TO" "$OPTS" || error=1
		done
		if [ $error -eq 0 ]; then
			add_daemon ramdisks
			stat_done
		else
			stat_fail
			exit 1
		fi
		;;
	stop)
		stat_busy "Saving ramdisks"
		error=0
		for M in ${DISKS[@]}; do
			FROM="$(echo "$M" | cut -d ':' -f 2)"
			TO="$(echo "$M" | cut -d ':' -f 1)"
			backup_rd "$FROM" "$TO" || error=1
		done
		if [ $error -eq 0 ]; then
			rm_daemon ramdisks
			stat_done
		else
			stat_fail
			echo -n "WARNING: failed to save ramdisk(s), tried to make "
			echo "backup(s) under /root."
			echo "Hit enter to proceed shutdown."
			read DUMMY
			exit 1
		fi
		;;
	restart)
		if ! ck_daemon ramdisks; then
			"$0" stop && sleep 3
		fi
		"$0" start
		;;
	*)
		echo "usage: $0 {start|stop|restart}"
		;;
esac
 
exit 0

UMTS per Handy unter Arch

Nur eine kleine Randnotiz. Mobiles Netz über UMTS per Handy ist auch unter Linux recht simpel geworden, zumindest über ein USB-Kabel, in meinem Fall getestet mit einem Sony Ericsson W890i.

Zur Vorgehensweise mit wvdial sei hier faul auf einen Artikel im Ubuntuusers.de-Wiki verwiesen ;)
umtsmon fand zwar Netze, konnte sich aber mit keinem verbinden (hat sich wohl etwas am pptp-client-Aufruf geändert).

19 Monate Arch – Was mich hält

Ein Blick auf mein pacman-log zeigt:

[2008-07-16 20:16] installed filesystem (2008.07-1)

Seit mehr als 19 Monaten residiert Arch also nun schon auf der Platte meines Notebooks. Und das, obwohl ich (entgegen meiner Einstellung zum Wechsel des Wohnortes) ein System aus reiner “Lust, mal wieder ein neues aufzusetzen” sonst nie länger als ein halbes Jahr am Stück behalten habe. Warum nun Arch? Das zeigt eine durch den regen Kontakt zu openSUSE-Maschinen und diverse Distributions-Eskapaden meiner Freundin ( ;) ) angestoßene Safari durch den mittlerweile recht dicht gewordenen Distro-Dschungel.

Am Wochenende nahm ich mir nämlich aktuelle Images sämtlicher vom Distro-Finder vorgeschlagener Distributionen (plus einiger Exoten, die mich schon länger mal interessierten) her und installierte sie testweise in einer virtuellen Maschine. Hier ein paar Eindrücke:

Debian: “Gutes, altes Debian” dachte ich mir, als ich die Seite betrat und feststellte, dass sich absolut nichts geändert hatte in den Jahren. “Oh, modernes, gutes, altes Debian” dann, als ich den nun grafischen Installer sah. “Grmpf, zu altes, gutes Debian” schließlich, als ich den fehlenden EXT4-Support realisierte. Das ist dann auch der entscheidende Nachteil: ich schätze die Stabilität des Systems auf Servern sehr, aber im privaten Bereich will ich ein Bisschen mehr bleeding-edge. EXT4 muss schon sein. Und da nicht mal das aktuelle Testing damit umgehen kann, fällt Debian leider flach für meine Zwecke.

Sidux: Viel mir ins Auge, als ich nach einem Debian-Derivat suchte, das den bei Debian vorherrschenden Staub kompensieren würde. Ubuntu kam von vornherein nicht in Frage – zu Mainstream, zu Canonical-verstickert.
Da ich kein KDE4 wollte, testete ich die XFCE-Variante. Im Grunde ein recht ordentliches System, allerdings mit recht unübersichtlichem init-output und ohne nennenswerte eigene Tools. Der Unterschied bei einem Umstieg wäre also minimal ausgefallen. Schwer zu beschreiben, was mir daran genau nicht gefiel – genauso schwer wie zu beschreiben, was mir denn gefiel. Vielleicht genau das… ;)

Fedora: Aktueller Hype bei einigen meiner ebenfalls vom Ubuntu-Hype genervten Kommilitonen. Ich hatte diverse Male das Vergnügen, die Distribution auf als Multimedia-PC gedachten Workstations zu installieren, und war vom Umgang mit proprietären Inhalten unter Fedora sehr genervt. Ich kann verstehen, dass man fragliche Codecs oder Closed-Source-Treiber nicht ohne Kommentar direkt ins System integrieren will. Aber muss es denn gleich kompliziert sein, als Endanwender bewusst an solche ranzukommen? Damals habe ich jedenfalls irgendwann den benötigten NVIDIA-Treiber manuell installiert, weshalb er jetzt auch bei jedem Kernelupgrade manuell neu gebacken werden muss. Ja, bestimmt hätte man es durch Hinzufügen irgendeines speziellen Repos irgendwie auch über die Paketverwaltung und damit “richtig” lösen können. Damals jedenfalls fand ich selbst im Wiki dazu nichts außer dem Hinweis auf die Lizenz und den Treiber von der Homepage.
Okay, mit dem neuen “nouveau”-Treiber könnte sich das erledigen und vielleicht war ich zu blind fürs Wiki, vielleicht teste ich Fedora doch mal. (Fedora gehört somit eigentlich nicht in die Liste, da nicht wirklich am Wochenende getestet.)

Zenwalk: Einer der Exoten, deren Beschreibung in der Wikipedia mir sehr viel versprechend vor kam. Schnell gefundener Haken: 32bit-only. Sorry Zenwalk, aber gemäß einem deiner eigenen Prinzipien, “optimized for specific architectures” wäre die Installation auf einem Core Duo Frevel.
Ich habe es trotzdem mal laufen lassen, um mir die Paketveraltung anzuschauen. Vielleicht finde ich noch eine passende Maschine.

Ender der Aufzählung, was bleibt? Ich schätze nach wie vor an Arch die

  • Aktualität der Pakete
  • KISS-Treue, die man überall spürt
  • Nähe zu den Sourcen, was das selbst-bauen einiger Pakete extrem vereinfacht

und das einzige, was mich derzeit wirklich stört ist das antike, nicht-nebenläufige (aber natürlich KISS-treue) Init-System, was auf meinem Notebook die Bootzeit leider in die Höhe treibt.
Tja Arch, auf die nächsten 20 Monate! :)

LVM Änderungen in Arch

Wer wie ich gerade nach einem Update die Maschine hochfährt und die Welt nicht mehr versteht, weil beim Booten (fast) keine Partition gefunden wird, hat vielleicht ein LVM-Setup und sollte seine Pfade überprüfen:

Bisher wurden Volume-Groups nämlich als Verzeichnis unter /dev angeboten, der Pfad des Volumes Vol1 auf Group1 als /dev/Group1/Vol1. Nun jedoch ist der Ordner für die VG weg und die Volumes landen in /dev/mapper, im Beispiel als /dev/mapper/Group1-Vol1.

Fröhliches fstabben ;)

based on theme by WordPress Themes