Projekte

Fehlermeldungen in Nextcloud 14

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

# nano /etc/apache2/sites-available/nextcloud.conf

1	# nano /etc/apache2/sites-available/nextcloud.conf

die vorhandene Zeile

Header append X-FRAME-OPTIONS "SAMEORIGIN"

1	Header append X-FRAME-OPTIONS "SAMEORIGIN"

entfernt. Darunter fügt man an dieser Stelle

Header set Referrer-Policy "no-referrer-when-downgrade"

1	Header set Referrer-Policy "no-referrer-when-downgrade"

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

# /etc/init.d/apache2 restart

1	# /etc/init.d/apache2 restart

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

# cd /var/www/html/nextcloud

1	# cd /var/www/html/nextcloud

und führt

sudo -u www-data php occ db:add-missing-indices

1	sudo -u www-data php occ db:add-missing-indices

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

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.

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.

Viel Spaß!

Fehlermeldungen nach Nextcloudinstallation

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.

# nano /etc/apache2/apache2.conf

1	# nano /etc/apache2/apache2.conf

Dort verändert man den bestehenden Eintrag

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

Options Indexes FollowSymLinks

AllowOverride None

Require all granted

</Directory>

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

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

# apt install php-apcu

1	# apt install php-apcu

installiert. Im Anschluss wird via

# nano /var/www/html/nextcloud/config/config.php

1	# nano /var/www/html/nextcloud/config/config.php

folgende Zeile hinzugefügt:

'memcache.local' => '\\OC\\Memcache\\APCu',

1	'memcache.local' => '\\OC\\Memcache\\APCu',

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

# nano /etc/php/7.0/apache2/php.ini

1	# nano /etc/php/7.0/apache2/php.ini

und trägt Folgendes am Ende der Datei ein:

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

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.

# /etc/init.d/apache2 restart

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.

# a2enmod headers

1	# a2enmod headers

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

Header always set Strict-Transport-Security "max-age=15552000; preload"

1	Header always set Strict-Transport-Security "max-age=15552000; preload"

ein und startet den Webserver mit

# /etc/init.d/apache2 restart

1	# /etc/init.d/apache2 restart

neu.

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

hality.org

Unsere regionale Free and Open Source Software Community geht nun langsam ins zweite Jahr. Ich habe heute die Domain hality.org um ein weiteres Jahr verlängert.

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.

# apt install postfix

1	# apt install postfix

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.

# nano /etc/postfix/master.cf

1	# nano /etc/postfix/master.cf

#smtp inet n - y - - smtpd

1	#smtp inet n - y - - smtpd

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

# postconf -e 'relayhost = 172.22.1.1'
# postconf -e "mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"
# postconf -e "inet_interfaces = loopback-only"

# postconf -e 'relayhost = 172.22.1.1'

# postconf -e "mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"

# postconf -e "inet_interfaces = loopback-only"

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

# /etc/init.d/postfix restart

1	# /etc/init.d/postfix restart

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.

intux.de wird werbefrei

Ich habe mich dazu entschlossen künftig auf Bannerwerbung auf intux.de zu verzichten.

Viel Spaß!

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

Listen using SSL (yes/no) [no]:

1	Listen using SSL (yes/no) [no]:

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.

cat /etc/letsencrypt/live/intux.de/{privkey,cert,chain}.pem > /home/znc/.znc/znc.pem

1	cat /etc/letsencrypt/live/intux.de/{privkey,cert,chain}.pem > /home/znc/.znc/znc.pem

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

/connect intux.de/Port -ssl

1	/connect intux.de/Port -ssl

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

Screenshots – Mailcow

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.

# cd  /etc/prosody

1	# cd /etc/prosody

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

# cp migrator.cfg.lua migrator.cfg.lua_bak

1	# cp migrator.cfg.lua migrator.cfg.lua_bak

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

# nano migrator.cfg.lua

1	# nano migrator.cfg.lua

local data_path = '/etc/prosody/data';

input {
type = "prosody_files";
path = data_path;
}

mydatabase {
type = "prosody_sql";
driver = "MySQL";
database = "Name der Datenbank";
username = "Benutzername der Datenbank";
password = "Passwort der Datenbank";
host = "localhost";
}
--[[

input {
type = "prosody_files";
path = data_path;
}
output {
type = "prosody_sql";
driver = "SQLite3";
database = data_path.."/prosody.sqlite";
}

]]

local data_path = '/etc/prosody/data';

input {

type = "prosody_files";

path = data_path;

}

mydatabase {

type = "prosody_sql";

driver = "MySQL";

database = "Name der Datenbank";

username = "Benutzername der Datenbank";

password = "Passwort der Datenbank";

host = "localhost";

}

--[[

input {

type = "prosody_files";

path = data_path;

}

output {

type = "prosody_sql";

driver = "SQLite3";

database = data_path.."/prosody.sqlite";

}

]]

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

# prosody-migrator input mydatabase

1	# prosody-migrator input mydatabase

alle bestehenden Accounts. Erscheint

Migrating…
Done!

war die Migration erfolgreich.

Viel Spaß!