Datenrettungsgeschichte

Ausgangssstatus:

  • sehr neue 500 GB Platte (Western Digital WD5000AAKB)
  • 4 Partitionen: System (10 GB), Swap (2 GB), Daten1 (1 GB), Daten2 (450 GB); Swap, Daten1 und Daten3 als logische Laufwerke innerhalb einer erweiterten Partition; alle NTFS; Windows XP

Fehler:

  • Nach nur 2 Monaten machte das System Probleme: Es hakte insgesamt; einige Programme ließen sich nicht mehr starten (u.a. Fehler über defekte DLL-Dateien); Netzwerkfreigaben waren nicht mehr zugreifbar; es ließen sich keine neuen Benutzer anlegen.
  • Nach Neuinstallation von Windows traten ähnliche Symptome auf.
  • Beim nochmaligen Versuch Windows neu zu installieren wurden im Setup die Partitionen nicht mehr erkannt. Rechner fuhr nicht mehr hoch.

Behebungs-/Rettungsversuche:

  • Auch Knoppix (von CD gebootet) sah die Partitionen nun nicht mehr. Es traten während des Bootens üble Festplatten-Fehler auf (AddrMarkNotFound; DriveReady SeekComplete DataRequest Error; UncorrectableError…).
  • leere externe 500 GB Platte besorgt um defekte Platte dumpen zu können; ext3-Dateisystem darauf angelegt
  • dumpen mit dd war erfolglos, da es, sobald ein Fehler kommt, komplett abbricht
  • (ab hier grml als Live-Linux benutzt; hat etliche Rettungstools mit drauf)
  • mit ddrescue (das macht trotz Lesefehlern weiter) versucht zu dumpen, jedoch abgebrochen, weil am Anfangsbereich der Platte anscheinend besonders viel kaputt war und es deshalb _extrem_ langsam war – höchstwahrscheinlich ist der Bereich, wo die Partitionstabelle lag, mit betroffen und deshalb erkennen die Systeme die Partitionen auch nicht mehr
  • da die System- und Swap-Partitionen am Anfang lagen und keine wichtigen Daten enthielten ddrescue anders aufgerufen um ungefähr die ersten 10 GB zu überspringen
  • ddrescue -v /dev/hda /mnt/temp/dump.bin /mnt/temp/log -i 11436756992
  • hat mit ca. 2 MB/s gedumpt und war daher erst nach 3 Tagen fertig; 50 MB Fehler sind aufgetreten
  • externe Platte an anderen Rechner angeschlossen
  • verschiedene Recovery-Tools erfolglos auf den Dump ausprobiert (u.a. testdisk) – unklar warum, evt. haben die Teile nen Problem mit, dass es kein kompletter Dump oder der Anfang komisch war

Erfolgreiches Wiederfinden der Partitionen:

  • Im Dump nach Markierungen für den Anfang von NTFS-Dateisystemen gesucht (".R.NTFS", wobei "." nichtdarstellbare Zeichen sind):
  • grep -a -b -o $‘\xeb\x52\x90\x4e\x54\x46\x53′ /media/disk/dump.bin | cut -d":" -f1 > grep_results.txt
  • grep brach irgendwann mit "Cannot allocate memory" ab; war jedoch nicht schlimm, da die wichtigen Partitionsgrenzen (Anfang von Daten1 und Daten2) schon gefunden wurden (bei einem Rechner mit 4 GB RAM)
  • alle Offsets aus grep_results.txt durchprobiert: jeweils ein readonly-loopback-Device mit entsprechendem Offset angelegt und versucht zu mounten – z.B.:
  • losetup /dev/loop0 /media/disk/dump.bin -r -o 1444063744
  • mount /dev/loop0 /mnt/temp2

Überlegungen/Anmerkungen:

  • Bei mir waren die Fundstellen 1444030976, 1444063744, 2521542656 und 2521575424. Da diese Paare (z.B. 1444030976 und 1444063744) zu dicht nebeneinander liegen (32 KB), als dass sich dazwischen eine Partition befinden könnte ist es naheliegend, dass 1444063744 und 2521575424 die echten Offsets sind. Evt. waren das Kopien des Boot/Superblocks der jeweils vorhergehenden Partition. Das soll wohl bei NTFS am Partitionsende gespeichert sein.
  • Vermutlich sind die fehlerhaften 50 MB nun noch irgendwo im Dump verteilt und einzelne Dateien zerstört.
  • Wenn im Dateisystem vorher Images von NTFS-Dateisystemen lagen könnte dies den Suchvorgang natürlich durch viele fehlerhafte Fundstellen verkomplizieren.
  • Ich hab keine Ahnung, wie sich das mit dem Partitionsende beim Loopback-Device verhält (es wird ja nur das Offset und keine Länge angegeben). Hängt vielleicht auch vom Dateisystem ab, ob es da zu Problemen kommen kann. Zumindest sollte man nicht drauf rumschreiben, daher bei losetup die Option -r für readonly.

Authentifizierung mit SSL Client-Zertifikaten

Eine ganz minimalistische Beispielkonfiguration:


<virtualhost domainname:443>
ServerName domainname
DocumentRoot /var/www/domainname

SSLEngine On
SSLCertificateFile ssl/apache.crt
SSLCertificateKeyFile ssl/apache.key
SSLCACertificateFile ssl/ca.crt
SSLVerifyClient require
SSLOptions +StdEnvVars
</virtualhost>

StdEnvVars verursacht, dass als Umgebungsvariablen bei CGI-Scripten auch die SSL-Daten gesetzt werden, um z.B. den CN des Client-Zertifikats auszulesen.

ssl/ca.crt heißt übrigens, dass die Datei dort liegt: /etc/apache2/ssl/ca.crt, weil das ServerRoot entsprechend auf /etc/apache2 gestellt ist.

Zeilenenden ins „Unix-Format“ umwandeln

\r’s (CR, 0×0D) aus einer Textdatei entfernen, um Zeilenumbrüche auf ein einfaches \n (LF, 0×0A) zu ändern:
tr -d '\015' < windowsformat.txt > unixformat.txt

Falsche Fahne live auf ARD

…sogar Spiegel Online hat drüber berichtet http://www.spiegel.de/kultur/gesellschaft/0,1518,562840,00.html *freu*

Selbstsigniertes SSL-Zertifikat erstellen

Weil ich die genauen Parameter jedes Mal vergesse und openssl zu viele hat statt schnell nachschlagen zu können… Creating a self-signed SSL-certificate.

openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.crt -keyout /etc/apache2/ssl/apache.key

Die Direktiven um sie in Apache festzulegen sind SSLCertificateFile (für apache.crt) und SSLCertificateKeyFile (für apache.key).

PHP, SuExec und mod_fcgid (FastCGI) unter Debian

Um in einer Shared Hosting Umgebung sicherzustellen, dass die unterschiedlichen Benutzer nicht gegenseitig auf ihre Dateien zugreifen können muss beachtet werden, dass PHP- bzw. generell CGI-Scripte im Kontext des Benutzers ausgeführt werden, und nicht alle unter der ID des Webservers (www-data) laufen. Eine Möglichkeit dafür stellt SuExec bereit, was in der apache2-Standardinstallation von Debian bereits enthalten ist.
Die folgende Schrittfolge habe ich auf einem frischen absolut minimalistischen Debian Etch getestet (ca. 390 MB nach der Installation der hier beschriebenen Pakete) .

Nötiges Zeugs installieren und SuExec-Modul aktivieren

aptitude install php5-cgi apache2 libapache2-mod-fcgid
a2enmod suexec

(nicht libapache2-mod-fastcgi, das ginge wohl auch, wird aber etwas anders konfiguriert)

User anlegen:

useradd --create-home --home-dir /var/www/user1 user1
passwd user1

Apache VirtualHost-Config für user1 einrichten:

vi /etc/apache2/sites-available/testvhost

Inhalt:

<virtualhost *>
        ServerName testvhost
        DocumentRoot /var/www/user1/htdocs/testvhost
        SuexecUserGroup user1 user1
        <directory /var/www/user1/htdocs/testvhost>
                Options +ExecCGI
                AddHandler fcgid-script .php
                FCGIWrapper /var/www/user1/php5-cgi .php
        </directory>
</virtualhost>

Site aktivieren:

a2ensite testvhost

Wrapper-Script erstellen:

echo '#!/bin/sh' > /var/www/user1/php5-cgi
echo 'exec /usr/bin/php5-cgi "$@"' >> /var/www/user1/php5-cgi
chown user1:user1 /var/www/user1/php5-cgi
chmod 0700 /var/www/user1/php5-cgi

Apache neustarten:

/etc/init.d/apache2 restart

als user1 einloggen

mkdir -p ~/htdocs/testvhost
echo "< ? passthru('id'); phpinfo(); ?>“ > ~/htdocs/testvhost/index.php

im Browser Testen – http://testvhost/

Statt testvhost muss natürlich überall der entsprechende Domainname eingetragen werden, oder testvhost mit der entsprechenden IP des Servers in die /etc/hosts.

Hinweise:

  • Das Document Root des Users ist nicht ohne grund in /var/www. – SuExec ist standardmäßig so kompiliert, dass nur Scripte ausgeführt werden können, die sich dort befinden.
  • Es darf kein mod_php mehr aktiv sein.
  • Da das Wrapper-Script dem User gehört (gehören muss), ist es ihm möglich darüber beliebige Programme als CGI-Script zu starten.
  • Um gegenseitiges Lesen von Dateien zu verhindern müssen noch andere Maßnahmen vorgenommen werden. Beispielsweise sollten die Dateien der User maximal die Berechtigungen 0770 haben (dafür wäre eine Umstellung der umask auf 027 oder so ähnlich sinnvoll). Damit Apache dann noch die Dateien lesen kann, sollte der www-data Benutzer in der Gruppe des Users sein.
  • Andere Parameter zum optimieren von mod_fcgid sind hier dokumentiert: http://fastcgi.coremail.cn/doc.htm

Festplatten mit dd und netcat übers Netzwerk spiegeln

  • auf beiden Rechnern z.B. Knoppix booten
  • auf Zielrechner: netcat -l -p 9000 | dd of=/dev/sda
  • auf Quellrechner: dd if=/dev/hda | netcat 192.168.1.151 9000

IP-Adresse muss entsprechend an die reale des Zielrechners angepasst werden.
Anmerkung: Das Verfahren sollte natürlich nur in vertrauenswürdigen Umgebungen eingesetzt werden, da keine Authentifizierung stattfindet. Alternativ wäre wohl SSH sinnvoll.

pls-Playlists direkt mit mplayer abspielen

Ein kleines Script

#!/bin/bash
mplayer `wget $1 -O - --quiet | grep http | cut -d"=" -f2`

Kann dann mit URL zu einer Playlist (z.B. von Livestreams) als Parameter aufgerufen werden.
Auf die richtige Schreibweise mit den Backticks (`) achten.

…oder direkt mplayer -playlist (URL)

Ping: Übertragung fehlgeschlagen. Fehlercode 65

oder „Ping: transmit failed, error code 65″ … In der Supportdatenbank des Herstellers des entsprechenden (sogenannten) Betriebssystems ist vermerkt, dass Zone Alarm den Fehler hervorrufen kann. Interessanterweise trifft dies auch zu, wenn Zone Alarm selbst garnicht gestartet ist. Dass es installiert ist reicht schon aus. Abhilfe ist also es wirklich mit dem Uninstaller zu deinstallieren (oder vermutlich es richtig zu konfigurieren). Ich vermute, dass bei der Installation das System erstmal so verstellt wird, dass (fast) alles geblockt wird und erst wenn ZA gestartet und richtig konfiguriert ist Pakete durchgelassen werden.
Bemerkenswert ist noch, dass diese Konfiguration offenbar zur Filterung von ICMP und TCP führt, nicht jedoch von UDP-Paketen. Daher funktionieren einige Dienste wie DNS und Filesharing-Protokolle – Ping und HTTP etc. jedoch nicht.

Subversion per DAV und SSL auf Debian

Installation von Subversion mit Apache-Modul (über SSL). Es wird ein Beispielrepository mit dem Namen „test“ angelegt. Dieses kann dann per https://localhost/test/ ausgecheckt werden. Die Passwörter für die Benutzer werden hier im Beispiel einfach aus der /etc/shadow-Datei genommen, also von den Linux-Systembenutzern. Anstatt /etc/shadow kann (wird normalerweise) eine seperate Datei für die Nutzerdaten verwendet werden. In der authz-Datei (im Repository-Konfigurationsverzeichnis) müssen diese User dann den entsprechenden Repositories bzw. Unterverzeichnissen zugeordnet werden (rw = Leseschreibzugriff; r = nur Lesezugriff). Im Beispiel gibt es einen Benutzer mit dem Namen „user0″.

Zunächst die benötigte Software installieren (wenn noch nicht installiert sollte dabei Apache und Subversion durch die Abhängigkeiten gleich mitinstalliert werden):

aptitude install subversion libapache2-svn

Apache konfigurieren (Vhost anlegen und Port 443 für SSL setzen)

/etc/apache2/sites-available/subversion:

<VirtualHost 127.0.0.1:443>
ServerName localhost
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
DocumentRoot /var/subversion
<Location />
Order allow,deny
Allow from all
DAV svn
SVNParentPath /var/subversion/public
AuthzSVNAccessFile /var/subversion/public/test/conf/authz
Satisfy Any
Require valid-user
AuthType Basic
AuthName "Test Subversion Repository"
AuthUserFile /etc/shadow
</Location>
</virtualhost>

/etc/apache2/ports.conf

Listen 80
Listen 443

Verzeichnis für Repositories anlegen, zugreifbar machen durch www-data (Apache) und test-Repository mit svnadmin erstellen.

mkdir -p /var/subversion/public
chown -R www-data:www-data /var/subversion
su www-data
cd /var/subversion/public
svnadmin create test

Definition der Benutzer

/var/subversion/public/test/conf/authz:

[groups]
admin = root
test-developers = user0

[/]
@admin = rw

[test:/]
@test-developers = rw

Im Beispiel gibt es 2 SVN-Benutzergruppen: admin und test-developers, denen jeweils ein Benutzer, root und user0 zugeordnet ist. Auf alle Repositories und Unterverzeichnisse (/) haben die Benutzer der Gruppe admin Lese- und Schreibzugriff (rw). Außerdem haben die Benutzer der Gruppe test-developers Lese- und Schreibzugriff (rw) auf das Repository „test“ und alle untergeordneten Verzeichnisse.

Vhost per Symlink aktivieren, ggf SSL-Zertifikat anlegen, SSL-Modul aktivieren, Apache neustarten:

ln -s /etc/apache2/sites-enabled/subversion /etc/apache2/sites-available/subversion
mkdir /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.key
a2enmod ssl
/etc/init.d/apache2 restart

Um das Repository auszuchecken muss dann https://localhost/test/ benutzt werden. In einem realen System würde der VHost natürlich nicht auf localhost gesetzt werden.