Fehlermeldungen in Nextcloud 14

kreatikar / Pixabay

Da sind sie wieder! Nach dem Upgrade auf Nextcloud 14 galt es auch hier wieder neu auftauchende Fehlermeldungen zu beseitigen. 

Nextcloud
Fehlermeldungen nach dem Upgrade auf Version 14

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

die vorhandene Zeile 

entfernt. Darunter fügt man an dieser Stelle

ein und auch die dritte Fehlermeldung verschwindet nach dem Neustart des Webservers.

Um das Datenbank-Problem zu lösen, wechselt man ich das Hauptverzeichnis der Nextcloud

und führt

aus. Die erfolgreiche Bestätigung sollte dann so aussehen:

Zum Schluss sind alle Überprüfungen bestanden und die Nextcloud darf wieder produktiv genutzt werden.

Nextcloud
Fehlermeldungen beseitigt – Alle Überprüfungen bestanden

Viel Spaß!

Fehlermeldungen nach Nextcloudinstallation

geralt / Pixabay

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.

Nextcloud
Fehlermeldungen nach der Installation

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.

Dort verändert man den bestehenden Eintrag

in

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 

installiert. Im Anschluss wird via

folgende Zeile hinzugefügt:

Um die Fehlermeldung zu PHP-OPcache zu eliminieren, öffnet man die php.ini

und trägt Folgendes am Ende der Datei ein:

Zum Schluss wird der Apache-Webserver neu gestartet.

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.

Dach trägt man in den Virtualhost der Webseite unter DocumentRoot

ein und startet den Webserver mit

neu.

Nextcloud
Fehlermeldungen beseitigt – Alle Überprüfungen bestanden.

Am Ende waren alle Warnungen beseitigt und alle Tests wurden erfolgreich bestanden.

Mail Relay für Mailcow Dockerized

Nachdem auf meinem neuen vServer ein Webserver und ein Mailserver installiert und eingerichtet waren, tauchte ein neues Problem auf. Meine Webseiten und meine Nextcloud konnten via PHP keine Mails mehr absetzen. Die Ursache hierfür liegt auch dieses Mal in der Konstellation meines Servers mit der installierten Container-Lösung Mailcow Dockerized, wo Postfix im Container seinen Dienst verrichtet und von dem Apache so nicht angesprochen werden konnte.

Was kann man tun?

Am einfachsten ist es in WordPress, Joomla! und der Nextcloud den Mailversand via SMTP einzurichten. Genau das hatte ich auch zur schnellen Lösung umgesetzt. Leider funktionierte das Ganze nicht wirklich mit Elgg

Wie löst man das Problem zufriedenstellend?

Ganz einfach, indem man ein Mail Relay einbaut. Dazu wird ein lokaler MTA für den Docker Host eingerichtet. Das klingt aber alles komplizierter als es tatsächlich ist.

Dazu habe ich Postfix installiert.

Postfix, Debian
Postfix Konfiguration

Postfix, Debian
Postfix Konfiguration – Internet Site
Postfix, Debian
Postfix Konfiguration – System mail name
Postfix, Debian
Postfix Konfiguration – System mail name – intux

Während der Installation wird man nach dem System mail name gefragt. Hier wurde der Hostname des Servers (intux) eingetragen. 

Vorsicht: Nicht die Domain eingeben!

Nach Abschluss der Installation, musste noch die /etc/postfix/master.cf geändert werden. Dazu wurde der SMTP Listener mit # auskommentiert.

Danach musste noch 172.22.1.1 als Relay Host hinzu gefügt und das Docker Interface aus inet_interfaces entfernt werden.

Nach einem Neustart von Postfix konnten nun wieder Systemmails via PHP von WordPress und Co. versendet werden.

Alle Änderungen werden übrigens in die /etc/postfix/main.cf geschrieben. Nur falls bei der Installation von Postfix mal etwas schief geht. 😉

Weiterführende Infos und Anleitungen findet man auf der Projektseite von Mailcow-Dockerized unter: https://mailcow.github.io/mailcow-dockerized-docs/

Und immer wieder Servercow

Mein Umstieg auf Debian 9

Aus IT-technischer Sicht sollte man Web- und Mailserver auf getrennten Systemen laufen lassen. Da ich aber meinen Server privat betreibe und das Ganze mehr ein Hobby ist, laufen bei mir Web- und Mailserver auf einem Host. 

vServer, Servercow
Übersicht der laufenden Prozesse mit htop

Angefangen hatte ich mit Debian 8 auf dem bisher meine Seite intux.de lief. Parallel dazu hatte ich einen Mailserver mit Mailcow 0.14 aufgesetzt. Beides arbeitete bisher ohne Probleme und es gab eigentlich keinerlei Bedarf hieran irgendetwas zu ändern, da Debian 8 als LTS noch bis Ende April 2020 unterstützt wird.

Da ich aber mein System auf die aktuelle Version Debian 9 Stretch anheben wollte, musste ich mir Gedanken machen, wie das am besten zu realisieren ist. Da es momentan kein Upgrade für Mailcow 0.14 gibt und diese Version nicht auf dem aktuellen Debian Stretch läuft, kam für mich nur die Container-Variante Mailcow Dockerized in Frage.

Ein Upgrade auf Debian 9 wäre natürlich möglich gewesen, jedoch habe ich mich dazu entschlossen Stretch auf einem separaten Server zu installieren und alle Dienste nacheinander rüber zu holen. Dieses Vorhaben konnte ich ohne Zeitdruck auf Servercow realisieren. Der grandiose Support von André Peters war hierbei mehr als hilfreich. Bei einigen Problemen hatte ich so einen kompetenten Ansprechpartner, der sehr schnell auf Anfragen reagierte.

Da Mailcow Dockerized autonom und aus dem System herausgelöst in einer eigenen Virtualisierung arbeitet, wär mein Apache 2 mit dem Webserver Nginx in Dockerized kollidiert. Hierzu war es notwendig einen Reverse Proxy auf dem Apache, wo mein Blog läuft, einzurichten. Des Weiteren konnten von meinem frischen System keine Mails über PHP abgesetzt werden. Auch hier musste ich mich in eine für mich neue Thematik, einen Local MTA, einarbeiten, welcher dann u.a. Systemnachrichten an Mailcow Dockerized zum Versenden übergibt. 

Fazit

Den Server parallel einzurichten und alle Dienste nach und nach umzuziehen stellte sich aus der Situation als die richtige Entscheidung heraus. Ich war so nicht gezwungen alles am Stück wieder zum Laufen zu bringen. Mailcow Dockerized ist leicht zu installieren und ohne ewige Konfiguration sofort einsatzbereit. Trotz zwei nun nebeneinander arbeitender Webserver läuft das gesamte System performanter als vorher. 

Ich habe mich zur Verwirklichung meiner kleinen Projekte vor fast 10 Monaten bewusst und aufgrund guter Kritiken für Servercow entschieden. Bei Problemen am Server und speziell mit Mailcow steht ein kompetenter Ansprechpartner zur Seite. Diesen Schritt habe ich zu keinem Zeitpunkt bereut. Sicher hat man mit einem eigenen Server einiges an Arbeit und Verantwortung auf dem Schirm, aber man ist dafür wesentlich flexibler. Dafür bietet Servercow ein gutes Zuhause.

hality.org

Startseite von hality.org

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ß!

Webadmin von ZNC nachträglich über SSL erreichbar machen

Als ich ZNC auf meinem Debian-Server installiert habe, hielt ich mich bei der Konfiguration an meine damalige Uberspace-Installation. Dort hatte ich die Standard-Abfrage

einfach nur bestätigt. Dies stellte nun kein gravierendes Problem dar. Im nachhinein war ich aber über den unverschlüsselten Zugang zum Webinterface via http://IP:Port nicht glücklich. Der Zugang über domain.tld:Port wurde logischerweise verwehrt.

Nun bin ich der Sache auf den Grund gegangen, warum ich das Webinterface nicht über domain.tld:Port erreiche. Hier verhinderte eine Kombination von dem Erzwingen von https und HSTS (HTTP Strict Transport Security) den Zugang zum Webinterface über intux.de. 

Der Entwickler rät davon ab die znc.conf im Editor zu bearbeiten. Stattdessen sollte hier das Webinterface zur weiteren Konfiguration genutzt werden. Dieses konnte ich ja, wie oben beschrieben, über http://IP:Port nutzen. Hier musste ich dann einen neuen Eintrag (anderer Port) in Listen Port(s) mit dem Häkchen SSL versehen. Über diesen Port ist dann nach dem Einpflegen von Let’s Encrypt das Webinterface via https erreichbar.

Ich verbinde mich nun mit mit dem ZNC-Bouncer via SSL mit:

vServer auf Servercow

Am 30.12.2016 mietete ich mir spontan einen vServer. Nach einigen Tagen der Einrichtung setzte ich einen Mailserver auf. Als alles zufriedenstellend lief, wurde schlussendlich mein Blog vom bisherigen Hoster mit rüber geholt. 

Bevor jedoch meine Unternehmung bzw. mein Projekt vServer startete, machte ich mir Gedanken, wo ich diesen mieten sollte. Da ich inzwischen einiges und nur positives über Servercow u.a. im OSBN gelesen hatte, war klar, dort werde ich es versuchen. Ein wirklicher Dauerbetrieb stand eigentlich nicht wirklich zur Debatte, sondern eher ein dreimonatiger Testlauf, um weitere Erfahrungen zu sammeln bzw. auszubauen. Da alles bisher so gut lief, werde ich jedoch den Server weiter betreiben.

Zu allererst wurde ein XMPP-Server, eine Nextcloud und ein IRC-Bouncer eingerichtet. Als das alles über eine eigens für dieses Unterfangen eingerichtete neue Domain lief, wagte ich mich an den aus meiner Sicht schwierigsten Part, den Mailserver.

Auch hier stellte sich heraus, dass Servercow die richtige Wahl für meine Bedürfnisse war. Der Betreiber und Tech-Blogger André Peters stellt mit Mailcow eine Mailserver-Suite, basierend auf Dovecot, Postfix, einem vorkonfigurierten Spamfilter sowie Virenschutz und weiterer Open-Source-Software, wie Roundcube und STARTTLS and SMTPS Support zur Verfügung. Ein sehr ansprechendes Web UI übernimmt nach dem Einrichten die User- und Server-Administration. Mailcow lässt sich ohne weiteres schnell, sicher und vor allem einfach aufsetzen. Die Mailcow-Mailserver-Suite ist für Debian 8 (Jessie) optimiert, unterstützt aber auch Ubuntu LTS 14.04 (Trusty Tahr) and Ubuntu LTS 16.04 (Xenial Xerus). Das kam mir sehr zu Gute, da ich mich ohnehin für Debian 8 als Server-Betriebssystem entschieden hatte. Zur Auswahl auf Servercow  stehen nicht nur große Betriebssystemvorlagen wie CentOS, Ubuntu, Fedora, FreeBSD, NetBSD sondern auch kleinere wie Alpine Linux oder Elastix. Andere Betriebssystem-ISOs sind auf Anfrage lt. Webseite problemlos einbindbar. 

Das Aufsetzen des Webservers Apache und der Umzug meiner Seite inkl. PIWIK waren zum Schluss nur noch Formsache.

Bei ein paar Kleinigkeiten musste ich jedoch den Support bemühen. Hierbei viel sofort positiv auf, wie schnell man sich kompetent und höflich den Problemen der Kunden annimmt. 

Als Bonus zu meinem Paket M und allen weiteren Konfigurationen stehen im Übrigen 150GB via FTP sowie Samba zur Verfügung.

Um einen kleinen optischen Eindruck zu gewinnen, habe ich ein paar Screenshots angehängt.

Screenshots – Servercow

Servercow – Information & Funktion
Servercow – Serversteuerung
Servercow – VPS-Panel
Servercow – Statistik
Servercow – Backups
Servercow – Storage-Server

Screenshots – Mailcow

Mailcow – Web UI
Mailcow – Admin-Zugang
Mailcow – Mail-Statistik
Mailcow – Spamfilter
Roundcube

Fazit

Mit Servercow habe ich einen sehr guten und fairen Server-Hoster gefunden, den ich bedenkenlos weiterempfehlen kann. Die 1 Gigabit-Anbindung sorgt für ordentlich Geschwindigkeit. Für Backups können drei Snapshots angelegt werden, bei Bedarf auch automatisch im wöchentlichen Intervall.

Prosody – Migrator

Vor ein paar Tagen habe ich nachträglich Prosody auf meinem Server an eine MySQL-Datenbank angebunden. Diese Funktion hat einige Vorteile gegenüber der herkömmlichen Speicherung der Daten im Datenverzeichnis. 

Die Anbindung an MySQL ist relativ einfach. Deshalb möchte ich hierauf nicht weiter eingehen.

Mit dem Prosody Migrator kann man nun den Altbestand der User in die Datenbank übernehmen. Der Pfad des Datenverzeichnisses ist in meinem Fall /etc/prosody/data. Zu beachten wäre, dass alle schon vorhandenen User-Daten dabei überschrieben werden.

Um mit der Migration zu beginnen, wechselt man in das Verzeichnis in dem der Ordner „data“ liegt. 

Von der Beispiel-Konfiguration sollte man vorhe eine Sicherung anlegen.

Nun öffnet man die Config und bearbeitet diese folgendermaßen:

Hierbei ist der Pfad (falls data woanders liegt) sowie die Zugangsdaten zur MySQL-Datenbank anzupassen. Das Ganze speichert man mit Ctrl + o und verlässt den Editor mit Ctrl + x. Nun migriert man mit 

alle bestehenden Accounts. Erscheint

Migrating…
Done!

war die Migration erfolgreich.

Viel Spaß!