ownCloud mit lighttpd und PHP auf Freetz

[oidia]

Hallo zusammen,

habe mich in den letzten Tagen mit o.g. Konfiguration beschäftigt. Dabei bin ich über einige Probleme gestolpert. Diese habe ich nun behoben und möchte die Probleme und Lösungen hier allen zur Verfügung stellen...

Probleme:
1) Ein Upload funktionierte nur für sehr kleine Dateien
2) svg Dateien wurden im Browser nicht angezeigt
3) Die timezone wurde nicht erkannt (falsche Uhrzeiten wurden angezeigt)

Lösungen:
1) Der Upload funktionierte deshalb nicht, weil "chroot" eingeschaltet war. Ausgeschaltet funktionierte es hingegen. Aber ich wollte es auch mit eingeschaltetem chroot zum Laufen bringen. Letztlich habe ich festgestellt, dass lighttpd ein tmp-Verzeichnis nutzen wollte, welches es mit chroot nicht gab: /var/tmp. Eine Anpassung der lighttpd_conf hat das Problem gelöst (siehe Patch).
2) Die svg Dateien wurden vom lighttpd falsch ausgeliefert, es war kein Mime-Typ definiert. Auch hier half die Anpassung der lighttpd_conf (siehe Patch)
3) Der lighttpd versuchte bei eingeschaltetem chroot auf TZ zuzugreifen (bin mir nicht mehr ganz sicher ob auf /etc/TZ oder /var/TZ). Ich habe daraufhin die TZ wir im Original-Root ins neue root unter /var/TZ kopiert und einen symbolischen Link in /etc auf ../var/TZ erstellt. Danach wurden auch die Zeiten korrekt angezeigt.

Hier nun der Patch für die Datei im make-Verzeichnis von Freetz:

Index: lighttpd_conf
===================================================================
--- lighttpd_conf    (Revision 13599)
+++ lighttpd_conf    (Arbeitskopie)
@@ -64,6 +64,7 @@
 ".xbm" => "image/x-xbitmap",
 ".xpm" => "image/x-xpixmap",
 ".xwd" => "image/x-xwindowdump",
+".svg" => "image/svg+xml",
 ".css" => "text/css",
 ".html" => "text/html",
 ".htm" => "text/html",
@@ -96,6 +97,7 @@
 server.pid-file = "/var/run/lighttpd.pid"
 server.username = "wwwrun"
 server.groupname = "wwwrun"
+server.upload-dirs = ( "/tmp", "/var/tmp" )
 EOF
 
 out="connection.kbytes-per-second = $LIGHTTPD_LIMITCONN\nserver.kbytes-per-second = $LIGHTTPD_LIMITSRV"

Vielleicht könnt ihr das ja in den Trunk mit aufnehmen

Viele Grüße
Markus

 

[Fischers Freetz]

Hallo!

Ich spiele mit dem Gedanken, Freetz auf meiner FB7390 zu installieren und meine OwnCloud (bzw jetzt NextCloud) von meinem Raspberry auf die FB umziehen zu lassen, um nicht mehr zwei Geräte laufen lassen zu müssen. Daher würden mich Erfahrungsberichte interessieren, was Schnelligkeit, Zuverlässigkeit und den gleichzeitigen Betrieb als normale Telefon/DECT-Basisstation an einem Analoganschluss betrifft.

Ich benutze OC zu 99% zum Synchronisieren von Adressen und Terminen auf mehreren Geräten. Dateien sind nicht unbedingt erforderlich, und wenn, dann höchstens kleine Dateien unter 200kb, z.B. PDF-Dateien zum Lesen für unterwegs. Aber die kann ich notfalls auch anders auf die Geräte verteilen, wenn die Leistung der Cloud auf der FB nicht reicht.

Wie sieht es mit der nötigen SQL-Datenbank aus? Als ich seinerzeit für OwnCloud von SQLite auf MySQL umgestiegen bin, ergab sich trotz der beschränkten Hardware des Raspberry ein enormer Geschwindigkeitszuwachs, was dadurch zustande kommt, daß bei SQLite bei einer Änderung des Inhalts stets die gesamte DB-Datei gelesen *und* geschrieben werden muss. Das ganze auf einer SD-Karte, und man kann Kaffee trinken gehen zwischendurch. ;-) MySQL schreibt dagegen nur die Daten neu, die sich verändert haben und es federt die Zugriffe durch Caches ab, es ergibt sich daher trotz des zusätzlich laufenden DB-Servers eine Steigerung der Verarbeitungsgeschwindigkeit beim Synchronisieren.

Die grafische Oberfläche der OC brauche ich nicht unbedingt zu benutzen, es reicht die reine Synchronisierung per CALDav und CARDDav.

Bedenken habe ich ein wenig wegen Stromausfall: der Raspberry hängt an einer USV, und dank apcupsd kann er sich selber kontrolliert(!) herunterfahren, wenn der Strom ausfällt. So weit ich sehe[1], gibt es dieses Programm nicht für Freetz. Das würde bedeuten, daß die FB zwar dank der USV weiterläuft, wenn der Strom ausfällt, aber wenn die Batterie leer ist, einfach ausgeschaltet wird. Dieser Fall ist natürlich für eine Datenbank absolut tödlich. Gibt es dafür eine Lösung?


Schon mal Danke im Voraus für alle Tips und Hinweise!


__________________
[1] http://trac.freetz.org/wiki/packages

 

[oidia]

Hallo Fischers Freetz,

ich habe relativ schnell die Experimente mit der OwnCloud auf der Fritz!Box eingestellt. Mein Anwendungsfall entspricht exakt deinem, also hauptsächlich Sync mit CalDav und CardDav. Deine Erfahrung mit SQLite kann ich bestätigen, es ist wirklich seeehr langsam. Das war auch der Grund, warum ich den genau entgegengesetzten Weg gegangen bin. Ich habe die OwnCloud nun auf einem Raspberry laufen. Das ist zwar immernoch langsam, aber es reicht mir und im Vergleich zur Fritz!Box ist es deutlich schneller. Meine Versuche liefen ebenfalls auf der 7390. Ich könnte mir vorstellen, dass eine 7490 mit USB 3.0 wieder etwas schneller wäre, aber da habe ich keine Erfahrungen.

Meine Empfehlung: bleib bei dem Raspberry Pi!

 

[Fischers Freetz]

Danke!

Ja, die CPU in der FB ist nicht die schnellste, aber sie war ja auch nie für mehr als Telefonanlage und Router gedacht. Der Raspberry, und erst recht die Version mit der Mehrkern-CPU, ist damit verglichen schon ein Hochleistungsrechner. ;-)

Ich würde halt nur gerne meinen Gerätepark etwas abspecken. Im Moment laufen hier viel zu viele Geräte permanent: das Modem des Kabelanbieters, ein Switch mit der Firewall, die 7390 für's Telefon, und der Raspberry. Das muss irgendwie schlanker gehen. Mir ist natürlich bewusst, daß es nicht sinnvoll ist, alle Funktionen auf eine Maschine zu packen, insbesondere die Firewall, und daß ich das Modem des Kabelanbieters nicht ersetzen kann, da es proprietär ist und gleichzeitig den HD-Receiver beinhaltet.

Ich könnte mir zwar, wenn der Router-Zwang fällt, eine eigene 6490 o.ä. zulegen, die Zugangsdaten vom Anbieter eintragen, und den HD-Receiver daran per Ethernet anschließen, so, wie es auch bei der Vertrags-Variante mit einer FB des Anbieters geschieht. Diese würde dann meine bisherige 7390 ersetzen, und wenn die leistungsstark genug ist, könnte ich OwnCloud darauf laufen lassen. Aber Freetz auf einer Kabel-FritzBox, läuft das?

 

[oidia]

Also in der Auswahl für das zu kompilierende Freetz ist keine 6490 dabei - sieht also schlecht aus...

 

[PeterPawn]

Es ist zwar immer noch vollkommen unklar (und wird es wohl auch bis zum Auftauchen erster Geräte bleiben), was AVM da nun bei freiverkäuflichen 6490 bzw. der 6590 plant.

Sollte es AVM da tatsächlich egal sein, wenn der Kunde eigene Software auf dem Router installieren kann ("egal" meint hier dieselbe Vehemenz bei den Gegenmaßnahmen wie bei den DSL-Modellen), dann wäre so eine 6490 gar keine so schlechte Wahl ... der ATOM-Core bietet (meiner Meinung nach) tatsächlich genug Reserven, um da auch noch etwas zusätzliche Software laufen zu lassen.

Das ginge bei einem OpenVPN-Server wieder los (das AVM-IPSec läuft auf dem langsameren ARM-Core) und bei passenden Speichermedien (so etwas macht man dann tatsächlich auf einer HDD und nicht auf einem Stick, der in aller Regel selbst noch einmal den Durchsatz einschränkt, wenn es nicht ein sauteures (und dann verschwendetes) Modell ist) könnte dann - wie oben bemerkt, je nach DB, die darf natürlich auch nicht riesig sein, wenn es eine SQLite3-DB ist - auch eine kleine ownCloud-Installation da recht performant sein.

Wenn ich raten müßte (man mag mich mit dem passenden Benchmark widerlegen), würde ich aus dem Bauch heraus dem ATOM-Core des Puma6 eine höhere Performance bescheinigen als einem RasPi und die I/O-Anbindung für Storage wäre auch nicht soo verschieden. Wenn die ersten gekauften 6490/6590 bei den Bastlern dann auftauchen, bin ich mal gespannt, wie lange es braucht, bis da der (m.E. vorhandene) SATA-Anschluß als eSATA nach außen geführt und mit einer passenden HDD bestückt wird.

Wenn AVM die Firmware weiterhin konsequent verriegelt bei den DOCSIS-Modellen, wäre man damit aber von Lücken in dieser Absicherung abhängig und damit sollte man dann ein solches Vorhaben mit 6490/6590 eher beerdigen.

Aber ich wüßte nicht, daß sich AVM zu dieser Frage ("firmware sealed or not") bisher öffentlich geäußert hätte ... damit muß man solche Überlegungen wohl aufschieben.

 

[Fischers Freetz]

Ich habe bisher von AVM den Eindruck eines Unternehmens, dem etwas an seinen Kunden gelegen ist, das sich um seine Kunden kümmert, das mit und für die Kunden arbeitet und sie nicht einfach nur als nützliche Abnehmer der eigenen Produkte, darüber hinaus aber als Störung der betrieblichen Abläufe betrachtet, wenn es z.B. um Support geht. Fehler werden schnell behoben, schneller als bei anderen Herstellern, und Kontakte mit dem Kundendienst verlaufen nicht wie mit einer Maschine.

Wie gesagt: das ist mein Eindruck. Ich kann mir daher vorstellen, daß die Versiegelung der FritzBoxen für den Einsatz bei Kabelanbietern gar nicht die Idee von AVM war, sondern auf Druck der Kabelanbieter geschah, die nicht wollten, daß ihre Kunden daran etwas ändern.

 

[PeterPawn]

Selbst wenn das so war ... die Veröffentlichung einer FRITZ!Box mit zugänglicher Firmware zieht (ohne weitere Maßnahmen) fast zwangsläufig auch für die von den KNB direkt "vertriebenen" (oder "vermieteten/verliehenen") FRITZ!Boxen die Möglichket nach sich, dort ebenfalls eine andere Firmware zu installieren.

Ob das dann vom jeweiligen Vertrag zwischen Kunden und KNB gedeckt ist oder nicht, kann bei solchen Überlegungen auch keine Rolle spielen, denn das war es bisher auch nicht ... nun ist so eine alternative Firmware aber auch kaum als (dauerhafte) "Beschädigung" zu interpretieren, vor allem dann, wenn sie durch einfaches Update wieder ersetzt werden kann.

Damit wird sich vermutlich wirklich nichts ändern bzgl. der Verfügbarkeit der Firmware ... aber auch das ist logischerweise pure Spekulation und um das "Aufschieben" kommt man nicht herum. Ich will auch keinen Pessimismus um jeden Preis verbreiten, aber die Euphorie anderer, daß sich ab dem 01.08.2016 auch bei den DOCSIS-Boxen die Situation grundlegend ändern wird, teile ich nicht - ich lasse mich aber gerne überraschen, wenn AVM tatsächlich die Firmware selbst bereitstellt. Allerdings sage ich für diesen Fall auch voraus, daß es max. 14 Tage dauert, bis die Firmware so weit auseinandergenommen wurde, daß (beim derzeitigen Stand von Bootloader und Firmware, wobei ich die 06.50 dort noch nicht kenne) eigene Änderungen daran ausgeführt werden können. Derartige Bemühungen würden durch den Vertrieb von neuer Firmware (auch künftig) nur über die KNB zwar nicht unmöglich gemacht, aber schon ziemlich erschwert. Daß so etwas im Kabel-Segment nicht so vollkommen ungewöhnlich ist (wenn auch auf anderen Kanälen), habe ich am Beispiel der "zertifizierten Digital-Receiver" schon einige Male versucht zu zeigen.

Nun ist so ein Receiver zwar (in Grenzen) eher harmlos im LAN (wobei wohl kein Kunde sicher sagen kann, daß der nicht auch angreifbar ist, denn auch deren Firmware gibt es in aller Regel eben nicht zur Kontrolle ... dann verlören sie vermutlich wieder ihre "Zertifizierung"), da ist ein Router dann wieder ein ganz anderes Kaliber, mit dem die Sicherheit des gesamten Heimnetzwerks steht und fällt.

Da ist (m.E.) dann so eine (unabhängige) Analyse sogar wieder notwendig und sinnvoll ... wenn sich nur Blackhats damit befassen und dann die Lücken dort ausnutzen, ist am Ende wieder der Kunde der Gea****te, weil er nicht einmal vernünftig nachweisen kann, daß in seinem Router ein Lücke klaffte, die er nicht zu vertreten hat(te). Insofern bringt tatsächlich die Veröffentlichung von Firmware wieder für beide Seiten (logischerweise auch für "die dunkle Seite", aber das läßt sich kaum verhindern) Vorteile ... wie sich AVM an dieser Stelle positionieren wird, werden wir ab dem 01.08.2016 sehen.

Die üblichen OpenSource-Pakete wären ohnehin auch heute schon erhältlich ... die muß AVM nach den Bestimmungen der Lizenzvereinbarungen einem anfragenden Kunden auch jetzt schon überlassen, denn die GPL schreibt nicht einmal davon etwas, daß man tatsächlich ein Gerät mit der fraglichen Software selbst besitzen muß. Schon das "in den Verkehr bringen" reicht aus ... die Frage der tatsächlichen Funktionsfähigkeit und Vollständigkeit dieser veröffentlichten Pakete stellt sich ja auch gerade bei den VR9-Modellen mit Linux 3.10.73 - ich bleibe dabei, daß die Sourcen unvollständig sind (man kann mich nur zu gerne widerlegen, denn dann könnten wir endlich auch den Kernel bei diesen Versionen ersetzen).

Selbst wenn es also nicht eine Idee von AVM gewesen sein sollte ... hebt man diese "Versiegelung" (mir fällt kein besseres Wort im Deutschen ein) auf, gilt das beim derzeitigen Kenntnisstand mehr oder weniger zwangsläufig auch für die Boxen, die von den KNB bei AVM geordert werden. Wenn da tatsächlich der unterstellte Druck bestand oder sogar noch weiterhin besteht, dann wird es mit einiger Wahrscheinlichkeit auch keine "frei verfügbare" Firmware geben ... die damit einhergehenden "Gefahren" für diese Abschottung und die Menge der dann von den KNB ggf. nicht mehr abgenommenen Geräte müßte AVM dann gegen den potentiellen Zuwachs an Kunden bei Retail-Boxen abwägen ... ich will nicht unken, aber das dürfte bei einem Straßenpreis von > 200 EUR (und viel billiger wird eine 6490 m.E. nicht werden, auch keine 6590) nicht sofort mit einem Feuerwerk an verkauften DOCSIS-Boxen beginnen und ich kann mir auch keine Schlangen mit Schlafsäcken vor den Elektronikmärkten in der Nacht vom 31.07. auf den 01.08. vorstellen.

Wie gesagt, ich lasse mich überraschen ... aber nur "an das Gute in einer (deutschen) Firma" zu glauben, ist mir persönlich etwas zu einfach. AVM ist ein Wirtschaftsunternehmen und auch da gilt, daß am Ende der wirtschaftliche Erfolg zählt. Kann man den durch bessere Kundenbindung über besseren Support erzielen, baut man eben den Support entsprechend aus ... dann paßt auch wieder der erste Absatz in #7. Aber nur, damit die eigenen Kunden es besser haben, weil man sie so sehr mag, wird wohl kein Hersteller derartige Anstrengungen unternehmen ... sprich: Zeitigen solche Maßnahmen nicht den erwarteten Effekt, stampft man in aller Regel so etwas auch ganz schnell wieder ein - das "an den Kunden etwas gelegen" ist mir da etwas zu blauäugig gedacht.

Es ist eher eine Symbiose ... ohne die Kunden kann auch AVM nicht (über-)leben (im internationalen Vergleich ist AVM - ohne jemandem zu nahe treten zu wollen - ein eher kleines Licht, das hat für die AVM-Kunden in D sogar gewisse Vorteile) und das ist erstes Semester BWL, daß man auch einen gewissen Kundendienst bieten muß. Wenn der Kunde das dann so wahrnimmt wie Du, dann hat auch alles funktioniert ... vom Marketing bis zum tatsächlich geleisteten Support; insofern ist das auch meinerseits keine Kritik am Gebaren von AVM, es ist wieder nur meine Meinung zur eigentlichen "Motivation" von AVM, weil mir das Verhältnis Kunde-AVM etwas zu sehr verklärt wurde.