Falls ddclient nicht mehr die IP-Adresse mit dem entsprechenden DynDNS-Anbieter abgleicht, kann das Stoppen des Dienstes und der Neustart mit der Option –force eventuell helfen:
|
1 2 |
sudo /etc/init.d/ddclient stop sudo ddclient --force |
Siehe hierzu auch: https://intux.de/2016/04/raspberry-pi-3-mit-dyndns/
Da sind sie wieder! Nach dem Upgrade auf Nextcloud 14 galt es auch hier wieder neu auftauchende Fehlermeldungen zu beseitigen.
Der „X-Frame-Options“-HTTP-Header ist nicht so konfiguriert, dass er „SAMEORIGIN“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das hinzufügen von Indizes in großen Tabellen einige Zeit in Anspruch nehmen wird, wurden diese nicht automatisch erzeugt. Durch das Ausführen von „occ db:add-missing-indices“ können die fehlenden Indizes manuell hinzugefügt werden, während die Instanz weiter läuft. Nachdem die Indizes hinzugefügt wurden, sind Anfragen auf die Tabellen normalerweise schneller.
- Fehlender Index „share_with_index“ in der Tabelle „oc_share“.
- Fehlender Index „parent_index“ in der Tabelle „oc_share“.
- Fehlender Index „fs_mtime“ in der Tabelle „oc_filecache“.
Der „Referrer-Policy“ HTTP-Header ist nicht gesetzt auf „no-referrer“, „no-referrer-when-downgrade“, „strict-origin“ oder „strict-origin-when-cross-origin“. Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.
Um die erste Fehlermeldung zu beseitigen, wurde im Virtual Host mit
|
1 |
# nano /etc/apache2/sites-available/nextcloudcloud.conf |
die vorhandene Zeile
|
1 |
Header append X-FRAME-OPTIONS "SAMEORIGIN" |
entfernt. Darunter fügt man an dieser Stelle
|
1 |
Header set Referrer-Policy "no-referrer-when-downgrade" |
ein und auch die dritte Fehlermeldung verschwindet nach dem Neustart des Webservers.
|
1 |
# /etc/init.d/apache2 restart |
Um das Datenbank-Problem zu lösen, wechselt man ich das Hauptverzeichnis der Nextcloud
|
1 |
# cd /var/www/html/nextcloud |
und führt
|
1 |
sudo -u www-data php occ db:add-missing-indices |
aus. Die erfolgreiche Bestätigung sollte dann so aussehen:
|
1 2 3 4 5 6 7 |
Check indices of the share table. Adding additional share_with index to the share table, this can take some time... Share table updated successfully. Adding additional parent index to the share table, this can take some time... Share table updated successfully. Adding additional mtime index to the filecache table, this can take some time... Filecache table updated successfully. |
Zum Schluss sind alle Überprüfungen bestanden und die Nextcloud darf wieder produktiv genutzt werden.
Fehlermeldungen beseitigt – Alle Überprüfungen bestandenViel Spaß!
Nach einer frischen Installation von Nextcloud hat man i.d.R. mit einigen Fehlermeldungen zu kämpfen. Die Suche nach den Problemlösungen beschäftigt mich dann immer eine ganze Weile. Aus diesem Grund habe ich einfach einmal aufgeschrieben, was ich bei der letzten Installation alles noch erledigen musste.
Hier die Sicherheits- & Einrichtungswarnungen nach der Installation:
Ihr Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, Ihren Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass Sie es aus dem Document-Root-Verzeichnis des Webservers herausverschieben.
Der Zugriff auf diese Site erfolgt über HTTP. Es wird dringend geraten, den Server so zu konfigurieren, dass er stattdessen nur HTTPS akzeptiert, wie es in den Sicherheitshinweisen beschrieben ist.
Es wurde kein PHP-Memory-Cache konfiguriert. Zur Erhöhung der Leistungsfähigkeit kann ein Memory-Cache konfiguriert werden. Weitere Informationen finden Sie in der Dokumentation.
Bitte überprüfen Sie noch einmal die Installationsanleitungen und kontrollieren Sie das Protokoll auf mögliche Fehler oder Warnungen.
Der PHP-OPcache ist nicht richtig konfiguriert. Für eine bessere Leistung empfiehlt es sich folgende Einstellungen in der php.ini vorzunehmen:opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
Dem Datenverzeichnis entzieht man wie folgt die Erreichbarkeit aus dem Internet. Dazu öffnet man die /etc/apache2/apache2.conf.
|
1 |
# nano /etc/apache2/apache2.conf |
Dort verändert man den bestehenden Eintrag
|
1 2 3 4 5 |
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory> |
in
|
1 2 3 4 5 |
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> |
Die Umstellung auf HTTPS wurde nach der Anleitung „Let’s Encrypt auf dem Raspberry Pi“ durchgeführt.
Den PHP-Memory-Cache richtet man ein, indem man die benötigten Pakete via
|
1 |
# apt install php-apcu |
installiert. Im Anschluss wird via
|
1 |
# nano /var/www/html/nextcloud/config/config.php |
folgende Zeile hinzugefügt:
|
1 |
'memcache.local' => '\\OC\\Memcache\\APCu', |
Um die Fehlermeldung zu PHP-OPcache zu eliminieren, öffnet man die php.ini
|
1 |
# nano /etc/php/7.0/apache2/php.ini |
und trägt Folgendes am Ende der Datei ein:
|
1 2 3 4 5 6 7 |
opcache.enable=1 opcache.enable_cli=1 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.memory_consumption=128 opcache.save_comments=1 opcache.revalidate_freq=1 |
Zum Schluss wird der Apache-Webserver neu gestartet.
|
1 |
# /etc/init.d/apache2 restart |
Nun erhielt ich die nächste Fehlermeldung.
Der „Strict-Transport-Security“-HTTP-Header ist nicht auf mindestens „15552000“ Sekunden eingestellt. Für mehr Sicherheit wird das Aktivieren von HSTS empfohlen, wie es in den Sicherheitshinweisen erläutert ist.
Bitte überprüfen Sie noch einmal die Installationsanleitungen und kontrollieren Sie das Protokoll auf mögliche Fehler oder Warnungen.
Diese beseitigt man indem man das Header-Modul für den Apache2 aktiviert.
|
1 |
# a2enmod headers |
Dach trägt man in den Virtualhost der Webseite unter DocumentRoot
|
1 |
Header always set Strict-Transport-Security "max-age=15552000; preload" |
ein und startet den Webserver mit
|
1 |
# /etc/init.d/apache2 restart |
neu.
Am Ende waren alle Warnungen beseitigt und alle Tests wurden erfolgreich bestanden.
Gestern habe ich das erste Mal das offizielle 7″ Touchscreen für den Raspberry Pi verbauen dürfen. Das Ganze war recht schnell und unkompliziert bewerkstelligt (siehe Video von Maker-Tutorials.com). Für den späteren Einsatz empfehle ich hierzu das entsprechende Bundle, bestehend aus Gehäuse und Touchscreen.
Zu beachten ist dann, dass das Display per Befehl um 180° zu drehen ist, da es sonst im Gehäuse auf dem Kopf steht. Dazu wird mit
|
1 |
sudo nano /boot/config.txt |
|
1 |
lcd_rotate=2 |
an das Ende der Datei eingetragen und mit Ctrt + o gespeichert. Nach dem Verlassen des Editors mit Ctrl + x wird der Rpi rebootet.
Quelle: YouTube
Meine Empfehlungen
Heute möchte ich ein wenig Werbung für die regionale Open Source Community von Halle (Saale) machen. Ende Januar 2016 hatten Andreas und ich die Idee eine Online-Community für Gleichgesinnte zu gründen. Im Vordergrund sollte der Gedankenaustausch rund um freie und quelloffene Software stehen.
Hierzu haben wir am 10.02.2017 den Grundstein gelegt. Es wurde damit begonnen ein kleines soziales Netzwerk unter hality.org aufzubauen. Daran teilnehmen kann natürlich jeder! Hierbei spielt keine Rolle ob ihr Hallenser seid oder aus einer anderen Ecke der Republik kommt.
Um die Community etwas lebhafter zu gestalten, möchten wir natürlich auch Treffen organisieren. Dabei soll der Fokus auf freier Software liegen. Installationshilfen sowie Workshops sind geplant.
Unter XMPP und IRC stehen entsprechende Chaträume bereit.
XMPP: hality@conference.intux.de
IRC: #intux
Viel Spaß!
Seit ca. vier Jahren habe ich auf meinen Raspberry Pi eine eigene Cloud installiert. Anfangs war es mehr oder weniger eine reine Testumgebung. Mittlerweile möchte ich aber auf die Möglichkeit, Daten zu Hause in der eigenen Wolke zu speichern, nicht mehr verzichten. Inzwischen läuft eine Nextcloud 11.0.2 auf einem Raspberry Pi 3 Modell B.
Vor einem halben Jahr bin ich dann noch einen Schritt weiter gegangen. Meine Kontakte, Kalender und Aufgaben werden ebenfalls über die Nextcloud mit meinem Smartphone und Notebook synchronisiert. Der Vorteil hierbei: Google bleibt außen vor. Zur Synchronisation setze ich mittlerweile DAVdroid in Verbindung mit der App Calendar Color ein. Des Weiteren werden Aufgaben mit der App Open Tasks bearbeitet. Natürlich kommt auch die eigentliche Applikation Nextcloud zum Einsatz. Diese Apps sind alle kostenlos auf F-Droid erhältlich. Wer den Entwicklern etwas Geld zukommen lassen will, kann dies natürlich direkt tun.
Mit ein wenig Willen und Lust zum Basteln ist die eigene Cloud schnell installiert und einsatzbereit. Hier kurz eine Liste der von mir eingesetzten Komponenten:
Von Außen erreiche ich die Nextcloud über eine auf INWX eingerichtete DynDNS-Adresse. Um den Zugang aus dem Internet etwas zu härten, verwende ich seit Kurzem eine Zwei-Faktor-Authentifizierung über den Google Authenticator.
Vorsicht: Bei der Einrichtung sind die Backup-Codes unbedingt zu sichern! Hier besteht die Gefahr, dass man sich ungewollt aussperrt.
Vor einiger Zeit fiel mir auf, dass mein Domain-Verwalter INWX auch DynDNS anbietet. Zwar läuft das DynamicDNS noch im Beta-Stadium, trotzdem funktioniert es bestens mit meinem Raspberry Pi. Aufbauend auf dem Artikel „Raspberry Pi 3 mit DynDNS“ habe ich nun die /etc/ddclient.conf folgendermaßen konfiguriert:
|
1 2 3 4 5 6 7 8 9 10 |
# Configuration file for ddclient generated by debconf # # /etc/ddclient.conf protocol=dyndns2 use=web web=checkip.dyndns.org server=dyndns.inwx.com login=Benutzername password='Passwort' xxxxx.intux.de |
Viel Spaß!
Mit einer Passwortänderung die unangenehme Folgen hatte, musste ich letzte Woche kämpfen. Nach einem routinemäßigen Austausch des Nextcloud-Passworts stellte ich fest, dass sich der Client am Notebook nach dem Neustart nicht mehr mit meiner eigenen Cloud verbunden hat. Dieser Umstand war nicht schön, beunruhigte mich aber nicht weiter. Am Smartphone traten dann aber ähnliche Verbindungsprobleme auf. Auch der Nextcloud-Cliend für Android konnte nicht mehr auf den Raspberry Pi zugreigen.
Sicherheitshalber wurde das neue Passwort meinerseits nochmal gecheckt. Dabei fiel auf, dass beim Login am Webinterface sehr viel Zeit verging, man sich danach aber wie gewohnt in der Cloud bewegen konnte. Ein wenig Recherche brachte dann die Lösung. Der durch Bruteforce-Attacken geschützte Zugang musste für die entsprechende IP zurück gesetzt bzw. entfernt werden. Dazu werden die IP-Einträge des Clients aus der Tabelle oc_bruteforce_attempts der MySQL-Datenbank gelöscht (xx.xx.xx.xx durch gesperrte IP ersetzen).
|
1 |
DELETE FROM oc_bruteforce_attempts WHERE ip = 'xx.xx.xx.xx'; |
Anschließend konnten alle Clients, wie zuvor problemlos auf die Nextcloud zugreifen.
Vor über einem Monat habe ich einen Test gestartet, wobei nun alle Kontakte, Termine und Dateien meines Smartphones mit einem Raspberry Pi synchronisiert werden. Dazu wurde die Standard-Synchronisation dieser Dienste zu Google deaktiviert.
Auf dem Raspberry Pi läuft ein aktuelles Raspbian Jessie. Die Ports 21, 22, 80 und 443 wurden zu diesem Zweck (FTP, SSH, HTTP und HTTPS) am heimischen Router geöffnet. Um nun von außen einen Zugang zu bekommen, nutze ich den Dienst NoIP. So kann ich mit einer festen Internetadresse über die sich ständig ändernde öffentliche IP auf meinem Raspberry Pi zugreifen. Der RasPi gleicht diese IP mit dem installierten ddclient ab. Weiterhin sind der Webserver Apache2 und eine ownCloud installiert. Letztere dient der Speicherung der zuvor erwähnten Daten. Das Ganze wurde mit einem Let’s Encrypt Zertifikat verschlüsselt.
Um diese Daten dann mit der Cloud zu synchronisieren, nutze ich mit dem Smartphone die drei kostenpflichtigen Apps CardDAV-Sync, CalDAV-Sync und FolderSync. Am PC synchronisiert Debian 8 die Daten mit dem ownCloud Client. Kontakte und Termine werden im Mail-Programm Evolution abgegriffen.
Wie läuft das alles nun rückblickend?
Eigentlich erstaunlich gut und ohne Probleme meinerseits. Ein zwischenzeitlicher Ausfall, hatte mich aber kurzzeitig hierbei aus der Bahn geworfen. Mein Internet-Provider stellte ohne Ankündigung meinen Anschluss auf Port and Address Translation (PAT). Dabei war es nicht mehr möglich über die öffentliche IP auf mein Heimnetz zuzugreifen. Erst nach Rücksetzung durch den Support auf Network Address Translation (NAT) konnte ich meine Cloud wieder erreichen.
Ja, es geht auch ohne Google, wenn man die Daten des Smartphones sichern möchte. Mit dieser Heim-Lösung bin ich im Moment sehr zufrieden. Die Anschaffungs- und Stromkosten eines Raspberry Pi inkl. Zubehör halten sich in Grenzen. Zudem nutze ich eine 64GB MicroSD, die wirklich sehr viel Spielraum zur Datensicherung bietet.
Übrigens gibt es CardDAV-Sync, CalDAV-Sync und FolderSync auch in kostenlosen Light-Versionen. Diese verfügen aber nicht über den vollständigen Funktionsumfang.
Ich habe hier anhand dieses Beispiels eine Einkaufsliste der eingesetzten Hardware zusammen gestellt.
Wer mich kennt, weiß, dass ich nicht gerade ein Freund der Fliegerei bin. Jetzt hat mich aber eine Geschichte der ganzen Sache etwas näher gebracht. Hierbei handelt es sich um Flightradar24. Dieser Dienst zeigt die Bewegung sämtlicher Flugzeuge am Himmel.
Flightradar24 finanziert sich zu einem Großteil durch Werbung. Diesen störenden Nebeneffekt kann man aber mit ein wenig technischem Aufwand umgehen.
Bei der Suche nach einem weiteren spannenden Projekt für den Raspberry Pi, habe ich nun entdeckt, dass man sich an Flightradar24 beteiligen und so in den Genuss eines werbefreien Premium-Business-Accounts kommen kann.
Was wird hierzu benötigt?
Zu allererst sollte man grundsätzlich bereit sein, Funksignale der sich im näherem Luftraum befindlichen Flugzeuge über den Raspberry Pi zu empfangen und diese an Flightradar24 zu übermitteln.
Viel technischen Schnick-Schnack braucht man dazu nicht. Es reicht ein Raspberry Pi, mit einer entsprechenden MicroSD die genug Platz für das OS Raspbian bietet. Ich verwende hier eine Speicherkarte mit 8GB. Diese verfügt über genug Reserven. Des Weiteren wird ein DVB-T Stick mit einem RTL2832U/R820T-Chip angeschlossen, welcher ADS-B Signale (Automatic Dependent Surveillance – Broadcast) empfangen kann. Eine Verbindung des Einplatinencomputers zum Internet ist Voraussetzung.
Ist Raspbian installiert, wird folgender Befehl ausgeführt:
|
1 |
sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)" |
Hierbei wird das kleine Programm dump1090 installiert und konfiguriert. Es werden dabei Daten wie eMail-Adresse, Standort (Lat, Lon, Hight) sowie der verwendete Empfänger (z.B. Receiver selection – 1) abgefragt. Um die Daten dann auch entsprechend darstellen zu können, muss die Multilateration (MLAT) hier aktiviert werden. Nach Abschluss der Konfiguration erhält man von Flightradar24 eine eMail mit dem Sharing Key und dem Code der neu angelegten Empfangsstation.
Den Business-Account kann man nun mit der bei Flightradar24 während der Konfiguration hinterlegten eMail-Adresse anlegen und aktivieren.
Die lokale Hauptseite der Empfangsstation erreicht man über http://IP:8754. In meinem Fall ist das http://192.168.1.60:8754. Von dort gelangt man zur Liste der getrackten Flugzeuge und auch zu den Einstellungen. Des Weiteren besteht die Möglichkeit von hieraus dump1090 zu beenden.
Um nun die von der Station getrackten Flugzeuge sichtbar zu machen, gibt man in den Einstellungen http://IP:8754/settings.html unter „Process arguments“ folgende Zeile ein.
|
1 |
--net --net-http-port 8080 |
Nun werden alle empfangenen Flugzeuge über http://IP:8080 in Google Maps oder OpenStreetMap dargestellt.
Nach jedem Neustart des Raspberry Pi wird auch dump1090 automatisch ausgeführt. Hat man jedoch den Dienst beendet, so lässt sich dieser über
|
1 |
sudo service fr24feed restart |
wieder aktivieren.
Wenn dump1090 längere Zeit (48h) keine Daten übermittelt, wird der Account stufenweise herunter gefahren bis der Raspberry Pi wieder an Flightradar24 Signale sendet. Nach 7 Tagen ohne Signal steht der Account auf Basic. Hierzu findet man Folgendes:
If You Are Sharing Data with Flightradar24
We’ve upgraded your existing Premium account to our new Business subscription! In addition to the detailed live flight information included as part of our Gold subscription, our Business subscription also includes access to a full year of historical data and the ability to download individual flights in KML or CSV format. You also have access to our new Airport and Fleet views. You can learn more about our Business subscription in our introductory blog postor by visiting our Premium page.
Your Business subscription will remain active as long as you are sharing data with Flightradar24. If you stop sharing data, your subscription will be downgraded to Gold after 48 hours. If we have not received data from you for 7 days, your subscription level will return to Basic.
