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.

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

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

a4

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

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?

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.

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.

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. 

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.

Überblick apt Befehle

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

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.

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.

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

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.

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

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

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.

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.

• “Gateway”: Der Server, auf dem das Mailsystem eingerichtet ist.
• Host” / “externer Host”: Ein Server, der für den Mailversand den Mailserver nutzen soll.

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" postmaster@mysystems.tld

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.

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.

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

Bild von JuralMin via pixabay / Lizenz: CC0 Public Domain

Ubuntu verfügt inzwischen neben der Hauptversion, die ab der kommenden Version 17.10 wieder mit GNOME ausgestattet sein wird, über fünf Derivate. Die bereits etablierten Kubuntu, Xubuntu und Lubuntu, sowie die beiden relativen Neuzugänge Ubuntu MATE und Ubuntu Budgie. Für den Anwender bedeutet das neben den Vorzügen der absoluten Wahlfreiheit, leider auch die Notwendigkeit sich für ein Derivat zu entscheiden. Lediglich in speziellen Nutzungsfällen macht die parallele Nutzung mehrere Desktopumgebungen wirklich Sinn.

Voraussetzungen

Die meisten langjährigen Linux-Anwender haben ihre Lieblingsdesktopumgebung. Bei mir war das lange KDE Plasma, inzwischen setze ich in meinen virtuellen Maschinen fast ausschließlich auf MATE. Im konkreten Fall soll aber ein System für eine Dritte Person eingerichtet werden, die eigentlich keine Präferenzen hat. Daher habe ich mir mal die Mühe gemacht alle Derivate in der aktuellen Entwicklungsversion in eine virtuelle Maschine auszutesten.

Die Zielhardware ist dabei sehr dankbar. Das Notebook ist bereits einige Jahre alt, aber noch hinreichend leistungsstark. Es handelt sich dabei um eine Kombination aus Intel Core i5 und eine Geforce 310M. Das benötigt keinen besonders aktuellen Kernel, schließt aber von der Leistung keine Desktopumgebung von vornherein aus.

[message_box title="Info" type="info" close="no"]Die Reihenfolge der Desktopumgebung orientiert sich an ihrer zeitlichen Aufnahme in das Ubuntu Projekt.[/message_box]

Ubuntu

Die Hauptvariante der Distribution liefert ab Version 17.10 wieder GNOME als Standard aus. Lediglich kleine Anpassungen an die Unity-Vergangenheit schwingen noch mit, wie das eigene Design und das ständig präsente Dock an der linken Seite.

Für die Hauptvariante spricht der offizielle Support im Main-Bereich der Distribution und die relativ stimmige Gesamtumsetzung des Derivats.

Gegen GNOME spricht im konkreten Fall der Fokus auf die Tastaturnutzung. Die GNOME Shell lässt sich zwar auch mit der Maus bedienen, aber sowohl der Programmstarter, wie auch die Aktivitätenübersicht ist mehr auf Tastaturbedienung ausgelegt. Insbesondere der Programmstarter wirkt durch fehlende Kategorien schnell unübersichtlich. Die starke funktionale Reduktion hat zudem definitiv ihren Zenit überschritten und wird durch die GNOME-Entwickler inzwischen schon zwanghaft betrieben. In Abwägungen scheint die Streichung einer Funktion immer erst eimal positiv vorbelegt zu sein und muss erst durch Argumente verhindert werden, anstatt anders herum.

Diiese Kritikpunkte lassen sich zwar mittels Addons beheben, damit holt man sich aber im Fall von Aktualisierungen oder Entwicklungsbrüchen unabsehbare Probleme ins Haus.

Zusammengefasst:

+ Ubuntu Main Support

+ Stimmiges Gesamtkonzept

+ Mäßig ansprechendes Design

- Präferenz auf Tastatureingabe

- Bedienkonzept weicht von allen anderen Desktops ab

- Übertriebener Reduktionismus

- Unübersichtliche Programmpräsentation

Kubuntu

Kubuntu ist historisch gesehen das erste Derivat und durch den zeitweiligen offiziellen Status auch noch immer recht hervorgehoben. Nach einer sehr unruhigen Phase rund um den Release von 16.04 hat das Projekt sich auch wieder gefangen und liefert wieder funktionsfähige Versionen aus.

KDE Plasma bietet ein stimmiges Gesamtpaket und die an Windows 7 angelehnte Bedienung erleichtert vielen den Umstieg. Einige Programme wie z.B. der Dateimanager Dolphin gehören sicherlich zu den besten im Linux-Ökosystem.

Die Unterstützung ist jedoch in den letzten Jahren zweifelhaft geworden. Bedingt durch die geringe Berücksichtigung der Interessen von LTS-Distributionen durch das KDE-Projekt und die geringe Kubuntu-Entwicklerzahl bleiben viele Probleme ungelöst und selbst sicherheitsrelevante Lücken bekommen nicht die notwendige Beachtung. Viele native Programme wie KMail kämpfen zudem seit Jahren mit Stabilitätsproblemen. Die weitere Entwicklung der Oberfläche (Stichwort Kirigami) ist zudem stark im Fluss, weshalb man nicht absehen kann, wo KDE Plasma in wenigen Jahren steht.

Zusammengefasst:

+ Stimmiges Gesamtkonzept

+ Konservatives Bedienkonzept (ähnlich wie Windows 7)

+ Ansprechendes Design

+/- Viele Einstellungsmöglichkeiten

- Unterstützung seit einiger Zeit problematisch

- Entwicklungsrichtung unklar

Xubuntu

Gemessen an Linux-Entwicklungszyklen ist Xfce bereits sehr alt. Xfce gibt es seit den 1990ern und die aktuelle Hauptversion 4 erschien bereits 2003. Xfce ist somit keine Eintagsfliege, aber das Alter der gegenwärtigen Hauptversion offenbart auch die schleppende Entwicklung.

Für Xubuntu spricht die konservative Bedienung des Desktops und die solide Programmauswahl. Das Design entspricht zudem modernen Standards und nimmt dem Desktop etwas von der veralteten Optik anderer Distributionen. Der Desktop lässt sich zudem recht flexibel mit modernen Elementen wie einem Dock oder einem individuellen Menü anreichern.

Etwas unklar ist jedoch die mittelfristige Perspektive. Version 4.14 schafft voraussichtlich erst den Sprung auf Gtk3, das wiederum bereits seit Jahren veröffentlicht ist. Es ist vollkommen unklar ob bei aktuellen Entwicklungsressourcen moderne Technologie wie Wayland oder HiDPI unterstützt werden können.

Zusammengefasst:

+ Relativ stimmiges Gesamtkonzept

+ Konservatives Bedienkonzept (ähnlich Windows XP)

+ Ansprechendes Design

- Mittel-/Langfristige Entwicklungsperspektive unklar

Lubuntu

Lubuntu teilt sich bereits seit einiger Zeit in zwei Entwicklungspfade. Standard bleibt auf absehbare Zeit die ressourcenschonende GTK2-basierte LXDE-Oberfläche. Daneben gibt es den LXQt-Entwicklungspfad, der mittelfristig einen modernen, ressourcenschonenden Desktop hervorbringen soll. Mit 17.10 bringt Lubuntu erstmals offiziell Images mit diesem Desktop heraus.

Lubuntu - Klassisch (LXDE)

Der klassische LXDE Desktop ist die ressourcenschonendste Oberfläche, die für Linux zur Verfügung steht - abgesehen von rudimentären Fenstermanagern.

Optisch lehnt sie sich an Windows XP an und durch die eingestellte Weiterentwicklung ist mit funktionalen Überraschungen nicht zu rechnen.

Problematisch ist aber, dass LXDE lediglich ein Desktop ist und nur wenige wirklich zugehörige Programme umfasst. Viele benötigte Programme sind deshalb aus anderen Oberflächen entliehen, weshalb der Desktop kein stimmiges Gesamtbild abgibt und sich die Programmbedienung oftmals stark unterscheidet.

Zusammgenfasst:

+ Funktional stabil

+ Ressourcenschonend

+ Sehr konservatives Bedienkonzept (ähnlich Windows XP)

- Entwicklung hinsichtlich LXQT unklar

- Kein stimmiges Gesamtkonzept

Lubuntu - Next (LXQt)

LXQt ist durch die Fusion der Entwicklerteams von LXDE und RazorQt entstanden und soll eine neue Generation des ressourcenschonenden Linux-Desktops einleiten. Optisch wirkt der Desktop durch den starken Rückgriff auf Oxygen-Designelemente aber bereits wieder veraltetet.

Durch die mögliche Verwendung von KWin als Fenstermanager eröffnet sich mittelfristig die Möglichkeit auf moderne Technologien wie Wayland zurück zu greifen. LXQt entwickelt hier als erster der kleinen Desktops eine Idee wie man in Zukunft weiter bestehen kann.

Trotz jahrelanger Entwicklung ist der Desktop dennoch bisher nur eine Technologievorschau. Die Softwaresammlung ist widersprüchlich (z.B. QTerminal und LXTerminal) und basiert im Hintergrund auf Qt, GTK und ihren widersprüchlichen Systemen (z.B. KIO und GVFS). Wie funktional dies im Alltag ist müsste sich erst zeigen - ressourcenschonend ist es nicht.

Ob LXQt in naher Zukunft wirklich LXDE beerben kann ist daher fraglich.

Zusammengefasst:

Entfällt wegen Entwicklungsstatus

Ubuntu MATE

Abspaltungen aufgrund von Unzufriedenheit mit der Entwicklung des Hauptprojekts gibt es bei Open Source-Projekten immer wieder. MATE beweist, dass man damit tatsächlich auch erfolgreich sein kann. Gestartet als Kopie von GNOME 2 hat man inzwischen erfolgreich den Sprung auf GTK3 geschafft und gleichzeitig das bewährte Bedienkonzept bewahrt.

Durch die Übernahme des GNOME 2-Quellcodes ist MATE unter den kleinen Projekten die vollständigste Desktopumgebung. Neben dem Desktop bietet man eine Reihe passender Programme. Die Entwicklung ist zudem verhältnismäßig agil, weshalb auch Zukunftsherausforderungen vermutlich gemeistert werden.

Die GNOME2-Basis hat aber auch Nachteile, die MATE bis heute nicht vollständig beheben konnte. Die Einstellungen sind ein wildes Sammelsurium kleinerer Programme und die Konfiguration der Leisten mit ihren Plugins äußerst kleinteilig. Ubuntu MATE lebt zudem stark vom Synchronisationsprozess mit Debian. Nach der Veröffentlichung einer Version enthalten die einzelnen Pakete nur noch wenig Pflege.

Zusammengefasst:

+ Funktional stabil

+ Ausgereiftes GNOME 2 Bedienkonzept

+ / - Verhältnismäßig ansprechendes Design

- Große Abhängigkeit von Debian

Ubuntu Budgie

Budgie ist der Neuling in der Ubuntu-Familie. Ursprünglich als Desktop für Solus Linux entwickelt, ist Budgie nun auch in andere Distributionen eingezogen. Die Zielgruppe von Budgie sind Anwender auf dem GNOME-Umfeld, die mit der GNOME Shell unzufrieden sind, jedoch auch nicht zu konservativen Ausprägungen wie Cinnamon oder MATE wechseln wollen.

Budgie hat ein erstaunlich durchdachtes Bedienkonzept mit einer Leiste am oberen Bildschirmrand einem Dock links und einer Widgetleiste rechts, die ähnlich wie bei macOS eingeblendet werden kann. Die Programmaustattung kommt größtenteils von GNOME, harmoniert aber gut mit dem Budgie Desktop. Die Einstellungsmöglichkeiten sind aber verhältnismäßig umfangreich.

Ubuntu Budgie hat seinen offiziellen Derivatstatus erst seit Version 17.04 ist verfügt deshalb zur Zeit über keine LTS-Variante. Langfristig gibt es wohl zudem Überlegungen den Desktop auf Qt zu portieren, weshalb die Entwicklungsrichtung unklar ist.

Zusammengefasst

+ Stimmiges Gesamtkonzept

+ Ansprechendes Design

- Keine LTS Version

- Entwicklungsrichtung unklar

- Vor allem für Solus entwickelt, Integration in Ubuntu erst seit kurzem

Fazit

Neben den althergebrachten Platzhirschen GNOME Shell und KDE Plasma haben sich zahlreiche Alternativen entwickelt. Diese Aufspaltung von Entwicklungsressourcen schlägt sich jedoch bei manchen Projekten auch negativ nieder, wie man z.B. bei Xfce oder LXQt sehen kann. Die positive Überraschung war für mich Budgie, das ich bisher unter "Noch so ein GNOME-Fork" abgetan hatte. Wem die GNOME Shell nicht gefällt und die KDE-Entwicklungsrichtung nicht passt, sollte sich das unbedingt mal ansehen.

Im konkreten Fall wird es wohl auf MATE oder Budgie hinauslaufen. Je nachdem wie modern es der Anwender haben möchte. Denn in gewisser Weise wirkt Budgie wie die moderne Inkarnation von MATE.

Bilder im PNG- und JPG-Format sind komprimiert – oft jedoch nicht so stark, wie es möglich wäre. Für schnelle Internetseite kann das aber ein entscheidender Faktor sein. Das Plugin „Compress JPEG & PNG images“ von TinyPNG hilft dabei.Mit meinem letzten Theme hatte ich es schon einmal geschafft: 100 Punkte beim Google Pagespeed Test. Allerdings war das damals schon nicht so ganz leicht und mir ist es noch schwerer gefallen, das zu reproduzieren. Vor allem das verdammte „Above the Fold“-Problem raubt mir den letzten Nerv. Auf dem Desktop häng ich jetzt bei 97 Punkten und bei Mobile bei 85 Punkten…

EWWW Image Optimizer genügt nicht

Geärgert hat mich aber auch, dass angeblich meine Bilder nicht genügend komprimiert seien. Lange Zeit war ich mit dem „EWWW Image Optimizer“ gut gefahren. Aber irgendwie zeigte mir der Google Test ständig an, dass die Bilder noch kleiner sein könnten. Ich habe dann verschiedene Plugins durchprobiert und festgestellt, dass man bei denen immer auch eine Bezahlkomponente hat. Eine bestimmte Anzahl Bilder sind kostenlos – alles darüber hinaus kostet Geld. Na gut – dann sind aber meine Ansprüche auch andere!

TinyPNG kannte ich schon als Dienst, über den man auch Bilder für Facebook unkompliziert optimiert komprimieren lassen kann. Die bieten ein eigenes WordPress-Plugin an und das funktioniert erst einmal ganz unkompliziert: Installieren und dann einmal die Mediathek durch-komprimieren. Bis 500 Bilder ist das kostenlos – danach kostet das Geld (Kreditkarte!). Allerdings waren das für mein Blog nur rund 5 €. Das ist es mir Wert, denn ab da meckerte Google nicht mehr. Ab jetzt habe ich 500 Bilder pro Monat frei. Das werde ich sehr wahrscheinlich in nächster Zeit nicht überschreiten.

Geschwindigkeit könnte besser sein

Allerdings dauert es jetzt wesentlich länger, wenn ich ein neues Bild hochlade. Das Bild wird nun einmal zunächst in meine Mediathek geladen, dann per API an TinyPNG geschickt, komprimiert und per API wieder zurück geschickt. Da könnte ich mir noch einen besseren Ablauf vorstellen, der das mehr im Hintergrund passieren lässt, denn in der Zwischenzeit kann ich bei dem Bild keine Meta-Daten eintragen und ich kann auch nicht am Artikel weiterarbeiten. Zumindest könnte man darauf hingewiesen werden, was gerade passiert. Ich selbst weiß das ja – aber wenn ich andere Leute mit dem Plugin arbeiten lassen würde, müsste ich denen das erst erklären.

Das Ergebnis aber kann sich sehen lassen: Meine Mediathek ist um 27% geschrumpft, der Google Speedtest meckert nicht mehr. Ich bin zufrieden.

Links

• Plugin-Seite: Compress JPEG & PNG images

Das beste WordPress Plugin für komprimierte Bilder

TrueOS (vormals PC-BSD) will im übertragenen Sinn das Ubuntu der BSD-Welt sein. Ein einfach zu installierendes Desktop-Betriebssystem, das dem potenziellen Benutzer einen möglichst leichten Einstieg ermöglicht. Hinter TrueOS steht iXsystems von denen auch FreeNAS stammt. Standardmäßig setzt TrueOS auf die Desktop-Eigentwicklung Lumina, die genau wie KDE Plasma auf Qt 5 als Toolkit setzt.

Manchmal macht man einen Blick über den Tellerrand und es lohnt sich im Nachhinein. FreeNAS war bei mir so ein Fall. Eigentlich hat mich BSD immer abgeschreckt. Man hat wenig Erfahrung damit und es gilt als kompliziert. FreeNAS war jedoch das genaue Gegenteil davon. Ein richtiger Quantensprung gegenüber Linux-Pendants wie OpenMediaVault. Daher wollte ich nun auch mal BSD auf dem Desktop probieren. TrueOS schien hier aufgrund der gleichen Firma im Hintergrund die richtige Wahl zu sein.

Installation

Die Installation ist für den geübten Linux-Nutzer keine Hürde. Man lädt ein über 2GB großes ISO-Image herunter und bootet von diesem. Die Installation lässt einem recht wenige Möglichkeiten und durch Abnicken der Voreinstellungen erreicht man nach wenigen Minuten (abhängig von der Leistungsfähigkeit der Hardware) eine funktionsfähige TrueOS-Installation.

Ähnlich wie bei Fedora erfolgt die abschließende Einrichtung des Systems erst nach dem ersten booten. Erst jetzt werden Systemzeitzone und andere Informationen eingestellt, sowie ein Benutzer angelegt.

Da der hiesige Test in einer virtuellen Umgebung erfolgte lässt sich zur Hardwareunterstützung leider nicht viel schreiben.

Lumina Desktop

Ist die Einrichtungsroutine absolviert begrüßt einen der Lumina-Desktop.

Lumina ist eine Reaktion auf die stärkere Verzahnung der restlichen freien Desktopoberflächen mit Linux. Moderne Oberflächen wie KDE Plasma und GNOME benötigen z.B. inzwischen systemd, was für BSD nicht zur Verfügung steht.

Die Entwicklung von Lumina hat inzwischen Version 1.3 hervorgebracht und schon einige Jahre Entwicklungszeit hinter sich. Um ehrlich zu sein: Das merkt man dem System nicht an! Die Stabilität ist zwar in Ordnung, aber funktional ist Lumina ein etwas besserer Fenstermanager. Als Linux-Nutzer hat man ja Erfahrung mit spartanischen Umgebungen und simplen Fenstermanagern. Lumina hat hier aber im direkten Vergleich ungefähr den Workflow von IceWM - natürlich mit einer etwas moderneren Optik.

Am unteren Rand ist eine herkömmliche Fensterleiste positioniert, in der sich links ein Startmenü im Stile von Windows 95 versteckt. Rudimentäre grafische Einstellungsmöglichkeiten, sowie ein Updatemanager ermöglichen dem Anwender die Konfiguration und Wartung des Systems.

Die Basisanwendungen wie Mediaplayer, Dateimanager, PDF-Viewer etc. werden durch Eigenentwicklungen bedient. Diese sind funktional durchweg rudimentär. Beispielhaft sei hier auf den Lumina-Dateimanager verwiesen.

Vorinstalliert sind zudem eine Reihe von Qt-Programmen wie z.B. Qupzilla als Browser oder Trojita für Mails. Deren Qualität schwankt von Programm zu Programm. Während VLC beispielsweise natürlich vollkommen ausgereift ist, kann man gleiches von Trojita wirklich nicht behaupten. Diese Schwächen haben aber wenig mit TrueOS oder Lumina zu tun, sondern sind direkte Folgen der eingeschränkten Programmauswahl im Qt-Bereich.

Fazit

BSD als Unterau machte in diesem Test keinen schlechten Eindruck. Während im Server- und NAS-Bereich gegenüber Linux aber echte Vorteile existieren, ist der Desktop eher ein Rückschritt. Die mit viel PR angekündigte Eigenentwicklung ist funktional auf dem Stand kleinerer Linuxprojekte wie LXQt oder simpler Fenstermanager. Selbst konservativ entwickelte Desktopumgebungen wie beispielsweise Xfce haben hier definitiv die Nase vorn.

Für Puristen eventuell eine Alternative, für alle anderen jedoch kein Grund zu wechseln.

Ich stand an mehreren Stellen vor dem Problem, auf einen gemeinsamen Ordner und Dateien mit verschiedenen Benutzern zugreifen zu wollen. Aus Sicherheitsgründen sollten allerdings nicht alle Benutzer Lese- und Schreibrechte haben, sondern ich wollte die Rechte gerne feiner festlegen.

Das Problem

Konkret hatte ich zwei Fälle.

1. Lokale User sollten über SAMBA Shares lesend und schreibend auf die Files zugreifen können.
2. Ein lokal installierter Webserver soll nur lesend auf die Dateien zugreifen können
3. Ein externer Server soll über einen SSH Zugang lesen und schreiben können.

im zweiten Fall sollte

1. ein Webserver lesend und schreibend auf ein Verzeichnis und Dateien zugreifen können
2. ein weiterer Benutzer lesend und schreibend auf das selbe Verzeichnis und Dateien zugreifen.

Grundsätzlich lassen sich beide Fälle lösen, indem alle Benutzer die auf das Verzeichnis lesend und schreibend zugreifen können sollen in eine Benutzergruppe gepackt werden und diese als primäre Gruppe festgelegt wird. Dies war auch meine ursprüngliche Lösung.

Durch setzen der entsprechenden umask werden alle Dateien und Verzeichnisse beim Erstellen mit Lese- und Schreibrechten für die betroffenen Benutzer ausgestattet. Das Setzen des Lesezugriffs für alle Benutzer erlaubt es weiteren Benutzern auf die Dateien zugreifen zu können, ohne Schreibzugriff zu erhalten.

Leider habe ich die Lösung als unbefriedigend empfunden. Standardmäßig habe ich eine umask von 027 gesetzt, wobei sonstige Benutzer grundsätzlich weder Lese- noch Schreibrechte erhalten. Dies musste ich wieder aufweichen.
Außerdem herrscht im gemeinsamen Verzeichnis ein Wildwuchs an Dateien von verschiedenen Benutzern.
Durch das setzen einer gemeinsamen Standardgruppe, werden alle von den betroffenen Benutzern erstellte Dateien überall mit der gemeinsamen Gruppe erstellt und können dadurch auch überall von den betroffenen Usern gelesen bzw. geschrieben werden. Ich hätte das Recht allerdings gerne auf das eine, gemeinsame Verzeichnis beschränkt.

Generell habe ich das hantieren mit verschiedenen Dateirechten, Gruppen, umask usw. als unübersichtlich und chaotisch empfunden und habe mich mit der Lösung schlichtweg nicht wohlgefühlt.

Die Lösung

Durch Zufall bin ich auf eine Lösung gestoßen, welche mir sehr viel besser gefällt: bindfs

Mit bindfs lässt sich ein Verzeichnis an verschiedenen Stellen mit verschiedenen Berechtigungen mounten. Auf Wunsch werden alle in das Verzeichnis geschriebenen Dateien mit einem bestimmten User und bestimmten Rechten erstellt.

D.h.:

1. Jeder Benutzer sieht das Verzeichnis so als wäre es sein eigenes und mit den Rechten die dieser Benutzer benötigt. z.B. Eigentümer sftp:sftp
2. In Wirklichkeit werden die Dateien aber mit den Rechten eines anderen Benutzers ins Dateisystem geschrieben. z.B. www-data:www-data
3. Alle Dateien die außerhalb des gemeinsamen Verzeichnisses geschrieben werden, werden mit den normalen Rechten des Users geschrieben (z.B. im Homeverzeichnis).

Bindfs ist somit sehr flexibel, was das einstellen von Berechtigungen für einen gemeinsamen Mountpoint angeht. Realisiert wird dies durch die Benutzung von FUSE, was zwar sehr flexibel und bei mir bisher auch sehr zuverlässig ist, allerdings sehr viel weniger performat und mehr Last auf der CPU erzeugt als das direkte Schreiben ins Dateisystem.

Es macht also Sinn, dass der Benutzer der die Dateien ständig benutzt (z.B. der Webserver oder Samba) auch der tatsächliche Eigentümer der Files ist und auch direkt in das gemeinsame Verzeichnis schreibt.

Benutzer welche das Verzeichnis nicht ständig benutzen mounten das gemeinsame Verzeichnis über bindfs.

ein Beispiel

In diesem Beispiel wird ein gemeinsames Verzeichnis für die Benutzer samba und sftp erstellt, in welches beide Benutzer schreiben dürfen. Tatsächlich werden alle Dateien aber mit dem Benutzer samba ins Dateisystem geschrieben.

Installieren lässt sich bindfs unter Ubuntu / Debian aus den Paketquellen

sudo apt install bindfs

Dann kann der gemeinsame Ordner erstellt und die gewünschten tatsächlichen Rechte vergeben werden

sudo mkdir -p /mnt/samba/shares
sudo chown -R samba: /mnt/samba/shares

Als nächstes wird der Mountpoint für den zusätzlichen User erstellt.

sudo mkdir -p /mnt/sftp/samba
sudo chown -R sftp: /mnt/sftp/samba

Damit /mnt/samba/shares auch unter /mnt/sftp/samba mit den entsprechenden Rechten gemounted wird muss folgender Eintrag in die /etc/fstab hinzugefügt werden:

bindfs#/mnt/samba/shares /mnt/sftp/samba fuse force-user=sftp,force-group=sftp,create-for-user=samba,create-for-group=samba,chgrp-ignore,chown-ignore,chmod-ignore 0 0

Dadurch werden alle durch den Benutzer sftp erstellten Dateien tatsächlich mit dem Benutzer samba erstellt.

Test

zum testen erstellen wir mit jedem Benutzer eine Datei, jeweils im Verzeichnis welches diesem User gehört.
zuerst als User samba

su samba
cd /mnt/samba/shares
touch testfile-samba.txt

dann als User sftp

su sftp
cd /mnst/sftp/samba
touch testfile-sftp.txt

und siehe da: In beiden Verzeichnissen erscheinen nun beide Dateien. Im Verzeichnis des Users samba mit diesem als Eigentümer und im Verzeichnis des Users sftp mit diesem als Eigentümer.

weitere Beispiele und die Dokumentation ist auf der Homepage des Projekts zu finden: http://bindfs.org/

Die kleine Notizverwaltung Notes-up für Linux kann Notizen als hübsch gestaltetes PDF exportieren – seit kurzem nutze ich das Tool auch in der Arbeit. Die Notizen kann man im Bearbeitungsmodus mit Markdown auszeichnen und in einer schicken Vorschau anzeigen lassen. Genau so exportiert Notes-up sie dann als PDF. Die Optik beeinflussen Stylesheets, die man auch verändern kann. Notes-up wurde eigentlich für ElementaryOS geschrieben und lässt sich dort aus den Paketquellen installieren. Zwar sieht das Tool unter ElementaryOS noch besser aus, nutzen kann man es aber auch unter (X)Ubuntu.

Notes-up verwendet Markdown zur Gestaltung des Dokuments, stellt aber auch Buttons für die wichtigsten Formatierungen bereit. Ein Hilfebutton klappt eine Übersicht über Markdown-Auszeichnungen aus. Im Programm wechselt man zwischen „Bearbeiten“ und „Ansicht“. Letzteres zeigt, wie das Dokument aussieht, wenn es mit Hilfe des gewählten Stylesheets gestaltet wurde. In den Einstellungen unter „Ansicht“ stehen drei Stylesheets zur Wahl; eigene Anpassungen sind möglich. In einer der letzten Versionen hat der Entwickler eine Rechtschreibprüfung eingebaut.

Im Bearbeitungsmodus von Notes-up zeichnet man den Text mit Markdown aus. Eine Hilfe liefert bei Bedarf die wichtigsten Auszeichnungen.

Zwar gibt es eine Launchpad-Paketquelle zur Installation unter Ubuntu, darin fehlen allerdings aktuelle Programmversionen. Da in älteren Ausgaben der Export auf einer deutschsprachigen Desktop-Oberfläche noch nicht funktioniert, muss man das Tool für Ubuntu und Co. selbst kompilieren. Dafür sind einige Tools und Bibliotheken nötig, die der folgende Befehl nachrüstet:

sudo apt install cmake valac git libwebkit2gtk-4.0-dev libgee-0.8-dev libgtksourceview-3.0-dev libgtk-3-dev libgranite-dev libsqlite3-dev libglib2.0-dev libgtkspell3-3-dev

Anschließend braucht man noch das aktuelle Release, das als ZIP-Archiv oder mit git heruntergeladen wird. Mindestens Version 1.4.5 sollte es sein, denn nur mit dieser funktioniert der Export in PDFs auch auf deutschen Desktop-Oberflächen.

Selbst kompilieren leicht gemacht

Ich fand den Weg mit Git ganz bequem, die folgenden Befehle holen den aktuellen Quellcode von Github, danach wechselt der angemeldete User ins Verzeichnis Notes-up, legt dort ein Verzeichnis build an und wechselt hinein. Der cmake-Befehl kompiliert dann das Programm, wobei der Parameter --Dnoele=1 dafür sorgt, dass ElementaryOS-typische Abhängigkeiten wie Contractor entfallen.

git clone https://github.com/Philip-Scott/Notes-up
cd Notes-up
mkdir build && cd build
cmake --Dnoele=1 -DCMAKE_INSTALL_PREFIX=/usr ../

Installation mit checkinstall

Theoretisch könnte es danach mit sudo make install weitergehen. Ich installiere das Programm allerdings lieber als Paket über die Paketverwaltung, so dass ich es bei Bedarf leichter wieder loswerde. Dazu muss das Paket checkinstall installiert sein, das aus dem kompilierten Code ein Debian-Paket baut und einrichtet. Zur abschließenden Installation von Notes-up tippt man dann immer noch im build-Verzeichnis:

sudo checkinstall

Dabei fragt checkinstall einige Bezeichnungen ab, unter anderem sollte man das Paket „notes-up“ nennen, um es später in der Paketverwaltung wiederzufinden. Um das Programm bei Nichtgefallen wieder loszuwerden reicht dann der Befehl sudo dpkg -r notes-up .

Stylesheets und Schriften

Notes-up kann auch Zeilennummern zeigen und die Rechtschreibung kontrollieren.

Nicht immer sehen die Notizen dann gleich gut aus. Falls zum Beispiel die im Stylesheet verwendeten Schriftarten Open Sans und Droid Sans fehlen, verwendet Notes-up eine Standardschrift wie Helvetica. Die Schriften stehen unter fonts.google.com zum kostenlosen Download bereit. Sie müssen dann nur in ein neu angelegtes Verzeichnis .fonts im Home-Verzeichnis entpackt werden. Beim nächsten Programmstart findet Notes-up sie dann auch.

Der Beitrag Notes-up: Notizenverwaltung unter (X)Ubuntu installieren erschien zuerst auf Linux & Open-Source-Blog.

In einem anderen Artikel habe ich ausführlich über die Konfiguration von vdirsyncer gesprochen. In diesem Artikel soll es nur schnell um die Eigenheiten bei der Verbindung mit der Sogo Groupware gehen.

Kalendar

Das besondere ist hier eigentlich nur der Link für den Kalender:

 url = "https://exmaple.com/SOGo/dav/mein@email.com/Calendar/"

Dann wird vdirsyncer automatisch alle Links finden.

Kontakte

Der Link für die Kontakte sieht ähnlich aus:

url = "https://exmaple.com/SOGo/dav/mein@email.com/Contacts/"

Hier gibt es die Möglichkeit, am Ende noch speziell das Adressbuch hinzuzufügen:

url = "https://exmaple.com/SOGo/dav/mein@email.com/Contacts/personal/"

Dann kurz ein vdirsyncer discover dann ein vdirsyncer sync und fertig alles ist synchronisiert!

Bereits vor ein paar Monaten ist Linphone 4.x erschienen. Der freie SIP Client hat eine dringend benötigte Oberflächenkur erhalten.

Die Telefonie Software für Linux, Mac OS X und Windows basiert auf Qt 5.9 und hat neben der modernen UI eine intelligente Suchleiste erhalten. Diese erlaubt es Kontakte zu suchen, Chats zu starten oder Anrufe zu tätigen.

Anrufe können nun auch via HD Video geführt werden, Konferenzen werden unterstützt, sowie Chats als Ergänzung zum Gespräch.
Zur Nachverfolgung wurde ein globaler Verlauf für Anrufe, Chats und Co integriert. Die Software steht weiterhin unter GPLv2 Lizenz und somit frei zur Verfügung.

Installation unter Ubuntu, Mint und Elementary OS

Für Debian Systeme steht ein Repository zur Verfügung, welches allerdings nicht auf einem aktuellen Stand ist und nur Version 3.9.x anbietet:

sudo add-apt-repository ppa:linphone/release

sudo apt-get update

sudo apt-get install linphone

Es besteht die Option das Programm selbst zu builden, bei mir sind allerdings die ersten Versuche gescheitert...in einer virtuellen Umgebung. Eventuell hat einer hier mehr Glück, mir fehlt dazu gerade etwas die Zeit.

sudo apt-get install git build-essential automake autoconf libtool   \
intltool libgtk2.0-dev libspeexdsp-dev libavcodec-dev libswscale-dev \
libx11-dev libxv-dev libgl1-mesa-dev libreadline-dev libgsm1-dev     \
libtheora-dev libsqlite3-dev libupnp-dev libsrtp0-dev open-vm-tools   \
open-vm-tools-dev cmake-* libmbedtls-dev libmbedtls-doc libmbedtls10   \
libcunit1 libcunit1-dev libantlr3c-dev libantlr3-runtime-java antlr3 \
libortp-dev libortp9 libmediastreamer-base3 libmediastreamer-dev     \
extra-cmake-modules yasm libv4l-dev libasound2-dev python-pip doxygen graphviz xcode ninja

git clone https://github.com/BelledonneCommunications/linphone-desktop.git
cd linphone-desktop
git submodule sync && git submodule update --init --recursive
./prepare.py

make
sudo make install

Fazit

Die Software hat mit der neuen Oberfläche eine riesen Schritt gemacht, auch die frischen Funktionen sind nicht zu verachten. Wie schon beim letzten Artikel über Linphone ist die Konkurrenz immer noch relativ klein. Ekiga 5 lässt weiterhin auf sich warten, X-Lite/Bria ist Closed Source. Lediglich Jitsi bietet ähnliche Funktionen. 

Wer sichere Kommunikation für wichtig hält, ist mit Linphone relativ gut beraten, da es moderne Technologien wie zRTP, TLS und SRTP unterstützt.

Bevor es keine Möglichkeit gibt Version 4.x via Repository zu beziehen, ist zumindest für Alltags Linux Nutzer die Einstiegshürde etwas hochgelegt. Windows und Mac Anwender, können allerdings bereits einen Installer laden, was ich für meinen ersten Test auch getan habe.

PowerLAN, auch bekannt als dLAN oder Powerline, bezeichnet eine Technologie, zum Aufbau eines lokalen Netzwerks, unter Nutzung vorhandener Stromleitungen.

Adapter verschiedener Hersteller versprechen dabei eine Übertragungsgeschwindigkeit von bis zu 2000 Mbit/s. Doch ob diese Geschwindigkeit im eigenen Haushalt auch nur annähernd erreicht wird hängt von vielen Faktoren ab. Darunter fallen z.B. Alter und Zustand der Hausverkabelung, aber auch angeschlossene elektrische Geräte können die Übertragungsgeschwindigkeit negativ beeinflussen.

Um die Geschwindigkeit des PowerLAN zu messen bietet sich das Programm iperf an, welches unter allen gängigen Linux-Distributionen zur Verfügung steht.

Test der Messmittel

Bevor man mit der Messung beginnt und viel Mist misst, sollte man noch ein paar Dinge beachten.

Um mit iperf die Geschwindigkeit des Netzwerks zu messen, kommen in meinem kleinen Versuchsaufbau zwei Notebooks mit Ubuntu 16.04 LTS und Gigabit-Netzwerkkarte zum Einsatz. Denn selbstverständlich haben auch die Geschwindigkeit der verwendeten Netzwerkkarten und selbst der Netzwerkkabel einen Einfluss auf das Messergebnis. Verwendet man Netzwerkkarten mit einer Geschwindigkeit von 100 Mbit/s oder ist schon ein paar Mal mit dem Bürostuhl über das Netzwerkkabel gerollt, darf man sich nicht wundern, wenn man nicht mal annähernd an die versprochene Geschwindigkeit herankommt. Aber auch andere Programme, die evtl. zur gleichen Zeit ausgeführt werden und das Netzwerk nutzen, können die Messergebnisse beeinträchtigen. Es gilt diese Störfaktoren möglichst auszuschließen.

Die beiden Notebooks verbinde ich zuerst über einen Gbit-Switch miteinander. Dazu verwende ich die neuen LAN-Kabel, welche den PowerLAN-Adaptern beiliegen. Dank IPv6 ist keine weitere Konfiguration der Schnittstellen erforderlich. Es können direkt die link-local Adressen genutzt werden, um miteinander zu kommunizieren. Nun wird auf einem der beiden Notebooks iperf (iperf -s) im Servermodus gestartet, womit es auf eingehende Verbindungen wartet.

Auf dem anderen Notebook wird iperf im Client-Modus gestartet (iperf -c hostname), welches sich dann zum Server verbindet und mit der Messeung beginnt. Das Ergebnis einer solchen Messung ist der folgenden Ausgabe zu entnehmen:

------------------------------------------------------------
Client connecting to fe80::%eth0, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local fe80:: port 47748 connected with fe80:: port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.07 GBytes   915 Mbits/sec

Bei ca. 10 Wiederholungen dieses Tests lag die Geschwindigkeit stets zwischen 910 Mbits/s und 936 Mbits/s. Für einen kleinen SoHo-Switch ein hervorragendes Ergebnis. Nun bin ich natürlich gespannt, ob die PowerLAN-Adapter die angepriesene Geschwindigkeit ebenfalls liefern können.

Messung der PowerLAN-Verbindung

Die PowerLAN-Adapter wurden direkt in Wandsteckdosen eingesetzt. Die integrierten Steckdosen sollen von weiteren Endgeräten verursachte Störungen auf der Leitung herausfiltern und so die bestmögliche Leistung garantieren.

In meinem Versuchsaufbau befand sich ein Adapter im Erdgeschoss, während der andere im darüberliegenden Raum im 1. OG angeschlossen wurde. Beide Adapter haben sich innerhalb kurzer Zeit gefunden und zu einem Paar verbinden lassen.

Anschließend wurde die Übertragungsgeschwindigkeit mit iperf gemessen. Die Messung wurde mehrfach wiederholt, um Ausreißer erkennen zu können. Das Ergebnis war leider sehr enttäuschend. Die durchschnittliche Übertragungsrate lag bei 31 Mbit/s. Ausreißer gab es ledigich nach unten, wo bei einigen Tests nur 7 Mbit/s übertragen wurden.

In der Folge habe ich noch weitere Messungen an anderen Steckdosen im Haus durchgeführt, kam aber nicht über eine maximale Übertragungsrate von 36 Mbit/s hinaus. Hinzu kommt die Beobachtung, dass die getesteten Adapter während einer Messung wiederholt die Verbindung zueinander verloren und Messungen wiederholt werden mussten.

Leider bestätigten sich damit Ergebnisse aus früheren Tests, so dass kein sinnvoller Einsatz dieser Technik in unserem Haus möglich scheint.

Fazit

PowerLAN verspricht die schnelle und einfache Vernetzung von netzwerkfähigen Geräten über das Stromnetz in der eigenen Wohnung bzw. im eigenen Haus. Die versprochenen Übertragungsraten von teilweise mehr als 1 Gbit/s werden dabei jedoch nicht in jedem Fall erreicht. Häufig liegen diese sogar deutlich unter den angegebenen Maximalwerten. Daher ist ein Test der Übertragungsgeschwindigkeit in jedem Fall empfehlenswert.

Bevor man jedoch mit der Messung beginnt, sollte man die eingesetzten Messmittel auf ihre Tauglichkeit und Leistungsfähigkeit hin überprüfen. Denn sonst gilt wieder: „Wer viel misst, misst viel Mist.“

Wer den Nextcloud-Client wie im Artikel „Nextcloud-Client für Debian 9“ beschrieben installiert hat, wird evtl. festgestellt haben, dass die Quelle von opensuse.org kaputt ist.

Abhilfe schafft ein Austausch des vorhandenen Eintrags in der /etc/apt/sources.list.d/nextcloud-client.list. Dazu öffnet man diese mit:

nano /etc/apt/sources.list.d/nextcloud-client.list

Nun wird die Zeile

deb http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/ /

durch

deb http://ppa.launchpad.net/nextcloud-devs/client/ubuntu zesty main

ersetzt und die neue Quelle mit

apt-key adv --recv-key --keyserver keyserver.ubuntu.com AD3DD469

verifiziert.

Viel Spaß!

Der Beitrag Nextcloud-Client – Quelle kaputt erschien zuerst auf .

In meinem Beitrag “Dezentrales HA Servercluster-VPN mit PeerVPN” habe ich euch PeerVPN vorgestellt - einen kleinen Peer-to-Peer VPN-Server, der sich wunderbar eignet, um seine Hosts miteinander zu vernetzen. Ich betreibe selbst mehrere Server an verschiedenen Standorten, die direkt miteinander Daten austauschen. So kommuniziert beispielsweise jeder Host mit einem zentralen Munin-Server, um Statusupdates zu senden. Auch Icinga-Daemons laufen auf den Hosts und prüfen verschiedene lokale Dienste. Das Ergebnis wird an das Icinga-Backend geschickt.

All diese Kommunikation soll für die Öffentlichkeit nicht einsehbar sein, d.h.:

• Die Existenz von Wartungs- und Verwaltungsdiensten soll verborgen werden
• Die Verbindung soll verschlüsselt werden: Internet und Hoster kann im Zweifel nicht getraut werden
• Nur autorisierte Personen oder Maschinen sollen Zugriff auf bestimmte Dienste haben (z.B. Admin, Munin-Frontend)

Ziel ist also ein “Wartungsnetz”, welches nur dem Austausch der Hosts untereinander und dem Administrator dienen soll. Dienste wie Munin-Clients, Icinga-Clients, Docker-Daemons und sonstiges werden fest an die IP-Adresse aus dem Wartungsnetz gebunden und sind damit nicht mehr über die öffentlichen IP-Adressen des jeweiligen Hosts erreichbar. Das bringt drei Vorteile mit sich:

• Ein aufgeräumtes Setup: Öffentliches kommt ans Internet, Privates in ein eigenes Netz.
• Sicherheit:
  • Sicherheitskritische Dienste und Dienste, die nicht für die Öffentlichkeit bestimmt sind, sind aus dem Internet nicht erreichbar.
  • Es gibt Client-Server-Software, die nicht für den Betrieb im Internet ausgelegt ist, sondern nur für die Verwendung innerhalb eines Rechenzentrums (z.B. in dedizierten, lokalen Netzen). Auf Verschlüsselung und Authentifizierung wird hier oftmals verzichtet. Diese Software kann in einem solchen Wartungsnetz trotzdem guten Gewissens genutzt werden.
• Komfort: Software via MySQL, Redis und weitere beherrschen zwar oft die Absicherung der Verbindung in einem Client-Server / Cluster -Setup, doch das Einbinden neuer Nodes ist nicht immer bequem. So beherrscht beispielsweise auch Munin sichere Verbindungen via TLS - dafür muss dann aber eine X.509-CA aufgebaut und gepflegt werden. Das schließt dann auch das umständliche Hantieren mit Zertifikaten ein. In einem dedizierten, sicheren Host-Netz kann auf die Munin-eigene Authentifizierung verzichtet werden.

Heute habe ich die vollständige Vernetzung all meiner Hosts in ein eigenes Wartungsnetz (bzw. virtuelles “lokales” Netz) in Angriff genommen. Sofort war klar, dass ich das Netz mit PeerVPN realisieren wollte, um einen Single Point of Failure zu vermeiden. Bei Installieren der Software auf dem ersten Server ist mir jedoch folgendes aufgefallen:

• PeerVPN ist nicht kompatibel mit OpenSSL 1.1, welches von allen Hosts verwendet wird. Das Problem lässt sich lösen, indem PeerVPN statisch mit LibreSSL gelinkt wird. Dann bekommen die LibreSSL-Bibliotheken allerdings keine automatischen Updates durch das Betriebssystem. Heißt: Updates für LibreSSL müsste ich dann manuell verfolgen, und auf jedem der Hosts bei Bedarf PeerVPN neu linken.
• Die Installation von PeerVPN ist nicht besonders zeitintensiv, aber die Einrichtung auf mehreren Hosts artet dann doch in Arbeit aus: Quellcode herunterladen, LibreSSL herunterladen, PeerVPN kompilieren und linken, im System integrieren, und einen Systemd-Service erstellen.

Das muss doch auch bequemer gehen. Und vor allem die Sache mit den Updates wollte ich eleganter gelöst haben.

Eine komfortable Lösung: PeerVPN im Docker-Container

Wenn man eine einzelne Anwendung als Baustein unabhängig vom Hostsystem ausrollen will, bieten sich Linux-Container an. Ich musste sofort an einen Docker-Container denken, den ich auf jedem meiner Hosts starten kann. PeerVPN sollte im Docker-Container laufen und mittels Host-Networking allen anderen Diensten auf demselben Host den Zugriff auf das Wartungsnetz ermöglichen. Glücklicherweise hat sich Markus Juenemann bereits Gedanken zu PeerVPN unter Docker gemacht, sodass ich seine Arbeit aufgreifen konnte. Ein paar kleine Änderungen habe ich schließlich in einen Fork des Projekts eingebracht: https://github.com/ThomasLeister/docker-alpine-peervpn (die meisten Änderungen sind inzwischen via Pull Request zurück in das Originalprojekt geflossen)

VPN Deployment auf den Hosts

Von nun an war die Verknüpfung der Hosts miteinander ein Kinderspiel. Docker und Docker-Compose waren auf den meisten Maschinen schon vorhanden. Für die Integration eines neuen Hosts in das Wartungsnetz waren nur noch 2 Schritte notwendig:

1) Docker-Compose File auf den Host kopieren

version: '3'
services:
peervpn:
image: thomasleister/peervpn
container_name: "peervpn"
network_mode: "host"
cap_add:
- NET_ADMIN
restart: "always"
environment:
NETWORKNAME: srvnet
INTERFACE: "srvnet0"
PSK: "meintollerpresharedkey"
LOCAL: "0.0.0.0"
PORT: 7000
INITPEERS: "1.2.3.4 7000"
IFCONFIG4: "10.8.1.1/24"
ENABLERELAY: "yes"
ENABLEIPV6: "no"

(… und anpassen!)

2) PeerVPN starten

docker-compose up -d

Zur Überprüfung der Funktion kann die Ausgabe von PeerVPN beobachtet werden:

docker-compose logs -f peervpn

Nach wenigen Sekunden können sich alle teilnehmenden Hosts über die 10.8.1.x-IP-Adressen erreichen, oder auf dem srvnet0 Interface eigene Dienste über dieses Netz verfügbar machen.

Automatische Updates mit Watchtower

Ein generelles Problem beim Einsatz von Docker sind fehlende, automatische Updates. So würde mein Alpine-Linux-Container mit PeerVPN nach dem ersten Pull des Images immer mit demselben Softwarestand laufen bzw. wieder gestartet werden. LibreSSL-Updates würden meinen Container nicht ohne weiteres Zutun erreichen. Ich müsste ständig selbst nachsehen, ob es Updates für Alpine Linux gibt, dann mein Image ggf. neu bauen und auf allen Hosts dieses neue Image downloaden, um dann meine PeerVPN-Container neu zu starten.

Mein eigenes PeerVPN-Image auf DockerHub kann ich automatisch neu bauen lassen, wenn das Basisimage (Alpine Linux Official) sich verändert. Doch wie kommt das aktuelle PeerVPN-Image auf meine Hosts? Auch hierfür gibt es eine Lösung: Watchtower

Das Tool wird selbst als Container auf den Hosts gestartet und überwacht alle aktiven Container. Ändert sich das Image, auf dem ein Container basiert, erkennt Watchtower das, lädt das neue Image herunter und startet die entsprechenden Container neu.

Neben meinen PeerVPN-Containern habe ich auf jedem der Hosts also auch einen Watchtower-Container gestartet. Der nützt mir nicht nur im Zusammenhang mit PeerVPN, sondern generell bei allen Docker-Containeranwendungen. Der zusätzliche Aufwand fiel für mich daher nicht so sehr ins Gewicht.

version: '3'
services:
watchtower:
image: v2tec/watchtower
container_name: "watchtower"
restart: "always"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
command: "--interval 300 --cleanup"

Watchtower starten:

docker-compose up -d

Wer nur einzelne Container auf Updates überwachen lassen will, kann den “command” Parameter z.B. wie folgt erweitern:

command: "--interval 300 --cleanup meincontainer1 meincontainer2 meincontainer3"

(Übrigens: Watchtower aktualisiert nicht nur andere Container, sondern konsequenterweise auch sich selbst)

Fazit

Meine Hosts sind nun allesamt miteinander sicher vernetzt. Monitoring-Tools und andere verteilte Anwendungen können nun miteinander verknüpft werden, als wären sie in einem gemeinsamen, lokalen Netz. Das nimmt einem nicht nur Arbeit bei der Konfiguration ab, sondern sorgt auch für eine striktere Trennung zwischen Administrator-Diensten und öffentlichen Diensten.

Durch die Kapselung der VPN-Software in einem Docker-Container und die automatischen Updates via Watchtower muss ich mir keine Gedanken mehr um Updates und Kompatibilität mit dem Hostsystem machen. Neue Hosts sind zudem schnell in das bestehende Netz integriert.

Wer ein solches Wartungsnetz auch für seine Infrastruktur nutzen will, kann gerne auf mein Docker-Image und die oben genannten Docker-Compose-Files zurückgreifen.

Übrigens: Die 10.8.1.x-Adressen der Hosts habe ich im DNS verfügbar gemacht. So könnte z.B. 10.8.1.1 auf meinhost.srvnet.domain.tld gemappt sein. Das erleichtert den Umgang mit den IP-Adressen

Mozilla hat zwei neue Einstellungen in Firefox 57 implementiert, welche dem Nutzer die Möglichkeit zur Konfiguration geben, wie Lesezeichen in Firefox geöffnet werden sollen.

Standardmäßig öffnet Firefox Lesezeichen im aktiven Tab. Für Nutzer, welche ihren aktiven Tab nie überschreiben wollen, kann dies lästig sein. Firefox 57 wird zwei neue Einstellungen in about:config besitzen, um das Verhalten zu ändern.

Standardmäßig ändert sich nichts, Firefox wird Lesezeichen weiterhin wie gewohnt im gerade aktiven Tab öffnen. Sobald über about:config der Schalter browser.tabs.loadBookmarksInTabs per Doppelklick auf true gesetzt wird, öffnet Firefox Lesezeichen in einem neuen Tab und fokussiert den gerade geöffneten Tab. Wird zusätzlich noch der Schalter browser.tabs.loadBookmarksInBackground per Doppelklick auf true gesetzt, dann öffnet Firefox die Lesezeichen ebenfalls in einem neuen Tab, allerdings im Hintergrund, so dass dass das Lesezeichen zwar geöffnet, der aktive Tab aber im Vordergrund bleibt.

Nutzer von Firefox 55 können eine Änderung des Standard-Verhaltens bereits jetzt zum Beispiel über die Erweiterung Open Bookmarks in New Tab erreichen. Ab Firefox 57 wird dafür keine Erweiterung mehr notwendig sein. Nach derzeitiger Planung erscheint Firefox 57 am 14. November.

Der Beitrag Firefox 57: Lesezeichen in einem neuen Tab öffnen erschien zuerst auf soeren-hentzschel.at.