Schlagwort-Archiv: debian

LAN vor WLAN im NetworkManager

Mein Arbeitsnotebook ist aus Performancegründen meistens per Kabel am Netzwerk angeschlossen, für die Mobilität im Büro besteht zusätzlich eine WLAN-Verbindung zum selben Netzwerk. Beide Verbindungen werden vom NetworkManager verwaltet, allerdings kann man hier keine Priorisierung einstellen, was zu folgender Routing-Tabelle führt:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 wlan0
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U     0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth0

Die Metric steht bei beiden Interfaces auf 0, weshalb nicht eindeutig festgelegt ist, wo der Traffic nun rausgeht. Das System nimmt die erste Route, die in diesem Falle über das WLAN läuft.

Um dieses Problem zu umgehen, habe ich ein NetworkManager-Script gebastelt. Dies muss im Verzeichnis /etc/NetworkManager/dispatcher.d/ liegen und für root ausführbar sein.

#!/bin/sh
 
#wireless-metric.sh - NetworkManager script
#sets a higher metric for wireless connections to prioritize a wired connection
 
#metric that will be used for the wireless connection
METRIC=100
 
#check input parameters
if [ -z "$1" -o -z "$2" ]; then
  echo "This script is meant to be run by the NetworkManager";
  echo "Syntax: $0 <device> <up/down>"
  exit 1
fi
device=$1
updown=$2
 
#exit if the current connection isn't a wireless one
iwconfig $device > /dev/null
if [ $? -eq 161 ]; then
  exit
fi
 
#get default route and local network address
defaultgw=`ip route|grep default.*$device|awk '{print $3}'`
localnet=`ip route|grep $device|grep -v default|head -n1|awk '{print $1}'`
 
#delete the routes for the device and add new ones with the higher metric
if [ "$updown" = "up" ]; then
  route del -net $localnet dev $device
  route add -net $localnet dev $device metric $METRIC
  route del -net 0.0.0.0/0 gw $defaultgw dev $device
  route add -net 0.0.0.0/0 gw $defaultgw dev $device metric $METRIC
fi

Nachdem ich die WLAN-Verbindung getrennt und wieder aufgebaut habe, finde ich nun eine eindeutige Routingtabelle vor:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    100    0        0 wlan0
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U     100    0        0 wlan0
10.0.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth0

Das Script wurde getestet unter Debian 7.1 wheezy AMD64 mit NetworkManager Version 0.9.4.0-10.

Debian-Paketlisten sichern und wiederherstellen

Für den Umzug auf neue Hardware möchte ich meine installierten Pakete auch auf dem neuen System installieren. Dazu sichere ich die Paketlisten mit dpkg. Dabei geht allerdings die Information verloren, ob ein Paket manuell oder aufgrund von Abhängigkeiten automatisch installiert wurde. Mit apt-mark lässt sich diese Information ebenfalls speichern.

Paketliste sichern:

dpkg --get-selections > packages.list
apt-mark showauto > packages_auto.lst
apt-mark showmanual > packages_manual.lst

Paketliste wiederherstellen:

dpkg --set-selections < packages.list
apt-get -u dselect-upgrade
apt-mark auto `cat packages_auto.lst`
apt-mark manual `cat packages_manual.lst`

ARP-Cache unter Linux vergrößern

Die Ursachen von Verbindungsabbrüchen in einem größeren LAN zu finden ist schwierig, in meinem Fall war die ARP-Tabelle des Routers voll. Auf Debian-Systemen ist sie standardmäßig auf 1024 Einträge begrenzt. Ist der Adressraum des Netzwerks größer, könnte jemand allein durch einen Ping-Scan die ARP-Tabelle des Routers füllen. Wenn das passiert, ist im Kernel-Log folgende Meldung zu lesen.

Dec 16 09:08:19 router kernel: [14468939.388404] Neighbour table overflow.
Die Begrenzung lässt sich mit folgenden Befehlen festlegen - ersteres ist das Hardlimit, das andere das Softlimit.

echo 65536 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
echo 32768 > /proc/sys/net/ipv4/neigh/default/gc_thresh2

Um die Optionen dauerhaft zu speichern, sollten sie in die sysctl.conf eingetragen werden.

net.ipv4.neigh.default.gc_thresh2=32768
net.ipv4.neigh.default.gc_thresh3=65536

Debian »Lenny« released

Kurzinfo für alle, die es im Liebestaumel des Valentinstages verpasst haben: Debian 5.0 aka Lenny wurde released und ist damit die aktuelle stable Version.

Die Vorgängerversion Etch ist damit in den Status oldstable gerutscht und sollte innerhalb dieses Jahres ersetzt werden.

Auf einem Entwicklungsserver kam es beim Dist-Upgrade auf Lenny zu keinen bemerkenswerten Problemen. Selbst der Wechsel auf Python 2.5 gelang problemlos (einzige Ausnahme: Teamsoftware trac mit Sqlite-Backend).

Da die Paketquellen automatisch umgestellt werden, sollten Update-Unwillige die sources.list von apt checken.

UPDATE: Auch adminlife.net berichtet natürlich über den Release und hat ein paar interessante Links zusammengestellt, u.a. auch die Liste, die ich zu faul war anzulegen: Alle nennenswerten Änderungen von Etch zu Lenny – nachzulesen in mika’s blog.

Link: Debian »Lenny« Release-Information

Kurztipp: usermod und die zusätzlichen Gruppen

Gerade stellte sich mir das Problem: Ein Script soll beim Anlegen eines Users und einer Gruppe den Web-User (www-data) der neuen Gruppe hinzufügen. Das funktionierte auch wie gewünscht:

usermod -G user123 www-data

Das Problem: Der Benutzer www-data ist nun zwar Mitglied der Gruppe user123, hat allerdings in allen anderen Gruppen “vergessen”, dass er dazu auch gehören sollte. Das sollte natürlich nicht passieren, denn der Aufruf soll ja nur ergänzend und nicht ersetzend sein. Ein Blick in die Manpage zeigt die einfache Lösung, die ich leider bisher übersah:

usermod -G user123 -a www-data

Der Parameter -a hängt die neue Gruppe an die bisherigen an und erhält damit die Gruppenzugehörigkeiten.

Debian user, checkt eure sources.list!

Debian Lenny soll aller Voraussicht am nächsten Wochenende (14. Februar 2009) vom Status testing in stable gehoben werden. Die derzeit aktuelle Version Debian Etch wird damit in den Status  oldstable wechseln.

Mit dieser Veränderungen ist auch eine Änderung der Paketbasis verbunden. Wer nämlich in der Paketverwaltung APT (Tools apt bzw. aptitude) einfach nur auf den stable-Zweig verweist, wird ab der Statusänderung plötzlich statt mit Etch-Paketen mit Lenny-Paketen versorgt.Dies führt dazu, dass nahezu alle installierten Pakete veraltet sein werden und nach einem Upgrade schreien.

Weiterlesen

Private Shell-Kommando Hitliste

Wo alle am Jahresende gerade so in Bilanz-Stimmung waren, lief mir etwas interessantes über den Weg: Ein Einzeiler, der aus der bash-history ein Best-of extrahiert. Und das geht so:

	history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}' | sort -rn | head

Meine Top 10 aus der aktuellen bash:

52 l
50 htpasswd
50 cd
35 tail
29 exit
28 mc
27 /etc/init.d/apache2
19 grep
18 chown
16 rm

via: http://www.marianoiglesias.com.ar: My top 10 commands for July, 2008

Hardware-Tools: (Ich will) wissen, was in dir steckt…

Als Sysadmin hat man so einige -vermeintlich einfache- Probleme, die dann im Detail doch etwas Verrenkungen bedeuten, um sie zu lösen.

Heute galt es herauszufinden, warum die Test-Installation von Open-Xchange nicht laufen will. Ein Blick ins Log ergab, dass der Prozess 256MB Ram anforderte – etwas zuviel für den Testserver mit 256MB abzüglich einer Onboard-Grafikkarte (also 240MB effektiv).

Nun zum nächsten Problem: Wie bekomme ich heraus unter Debian-Linux in der Konsole heraus, welche Art Speicher in welcher Verteilung verbaut ist, ohne den Server auszuschalten und zu öffnen?

Weiterlesen

apticron+apt-listbugs: Nie mehr ein Update verpassen

Der geplagte Sysadmin hat den ganzen Tag soviel zu tun – eines davon ist, die ausstehenden Patches im Auge zu behalten. Üblicherweise werden dazu RSS-Feeds und Mailinglisten abonniert und im Falle von Debian regelmäßig

aptitude update && aptitude dist-upgrade

ausgeführt, um nach Aktualisierungen der Debian-Pakete zu suchen.

Was für selbst compilierte Software nicht so richtig geht, ist für die Debian-Pakete möglich: Die Automatisierung des Checks.

Es gibt einige Admins, denen der manuelle Updatevorgang auch noch zu müselig ist und die das Update (mit Parametern) ebenfalls via cron erledigen. Ich bin allerdings der Meinung, dass dies zu “gefährlich” ist, da es in manchen Fällen vorkommt, dass die geupdateten Dienste nicht mehr starten oder andere Fehler produzieren. Ein waches wachsames Auge des Sysadadmins kann da schon helfen.

Also suchte ich nach einer Möglichkeit zeitnah über neue Pakete und deren Bugfixes informiert zu werden und fand sie:

apticron informiert via Mail, sobald neue Pakete zur Verfügung stehen. Im Zusammenspiel mit dem Perl-Skript apt-listbugs sieht man in der Infomail (und auch bei jedem manuellem Updatevorgang) auch gleich, welche Bugs gefixt wurden und kann so nach Wichtigkeit das Update planen.

So sieht eine Beispielmail dann im Ergebnis aus:


apticron report [Sat, 01 Dec 2007 06:35:14 +0100]
========================================================================

apticron has detected that some packages need upgrading on: 

	fqdn.tld
	[ 123.123.123.123 ]

The following packages are currently pending an upgrade:

	libmysqlclient15off 5.0.32-7etch3
	mysql-client-5.0 5.0.32-7etch3
	mysql-common 5.0.32-7etch3
	mysql-server-5.0 5.0.32-7etch3

========================================================================

Package Details:
Lese Changelogs...
--- Änderungen für mysql-dfsg-5.0 (libmysqlclient15off mysql-client-5.0 mysql-common mysql-server-5.0) ---
mysql-dfsg-5.0 (5.0.32-7etch3) stable-security; urgency=high

  * SECURITY:
    Fix for CVE-2007-5925: The convert_search_mode_to_innobase function in
    ha_innodb.cc in the InnoDB engine in MySQL 5.1.23-BK and earlier allows
    remote authenticated users to cause a denial of service (database crash)
    via a certain CONTAINS operation on an indexed column, which triggers an
    assertion error. (closes: #451235)

 -- Norbert Tretkowski <nobse@debian.org>  Thu, 15 Nov 2007 18:51:30 +0100

mysql-dfsg-5.0 (5.0.32-7etch2) stable-security; urgency=high

  * Security release prepared for the security team by the Debian MySQL
    maintainers. The patches were mostly taken from the Ubuntu project.
  * CVE-2007-2583: The in_decimal::set function in item_cmpfunc.cc in MySQL
    allowed context-dependent attackers to cause a denial of service (crash)
    via a crafted IF clause that results in a divide-by-zero error and a NULL
    pointer dereference. Closes: #426353
  * CVE-2007-2691: MySQL did not require the DROP privilege for RENAME
    TABLE statements, which allows remote authenticated users to rename
    arbitrary tables. Closes: #424778
  * CVE-2007-2692: The mysql_change_db function in MySQL did not restore
    THD::db_access privileges when returning from SQL SECURITY INVOKER
    stored routines, which allowed remote authenticated users to gain
    privileges. Closes: #424778
  * CVE-2007-3780: It was discovered that MySQL could be made to overflow
    a signed char during authentication. Remote attackers could use crafted
    authentication requests to cause a denial of service.
  * CVE-2007-3782: Phil Anderton discovered that MySQL did not properly
    verify access privileges when accessing external tables. As a result,
    authenticated users could exploit this to obtain UPDATE privileges to
    external tables.

 -- Christian Hammers <ch@debian.org>  Tue,  6 Dec 2007 21:54:01 +0100

========================================================================

You can perform the upgrade by issuing the command:

	aptitude dist-upgrade

as root on fqdn.tld

It is recommended that you simulate the upgrade first to confirm that
the actions that would be taken are reasonable. The upgrade may be
simulated by issuing the command:

	aptitude -s -y dist-upgrade
--  apticron

Zu installieren sind beide Tools ganz leicht über aptitude.

Bugs, bugs, bugs

Hier nur ein paar aktuelle Nachrichten zu – teils krassen – Sicherheitsproblemen kurz notiert:

Die Bugs sind bereits alle gefixt, die Updates sollten schnellstens eingespielt werden.

Offen ist noch dieser, zumindestens gibt es noch kein neues Debian-Paket:

Aber nicht nur wir müssen unsere Hausaufgaben machen:

Schon wieder ein neuer Etch-Kernel

Kommt mir das nur so vor oder ist die Häufigkeit der Kernel-Updates gerade etwas höher?!

Laut Log habe ich gerade am 25.08.2007 den Kernel aktualisiert (ja, mit etwas Verzögerung), aber nun schon wieder? Und wenn ich mir so ansehe, was so gefixt wurde, treibt mich auch gerade nicht so die Eile, denn nichts davon betrifft eines meiner Systeme direkt.

Nichts destotrotz möchte/muss/sollte man ja synchron mit Debian-Paketen bleiben und daher werde ich Upgrades demnächst durchführen.

Hier die Fixes @ Debian-Security — DSA-1363-1 linux-2.6

ftplicity: inkrementelle Backups sicher ablegen

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:

Vorteile

In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.

Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:

  • Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.

    Lösung: kleine Dateien übertragen durch Erstellung von Volumes

  • Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.

    Lösung: Verschlüsselung der Daten mittels GPG

  • Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).

    Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.

  • Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.

    Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek

Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:

Weitere Vorteile

  • Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.

    Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann

  • Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.

    Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.

So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. Weiterlesen