Tobi’s Blog

Gedanken zur Softwareentwicklung und anderes

Neue HyperCache Version: 2.51

Erstellt von Tobi am Dienstag 29. September 2009

Das Update auf die aktuellste Version von Hypercache hat mir eben ein klein wenig Probleme bereitet, wobei das alles hausgemacht war. Damit das nicht jeder für sich nochmal durchmachen muss, hier eine kurze Zusammenfassung:

Nach dem Update sehen die Einstellungen komplett anders aus. Es gibt keine Clean-Cache-Events mehr sondern nur noch den “Cache invalidation mode”. Den hab ich auf “all” gelassen und es scheint soweit die gleiche Funktion zu erfüllen. Ändert man an den Daten etwas, werden alle Cache-Daten entfernt.

Gzip wurde in “Enable compression” umbenannt, was etwas verwirrend ist, da die Funktionsweise nicht genau erklärt wird. Das steht nach wie vor auf “ein”. Außerdem gibts ein neues “Disk space usage”, was genauso wenig erklärt wird. Ich hab es erst mal aus gelassen, da dort was von “less performant” steht und der Cache nicht wirklich kleiner wurde.

Nachdem ich alle Optionen neu gesetzt hatte wollte ich den Cache testen. Die Startseite funktionierte tadellos und wurde auch gecacht und im Quelltext stand das HyperCache-Kommentar ganz am Ende. Alle anderen Seiten wurden aber NICHT gecacht. Nach etlichen Einstellungsversuchen und auch einem Downgrade auf Version 2.3.2 änderte sich das nicht. Erst, als ich mal durch Zufall den Browser schloss und dann nochmal testete.

Was war passiert? HyperCache aktiviert normalerweise den Cache für alle anonymen Benutzer, für eingelogggte ist er IMMER abgeschalten. Warum auch immer, aber die Startseite ist da wohl eine Ausnahme, was bei mir kräftig für Verwirrung sorgte. Also immer dran denken, wenn man den Cache testet: erst wieder ausloggen.

Ansonsten rennt das Plugin nach wie vor wie Hulle ( Tendenz Otze :) )

Abgelegt unter Technik | Keine Kommentare »

24h offline

Erstellt von Tobi am Dienstag 1. September 2009

Schon ein komische Gefühl, wenn man mal einen ganzen Tag keinen Strom hat. Naja, jetzt gehts ja wieder alles und der Server ist auch wieder online.

Abgelegt unter Allgemein | Keine Kommentare »

SVN-Server unter Ubuntu aufsetzen

Erstellt von Tobi am Donnerstag 16. Juli 2009

Da mein bisheriges SVN-Repository abgeschalten wurde, musste ich mich darum kümmern selber eines aufzusetzen. Große Ansprüche habe ich da nicht, es sollte nur einfach und schnell eingerichtet und über eine IP/Domain erreichbar sein. Folgende Möglichkeiten hab ich gefunden:

Das blanke Verzeichnis als Repository
SVN hat eigentlich gar keinen Server, sondern nur eine Vorggegebene Verzeichnisstruktur und eine dazugehörige Datenbank, die zusammen ein Repository darstellen. Man kann als Datei direkt per svn [COMMAND] file:///my/repository/path darauf zugreifen. Da man hier aber nur lokal zugreifen kann, die Benutzerrechte entsprechend anpassen muss und ansonsten auch keinerlei Zugriffsschutz einrichten kann, fiel das schonmal flach.
Als Apache2-Modul
Ein Apache-Server in dem per WebDAV und SVN connector auf das Repository zugegriffen werden kann. Hier hab ich keine brauchbare Anleitung finden können, die mir schnell genug zum Ziel führte. Außerdem müsste dann immer ein Apache laufen, was mir ein wenig wie mit Kanonen auf Spatzen zu schießen erscheint. Also so auch nicht.
Der mitgelieferte svnserve-Deamon
Ein eigener Deamon der mit svn schon mitgeliefert wird und super simpel funktioniert. Er ist nicht sonderlich sicher, aber ich greife nur über ein VPN auf den Dienst zu, da ist die Sicherheit nicht ganz so wichtig. Hier war diese Anleitung ganz hilfreich, die mir hier auch als Grundlage diente.

Folgendes muss (als Root oder per Sudo) getan werden, um ein SVN-Repository incl. “Server” aufzusetzen:

Vorbereiten

apt-get install subversion
Alle benötigten SVN Module installieren
mkdir /home/svn;chown root:root /home/svn;chmod go-rwx /home/svn
Das Root-Verzeichniss anlegen, in dem alle SVN-Repositories untergebracht werden sollen, und die Rechte so setzen, dass nur root darin etwas machen kann
echo -e “[users]\nmyUser = myUnencryptedPwd” > /home/svn/.passwd
Legt die allgemeingültige “Benutzertabelle” für SVN an. Hier der Benutzer myUser mit dem Passwort myUnencryptedPwd. Neue Benutzer einfach in die Datei in eine neue Zeile eintragen. Aber ACHTUNG: die Passworter liegen im Klartext vor und das lässt sich in der Form auch nicht ändern. Also am besten eigene, nur für dieses SVN gedachte Passwörter benutzen.
echo -e “[general]\nanon-access = none\nauth-access = write\npassword-db = ../../.passwd” > /home/svn/svnserve.conf
Legt die SVNServe-Config an und zwar so, dass die eben angelegte Benutzertabelle verwendet wird und nur autorisierte Benutzer auf die Repositories zugreifen dürfen
chmod 600 /home/svn/.passwd;chmod 600 /home/svn/svnserve.conf
Die Rechte zur Sicherheit nochmal einschränken, schließlich stehen da Passwörter im Klartext drin

Die angelegte Benutzertabelle und die Server-Config sollen in allen Repositories gelten, weswegen sie hier im SVN-Root-Verzeichnis liegen. Man kann das auch für jedes einzelne Repository machen, aber das das brauche zumindest ich an dieser Stelle nicht.

Server einrichten und starten

Dieses Init-Script runterladen
…und dann die Zeile
DAEMON_ARGS="-d -r /home/svn --listen-host 127.0.0.1"anpassen. IP und Port z.B. Das Script selber stammt aus der oben erwähnten Anleitung.
mv [INITDATEI] /etc/init.d/svnserve;chmod +x /etc/init.d/svnserve
Die Datei im Standart-Startordner des Systemes ablegen und die Rechte anpassen
update-rc.d svnserve defaults
Bewirkt, dass der Server beim Systemstart immer mitgestartet wird
/etc/init.d/svnserve start
Startet des SVN-Server

Ein Repository anlegen

Diesen Schritt kann man für jedes neue Repository ausführen

svnadmin create /home/svn/myFirstRepo
Legt das Repository an, also die SVN Datenbank und die Grundlegenden Verzeichnisse. In dem Fall mit dem Namen myFirstRepo
cd /home/svn/myFirstRepo/conf;rm *;ln -s ../../svnserve.conf;
Entfernt die Config und Benutzertabelle für das Repository und verwendet die oben angelegten, globalen Dateien
/etc/init.d/svnserve restart
Startet des SVN-Server neu, damit er die Änderungen auch mitbekommt

Jetzt kann man per svn info svn://127.0.0.1/myFirstRepo, nur eben mit der passenden IP, prüfen ob alles geht. Der Login sollte abgefragt und ein paar grundlegende Daten über das Repository angezeigt werden.

Dem neuen Repository fehlen aber noch ein paar Dinge, die die meisten SVN-Clienten einfach voraussetzen. Z.B. dass man Branches im /branches Verzeichnis ablegt und dass der Trunk unter /trunk liegt u.v.m. Deshalb ist es sinnvoll, gleich die empfohlene Verzeichnisstruktur anzulegen. Hierzu muss man als normaler Benutzer folgendes tun:

mkdir tmp
mkdir tmp/trunk
mkdir tmp/trunk/myFirstProject
mkdir tmp/branches
mkdir tmp/branches/myFirstProject
mkdir tmp/tags
mkdir tmp/tags/branches
mkdir tmp/tags/branches/myFirstProject
svn import tmp svn://127.0.0.1/myFirstRepo -m "svn-Verzeichnisstruktur erstellt"

Weiteres Projekt einem repository hinzufügen

Damit werden die grundlegenden Verzeichnisse im Repository abgelegt. Die myFirstProjekt-Verzeichnisse sind die Verzeichnisse für ein einzelnes Projekt. Will man eines weiteres hinzufügen, muss man folgendes, wieder als normaler Benutzer, tun:

svn co svn://127.0.0.1/myFirstRepo
mkdir myFirstRepo/trunk/mySecondProject
mkdir myFirstRepo/branches/mySecondProject
mkdir myFirstRepo/tags/branches/mySecondProject
svn ci myFirstRepo -m"Weiteres Projekt angelegt

Alles in allem gar nicht viel Arbeit, aber die Tatsache, dass es ziemlich unsicher ist, hinterlässt schon einen starken Nachgeschmack. Aber in meinem VPN laufen noch ganz andere, extrem unsichere Dienste, so dass das hier den Kohl auch nicht fett macht.

Abgelegt unter Linux(Ubuntu) | 1 Kommentar »

Backups, Teil 2: Ursachen für DVD-Probleme und Test der DVD-/CD-Fehlerkorrektur

Erstellt von Tobi am Freitag 29. Mai 2009

Wegen meiner Datenverluste hab mich mal im Netz und im Handel schlau gemacht, ob es ggf. Rohlinge gibt, die haltbarer bzw. besser geeignet sind. O-Ton: eigentlich nicht. Auf einen Hersteller kann man sich wohl nicht mehr verlassen, da alle in Fernost bei Billiganbietern produzieren und man quasi jeden Monat von der gleichen Marke Rohlinge eines anderen Herstellers bekommen kann. Außerdem ist generell die Datenschicht von DVD-ROMs, wohl aus Kostengründen, aus wenig haltbaren, organischen Materialien hergestellt. Diese sind sehr anfällig gegen Licht und jede andere Alterungserscheinung.

DVD-RW dagegen bestehen aus anorganischem Material, ebenso wie DVD-RAMs. Bei letzteren hörte ich nur Gutes von der Haltbarkeit, musste aber feststellen, dass das ein absolut unbrauchbares Format ist. Kein mir bekanntes DVD-Laufwerk unterstützt die Dinger und zum Kauf hab ich auch noch keine gesehen. DVD-RWs dagegen sind zwar etwas teurer als DVD-ROMs, aber mit ca. 1 € pro Rohling könnte ich gut leben, wenn es denn hält.

Ein weiterer Punkt für die Anfälligkeit aller DVD-Arten der öfter genannt wurde ist, mit Ausnahme bei der DVD-RAM, die offenbar schlecht umgesetzte “Fehlerkorrektur”. Es werden bai allen dieser Datenträger redundante Daten “intelligent” auf der Oberfläche verteilt und zwar so, dass übliche Fehler wie Kratzer, ausgeglichen werden können. Es gibt aber bei der DVD das Problem, dass die inneren und die äußeren Bereiche damit nicht ordentlich abgedeckt werden und somit besonders gefährdet sind. Beim Innenbereich ist das besonders kritisch, denn wenn der unlesbar ist, erkennt das Laufwerk den Datenträger nicht mehr als solchen und man kann gar nichts mehr machen. Für diesen Fall gibt es zwar auch Programme im Netz, aber die haben bei mir keinen Erfolg gebracht.

Der Kratztest

Alleine die Aussagen der Händler oder die Infos im Netz helfen mir wenig. Praxiserfahrung musste her. Also ging ich im ersten Schritt daran, verschiedene Rohlinge voll zu schreiben und Kratzer in verschiedener Formen und an verschiedenen Stellen zu machen und die Auswirkungen zu untersuchen. Da das Programm dvddisaster auch eine Checksummendatei zur besseren Fehlerkorrektur anbietet und ich ja dann schon defekte Datenträger hatte, konnte ich das auch gleich mit testen.

Zur Vorbereitung hab ich eine DVD und eine CD voll beschrieben und das ISO-Image der beiden auf die Platte gesichert. Von diesen Images hab ich mit dvddisaster zwei Checksummendatei (ECC) mit den Standardvorgaben des Programmes erstellt. Eine “normal” mit 14,2% und eine “hoch” mit 33,5% Redundanz. Nebenbei: selbst wenn diese Dateien gut sind, haben sie doch das Problem, dass man auch sie irgendwo sichern muss. Sinniger weise nicht auf der gleichen und eigentlich auch auf keiner anderen DVD, aber wo dann?

Nachdem ich auf die Art vom gleichen Image einige DVDs und CDs gebrannt hatte, fing ich an, mit einer Schere Kratzer auf die Unterseite zu machen. Die extreme dabei hab ich mal notiert

Fehlerverhalten bei Kratzern auf DVDs

Alle Typen verhalen sich gleich: +RW, -RW, +R, -R

4 Kratzer von der Mitte bis zum Außenrand
dvd-kratzer-3
Kein Schaden. Das kann die Fehlerkorrektur gut ab, scheinbar ist sie genau dafür da.
Ein 2cm Kratzer, fast mit der Spur
dvd-kratzer-1 4500 x 5 Sektoren kaputt. Das sind bei 2KB Sektorgröße 45MB, aber im Zweifel schon ein riesen Problem. Mit der normalen Checksummendatei ist es komplett restaurierbar. Anmerkung: auf dem Bild ist noch ein Kratzer zu sehen, den hatte ich später drau gemacht und weiter getestet. Der hatte keine weitere Auswirkung mehr.
6 Kratzer, davon 4 mit der Spur
dvd-kratzer-4
Die hälfte der Daten ist Defekt. Die hohe Checksummendatei hilft genauso wenig weiter wie die normale. Damit lassen sich noch ein paar Prozent retten, mehr aber nicht.
3 mal 1cm Kratzer innen fast am Loch und fast mit der Spur
dvd-kratzer-2
Die DVD lässt sich nicht mehr lesen, d.h. das Laufwerk will sie nicht mehr haben. Dementsprechend ein Totalverlust. Mit ein bisschen Rumprobieren hab ich es auch mit einem einzigen, 1cm langen Kratzer hinbekommen. Die Archillesferse der DVD. Da darf nix schief gehen.

Ich hab einige Rohlinge zerlegt und konnte immer nur wenige Kratzer hinterlassen, bevor nicht über 50% der Daten drauf gingen. Gab es einen kratzer in der mitte wurde die DVD oft nicht mehr als solche erkannt. Die Checksummendateien von DVDdisaster helfen bei kleinen Fehlern, aber ansonsten sind sie eher was zum Gewissen beruhigen als eine echte Hilfestellung.

Fehlerverhalten bei Kratzern auf CDs

Hier war ich ziemlich erstaunt. Ich fing vorsichtig an und mit jedem Kratzer gab es Fehler. Egal ob mit oder quer zur Spur. Die Fehler ließen sich mit den Checksummendateien nur ganz am Anfang nurtzbringend verwenden. Ab 4 Kratzern war es dann egal und es gab Datenverluste. Interessant fand ich nur, dass ich den Datenträger nicht zerstören konnte. Ich hinterließ 38 tiefe Kratzer mit bis 5cm länge, mit und quer zur Spur cd-kratzer-1. Auch so verteilt, dass sowohl ganz innen und ganz außen mit der Spur einiges zerkratzt war. Danach hatte ich weder Lust noch Kraft und außerdem irgendwie keinen Platz mehr auf der Oberfläche um noch was beschädigen zu können. Die CD war zu 95% nicht mehr lesbar, wurde aber noch korrekt als CD erkannt.

Fazit aus dem Kratzertest

DVDs sind gerade ganz innen tatsächlich extrem empfindlich. Fehler von innen nach außen sind gut abgefangen aber solche mit der Spur sind ein riesen Problem. Bei CDs sind Fehler immer ein Problem, aber es gibt keine besonders empfindlichen Stellen. Diese Info nützt, ganz allein für sich, gar überhaupt nichts. Im Zusammenhang ist es aber entscheidend. Dazu mehr im dritten Teil.

Und noch Abschließend, obwohl ich es oben schon erwähnt hatte: die ECC-Checksummendateien von dvddisaster sind wenig hilfreich. Eine sinnvolle Speicherlösung bringt da mehr.

Demnächst dann Teil 3 mit dem Langzeittest der Alterung von DVD- und CD-Rohlingen und dem abschließenden Fazit.

Abgelegt unter Technik | 1 Kommentar »

Backups, Teil 1: Datenverlust bei DVDs und Rettungsmöglichkeiten

Erstellt von Tobi am Mittwoch 27. Mai 2009

Vor einigen Jahren, so ungefähr als CD-ROM’s aufkamen, begann ich meine Daten auf die Silberschreiben als Backup zu brennen. Schon damals vertraute ich den Dingern wenig und legte immer gleich 2 gleiche an. Mit den Jahren verflog die Angst vor Datenverlust, weil ich keinerlei Probleme selbst mit 10 Jährigen CD-Rohlingen hatte. Als dann DVD’s erschwinglich wurden, übernahm ich das Vertrauen in die neuen Datenträger und benutzte ab dann diese für meine Backups. Das war ein Fehler, den ich bitter bereuhe und auch teuer bezahlt habe.

Das Problem

Insgesamt hatte ich über 2 1/2 Jahre hinweg, meine Backups sporadisch auf DVD’s verteilt, wie es halt gerade passte. Insgesamt haben sich 15 DVDs auf die Art angesammelt, die ich vor einiger Zeit dann mal sortieren und sauber archivieren wollte. Allesamt, ok bis auf eine, in der Hülle im Schrank aufbewahrt und ohne Kratzer, Staub oder sonstige Gebrauchsspuren. Beim Auslesen erhielt ich folgendes, niederschmetterndes Ergebnis:

2 DVDs komplett unbrauchbar
Eine lag für ca. eine Woche auf meinem Schreibtisch (Nordseite des Hauses) und war komplett ausgeblichen, da kann ich den Schaden ggf. noch verstehen, wenn auch nicht wirklich. Die andere war von einfach so kaputt, ohne verkratzt oder ausgeblichen zu sein. Kein Laufwerk konnte sie noch als DVD erkennen. Ein Totalverlust.
4 DVDs schwer beschädigt
Nicht verblichen und keine Kratzer zu sehen. Die äußeren Sektoren waren komplett im Eimer und auch in der Mitte gabs gute Fehlerstellen (woher ich die Fehlerstellen so genau weiß gibts weiter unten). Insgesamt waren ein paar 100MB weg.
6 DVDs leicht beschädigt.
Wieder trotz einwandfreihem Zustand. Hier gabs nur vereinzelte Feher, meißt am Außenrand
2 DVDs minimal beschädigt
Wieder ein super Zustand. Wenn ich sie nur “normal” ausgelesen hätte z.B. über die Dateiverwaltung, währen auch hier Fehler wie bei den 6 leicht beschädigten aufgetreten. Aber mit meinem Lebensretter-Tool konnte ich wenigsten die Daten komplett retten

Damit bleibt, nach Adam Riese, genau EINE komplett unbeschädigte DVD übrig. Da ich das Datum des Brennvorganges auf die DVD gekritzelt hatte, kann ich sagen, es hat sehr viel, wenn nicht alles, mit dem Alter der DVDs zu tun. Der Rohling-Typ war uninteressant, denn Vertreten sind die Marken Fujifilm, Tevion, Intenso und Octron und keiner der Rohlingtypen wurde von Fehlern verschont.

Die (teilweise) Rettung

Geholfen hat mir in erster Linie die Tatsache, dass meine Backups so verteilt und völlig unorganisiert waren. Dadurch waren viele Daten redundant und ich konnte so ca. 90% retten. Aber 10% Verlust, gerade bei z.B. alten Fotos, sind zu hart. Für weitere ca. 9% half mir das Linux-Tool dvddisaster. Die Idee dahinter ist so einfach wie genial. Man kann eine DVD einlesen und jeder einzelne, korrekt gelesene Sektor wird einem ISO-image auf der Platte hinzugefügt. Man kann dann das Image auf einen anderen Rechner legen und mit dessen Laufwerk das ganze nochmal versuchen. Sind dort Sektoren lesbar, die bisher noch fehlten, wird das ISO-Image aufgefüllt. Auf die Art kommt man schon recht weit.

Außerdem kann man das Laufwerk noch so ansteuern, dass die eingebaute Fehlerkorrektur umgangen und diese Arbeit vom Programm übernommen wird. Auch das hilft enorm. Auf diese Art konnte ich die 2 minimal beschädigten DVDs komplett und fehlerfrei auslesen. Mit den Einstellungen, jeden Sektor 10 mal zu lesen und die Fehlerkorrektur auf jede erdenkliche Art zu versuchen, kann man wirklich was erreichen. Das erkauft man sich aber durch sehr viel Zeit, denn meine schlimmste DVD brauchte ganze 1 1/2 Tage um ausgelesen zu werden. Leider nicht komplett fehlerfrei.

Besonders gut an dem Programm ist, dass man aus zwei oder mehr fehlerhaften DVDs eine ganze machen kann, vorausgesetzt man hat exakt gleiche Kopien einer DVD und die Fehler liegen nicht an den selben Stellen. Aber ich dachte ja, zumindest damals, dass Redundanz dieser Art nicht mehr nötig sei.

Der Verlust

Auf den 2 komplett unbrauchbaren DVDs war nur ein TV-Mitschnitt eines Konzertes und ein “bisschen” Musik. Beides ist nicht toll, aber verschmerzbar. Es hätte mich schlimmer erwischen können. Ansonsten fehlt mir nur ein 20KB großes Stück eines tgz-Archives, was gesamt 150MB groß ist. Das sind alle Bilder von vor 2002 die ich besitze. Man könnte denken, dann ist halt nur ein, maximal noch ein Zweites Bild im Archiv kaputt. Aber auch da war mir das Glück nicht hold.

Probleme mit Archiven

TGZ Archive sind scheinbar extrem FehlerINtolerant, denn ich kann die 500kb VOR der fehlerhaften Stelle entpacken, alles dahinter liegende nicht. Ich habe noch keine Möglichkeit gefunden, das zu Umgehen, hoffe aber noch auf eine Rettunng. Auf der Suche nach brauchbaren Alternativen bin nur über Gerüchte gestolpert, das RAR da besser sei. Das werd ich aber auch noch mal genauer testen.

Weiteres Vorgehen

Den Grund für die Ausfälle wollte ja schon herausfinden, also musste Ursachenforschung betrieben werden. Außerdem eine neue Lösung für Backups.

Da das Tool einem auch anzeigt, wo genau die fehlerhaften Sektoren auf der Oberfläche zu finden sind, zumindest kann man sehen, ob es eher im Innenbereich oder eben weiter außen Fehler gab, erhält man einen guten Überblick über den Zustand der DVD. Durch die Anzeige, wie schnell welcher Teil ausgelesen werden konnte, sieht man auch bei komplett fehlerfreihen DVDs und CDs, wie es um den Datenträger steht, da das Laufwerk langsamer wird, je problematischer der Lesevorgang war. Das war eine gute Grundlage, mal ein paar Tests mit den löchrigen Scheiben zu machen.

Folgende Dinge habe ich bereits durchgeführt und werde die Tage ausführlicher darüber berichten:

  • Ursachenforschung, warum DVDs so Probleme machen und ob und wie man die umgehen kann
  • Test der Fehlerkorrektur bei DVD und CD bei Kratzern.
  • Qualität der Checksummen-Dateien zur Fehlerkorrektur mit dvddisaster
  • Langzeittest der Alterungserscheinungen von DVD-ROM, DVD-RW und CD

Fazit

Backups IMMER redundant anlegen und DVD-ROM keinesfalls vertrauen. Da kann man auch gleich seine Daten in /dev/null schieben. Auch Archive oder Verschlüsselung bei Backups nicht verwenden, da die das Problem nur vergrößern. Lieber mehr Datenträger benutzen und die dann wegschließen. Und Teil 2 lesen :)

Abgelegt unter Technik | 3 Kommentare »