ubuntuusers.de

26. September 2017

Ich habe mir angewöhnt im Browser Suchanfragen über Kürzel zu stellen. Somit suche ich beispielsweise mit “g wayland arch linux” nach Wayland unter Arch Linux. Oder mit “ddg hamburger teespeicher” suche ich mit DuckDuckGo nach meinem bevorzugten Teehändler dem Hamburger Teespeicher. Nur meine Searx-Instanz habe ich bisher direkt aufgerufen.

Das habe ich jetzt einmal geändert und mir für meine eigene Searx-Instanz ebenfalls einen Suchmaschineneintrag erstellt. Im Grunde genommen ist es kein Hexenwerk und in unter einer Minute erledigt.

searxsuche.png

Dieses Beispiel zeigt das Hinzufügen einer Suchmaschine unter Vivaldi (ALT+P -> Suche). Unter Chrome/Chromium sollte es vermutlich gleich bzw. ähnlich aussehen. Zu anderen Browsern kann ich keine Aussage treffen.

Als URL geben wir die Adresse ein, unter der die betreffende Searx-Instanz erreichbar ist. An deren Ende fügen wir dann noch /?q=%s hinzu. Das %s ist hier ein Platzhalter für unsere Suchbegriffe. Als Kürzel habe ich mal sx genommen, da “s” bereits für Startpage vorgesehen ist. Abschließend noch schnell auf Hinzufügen klicken und fertig. Wer will, kann vorher den Eintrag als Standard setzen. Nun kann man direkt in der Adresszeile mit dem Kürzel sx eine Searx-Installation befragen.

Searx bietet auch die Möglichkeiten diverse Kategorien zu durchsuchen. Wie zum Beispiel unter anderem Nachrichten, Musik, IT oder Dateien. Nehmen wir mal an, dass man einen Eintrag für die Kategorie “Nachrichten” erstellen will. Hierzu müssen wir obigen Link einfach erweitern, so dass aus http://searx.fryboyter.de/?q=%s&categories=news wird. Anstelle von news trägt man hier einfach die gewünschte Kategorie ein. Hierzu muss man allerdings die englische Bezeichnung nutzen.

Ach ja… Der genannte Link ist nur ein Beispiel und funktioniert nicht. Wer sich die Metasuchmaschine einmal ansehen will, findet unter https://github.com/asciimoo/searx/wiki/Searx-instances eine Liste von Instanzen. Hier dürfte searx.me mit die bekannteste Adresse sein. Für die Installation einer eigenen Instanz lohnt sich ein Blick in die Anleitung von mdosch. Diese ist zwar für Uberspace gedacht, aber ich denke man hiermit auch Searx bei anderen Anbietern installieren.

24. September 2017

Lokalen Datenbanken werden beim Löschen der Firefox-Chronik nicht gelöscht. Aus Datenschutz-Sicht kann dies als Problem erachtet werden. Mit Firefox 56 behebt Mozilla das Problem, Firefox 57 kommt mit einer besseren Speicher-Verwaltung.

Firefox erlaubt ein bequemes Löschen der Chronik, Offline-Daten sowie weiterer Spuren der Benutzung, entweder über einen bestimmten Zeitraum oder komplett. Darunter fallen allerdings keine lokalen Datenbanken, wie sie in Zusammenhang mit moderneren Webtechnologien wie IndexedDB oder Local Storage fallen. An dem Problem ist nichts neu. Ganz im Gegenteil, bereits vor vielen Jahren war dies bekannt, ohne dass dem Thema seitens Mozilla oder der Öffentlichkeit besonders viel Aufmerksamkeit geschenkt worden wäre. Nachdem das Problem in der vergangenen Woche wie aus dem Nichts plötzlich erneut zum Thema gemacht und medial aufgegriffen wurde, hat sich Mozilla dem Thema angenommen und eine außerordentlich schnelle Lösung erarbeitet: bereits mit Firefox 56, welcher in der kommenden Woche veröffentlicht werden wird, wird Firefox lokale Datenbanken löschen, wenn der Nutzer Offline-Daten der Webseite löschen lässt.

Sogar eine mögliche Umsetzung in Firefox ESR 52 wird derzeit diskutiert, auch wenn aufgrund der fortgeschrittenen Zeit und des daraus resultierenden Risikos aus Release-Sicht denkbar ist, dass das Problem erst im November mit Firefox ESR 52.5 gelöst wird. Nichtsdestominder wäre dies sehr positiv zu bewerten, weil ESR-Versionen normalerweise nur Bugfixes und Sicherheits-Updates erhalten und dieses Problem auch kein neues Problem von Firefox 52 ist.

Unabhängig von dieser Verbesserung für Firefox 56 und ggfs. Firefox ESR 52 wird Mozilla Firefox 57 mit einer verbesserten Speicher-Verwaltung ausstatten. Diese war bereits für Firefox 57 implementiert, ehe das ganze Thema medial neu aufgegriffen worden ist.

Ab Firefox 57 zeigt der Mozilla-Browser direkt in den Firefox-Einstellungen einen Button an, um derartige Daten komplett zu löschen. Außerdem neu in den Einstellungen ist eine Liste aller Webseiten, welche Daten gespeichert haben, inklusive Angabe der bisherigen Speicherbelegung sowie Möglichkeit, die Daten nur für einzelne Webseiten zu löschen.

Lokale Datenbanken löschen - Firefox 57

Der Beitrag Datenschutz-Fix: Löschen lokaler Datenbanken ab Firefox 56 möglich erschien zuerst auf soeren-hentzschel.at.

Mittlerweile verstecken sich viele Zusatzinformationen wie Hilfeeinträge in Programmen, oder Statusinformationen bei einem Klick auf Tray-Icons auf Webseiten. Ein Klick auf einen solchen Link, z.B. in der Nextcloud App o.ä. soll dann den im System eingestellten Standardbrowser öffnen und die verlinkte Webseite anzeigen.

Bei meinem Desktop mit Antergos Linux hatte ich leider die Situation, dass solche Links immer im Firefox geöffnet wurden, obwohl Chromium eigentlich als Standardbrowser im System gesetzt war.

Nach einigem suchen und probieren, habe ich herausgefunden dass in der MIME-Type Zuordnung des Users im Homeverzeichnis unter ~/.config/mimeapps.list, allen HTML Dateien der Browser Firefox zugeordnet war. Diese Zuordnung schlägt wohl manchmal die Standardeinstellung über die GUI.

Um dies zu ändern müssen in dieser Datei alle Einträge mit firefox.desktop in chromium.desktop geändert werden.
Dies kann man elegant mit der Suchen-und-Ersetzen-Funktion z.B. von Gedit erledigen.

gedit ~/.config/mimeapps.list

 

 

unter Ubuntu hätte man dies wahrscheinlich über das Alternativen-System lösen können, mit einem

sudo update-alternatives --config x-www-browser

Dieser Text ist lizensiert unter einer Creative Commons Namensnennung 4.0 International Lizenz.
Titelbild “pfeil-richtung-browser-web-www-1773950” von Pixabay steht unter Creative Commons CC0

Antergos: Links werden nicht im Standardbrowser geöffnet ist ein Beitrag von techgrube.de.

Vor einigen Wochen habe ich im Rahmen eines PC-Upgrades auch wieder mein Arch Linux-System neu installiert.

Bei der Benutzung von LibreOffice fiel dann auf, dass als Standard für neue Seiten das US-Format Letter eingestellt war. LibreOffice selber bietet keine einfache Möglichkeit, das Standardpapierformat zu ändern. Vor 5 Jahren hatte ich schon einmal ein ähnliches Problem. Die Lösung ist bis heute die gleiche: in der Datei

/etc/papersize
wird das Papierformat zentral für das System eingestellt. Möchte man das in Deutschland übliche Format DIN A4 einsetzen, ersetzt man den Inhalt durch:

a4

Nach einem Neustart sollten die Änderungen dann aktiviert sein. Weitere Informationen und Konfigurationsoptionen befinden sich unter man papersize.

22. September 2017

Mit Piwik kannst Du vernünftige Web-Statistiken erfassen – ganz ohne Google.

Besonders umfangreiche Daten brauch ich für mein Blog nicht – ich verkauf nichts und ob ich ein paar Leser mehr oder weniger habe, ist mir relativ egal. Ein Plugin wie Statify würde eigentlich reichen. Da kann ich sehen, welcher Inhalt gerade gelesen wird. Piwik bietet aber ein paar weitere Möglichkeiten, die ich mit den Jahren zu schätzen gelernt habe.

Die Einrichtung ist simpel

Piwik ist Open Source und eine PHP-Anwendung, die man installieren kann, wie zum Beispiel WordPress. Beim Schleswig-Holsteinischen Datenschutz gibt es Tipps zur Datenschutz-konformen Konfiguration. Für WordPress gibt es das Plugin WP-Piwik, mit dem man den nötigen Tracking-Code sehr einfach einbinden kann. Ab da zählt Piwik die Zugriffe: Welcher Besucher surft mit welchem Browser auf welcher Seite, was klickt der da und wir lange liest der.

Ich bastel häufiger an meiner Seite herum und die Statistik bietet auch einen Hinweis darauf, ob irgendwas grundsätzlich schief läuft – wenn zum Beispiel meine Fehlerseite plötzlich dauernd aufgerufen wird. Ich finde es aber auch interessant zu sehen, ob ich Besucher von anderen Seite als Google, Twitter, Facebook bekomme. Manchmal werden ich in irgendwelchen Blog-Artikeln verlinkt – das würde ich sonst gar nicht mitbekommen.

Seit Juli 2009 läuft meine Statistik und ich kann sehen, dass ich zwischenzeitlich fast doppelt so viele Besucher auf der Seite hatte – dabei sind die Inhalte die gleichen, nur halt ein paar Jahre mehr Artikel. Ich glaube, das hat damit zu tun, dass ich eine Zeit lang viel über den Raspberry Pi gebloggt hab, als es zu dem noch nicht viel im Netz gab.

Es zeigt sich, dass es Artikel gibt, die über Jahre gut laufen. Das sind diese Artikel, in denen ich irgendetwas erkläre. Artikel mit einem aktuellen Bezug können in ein paar Tagen sehr viele Zugriffe bekommen und dann nie wieder.

Google Alternative

All diese Infos kann man sicher auch bei Google Analytics bekommen und auch Google Analytics kann man inzwischen Datenschutz-konform einrichten. Ich hab meine Daten aber immer ganz gerne bei mir. Die Installation von Piwik ist einfach und die Updates laufen seit Jahren mit einem einfachen Klick – so einfach wie bei WordPress.

Was ist los auf meiner Website?

21. September 2017

Im November wird Mozilla Firefox 57 veröffentlichen, den größten und wohl auch wichtigsten Release in der Geschichte von Firefox. Nun hat Mozilla eine erste offizielle Beta-Version von Firefox 57 veröffentlicht, welche eine Vorschau auf diese wichtige Firefox-Version gibt.

Mozilla wird voraussichtlich im November dieses Jahres Firefox 57 veröffentlichen. Firefox 57 wird dabei kein gewöhnlicher Release sein, denn mit Firefox 57 wird Mozilla einige sehr bedeutende Änderungen einführen, was diese Version zu einem Meilenstein in der Geschichte von Firefox und Wegweiser für die Zukunft des Mozilla-Browsers machen wird.

Lese-Tipp: Kommentar: Wieso Firefox 57 Mozillas bester Release aller Zeiten wird

Einen ausführlichen Überblick über alle wesentlichen Veränderungen von Firefox 57 wird es November auf diesem Blog geben, wenn der letzte Feinschliff an Firefox 57 vorgenommen wurde. Bis dahin sei dieser Kommentar zu Firefox 57 allen Lesern ans Herz gelegt, welcher eine Idee darüber gibt, was uns Ende des Jahres erwartet.

Dass Firefox 57 etwas Besonderes ist, zeigt sich auch an der Auslieferung der ersten Beta-Version. Mit der geplanten Veröffentlichung von Firefox 56 am 28. September würde die erste Beta-Version von Firefox 57 normalerweise frühestens am 29. September erscheinen. Stattdessen hat Mozilla bereits jetzt eine erste Beta-Version von Firefox 57 veröffentlicht. Eine weitere Besonderheit: diese Beta-Version ist nicht auf dem regulären Beta-Kanal verfügbar, sondern ausschließlich für Nutzer der Developer Edition von Firefox.

Download Mozilla Firefox 57 Beta 1

Passend zum neuen Logo von Firefox 57 zeigt sich die Developer Edition von Firefox nun auch in einem neuen Logo.

Firefox-Logo Developer Edition

Auch die zweite Beta-Version von Firefox 57 wird ausschließlich auf dem Kanal der Developer Edition vertrieben werden. Auf dem regulären Beta-Kanal geht es dann mit Firefox 57 Beta 3 zum erwarteten Zeitpunkt los.

Mit Firefox 57 Beta 3 wird Mozilla dann übrigens auch die Wortmarke im Info-Dialog von „Firefox“ auf „Firefox Quantum“ ändern. Unter dem Projektnamen Quantum liefen zahlreiche Verbesserungen von Firefox und seiner Gecko-Engine, welche schließlich in Firefox 57 gipfeln.

Der Beitrag Erste Beta-Version von Firefox 57 kann getestet werden erschien zuerst auf soeren-hentzschel.at.

20. September 2017

Nicht erst seit Ubuntu 16.04 dürfte der apt Befehl bekannt sein, allerdings hat er seit dem einen höheren Bekanntheitsgrad erreicht.

Doch wo genau liegen die Unterschiede von apt und apt-get?

Beide basieren auf dpkg, dem Paketmanagement von Debian (Debian Package Manager).

APT (Advanced Package Tool) ist nichts weiter als ein Kommandozeilen Tool, welches mit dpkg interagiert. 

aptitude-apt-get-apt-Commands

Um Benutzern die Arbeit mit Paketen einfacher zu machen, wurde apt-get ins Leben gerufen, eine Weiterentwicklung davon ist apt. Beide können als Frontends für dpkg angesehen werden.


Das neuere apt bietet grafische Elemente (es lebe der farbige Fortschrittsbalken) und soll Kommandos wie apt-cache und apt-get unter einem Hut vereinen.

apt-fortschrittsbalken

Überblick apt Befehle

Einen Überblick der alten und neuen Befehle habe ich euch unten zusammengestellt.

apt vs. apt-get
apt Kommando apt-get Kommando Funktion
apt install apt-get install Pakete installieren
apt remove apt-get remove Pakete deinstallieren
apt list --upgradable -- Anstehende Updates anzeigen
apt list dpkg list Pakete auflisten
apt purge apt-get purge Pakete und Konfiguration entfernen
apt update apt-get update Repository aktualisieren
apt upgrade apt-get upgrade Anstehenden Pakete aktualisieren
apt full-upgrade apt-get dist-upgrade Anstehenden Pakete aktualisieren und deinstallieren
apt autoremove apt-get autoremove Nicht benötigte Pakete deinstallieren
apt search apt-cache search Pakete suchen
apt show apt-cache show Paketdetails anzeigen
apt edit-sources -- sources.list editieren

 

19. September 2017

In weniger als zwei Monaten ist es soweit und Mozilla wird Firefox 57 veröffentlichen, den größten und wohl auch wichtigsten Release in der Geschichte von Firefox. Neue Anpassungsmöglichkeiten von Firefox 57 wurden bereits vorgestellt, dieser Artikel stellt die neusten Verbesserungen der Firefox-Anpassung vor.

Mozilla wird voraussichtlich im November dieses Jahres Firefox 57 veröffentlichen. Firefox 57 wird dabei kein gewöhnlicher Release sein, denn mit Firefox 57 wird Mozilla einige sehr bedeutende Änderungen einführen, was diese Version zu einem Meilenstein in der Geschichte von Firefox und Wegweiser für die Zukunft des Mozilla-Browsers machen wird. Teil dieses besonderen Releases wird Photon sein, das neue visuelle Erscheinungsbild von Firefox.

Lese-Tipp: Kommentar: Wieso Firefox 57 Mozillas bester Release aller Zeiten wird

Mit Firefox 57 wird Mozilla auch ein paar neue Möglichkeiten der Browser-Anpassung standardmäßig einbauen. Der Großteil davon wurde auf diesem Blog bereits ausführlich vorgestellt. Nun gibt es noch ein paar weitere Änderungen für Firefox 57, welche an dieser Stelle vorgestellt werden sollen.

Intelligenter Download-Button, aber optional

Ein Download-Button in der Symbolleiste von Firefox ist nichts neues. Dieser war bisher permanent sichtbar – oder gar nicht, sofern dieser über die Anpassen-Oberfläche entfernt worden ist. Ab Firefox 57 wird der Dowload-Button standardmäßig nicht mehr sichtbar sein, aber automatisch erscheinen, sobald der Nutzer einen Download startet.

Mozilla ändert aber nicht nur das standardmäßige Verhalten dieser Schaltfläche, sondern führt gleichzeitig eine Option ein, um das dieses Verhalten zu deaktivieren, womit sich der Download-Button auch in Zukunft so wie früher verhält: entweder immer oder nie sichtbar. Damit die Option sichtbar wird, muss der Download-Button in der Anpassen-Oberfläche zunächst angeklickt werden.

Firefox 57 Download-Button

Suchleiste, Ja oder Nein?

Eine weitere Änderung in Firefox 57 wird die standardmäßige Sichtbarkeit der Suchleiste betreffen. Firefox ist einer der letzten Browser mit getrennter Adress- und Suchleiste, wobei auch die Adressleiste von Firefox für Suchen genutzt werden kann. Ab Firefox 57 verschwindet – zumindest für neue Nutzer – die Suchleiste aus dem Standard-Auslieferungszustand von Firefox, kann aber auf Wunsch, wie viele andere Elemente der Browser-Oberfläche, über die Anpassen-Oberfläche wieder hinzugefügt werden. Für bestehende Nutzer soll sich hingegen nichts ändern.

Dass die Suchleiste für Firefox eine besondere Rolle spielt, zeigt sich an einer weiteren Änderung von Firefox 57. Zusätzlich zum bereits seit Jahren vorhandenen Weg, um die Suchleiste zur Oberfläche hinzuzufügen und zu entfernen, integriert Mozilla eine nicht zu übersehende Einstellung in die Einstellungs-Oberfläche von Firefox.

Firefox 57 Einstellung Suchleiste

Der Beitrag Weitere neue Anpassungsmöglichkeiten ab Firefox 57 erschien zuerst auf soeren-hentzschel.at.

Mein Linux Mint ist mittlerweile recht antiquiert und ebenso die Software die mitkommt. Auf ein Distupgrade habe ich keine Lust, da die / Partition voll ist und mein Rechner mit 4 Jahren bald ersetzt wird.
Mit Linux Mint 17 bekommt man openssh in der Version 6.6 aber ich brauche das super coole Feature Proxy Jump. Der Spaß ist recht schnell kompiliert:

wget http://mirror.exonetric.net/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
tar -zxvf openssh-7.5p1.tar.gz
 cd openssh-7.5p1/
./configure
make

Da ich nur den ssh client benötige mache ich statt

sudo make install

einfach

sudo cp ssh /usr/bin/

Fertig.

ms@w530~/Downloads/openssh-7.5p1$ ssh -V
OpenSSH_7.5p1, OpenSSL 1.0.2l  25 May 2017

Der Beitrag SSh Client updaten erschien zuerst auf Unerklärliches am Rande.

16. September 2017

Mozilla hat mit Multi-Account Containers für Firefox eine neue Erweiterung für Firefox veröffentlicht. Diese basiert auf der Container-Funktionalität, welche Mozilla im Rahmen von Test Pilot getestet hatte, und erleichtert den Umgang mit verschiedenen Identitäten im Web.

Was sind Container?

Über Container oder Container-Tabs wurde auf diesem Blog schon häufiger berichtet. Es handelt sich dabei um ein Privatsphäre-Feature, welches in dieser Form noch in keinem anderen der großen Browser existiert. Die Container stellen getrennte Umgebungen unter anderem für Cookies, Local Storage, IndexedDB, den HTTP- und den Bilder-Cache dar. Chronik, Lesezeichen, gespeicherte Passwörter sowie Formulardaten hingegen teilen sich alle Container.

Ein möglicher Anwendungsfall, der sich daraus ergibt, ist beispielsweise das Anmelden mit sowohl einer privaten als auch mit einer geschäftlichen E-Mail-Adresse beim selben Anbieter – gleichzeitig, ohne einen anderen Browser hinzuziehen zu müssen oder ein privates Fenster dazu zweckzuentfremden. Als weiteres Beispiel wäre denkbar, auf Facebook angemeldet zu sein, ohne dass Facebook den Benutzer über die Facebook-Buttons auf Webseiten tracken kann. Wenn es um Tracking geht, ist es natürlich auch bis zur Werbung nicht so weit und so ist ein weiteres denkbares Szenario, dass man Webseiten privat besuchen möchte, ohne entsprechende Werbeanzeigen zu sehen, wenn man Firefox für die Arbeit benutzt. Mozillas Erweiterung ermöglicht es auch, bestimmte Webseiten immer in einem bestimmten Container zu öffnen.

Neue Firefox-Erweiterung von Mozilla

Während die notwendige Plattform-Unterstützung Teil von Firefox ist, haben sich bereits mehrere interessante Firefox-Erweiterungen um die dazugehörige WebExtension-Schnittstelle gebildet. Container sind damit bereits ein fester Teil des Erweiterungs-Ökosystems von Firefox.

Auch Mozillas Implementierung des Container-Features erfolgt als Firefox-Erweiterung. Mozilla testet Container schon seit längerer Zeit als soganntes Test Pilot-Experiment. Nach Monaten des Experimentierens bietet Mozilla die Erweiterung ab sofort über sein Erweiterungs-Portal addons.mozilla.org an.

Download Firefox Multi-Account Containers

Die Erweiterung ist derzeit kompatibel mit Firefox 53 bis Firefox 56. Nutzer einer Vorab-Version von Firefox 57 greifen stattdessen zur über GitHub angebotenen Version. Noch handelt es sich bei Firefox Multi-Account Containers um keine vollständige WebExtension, weil erst mit Firefox 57 alle notwendigen APIs verfügbar sind, aber die Erweiterung wird rechtzeitig als mit Firefox 57 kompatible Version über addons.mozilla.org per Update zur Verfügung gestellt werden, so dass Nutzer bedenkenlos zur aktuellen Version greifen können. Im Gegensatz zum Test Pilot-Experiment werden bei der über addons.mozilla.org angebotenen Version keinerlei Daten an Mozilla gesendet.

Firefox Multi-Account Containers

Firefox Multi-Account Containers

Firefox Multi-Account Containers

Firefox Multi-Account Containers

Der Beitrag Mozilla veröffentlicht Multi-Account Containers für Firefox erschien zuerst auf soeren-hentzschel.at.

Wie jedes Jahr haben wir für die Teilnahme an der Ubucon, die vom 13. bis 15. Oktober 2017 in Wolfsburg stattfindet, ein Registrierung. Wir bitten alle, die bei der Ubucon teilnehmen möchten, sich zu registrieren. Die Registrierung ist soeben freigeschaltet worden.

Die Teilnahme an der Ubucon kostet in diesem Jahr 15 Euro. Dies ist eine Verpflegungspauschale, dadurch stehen jedem Besucher Getränke und Snacks zur Verfügung. Gerne kann alternativ auch mehr bezahlt werden, um die Veranstaltung finanziell zu unterstützen.

Um besser planen zu können, würden wir uns freuen, wenn Du schon Aussagen dazu treffen kannst, ob Du an den Social Events teilnehmen kannst. Während der Konferenz haben wir wieder ein paar Leckereien vorbereitet, auf die Du zugreifen kannst.

Hierbei ist zu beachten, dass die Anmeldung und Überweisung des Geldes spätestens zum 1. Oktober 2017 angestoßen sein muss. Es ist auch noch möglich, sich auf der Ubucon vor Ort anzumelden. Der Unkostenbeitrag steigt dann auf 20 Euro, weil wir nicht so gut planen können.

Unterdessen haben wir auch schon einige Programmpunkte auf unserer Programmseite verlinkt. Unser Call for Papers läuft ebenfalls noch.

zur Anmeldung

Seit dem Umstieg auf Bolt CMS nutze ich für die Kommentare Isso Comment. Leider gibt es hier derzeit keine Benachrichtigung für neue Kommentare. Was wohl dem einen oder anderen Leser von fryboyter.de nervt. Zumindest habe ich in letzter Zeit E-Mails deswegen bekommen.

Da bei solch einem System das Missbrauchspotenzial recht hoch ist, müsste man auf ein Opt-In-Verfahren setzen. Da es dies bei Isso Comment aktuell nicht gibt und ich auch nicht in der Lage bin, Abhilfe zu schaffen, habe ich mir mal Workaraounds überlegt.

Es gibt zum Beispiel Dienste wie https://visualping.io/ mit denen man Webseiten auf Änderungen überwachen kann. Bei Visualping liegt der Intervall bei 1 Stunde und man muss nur eine E-Mail-Adresse angeben. Eine Registrierung ist nicht nötig. Visualping bietet für Chrome auch eine Erweiterung an.

Für Firefox (den ich nur in Ausnahmefällen nutze) gibt es wohl Erweiterungen wie Distill Web Monitor. Inwieweit diese taugen kann ich, aus genannten Gründen, nicht sagen.

Falls jemand eine bessere Idee hat, immer her damit.

Edit: Inzwischen habe ich mir ein Script gebaut, welches einen Feed der letzten 20 Kommentare erstellt.

14. September 2017

Um nur bestimmte Mails zu löschen, z.b. häufige Fehlermeldungen
mit dem gleichen Inhalt kann man diese auch direct von procmail in
/dev/null schieben lassen.

Eine sehr simple /etc/procmailrc kann wie folgt aussehen:

:0
* ^Subject:.*BLABLA
/dev/null

Damit werden alle eMails bei denen der Betreff auf BLABLA endet gelöscht.
Man kann aber auch nach Absender filtern und löschen lassen, z.b. alle
emails meiner Werbeadresse sollen weg:

:0
* ^From.*werbung@nitschke-marl.de
/dev/null

Das ist nicht grade der beste Filter, aber um nur mal schnell
ein paar Wörter oder Absender zu blockieren kommt man so noch ohne
weitere Software aus.

Diskussion bitte hier: http://gnude.feste-ip.net/dev/index.php?topic=116.0

Zur Zeit beschäftige ich vermehrt mit Bash-Scripting. Natürlich habe ich in der Vergangenheit schon mal das ein oder andere kleinere Script für die Shell geschrieben, um mir die Arbeit zu erleichtern, aber ich hatte mal Lust auf etwas größeres, zudem wollte ich mich mal mehr mit Git auseinander setzen.

​ Schon vor längerer Zeit bin ich deswegen auf ein Script von Juan aufmerksam geworden, welches mit wenig Aufwand einen Apache inkl. Datenbank und Wordpres installiert.

​ Auf Grundlage dieses Scriptes - danke an Juan an dieser Stelle für die Erlaubnis - habe ich mit meiner eigenen Variante angefangen namens SLEMP. Natürlich gibt es deutlich elegentere Möglichkeiten der Umsetzung, Stichwort Ansible. Mir geht es aber um den Lerneffekt.

​ SLEMP steht für Secure LEMP. Anstelle wie Juan auf Apache, setze ich auf Nginx. Ziel ist eine sichere Konfiguration. Jeder vhost erhält seinen eigenen User, generell achte ich auf eine sichere nginx-Konfiguration.

​ Zur Zeit ist das Script noch ziemlich “dumm” und prüft die Voraussetzungen bzw. Eingaben nicht. Ebenfalls muss MariaDB zum jetzigen Zeitpunkt noch manuell installiert und eingerichtet werden.

​ Den Quellcode und weitere Infos findet ihr auf Github.

​ Was das Script bisher macht: ​ - Installation von nginx, php7, Let’s Encrypt (Certbot) - Einrichtung von PHP-FPM-Pool und nginx-vHost - Let’s Encrypt-Zertifikat wird erstellt

​ Was noch kommt: ​ - Installation und Konfiguration von MariaDB - zur Zeit hänge ich noch etwas an der Umsetzung von - mysql_secure_installation - Logrotation - Weitere Anpassungen an der nginx/Server-Konfiguration - Verbesserte CentOS-Unterstützung: Ich konnte das Script generell bisher nur kurz unter CentOS testen, prinzipiell sollte es laufen. Im nächsten Release werden die Regeln für firewalld automatisch gesetzt, SELINUX ist noch ein offener Punkt - Wordpress-Installation: Fehlt zum jetzigen Zeitpunkt noch

Zur Zeit beschäftige ich vermehrt mit Bash-Scripting. Natürlich habe ich in der Vergangenheit schon mal das ein oder andere kleinere Script für die Shell geschrieben, um mir die Arbeit zu erleichtern, aber ich hatte mal Lust auf etwas größeres, zudem wollte ich mich mal mehr mit Git auseinander setzen.

Schon vor längerer Zeit bin ich deswegen auf ein Script von Juan aufmerksam geworden, welches mit wenig Aufwand einen Apache inkl. Datenbank und Wordpres installiert.

Auf Grundlage dieses Scriptes - danke an Juan an dieser Stelle für die Erlaubnis - habe ich mit meiner eigenen Variante angefangen namens SLEMP.
Natürlich gibt es deutlich elegentere Möglichkeiten der Umsetzung, Stichwort Ansible. Mir geht es aber um den Lerneffekt.

SLEMP steht für Secure LEMP. Anstelle wie Juan auf Apache, setze ich auf Nginx. Ziel ist eine sichere Konfiguration. Jeder vhost erhält seinen eigenen User, generell achte ich auf eine sichere nginx-Konfiguration.

Zur Zeit ist das Script noch ziemlich "dumm" und prüft die Voraussetzungen bzw. Eingaben nicht. Ebenfalls muss MariaDB zum jetzigen Zeitpunkt noch manuell installiert und eingerichtet werden.

Den Quellcode und weitere Infos findet ihr auf Github.

Was das Script bisher macht:

  • Installation von nginx, php7, Let's Encrypt (Certbot)
  • Einrichtung von PHP-FPM-Pool und nginx-vHost
  • Let's Encrypt-Zertifikat wird erstellt

Was noch kommt:

  • Installation und Konfiguration von MariaDB - zur Zeit hänge ich noch etwas an der Umsetzung von
  • mysql_secure_installation
  • Logrotation
  • Weitere Anpassungen an der nginx/Server-Konfiguration
  • Verbesserte CentOS-Unterstützung: Ich konnte das Script generell bisher nur kurz unter CentOS testen, prinzipiell sollte es laufen. Im nächsten Release werden die Regeln für firewalld automatisch gesetzt, SELINUX ist noch ein offener Punkt
  • Wordpress-Installation: Fehlt zum jetzigen Zeitpunkt noch

Zur Zeit beschäftige ich vermehrt mit Bash-Scripting. Natürlich habe ich in der Vergangenheit schon mal das ein oder andere kleinere Script für die Shell geschrieben, um mir die Arbeit zu erleichtern, aber ich hatte mal Lust auf etwas größeres, zudem wollte ich mich mal mehr mit Git auseinander setzen.

Schon vor längerer Zeit bin ich deswegen auf ein Script von Juan aufmerksam geworden, welches mit wenig Aufwand einen Apache inkl. Datenbank und Wordpres installiert.

Auf Grundlage dieses Scriptes - danke an Juan an dieser Stelle für die Erlaubnis - habe ich mit meiner eigenen Variante angefangen namens SLEMP.
Natürlich gibt es deutlich elegentere Möglichkeiten der Umsetzung, Stichwort Ansible. Mir geht es aber um den Lerneffekt.

SLEMP steht für Secure LEMP. Anstelle wie Juan auf Apache, setze ich auf Nginx. Ziel ist eine sichere Konfiguration. Jeder vhost erhält seinen eigenen User, generell achte ich auf eine sichere nginx-Konfiguration.

Zur Zeit ist das Script noch ziemlich "dumm" und prüft die Voraussetzungen bzw. Eingaben nicht. Ebenfalls muss MariaDB zum jetzigen Zeitpunkt noch manuell installiert und eingerichtet werden.

Den Quellcode und weitere Infos findet ihr auf Github.

Was das Script bisher macht:

  • Installation von nginx, php7, Let's Encrypt (Certbot)
  • Einrichtung von PHP-FPM-Pool und nginx-vHost
  • Let's Encrypt-Zertifikat wird erstellt

Was noch kommt:

  • Installation und Konfiguration von MariaDB - zur Zeit hänge ich noch etwas an der Umsetzung von
  • mysql_secure_installation
  • Logrotation
  • Weitere Anpassungen an der nginx/Server-Konfiguration
  • Verbesserte CentOS-Unterstützung: Ich konnte das Script generell bisher nur kurz unter CentOS testen, prinzipiell sollte es laufen. Im nächsten Release werden die Regeln für firewalld automatisch gesetzt, SELINUX ist noch ein offener Punkt
  • Wordpress-Installation: Fehlt zum jetzigen Zeitpunkt noch

Zur Zeit beschäftige ich vermehrt mit Bash-Scripting. Natürlich habe ich in der Vergangenheit schon mal das ein oder andere kleinere Script für die Shell geschrieben, um mir die Arbeit zu erleichtern, aber ich hatte mal Lust auf etwas größeres, zudem wollte ich mich mal mehr mit Git auseinander setzen.

Schon vor längerer Zeit bin ich deswegen auf ein Script von Juan aufmerksam geworden, welches mit wenig Aufwand einen Apache inkl. Datenbank und Wordpres installiert.

Auf Grundlage dieses Scriptes - danke an Juan an dieser Stelle für die Erlaubnis - habe ich mit meiner eigenen Variante angefangen namens SLEMP.
Natürlich gibt es deutlich elegentere Möglichkeiten der Umsetzung, Stichwort Ansible. Mir geht es aber um den Lerneffekt.

SLEMP steht für Secure LEMP. Anstelle wie Juan auf Apache, setze ich auf Nginx. Ziel ist eine sichere Konfiguration. Jeder vhost erhält seinen eigenen User, generell achte ich auf eine sichere nginx-Konfiguration.

Zur Zeit ist das Script noch ziemlich "dumm" und prüft die Voraussetzungen bzw. Eingaben nicht. Ebenfalls muss MariaDB zum jetzigen Zeitpunkt noch manuell installiert und eingerichtet werden.

Den Quellcode und weitere Infos findet ihr auf Github.

Was das Script bisher macht:

  • Installation von nginx, php7, Let's Encrypt (Certbot)
  • Einrichtung von PHP-FPM-Pool und nginx-vHost
  • Let's Encrypt-Zertifikat wird erstellt

Was noch kommt:

  • Installation und Konfiguration von MariaDB - zur Zeit hänge ich noch etwas an der Umsetzung von
  • mysql_secure_installation
  • Logrotation
  • Weitere Anpassungen an der nginx/Server-Konfiguration
  • Verbesserte CentOS-Unterstützung: Ich konnte das Script generell bisher nur kurz unter CentOS testen, prinzipiell sollte es laufen. Im nächsten Release werden die Regeln für firewalld automatisch gesetzt, SELINUX ist noch ein offener Punkt
  • Wordpress-Installation: Fehlt zum jetzigen Zeitpunkt noch

Zur Zeit beschäftige ich vermehrt mit Bash-Scripting. Natürlich habe ich in der Vergangenheit schon mal das ein oder andere kleinere Script für die Shell geschrieben, um mir die Arbeit zu erleichtern, aber ich hatte mal Lust auf etwas größeres, zudem wollte ich mich mal mehr mit Git auseinander setzen.

Schon vor längerer Zeit bin ich deswegen auf ein Script von Juan aufmerksam geworden, welches mit wenig Aufwand einen Apache inkl. Datenbank und Wordpres installiert.

Auf Grundlage dieses Scriptes - danke an Juan an dieser Stelle für die Erlaubnis - habe ich mit meiner eigenen Variante angefangen namens SLEMP.
Natürlich gibt es deutlich elegentere Möglichkeiten der Umsetzung, Stichwort Ansible. Mir geht es aber um den Lerneffekt.

SLEMP steht für Secure LEMP. Anstelle wie Juan auf Apache, setze ich auf Nginx. Ziel ist eine sichere Konfiguration. Jeder vhost erhält seinen eigenen User, generell achte ich auf eine sichere nginx-Konfiguration.

Zur Zeit ist das Script noch ziemlich "dumm" und prüft die Voraussetzungen bzw. Eingaben nicht. Ebenfalls muss MariaDB zum jetzigen Zeitpunkt noch manuell installiert und eingerichtet werden.

Den Quellcode und weitere Infos findet ihr auf Github.

Was das Script bisher macht:

  • Installation von nginx, php7, Let's Encrypt (Certbot)
  • Einrichtung von PHP-FPM-Pool und nginx-vHost
  • Let's Encrypt-Zertifikat wird erstellt

Was noch kommt:

  • Installation und Konfiguration von MariaDB - zur Zeit hänge ich noch etwas an der Umsetzung von
  • mysql_secure_installation
  • Logrotation
  • Weitere Anpassungen an der nginx/Server-Konfiguration
  • Verbesserte CentOS-Unterstützung: Ich konnte das Script generell bisher nur kurz unter CentOS testen, prinzipiell sollte es laufen. Im nächsten Release werden die Regeln für firewalld automatisch gesetzt, SELINUX ist noch ein offener Punkt
  • Wordpress-Installation: Fehlt zum jetzigen Zeitpunkt noch

Zur Zeit beschäftige ich vermehrt mit Bash-Scripting. Natürlich habe ich in der Vergangenheit schon mal das ein oder andere kleinere Script für die Shell geschrieben, um mir die Arbeit zu erleichtern, aber ich hatte mal Lust auf etwas größeres, zudem wollte ich mich mal mehr mit Git auseinander setzen.

Schon vor längerer Zeit bin ich deswegen auf ein Script von Juan aufmerksam geworden, welches mit wenig Aufwand einen Apache inkl. Datenbank und Wordpres installiert.

Auf Grundlage dieses Scriptes - danke an Juan an dieser Stelle für die Erlaubnis - habe ich mit meiner eigenen Variante angefangen namens SLEMP.
Natürlich gibt es deutlich elegentere Möglichkeiten der Umsetzung, Stichwort Ansible. Mir geht es aber um den Lerneffekt.

SLEMP steht für Secure LEMP. Anstelle wie Juan auf Apache, setze ich auf Nginx. Ziel ist eine sichere Konfiguration. Jeder vhost erhält seinen eigenen User, generell achte ich auf eine sichere nginx-Konfiguration.

Zur Zeit ist das Script noch ziemlich "dumm" und prüft die Voraussetzungen bzw. Eingaben nicht. Ebenfalls muss MariaDB zum jetzigen Zeitpunkt noch manuell installiert und eingerichtet werden.

Den Quellcode und weitere Infos findet ihr auf Github.

Was das Script bisher macht:

  • Installation von nginx, php7, Let's Encrypt (Certbot)
  • Einrichtung von PHP-FPM-Pool und nginx-vHost
  • Let's Encrypt-Zertifikat wird erstellt

Was noch kommt:

  • Installation und Konfiguration von MariaDB - zur Zeit hänge ich noch etwas an der Umsetzung von
  • mysql_secure_installation
  • Logrotation
  • Weitere Anpassungen an der nginx/Server-Konfiguration
  • Verbesserte CentOS-Unterstützung: Ich konnte das Script generell bisher nur kurz unter CentOS testen, prinzipiell sollte es laufen. Im nächsten Release werden die Regeln für firewalld automatisch gesetzt, SELINUX ist noch ein offener Punkt
  • Wordpress-Installation: Fehlt zum jetzigen Zeitpunkt noch

13. September 2017

Nach einigem lesen zum Thema SSL und TLS und Cipher und und und, habe ich jetzt mal meine nginx Konfiguration angepasst. Erfolgreiches testen hat mich zu den Schluß kommen lassen, dass wenige Cipher reichen um ein A+ im SSL Labs Test zu bekommen.

Nginx Config

Die folgende Konfiguration sollte in der Datei /etc/nginx/nginx.conf stehen:

server_tokens off;

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header 'Referrer-Policy' 'no-referrer';

Site Config

Die folgende Konfiguration sollte für die jeweiligen Seite angelegt werden:

server {
        listen 80; 
        listen [::]:80;

        server_name exmaple.de www.example.de;
        if ( $host != $server_name ) { 
            return 301 https://$server_name$request_uri;
        }
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name example.de www.example.de;
        if ( $host != $server_name ) { 
            return 301 https://$server_name$request_uri;
        }

        ssl_certificate /etc/ssl/fullchain.pem;
        ssl_certificate_key /etc/ssl//privkey.pem;

        ssl_protocols TLSv1.2;
        ssl_prefer_server_ciphers on; 
        ssl_dhparam /etc/ssl/private/dhparam.pem;
        ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA;
        ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
        ssl_session_timeout  10m;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off; # Requires nginx >= 1.5.9
        ssl_stapling on; # Requires nginx >= 1.3.7
        ssl_stapling_verify on; # Requires nginx => 1.3.7
        resolver 127.0.0.1 valid=300s;
        resolver_timeout 5s; 
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;   
...
}

ssl_protocols

Die neueren Versionen von nginx unterstützen schon TLSv1.3. Ich empfehle daher, zu testen ob eure nginx Version das unterstützt und diese dann auch einzubinden.

resolver

Ich empfehle hier einen lokalen am besten unbound.

Und fertig ist die sichere nginx Server Konfiguration.

Update 1.0

Cipher angepasst, einige neue Option, Hinweis zu TLSv1.3 hinzugefügt.

Nach einigem lesen zum Thema SSL und TLS und Cipher und und und, habe ich jetzt mal meine nginx Konfiguration angepasst. Erfolgreiches testen hat mich zu den Schluß kommen lassen, dass wenige Cipher reichen um ein A+ im SSL Labs Test zu bekommen.

Nginx Config

Die folgende Konfiguration sollte in der Datei /etc/nginx/nginx.conf stehen:

server_tokens off;

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header 'Referrer-Policy' 'no-referrer';

Site Config

Die folgende Konfiguration sollte für die jeweiligen Seite angelegt werden:

server {
        listen 80; 
        listen [::]:80;

        server_name exmaple.de www.example.de;
        if ( $host != $server_name ) { 
            return 301 https://$server_name$request_uri;
        }
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name example.de www.example.de;
        if ( $host != $server_name ) { 
            return 301 https://$server_name$request_uri;
        }

        ssl_certificate /etc/ssl/fullchain.pem;
        ssl_certificate_key /etc/ssl//privkey.pem;

        ssl_protocols TLSv1.2;
        ssl_prefer_server_ciphers on; 
        ssl_dhparam /etc/ssl/private/dhparam.pem;
        ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA;
        ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
        ssl_session_timeout  10m;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off; # Requires nginx >= 1.5.9
        ssl_stapling on; # Requires nginx >= 1.3.7
        ssl_stapling_verify on; # Requires nginx => 1.3.7
        resolver 127.0.0.1 valid=300s;
        resolver_timeout 5s; 
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;   
...
}

ssl_protocols

Die neueren Versionen von nginx unterstützen schon TLSv1.3. Ich empfehle daher, zu testen ob eure nginx Version das unterstützt und diese dann auch einzubinden.

resolver

Ich empfehle hier einen lokalen am besten unbound.

Und fertig ist die sichere nginx Server Konfiguration.

Update 1.0

Cipher angepasst, einige neue Option, Hinweis zu TLSv1.3 hinzugefügt.

12. September 2017

Wer bereits ein Mail-System für den Versand und Empfang von E-Mails aufgesetzt hat, weiß, dass das je nach Funktionsumfang viel Arbeit sein kann. Wenn nicht nur ein Host E-Mails verschicken soll, sondern mehrere, kann es sich lohnen, einen zentralen Mailserver als “Mail-Gateway” zu nutzen. Das bedeutet: Für den Versand von E-Mails in das Internet und den Empfang aus dem Internet ist nur dieser eine Mailserver zuständig. Alle weiteren Hosts (“externe Hosts”) benötigen keine aufwendige Mailserver-Konfiguration, sondern kommen mit einer Minimalkonfiguration aus, welche es ihnen erlaubt, beim Versand auf das Gateway zurückzugreifen. DKIM, SPF und weitere Versand-spezifische Merkmale müssen dann nur auf dem Gateway eingerichtet und gewartet werden.

Mailserver Gateway

  • “Gateway”: Der Server, auf dem das Mailsystem eingerichtet ist.
  • Host" / “externer Host”: Ein Server, der für den Mailversand den Mailserver nutzen soll.
Im folgenden setze ich voraus, dass das Mail-Gateway nach meiner Mailserver-Anleitung aufgesetzt ist. Prinzipiell funktioniert es aber ähnlich auch mit anderen Gateways

Postfix-Grundkonfiguration auf dem externen Host

Externen Mailempfang auf den Hosts abschalten

Ẁenn ein Host nur für den Versand verwendet wird, kann der smtpd-Teil von Postfix abgeschaltet werden. In der Datei /etc/postfix/master.cf werden smtpd und ggf. submission-Teil einfach auskommentiert:

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#smtp inet n - - - - smtpd
#smtp inet n - - - 1 postscreen
#smtpd pass - - - - - smtpd
#dnsblog unix - - - - 0 dnsblog
#tlsproxy unix - - - - 0 tlsproxy
#submission inet n - - - - smtpd
# -o syslog_name=postfix/submission
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#smtps inet n - - - - smtpd
# -o syslog_name=postfix/smtps
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

Eine main.cf nur für den Nachrichtenversand

In der /etc/postfix/main.cf müssen nur wenige Einstellungen festgelegt werden. Diese werden je nach Art des Setups (im Folgenden) erweitert.

myhostname = host1.mydomain.tld
inet_protocols = all
inet_interfaces = 127.0.0.1, 10.8.0.1
##
## Mail-Queue Einstellungen
##
maximal_queue_lifetime = 1h
bounce_queue_lifetime = 1h
maximal_backoff_time = 15m
minimal_backoff_time = 5m
queue_run_delay = 5m
##
## TLS Einstellungen
###
tls_ssl_options = NO_COMPRESSION
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
### Ausgehende Verbindungen (SMTP Client)
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_host_lookup = dns, native
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_ciphers=high
smtp_tls_CAfile =/etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 0

(Bitte anpassen!)

Fall 1: Externer Host mit statischer IP-Adresse

Hosts, die über eine statische IP-Adresse (also eine immer gleich bleibende Adresse) erreichbar sind, kann sehr einfach der Zugriff auf das Gateway erlaubt werden. Dazu wird z.B. Host1 mit der IP-Adresse 10.8.0.1 in der Konfiguration des Gateways in mynetworks (main.cf) aufgenommen, z.B. so:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
10.8.0.1/32

Anwenden der neuen Einstellungen auf dem Mail-Gateway mail.mysystems.tld:

systemctl reload postfix

Auf dem externen Host host1.mydomain.tld wird Postfix via relayhost angewiesen, sämtliche Mails, die nicht lokal zugestellt werden können, an das Gateway weiterzureichen. Die Datei /etc/postfix/main.cf auf dem Host wird dazu um folgende Zeilen erweitert:

##
## Alle E-Mails an nicht-lokale Empfänger an das Gateway weiterleiten
##
relayhost = mail.mysystems.tld

Anwenden der Einstellungen auf dem externen Host host1.mydomain.tld

systemctl reload postfix

Fall 2: Externer Host mit dynamischer IP-Adresse (z.B. Homeserver)

Wenn ein Host über keine statische IP-Adresse verfügt, wie es z.B. bei den meisten Homeservern der Fall ist, muss zu einem etwas komplizierteren Setup gegriffen werden. In diesem Fall kann der Host nicht über die IP-Adresse autorisiert werden, sodass wir auf die normale SMTP-Authentifizierung zurückgreifen. Letztendlich ist die Postfix-Instanz auf dem Host für das Gateway also nichts weiteres als ein ganz normaler E-Mail-Client. Daher muss das Gateway auch über den Submission Port 587 angesprochen werden - nicht über Port 25!. Fügt die folgende Zeile am Host in der /etc/postfix/main.cf an:

relayhost = [mail.mysystems.tld]:587

Für die Authentifizierung wird außerdem der folgende Block unten angefügt:

##
## Authentifizierung am Relayhost
##
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd
smtp_sasl_security_options = noanonymous

Die Postfix-Instanz auf dem Host meldet sich wie ein normaler MUA (Mail user Agent) an, und muss daher auch ein entsprechendes Mailkonto auf dem Mail-Gateway besitzen, z.B. host3@mysystems.tld. Die dazugehörigen Zugangsdaten werden in die Datei /etc/postfix/relay_passwd eingetragen:

[mail.mysystems.tld]:587 host3@mysystems.tld:meinpasswort

Via

postmap /etc/postfix/relay_passwd

wird eine Datenbank-Datei erzeugt, die von Postfix gelesen werden kann. Bei jeder Änderung an relay_passwd muss dieses Kommando erneut ausgeführt werden.

Eine Besonderheit gibt es bei dieser Art des Setups noch: Da Postfix einen normalen Benutzer-Account für die Verbindung zum Gateway nutzt, ist er auch den Beschränkungen unterworfen, die für solche Accounts gelten. So dürfen Benutzer gemäß meines Mailserver-Setups nur E-Mails in ihrem eigenen Namen versenden. Damit soll Adressfälschung bei ausgehenden E-Mails verhindert werden. Der Host dürfte also nur E-Mails mit dem Absender host3@mysystems.tld erzeugen. Alles andere würde vom Gateway blockiert werden. Nun senden einige Tools wie z.B. mdadm aber standardmäßig im Namen root@host3.mydomain.tld - der Versand würde scheitern.

Die Lösung für das Problem ist ein Neu-Schreiben des “Envelope-From”: E-Mails, die vom Host ausgehen, werden so umgeschrieben, dass deren Absender immer host3@mysystems.tld lautet. Damit wird das Problem umgangen. Zum Umschreiben wird die Einstellung sender_canonical_maps genutzt. Fügt das folgende Snippet unten an die main.cf an:

###
### Adressen von Absendern, z.B. root@host3.mydomain.tld müssen nach host3@mysystems.tld umgeschrieben werden
### Für außenstehende Systeme darf es nur host3@mysystems.tld als Absender geben.
###
sender_canonical_maps = hash:/etc/postfix/rewrite_from

… und erzeugt eine neue Datei /etc/postfix/rewrite_from mit folgendem Inhalt:

@host3.mydomain.tld host3@mysystems.tld

Auch diese Datei wird via postmap in eine für Postfix lesbare Datenbank umgewandelt.

postmap /etc/postfix/rewrite_from

Anwenden der Einstellungen:

systemctl reload postfix

Lokale Mailzustellung auf externen Hosts verhindern und Mails weiterleiten

Standardmäßig werden E-Mails, die beispielsweise an den lokalen “root”-User eines externen Hosts gehen, nicht über das Gateway geschickt. Benachrichtigungsmails bzgl. RAID-Status, APT-Status und Mails von weiteren Softwarepaketen bleiben dann lokal in /var/mail/root liegen und geraten in Vergessenheit. Durch ein Umschreiben des Empfängers von selbst erzeugten Mails können diese Systemmails aber abgegriffen und an eine beliebige, andere Mailadresse weitergeleitet werden. Dazu wird in /etc/postfix/main.cf auf dem jeweiligen Host folgendes unten angefügt:

###
### Lokale Empfänger *@host1 (z.B. "root") umschreiben
### damit Mails nicht in /var/mail/root abgelegt werden, sondern an beliebigen Empfänger weitergeleitet werden.
###
recipient_canonical_maps = hash:/etc/postfix/rewrite_local_to

Die zugehörige Datei /etc/postfix/rewrite_local_to wird mit folgendem Inhalt angelegt:

@host1.mydomain.tld postmaster@mysystems.tld

Damit würden sämtliche Mails an lokale Nutzer des Hosts an postmaster@mysystems.tld weitergeleitet werden. Wer das Umschreiben des Empfängers beschränken will, kann statt @host1.mydomain.tld auch vollständige Adressen wie z.B. root@host1.mydomain.tld angeben.

Nach dieser Konfigurationsänderung ist es notwendig, die passende Datenbankdatei für Postfix zu erzeugen und den Dienst neu zu starten:

postmap /etc/postfix/rewrite_local_to
systemctl reload postfix

Das Postmap-Kommando muss nach jeder Änderung in der Datei rewrite_local_to wiederholt werden!

Setup testen

Auf den Hosts kann das Verhalten von Postfix überprüft werden, indem eine kleine Testmail verschickt wird:

echo "Testmail an eine beliebige E-Mail-Adresse" | mail -s "Testmail" postmaster@mysystems.tld

Ob auch E-Mails an den lokalen “root” User eines Hosts erfolgreich eingesammelt und weitergeleitet werden, kann hiermit überprüft werden:

echo "Testmail an den lokalen root-User" | mail -s "Testmail" root

11. September 2017

Heute stolperte ich im OSBN über den Beitrag Über fehlgeschlagenem Service per XMPP informieren von Fryboyter. Die Idee fand ich gut, aber ich würde mir lieber die Systemmails von Linux, die ich derzeit im Thunderbird abfrage, per XMPP zusenden lassen.

Nach kurzer Suche mit searx fand ich den englischen Blogpost SendXMPP mail forward on Debian Jessie. Ich bin ein klein wenig von der Anleitung abgewichen und möchte die Lösung auch für mich dokumentiert haben, falls der Blogeintrag mal verschwindet darum halte ich das Vorgehen hier auch noch mal fest.

Warnung

Es könnte sein, dass wichtige oder sensible Informationen in den Systemmails enthalten sind. Deshalb würde ich davon abraten diese über fremde Server zu senden.

Zuerst habe ich sendxmpp aus den Debian-Repositories installiert:

# apt install sendxmpp

Anschließend habe ich überprüft ob sendxmpp überhaupt Nachrichten zustellen kann. SENDER, SENDER_SERVER, EMPFAENGER, EMPFAENGER_SERVER, PASSWORT und PORT (wird nur benötigt, wenn nicht der Standardport 5222 verwendet wird) sind hier und im weiteren Verlauf natürlich an die eigene Konfiguration anzupassen.

$ echo 'Hallo Welt' | sendxmpp -t  -u SENDER -j SENDER_SERVER:PORT -p 'PASSWORT' EMPFAENGER@EMPFAENGER_SERVER
Invalid or unreadable path specified for ssl_ca_path. at /usr/share/perl5/Stream.pm line 641

Ich bekam die gleiche Fehlermeldung wie Fryboyter und konnte das Problem beheben indem ich wie in seinem Beitrag beschrieben in /usr/share/perl5/XML/Stream.pm Zeile 223 folgendermaßen abänderte:

    $self->{SIDS}->{default}->{ssl_ca_path} = '/etc/ssl/certs';

Als nächstes habe ich die Datei /etc/sendxmpp.conf mit folgendem Inhalt angelegt:

SENDER@SENDER_SERVER:PORT PASSWORT

Anschließend wurde die Datei ausschließlich für ihren Besitzer les- und beschreibbar gemacht und der Besitzer zu Debian-exim geändert:

# chmod 600 /etc/sendxmpp.conf
# chown Debian-exim:Debian-exim /etc/sendxmpp.conf

Nun habe ich die Datei /usr/local/bin/mail2xmpp angelegt und folgendes eingetragen:

1
2
#!/bin/bash 
echo "$(cat)" | sendxmpp -t  -f /etc/sendxmpp.conf EMPFAENGER@EMPFAENGER_SERVER

Die Datei wurde anschließend noch ausführbar gemacht:

# chmod 755 /usr/local/bin/mail2xmpp

Um zu definieren wie die Mails zugestellt werden muss die Datei /etc/aliases bearbeitet werden, wobei USER natürlich anzupassen ist:

# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: USER
USER:,|/usr/local/bin/mail2xmpp
logcheck: root

Damit die Systemmails per pipe weitergereicht werden können muss die Datei /etc/exim4/exim4.conf.localmacros angelegt und diese Zeile eingetragen werden:

SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe

Anschließend werden die neuen Aliase eingelesen und exim4 neu gestartet:

# newaliases
# systemctl restart exim4.service 

Abschließend wird noch getestet ob der Mailtransport über XMPP funktioniert:

$ echo "Das ist ein Test" | mail -s testmail root

An einem meiner Rechner bekam ich hier eine Fehlermeldung:

mail: Nachricht kann nicht gesendet werden: Prozess wurde mit einem von Null verschiedenen Status beendet

In den logs sah ich folgendes:

Sep 12 19:02:53 backup exim[446]: 2017-09-12 19:02:53 1droaL-00007C-Lt <= root@backup U=root P=local S=341
Sep 12 19:02:53 backup exim[446]: 2017-09-12 19:02:53 1droaL-00007C-Lt Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=104 egid=109
Sep 12 19:02:53 backup exim[446]: exim: could not open panic log - aborting: see message(s) above

Das konnte ich ganz einfach beheben indem ich den Ordner /var/log/exim4/ angelegt und Debian-exim als Eigentümer festgelegt habe:

# mkdir /var/log/exim4
# chown Debian-exim:Debian-exim /var/log/exim4
[Update 2017-09-12]

An einem meiner Rechner gab es nach der Einrichtung noch eine Fehlermeldung beim Versuch Nachrichten über XMPP weiterzuleiten. Ich habe den Beitrag dementsprechend erweitert.

Auf meinen Raspberry Pi’s laufen einige Dienste wie ein Q3A-Server. Diese zum Beispiel mit Zabbix zu überwachen ist mir dann doch etwas übertrieben, da diese Dienste entweder rein privat genutzt werden oder ich einfach keine Uptime garantiere.

Trotzdem wäre es dann doch interessant wenn ich darüber informiert werde wenn zum Beispiel ein Dienst nicht gestartet werden konnte. Vor allem wenn man nicht daheim ist. Da ich auf meinem Smartphone auch einen XMPP-Client installiert habe, würde sich eine Lösungen mittels XMPP und systemd anbieten.

Um die Nachrichten zu versenden habe ich mir sendxmpp installiert. Unter Arch findet man das Paket im AUR. Um zu testen ob das Versenden überhaupt funktioniert, habe ich es gleich einmal ausprobiert.

echo 'Hallo Welt' | sendxmpp -t  -u fryboyter -j jabjab.de -p 'strenggeheim' empfänger@deshalbfrei.org

Und schon knallt es und ich bekomme die Fehlermeldung “Invalid or unreadable path specified for ssl_ca_path. at /usr/share/perl5/vendor_perl/XML/Stream.pm line 641” vor den Latz geknallt. Dann schauen wir uns die Datei doch mal an. Zeile 641 verrät mir allerdings recht wenig. Allerdings gibt es in besagter Datei die Zeile $self->{SIDS}->{default}->{ssl_ca_path} = “;. An deren Ende habe ich zwischen die beiden ” einfach mal /etc/ssl/certs eingetragen.

Nächster Versuch, nächste Fehlermeldung. Error ‘AuthSend’: error: bad-protocol[?]. Na das ist ja mal sehr aussagekräftig. Nach etwas Google-Fu konnte ich das Problem in der Datei /usr/share/perl5/vendor_perl/Net/XMPP/Protocol.pm ausfindig machen. In Zeile 2104 steht return $ self-> AuthSASL (% args);. Diese Zeile kommentieren wir einfach mal mit einem # am Anfang aus. Ich bin mir allerdings nicht sicher, ob das nicht irgendwelche Nebenwirkungen hat.

Und wieder ein neuer Anlauf. Und plötzlich informiert mich mein XMPP-Client dass ich für empfänger@deshalbfrei.org eine Nachricht erhalten habe. Yeehaa!

Da nun die Benachrichtungen per XMPP funktionieren, erstellen wir unter /usr/bin ein Shellscript (nennen wir es mal xmpp.sh) mit folgendem Inhalt.

#!/bin/bash

UNIT=$1

UNITSTATUS=$(systemctl status $UNIT)
ALERT=$(echo -e "\u26A0")

echo "$ALERT Unit failed $UNIT $ALERT Status: $UNITSTATUS" | /usr/bin/site_perl/sendxmpp -t  -u fryboyter -j jabjab.de -p 'strenggeheim' empfänger@deshalbfrei.org

Nun erstellen wir unter /etc/systemd/system die Servicedatei xmpp@.service mit folgendem Inhalt.

[Unit]
Description=Benachrichtigung mittels XMPP
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/xmpp.sh %I

Zum Schluss editieren wir noch die Service-Dateien der Dienste die wir überwachen wollen und packen unter dem Bereich [Unit] die Zeile OnFailure=xmpp@%n.service.

Startet nun ein Service nicht erhält man automatisch eine Nachricht per XMPP die beispielsweise so aussieht.

⚠ Unit failed monitorhell.service ⚠ Status: ● monitorhell.service - Tastaturbeleuchtung automatisch aktivieren
   Loaded: loaded (/etc/systemd/system/monitorhell.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2017-09-11 16:36:13 CEST; 1min 18s ago
  Process: 510 ExecStart=/bin/bashx -c echo 2219 > /sys/class/backlight/intel_backlight/brightness (code=exited, status=203/EXEC)
 Main PID: 510 (code=exited, status=203/EXEC)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

In meinem letzten Beitrag habe ich mein PeerVPN-Setup zur Realisierung meines Wartungsnetzes vorgestellt. Wenige Stunden später musste ich feststellen, dass ich bei meinem Setup etwas wichtiges nicht bedacht hatte: Bei einem Server-Neustart versuchen die Dienste, die nur über das Wartungsnetze 10.8.1.0/24 erreichbar sein sollen, sich an das srvnet0-Interface zu binden. Das schlägt allerdings fehl, denn der Docker-Container mit dem PeerVPN-Node startet erst wesentlich später, und die srvnet0-Schnittstelle existiert bis zu diesem Zeitpunkt noch nicht. Das wird mit Fehlermeldungen und nicht verfügbaren Diensten bestraft. Die Lösung ist, diese Dienste warten zu lassen, bis srvnet0 verfügbar ist.

Ein neues Systemd-Target einführen

Da der Zeitpunkt der srvnet0-Verfügbarkeit ein wichtiger Anker für weitere Abhängigkeiten ist, habe ich mich entschieden, auf meinen Systemen ein neues Systemd-Target /etc/systemd/system/srvnet0.target einzuführen:

[Unit]
Description=target is active if srvnet0 interface is available
Requires=sys-subsystem-net-devices-srvnet0.device
After=sys-subsystem-net-devices-srvnet0.device

Sobald die srvnet0-Schnittstelle verfügbar ist, wechselt der Status des Targets auf “active”, und alle vom Target abhängigen Dienste werden nun ebenfalls gestartet. Der Docker-Container mit PeerVPN wird bereits durch den automatisch startenden Docker-Daemon gestartet, denn als “restart”-Policy wurde für diesen Container “always” angegeben. Darum müssen wir uns also nicht kümmern.

Weitere Dienste vom Target abhängig machen

Nun, da das neue Target definiert ist, und den Zeitpunkt markiert, an dem die VPN-Schnittstelle verfügbar ist, muss dieses nur noch in die Service-Definitionen als Requirement aufgenommen werden:

After=srvnet0.target
Requires=srvnet0.target

Es ist allerdings ratsam, diese Definition nicht in bereits bestehenden Unit-Files zu ergänzen, sondern stattdessen eine weitere Konfigurationsdatei zu erzeugen, welche ein bestehendes Unit-File automatisch ergänzt. Soll beispielsweise der Unbound-Resolver (Service: unbound.service) auf die srvnet0-Schnittstelle warten, so wird ein Verzeichnis /etc/systemd/system/unbound.service.d/ angelegt, und darin eine Datei unbound.conf. Diese enthält folgenden Inhalt:

[Unit]
After=srvnet0.target
Requires=srvnet0.target

Systemd führt alle Unit-Files inkl. Ergänzungsdateien dann automatisch zusammen. Konflikte bei Paket-Upgrades durch manuell veränderte Unit-Files werden somit verhindert und Anpassungen bleiben von den Standardkonfigurationen sauber getrennt.

Die neue Systemd-Konfiguration wird nun neu geladen:

systemctl daemon-reload

Nach einem Reboot kann überprüft werden, ob Target und abhängiger Service erfolgreich gestartet wurden:

systemctl status srvnet0.target
systemctl status unbound.service

Beide Kommandos sollten in grüner Farbe “active” zeigen.

Die srvnet0-Schnittstelle ist übrigens schon verfügbar, bevor Traffic durch das VPN geschickt werden kann. Bis die Kommunikation zwischen den Nodes funktioniert, können noch ein paar Sekunden vergehen. Anwendungen können jedoch schon vorher Ports auf dieser Schnittstelle belegen.

Weitere Services können vom Target abhängig gemacht werden, indem für sie ebenfalls ein neues, passend benanntes Verzeichnis mit der oben stehenden Konfiguration angelegt wird. (Neuladen der Systemd-Konfiguration nicht vergessen!)