Beim Upload eine ca. 1.3 GB großen ISO-Datei über das Owncloud-Backend, geht der Prozessor des Raspi3 in die Knie.
Investigating…
Monat: Juli 2016
Raspberry PI3 und Owncloud 9 auf Raspbian Lite
Nachdem ich mittlerweile einen recht potenten Internetzugang zu Hause habe, wollte ich mal versuchen, wie es sich denn verhält, wenn man Owncloud wirklich zu 100% selbst hostet und nicht auf einen externen Serveranbieter angewiesen ist.
Zu diesem Zwecke, hatte ich zuletzt in einen Raspberry PI3 investiert.
Als Betriebsystem kommt Raspian Lite (Jessie) zum Einsatz.
phpmyadmin installieren
Zuerst installiere ich mysql-server5, anschließend dann phpmyadmin. Phpmyadmin zieht den Apache Webserver und div. Php-Module mit. Bei der Vergabe des MySql-Rootpasswortes sollte man kein zu einfaches Passwort wählen!
/var/www auf SSD mounten
Anmerkung: Im Nachhinein gesehen, wäre es wahrscheinlich besser gewesen, das komplette /var Verzeichnis auszulagern!
Ich mounte also per /etc/fstab/ die erste Partition der SSD /dev/sda1 auf /var/www. Das Verzeichnis liegt somit auf einer rund 60GB großen Partition auf der SSD-Festplatte.
Owncloud Repo hinzufügen und installieren
Wie man auf der Site https://download.owncloud.org/download/repositories/stable/owncloud/ beschrieben, binde ich das Repository in apt ein. Die installation von Owncloud geschieht mittels:
apt-get update
apt-get install owncloud
Datenbank für Owncloud erstellen
Per phpmyadmin lege ich die für Owncloud notwendige Datenbank an.
Natürlich brauchen wir auch noch einen User, der auf die DB zugreifen soll. Bitte nicht den MySql – Root User verwenden!
Nachdem User und Datenbank erstellt sind, müssen noch die Berechtigungen des User auf die Datenbank vergeben werden (Klick für größeres Bild).
SSL Vhost aktivieren, SSL Zertifikat einbinden
Owncloud sollte NICHT per HTTP angesprochen werden. Es sollte eine strikte Umleitung auf SSL erfolgen. Dies wiederum, erfordert ein entsprechends SSL Zertifikat. Ein solches Zertifikat kann man sich entweder selbst erstellen, oder aber günstig erwerben. Ich habe mit AlphaSSL gute Erfarhungen gemacht. Es spricht jedoch nichts dagegen, ein selfsigned Zertifikat zu verwenden. Es geht ja primär um die Verschüsselung.
Genauere Infos dazu u.a. bei Digitalocean
Eine Bespielkonfiguration (Apache Vhost-Datei unter /etc/apache2/sites-available/dein.vhost.conf), mit permanenter Umleitung auf https kann z.B.: so aussehen (Apache Version 2.4):
<VirtualHost *:80>
ServerName owncloud.server.at
DocumentRoot /var/www/owncloud
SSLVerifyClient optional
Redirect permanent / https://owncloud.server.at
</Virtualhost><VirtualHost *:443>
ServerName owncloud.server.at
<IfModule mod_headers.c>
Header always set Strict-Transport-Security „max-age=15768000; includeSubDomains; preload“
</IfModule>SSLEngine on
SSLCertificateKeyFile /etc/ssl/private/zertifikat.key
SSLCertificateFile /etc/ssl/certs/zertifikat.crt
SSLCaCertificateFile /etc/ssl/certs/AlphaSSLroot.crt
DocumentRoot /var/www/owncloud
<Directory /var/www/owncloud>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
ErrorLog /var/log/apache2/owncloud_error.log
CustomLog /var/log/apache2/owncloud_access.log combined
</VirtualHost>
Oben FETT geschrieben = permanente Umleitung auf HTTPS
Die Konfiguration muss dann noch per a2ensite <vhostfile> aktiviert werden! (Achtung Apache Restart nicht vergessen!)
Apache Modul SSL und headers aktivieren
a2enmod ssl
a2enmod headers
service apapche2 restart
Memory Cache apcu installieren
apt-get install php5-apcu
Danach diese Zeile (unten fett geschrieben) in /var/www/owncloud/config/config.php einfügen:
‚dbpassword‘ => ‚wPCn5EhH5q4E4ZcB‘,
‚logtimezone‘ => ‚UTC‘,
‚installed‘ => true,
‚memcache.local‘ => ‚\OC\Memcache\APCu‘,
Apache Restart nicht vergessen.
Owncloud Installation starten
Nun sollten die grundlegenden Vorarbeiten erledigt sein. Nach Aufruf des entsprechenden URL der Owncloudinstallation, gibt man nun DB_User, Datenbank, Host, Owncloud-Admin-User inklusive Passwort in die erscheinende Maske im Browser ein und klickt auf „Installation Fertigstellen“.
Ist alles glatt gegangen, sollte man im Backend von Owncloud landen.
Weitere wichtige Schritte
Serverseitige Verschlüsselung aktivieren
Im Backend sollte die serverseitige Verschlüsselung (Anklicken des angemeldeten User – Administration – links auf Serverseiteige Verschlüsselung – Haken setzen bei Serverseiteige Verschlüsselung aktivieren + Klick auf Verschlüsselung aktiveren) eingeschaltet werden.
Verschlüsselungsmodul laden
Aktivieren des Verschlüsselungsmodules über Klick (links) auf: Apps – Nicht aktiviert – Default encryption module – > auf Aktivieren klicken.
Danach bitte nochmals ab- und wieder anmelden, damit der Schlüssel initialisiert werden kann.
fail2ban installieren
apt-get install fail2ban
Danach kopiert man /etc/fail2ban/jail.conf nach jail.local und aktiviert die entsprechenden jails in der Datei.
Am Beispiel von ssh sieht die Konfig so aus (enabled einfach auf true stellen):
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
rkhunter installieren
apt-get install rkhunter
rkhunter –propupd –update
Sollte man in eine Fehlermeldung a la: „Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /usr/bin/lwp-request“ laufen, muss in /etc/rkhunter.conf die Zeile
SCRIPTWHITELIST=/usr/bin/lwp-request
auskommentiert werden. Danach sollte das Updatescript problemlos durchlaufen und einen Fingerabdruck des Systemes erstellen.
mod_evasive aktivieren
apt-get install libapache2-mod-evasive
Nach der Installation sollte man das Logginverzeichnis erstellen und dem Apache-User (in der Regel www-data bei einsatz von mod_php) Zugriff auf dieses Verzeichnis gewähren.
chown www-data /var/log/mod_evasive
Unter /etc/apache2/mods-available/evasive.conf muss die Konfiguration angepasst werden. Eine nicht so scharf eingestellte Beispielkonfiguration wäre:
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 20
DOSSiteCount 100
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSEmailNotify hostmaster@it-networker.at
#DOSSystemCommand „su – someuser -c ‚/sbin/… %s …'“
DOSLogDir „/var/log/mod_evasive“
DOSWhitelist 127.0.0.1
</IfModule>
Dies sollte es vorerst gewesen sein. Im folgenden Teil (noch in Arbeit), werde ich kurz auf die zusätzliche Absicherung des Systemes eingehen und auch eine Benachrichtigung einrichten.
Vor allem kann ich dann eventuell schon Aussagen bezogen auf die Leistungsfähigkeit des PI3 tätigen.
TP-Link Archer MR200 – Drei Hutchison und 4G – fixe IP
Der TP-Link Router bietet mehr Möglichkeiten wie der Webgate3, deshalb schickte ich mit heutigem Tage den braven Gate in die Pension. Zuvor entfernte ich natürlich noch die Simkarte und steckte sie in den SIM-Slot des TP-Link.
Da ich externe Antennen verwende, blieben die mitgelieferten Stummelantennen originalverpackt in der Verpackung liegen.
Nur noch das CAT-Kabel anschließen, die Stromversorgung anstecken und Power UP.
„Das wird eine Plug and Play Installation“, dachte ich mir.
Standardmäßig hat der MR200 die IP 192.168.1.1. Ich arbeite mich durch den kurz gehaltenen Assistenten, sehe dass mein Provider samt APN drei.at bereits erkannt worden ist, klicke hastig weiter…
Internet Verbindung wird überprüft… und überprüft… und FEHLER, keine Verbindung
Kurz überlegt, was hab ich falsch gemacht, mir fällt nichts ein. Signalstärke liegt bei 100%. Trotzdem hol ich die Stummelantennen raus. Signalstärke fällt auf 70%. Der Verbindungstest schlägt fehl.
Ich wechsle in das Menü „Internet“ im Backend des Router. Stelle den Network Mode von Auto auf 4G. Keine Verbindung. Na gut, dann versuch ich halt auch noch 3G. Plötzlich lese ich „connected“.
Jetzt, wo ich eine Internetverbindung zu Stande gebracht habe, kann ich gleich ein Firmware-Update durchführen. (vielleicht behebt ja das das Problem). Ein unspektakuläres Firmware Update später, muss ich jedoch feststellen, dass die Aktualisierung genau „nichts“ gebracht hat. Es funktioniert immer noch nicht.
Bleibt mir wohl der Griff zum Telefon nicht erspart – Hotlinetime.
Gibt es vielleicht irgendwelche Einschränkungen seitens der Providers? Meine letzte Hoffnung zerstört der sehr freundliche Mitarbeiter mit einem „Uns ist egal, welche Hardware sie einsetzen, sie müssen nur den APN: drei.at einstellen.“ (Anm.: Ich habe gefragt, ob das auch bei fixer IP so ist).
Mist, da hat wohl der Router einen Defekt… Doch dann passierte es ;-).
Mir schoss in den Kopf, dass ich irgendwo mal etwas vom APN: static.drei.at gelesen hab. (Gedankengang: static.drei.at … statische IP, könnte vlt. klappen).
Ich stelle also den APN auf static.drei.at um, schalte auf 4G und der Router connected. Damit meine Verbindung allerdings auch auf 3G zurück fallen kann, belasse ich dann die Einstellung auf Auto.
Fazit
Wer Drei Hui Flat in Verbindung mit einer statischen (fixen) IP verwendet und nicht den Webgate3 einsetzt, muss den APN manuell auf static.drei.at setzen, sonst klappt die Verbindung per 4G nicht!
Acer Iconia Tab A700 – Recovery Menü
Stunden hab ich nun gebraucht, um ein mir nicht bekanntes Acer Iconia A700 in das Recovery Menü zu bringen. Es ist in einem Bootloop festgesteckt. (Ich wusste, nicht welche Androidversion installiert war…)
Wipe Data / Factory Reset per Recoverymenü hat es schließlich gerettet. 😉
…und Volume minus ist der Teil der Wippe der 2 Punkte hat, Volume + der Teil der nur einen Punkt als Markierung hat… Logisch? Nein!!! *WTH!!!*
Gefühlte 100 Interneitseiten und Tastenkombinationen später… (DANKE: http://forum.xda-developers.com/showpost.php?p=32374546&postcount=2)
With JB there is a change on the A700 (can’t test on A701):
Boot into recovery:
– Press [vol-] + [power]
– Once the tablet vibrated, let go [power] and keep [vol-].
– Now the tablet vibrates a second time, let go [vol-] and press [vol+] quick
– Once the text that appears on the screen („loading recovery kernel image“), let go [vol+].
Android Kontakte mit Owncloud synchronisieren
Nachdem ich mich in letzter Zeit recht intensiv mit dem Abkoppeln von den Bigplayern in Sachen Cloudservices beschäftige, habe ich mir heute angeschaut, wie ich denn meine Kontakte von meinem Android Smartphone in die ownCloud bringe.
Zuallererst muss natürlich die Kontakteapp in Owncloud installiert werden.
Einerseits testete ich das kostenlose CardDAVSync-free, das nur Kontakte synchronisieren kann.
Hier bin ich auf ein Problem gestoßen: Ändere ich in Owncloud den Namen des Kontaktes, ändert sich dieser nach der Synchronisierung am Smartphone nicht (jedenfalls nicht so, wie ich es erwartet habe).
Nehmen wir hierfür ein Beispiel: Ein Kontakt ist nur mit Vorname „Sonja“ gespeichert. Ich ändere in Owncloud-Kontakte im obigen Bereich den Kontakt auf „Test Sonja“ und synchronisiere.
Dennoch bleibt am Smartphone der Name zumindest bei der Kontaktliste (Anzeigename) auf Sonja stehen.
Geht man in die Detailansicht des Kontaktes, dann erkennt man, dass hier sehr wohl „Test Sonja“ hinterlegt ist.
Der Anzeigename in Owncloud entspricht nicht dem Vornamen und Nachnamen des Kontaktes im Smartphone. Das ist zumindest meine Annahme. Ändert man die Details direkt am Smartphone und synchronisiert erneut, funktioniert es wie erwartet.
Dies war der Grund weshalb ich noch eine kostenpflichtige Smartphone-App getestet habe – DAVDroid.
Beide Apps legen am Smartphone ein eigenes -dem Konto zugeordnetes- Adressbuch an. Im Falle von DAVDroid nennt sich das Adressbuch somit DAVdroid. Anfangs ist das Adressbuch noch leer.
Konfiguration der App
Grundsätzlich sollte https bei der Verbindung zum ownCloud-Server verwendet werden. Die Konfiguration ist eigentlich schnell erledigt. Man muss nur Username / Passwort und den richtigen „dav-pfad“ angeben.
Für Owncloud lautet dieser /remote.php/dav/ der komplette URL würde beispielsweise dann so lauten: https://owncloud.deinedomain.com/remote.php/caldav/
Anmerkung: Im obigen Beispiel wird angenommen, dass owncloud direkt per Subdomain „owncloud“ angesteuert werden kann, weshalb hier im Pfad /owncloud wegfällt.
Natürlich wird auch noch der ownCloud Benutzername und das Passwort von DAVDroid gefordert, um die Verbindung aufbauen zu können.
Details zur Konfiguration findet man auch auf der Website des Entwicklers.
Kontakte von GMAIL nach DAVDroid verschieben
Auf meinem Smartphone (Android 6.0.1) kopiere ich alle Kontakte von meinem Googlekonto zu DAVDroid, wobei ich die Kontakte jedoch auf meinem Googlekonto belasse (Backup).
Danach blende ich in der Kontakteapp nur die Kontakte von DAVDroid ein.
Synchronisierung anstossen
Auf dem PC bereits in Owncloud (Kontaktapp) eingeloggt, starte ich die Synchronisierung und beobachte dabei das Logfile meines Apachen (owncloud_access.log). Ich sehe etliche PUT Kommandos. Gut… Die Kontaktapp von Owncloud füllt sich mit Inhalten.
Alles funktioniert soweit, wie bei der Gratisapp auch.
ABER: Ich laufe wieder in selbiges Problem (siehe oben).
Ein Denkfehler meinerseits? Ein Konfigurationsfehler? ein Bug?
Ich weiß es im Moment nicht…