Total Verfriemelt

Ich bastele mir gerade ein NAS zusammen und habe mich für ein Mini-ITX Atom D510 Board mit NM10 Chipsatz und einer onBoard Realtek 8168 NIC entschieden. Wichtig für ein NAS ist, dass es Netzwerk kann Tja nur doof, dass unter den meisten Distributionen der r8168 als r8169 erkannt und dementsprechend auch das falsche Modul geladen wird.

[root@nas ~]# lspci
00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

[root@nas ~]# lsmod | grep r81
Module                  Size  Used by
r8169                  37573  0
mii                     9409  1 r8169

Mit zuverlässigem Netzwerk ist da oft nicht viel, wenn man überhaupt einen “Link Up” bekommt. Hier muss man selbst Hand anlegen und sich erstmal den Treiber von Realtek besorgen.

Dieses Paket dann per USB Stick oder sonstwie auf das System wuppen und entpacken. Ist das erledigt, kann das Modul gebacken, installiert und bekannt gemacht werden:

[root@nas r8168-8.018.00]# make clean modules
make -C src/ clean
make[1]: Entering directory `/usr/src/r8168-8.018.00/src'
rm -rf *.o *.ko *~ core* .dep* .*.d .*.cmd *.mod.c *.a *.s .*.flags .tmp_versions Module.symvers Modules.symvers Module.markers *.order
make[1]: Leaving directory `/usr/src/r8168-8.018.00/src'
make -C src/ modules
make[1]: Entering directory `/usr/src/r8168-8.018.00/src'
make -C /lib/modules/2.6.18-164.el5/build SUBDIRS=/usr/src/r8168-8.018.00/src modules
make[2]: Entering directory `/usr/src/kernels/2.6.18-164.el5-i686'
 CC [M]  /usr/src/r8168-8.018.00/src/r8168_n.o
/usr/src/r8168-8.018.00/src/r8168_n.c: In function »rtl8168_tx_clear«:
/usr/src/r8168-8.018.00/src/r8168_n.c:8073: Warnung: Variable »dev« wird nicht verwendet
 CC [M]  /usr/src/r8168-8.018.00/src/r8168_asf.o
 CC [M]  /usr/src/r8168-8.018.00/src/rtl_eeprom.o
 LD [M]  /usr/src/r8168-8.018.00/src/r8168.o
 Building modules, stage 2.
 MODPOST
 CC      /usr/src/r8168-8.018.00/src/r8168.mod.o
 LD [M]  /usr/src/r8168-8.018.00/src/r8168.ko
make[2]: Leaving directory `/usr/src/kernels/2.6.18-164.el5-i686'
strip --strip-debug r8168.ko
make[1]: Leaving directory `/usr/src/r8168-8.018.00/src'

[root@nas r8168-8.018.00]# make install
make -C src/ install
make[1]: Entering directory `/usr/src/r8168-8.018.00/src'
install -m 744 -c r8168.ko /lib/modules/2.6.18-164.el5/kernel/drivers/net/
make[1]: Leaving directory `/usr/src/r8168-8.018.00/src'

[root@nas r8168-8.018.00]# depmod -a

Damit das System nicht auf dumme Gedanken kommt und womöglich noch das alte Modul nutzt, wird ein zusätzlicher Eintrag in die /etc/modprobe.d/blacklist erstellt.

blacklist r8169

In der /etc/modprobe.conf wird der alias für eth0 von r8169 auf r8168 abgeändert.

alias eth0 r8168

Nach einem Reboot oder entladen des alten Moduls && laden des neuen Moduls && Netzwerk Neustart sollte das neue Modul geladen sein und man kann fröhlich Daten schubsen.

[root@nas ~]# lsmod |grep r81
r8168                 100028  0

Die Geschichte mit dem ESXi Backupscript ist ja nicht neu und mich sowie viele andere User stört die fehlende Möglichkeit, Statusmails zu versenden.  Ich habe bisher ab und zu mal in die Backups geschaut und geguckt ob auch alles gesichert wurde. Da auf dem ESXi bei mir nur unkritische Systeme laufen, ist es nicht ganz so wild wenn mal ein Backup fehlt, nervig ist es dann aber trotzdem. Nun ist es mit Hausmitteln aber nicht möglich Mails zu versenden und ich denke VMware hat sich etwas dabei gedacht, die Busybox so extrem abzuspecken. Zum einen werden Sicherheitstechnische Gründe dahinter stecken und zum anderen soll der ESXi auch auf USB Sticks etc. passen. Also muss eine andere Lösung her und beim erforschen des Systems ist mir Python eingefallen. Leider hat VMware auch hier an sehr vielen Librarys gespart, so fehlt auch die wichtigste Lib für den Mailversand, die smtplib.

Python 2.5 (r25:51908, Mar  5 2007, 23:18:19)
[GCC 4.1.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: No module named smtplib

Die Ausgabe zeigt schon, dass VMware die Version 2.5 einsetzt. Also habe ich eben diese Version von Python heruntergeladen und den enthaltenen Lib Ordner auf einen Datastore entpackt.

Link

[More]

Willkommensbildschirm ist vielleicht etwas undeutlich ausgedrückt, mir ist aber gerade keine bessere Bezeichnung eingefallen. Gemeint ist jedenfalls die Startseite, die im Browser erscheint, wenn man den ESXi via HTTPs aufruft. Aus ganz unterschiedlichen Gründen möchte man diese Seite vielleicht verbergen, z.B. wenn man einen ESXi bei Hetzner gehosted hat und er mit nacktem Pöter im Netz steht.

ESXi "Willkommensbildschirm"

Um diese Seite zu entfernen, reicht es aus, die /usr/lib/vmware/hostd/docroot/index.html umzubenennen:

mv /usr/lib/vmware/hostd/docroot/index.html /usr/lib/vmware/hostd/docroot/index.html.bak

Wer abgesehen vom ESXi bei Hetzner oder sonstwo noch einen Server mit fester IP hat, sollte sich vielleicht überlegen, das Routing dahingehend zu ändern, dass der ESXi nur via dieser anderen statischen IP erreichbar ist. Denn die Konsole des ESXi direkt im Netz halte ich für keine besonders gute Idee… Just my 2 cent.

Seit Tagen schon stören mich die Spammer, die als Referer eine eindeutig nicht- jugendfreie Domain hinterlassen. Bisher hat Akismet zwar alles schön säuberlich rausgefiltert aber trotzdem stört es mich, dass sie bis ins Backend durchkommen. Da der Blog hier auf einem Lighttpd läuft, habe ich mich mal nach einer Möglichkeit umgeschaut, die bösen Buben schon vor dem Kommentieren abzuweisen.

Folgender kleiner Einzeiler in der vhost Konfiguration schickt jeden Referer der eins der Schlagwörter beinhaltet, auf ein 403 Forbidden.

$HTTP["referer"] =~ "fuck|viagra|cialis|sperm|ass" { url.access-deny = ( "" ) }

Und tschüss…

Testen kann man das übrigens ganz schön mit dem RefControl AddOn für den Firefox.

Will man einen Telefonserver in einer virtuellen Maschine betreiben, hat man theoretisch 2 Möglichkeiten. 1. Man setzt komplett auf VoIP oder 2. man nutzt Lancapi um via LAN Zugriff auf eine ISDN Karte zu haben, die in einem physischen Server steckt. In meinem Fall habe ich die AVM Fritzcard in einen Backupserver eingebaut.

Zunächst sollte man erst einmal auf dem Rechner, in dem die ISDN Karte steckt, die isdn4k-utils fcpci sowie die capi4k-utils installieren.

[More]

Die Daemontools unter Linux sind nicht dazu da .ISO oder .IMG Files zu mounten, wie etwa bei den Daemontools unter Windows, sondern sie machen einen Dienst “Hochverfügbar”. Daemontools ersetzen für die überwachten Dienste, die Init Scripte und starten einen Dienst innerhalb von 5 Sekunden nach Absturz oder beenden neu. Der Daemon supervise, überwacht alle Dienste, für man unter dem Ordner /service/$DIENST ein Run-Script angelegt hat.

Die Installation der Daemontools ist unter CentOS5 leider etwas tricky. Ohne Eingriff kompiliert die 0.76 Version von D.J. Bernstein leider nicht fehlerfrei. Wer eine andere Distribution einsetzt, kann evtl. gleich bei der Konfiguration weitermachen. Sollte man bei der Installation allerdings folgenden Fehler erhalten,

usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in envdir.o

muss man in der “src/conf-cc” die Zeile, welche mit gcc anfängt, durch ein

-include /usr/include/errno.h

ergänzen.

[More]

Vor einiger Zeit habe ich hier das ghettoVCB Backup Script für den VMWare ESXi 3.x vorgestellt. Eine Version für den ESXi 4.0 gibt es dort ebenfalls. Da der ESXi bei einem Reboot sein Filesystem neu aufbaut sind alle Änderungen, die man z.B. für SSH Keybased Authentication oder Cronjobs vornimmt wieder verschwunden. Um die Einstellungen trotzdem persistent zu machen sind weitere Schritte notwendig.

Vorbereitungen auf dem ESXi.

Da auf dem ESXi von Haus aus kein SSH unterstützt wird, sollte dies erst einmal erledigt werden. Eine gute Anleitung dazu findet ihr hier.

Remotebackup von einem Linuxserver aus

SSH Keybased Auth – ESXi Server

Wir erstellen also das benötigte Verzeichnis /.ssh im Root  und darin das authorized_keys File.


mkdir /.ssh
touch /.ssh/authorized_keys
chmod 600 /.ssh
chmod 600 /.ssh/authorized_keys


SSH Keybased Auth – Linux Client

Auf dem Linux Client erstellen wir per ssh-keygen unseren Public Key, wobei wir passphrase leer lassen.


[root@gollum ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.


Den Inhalt der Datei /root/.ssh/id_rsa.pub kopieren wir in die Datei /.ssh/authorized_keys.
Der Login sollte jetzt ohne eine Eingabe vom Passwort funktionieren.

Damit das Ganze auch nach einem Reboot noch funktioniert, muss der Ordner ./ssh in die /bootbank/oem.tgz verfrachtet werden.

tar c - /.ssh | gzip > /bootbank/oem.tgz

Jetzt erstellen wir ein Script, welches auf dem 2. Linux Host via Cronjob ausgeführt werden soll und das Backup anstößt. (Bitte darauf achten, dass die ghettoVCB.sh und die backuplist.txt auf einem Datastore liegen, das diese sonst ebenfalls nach einem Reboot flöten gehen.)

Der Inhalt sollte in etwa wie folgt aussehen:

#!/bin/bash
ssh fb-vm-esxi01 << EOL #Verbindung zum ESXi aufbauen
/vmfs/volumes/datastore1/ghettoVCBi4.sh /vmfs/volumes/datastore1/backuplist.txt #Befehl der auf dem ESXi ausgeführt wird
exit #Logout vom ESXi
EOL

Zu guter Letzt können wir das Script auf dem Linuxserver in einen Cronjob packen.

Cronjobs auf dem ESXi direkt

Die Crontab des ESXi liegt unter /var/spool/cron/crontab/root, ist ebenfalls nicht persistent und auf 512 Zeichen limitiert. Wer mehr in die Crontab schreiben möchte, muss die oben erwähnte Vorgehensweise nutzen.

Wenn nur das Backup gestartet werden soll, reicht die ESXi Crontab aber noch aus.

Dazu öffnen wir die /etc/rc.local und fügen folgende Zeile hinzu:

echo "0 21 * * 5 /vmfs/volumes/datastore1/ghettoVCB4i.sh" >> /var/spool/cron/crontabs/root

Somit wird bei jedem Reboot der Eintrag in der Crontab wiederhergestellt.

Ein großes Dankeschön an die Kommentatoren, die mich auf die Rebootgeschichte aufmerksam gemacht haben.

So langsam aber sicher sind alle Webserver unter meiner Fuchtel auf Archlinux migriert und haben das auf RHEL basierende CentOS abgelöst. Ich hab vor etwa einem Jahr den ersten Webserver umgestellt und bisher nur gute Erfahrungen gemacht. Die Perfomance der Arch Webserver ist im Vergleich zu den CentOS doch deutlich gestiegen. Das bekommt man mit CentOS doch auch hin werden sicher einige denken. Klar bekommt man das hin, keine Frage, jedoch nur mit erheblichen Mehraufwand. Eine frische Archlinux Installation ist frei von Software die nicht zum Betrieb des Systems benötigt wird. Selbst bei der Minimalinstallation von CentOS muss man erst Dienste deaktivieren die nicht benötigt werden. Somit spart man ne Menge kostbarer Zeit. Die Installation des Grundsystems für dieses Tutorial hat vom Einlegen der “virtuellen” Cd bis zum abschließenden Reboot und Login keine 10 Minuten gedauert.

Der Webserver Lighttpd ist eine wirklich gute Alternative zu Apache. Große Webseiten wie z.B. Teilbereiche von Myspace, imageshack.us und auch der ehemalige Torrent Tracker The Pirate Bay setzen bzw. setzten auf Lighttpd.

[More]

Tweetdeck ist ein schöner Twitterclient für Adobe AIR. Somit ist es eigentlich auch nicht weiter wild, diesen unter Archlinux zu installieren. Wenn man weiß wie…

[More]

Spiele gibt es für den MAC zwar genug, was aber wenn man z.B. eine Runde Counter Strike spielen möchte? Steam/CSS gibt es momentan noch nicht nativ für den Mac. Eine Möglichkeit ist es, per Bootcamp ein zusätzliches Windows einzurichten, der Nachteil ist allerdings, dass man dann nur für ein kleines Spielchen den Rechner neu starten muss.

Die zweite Möglichkeit ist eine Emulation. Die Linuxuser kennnen bestimmt Wine, welches es emöglicht einige Windowsprogramme unter Linux auszuführen. Die kommezielle Version von Wine, Crossover ist dabei schon etwas weiter und hat bereits einige unterstützte Programme im Angebot. Zum einen gibt es Crossover Mac um z.B. Microsoft Office auszuführen und Crossover Games für Spiele.

Die Unterstützung für Steam, hat zwar noch nicht den Goldstatus erreicht, ist aber dennoch brauchbar wie ich festgestellt habe.

[More]