Tools 2012

Einige unsortierte Tools für Ubuntu/Debian Linux die ich nicht vergessen möchte:

  • pdfshuffler – PDFs sortieren, zusammenfügen, trennen
  • gpsprune – GPS Tracks bearbeiten. Insbesondere das komprimieren (reduzieren von Punkten) von Tracks ist hiermit für mich einfacher als mit gpsbabel
  • sqliteman – SQLite Datenbank Administrator
  • gpick – Color Picker Tool

DNS DDOS: fail2ban mit Bind

In letzter Zeit werden einige DNS Server mittels Anfragen wie die folgenden geflutet.

query: ripe.net IN ANY +ED
query: isc.org IN ANY +ED

Mittels fail2ban („apt-get install fail2ban“) kann man diese Querys recht einfach auf die schwarze Liste setzen und mit iptables blocken. Dazu muss der Named erst mal alle Querys loggen:

# /etc/bind/named.conf.local

logging {
    channel query.log {
        file "/var/log/named/query.log" versions 0 size 1m;
        severity debug 3;
        print-time yes;
    };
    category queries { query.log; };
};

Das „versions 0 size 1m“ gibt an, das Named eine Datei von 1MB Größe immer wieder überschreiben soll. Das File hätte ohne diese Anweisung schnell einige GB erreicht…

Für fail2ban habe ich hier ein quick-and-dirty script angepasst, welches auf die beiden oben genannten Domains testet (Download: named-ddos.conf). Das Rezept ist auch gut anpassbar für eigene Zwecke. Das Script „named-ddos.conf“ gehört nach „/etc/fail2ban/filters.d/“.

In der /etc/fail2ban/jail.conf muss das Rezept jetzt noch aktiviert werden:

[named-ddos-tcp]
enabled  = true
port     = domain,953
protocol = tcp
filter   = named-ddos
logpath  = /var/log/named/query.log
maxretry = 8

[named-ddos-udp]
enabled  = true
port     = domain,953
protocol = udp
filter   = named-ddos
logpath  = /var/log/named/query.log
maxretry = 8

Nach einem restart von fail2ban sollte /var/log/fail2ban.log anzeigen, dass IPs gebannt werden:

2012-08-02 22:56:44,886 fail2ban.actions: WARNING [named-ddos-udp] Ban 63.166.xxx.xxx
2012-08-02 22:56:44,903 fail2ban.actions: WARNING [named-ddos-udp] Ban 216.9.xxx.xxx

Wenn alles funktioniert würde ich den loglevel in der /etc/fail2ban/fail2ban.conf auf „1“ setzen damit das logfile nicht überläuft.

Nutzung auf eigene Gefahr ;-) Man sollte sich dessen bewusst sein, dass u.U. auch „legale“ User ausgesperrt werden könnten und bei Bedarf die Schwellwerte anpassen.

Ubuntu: CDROM als APT Repository

Um mal schnell die Ubuntu CD im Laufwerk als APT-Repository hinzuzufügen, hilft folgendes Kommando:

sudo apt-cdrom add

Mir passiert es z.B. öfter, dass ich vergesse bei der Installation das Paket „vlan“ mit zu installieren und stehe dann ohne Netzwerk da…

PHP5.3: log mail() usage

Es geschehen noch Wunder. Ein ur-alter Patch, der PHP das Loggen der „mail()“ Funktion beibringt hat es in den Core geschafft – und ich habe es nicht gemerkt ;).

Damit wird es auf Shared-Hosting Systemen endlich (ohne Klimmzüge) möglich, spammende Formulare etc. zu identifizieren…

So wird es aktiviert:

# /etc/php.ini
 
mail.add_x_header = On              # Fügt einen neuen Mailheader hinzu:
                                    # X-PHP-Originating-Script: <uid>:formmail.php
 
mail.log = /var/log/phpmail.log     # Loggt jede Benutzung der mail() Funktion

Das Log sieht dann so aus:

mail() on [/var/www/formmail.php:3]: To: otto@example.org -- Headers:

many THANKS!

LVM: Found duplicate PV

Nachträglich ein DRBD Laufwerk eingerichtet. Vorher war auch schon ein LVM im System aktiv. Nach dem Einzug des DRBD-Layers meckerte LVM merkwürdigerweise immer mehrere Physical Volumes mit der selben ID an:

Found duplicate PV sX26QEl0aPdVRr1uMA8VhR7PpTIJ0Xu0: using /dev/sdb1 not /dev/drbd0
Found duplicate PV sX26QEl0aPdVRr1uMA8VhR7PpTIJ0Xu0: using /dev/sdc1 not /dev/sdb1

In der lvm.conf war der Filter korrekt gesetzt (damit nur das drbd Laufwerk nach PVs durchsucht wird), auch „write_cache_state“ hatte ich disabled.

#/etc/lvm/lvm.conf
filter = [ "a|/dev/drbd|", "r/.*/" ]
write_cache_state = 0

Trotzdem kam mir immer wieder das alte PV ins Gehege. pvscan, reboot etc. nützte nichts… Letzendlich war der Grund der Cache vom LVM. Also die Cache-Datei gelöscht:

rm /etc/lvm/cache/.cache

Danach pvscan, vgscan etc. und alles war wieder gut.

Meine Vermutung zum Grund der ganzen Aktion ist, dass ich die lvm.conf Einstellungen erst geändert hatte nachdem ich das DRBD und ein neues LVM aktiviert hatte. Wenn die Einstellung „write_cache_state“ dann deaktiviert wird, wird der Cache auch nicht mehr aktualisiert, wird aber dennoch verwendet! Wie gesagt: Vermutung.

dd Fortschritt/progress anzeigen

Mal wieder ein dd angeschmissen und es dauert Stunden? Vergessen das dd durch eine Statistik-Pipe zu schicken?

dd ist empfänglich für das Signal „SIGUSR1“ welches dd veranlasst zwischendurch seinen Status auszugeben. Also zunächst gilt es die pid des dd Prozesses herauszufinden und dann das Signal zu senden. Oder einfach wie hier „killall“ zu verwenden:

killall -SIGUSR1 dd     # sendet das Signal an alle dd Prozesse

Das Terminal mit dem laufenden dd Kommando gibt dann brav seinen Status aus:

1476369209+0 records in
1476369209+0 records out
755901035008 bytes (756 GB) copied, 30066.9 s, 25.1 MB/s

DRBD: Split-Brain recovery

Notiz zum DRBD Split-Brain recovery im primary/primary setup. Nutzung auf eigene Gefahr!

Auf dem nicht aktuellen Node ausführen:

vgchange -a n vmdata                     # lvm herunterfahren (falls vorhanden)
drbdadm secondary r0                     # zu secondary deklarieren
 
drbdadm -- --discard-my-data connect r0  # eigene Daten ignorieren und zum
                                         # anderen Node verbinden (resync startet)
 
drbdadm primary r0                       # wieder zum primary machen
 
cat /proc/drbd                           # status überprüfen
...
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:80464 dw:80456 dr:2248 al:0 bm:89 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Hier steht es auch nochmal offiziell.

Ubuntu: KeePass & mono

Folgende mono-Librarys müssen nachinstalliert werden damit KeePass mit mono unter Ubuntu läuft:

sudo apt-get install \
libmono-system-runtime2.0-cil \
libmono-winforms2.0-cil

mdadm: Device or resource busy

Beim Hinzufügen einer neuen Partition zu einem RAID kam vorhin folgende Meldung:

mdadm --add /dev/md0 /dev/sda1
mdadm: Cannot open /dev/sda1: Device or resource busy

Gemounted war die Partition nicht – was ich jedoch nicht beachtet hatte war, dass der device-mapper sich die Platte beim booten geschnappt hatte:

dmsetup ls
ddf1_System	(253, 0)
ddf1_Systemp2	(253, 2)
ddf1_Systemp1	(253, 1)

D.h. ich musste die Platte noch aus der device-mapper Verwaltung herausnehmen:

# Entfernt alle (!!!) Platten aus der Verwaltung des device-mapper
dmsetup remove_all

Danach klappt auch das hinzufügen mit mdadm wieder:

mdadm -a /dev/md0 /dev/sda1
mdadm: added /dev/sda1