Archiv ‘Linux’

Sonntag, 26. Dezember 2010

Netgear ReadyNAS Duo mit eigener FTP-Backuproutine sichern

Die Gründe hinter einem solchen Vorhaben können vielfältig sein — aber wer will es einem Linux-Hacker verübeln, wenn er sich des in einem ReadyNAS Duo werkelnde (aber völlig veraltete) Debian GNU/Linux‘ bemächtigen will?

Pakete nachinstallieren

Von der ReadyNAS-Web-Site lädt man sich zwei Binärpakete herunter, die mit der Installation über die Web-Oberfläche des Gerätes a) den Root-Zugang und b) apt-get nachrüsten:

Tipps

  • Falls die Download-Links nicht mehr funktionieren, schaut man am Besten unter Add-ons for RAIDiator 4.1.3+ nach. Klappt dieser Link auch nicht, hangelt man sich über die Web-Site via
    Support > Downloads > ReadyNAS Add-Ons > Add-ons for RAIDiator 4.1.3+
    durch.
  • Das Root-Passwort entspricht dem Administrator-Passwort, welches man zum Login auf der Web-Oberfläche verwendet.

lftp nachrüsten

Für das Backup der lokal auf dem NAS gespeicherten Daten auf einen entfernten FTP-Server habe ich mich für das Tool lftp entschieden:

# apt-get install lftp

Backup-Script einrichten

Damit man die Datensicherung automatisieren kann, sollte man unter /usr/local/bin/backup-emeidi.sh folgendes Script ablegen und gemäss seinen eigenem Gutdünken anpassen:

#!/bin/bash    

HOST="www.host.tld"
USER="user"
PASS="pass"
LCD="/c/"
RCD="/"

echo "---------------------------------------------------------------------"
echo "Backing up $LCD to $HOST/backup$RCD with user $USER"
echo "---------------------------------------------------------------------"
echo `date`
echo "---------------------------------------------------------------------"

lftp -c "
open ftp://$USER:$PASS@$HOST; 
lcd $LCD;
cd $RCD;
mirror --reverse \
       --verbose \
       --no-perms \
       --no-umask \
       --ignore-time"

echo "---------------------------------------------------------------------"
echo "Backup finished."
echo "---------------------------------------------------------------------"
echo `date`
echo "---------------------------------------------------------------------"
echo ""

exit 0

Die Variable LCD speichert das lokale Verzeichnis, die Variable RCD das entfernte (auf dem FTP-Server liegende) Verzeichnis.

Am Ende macht man das Script mittels folgendem Befehl ausführbar:

# chmod 755 /usr/local/bin/backup-emeidi.sh

Cron-Job einrichten

Damit das Script nun täglich einmal mitten in der Nacht ausgeführt wird, erstellt man sich unter /etc/cron.d/backup-emeidi einen entsprechenden Cron-Job:

...
0 1     * * *   root    /usr/local/bin/backup-emeidi.sh | mail -s "Backup ReadyNAS" -c syslog@server.tld syslog@customer.tld
...

Dieser Cron-Job wird täglich um 1 Uhr morgens gestartet und mailt das Ergebnis an syslog@customer.tld wie auch an syslog@server.tld. So kann der Sysadmin, wie auch der Kunde, täglich die Ergebnisse des Backuplaufes überprüfen.

Problem

Bei meinem Kunden werden lustigerweise gewisse Dateien in jeder Nacht gebackupt, obwohl diese nachweislich nicht verändert wurden. Ich vermute hier einen Bug in lftp.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. Dezember 2010

.bashrc wird beim Login nicht gelesen/ausgeführt

Da habe ich also all die nützlichen Anweisungen in meine ~/.bashrc eingefügt, damit beim Shellzugriff auf einen Linux-Server einerseits die Listings schön farbig ausgegeben werden, andererseits Nachfragen beim Löschen und Verschieben von Dateien erscheinen und so sicherstellen, dass ich aus Flüchtigkeit keine Dummheiten begehe:

...
export CLICOLOR=1
export LSCOLORS=DxGxcxdxCxegedabagacad
 
export LS_OPTIONS='--color=auto'
eval "`dircolors`"
alias ls='ls $LS_OPTIONS'
 
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

Doch was ist los? Nach einem Login bleiben die Terminalfarben bei einem Listing eines Verzeichnisses … weiss auf schwarz!

Ein kurzer Test mittels

$ . ~/.bashrc

Quelle: Kurztipp: bash neustarten und .bashrc neu einlesen

zeigt dann aber rasch, dass die Farben wirklich erscheinen — wenn denn .bashrc auch beim Login geladen werden würde.

Ein Vergleich mit einem anderen, ordungsgemäss funktionierenden Debian GNU/Linux zeigt das Problem umgehend auf: Es fehlt die ~/.profile. Nachdem ich diese Datei erstellt und mit folgenden Zeilen gefüllt habe, funktioniert das Farbfernsehen per SSH dann auch ab dem ersten Login:

# ~/.profile: executed by Bourne-compatible login shells.

if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi

mesg n

Quelle: bashrc not getting read at login

Tags: , ,
Labels: IT, Linux

2 Kommentare | neuen Kommentar verfassen

Samstag, 11. Dezember 2010

realpath() des aktuellen Verzeichnisses in der Linux Shell

readlink -f .

Quelle: Bash equivalent for PHP realpath() | Andy Skelton

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 6. Dezember 2010

Debian Etch auf Lenny aktualisieren

Heute hatte ich es mit einer längst vergessen geglaubten Virtuellen Maschine zu tun, auf welcher noch ein Debian GNU/Linux mit einem 2.4er-Kernel installiert war. Im Grunde ging es nur darum, die aktuellsten VMware-Tools auf dieser Kiste zu installieren — doch wie immer zog dies umgehend einen riesigen Rattenschwanz an Debugging und sonstigen Upgrade-Arbeiten mit sich.

Nach etlichem Pröbeln und apt-get-Endlosschleifen hier die Kurzzusammenfassung, wie man Etch auf Lenny bringt:

sources.list

Zuerst einmal muss man Etch auf den letzten verfügbaren Stand aktualisieren. Da die Etch-Pakete von den Mirrors verschwunden sind, muss man alle vorhandenen Zeilen in der Datei /etc/apt/sources.list auskommentieren und folgende Zeilen einfügen:

deb http://archive.debian.org/debian-archive/debian/ etch main
deb-src http://archive.debian.org/debian-archive/debian/ etch main

Quelle: Debian (etch): sources.list

GPG

Natürlich funktioniert das apt-get update auf meiner Installation nicht sauber, weil mir einige PGP-Schlüssel fehlen. Da deren Fingerprint angegeben wird, kann ich diese ganz simpel mit folgendem Befehl mit meinem System bekannt machen:

# gpg --keyserver pgpkeys.mit.edu --recv-key  010908312D230C5F 
# gpg -a --export 010908312D230C5F | apt-key add -

Quelle: [Debian] Apt-get : NO_PUBKEY / GPG error

apt-get upgrade && dist-upgrade

Jetzt folgt das obligate

# apt-get update
# apt-get install apt aptitude
# apt-get upgrade
# apt-get dist-upgrade

um die neuesten Pakete zu installieren. Das System ist nun bereit, um auf einen neuen Kernel gehoben zu werden:

# apt-get install linux-image-2.6.18-6-686

Ist der Kernel installiert und GRUB angepasst (geschieht automatisch), sollte man den Server einmal neu starten (reboot).

sources.list

Frisch zurück im System mit Kernel 2.6, werden die oben hinzugefügten Zeilen nun wieder auskommentiert. Stattdessen fügt man nun folgende Repositories in /etc/apt/sources.list ein:

deb http://mirror.switch.ch/ftp/mirror/debian lenny main
deb-src http://mirror.switch.ch/ftp/mirror/debian lenny main

deb http://security.debian.org/ lenny/updates main

Quelle: Upgrading Debian Etch to Lenny stuck on kernel/libc issue

aptitude

ACHTUNG: Anstelle dieses kritische Kernel-Upgrade nun mit apt-get zu machen, hält man sich lieber an die Anweisungen der Debian-Maintainer und verwendet aptitude. Dieses kann viel besser mit Abhängigkeiten umgehen (Stichwort: libc6, dpkg (mit Breaks) etc.)

# aptitude update
# aptitude upgrade
# aptitude dist-upgrade

Quelle: Howto Upgrade Debian 4 Etch to Debian 5.0 Lenny

Dies bringt alle Pakete auf den neuesten Stand, die für das nun definitive dist-upgrade zwingend sind.

Kernel-Sourcen

Da die Kernel-Sourcen für Kernel 2.6.18 irgendwie nicht verfügbar sind, aktualisiert man kurzerhand auf Kernel 2.6.26:

# apt-get install linux-image-2.6.26-686
# reboot

Damit die VMware-Tools korrekt installiert werden können, lädt man sich nun auch noch die korrespondieren Quellen herunter:

# apt-get install linux-headers-`uname -r`

VMware-Tools

Anschliessend spielt man die VMware-Tools in gewohnter Manier ein. Fertig!

Tags:
Labels: IT, Linux

1 Kommentar | neuen Kommentar verfassen

Dienstag, 30. November 2010

Debian-Installation hängt mit 1% bei „Select and Install Software“

Heute konnte ich auf der Arbeit wieder einmal einen ausgemusterten PC mit Debian GNU/Linux versehen und zu einem Server (cups mit Samba inkl. Windows-Druckertreiber) umwandeln. Obwohl heuer, 2010, die Installation eines Linux-Betriebssystems kaum mehr grosse Mühe bereitet, fanden sich auch dieses Mal wieder Stolpersteine.

Konkret: Die Installation hing beim Aktualisieren der Pakete über den Internet-Mirror von SWITCH. Der Fortschrittsbalken im Dialog „Select and Install Software“ blieb bei 1% stecken und bewegte sich auch nach mehreren Minuten warten nicht weiter.

Nach etwas Googeln fand ich als erstes heraus, dass man mit Druck auf die Tasten Ctrl-Alt-F4 in die textbasierte Log-Ansicht der Installationsroutine schalten konnte. Dort stand etwas in der Form:

...
Nov 30 15:04:00 in-target:  To continue, enter "Yes"; to abort, enter "No"

Die Installation hing also, weil die Entwickler der Routine nicht vorhergesehen hatten, solche Eingabeaufforderungen automatisch mit „yes“ zu beantworten.

Als nächstes startete ich deshalb den Rechner neu, spielte die Installation durch, vermied es aber tunlichst, die Netzwerkkarte zu konfigurieren. So wurde die Internet-Aktualisierung zwar übersprungen und der Rechner bootete nach der Installation brav in die Shell — doch ich war danach aber schlichtweg nicht in der Lage, das Netzwerk zu laden (wahrscheinlich hätte ich das entsprechende Treibermodul laden müssen). Es trennt mich somit noch ein weiter Weg bis zum bombensicheren Linux-Admin.

Also hiess es ein weiteres Mal zurück zum Start. Dieses Mal initialisierte ich die Netzwerkkarte wieder von Beginn weg mit den benötigten Informationen. Als der Balken aber erneut hing, wechselte ich mittels Ctrl-Alt-F2 in ein interaktives Shell. Dort versuchte ich mich der brachialen Methode:

# ps ax | grep aptitude
 5760 ?        Ss     0:00 aptitude ...
# kill 5760

Der blockierte Prozess wurde so nullkommaplötzlich abgetötet. Mittels Ctrl-Alt-F1 ging es zurück in den Installationsbildschirm, wo mir eine rotgefärbte Fehlermeldung entgegenleuchtete und mir mitteilte, dass der wichtige Prozess verschwunden war.

Ich folgte den Anweisungen auf dem Bildschirm, drückte „Continue“, um die Installation trotz des Fehlers fortzusetzen und wählte aus der nun angebotenen Liste aus, dass nun der Bootloader grub in den MBR der Festplatte geschrieben werden sollte.

Die Installation lief durch, der Rechner startete neu — und sobald ich mich eingeloggt hatte, führte ich folgenden Befehl aus:

# apt-get update
...
# apt-get dist-upgrade

So hievte ich mein Debian GNU/Linux 5.0.6 auf 5.0.7 — und der Tag war gerettet.

Tags: ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Dienstag, 26. Oktober 2010

Darf ein Web-Entwickler seine geliebte Scripting-Sprache aufgeben?

How do you hire a programmer if you’re not one yourself? Some things to look for …

1. How opinionated are they?

Ask them about a juicy programming topic (e.g. Ruby or Python?). The tone and reasoning of the answer will reveal a lot. In our recent podcast on programming, Jeff said, “When people have strong opinions about things — when they can talk at length about something — it’s a good indication that they’re passionate about it.”

Quelle: How to hire a programmer when you’re not a programmer – (37signals)

Genau dies habe ich letzte Woche erlebt. Ich auf der Seite des Programmierers, auf der anderen Seite ein Headhunter, der für ein „internationales“ Unternehmen in Zürich einen Web-Entwickler suchte. Er war über Xing an meine Kontaktangaben gelangt.

Auf die Frage, ob ich Erfahrung in ASP.NET hätte, erwiderte ich ein klares Nein, um anzufügen, dass ich das letzte Mal im Jahr 2000 ASP programmiert hätte. ASP war damals mein erster Einstieg in webbasierte Scriptingsprachen. Innert weniger Monate wurde ich dann aber äusserst rasch auf die gute Seite der Macht gezogen — und entwickelte fortan auf den LAMP-Stack aufbauend.

Der Headhunter hakte nach: Ob ich es mir denn vorstellen könne, ASP.NET zu erlernen? Darauf erwirderte ich ein klares und dezidiertes „Nein“. Ich, der Mac OS X/Linux-Fan, der plötzlich in Visual Studio rumeiert? Das wäre wie wenn ein Kommunist zur SD überlaufen würde. Oder ein Wechselstromverfechter ins Camp der Gleichstromfreaks übertreten würde.

Ich habe mich noch ein/zwei Male gefragt, ob ich wirklich die richtige Antwort gegeben habe — doch mit obiger Bemerkung von Seiten der Web-Entwicklerprofis bin ich ein für allemal sicher, dass ich mich richtig entschieden habe.

Tags: , , , , , , ,
Labels: IT, Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. August 2010

E-Mails mit imapfilter serverseitig ablegen

Seit vielen Jahren verwende ich das IMAP-Protokoll zum Zugriff auf alle meine Mail-Adressen. Doch leider nimmt die Mailflut immer mehr zu, und das stört.

Bis zum heutigen Tag habe ich mich „Regeln“ in Apple Mail beholfen, um Mails beim Eintreffen in die entsprechenden Unterordner abzulegen. Seit ich aber einen Laptop und ein iPhone besitze und zunehmend auch unterwegs Mails abrufe, wäre es äusserst nützlich, wenn ich eingehende Mails vollständig automatisch serverseitig vorsortieren und in Unterordner ablegen könnte.

Bisher war ich dazu genötigt, die Regeln von Apple Mail auf meiner Workstation zu Hause auf den Laptop zu übertragen. Immer wieder habe ich mir dabei vorgenommen, diese Redundanz aufzuheben. Heute ist es nun soweit!

Was tun? Wer einen dedizierten Mailserver im Keller stehen hat, wird sich auf procmail-Scripts stützen (ich habe auch schon darüber berichtet), die eingehende E-Mails nach bestimmten Kriterien in Unterordner verschieben. Dies ist für mich keine Option, weil mein von Genotec betriebener Mailserver keinen Shellzugriff bietet. Auch bietet der Hoster keine anständige Möglichkeit an, serverbasierte Filter einzurichten.

Heute nun bin ich via einer diesbezüglichen Frage auf der Community Serverfault auf imapfilter gestossen.

Installation

Zuerst installiert man sich das Paket unter Debian auf einem ans Internet angeschlossenen Server, der nonstopp läuft:

apt-get install imapfilter

Filterregeln erstellen

Anschliessend schreibt man sich mit der Sprache Lua (vgl. die Beispiele Rotating email into your inbox using imapfilter sowie sample.config.lua.txt) entsprechende Filter-Rezepte und legt diese nach einem chmod 600 * im Homefolder beispielsweise unter ~/.imapfilter/filter/ ab.

Nachfolgend ein solches „Rezept“ für einen meiner Mailkonti:

mbox = IMAP {
    server = 'mail.server.tld',
    username = 'user@domain.com',
    password = '********',
    ssl = 'ssl3'
}

-- Facebook
messages = mbox.INBOX:contain_from('facebookmail.com')
messages:move_messages(mbox['Facebook'])

...

-- AHC
messages = mbox.INBOX:contain_field('List-ID','gi-ch.googlegroups.com')
messages:move_messages(mbox['AHC'])

...

Wie man anhand dieses Beispiel sieht, kann man jedes beliebige Feld des Mail-Headers auswerten. Als Hilfe für alle verfügbaren contain_X-Befehle sei auf die Dokumentation unter imapfilter_config – imapfilter configuration file verwiesen. Es gibt auch noch andere Befehle, die es ermöglichen, noch deutlich feingranuliertere Regeln zu programmieren.

Hat man wie ich mehrere Mail-Konti, die abgegrast werden sollen, erstellt man entsprechende Filter für jedes Konto und legt diese im selben Ordner unter einem aussagekräftigen Namen ab.

Shell-Script schreiben

Damit man diese nun alle auf’s Mal durchackern lassen kann, empfiehlt sich, ein kleines Shell-Script zu schreiben:

#!/bin/sh

IMAPFILTER=`which imapfilter`
RECIPESROOT="~/.imapfilter/filter"

cd $RECIPESROOT

for RECIPE in *
do
        #echo "Running $IMAPFILTER -c '$RECIPESROOT/$RECIPE'"
        $IMAPFILTER -c "$RECIPESROOT/$RECIPE"
done

exit 0

Cron-Job einrichten

Anschliessend richtet man einen Cron-Job ein, der die Mailserver beispielsweise alle 5 Minuten nach neuen Nachrichten abfragt und je nachdem die Filterregeln anwendet:

*/5 * * * *	/usr/local/bin/imapfilter.sh

Fertig ist der kostenlose, transparente Filterservice für eingehende Mails.

Tags: , , ,
Labels: Linux

3 Kommentare | neuen Kommentar verfassen

Mittwoch, 28. Juli 2010

Debian GNU Linux auf „dependency-based boot system“ umstellen

Seit einigen Wochen offeriert mir Debian bei jedem apt-get dist-upgrade, mein System auf ein abhängigkeitsbasiertes Bootsystem („dependency-based boot system“) umzustellen.

Störrische Pakete

Leider ist dies bisher jedesmal gescheitert, weil folgende init.d-Skripte die Umstellung verhindert haben:

'libdevmapper1.02' missing LSB tags and overrides, 
'iptables' missing LSB tags and overrides, 
'xfree86-common' missing LSB tags and overrides, 
's3sqld.init' missing LSB tags and overrides, 
'libdevmapper1.00' missing LSB tags and overrides, 
'dhcp' missing LSB tags and overrides, 
'raid2' missing LSB tags and overrides, 
'rendezvous' missing LSB tags and overrides,

Gestern habe ich mir nun endlich die Mühe genommen, mein System zu durchforsten, aufzuräumen und auf die neue Boot-Methode umzustellen. Wie es sich herausstellte, war es doch nicht so kompliziert, wie ich es befürchtet hatte.

Generisches Vorgehen

Zuallererst ist zu überprüfen, ob das bemängelte Script tatsächlich noch vom System benötigt wird oder ob es bei einem apt-get remove <package> versehentlich zurückgelassen wurde.

Als erstes sucht man deshalb auf packages.debian.org mit der Suchfunktion unter „Search the contents of packages“ nach der entsprechenden Datei. Kann diese in keinem aktuellen Paket gefunden werden, ist es wahrscheinlich, dass es sich um ein Überbleibsel handelt. Zur Sicherheit kann man mittels dpkg --list | grep <vermutetes package> überprüfen, ob das Paket tatsächlich vor langer Zeit entfernt wurde (rc steht in diesem Fall zu Beginn der Zeile).

Wird die Datei hingegen irgendwo gefunden, muss man mittels Google herausfinden, ob und wie das init-Skript von Hand angepasst werden kann, um die geforderten „LSB tags“ und „overrides“ eingepflegt zu erhalten.

Konkretes Vorgehen

Konkret sah das Prozedere bei mir folgendermassen aus (Achtung: Sicherheitskopien sind ratsam, um notfalls nicht das gesamte System zu zerschiessen):

  • libdevmapper1.02 wird benötigt. Das Skript muss mit der Anleitung von Bug#361358: marked as done (libdevmapper1.02: Please add LSB formatted dependency info in init.d script) angepasst werden
  • libdevmapper1.00 Überrest, kann gelöscht werden (apt-get remove libdevmapper1.00), da eine neuere Version dieses Pakets auf dem System installiert ist (s. oben)
  • iptables Überrest, kann gelöscht werden (rm /etc/init.d/iptables) — auch wenn es der Package-Maintainer aus Rückwärtskompatibilität dort belassen möchte: „The script was dropped from the package ages ago. Unfortunately, removing it would have been problematic, so it’s just a vestige.“
  • xfree86-common Überrest, kann (in meinem Fall!) gelöscht werden, da dpkg --list | grep xfree meldet: rc xfree86-common 6.9.0.dfsg.1-6
  • s3sqld.init Überrest einer Testinstallation des unbrauchbaren Seco Backups. Kann gelöscht werden.
  • dhcp Es handelt sich hierbei um ein hoffnungslos veraltetes Paket, das aus Sicherheitsgründen umgehend ersetzt werden sollte: apt-get install dhcp3-server Die DHCP-Konfiguration in /etc/dhcp3/dhcpd.conf muss dabei glücklicherweise nicht angepasst werden.
  • raid2 Überrest (?), verweist auf nicht mehr vorhandene raidstart etc. und kann deshalb gelöscht werden.
  • rendezvous Überrest, das Paket wird auf dem Debian-Server nicht mehr gefunden. Das Paket kann entfernt werden: apt-get remove rendezvous. Je nachdem muss man vorher noch einen in der Zwischenzeit gelöschten Benutzer daapd erstellen, der dann von der Deinstallationsroutine gleich wieder entfernt wird.
  • initrd-tools.sh Bei der Suche nach dieser Datei im Debian Package-Archiv wurde kein Paket zurückgeliefert, welches dieses Script auf dem System installieren würde. Ich habe diese Datei deshalb kurzerhand gelöscht.

Endlich den Schalter umlegen …

Schlussendlich kann man die Boot-Methode nun umstellen:

# dpkg-reconfigure sysv-rc
info: Checking if it is safe to convert to dependency based boot.
info: Reordering boot system, log to /var/lib/insserv/run-20100727T1330.log
success: Enabled dependency based boot system.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 5. April 2010

Wenn man sich mit denyhosts.py selber aussperrt …

… ist es an der Zeit, in der Datei /etc/hosts.allow endlich folgenden Eintrag anzufügen:

...
sshd: 192.168.0.2
...

Wobei hier natürlich anstelle von 192.168.0.2 die IP-Adresse angegeben werden sollte, die der Client (also die Workstation, von welcher man sich per SSH auf den Server verbindet) trägt.

Via: Debian Linux Stop SSH User Hacking / Cracking Attacks with DenyHosts Software

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 13. Dezember 2009

Erfahrungen bei einem Server-Upgrade

Gestern um 20:00 begann ich damit, meinen Heimserver dem grössten Upgrade in seiner Geschichte zu unterziehen. Zwei Gründe bewegten mich zu diesem Entscheid: Einerseits war das Gerät längst betagt und mittlerweile äusserst schwach auf der Brust. Andererseits kämpfe ich seit dem Sommer 2009 sporadisch mit „Black Screens Of Death“, welche nur mit einem Reset zu beheben waren. Natürlich machen solche Ausfälle bei einem eigentlich 24/7 verfügbaren Server keinen Sinn. Leider brachte die Fehlersuche über Monate hinweg keine Ursache zu Tage. Vermutlich lag es an der Altersschwäche eines Bauteils.

Was hat sich in der Hardware geändert?

Server alt

  • Yeong Yang YY-B0221 (spezielles Server-Gehäuse mit zwei Abteilen für Motherboard und Laufwerke)
  • Intel Pentium III, 600 MHz
  • Asus P3B-F
  • 4x Kingston 256 MB, SDRAM, PC100 — KVR133X64C3/256
  • Matrox Millennium G200, AGP
  • Intel PWLA8391GT, PCI, Gigabit-Ethernet
  • Adaptec AHA-2940U2W, SCSI-Controller
  • 1x Fujitsu MAJ3182MP, 18.2 GB, U2W-SCSI — System
  • FirmTek SeriTek/1S2, SiL 3112, SATA-Controller
  • 1x Maxtor , 160 GB, SATA — /var
  • 2x Promise Ultra 133 TX2
  • 4x Samsung SP2514N, 250 GB, ATA-7 (RAID1+0) — Storage

Server neu

  • Yeong Yang YY-B0221 (spezielles Server-Gehäuse mit zwei Abteilen für Motherboard und Laufwerke)
  • Intel Core 2 Duo E5400, Dual Core 2.7 GHz, 800 MHz
  • Asus P5QPL-VM-EPU, Mini-ATX
  • 1x Apacer 1 GB, DDR2, 800 MHz
  • Intel PWLA8391GT, PCI, Gigabit-Ethernet
  • 1x Samsung HD161GJ, 160 GB, SATA-3 — System
  • 2x Samsung HD154UI, 1.5 TB, SATA-3 (RAID1) — Storage

Erfahrungshäppchen

  • Grundsätzlich sei wieder einmal zu erwähnen, dass man ein solch tiefgreifendes Hardware-Update unter Windows schlichtwegs hätte vergessen können; um eine Neuinstallation wäre man auf Grund der komplett anderen Hardware nicht herumgekommen. Ich lobe mir deshalb Debian GNU/Linux, welches — zwar auch mit einiger (selbstverursachter) Müh und Not — nach einigen Anpassungen anstandslos unter der neuen Hardware bootete.
  • Durch die Vereinfachung der Storage-Infrastruktur (Wegfall von 3 Platten und 4 Controllern) sank die Stromaufnahme um 5 %, obwohl anzunehmen ist, dass CPU und Motherboard mehr Energie benötigen als die Komponenten des alten Servers.
  • Dass im Server-Gehäuse nun nur noch 3 statt 6 Festplatten hängen, erlaubt mir, diese deutlich effizienter zu kühlen. Auch das Betriebsgeräusch des Servers ist aus meiner Empfindung etwas leiser geworden.
  • Das Motherboard weist einen sog. EATXPWR-Connector auf. Auf den ersten Blick befürchtete ich, am Sonntag noch ein neues Netzteil kaufen zu können. Steckt man den Stromstecker eines normalen ATX-Netzteils ein, sind vier Pins des neuen Steckers nicht belegt. Das Board startet trotzdem — wenn man den zusätzlichen 4-pin 12V-Anschluss in der Nähe des Prozessors mit dem entsprechenden Kabel des Netzteils bestückt. Der Betrieb ist also durchaus möglich — entweder mit 20-pin ATX + 4-pin ATX 12V oder 24-pin EATXPWR.
  • Aus ISO-Images von Ubuntu einen bootbaren USB-Stick zu bauen, ist unter Mac OS X nicht möglich. Es wird vielerorts empfohlen, stattdessen die IMG-Datei des Ubuntu Netbook Remix herunterzuladen, ohne aber auf eine solche Datei zu verlinken. Diese gibt es nämlich nur für das ältere Ubuntu 9.04 (aktuell: 9.10); bspw. auf dem SWITCH-Mirror: ubuntu-9.04-netbook-remix-i386.img. Mit diesem Image soll es anschliessend gemäss Anleitungen im Netz möglich sein, unter Mac OS X mit dem Terminal den Stick mit Ubuntu bootbar zu machen.
  • Da der Download dieser Datei ein gute Stunde dauerte, habe ich schlussendlich einen alten DVD-Brenner im Server verbaut und den Server von CD gebootet.
  • Bei der Partitionierung der neuen 160 GB-Systemplatte mit fdisk unter Ubuntu Live-CD habe ich bei der Grössenangabe für die einzelnen Partitionen vergessen, ein + voranzustellen (Bspw. +512M für eine Partition mit 512 MB Platz). Deshalb ist meine /boot-Partition nun nicht 512 MB gross, sondern 3.1 GB *autsch*
  • Um den Swap-Space zu initialisieren, benutzte ich mkswap, was beim ersten Anlauf aber enorm viel CPU-Resourcen benötigte und nicht vor dem Ende meiner Geduld abgeschlossen werden konnte. Indem ich dieses Executable ohne den Paramenter -c (für „check“) aufrief, rauschte die SWAP-Formatierung wie im Schnellzugstempo durch.
  • Nachdem ich die Daten von der alten SCSI-Systemplatte auf die SATA-Systemplatte kopiert hatte (der Adaptec AHA-2940U2W SCSI-Controller und die daran hängende Platte wurde vom Board und Ubuntu problemlos erkannt), startete der Rechner nicht, weil GRUB einen „Error 2“ meldete. Ich war mir ganz sicher, dass ich den Bootsektor in die richtige Platte geschrieben und mit hd(0,0) auch garantiert die richtige Platte konfiguriert hatte. Wo also lag das Problem? Dank eines Blog-Artikels GRUB „Error 2“ May Mean Incompatible stage1.5, stage2, and ext2 kam ich darauf, dass ich die Platte mit einem brandneuen mkfs.ext3 formatiert, dann aber die GRUB-Stages 1.5 und 2 datierend aus dem 2007 von der alten Platte in den Bootsektor geschrieben hatte. Glücklicherweise fanden sich unter /usr/lib/grub/i386-pc/ neuere Dateien im leicht grösseren Umfang und aus dem Jahr 2009. Nachdem ich diese Dateien über /boot/grub kopiert und den MBR neu geschrieben hatte, funktionierte der Bootvorgang dann endlich wie geschmiert.
  • Nachdem das System zum ersten Mal in der neuen Konfiguration ohne fremde Hilfe hochgekommen war (nicht vergessen: /etc/fstab und /boot/grub/menu.list müssen zwingend angepasst werden!), ging es nun darum, /var von der alten SATA-Platte rüberzukopieren. Wie bei allen Kopieraktionen verwende ich dazu # rsync -av . /mnt/sda1 oder dergleichen. Bricht der Kopiervorgang aus unerfindlichen Gründen ab, stellt man mit rsync sicher, dass nur diejenigen Dateien kopiert werden, die auf dem Zielsystem noch nicht identisch vorhanden sind. Auch werden die Benutzer und Rechte auf jeden Fall mitkopiert.
  • Die Daten vom RAID1+0 kopierte ich heute Sonntag-Nachmittag auf das neu erstellte RAID1. Damit ich die Daten nicht über das langsame Ethernet-Netzwerk kopieren musste, suchte ich mir zwei exteren USB-Festplattengehäuse und wählte dann zwei Festplatten des RAID-Verbundes aus. Wichtig ist bei RAID1+0 natürlich, dass man die zwei komplementären Platten nimmt, die im Degraded-Modus das ganze Volume herstellen. Damit mdadm die Platten erkannte, musste ich in /etc/mdadm/mdadm.conf einige Ergänzungen vornehmen, weil der verschachtelte RAID-Verbund nicht automatisch erkannt wurde. Kernstück waren dabei folgende Zeilen:
    ...
    DEVICE partitions
    ...
    ARRAY /dev/md10 metadata=0.90 UUID=8b74168f:921d62ec:197e72a9:dcc396dd
    ARRAY /dev/md11 metadata=0.90 UUID=c7acb783:7d200806:ba3b0bb9:fba14ed1
    ARRAY /dev/md1 metadata=0.90 UUID=0b0b49d4:63eada39:e2d889b1:01493278

    Die UUIDs waren glücklicherweise in der alten mdadm.conf hinterlegt. Sie sind unbedingt zu notieren und an einem sicheren Ort aufzubewahren. Anschliessend klappte es problemlos, die RAID-Arrays mittels # mdadm --assemble /dev/md0 etc. zu starten (natürlich in der richtigen Reihenfolge, d.h. /dev/md1 am Schluss, wenn die RAIDs der beiden USB-Platten gestartet wurden. Ob metadata=0.90 wirklich nötig ist, weiss ich nicht. Als ein Array nur im auto-read-only-Modus gestartet wurde, führte ich folgenden Befehl aus, um auch Schreibvorgänge zu ermöglichen (im Grund ja unnötig, da wir nur Daten ab der Platte kopieren wollen):

    # mdadm --readwrite /dev/md10
  • Der anschliessende Kopiervorgang war einerseits ein Burn-In-Test für die verschiedenen Bussysteme des neuen Servers (USB, SATA), andererseits zeigte er die Performance der neuen Hardware:
    sent 460359385722 bytes  received 762070 bytes  38412962.39 bytes/sec
    total size is 460300401834  speedup is 1.00

    — 38 MB/Sekunde sind kein schlechter Wert für ATA-7 über USB auf SATA.

  • Da das neue Board nur noch die Pins für einen LPT-Anschluss mitbringt, musste ich meinen HP Laserjet 1300 neu über USB an den Server anschliessen. Leider wurde dabei aber /dev/usb/lp0 nicht automatisch erstellt. Nach einem # apt-get dist-upgrade erschien dieses Device plötzlich in der Dateiliste. Nur noch /etc/printcap anpassen (statt /dev/lp0 ist es neu /dev/usb/lp0 — fertig!). Auf jeden Fall lud der Kernel alle benötigten Module (usblp, usbcore und uhci_hcd). Dass der Drucker auch wirklich da ist, erkennt man mit dem Befehl:
    # lsusb
    ...
    Bus 002 Device 002: ID 03f0:1017 Hewlett-Packard LaserJet 1300
    ...

    Dieser Befehl findet sich im Paket usbutils

  • Bei Aufräumarbeiten in meinem IT-Ersatzteillager fand ich zufälligerweise ein Slotblech, welches zwei serielle Ports (COM1 & COM2) bereitstellte. Da das neue Board Pins für eine COM-Schnittstelle mitbringt, konnte ich so die ältere USV (APC 1400VA) wieder am Server anschliessen.

Labels: IT, Linux

1 Kommentar | neuen Kommentar verfassen