In vim mit root-Rechten speichern

Ist euch das nicht auch schon passiert, dass ich mit vim eine Datei editiert habt und dann beim Speichern bemerkt, dass ihr keine Schreibrechte auf die Datei habt?

Jochen Lillich hat in seinem Blog einen Tipp, wie ihr die Datei mit root-Rechten speichern könnt:

:w !sudo tee %

Dieser Befehl speichert die Datei, danach könnt ihr sie mit :q! verlassen und die Warnungen ignorieren, die Änderungen sind dennoch gespeichert.

Alles weitere zur Funktionsweise des Befehls erfahrt ihr in Jochens Blogpost.

Terminal-Ausgabe in die Zwischenablage umleiten

Ich bewege mich ja viel und oft im Linux-Terminal, um verschiedene Aufgaben zu erledigen. Manchmal ist es ganz nützlich, wenn man die Ausgabe des Terminals über die Zwischenablage in anderen Programmen weiter verwenden kann. Zwar hat man immer die Möglichkeit, die Ausgabe zu kopieren und mit den gängigen Methoden (Strg-C oder über Menübefehle der Konsolen-Anwendung) in die Zwischenablage zu befördern, allerdings ist das nicht immer praktikabel. Wenn zum Beispiel die Ausgabe so umfangreich ist, dass sie den Inhalt einer Bildschirmseite überschreitet, wird das Markieren ziemlich mühsam.

Abhilfe schafft hier das kleine Tool xclip, das ihr auf den meisten Distributionen über den jeweiligen Paketmanager installieren könnt. Danach habt ihr die Möglichkeit, die Ausgabe im Terminal auf xclip umzuleiten.

So leitet

ls | xclip -sel clip

die Ausgabe des ls-Befehls direkt in die Zwischenablage und ihr könnt das systemweit in jeder Anwendung wieder einfügen. xclip kann noch ein paar Dinge mehr, hierzu empfehle ich die Manpage.

Iptables Firewall - Wann beim Portforwarding ein DNAT nicht genug ist

Betreibt man Firewalls auf einem Linux-Router mit iptables, kommt man früher oder später in die Verlegenheit, Portforwarding machen zu müssen. Schaut man dann einschlägige Anleitungen im Internet an, findet man solche, die das allein über ein DNAT (Destination Natt ing) in der Prerouting-Chain lösen, manche wiederum sagen, dass man unbedingt auch ein SNAT (Source Natting) in der Postrouting-Chain machen muss, sonst würde das überhaupt nicht funktionieren.

Ich hatte das Problem letztens und möchte das hier mal etwas aufdröseln, damit ich beim nächsten mal nicht wieder Schaubildchen malen muss. Vielleicht hilft es ja auch dem ein oder anderen von euch, wenn ihr mal einen ähnlichen Routing-Fall lösen müsst.

Ich gehe in diesem Artikel nicht auf die Grundlagen des Routings und Firewallings ein, sondern möchte nur den oben erwähnten speziellen Fall genauer beschreiben.

Zunächst schauen wir uns grob an, wie so ein IP-Paket die einzelnen Chains (Ketten) unserer Firewall durchläuft.

Schematische Darstellung der Routing-Chains

Wie man sieht, haben wir zwei NAT-Chains (Network Adress Translation), nämlich die Prerouting- und die Postrouting-Chain. Jedes IP-Paket enthält unter anderem eine Absender-IP und eine Empfänger-IP. In diesen beiden Ketten kann iptables diese beiden Adressen umschreiben, nämlich die Empfänger-Adresse im Prerouting und die Absender-Adresse im Postrouting. Das besondere ist, dass diese Adressen, sobald die Antwort auf so ein verändertes Paket wieder bei unserem Router ankommen, auch wieder zurück übersetzt werden können.

Unsere Router zu Hause machen das übrigens ständig, wenn wir im Internet surfen. Bei allen Paketen wird die private IP-Adresse aus unserem Heimnetz in die öffentliche IP-Adresse ausgetauscht, die wir von unserem Provider erhalten haben. Kommt eine Anwort zurück, tauscht der Router die Adresse wieder zurück und sendet die Internetinhalte an das Gerät in unserm LAN, das sie auch angefordert hat.

Diese spezielle Form des SNAT in der Postrouting-Chain nennt man auch Masquerading.

Doch nun zu einem etwas komplexeren Setting, bei dem wir spezielle Adressumschreibungen benötigen, die über ein pauschales Masquerading hinaus gehen.

Wir haben als Beispiel eine Firewall mit drei Netzwerkkarten, eine (eth0) zeigt ins Internet mit einer öffentlichen IP-Adresse 1.2.3.4, eine Karte (eth2) zeigt in unser internes Firmennetz und hat die IP 192.168.1.1/24. Die dritte Karte (eth1) mit der IP 192.168.10.1/24 zeigt auf ein Netzwerk, in dem zwei Webservices laufen, die aus dem Internet erreichbar sein sollen.

Alle Pakete aus dem Internet, die auf für die IP-Ports 80 und 443 ankommen, sollen auf einen Reverse-Proxy weitergeleitet werden, der dann den Verkehr weiter an die zuständigen Rechner für die jeweiligen Services verteilt.

Das ganze schaut schematisch so aus:

Schematische Darstellung des Beispiel-Netzwerks

Die beiden Adressen “service_a.example.com” und “service_b.example.com” werden vom DNS auf die IP-Adresse 1.2.3.4 geleitet. Also müssen unsere Firewall anweisen, alle Pakete, die auf der IP-Adresse 1.2.3.4 auf Port 80 und 443 ankommen, an unseren Reverse-Proxy zu forwarden.

Dazu müssen wir zunächst das Forwarding für diese Ports in der FORWARD-Chain erlauben:

iptables -A FORWARD -i eth0 -o eth1 -p TCP --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p TCP --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Dann kommt das eigentliche Portforwarding, also das Umschreiben der Empfängeradresse im Paket.

iptables -t nat -A PREROUTING -d 1.2.3.4 -p TCP --dport 80 -j DNAT --to-destination 192.168.10.10:80

iptables -t nat -A PREROUTING -d 1.2.3.4 -p TCP --dport 443 -j DNAT --to-destination 192.168.10.10:443

Das funktioniert zunächst für alle Pakete, die aus dem Internet (hier als Beispiel von der IP-Adresse 3.4.5.6) kommen. Die Empfänger-Adresse wird auf den Proxy umgeschrieben:

Source          Dest
3.4.5.6         1.2.3.4  -> DNAT -> 192.168.10.10

und auf dem Rückweg:

Source          Dest
3.4.5.6         1.2.3.4  <- DNAT <- 192.168.10.10

Der Absender 3.4.5.6 erhält also als Antwort auf sein Paket, dass mit der Empfängeradresse 1.2.3.4 abgesendet wurde.

Das gleiche funktioniert auch, wenn ein Rechner aus dem internen Netz ein Paket an einen unserer beiden Services sendet. Der Router sorgt auch hier wieder für den Aus- und Zurücktausch der Empfänger-Adresse des Pakets.

Jetzt kommen wir aber zu einem Fall, in dem das so nicht funktioniert. Nehmen wir einmal an, der Rechner “service_a.example.com” muss ein IP-Verbindung zu “service_b.example.com” herstellen. Da “service_b.example.com” auch im internen Netz mit der IP 1.2.3.4 übersetzt wird, geht unser IP-Paket also an unseren Router, der auch wieder brav die Empfängeradresse austauscht.

Source          Dest
192.168.10.50   1.2.3.4  -> DNAT to 192.168.10.10

Das Paket geht zunächst ordnungsgemäß an unseren Reverse-Proxy, der an 192.168.10.60 (service_b) vermittelt. Nun soll der Proxy eine Antwort an den Absender schicken und hat folgendes IP-Paket vorliegen:

Source          Dest
192.168.10.50   192.168.10.10

Ah, das Paket kommt von einer IP aus dem eigenen Netz, die ganz ohne Routing direkt erreicht werden kann, also wird die Antwort direkt an 192.168.10.50 gesendet.

Dieser Rechner kann aber mit der Antwort nichts anfangen, denn er hat nie ein Paket an die IP 192.168.10.10 gesendet, sondern an 1.2.3.4.

Also wird die Antwort verworfen, die IP-Verbindung kommt in diesem Fall nicht zustande. Hier haben wir den Fall, in dem ein DNAT für das Portforwarding nicht ausreicht.

Um dafür zu sorgen, dass die Antwort den gleichen Weg nimmt wie das Ursprungspaket auf dem Weg zum Reverse-Proxy und damit der Router die Daten des Pakets wieder auf den ursprünglichen Wert zurücksetzt, müssen wir in der Postrouting-Chain die Absender-Adresse des Pakets auf die IP des Routers ändern:

iptables -t nat -I POSTROUTING -s 192.168.10.0/24 -d 192.168.10.10 -p tcp --dport 80 -j SNAT --to-source 192.168.10.1

iptables -t nat -I POSTROUTING -s 192.168.10.0/24 -d 192.168.10.10 -p tcp --dport 443 -j SNAT --to-source 192.168.10.1

Zusätzlich benötigen wir an dieser Stelle eine Forwarding-Regel, die das Forwarding auch von eth1 zu eth1 erlaubt:

iptables -A FORWARD -i eth1 -o eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Dadurch stellen wir sicher, dass das Paket bei Beantwortung zunächst wieder an den Router geschickt wird, der dann die IP-Adressen wieder auf die alten Werte korrigiert.

Als Regel kann man festhalten, dass wir immer dann eine SNAT-Regel für das Portforwarding benötigen, wenn durch das umschreiben der Empfänger-Adresse (DNAT) das IP-Paket so geändert wird, dass sich der Routing-Pfad auf dem Rückweg so ändert dass der Router, der das Natting durchgeführt hat, nicht mehr beteiligt ist. Dann ist es notwendig, auch die Absenderadresse so zu manipulieren, dass das Paket den gleichen Weg zurück nimmt und am NAT-Router wieder umgeschrieben wird.

Telefonieren unter Linux mit Linphone und der Fritzbox

In Zeiten der IP-Telefonie ist es praktisch, dass man auch mit einem entsprechenden Client direkt ohne ein zusätzliches Telefon direkt vom Rechner telefonieren kann. Auch unter Linux gibt es die sogenannten SIP-Clients, mit denen man über einen SIP-Provider telefonieren kann.

Wenn ihr zu Hause einen Router habt, der auch IP-Telefonie beherrscht, könnt ihr diesen oftmals auch als SIP-Provider nutzen. Ich habe mal aufgeschrieben, wie das mit einer Fritzbox 7590 und dem Programm Linphone unter Linux funktioniert.

Telefonie-Gerät auf der Fritzbox einrichten

Als erstes muss ein neues Telefoniegerät auf der Fritzbox eingerichtet werden. Im Menü der Fritzbox (in meinem Fall eine 7590) geht ihr auf den Punkt "Telefonie"-"Telefoniegeräte" und wählt die Schaltfläche "Neues Gerät einrichten".

In der nächsten Maske "Telefon" auswählen und auf "Weiter" klicken.

In der nächsten Maske müssen wir der Fritzbox sagen, dass es sich um ein IP-Telefon handelt. Außerdem könnt ihr einen Namen für das Gerät vergeben.

Nun geben wir einen Benutzernamen und ein Kennwort ein. Diese Daten müssen wir uns merken, um später den Client einrichten zur können.

Wenn ihr über euren Internetprovider mehrere Rufnummern zur Verfügung gestellt bekommt, könnt ihr nun auswählen, mit welcher Rufnummer euer Client später raustelefonieren soll.

Ebenso könnt ihr festlegen, ob euer Client bei allen ankommenden Rufnummern klingeln soll oder nur bei bestimmten. Das ist zum Beispiel bei Homeoffice praktisch.

Die nächste Maske zeigt nochmal alle Einstellungen an und mit "Übernehmen" wird die Anlage des Gerätes gestartet.

Zum Schluss möchte die Fritzbox noch, dass ihr euch autorisiert, dass kann entweder über eine Zahlenkombination erfolgen, die ihr an einem bereits an die Fritzbox angeschlossenen Telefon eingebt, oder über das Drücken einer Taste auf der Fritzbox selbst.

Die Vorbereitungen auf der Fritzbox sind nun abgeschlossen und wir können den Linphone-Client einrichten.

Linphone einrichten

Linphone ist in den gängigen Distributionen über die jeweiligen Installationswerkzeuge installierbar. Bei den verschiedenen Ubuntu-Derivaten auch bequem über die Befehlszeile mit:

sudo apt install linphone

Beim ersten Start begrüßt uns ein Einrichtungsassistent, den wir natürlich gern mit "Forward" starten.

In der nächsten Maske den Punkt "Ich habe bereits ein SIP-Konto und möchte es jetzt benutzen" wählen.

Jetzt kommen Benutzername und Kennwort aus der Fritzbox-Einrichtung zum Einsatz. Im Feld "Domäne" tragt ihr die IP-Adresse eurer Fritzbox ein. Mit Klick auf "Apply" wird das Konto eingerichtet.

Wenn alles richtig eingegeben wurde kann man jetzt über das eingerichtete Konto in Linphone bequem vom Linuxrechner telefonieren. Am besten verwendet man dazu natürlich ein entsprechendes Headset.

Debian 10 "Buster" veröffentlicht

Debian 10 Logo

Das Debian-Projekt hat nach zwei Jahren die neue stabile Version 10 der universellen Linux-Distribution veröffentlicht. Seit gestern kann das neue Stable-Release mit dem Codenamen "Buster" offiziell heruntergeladen werden.

Obwohl Debian meist gern auf Servern ohne grafische Benutzeroberfläche genutzt wird, bringt Buster mehrere Deskop-Umgebungen mit:

  • Cinnamon 3.8
  • GNOME 3.30
  • KDE Plasma 5.14
  • LXDE 0.99.2
  • LXQt 0.14
  • MATE 1.20
  • Xfce 4.12

Die GNOME-Umgebung verwendet im neuen Release erstmals des Wayland-Display-Server als Standard. Xorg ist aber weiterhin installiert und kann beim Login ausgewählt werden.

Das Zugangskontroll-Framework AppArmor ist installiert und eingeschaltet. Bei der Netzwerkfilterung stehen als Befehlsschnittstelle sowohl nftables als auch iptables zur Verfügung. Ein weiteres Sicherheitsfeature sind die Reproducable Builds. Hierdurch ergeben 91% der Quellpakete beim Selbstkompilieren identische Binärpakete.

Die UEFI-Unterstützung wurde verbessert und auch das treiberlose Drucken sollte nun problemlos funktionieren.

Zahlreiche Softwarepakete wurden aktualisiert, obwohl traditionell bei Debian aufgrund des Entwicklungsprozesses nicht die allerneuesten Pakete zum Einsatz kommen. Dafür erhält man eine sehr stabile und gut getestete Distribution.

Alle weitern Informationen, auch die Download- und Update-Möglichkeiten, könnt ihr im Release-Artikel des Debian-Projekts finden. Viel Spass beim Installieren und Updaten. :-)

Kubuntu Cosmic Cuttlefish (18.10) Beta erschienen

Bald ist es Oktober und somit steht das nächste Zwischenrelease für die beliebte Linux-Distribution Ubuntu und damit auch für die verschiedenen Desktop-Flavours an. Auch für das von mir bevorzugte Kubuntu, welches auf die Desktop-Umgebung KDE optimiert wurde, haben die Entwickler nun die erste Beta der Version 18.10 zur Verfügung gestellt.

Wie immer gibt es den Hinweis der Kubuntu-Community, dass die Beta-Version nicht für Nutzer gedacht ist, die ein stabiles System benötigen. Eine Beta kann immer Fehler und Probleme enthalten, darüber sollte man sich im klaren sein, wenn man eine solche Version installiert.

Ich nutze schon seit langem immer nur die LTS-Versionen von Kubuntu und habe auf meinem Rechnern vor kurzem die letzte LTS-Version 18.04 installiert. Dennoch habe ich mir das ISO heruntergeladen und in einer virtuellen Maschine installiert, um mir Kubuntu 18.10 einmal kurz anzusehen.

Sofware aufgefrischt

Kubuntu Screenshot 1Für diejenigen Nutzer, die bereits mit der 18.04 unterwegs sind, ändert sich außer dem angepassten Standardhintergrund-Bild nicht viel. Das dunkle Theme der letzten LTS-Version, das mir übrigens sehr gut gefällt, wurde übernommen. Die Plasma-Version wurde auf 5.13.5 aktualisiert. Die KDE-Applications  kommen in der Version 18.04.3 daher.

Der Standard-Webbrowser ist nach wie vor Mozillas Firefox. Nutzt man die Standardinstallation, die eine große Auswahl von Software-Paketen mitinstalliert, steht als Office-Suite LibreOffice 6.1.1 zur Verfügung, das jetzt erstmals QT5 für die Darstellung des Frontends nutzt.

Snaps standardmäßig aktiviert

Discover mit aktiviertem Snap-BackendSchon in 18.04 waren die Paketverwaltungs-Tools Snap und Flatpak im Programmverwaltungs-Tool "Discover" integriert, beide mussten aber zunächst in den Einstellungen aktiviert werden, um genutzt werden zu können. In der Beta sind nun Snaps standardmäßig aktiviert. Das kann bei unerfahrenen Benutzern allerdings zu Verwirrungen führen, wenn auf einmal scheinbar identische Programme mehrmals auftauchen.

Programmliste in DiscoverErst ein Klick auf die verschiedenen Einträge offenbart die Quelle des Programms, ob es also aus einem (Ubuntu) Repository oder aus einem Snap installiert wird. Hier wäre es sicher schöner, wenn man das gleich in der Übersicht erkennen könnte.

Programmquelle im Detail

Kurzes Zwischenspiel für Wayland

Der alternative Anzeige-Server Wayland hat in dieser Beta ein kurzes Zwischenspiel. Man kann diesen bei der Anmeldung am System als Alternative zum X-Server starten. Die Entwickler weisen allerdings ausdrücklich darauf hin, dass die Implementierung noch sehr instabil ist nur zu Testzwecken genutzt werden sollte. In der stabilen Version von Kubuntu 18.10 wird die Option standarmäßig nicht mehr zur Verfügung stehen.

Testen und Bugs melden

Das Ziel einer Beta-Version ist es immer, mögliche Fehler und Stabilitätsprobleme vor dem eigentlichen Release zu finden und noch vorher beheben zu können. Wer sich Kubuntu 18.10 also schonmal installiert (zum Beispiel gefahrlos in einer virtuellen Maschine) und solche Bugs findet, kann die im Bugtracker melden und so zur Qualität vom endgültigen Release beitragen. Happy Testing!

Kubuntu 16.04 - Grafikprobleme nach Kernelupdate im Juli 2018

Auf meinem stationären Rechner daheim verrichtet nun seit über zwei Jahren ein Kubuntu 16.04 LTS brav seinen Dienst und macht eigentlich kaum Probleme, auch nicht bei den Systemupdates, die regelmäßig erscheinen. Beim letzten Update im Juli 2018, bei dem auch der Kernel auf die Version 4.4.0-130 aktualisiert wurde, gab es auf meinem Rechner aber einige Grafikprobleme. So war zum Beispiel die Transparenz der Kontrollleiste nicht mehr wie vorher, die Farben des hellen Breeze-Themes waren deutlich dunkler und irgendwie "nicht mehr stimmig".

Problematischer war jedoch, dass im Firefox-Browser einige der Icons in der Iconleiste nicht mehr angeklickt werden konnten, zum Beispiel das "Menü"-Icon und auch das von uBlock Origin.

Firefox Iconleiste

Nach einigem Suchen im Netz scheint es sich um ein Problem des Compositors in Verbindung mit OpenGL zu handeln. Das sorgt wohl für die komischen Farben und für die Probleme mit Anwendungen, die GTK-Stilelemente nutzen und nicht die von KDE/Plasma (wie z.B. Firefox). Folgende Systemeinstellung hat das Problem bei mir zunächt einmal behoben.

In den Systemeinstellungen unter "Anzeige und Monitor" im Reiter "Compositor" habe ich das Ausgabemodul auf "XRender" umgestellt.

XRender-Einstellung

Danach waren die Icons im Firefox sofort wieder klickbar, die Farbprobleme der Kontrollleiste waren nach einem Neustart des Systems auch verschwunden. Negative Nebeneffekte durch diese Umstellung habe ich bisher nicht festgestellt. Ich werde das Problem mal weiter verfolgen und wenn ich weitere Informationen finde, diesen Artikel aktualisieren.

Kubuntu 17.10 beta1 steht zum Test zur Verfügung

Kubuntu Logo

Im Oktober wird die Version 17.10 von Ubuntu und seinen Derivaten - darunter auch die KDE-Variante Kubuntu - erscheinen. Für Neugierige steht nun bereits die beta1 von Kubuntu 17.10 zur Verfügung.

Wir immer sollte man diese Version nicht auf Systemen installieren, die man produktiv nutzt und dringend benötigt. Es bietet sich an, die Version in einer virtuellen Maschine, z.B. unter Virtualbox, auszuprobieren.

Wer es wirklich möchte, kann eine bestehende 17.04 mit dem Befehl "sudo do-release-upgrade -d" auf die 17.10 beta1 aktualisieren. Images für eine frische Installation findet ihr hier.

Die Release-Notes findet ihr wie immer im offiziellen Wiki. Viel Spaß beim Testen

KDE Connect unter Gnome nutzen mit MConnect

Vor kurzem hatte ich über KDE Connect geschrieben. Auf dem KDE Desktop lässt sich damit eine Verbindung zu einem Android Smartphone aufbauen und so zum Beispiel die Benachrichtigungen des Telefons auf dem Computer anzeigen.

Um die Erweiterung auch in einer Gnome-Umgebung komfortabel nutzen zu können, gibt es jetzt die Gnome-Erweiterung MConnect. In diesem Artikel von Pro-Linux erfahrt ihr weitere Einzelheiten.

Debian 9 "Stretch" veröffentlicht

Debian Logo

Nach 26 Monaten Entwicklungszeit hat das Debian-Projekt die neue Version 9 der freien Linux-Distribution freigegeben.

Neben aktualisierten Version der enthaltenen Softwarepakete hebt das Team besonders hervor, das als Standard MySQL-Variante nun MariaDB verwendet wird. Bestehende MySQL-Versionen werden beim Update auf MariaDB migriert. Außerdem werden der Browser Firefox und der Mailclient Thunderbird nun wieder mit ihren ursprünglichen Namen und nicht mehr als Iceweasel und Icedove ausgeliefert. Wie immer sind in einer neuen Debian-Version nicht die aktuellsten Versionen von Softwarepaketen enthalten, sondern solche, die das Projektteam für stabil genug hält. Einen guten Überblick über weitere Neuerungen bietet der Blogpost zur Freigabe von Stretch.

Support für ältere Debian-Versionen

Debian 9 wird durch das Debianprojekt und das LTS-Team für die nächsten fünf Jahre gepflegt. Und was geschieht mit den alten Debian-Versionen? Debian 6 "Squeeze" ist End-of-Life, erhält also keine Updates mehr und sollte daher nicht mehr genutzt werden. Debian 7 "Wheezy" erhält momentan vom LTS-Team noch Updates bis Mai 2018. Debian 8 "Jessie" wechselt zunächst traditionsgemäß für 12 Monate in den "OldStable"-Zweig und wird weiter gepflegt, danach ist die Übernahme der Pflege durch das LTS-Team geplant, so dass man "Jessie" noch bis April 2020 mit Sicherheitsupdates versorgen kann.