Erfahrungsbericht: BackTrack Linux Aufkleber fürs Rack

Woher nimmt man in Deutschland in Wunschgröße und -farbe produzierte strapazierfähige BackTrack Aufkleber? Von einem kleinen Autoaufkleber Shop.

BackTrack Aufkleber auf Serverschrank

Im Netzwerklabor an der IRB läuft BackTrack Linux, auf meiner privaten Hardware läuft BackTrack Linux und ein großer Teil meiner Arbeit liegt im gleichen Gravitationsfeld. Aufkleber für Laptops und T-Shirts gibt es bereits von Trixgraphix, aber eben nicht in vielen Farben und nicht in jeder Größe.

Der Hersteller Cardekotec hat sich sehr kooperativ gezeigt und ermöglicht jetzt auch die Bestellung von BackTrack Drachen in fast beliebiger Größe und Farbe.

Bestellung

Nach kurzem E-Mail Kontakt konnte Cardekotec den Drachen anbieten, in jeder der Farben und Folienarten. Die verschiedenen möglichen Farben (immerhin 30 verschiedene) sind zu diesem Drachen identisch. Bestellt habe ich den BackTrack Drachen in schwarz-matt und einer Breite von 60 Zentimetern zu einem Preis von 16,00 Euro plus Versandkosten von 5,90 Euro und einem Verklebeset (das aber nicht nötig ist). Nach zwei Tagen war der Aufkleber in einer großen Umverpackung hier. Im Paket war eine Rolle, auf die der Aufkleber gespannt war.

Verarbeitung

Was man beachten sollte ist, dass es sich bei den Aufklebern von Cardekotec um Autoaufkleber handelt. Autoaufkleber sind strapazierfähiger als normale Aufkleber. Also nicht einfach Aufkleber von Trägerfolie nehmen und aufkleben, gerade nicht bei größeren Aufklebern. Der Aufkleber befindet sich zwischen einer Trägerfolie und einer Transferfolie. Das verkleben ist aber denkbar einfach.

  1. Klebestelle reinigen
  2. Aufkleber anhalten und (zum Beispiel mit Panzertape) spätere Position markieren
  3. Trägerfolie entfernen
  4. Von einer Ecke zur entgegengesetzten langsam den Aufkleber auf die Klebestelle aufbringen
  5. Mit einem ebenen Gegenstand anmassieren
  6. Luftlöcher vorsichtigst aufstechen

Jetzt 20-30 Minuten warten und dann die Transferfolie in einem 180 Grad Winkel vorsichtig entfernen.

Fazit

Mein Serverschrank wird von einem BackTrack Drachen geziert und das ohne große Probleme beim Aufkleben gehabt zu haben. Der Preis von 16 Euro plus Versand geht in Ordnung und das Team von Cardekotec hat sich bereit erklärt jederzeit auf Anfrage per E-Mail weitere BackTrack Aufkleber anzufertigen. Ob man dort weiss, was BackTrack Linux ist?

Mailscanner running with -T switch und Lock.pm

Wird das Debian Squeeze MailScanner Paket mit postfix eingesetzt, tut sich erstmal nichts.

Problem

root@outpost:~# MailScanner --debug
# [...] Gekürzt [...]
Insecure dependency in open while running with -T switch at /usr/share/MailScanner//MailScanner/Lock.pm line 358.

Das Ergebnis ist, dass MailScanner nicht startet. Schaut man sich die an Zeile 347 beginnende Funktion openlock() an, wird schnell klar, worum es geht: File Locking. Und der Fehler ist eigentlich keiner, sondern ein Feature. Leider ein Feature von perl, dass in MailScanner nicht vollständig umgesetzt wird. Einige Module von MailScanner werden im Perl Taint Mode ausgeführt, bei dem keiner Eingabe vertraut wird.

Dabei muss jede Eingabe vom Programmierer als zulässig bestätigt werden, was für die Postfix Anbindung anscheinend noch nicht geschehen ist. Der Thread auf der MailScanner Mailinglist zu diesem Thema (einer von vielen) bestätigt das.

Workaround

Man verändert das Hauptskript unter /usr/sbin/MailScanner und ergänzt am Ende des Shebang ein großes -U. Damit wird Eingaben wieder vertraut.

#!/usr/bin/perl -I/usr/share/MailScanner/ -U

Transmission auto-delete Quota Skript

Möchte man immer die aktuellsten frei zugänglichen Linux-Distributions Torrents herunterladen, um andere Nutzer durch die eigene Bandbreite zu unterstützen, wird irgendwann die Festplatte voll. Dieses Skript schafft Abhilfe.

#!/bin/bash
# transmission-quota.bash
#
# FIFO quota for transmission-daemon.
# This script forces a maximum size upon
# your transmission download directory
# by deleting the oldest torrent, until
# the quota is met again.
#
# Run regularily from cron:
# */5 * * * *     /home/torrent/transmission-quota.bash
#

# Where is your transmission download directory?
TR_DIR="/path/to/your/transmission/downloads"

# How big in bytes may the download directory grow?
TR_MAXBYTES=1879048192000

# Wheres your transmission-remote binary?
CLIPATH="/usr/bin/transmission-remote"

# Login:Password, if applicable
TR_UPASS="myUsername:myPassword"

# URL to Transmission RPC Interface (usually http://X:9091/transmission/rpc)
TR_URL="http://localhost:9091/transmission/rpc"

# # # No Configuration needed below here # # #

while [ "`du -sb ${TR_DIR} | awk '{print $1}'`" -gt "${TR_MAXBYTES}" ]; do
        CURRENT_SEEDING=`${CLIPATH} ${TR_URL} -n ${TR_UPASS} -l | awk '{ if ($2 == "100%") print $1 }' | sed 's/*$//'`
        OLDEST_TIMESTAMP=`date +%s`

        for torrent in ${CURRENT_SEEDING}
        do
                DATE_ADDED=`${CLIPATH} ${TR_URL} -n ${TR_UPASS} -t ${torrent} -i |grep "Date added:" | sed 's/Date added://g'`
                TIMESTAMP_ADDED=`date --date "${DATE_ADDED}" +%s`
                if [ "${TIMESTAMP_ADDED}" -lt "${OLDEST_TIMESTAMP}" ]; then
                        OLDEST_TIMESTAMP=${TIMESTAMP_ADDED}
                        OLDEST_ID=${torrent}
                fi
        done
        ${CLIPATH} ${TR_URL} -n ${TR_UPASS} -t ${OLDEST_ID} --remove-and-delete &> /dev/null
        DAYS_AGO=`echo $(( ( $(date +%s) - $OLDEST_TIMESTAMP ) / 3600 / 24 ))`
        echo deleted torrent id ${OLDEST_ID} from ${DAYS_AGO} days ago | logger -t transmission-quota
done

Gentoo per Rescue System installieren Quick’n’Dirty

Manchmal braucht man einfach nicht den unzerstörbaren Panzer (hier seit neun Jahren Debian GNU/Linux), sondern den getunten und tiefergelegten Lowrider mit Neonbeleuchtung. Oder kurz: Zum wiederholten mal hat mir mein Arbeitskollege im Labor Gentoo Linux empfohlen. Durch Zufall wurde ich auch noch zu einem Alpha-Test des neuen OVH Rechenzentrums in den USA eingeladen und habe jetzt einen Server übrig. Zeit Vorurteile durch Spaß am Gerät auszuräumen. Probefahrt mit Gentoo.

21:50 Uhr, das Rescue System ist gestartet. Dass das Motto des Abends nicht „Einklick-Installation“, sondern eher „Du bist der Installer!“ lautet, war mir klar. Sicher eine gute Möglichkeit das eigene Linux foo auf den Prüfstand zu stellen.

1. Alte Partitionstabelle löschen

dd if=/dev/zero of=/dev/sda bs=512 count=1

Oder direkt im Rescue System mittels cfdisk -z /dev/sda mit einer neuen leeren Partitionstabelle beginnen.

2. Partitionen anlegen und Dateisysteme erstellen

So vorhanden mittels cfdisk oder fdisk die notwendigen Partitionen anlegen. Wer Gentoo zum ersten mal installiert, sollte sich auf eine /boot, eine / (beide Partitionstyp 83) und eine kleine Auslagerungspartition (Partitionstyp 82) beschränken.

Danach geht es auch schon ans erste formatieren der Partitionen mit entsprechenden Dateisystemen. Hier kann (scheinbar typisch für Gentoo) frei zwischen allen verfügbaren mkfs Befehlen gewählt werden.

3. Partitionen strukturiert einhängen

mkdir -p /mnt/gentoo
mount /dev/sda3 /mnt/gentoo # Das Wurzeldateisystem
mkdir /mnt/gentoo/boot # Verzeichnis für die Boot-Partition
mount /dev/sda1 /mnt/gentoo/boot
swapon /dev/sda1

4. Stage3 Gentoo Image herunterladen und installieren

cd /mnt/gentoo
wget http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/stage3-amd64-20120329.tar.bz2
tar xvjpf stage3-*.tar.bz2

Jetzt fehlt noch ein aktueller Portage Snapshot, in dem die aktuell verfügbaren Pakete vermerkt sind. Es empfiehlt sich statt dem folgenden Link den aktuellsten Snapshot von dieser Adresse herunterzuladen, falls im Rescue System ein Fehler angezeigt wird. Oft weist das auf eine alte/unvollständige wget Version hin.

wget http://ftp.halifax.rwth-aachen.de/gentoo/releases/snapshots/current/portage-latest.tar.bz2
tar xjpf portage-latest.tar.bz2

5. Chroot für Installation vorbereiten

cp /etc/resolv.conf etc/resolv.conf
mount -t proc none /mnt/gentoo/proc
mount -o bind /dev /mnt/gentoo/dev
chroot /mnt/gentoo /bin/bash
env-update
source /etc/profile # Weil wir keine Login-Shell gestartet haben, einmal die profile manuell einlesen

6. Locales und Zeitzone konfigurieren

Der Einfachheit halber, werden jetzt nur die drei wichtigsten locales erzeugt. Dafür werden in der Datei /etc/locale.gen folgende Zeilen einkommentiert (Raute entfernen): en_US ISO-8859-1, en_US.UTF-8 UTF-8, de_DE@euro ISO-8859-15. Danach werden die locales erzeugt.

locale-gen -A -j2

Danach braucht es nur noch eine Zeitzone für den neuen Server.

cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

7. Portage aktualisieren

Zuerst aktualisieren wir den Portage Baum noch einmal, da zwischen dem Snapshot und dem aktuellen Datum Aktualisierungen stattgefunden haben können. Hier wird wieder deutlich, dass Gentoo ein Rolling Release ist, bei dem es sich lohnt, immer auf dem aktuellen Stand zu sein.

emerge --sync # Dauert einige Minuten

8. Kernel kompilieren und installieren

emerge gentoo-sources
cd /usr/src/linux # 
make menuconfig

Da es zuerst darum geht, schnell einen bootfähigen Server zur Verfügung zu haben, muss nur das Dateisystem der /boot Partition fest in den Kernel einkompiliert werden. Da das Dateisystem (hier XFS) für die Wurzelpartition aber sowieso geladen werden muss, wird es auch direkt einkompiliert. Danach können der Kernel und die Module kompiliert werden.

make && make modules_install
make install

Damit ist der Kernel in /boot installiert. Jetzt brauchen wir den exakten Pfad zum Kernel, um gleich den Bootmanager konfigurieren zu können.

ls /boot/vmlinuz-* # Hier: /boot/vmlinuz-3.2.12-gentoo

9. Bootmanager kompilieren und installieren

emerge grub
cd /boot/grub
nano menu.lst

Hier muss der eben kompilierte Kernel eingetragen werden und die / Partition als Paramter übergeben werden. Für das Beispiel sieht es so aus:

default 0
timeout 1 

title Gentoo
root (hd0,0)
kernel /boot/vmlinuz-3.2.12-gentoo root=/dev/sda3                                    

Jetzt wird der Bootmanager im Master-Boot-Record der Festplatte installiert. Aber da die Installation in einem chroot stattfindet, muss zuerst die Tabelle der eingebundenen Dateisysteme erzeugt werden.

grep -v rootfs /proc/mounts > /etc/mtab
grub-install --no-floppy /dev/sda

10. Netzwerk

Der vorletzte Schritt bei der Installation besteht darin, das Netzerkinterface zu konfigurieren. Dafür werden die Daten mit denen das Rescue System gestartet wurde übernommen.

ifconfig #IP des Servers abrufen
route -n # Default Gateway abrufen
nano /etc/conf.d/net
config_eth0="ServerIP netmask 255.255.255.0 brd SubnetzBroadcast"
routes_eth0="default via SubnetzGateway"

Jetzt muss das Interface noch in das OpenRC Startsystems eingebunden werden und auch dieser Schritt ist abgeschlossen.

cd /etc/init.d
ln -s net.lo net.eth0
rc-update add net.eth0 default

11. Abschluss der Installation

Bevor der neu installierte Server gestartet werden kann, sollte eine Möglichkeit geschaffen werden, um entfernt darauf zugreifen zu können. Dafür empfiehlt sich OpenSSH.

emerge openssh
rc-update add sshd default

Damit nicht auch noch ein Systembenutzer angelegt werden muss, wird temporär das Anmelden mit dem root Benutzerzugang erlaubt. Dafür folgende Änderung in der Datei /etc/ssh/sshd_config durchführen.

PermitRootLogin yes # diese Zeile einkommentieren (# entfernen)

Die letzten zwei Aufgaben vor dem wohlverdienten reboot bestehen im setzen des root Passworts und dem schreiben einer sinnvollen /etc/fstab Datei, damit der neue Server die notwendigen Partitionen auch einbindet.

passwd root
nano /etc/fstab

Hier eine am Beispiel Server orientierte /etc/fstab:

/dev/sda1               /boot           ext4            noauto,noatime  1 2
/dev/sda3               /               xfs             noatime         0 1
/dev/sda2               none            swap            sw              0 0

Wenn die Wurzelpartition mit XFS formatiert wurde, wird noch ein letztes Softwarepaket benötigt: emerge xfsprogs.

12. Reboot!

Fazit

Um 23:45 Uhr hatte ich meine erste bash unter Gentoo per ssh im Terminal. Die Installation war zwar gewöhnungsbedürftig, weil nicht so automatisiert, wie bei Debian oder gar Ubuntu, aber hat schon andeutungsweise die Freiheiten von Gentoo gezeigt. Trotzdem kommt das System für mich nicht in Frage, zumindest vorerst nicht für den produktiven Einsatz. Grund ist, dass man durch die Kompilationszeiten (Kernel hier: 40 Minuten, Grub: 15 Minuten) aus der Konzentration gerissen wird und sich zwangsweise mit etwas anderem beschäftigen muss.

Das „g“ Logo ist ein eingetragenes Warenzeichen der Gentoo Foundation, Inc

SNMP mit Munin

Wer im SoHo-Bereich bisher Munin für das Netzwerk Monitoring eingesetzt hat, kann beim neuen Switch oder AccessPoint eine böse Überraschung erleben. Ohne munin-node kein Monitoring. Dabei unterstützt Munin SNMP fähige Geräte sehr elegant; wenn man ein paar Vorraussetzungen beachtet.

SNMP wird in Munin eingebunden, indem ein munin-node die SNMP-Informationen zur Verfügung stellt. Auf dem gewählten Host (bestenfalls ein Linux System), kann Munin die unterstützten Plugins des SNMP fähigen Geräts selbst finden. Hier am Beispiel eines Netgear GS716T (sehr einfacher WebSmart Switch) mit dem Hostnamen coreswitch.

1. Unterstützte Plugins aktivieren

munin-node-configure --snmp coreswitch --snmpversion 2c --snmpcommunity meineROsnmpCOMMUNITY --suggest --shell

Die manpage von munin-node-configure verrät, dass hier auch die SNMP Versionen 1 und 3 unterstützt werden. Der Befehl liefert auf Basis der SNMP MIB des Switches direkt Shellbefehle, die alle unterstützten Interface- und Informations-Plugins in die laufende Munin Konfiguration einbinden. Sehr komfortabel.

2. Neues Gerät in munin.conf eintragen

Hier ist der erste Fallstrick versteckt. Munin erwartet, dass der Node-Name in der Konfigurationsdatei exakt dem Hostnamen entspricht (in diesem Fall coreswitch). Wählt man einen eigenen Namen, kommt es bereits zu Problemen.

[coreswitch]
    address 127.0.0.1
    use_node_name no

3. SNMP Community und Version in /etc/munin/plugin-conf.d/munin-node festlegen

Hier gibt es zu beachten, dass mit dem regulären Ausdruck in eckigen Klammern (hier snmp_coreswitch*), alle Plugins die für den Switch im ersten Schritt aktiviert wurden, abgedeckt sein müssen. Im Zweifelsfall lässt sich das mit ls /etc/munin/plugins/snmp_coreswitch* nocheinmal prüfen.

# added by hand
[snmp_coreswitch*]
env.community meineROsnmpCOMMUNITY
env.version 2

Nach fünf Minuten sind die ersten Graphen des neuen SNMP Geräts erstellt. Weitere Informationen zur SNMP Einbindung in Munin finden sich im Wiki des Projekts.

Wer unbedingt einen anderen Node-Namen in der Datei munin.conf (und damit im Webinterface) benutzen möchte, kann das, indem in der Datei /etc/munin/plugin-conf.d/munin-node unter der SNMP Community mittels env.host die IP-Adresse oder Hostname des SNMP Geräts angegeben wird.