Passwörter in der Owncloud speichern

Früher habe ich den komfortablen Passwortmanager LastPass empfohlen. Nun habe ich jedoch einen eigenen Server am Start, mit dem man sehr viel mehr Möglichkeiten hat und nicht mehr einem Drittanbieter vertrauen muss.

Früher habe ich den komfortablen Passwortmanager LastPass empfohlen. Nun habe ich jedoch einen eigenen Server am Start, mit dem man sehr viel mehr Möglichkeiten hat und nicht mehr einem Drittanbieter vertrauen muss.

Es gibt zwar erste Versionen von dedizierten Passwort-Apps für Owncloud, ich setze bei solchen neuralgischen Sachen aber lieber auf altbewährtes. Mit KeePass2 konnte ich mich inzwischen so weit anfreunden, dass ich es unter Linux einsetzen kann. Zwar ist die Windows-Emulation via Mono alles andere als schön, aber sie funktioniert. Vorteil von KeePass ist, dass es OpenSource ist und es daher eine Vielzahl von Plugins und Forks für alle denkbaren Plattformen gibt.

die Installation unter Linux ist schnell gemacht

$ sudo apt-get install keepass2 mono-complete

Zu meiner Entscheidung hat auch beigetragen, dass mein Lieblingsbrowser Opera nun auf Chrome basiert und dadurch mit Trick 17 auch Chrome Apps in Opera installiert werden können. Bisher gab es nur für LastPass eine Erweiterung für Opera. Mit der Erweiterung ChromeIPass kann man nun in Chrome bzw. Opera sehr komfortabel auf die Passwortdatenbank in KeePass 2 zugreifen. Eine ähnliche Erweiterung – KeeFox –  existiert auch für Firefox. Somit hat man den Komfort von LastPass auf dem eigenen Server.

Damit Die Browsererweiterung mit KeePass kommunizieren kann, lädt man sich KeePassHttp herunter, man braucht nur die Plugin-Datei.

$ cd /usr/lib/keepass2
$ sudo mkdir plugins
$ cd plugins
$ wget https://chrome.google.com/webstore/detail/chromeipass/
ompiailgknfdndiefoaoiligalphfdae

Danach muss man KeePass 2 neu starten. Es sollte die Erweiterung dann erkennen.

Die Browsererweiterungen unterstützen übrigens nur das aktuelle KeePass 2. KeePass 1 (Classic) und KeePassX (Linux Fork) werden nicht unterstützt, Für den Mac habe ich mir KyPass zugelegt, die App kostet zwar etwas, tut aber aber Ihren Dienst besser als frühe Alpha Versionen von MacPass (kann man nur mit XCode kompilieren). Von der Installation von KeePass2 via Mono auf dem Mac schreckte ich dann doch zurück.

Update April 2018

Es gibt nun eine komplett plattformübergreifende Lösung, die auf KeePassX aufbaut, dieses jedoch stark verbessert: KeePassXC. Es ist für Linux, Windows und MacOS verfügbar und unterstützt OTP, das heißt man kann One-Time-Passwords direkt in der Anwendung generieren. Außerdem gibt es eine neu entwickelte Browser-Erweiterung,  sodass Passwort-Felder direkt im Browser ausgefüllt werden.

Damit ist die obige Anleitung obsolet, denn es gibt fertige Pakete für KeePassXC und die Browsererweiterung gibt e im jeweiligen AppStore des Browserherstellers.

HP MicroServer Gen8: USB3 HDD wird ständig unmounted

Ich nutze eine externe 1.8 TB Festplatte von Intenso um die Partition des Servers mit rsnapshot zu sichern. Dabei setze ich auf LVM, damit der Server im Betrieb gesichert werden kann. Seit geraumer Zeit schlage ich mich damit herum, dass die externe...

Ich nutze eine externe 1.8 TB Festplatte von Intenso um die Partition des Servers mit rsnapshot zu sichern. Dabei setze ich auf LVM, damit der Server im Betrieb gesichert werden kann. Seit geraumer Zeit schlage ich mich damit herum, dass die externe Platte einfach von alleine aus dem System geworfen wird.

Die Platte hat danach zwar Dateisystemfehler, das ist aber nicht die Ursache, sondern ein Symptom. Diese Fehler kann man in der Regel mit fsck beheben. Auffällig ist auch, dass die Festplatte danach immer einen anderen Buchstaben bekommt. Aus /dev/sde1 wird /dev/sdf1.

Auch eine komplett frische Formatierung brachte keine Abhilfe. Die Festplatte wird auf diversen Rechnern mit diversen Tools als fehlerfrei erkannt. Trotzdem wurde sie mir reproduzierbar unmounted. Nun habe ich die Lösung gefunden:

Der (obere) USB-Port ist schuld.

Der Microserver hat 2 USB 3.0 Ports. Diese sind (leider) hinten. Angeschlossen hatte ich die Platte immer ab oberen Port, über dem dann direkt das Gigabit Ethernet hing. Gigabit-Ethernet und USB3 sind beides Hochfrequenz-Verbindungen. Irgendwie stören sie sich gegenseitig (oder der USB-Port ist bei mir einfach defekt). Solche Probleme werden durch mangelhafte Schirmung der Ports hervorgerufen.

Mit dem unteren Port habe ich keinerlei Probleme.

HP MicroServer Gen8 vom 2,5″ Slot booten

In diesem Beitrag möchte ich alle Infos zusammenführen, die man benötigt, um den HP MicroServer Gen 8 mit einem 2,5″ Laufwerk für das OS und bis zu vier 3,5″ Datenplatten zu betreiben. Insbesondere wird darauf eingegangen, wie man von dem 2,5″ Laufwe...

In diesem Beitrag möchte ich alle Infos zusammenführen, die man benötigt, um den HP MicroServer Gen 8
mit einem 2,5″ Laufwerk für das OS und bis zu vier 3,5″ Datenplatten zu betreiben. Insbesondere wird darauf eingegangen, wie man von dem 2,5″ Laufwerk dann bootet.

Um eine 2,5″ Platte in dem oberen Fach einzubauen braucht man folgende Teile:

Hat man den Einbau geschafft, und die 3,5″ Slots im AHCI-Modus nutzen möchte, so hat man aber immer noch ein Problem. Der MicroServer bootet im AHCI Modus immer von der ersten Platte, eine Wahl des Boot-Devices ist nicht möglich. Die großen Festplattenslots werden dabei mit den Nummern 1-4 versehen, das optionale optische Laufwerk mit Nummer 5. Der Legacy-Modus ist nicht mehr empfehlenswert und den RAID-Modus kann man nur nutzen, wenn man eine Hardware-RAID-Karte besitzt.

In einem Forumsbeitrag habe ich eine Lösung dafür gefunden und möchte Sie euch hier in verbesserter Form vorstellen.

Für die Lösung braucht man einen (alten), kleinen USB Stick. Diesen Steckt man in den Internen USB 2.0 Anschluss. Am oberen Anschluss hängt die SSD oder 2,5″ Festplatte. Man kann das OS jetzt booten, wenn man alle 3,5″ Platten entfernt. (Alternativ kann man eine Live-CD wie die Super Grub2 Disc benutzen). Mit fdisk schaut man, wo der Stick eingebunden wurde. Man erkennt ihn an der Ausgabe. Vorsicht, bei den folgenden Operationen darf auf gar keinen Fall das falsche Laufwerk benutzt werden!

fdisk -l

Der Stick ist /dev/sdX (das X müsst ihr ersetzen).
Um Problemen vorzubeugen löschen wir – nach einem Backup – Bootloader und Partitionstabelle auf dem Stick. Diese liegen in den ersten 512 Bytes.

dd if=/dev/sdX of=bootstick.img count=512
dd if=/dev/zero of=/dev/sdX count=512

Beim erstellen des Dateisystems muss die Flag „bootbar“ gesetzt werden. Write schreibt das Dateisystem.

cfdisk /dev/sdX
mkfs.ext2 /dev/sdX1 # Dateisystem erstellen

Jetzt müssen wir noch den Bootloader auf den Stick schreiben.

mount /dev/sdX1 /mnt/
grub-install --no-floppy --root-directory=/mnt /dev/sdX
grub-mkconfig -o /mnt/boot/grub/grub.cfg

Nach dieser Prozedur bootet der Server auch mit eingesetzten 3,5″ Platten vom 2,5″ Slot. Im BIOS muss man USB als erstes Boot-Device auswählen.

Um nach einem Kernel Update die richtigen Kernel im Bootmenü zu haben, muss man den Stick auch wieder mounten und dann grub-mkconfig aufrufen. Die installierten Kernels werden dann automatisch erkennt.

Update Januar 2018
Das Prozedere ist recht umständlich. Bei Kernelupdates muss man manuell den Bootloader auf dem Stick aktualisieren. Mein HP MicroServer startet bei Reboot nicht vom Stick, nur bei Kaltstart. Würde mich mal interessieren warum? Der Bootstick ist einfach etwas, das leicht kaputt geht und dann das ganze System lahmlegt. Bootet der Server erst mal nicht mehr, muss man ILO bemühen, was wegen dem veralteten Java-Plugin bei mir nur noch im Safari funktioniert.

Wer nicht unbedingt alle vier Festplattenslots benötigt, ist mit einem Icy Dock 2,5″ zu 3,5″ Konverter (oder Alternative) besser bedient. Das OS bootet dann völlig normal, ohne irgendwelche Tricks. Das spart Nerven und Zeit bei Problemen. Aber Achtung, es passt aufgrund der speziellen Torx-Schrauben und der Position der Anschlüsse nicht jeder beliebige Konverter. Die beiden o.g. Adapter passen garantiert.

Ich betreibe den Microserver mit drei WD Red 2TB in einem RAID5, wodurch man dann insgesamt auf 4 TB nutzbarem Speicherplatz kommt.

 

OpenMediaVault: Umstieg auf RAID

Nachdem ich mich wegen der zusätzlichen Komplexität zuerst gegen ein RAID System entschieden habe, ist in mir der Entschluss gereift, es nun doch zu wagen. Den Umstieg von OpenMediaVault auf RAID möchte ich hier ausführlich dokumentieren. Doch langsa...

Nachdem ich mich wegen der zusätzlichen Komplexität zuerst gegen ein RAID System entschieden habe, ist in mir der Entschluss gereift, es nun doch zu wagen. Den Umstieg von OpenMediaVault auf RAID möchte ich hier ausführlich dokumentieren. Doch langsam, zuerst einmal die Vor- und Nachteile eines RAID-Systems.

Vorüberlegungen

Vorteile RAID

Ein RAID (Redundant Array of Independent Disks)  ist ein Verbund mehrerer Festplatten. Es gibt unterschiedliche RAID-Levels, sie hier alle zu erläutern würde den Rahmen des Artikels sprengen. Ich empfehle die Beschreibung bei Wikipedia. Abgesehen von RAID-0 hat  man bei RAID immer eine Redundanz, d.h. es kann eine (oder auch mehrere) Platte ausfallen, ohne dass Daten verloren gehen. Ich habe mich hier für ein RAID-5 entschieden.

  • Man hat einen großen, virtuellen Datenträger und muss sich nicht um die Festplatteneinteilung kümmern. Platten können nicht zu klein werden, denn man kann das RAID später einfach erweitern.
  • Bei Ausfällen bekommt man eine Warnung und kann die defekte Platte einfach austauschen. Die Redundanz wird dann von alleine wiederhergestellt. Das ist gerade auch deshalb interessant, weil Platten in einem NAS durch den 24/7 Betrieb stark belastet werden.
  • BEI RAID-5 hat man bei 3 x 1TB Platten eine Kapazität von 2 TB. 1 TB ist Parität. Dieses Verhältnis ist besser als z.B. bei RAID -1. Hier fiele die Hälfte der Kapazität weg.
  • Die Performance ist besser als bei RAID-1, allerdings die CPU-Last höher, wegen der Paritätsberechnung.

Nachteile RAID

  • Höherer Stromverbrauch, da immer drei Festplatten rotieren. Ohne RAID könnten vielleicht zwei davon schlafen.
  • Man braucht für RAID 5 mindestens drei Platten. Die Kapazität des RAID-5 richtet sich dann nach der Kleinsten.
  • Eine zusätzliche Abstraktionsebene, dies spielt vorallem bei der Datenrettung eine Rolle.
  • Hohe Kosten für RAID-Hardware, ich setze aber auf ein OS-RAID, das kostet nichts und ist nur wenig langsamer.

Ich finde die Vorteile überwiegen hier ganz klar, gerade wenn der Server zuverlässig sein soll. Die Datenrettung ist hier auch nicht so problematisch wie bei einem Hardware- oder BIOS-RAID, weil nur die Software eine Rolle spielt.

Festplatten

Als Platten habe ich zwei WD Caviar Green 1TB
und eine WD Caviar Red 2TB
im Einsatz. Die Green-Platten sind für den Einsatz im NAS eigentlich nicht so gut geeignet, aber sie tun ihren Dienst. Die Unterschiede liegen neben der aus Dauerbetrieb ausgelegten Hardware vorwiegend in der Software, die dann z.B. bei den Red-Platten schneller meldet, dass ein Block nicht gefunden wurde. Das OS holt sich diesen Block dann von einer anderen Platte. Im Heimbetrieb hat man ja i.d.R. auch keinen 24/7 Dauerbetrieb der Platten, weil sie sich nach 30min Inaktivität schlafen legen.

RAID-Methoden

RAID-Adapter / Hardware-RAID

Im professionellen Umfeld werden spezielle PCIe-Steckkarten eingesetzt. Diese sind beim Aufbauen und Wiederherstellen des RAID deutlich schneller, kosten aber mehrere 100 €. Die Hersteller halten diese TEile lange vorrätig, denn bei einem Fehler könnte käme man sonst nicht mehr an seine Daten.

BIOS-RAID

Viele BIOS-Setups erlauben die Einrichtung eines RAID, das dann vom Betriebssystem unabhängig ist. So kann das gesamte OS auf ein RAID installiert werden. Von dieser MEthode ist aber abzuraten, denn im Fehlerfall darf man das exakt gleiche Motherboard finden. Dies ist schon nach 2 Jahren kaum noch möglich. Von der Geschwindigkeit her ähnlich dem OS-RAID.

Betriebssystem-RAID

Diese Variantesetzt ein RAID-fähiges Betriebssystem vorraus. Es ist eine reine Software-Lösung. performancemäßig sicher nicht die schnellste Variante, aber besser als das BIOS-RAID. Diese Methode setze ich ein.

Backup

Für die RAID-Einrichtung müssen die Platten komplett gelöscht werden. Deshalb ist ein Backup vonnöten. Ich nutze meinen Server für vielerlei Daten. Auf den zwei bestehenden 1 TB Platten sind jeweils um die 450 GB belegt. Sie sollen auf eine externe 1,7 TB USB3 Platte. Doch diese ist unversehens voll, obwohl der Platz doch gut reichen sollte. Was ist passiert?

Für das Backup meiner Linux-Rechner nutzte ich Backintime. Dieses sehr nützliche Tool erzeugt Hard-Links um Speicherplatz zu sparen. Für das Backup auf die externe Platte habe ich rsync benutzt. Dieses setzt hard-Links standardmäßig überhaupt nicht um sondern kopiert die gleiche Datei zigmal. Dies lässt dich durch die Option -H verhindern. Die Berechnung ist allerdings aufwändig.

Ein weiterer Punkt warenFestplattenabbilder von VirtualBox. Diese nutzen Sparse-Images, d.h. der Platz wird nur soweit belegt wie notwendig. Auch damit kann rsync standardmäßig nicht umgehen und erzeugte so zigfach 20 GB große Dateien. Die Option –sparse schafft Abhilfe.

Letztlich lautet der Aufruf

rsync -avpH --sparse <Quelle> <Ziel>

Die Optionen -H und –sparse muss man in den zusätzlichen Optionen des USB-Datensicherungs-Plugins von OpenMediaVault manuell eingeben. Dieses Plugin hat den Vorteil, dass das Kopieren von selbst läuft und nicht der PC wegen SSH mitlaufen muss. Denn das Kopieren von 1 TB dauert einen 3-4h. Deshalb sollte man auf garkeinen Fall USB2-Platten benutzen! Diese übertragen nur magere 25 MB/s.

RAID einrichten

Sind die Daten gesichert, muss man in OpenMediaVault sämtliche Freigaben löschen und bei den Diensten entfernen. Ansonsten kann man die Platte nicht löschen. Das ist leider sehr umständlich gelöst. Ich brauchte eine halbe Stunde bis ich die letzte Stelle gefunden hatte, wo noch eine Freigabe eingetragen war.

Hat man das geschafft, kann man unter Datenspeicher > Raid-Verwaltung das RAID erzeugen. Die Festplatten werden dann Bit für Bit überschrieben, was wieder sehr lange dauert. Kleiner Platten gehen schneller als große.

Ist dieser Vorgang abgeschlossen, formatiert man den RAID-Verbund noch mit EXT4 und kann seine Daten dann zurückspielen und die Freigaben ggfs. wieder einschalten.

Es lohnt sich übrigens, sich ein Schema zu überlegen wo welche Daten abgelegt werden. Dienste, die über das Internet erreichbar sind oder wie mysql häufig gebraucht werden, liegen bei mir auf der Systemplatte, damit nicht immer die großen Festplatten anspringen. Auf dem RAID liegen Backups, Home-Verzeichnisse, Medien-Dateien usw.

Ergebnisse

Vor dem RAID-Umstieg erreichte ich bei Rsync-Backups (backintime) maximal 95 MB/s. Mit RAID sind Werte von 113 MB/s normal, ich habe auch schon Spitzen von 118 MB/s gesehen.  Das liegt sehr nahe am theoretischen Maximum von Gigabit Ethernet (125 MB/s). Die CPU Last auf dem Server (Dual Core Xeon, 2,3 GHz, 4 GB RAM) pendelt sich dann bei 40 und 50% ein. Das liegt an der Paritätsberechnung. Beim internen Kopieren von einer USB3-Platte lag die CPU Last sogar bei 70%. Diese Daten zeigen, dass mit meinem alten Prozessor, dem Celeron kein RAID5 zu machen gewesen wäre. Er lag ja schon im Leerlauf bei 20% Last.

Der Stromverbrauch bei Leerlauf stieg wegen der dritten Platte von 36 auf 40 W. Beim internen Kopiervorgang schluckte das System 72 W. Im Betrieb bei Netzwerkzugriffen sind es 43 W.

 

 

Neue Hardware im Server

Nachdem ich den MicroServer von HP in den letzten Wochen ausgiebig getestet habe, reife in mir doch der Entschluss heran, dass die enthaltene Hardware zu knauserig ist. Der Prozessor Intel Celeron G1610T lief z.B. auch im Leerlauf mit 15-20% Last und...

Nachdem ich den MicroServer von HP in den letzten Wochen ausgiebig getestet habe, reife in mir doch der Entschluss heran, dass die enthaltene Hardware zu knauserig ist. Der Prozessor Intel Celeron G1610T lief z.B. auch im Leerlauf mit 15-20% Last und der mit 2 GB ziemlich mickrige Arbeitsspeicher war – wenn man den Page-Cache noch dazu nimmt fast immer randvoll.

Dank gezockelter CPU und einem freien RAM-Steckplatz kann man den MicroServer aber prima aufrüsten. Gekauft wurde ein Intel Xeon E3-1220L
. Die Prozessorlast im Leerlauf liegt nun bei 0-1%. Der Stromverbrauch der neuen CPU ist trotz der Mehrleistung geringer (17 statt 35 W TDP). Und ganz wichtig, die CPU unterstützt den AES-Befehlssatz, sodass meine OwnCloud-Verschlüsselung nun viel schneller abläuft. Das ist auch für den Aufbau von SSL/TLS-Verbindungen wichtig, zumal die Bitlänge immer höher wird.

Der zweite RAM Riegel mit 2 GB wurde für knapp 30 € bei eBay geschossen. 4 GB reichen für den Heimgebrauch völlig aus, sofern man kein ZFS einsetzen will. Im Leerlauf mit drei aktiven Webseiten (Owncloud, Piwik, Etherpad) sind gerade einmal 694 MB, also knapp 18 % belegt. Da ist noch genug Luft nach. DEr freie RAM wird utomatisch als Page Cache benutzt und beschleunigt dann Festplattenzugriffe. Insofern schadet mehr RAM nie. Der Original RAM hat folgende Spezifikationen: DDR3 PC3 12800 ECC
. Nicht ECC-fähiger RAM funktioniert nicht.

 

OwnCloud auf Speed

Seit einigen Wochen habe ich eine OwnCloud 8 Installation auf dem MicroServer am Laufen. In dieser OwnCloud habe ich mein 27 GB großes Bildarchiv abgelegt, da man es auf diese Weise auf allen Rechnern zur Verfügung hat. Die Geschwindigkeit der Synchr...

Seit einigen Wochen habe ich eine OwnCloud 8 Installation auf dem MicroServer am Laufen. In dieser OwnCloud habe ich mein 27 GB großes Bildarchiv abgelegt, da man es auf diese Weise auf allen Rechnern zur Verfügung hat. Die Geschwindigkeit der Synchronisation hat mich allerdings bisher nicht wirklich überzeugt. Sie ist nicht mit einem rsync auf den gleichen Server zu vergleichen. Rsync lastet die Gigabit Ethernet Verbindung fast komplett aus. OwnCloud dagegen schlummert mit maximal wenigen MB/s vor sich hin. Und scheint zwischen den einzelnen Dateien eine großzugige Pause einzulegen. In diesem Artikel habe ich einige Tricks und Kniffe gesammelt, die helfen OwnCloud schneller zu machen. 

Optimierungen am Netzwerk

Mein Server hängt an einer FritzBox, für die ich den DynDNS-Dienst myFritz von AVM benutze. Weil das Zertifikat auf die DynDNS-Domain ausgestellt wurde, muss man in den OwnCloud Clients die Domain eintragen. Dadurch werden Anfragen aber über das Internet geroutet:

$ traceroute to xxxx.myfritz.net (109.42.xxx.xx), 30 hops max, 60 byte packets
 1 fritz.box (192.168.179.1) 0.347 ms 0.426 ms 0.504 ms
 2 ip-109-42-xxx-xx.web.vodafone.de (109.42.xxx.xx) 3.973 ms !X 3.982 ms !X 3.979 ms !X

Man beachte die langen Latenzen (Mobilfunk). Trägt man nun in der /etc/hosts Datei folgendes ein

192.168.179.28 xxxx.myfritz.net

liefert traceroute eine Latenz von unter einer Millisekunde und routet direkt zum Ziel. Bei IPv6 ist dieser Schritt übrigens nicht nötig, Der Router erkennt dann von selbst, dass diejenige IP ‚ihm gehört‘ und fragt garnicht erst den DNS Server des Hosters. Dazu muss man aber eine IPv6 Adresse vom Provider erhalten haben und auch im Heimnetz solche IPs per DHCPv6 verteilen. OpenMediaVault hat mit IPv6 leider noch seine Probleme. Auch auf manchen Android-Geräten scheint IPv6 fehlerhaft implementiert, wie mir AVM bestätigte.

Update 21.04.2015:  Im WLAN blockierte bei mir die FritzBox die Auflösung des Domainnamens. Owncloud funktionierte dadurch im WLAN nicht (ohne hosts-Eintrag). Um das zu ändern, muss man den DNS-Rebind-Schutz für diese Domain deaktivieren. Das geht unter Heimnetz > Netzwerkeinstellungen.

Update 28.05.2016: Es gibt leider ein ernstzunehmendes Problem mit IPv6. Die Owncloud-App für Android hat im WLAN einen Bug, es kommt keine Verbindung zustande. Dieser Bug wird hier  getrackt und hoffentlich bald gefixt. Wenn man diesen Bug kennt, kann man Die App halt nur noch von draussen nutzen. Nervig ist es nur für den Foto-Upload.

 

Eine weitere gute Idee ist auch das aktivieren von Jumboframes. Standardmäßig ist die Nutzlast (Maximum Transfer Unit – MTU) bei Ethernet auf 1500 Bytes beschränkt. Dieser Wert wird aber vorallem aus Gründen der Abwärtskompatibilität benutzt. Bei Gigabit Ethernet sollte ein größerer MTU kein Problem sein. Dazu muss man auf beiden Seiten der Verbindung

$ sudo ifconfig eth0 mtu 9000

setzen. Diese Änderung ist erstmal nicht permanent. Um die festzuklopfen,  ändert man den MTU-Wert in der Datei /etc/network/interfaces. Ich kann allerdings nicht versprechen, dass alle Umgebungen damit klar kommen.

Update:  FritzBoxen können überhaupt nicht mit JumboFrames umgehen. Sehr schade. Das erklärt auch meine Verbindungsabbrüche, wenn ich sie aktiviert habe.

Optimierungen bei OwnCloud

OwnCloud ist out-of-the-Box sehr konservativ eingestellt und vorallem so ausgelegt, dass es auf auf Webservern läuft, wo man keine Rootrechte hat. Zuhause sollte man unbedingt folgende Änderungen machen:

  1. von AJAX auf richtige Cronjobs umstellen. Das beschleunigt aber vorallem die Weboberfläche.
  2. Statt SQLite eine richtige mySQL-Datenbank einsetzen. Diese hat erheblich mehr Performance.
  3. Die mySQL Einstellungen optimieren
  4. Ein PHP Cache Paket installieren, z.B. PHP APC. Dieses soll zumindest die Weboberfläche um den Faktor 3 beschleunigen.
  5. Umgebungsvariablen für den Owncloud Client setzen.
  6. Update: PHP-FPM und NGINX besser konfigurieren

Cronjobs

Für die Cronjobs benutzt man auf einem Debian den Befehl

$ sudo -u www-data crontab -e

Dies bearbeitet die Cronjobs des Benutzers www-date. Das ist wegen den Rechten wichtig. Dort trägt man die Zeile

*/20 * * * * php -f /var/www/owncloud/cron.php

ein. Dadurch wird dann alle 20min der Owncloud-Cronjob ausgeführt. In der Administrationsoberfläche kann man dann von AJAX auf Cron umstellen und prüfen, ob der Cronjob ausgeführt wird.

Umziehen auf eine MySQL-Datenbank

Das Umstieg von der Dateibasierten sqlite-Datenbank auf mySQL ist komplizierter. Man muss sich damit gut mit mySQL auskennen. Hier gibt es eine Anleitung für OC7. Im Prinzip muss man wie folgt vorgehen:

Das Paket mysql-server installieren

sudo apt-get mysql-server

Bei der Installation vergibt man das Root-Passwort. Nun verhindet man sich mit der Konsole:

$ mysql -u root -p

Man sollte für OC einen eigenen Benutzer haben, der nur auf die OC-Datenbank zugreifen kann. Dazu benutzt man folgende mySQL Befehle

CREATE DATABASE <dbname>
CREATE USER <username>@localhost IDENTIFIED BY <password>

Die Rechte an der Datenbank gibt man dem neun Benutzer mit

GRANT ALL PRIVILEGES ON <dbname> . * TO <username>@localhost;

Verlassen kann man die mySQL Konsole mit exit; Nun das Skript /var/www/owncloud/occ ausführbar machen und ausführen:

$ sudo -u www-data chmod +x occ 
$.sudo -u www-data /occ db:convert-type –password=”<password>” –all-apps <username> localhost <dbname>

MySQL Einstellungen optimieren

Das Skript mySQLTuner gibt Tipps, was man verbessern kann. Die Einstellungen einer mySQL-Datenbank befinden sich unter Debian in /etc/mysql5/my.cnf. Nach Änderungen an dieser Datei muss man mySQL neustarten.

Folgende Variablen habe ich geändert. Mein Server hat 4 GB RAM.

  • innodb_buffer_pool_size von 128 MB auf 1 GB
  • query_cache_size von 16 MB auf 64 MB
  • tmp_table_size von 16 MB auf 32 MB
  • max_heap_table_size von 16 MB auf 32 MB

Variablen zeigt man auf der mySQL Konsole so an und kann sie auch ändern:

> SHOW VARIABLES LIKE 'query_cache_size';
> SET GLOBAL query_cache_size = 33554432;

Diese Änderungen verfallen aber nach einem Neustart. Will man sie behalten, muss man sie in der my.cnf eintragen. Man sollte sich immer informieren, welche Werte gut sind. Viel hilft nicht immer mehr! Manche Caches sollten eine bestimmte Größe nicht überschreiten

PHP Cache aktivieren

Dazu muss man lediglich die entsprechenden Pakete installieren und den Webserver neustarten

$ sudo apt-get install php-pear php-apc $ sudo service nginx restart

Konfigurieren muss man eigentlich nichts. Der Cache verbessert die Verarbeitungszeit der PHP-Skripte auf dem Server um etwa den Faktor 2x. Das ist natürlich insbesondere für dien Zugriff via Browser gut, aber auch der Sync-Client nutzt letztendlich HTTP-Aufrufe von PHP Skripten zur Dateiübertragung.

Umgebungsvariablen setzen

Bei Owncloud ist der Upload über den Browser erheblich schneller als über den Client. Dies liegt unter anderem daran, dass der Client seine Uploads in sog. Chunks einteilt, die standardmäßig nur 10 MB groß sind. Eine automatische Anpassung an die tatsächliche Bandbreite findet leider nicht statt. Man sieht dies sehr schön, wenn man in der Systemüberwachung den Netzwerkverkehr anzeigt.

Die Umgebungsvariable OWNCLOUD_CHUNK_SIZE ändert ihr  unter Linux in der .profile

OWNCLOUD_CHUNK_SIZE=104857600
export OWNCLOUD_CHUNK_SIZE

Dieser Wert entspricht 100 MB und ist für Gigabit Ethernet ausgelegt. Danach einmal abmelden und ihr solltet ordentliche Uploadraten mit dem Client erhalten.

Man sollte auch immer bedenken, dass die hier genannten hohen Geschwindigkeiten nur mit großen Dateien an einem Stück zustande kommen. Bei Bildarchiven z.B. macht OC trotz der Chunksize zu viele Unterbrechungen. Das wird mit folgender Grafik klar (Chunk Size=50 MB, viele 4-6MB große Dateien):

Owncloud Netzwerkstatistik
Owncloud Network Speed

Update: PHP-FPM und NGINX

Bei einem anderen Projekt habe ich gesehen, dass die Anzahl der Prozesse, die PHP-FPM starten darf, zu gering war. Es treten dann Warnungen in den Logfiles auf. Man sollte die Einstellung erhöhen, bis keine Warnungen mehr auftreten.

# /etc/php5/fpm/pool.d<dein-pool>.conf
pm = ondemand
pm.max_children = 32
pm.max_requests = 200
pm.process_idle_timeout = 10s

Diese Einstellungen sind beispielhaft. Durch die Einstellung ondemand werden Prozesse bei Bedarf erzeugt und nicht vorgehalten, was bei Umgebungen mit relativ geringer Last weniger RAM verbraucht [Quelle].

Als Webserver nutze ich Nginx. Bei Apache gibt es natürlich ähnliche Optionen, da verweise ich aber auf Google. Auch in den NGINX-Einstellungen kann man etwas optimieren:

# /etc/ngins/nginx.conf
worker_processes 4; # i.d.R. die Anzahl der CPU-Kerne
gzip on;
gzip_disable „msie6“; # IE 6 deaktivieren
gzip_vary on;
gzip_min_length 10240; # erst ab 10 KB komprimieren
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript # nur Textdateien komprimieren, keine Bilder etc.

Dies verbessert die Performence bei der Komprimierung, da nicht ,mehr jede noch so kleine Datei komprimiert wird. Das Komprimieren von Bildern, Videos usw. kostet nur CPU-Leistung, bringt aber wenig. Daher nur bei Text-Dateien.

Es gibt noch sehr viele andere Einstellungen. Ich möchte hier nur einen Anreiz geben, sich dort einzuarbeiten.

 

Fazit

Nach allen Optimierungen erreiche ich Raten von 50-60 MB/s, (abhängig von der Dateigröße und nicht durchgehend). Die Änderung der Umgebungsvariablen und der Caches auf dem Server hat am meisten gebracht, auch das Routing hatte seinen Anteil. Meine 4 GB RAM auf dem Server sind nun deutlich voller (25% vs. 16%). OwnCloud erzeugt sehr viel Overhead durch die Datenbank, daher lässt sich die Geschwindigkeit nicht mit rsync vergleichen. Für Heimnetz-Geschwindigkeiten ist OwnCloud nicht ausgelegt, aber die Uploadgeschwindigkeit ist trotzdem erheblich besser als per VDSL auf einen fremden Server.

Die Einstellungen bei PHP-FPM und NGINX haben gefühlt etwas mehr Performance gebracht, ich hatte aber auch einen viel zu niedrigen Wert für die Anzahl der Prozesse voreingestellt.

Die Quelle meiner gesammelten Informationen möchte ich euch nicht vorenthalten. Das generelle Problem bei Internetrecherchen zu diesem Thema ist aber, dass sie meistens ältere OC Versionen betreffen.