Da der alte Server mir doch zu anfällig wurde, ein Upgrade ansteht und das Ding doch recht klobig ist, habe ich mich entschieden die Hardware komplett umzustellen. Ich habe ein neues kleines Spielzeug als Server neu aufgesetzt und habe den Küchenserverblog rüberkopiert. Da ich keine Lust habe, movabletype zu migrieren und eigentlich eh was Neues machen wollte, wird  tobis-home.de eingestellt. Ich starte linuxhomeserver.de und notiere dort was ich mit dem kleinen Cubietruck so angestellt habe und anstellen werde.

vorerst manuell, später automatisch:

--->>> redirect --->>> linuxhomeserver.de

Kürzlich ist ja nun die Version 1.0 des vielbesagten Webserver-Beschleunigungs-Plugins mod-pagespeed ("Apache 2 module to optimize web content") herausgekommen. Ich hatte bei den Versionen unter der 1.0 immer noch das Nachsehen was den folgenden Fehler betrifft, doch nun muss ich raus damit.

"dpkg -l mod-pagespeed*" ausgeführt...aha, auf meinem Webserver läuft also aktuell das Paket mod-pagespeed- 1.0.22.7-r2003.

Nach dem Einloggen auf der Weboberfläche des Ampache Version 3.5.4 Stable ("Ampache is a web based audio/video streaming application") bekommt man folgende Fehlermeldung:

XML-Verarbeitungsfehler: nicht wohlgeformt
Adresse: http://www.myserverurl.tld/ampache-subfolder/index.php
Zeile Nr. 54, Spalte 188:<script type="text/javascript">Event.observe('play_type_select','change',function(e){Event.stop(e);ajaxPost('http://www.myserverurl.tld/ampache-subfolder/server/ajax.server.php?page=stream&action=set_play_type','play_type_form','play_type_select');});</script></form>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^

Hier ist das Modul mod-pagespeed beteiligt. Ohne jetzt großartig nach Fehlkonfigurationen für das Modul in Verbindung mit Ampache geforscht zu haben, schaltete ich es erst einmal ab.
Pagespeed abschalten mit:

$ sudo a2dismod pagespeed

Webserver neu starten mit :

$ sudo service apache2 restart

Nun bleibt es wohl erst einmal wieder abgeschaltet... neues Update, neue Chance!

p.s. Sicherlich kan das auch irgendwie an ampache liegen, nur ohne pagespeed läuft's ja!


Update:   mod-pagespeed-beta  1.1.23.1-r2169 funktioniert mit ampache auch nicht

Im Gegensatz zur Novemberinstallation läuft seit etwa einem Monat bei mir Google's mod-pagespeed im "produktiven" Einsatz. Es sind keine Auffälligkeiten zu erkennen. Alles stabil!

Zur Funktion, das heißt "Schnelligkeitszuwachs des Apachen", kann ich leider wenig Aussagen machen. Aber trotzdem eine winzige Neuentdeckung:

Beim heutigen Update des Paketes...

$ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb
$ sudo dpkg -i mod-pagespeed-*.deb
Vorbereiten zum Ersetzen von mod-pagespeed-beta 0.9.15.3-r404 (durch mod-pagespeed-beta_current_i386.deb) ...
Entpacke Ersatz für mod-pagespeed-beta ...
Richte mod-pagespeed-beta ein (0.9.16.3-r534) ...

... ist nur eines aufgefallen:

Die Installation des .deb-Paketes erzeugt ein Paket-Quelleneintrag in der Datei

/etc/apt/sources.list.d/mod-pagespeed.list
_______________________________________________________________
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb http://dl.google.com/linux/mod-pagespeed/deb/ stable main
_______________________________________________________________

Vielen Dank Google, dass ihr Euer Programm auf meinen Server so "very convenient" aktuell halten möchtet. Ich hätte doch lieber gern einen Hinweis bei der Installation bekommen.

Nun gut sei es drum. Nun weiß ich es ja.
Die Pakete sind anscheinend auch noch nicht in der Quelle hinterlegt, heißt ja auch "stable". Ansonsten hätte das heutige Update ja keinen "Versiönchen"-Sprung angezeigt.


Na dann vielen Dank an die fleißigen Programmierer. Einer mehr testet mal das pagespeed-beta....
...ich weiß bisher nur noch nicht, ob es was bringt (und wie ich es vernunftbegabt testen kann)!

Update:

Heute sendete mir der apticron-Dienst meines Servers folgende Mail:

apticron report [Wed, 16 Mar 2011 23:48:18 +0100]
========================================================================

apticron has detected that some packages need upgrading on:

        www.tobis-home.de
        [ 123.456.7.8 ]

The following packages are currently pending an upgrade:

        mod-pagespeed-beta 0.9.16.9-r576

========================================================================

Damit ist klar, dass die Paketquelle vom mod-pagespeed "stable" auch für die Betaversion funktioniert.

Mit der Einwilligung zum Update: $ sudo apt-get dist-upgrade
ist nun die aktuelle Version installiert. Bisher gibt es keine Probleme damit!


Update2:

apticron report [Mon, 16 May 2011 23:48:21 +0200]
========================================================================

apticron has detected that some packages need upgrading on:

        www.tobis-home.de
        [ 123.456.7.8 ]

The following packages are currently pending an upgrade:

        mod-pagespeed-beta 0.9.17.6-r698

========================================================================


auch installiert!

Update3

apticron report [Thu, 19 May 2011 23:48:21 +0200]
========================================================================

apticron has detected that some packages need upgrading on:

        www.tobis-home.de
        [ 123.456.7.8 ]

The following packages are currently pending an upgrade:

        mod-pagespeed-beta 0.9.17.7-r716

========================================================================

läuft jetzt!
Das ServicePack 1 vom Windows 7 wollte installiert werden, und ich war selbst spät abends auch noch gewollt dieses zu erlauben... aber seht selbst!


80010108.jpg


Achje, ein Fehler! Der Schreck war nicht groß, nach dem erwähnten Backup-Error 0x81000019 hatte ich ja da noch eine Idee, auf die ich wohl ohne den vorangegangenen Fehler nie gekommen wäre.
Aber so war das ein Kinderspiel:


Voraussetzung 1:
(wie bei meinem System)

  • Windows-HDD selbst bootfähig oder anderer Bootloader drauf installiert (z.B. GRUB):
==> Im BIOS Windows-Platte als 1. Boot-Platte einstellen => ServicePack installieren!

Voraussetzung 2:

  • Windows-HDD nicht selbst bootfähig, GRUB auf anderer Platte=Bootplatte
  • +Versuch von 1. war weiterer Fehlschlag
==> Master-Boot-Record der Windows-Platte wieder flottmachen und von da starten
      - von Win7-CD starten -> Repair -> System-Recovery-Options: Command-Prompt
      - Eingabe: bootrec /rebuildbcd
                      bootrec /fixboot
                      bootrec /fixmbr
ODER
==> Master-Boot-Record der Windows-Platte auf vorhandenen GRUB zeigen lassen
      - Linux booten
      - Grub in vorhandenes Root-Verzeichnis schreiben + MBR auf Win7-Platte (hier: /dev/sdb)
      - Terminal-Eingabe: sudo grub-install /dev/sdb

DANACH
==> Nicht vergessen die Windows-Platte im BIOS als 1. Boot-Platte einzustellen!

Das Ergebnis sieht dann hoffentlich so aus:

win7sp1success.jpg


Viel Erfolg - Tobi

Bisher führte ich die Backups immer manuell aus: Platten gemounted, Grsync gestartet und beim voreingestellten Profil auf Ausführen gedrückt. Von einer gewissen Regelmäßigkeit war da nicht zu sprechen.

Es wäre möglich, das in Linux eingebaute cron zu nutzen. Für einen Desktop-Rechner ist der Cron-Job jedoch auch keine Alternative. Zur eingestellten Update-Zeit ist der Rechner möglicherweise nur an 1 von 7 Tagen wirklich eingeschaltet.

Hier kommt anacron ins Spiel. Mit anacron ist es möglich, mit einer gewissen Verzögerung nach dem Programmaufruf eine Aktion auszuführen. Den Programmaufruf von anacron wollte ich idealerweise nach dem Einloggen auslösen, sodass das Backup nach ca. 5 Minuten startet. Das Backupscript selbst wird dann von anacron aufgerufen.

Nachfolgend werden die beiden Stufen "Programmaufruf über anacron" und "Backupscript" beschrieben.

Sollte man jedoch wünschen, dass die externe Platte das Backup selbst ausführt, macht sich autorun ganz gut. Beim Einstecken des USB-Devices kann das Backup ausgelöst werden.

Umgekehrt ist es auch ganz praktisch, das Backup eines USB-Sticks auf eine lokale Platte zu starten

Die sehr praktische Backup-Funktion über autorun erläutere ich im dritten Abschnitt.


Terminaleingaben wie folgt: (# = Kommentare, $ = Terminal-Eingabezeilen, alles andere = Terminal-Ausgaben)


1.) Programmaufruf über anacron


### anacron installieren (falls noch nicht vorhanden)
$ sudo apt-get install anacron
### anacron für user "test" konfigurieren (s. auch INFO)
$ sudo groupadd anacron
$ sudo adduser test anacron
$ sudo chown root.anacron /var/spool/anacron
$ sudo chmod g+w /var/spool/anacron
### info-files anlegen (spool)
$ touch /var/spool/anacron/test.anacron.daily
$ touch /var/spool/anacron/test.anacron.weekly
$ touch /var/spool/anacron/test.anacron.monthly
### Rechte vergeben
$ chown root.anacron /var/spool/anacron/test.*
$ sudo chmod g+w /var/spool/anacron/test.*
$ sudo chmod g+r /var/spool/anacron/test.*
### INFO das Spool-Verzeichnis/Dateien des Users kann auch ins $Home verlegt werden
### hierzu muss der anacron-Start (s. unten) wie folgt erfolgen:
### /usr/sbin/anacron -s -S $HOME/.etc/anacron_spool/ -t $HOME/.etc/anacrontab
### Das selbst gewählte Verzeichnis bitte vorher anlegen!
### Für diesen Fall sind nur die nachfolgenden Arbeitsschritte notwendig:
### ---------------------------------------------------------------------------------------------------
### test's anacron im Home-Verzeichnis verankern (Verzeichnis ~/.etc nur beispielhaft benutze ich aber so)
$ mkdir $HOME/.etc/anacron.daily
$ mkdir $HOME/.etc/anacron.weekly
$ mkdir $HOME/.etc/anacron.monthly
### anacrontab anlegen
$ touch $HOME/.etc/anacrontab
### anacrontab bearbeiten: mit mcedit ,auch gedit etc. möglich
$ mcedit $HOME/.etc/anacrontab
________________ INHALT  $HOME/.etc/anacrontab______________
# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# period  delay  job-identifier  command
# 5 min daily, 10 min weekly, 15 min monthly
1       5       test.anacron.daily    nice run-parts --report $HOME/.etc/anacron.daily
7      10       test.anacron.weekly   nice run-parts --report $HOME/.etc/anacron.weekly
30     15       test.anacron.monthly  nice run-parts --report $HOME/.etc/anacron.monthly
_______________ENDE INHALT $HOME/.etc/anacrontab ___________


Script-Dateien, die man in den .daily/.weekly/.monthly-Verzeichnissen ablegt werden nach dem Start von anacron jeweils täglich/wöchentlich/monatlich gestartet.

Erst nach dem eigentlichen Start von anacron wird das Backup gestartet.

  • Der Start kann über eine crontab-Eintrag stattfinden:
### crontab editieren
$ crontab -e
_______________ eintragen ______________________
@reboot    /usr/sbin/anacron -t $HOME/.etc/anacrontab
______________________________________________

  • ODER: anacron nach Login über "Startprogramme" starten
Bildschirmfoto-Startprogrammeinstellungen.png

Der Eintrag wird über "hinzufügen" erstellt:
Bildschirmfoto-Startprogramm bearbeiten.png

Der folgende Eintrag startet anacron des Users "test" nach dem Login:

/usr/sbin/anacron -t /home/test/.etc/anacrontab


2.) Backupscript

Welche Dateien lege ich jetzt in meine anacron.daily/.weekly/.monthly-Verzeichnisse?

Ein Problem ist manchmal schon, die Platte ohne admin-Rechte (root) zu mounten (einhängen). Das folgende Beispiel hängt die Platte mit dem Label "raidstor" ein und sichert das Home-Verzeichnis des users "test" komplett in das Unterverzeichnis BACKUP/home der Platte. (Der Username test muss natürlich ersetzt werden)

HINWEIS: Ich habe das nur mit Linux-Dateisystemen benutzt (ext2/ext3/ext4). Für NTFS-Platten könnten zusätzliche Optionen für rsync notwendig werden.

Benötigte Pakete: libnotify-bin gvfs-bin
# Pakete installieren
$ sudo apt-get install libnotify-bin gvfs-bin

______________ file: $HOME/.etc/anacron.daily/localbackup_______________
#!/bin/sh

startmessage='Es wird eine Sicherung auf raidstor durchgeführt.'
midmessage='Der Computer darf während dieses Vorgangs nicht heruntergefahren werden!'
finishmessage='Die Sicherung ist abgeschlossen!'

notify-send -u normal -t 3 -i /usr/share/icons/grsync.png "$startmessage"
#MOUNTEN
gvfs-mount -d `readlink -f /dev/disk/by-label/raidstor`
sleep 2
notify-send -u normal -t 3 -i /usr/share/icons/gnome/scalable/status/dialog-warning.svg "$midmessage"
##BACKUP ausführen
rsync -ax --delete --delete-excluded --exclude=.gksu.lock --exclude=.thumbnails /home/test /media/raidstor/BACKUP/home
##BACKUP beenden
notify-send -u normal -t 3 -i /usr/share/icons/gnome/scalable/emblems/emblem-default.svg "$finishmessage"
______________________________________________________________________________________________


3.) Sicherung mittels autorun: Beispiel extern -> local


Das autorun-Script kann auf der zu externen Platte selbst gespeichert werden und mittels autostart wird das Backup ausgelöst. Hervorragend für USB-Sticks oder externe Festplatten.

Das Backup startet im Beispiel von einer externen (USB-)Platte KEYLINUX und sichert auf raidstor. Der umgekehrte Fall ist sicherlich auch möglich. Hierzu muss das Script nach dem Beispiel aus 2.) modifiziert werden.

Schreibrechte des Users auf dem Ziel bzw. Leserechte auf dem Stick sind von Vorteil!

HINWEIS: Ich habe das nur mit Linux-Dateisystemen benutzt (ext2/ext3/ext4). Für NTFS-Platten könnten zusätzliche Optionen für rsync notwendig werden.

Benötigte Pakete: libnotify-bin gvfs-bin
# Pakete installieren
$ sudo apt-get install libnotify-bin gvfs-bin

### Platte anstecken und per Nautilus einhängen
(#manuell einhängen)$ gvfs-mount -d `readlink -f /dev/disk/by-label/KEYLINUX`
$ cd /media/KEYLINUX
### Script-Datei anlegen (mit Users-Rechten, für root sudo benutzen -> $ sudo touch .autorun)
### Alternativ geht auch autorun.sh oder autorun (Vorteil .autorun ist versteckt)
$ touch .autorun
### Start-Rechte vergeben für user
$ chmod u+x .autorun
### alternativ: Start-Rechte vergeben für Gruppe
$ chmod g+x .autorun
### alternativ: Start-Rechte vergeben für alle
$ chmod a+x .autorun
### Script-Datei mir mcedit bearbeiten (oder auch Editoren wie "gedit" etc. möglich)
$ mcedit .autorun
__________________________ file: .autorun ________________________________
#!/bin/sh
startmessage='Sicherung von KEYLINUX auf raidstor wird durchgeführt.'
midmessage='KEYLINUX darf während dieses Vorgangs nicht getrennt werden!'
finishmessage='Die Sicherung von KEYLINUX ist abgeschlossen!'

notify-send -u normal -t 3 -i /usr/share/icons/grsync.png "$startmessage"
#raidstor MOUNTEN
gvfs-mount -d `readlink -f /dev/disk/by-label/raidstor`
sleep 2
notify-send -u normal -t 3 -i /usr/share/icons/gnome/scalable/status/dialog-warning.svg "$midmessage"
##BACKUP als user ausführen (nur mit entsprechenden Rechten)
rsync -ax --delete /media/KEYLINUX /media/raidstor/BACKUP
##BACKUP als root ausführen (Zeile ändern)
## gksudo "rsync -ax --delete /media/KEYLINUX /media/raidstor/BACKUP"
##BACKUP beenden
notify-send -u normal -t 3 -i /usr/share/icons/gnome/scalable/emblems/emblem-default.svg "$finishmessage"
_____________________________________________________________________

Beim Anstecken des USB-Devices erscheint nun folgende Nachricht:

Bildschirmfoto-KEYLINUX.png

Nach dem Klick auf OK, wird das Vertrauen des Scriptes eingefordert und los gehts...

Es war einmal wieder soweit: Ich wollte ein Windows-Backup machen.

Externe Platte mit NTFS angeschlossen und aufs Knöpfchen gedrückt -> "Systemsteuerung\Alle Systemsteuerungselemente\Sichern und Wiederherstellen" -> "Jetzt sichern"

Oh Schreck was nun! Ein Fehler: Fehlercode 0x81000019, ohne aufschlussreiche Erklärung.
(Hier ein Bild des reproduzierten Fehlers: Lösung unten.)

Fehlercode: 0x81000019Am Betriebssystem hatte ich nix verändert, benutze das Windows doch nur zum Spielen. Die Suche im Netz war nahezu erfolglos. Viele Foren mit massig Einträgen halfen nicht weiter. Speicherplatz frei machen half nix, hatte noch 100GB frei, warum auch! Beim Umstellen des Backup "ohne Systemabbild" gab's einen anderen Fehler (0x80070002). Ein Plattentest zeigte keine Fehler und brachte keine Besserung.

Ich fand nur: Die Dienste VSS und SPP sind irgendwie Schuld... naja das war nix Neues.

Meine Ereignisanzeige und die Fehlermeldung hatten mir das auch schon verraten:

Ereignisanzeige Backup Error

Die vier Ereignisse künden vom Backup-Error um 21:51:22.

Die Ausgaben der Ereignisse habe ich hier einmal aufgeführt:

1.) Event 8193


Protokollname: Application
Quelle:        VSS
Datum:         10.11.2010 21:51:25
Ereignis-ID:   8193
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Volumeschattenkopie-Dienstfehler: Beim Aufrufen von Routine "IVssAsrWriterBackup::GetAsrMetadata" ist ein unerwarteter Fehler aufgetreten. hr = 0x80042416, Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt.
.

Vorgang:
   PrepareForBackup-Ereignis

Kontext:
   Ausführungskontext: ASR Writer
   Ausführungskontext: Writer
   Generatorklassen-ID: {be000cbe-11fe-4426-9c58-531aa6355fc4}
   Generatorname: ASR Writer
   Generatorinstanz-ID: {2b66ed38-cb27-4d0c-ab43-e627131ed2ca}

Fehlerspezifische Details:
   ASR Writer: Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt. (0x80042416)

2.) Event 12290

Protokollname: Application
Quelle:        VSS
Datum:         10.11.2010 21:51:25
Ereignis-ID:   12290
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Volumeschattenkopie-Dienstwarnung: ASR writer Error 0x80042416. hr = 0x00000000, Der Vorgang wurde erfolgreich beendet.
.

Vorgang:
   PrepareForBackup-Ereignis

Kontext:
   Ausführungskontext: ASR Writer
   Ausführungskontext: Writer
   Generatorklassen-ID: {be000cbe-11fe-4426-9c58-531aa6355fc4}
   Generatorname: ASR Writer
   Generatorinstanz-ID: {2b66ed38-cb27-4d0c-ab43-e627131ed2ca}

Fehlerspezifische Details:
   ASR Writer: Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt. (0x80042416)

3.) Event 16387


Protokollname: Application
Quelle:        SPP
Datum:         10.11.2010 21:51:25
Ereignis-ID:   16387
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Fehler beim Erstellen von Schattenkopien, da ASR Writer einen Fehler gemeldet hat.  Weitere Informationen: Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt. (0x80042416).

4.) Event 4100 (Windows Backup)

Protokollname: Application
Quelle:        Windows Backup
Datum:         10.11.2010 21:51:25
Ereignis-ID:   4100
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Die Sicherung wurde nicht erfolgreich abgeschlossen, da eine Schattenkopie nicht erstellt werden konnte. Löschen Sie auf dem zu sichernden Laufwerk nicht benötigte Dateien, um Speicherplatz freizugeben, und wiederholen Sie den Vorgang.


Lösung:

Windows ist nur mein Zweit-Betriebssystem, daher läuft GRUB als Bootloader. Da ich kürzlich eine neue Festplatte eingebaut hatte, benutze ich nun die Neue als Bootlaufwerk. Der GRUB musste auch mit umziehen.

Nun ist es so, dass die neue Platte (SSD) im BIOS als 1. Bootplatte eingerichtet ist.
Windows und die Partition mit dem Windows-Bootloader sind auf dem "alten" RAID nur in zweiter Reihenfolge.

Das Backupsystem scheint also mit der Umstellung der 1. Bootplatte im BIOS ein Problem zu haben. Die Windows-System-Platte (bzw. Windows-Bootloader) müssen im BIOS an erster Bootreihenfolge stehen.

Ein Versuch gab mir Recht: Kurzerhand stellte ich die Windows-Platte im BIOS als HDD1 ein. Backup angeworfen: Läuft wieder ohne Fehler!

Glücklicherweise hatte ich die alte GRUB-Partition auf der Windows-Platte nicht gelöscht. GRUB und Windows-Backup schließen sich also nicht aus. Der GRUB muss nur auf dem gleiche Laufwerk wie der Windows-Bootloader (vielleicht auch Windows-System) liegen.

So, inzwischen ist das Backup beinahe fertig. Und ich überlege mir, ob ich meine alte GRUB-Partition auf dem Windows-RAID nicht wieder standardmäßig wegen den Win7-Backup-Bugs in Benuzung nehme.

Update: Wer GRUB (Version 1) benutzt, kann in der menu.lst den Eintrag "makeactive" ergänzen und schon klappt's wieder (s. auch Kommentare). Bei Grub2 ist das etwas schwieriger. Hier muss vor den chainload-Eintrag ein "parttool hd0,3 boot+" (in dem Fall erste Platte (0), dritte Partition (3)).

Heute hat Google den Webserver-Mod mod_pagespeed als Open Source freigegeben. Das musste ich gleich mal ausprobieren. Da mein Upload für den Webserver nicht allzu üppig ist, wäre das ja eine super Alternative.

Herunterladen+Installieren:

ich habe das heute freigegebene fertig kompilierte Paket installiert, das hier zu finden ist:

http://code.google.com/intl/de-DE/speed/page-speed/download.html

Terminaleingaben wie folgt: (# = Kommentare, $ = Terminal-Eingabezeilen, alles andere = Terminal-Ausgaben)

$ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb
$ sudo dpkg -i mod-pagespeed*.deb

Entpacke mod-pagespeed-beta (aus mod-pagespeed-beta_current_i386.deb) ...
Richte mod-pagespeed-beta ein (0.9.0.0-r128) ...
Enabling module pagespeed.
Run '/etc/init.d/apache2 restart' to activate new configuration!

$ sudo apt-get -f install
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Status-Informationen einlesen... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

$ sudo /etc/init.d/apache2 restart
 * Restarting web server apache2
 ... waiting

--> so, nun isses fertig!

Konfigurieren:

In der Datei /etc/apache2/mods-available/pagespeed.conf  kann man noch Einiges konfigurieren. Mich hat hier lediglich der Zugriff auf die Statistiken interessiert. Sonst habe ich die Voreinstellungen belassen.

Ich habe den letzten Abschnitt angepasst, der wie folgt aussieht:

   <Location /mod_pagespeed_statistics>
        Order allow,deny
        # You may insert other "Allow from" lines to add hosts you want to
        # allow to look at generated statistics.  Another possibility is
        # to comment out the "Order" and "Allow" options from the config
        # file, to allow any client that can reach your server to examine
        # statistics.  This might be appropriate in an experimental setup or
        # if the Apache server is protected by a reverse proxy that will
        # filter URLs in some fashion.
        #Allow from localhost
        Allow from 192.168.1.0/24
        SetHandler mod_pagespeed_statistics
    </Location>

Die fett markierte Zeile hat meinem Desktop-Rechner Zugriff auf die mod_pagespeed-Statistiken des Servers verschafft. Mit der Eingabe http://[meine-domain oder Server-IP]/mod_pagespeed_statistics  im Browser konnte ich mir die Aktivitäten anschauen. Das sah so aus:

resource_fetches: 0
total_page_load_ms: 0
page_load_count: 0
cache_extensions: 0
not_cacheable: 0
css_file_count_reduction: 0
css_filter_files_minified: 0
css_filter_minified_bytes_saved: 0
css_filter_parse_failures: 0
css_elements: 0
image_inline: 0
image_rewrite_saved_bytes: 0
image_rewrites: 0
javascript_blocks_minified: 0
javascript_bytes_saved: 0
javascript_minification_failures: 0
javascript_total_blocks: 0
url_trims: 0
url_trim_saved_bytes: 0
resource_404_count: 0
slurp_404_count: 0
serf_fetch_request_count: 0
serf_fetch_bytes_count: 0
serf_fetch_time_duration_ms: 0
serf_fetch_cancel_count: 0

Nach einigem Rumklicken auf den Webseiten zählten die Zahlen fleißig immer höher. Das Verzeichnis /var/mod_pagespeed wurde mit vielen zwischengespeicherten Dateien gefüllt. Alles toll schnell?

Nicht so ganz: Mein indianischer Webserver hat da den einen oder anderen, großen oder auch kleinen Hänger gezeigt. Es fing mit kurzen Verzögerungen an, auch Reload-Versuche mit F5-gedrücke ohne Erfolg.

Insgesamt lief das mod bei mir etwas mehr als 4 Stunden (ab 15 Uhr) ohne mein Dazutun. Danach habe ich viel rumprobiert und auch den Server genutzt. Die Aktivitäten sind natürlich in die Höhe geschnellt. Ich habe den Apachen ab 21 Uhr auch hin und wieder neu gestartet, deshalb die Einbrüche. Anhand der folgenden Munin-Plots kann man den Einfluss des pagespeed-mods deutlich erkennen.

Der helle Bereich zeigt den Zeitraum, in dem mod_pagespeed aktiv war.

apache_accesses-day.jpgapache_activity-day.jpgapache_processes-day.jpgcpu-day.jpgmemory-day.jpgprocesses-day.jpgDie Plots für Memory und CPU zeigen keine deutlichen Anstiege. Die Apache-Aktivität, sowie auch dessen Prozesse steigen kontinuierlich im Quasi-Leerlauf.

Abschließend habe ich den mod wieder deaktiviert, da er statt pagespeed nur pagebrake war.

$ sudo a2dismod pagespeed

Die Verzögerungen können sicherlich auch an meinem 1GHz-Server liegen, obwohl die Auslastungsdaten etwas anderes zeigen. Vielleicht ist der Kleine ja wirklich zu lahm für solch tolle Bandbreiteneinsparungen=Komprimierungen. Nur ist für mich fraglich, wie da die Verhältnismäßigkeiten sind. Brauche ich da viel Rechenpower um etwas Bandbreite einzusparen? Bringt das nur was, wenn viele Anfragen auf die einmal komprimerten Daten kommen? Was ist, wenn sich an meinem Output laufend was ändert? Oder ist der mod_pagespeed einfach nur total verbuggt?

Fragen über Fragen! ...is ja auch die beta-Version und vielleicht muss ich mich auch mehr in die Konfiguration einlesen - aber ich versuche es dann mal mit einer späteren Version aus. Danke Google!

Welch einen wunderschönen deutschen Namen gibt Ubuntu's Laufwerksverwaltung (palimpset) meinem frisch eingebauten Solid-State-Drive: Festkörperlaufwerk.
Zusammengesetzte Substantive sind etwas Wunderbares.


Ich hatte mich nun endlich entschieden: Eine OCZ Vertex2 E mit 120GB musste her. Nach dem Auspacken ging ich sofort zum Einbau mit anschließenden Speedtest über. Ihr werdet sehen:

Auspacken und Einbau:


01_von_aussen.jpg
Das Auspacken ist unspektakulär, schön für Desktopuser ist der mitgelieferte Einbaurahmen.

02_geoeffnet.jpg03_ausgepackt.jpg04_device.jpg

Der Einbau ist sicherlich auch keine Wunderleistung der Ingenieurkunst. Das 2.5"-Format lässt den benachbarten Platten noch schön viel Luft.
05_eingebaut.jpgNach dem Verstöpseln und dem mit Spannung erwarteten Erkennen des Laufwerks konnten die Tests beginnen.
Device Infos:

$ sudo smartctl -i /dev/sda
Device Model:     OCZ-VERTEX2
Serial Number:    OCZ-1600Y229CVXXXXXX
Firmware Version: 1.23
User Capacity:    120.034.123.776 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Not recognized. Minor revision code: 0x28
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Das Testen:

Hier seht ihr die Übersicht von Ubuntus Laufwerksverwaltung "palimpset".

Bildschirmfoto-120 GB Festkörperlaufwerk (ATA OCZ-VERTEX2) [-dev-sda] -- Laufwerksverwaltung.pngEin Klick auf den Button "Smart-Werte" brachte Folgendes zum Vorschein:

Bildschirmfoto-120 GB Festkörperlaufwerk (ATA OCZ-VERTEX2) - SMART-Werte.pngBildschirmfoto-120 GB Festkörperlaufwerk (ATA OCZ-VERTEX2) - SMART-Werte-1.png

Nun gut, die SMART-Infos sind eher spärlich gesäht. Dieses System ist allerdings auch für sich bewegende Platten geschaffen und nicht für mein neu erstandenes Festkörperlaufwerk ;o)

Die Geschwindigkeitswerte im RAW-Mode sind erstaunlich. Ohne Formatieren bzw. Partitionieren geht's da richtig ab. Die Herstellerangaben werden sogar beinahe eingehalten.

Bildschirmfoto-120 GB Festkörperlaufwerk (ATA OCZ-VERTEX2) - Vergleichstest.png
Nach dieser Aktion ging ich über, mit meinem Ubuntu "Lucid Lynx" mal flugs auf die SSD umzuziehen.

Die Partitionierung sollte man möglich knauserig vornehmen. Ich gönnte mir eine 500MB Boot-Partition. Den Rest der 120GB packte ich in eine root-partition. Den Speicherbereich für Auslagerungsdaten sollte man von einer SSD fernhalten. Die Swap-Partition blieb auf meinem RAID-System. Mit einer Live-CD machte ich eine Kopie meines Produktivsystems einschließlich meines /home-Verzeichnisses. Die Boot-Partition wurde mit dem Befehl grub-install (hier nachzulesen) gefüllt und aktiviert.

Ein erfolgreiches Booten war Pflicht, um einen Speedtest an der laufenden Installation durchzuführen:

Bildschirmfoto-120 GB Festkörperlaufwerk (ATA OCZ-VERTEX2) - Vergleichstest-nach-Installation.pngHier sind nun schon einige Unterschiede zum RAW-Test zu erkennen. Allein die mittleren Zugriffszeiten streuen jetzt nicht mehr so stark (man beachte den anderen Maßstab), sind aber im Mittel jetzt bei 0.2 ms. Die Leserate ist deutlich abgesackt.

Die Tests im laufenden Betrieb streuen etwas. Ein späterer Test, mit ausgewählt besseren Werten, ist hier zu sehen:

Bildschirmfoto-120 GB Festkörperlaufwerk (ATA OCZ-VERTEX2) - Vergleichstest-latest.pngWie Euch in der Übersicht der Speichergeräte vielleicht nicht entgangen ist, habe ich auch noch zwei Vergleichslaufwerke im Rechner eingebaut. Im rein synthetischen Vergleich der Speedtests mit den Platten meines Hardware-Raid-Controllers (3ware 9650SE-4LP), ist die SSD klar überlegen.... aber seht selbst:

RAID-0 mit 2x1TB Samsung@7200rpm (Standard Desktop Platten): Device Info
$ sudo smartctl -i --device=3ware,0 /dev/twa0
Device Model:     SAMSUNG HD103UJ
Serial Number:    S13PJXXXXXXXXX
Firmware Version: 1AA01113
User Capacity:    1.000.204.886.016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 3b

$ sudo smartctl -i --device=3ware,1 /dev/twa0
Device Model:     SAMSUNG HD103UJ
Serial Number:    S13PJ1XXXXXXXX
Firmware Version: 1AA01113
User Capacity:    1.000.204.886.016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 3b

Bildschirmfoto-2,0 TB Festplatte (AMCC 9650SE-4LP DISK) - Vergleichstest.pngBildschirmfoto-2,0 TB Festplatte (AMCC 9650SE-4LP DISK) - Vergleichstest-1.png
RAID-0 2x2TB Western Digital@5400rpm (Server Platten): Device Info
$ sudo smartctl -i --device=3ware,2 /dev/twa0
Device Model:     WDC WD2002FYPS-01U1B1
Serial Number:    WD-WCAVY15XXXXX
Firmware Version: 04.05G05
User Capacity:    2.000.398.934.016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated

$ sudo smartctl -i --device=3ware,3 /dev/twa0
Device Model:     WDC WD2002FYPS-01U1B1
Serial Number:    WD-WCAVY15XXXXX
Firmware Version: 04.05G05
User Capacity:    2.000.398.934.016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated

Bildschirmfoto-4,0 TB Festplatte (AMCC 9650SE-4LP DISK) - Vergleichstest.pngDeutlich zu erkennen, dass der interne Speicher (cache) der Serverplatten beim Ergebnis hin und wieder ordentlich reinhaut. Die Samsung-Desktopplatten zeigen diesen Effekt nicht. Daher muss davon ausgehen, dass der RAID-Controller nicht Schuld ist.

Bildschirmfoto-4,0 TB Festplatte (AMCC 9650SE-4LP DISK) - Vergleichstest-1.pngBildschirmfoto-4,0 TB Festplatte (AMCC 9650SE-4LP DISK) - Vergleichstest-2.png
Der Cache bringt insbesondere den Serverplatten nur einen kurzen Schub, deshalb kann man die maximalen Lesegeschwindigkeiten getrost ausklammern. Der Effekt ist zwar da, ich kann aber nur schwer einschätzen ob er etwas bringt.

Interessant am letzten Teil meines SSD-Berichts ist eigentlich der direkte Plattenvergleich 7200 vs. 5400 rpm (Umdrehungen/min). Die SSD ist den Werten nach deutlich vorn.

HDPARM-Test:

$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   8482 MB in  2.00 seconds = 4243.98 MB/sec
 Timing buffered disk reads:  404 MB in  3.01 seconds = 134.12 MB/sec

$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   8886 MB in  2.00 seconds = 4446.25 MB/sec
 Timing buffered disk reads:  674 MB in  3.00 seconds = 224.48 MB/sec

$ sudo hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads:   9036 MB in  2.00 seconds = 4521.76 MB/sec
 Timing buffered disk reads:  650 MB in  3.00 seconds = 216.32 MB/sec


So, nun könnt ihr mal raten, welche Platte(n) sda sdb oder sdc sind.

Das Ausschlusskriterium gibt Euch Recht. SDA muss mein neues Festkörperlaufwerk sein. Ist So: Hier spielen die Buffer des 3ware-RAID-Controllers wohl ihre Stärken aus.


Subjektive Beurteilung:

Der gefühlte Geschwindigkeitsgewinn ist lediglich beim Programmstart auszumachen. Beim Booten spielt offenbar der CPU auch noch eine wichtige Rolle bzw. ist der Datendurchsatz der SSD im Vergleich zum Hardware-RAID-0 nicht allzu viel höher.

Ubuntu hat mit dem Samsung-RAID in ca. 23s bis zum Login gebootet. Die SSD braucht nun ca. 20s.

Die Festplatten (raid) gingen vor allem bei einem Parallelstart von virtuellen Maschinen in die Knie. Ein gleichzeitiger Start von Ubuntu und Windows hatte ein längeres Warten zur Konsequenz. Mit der SSD ist dieser Zustand Geschichte. GIMP oder Firefox sind prompt da. Nach dem Login bis zum "fertigen" Desktop geht es spürbar schneller. Der Geschwindigkeitsgewinn ist schon spürbar.

Fazit:

Die Anschaffung hat sich für mich schon gelohnt. Wer allerdings mehr Wert auf viel Speicherplatz legt, sollte lieber in einen vernünftigen Hardware-RAID-Controller investieren.

Beim Kopieren von großen Datenvolumen sind sicherlich die RAID-Laufwerke die Bremse, jedoch kann ich auf diese nur große Daten kopieren. Die Kopiererei von SSD zu SSD wäre sicherlich schneller. Aber bisher sind die größeren Exemplare dieser Gattung unerschwinglich und meiner Meinung nach auch unnötig, da der Vorteil einer SSD im Vergleich zu einem vernünftigen RAID-System nur in Extremsituationen merkbar ist. Schlichtweg im Desktop-Rechner eine Sache für Nerds... im Mobilbereich bestimmt eine Revolution.

Update:


Letzlich kopierte ich eine 5,5GB große Datei von meinem Desktop (Festkörperlaufwerk) auf eine raid-Partition. Die Übertragungsrate pendelte sich so bei 70-80MB/s ein: Das kann doch nicht sein, dachte ich. Ein nachfolgender Test von raid-zu-raid war etwa doppelt so schnell. (Hab's leider nicht dokumentiert.)

Das veranlasste mich zu einem erneuten Test mit der gleichen Datei, wobei ich die Werte leider nicht reproduzieren konnte. Eventuell lief da noch etwas im Hintergrund. Trotzdem sehr interessant.

Dateisysteme bei allen Laufwerken sind: ext4

(Ist klar: Der Balken symbolisiert lediglich den Kopierfortschritt!)

Festkörperlaufwerk (Desktop) ==> WD-Raid@5400rpm (raidstor)

Bildschirmfoto-Dateioperationen-Desktop-Raidstor.pngFestkörperlaufwerk (Desktop) ==> Samsung-Raid@7200rpm (Videos)

Bildschirmfoto-Dateioperationen-Desktop-Videos.png
WD-Raid@5400rpm (raidstor) ==> Festkörperlaufwerk (Desktop)

Bildschirmfoto-Dateioperationen-Raidstor-Desktop.pngWD-Raid@5400rpm (raidstor) ==> Samsung-Raid@7200rpm (Videos)

Bildschirmfoto-Dateioperationen-Raidstor-Videos.pngSamsung-Raid@7200rpm (Videos) ==> Festkörperlaufwerk (Desktop)

Bildschirmfoto-Dateioperationen-Videos-Desktop.pngSamsung-Raid@7200rpm (Videos) ==> WD-Raid@5400rpm (raidstor)

Bildschirmfoto-Dateioperationen-Videos-Raidstor.png Naja, ich brauche da nicht zu viel Worte zu verlieren, hier ist eine Übersichtstabelle.

Quelle  /  Ziel                  SSD            WD-Raid           Samsung-Raid

SSD                             ----------           144 MB/s           140 MB/s

WD-Raid                      93 MB/s           -----------             145 MB/s

Samsung-RAID            96 MB/s          135 MB/s             -----------


Es ist schön zu wissen, dass man mit einem Linux-Server bedenkenlos in neue Hardware umziehen kann. Allerdings hatte ich es noch nie ausprobiert.
Endlich war es soweit, meine alte 500Mhz-Kiste wird durch eine alte 1000Mhz-Kiste ersetzt... mit hoffentlich wenig Aufwand.

So, Festplatte umgebaut, angeschaltet, fertig. Und nun!? Das Netzwerk und jegliche damit zusammenhängenden Dienste liefen nicht. Das Netzwerk ist mit das Wichtigste was einen Server ausmacht. Das ausgerechnet dies nun nicht funktioniert, hatte ich echt nicht gerechnet. Ohje, was nun.

Das Netzwerkgerät eth0 war nun eth1 und wurde schlichtweg nicht benutzt. Schreck lass nach!

Man muss die Zuordnung zu eth0 irgendwie manuell umstellen. Etwas Recherche hat mich auf folgende Datei gebracht:

/etc/udev/rules.d/70-persistent-net.rules
____________________________
# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# Converted from /etc/iftab on upgrade
#SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:12:34:89:ab:d1", ATTRS{type}=="1", NAME="eth0"


# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:23:45:90:bc:d2", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
____________________________

In dieser Datei wird nur die Zuordnung des "network device" von 1 auf 0 gestellt (letzte Zeile) und der alte Eintrag auskommentiert. Nach einem Neustart lief der Kleine und der Umzug war geschafft!


So, ich habe mein ubuntu (lucid) neu installiert, das Paket "gshutdown" gehört bei mir immer dazu. Dieses wunderbare Tool schaltet den Rechner nach oder zu einer bestimmten Zeit aus... sollte es. Nur, dass das shutdown nicht seine Arbeit verrichtet. Immer wenn ich dem Programm den Auftrag gebe nach einigen Minuten den Rechner auszuschalten, lande ich im gdm-login. Voll Nervig!

Mit etwas Nachforschen habe ich folgenden Workaround entdeckt:

#INSTALLATION
$ sudo apt-get install gshutdown


#shutdown (set user or group ID on execution)
$ sudo chmod +s /sbin/shutdown

#KONFIGURATION
#gshutdown öffnen und die Befehle manuell konfigurieren

Bildschirmfoto-Preferences.png
Folgende Eintragungen sind erforderlich:
#Schalte den Rechner aus
shutdown -h now

Bildschirmfoto-Configure the action.png
Analog muss man mit den anderen Einträgen wie folgt verfahren:
#Rechner neu starten
shutdown -r now
#Diese Sitzung beenden
logout -> gnome-session-save --logout --gui


Ab jetzt kann man in Ruhe beim heute-journal der ZDF-Mediathek nach dem Wetter einschlafen...

Reblog this post [with Zemanta]

Blogs

Pages

Creative Commons License
This blog is licensed under a Creative Commons License.