GnuPG Schlüssel exportieren

Wie man den privaten und den öffentlichen GnuPG Schlüssel auf einem neuen System einspielt, hatte ich im Artikel „GnuPG Schlüssel umziehen“ beschrieben. Hat man jedoch keine Sicherungen der Keys mehr zur Hand, so kann man die entsprechenden Schlüssel von einem bestehenden System via Terminal leicht mit folgenden Befehlen exportieren.

Dies hat den Vorteil, dass Änderungen am geheimen Schlüssel übernommen werden.

Beispiel: Ich hatte, als ich mein Schlüsselpaar erzeugt hatte, anfangs eine unsichere Passphrase (Passwort) vergeben. Dann wurde einige Zeit später das damalige Backup des geheimen Schlüssels von mir auf einem anderen Rechner eingespielt. In der Zwischenzeit hatte ich aber das Kennwort geändert. Die Passphrase auf dem anderen System stimmte so nicht mehr mit dem aktuellen Key überein. Da ich mich aber noch an das alte Passwort, dank KeepassX, erinnern konnte, war es kein Problem den Schlüssel zu verwenden.

Aus diesem Grund ist es besser die aktuellen Schlüssel wie hier beschrieben zu exportieren, um nicht mit Passwörtern und anderen Änderungen Probleme zu bekommen.

Eine weitere Möglichkeit wäre, das komplette Verzeichnis ~/.gnupg zu sichern.

Prosody Admin Web

Das Neuaufsetzen von Prosody auf einen Server mit Debian 9 lief bei mir mal wieder nicht ganz ohne Probleme. So hatte ich erst am Wochenende festgestellt, dass es nicht möglich war einzelne Usern zu löschen. Die letzten Spam-User-Registrierungen, wollte ich aber schnell wieder los werden. Der Lösch-Befehl

brachte in /var/log/prosody/prosody.err eine Fehlermeldung mit dem Hinweis auf ein Upgrade der neuen Datenbank. Dies war notwendig, da Prosody zuvor auf MySQL lief. Debian 9 hingegen nutzt MariaDB. Dieser Fehler konnte nun recht einfach mit

behoben werden.

Nun fiel mir aber noch ein weiteres Problem ins Auge. Seit einiger Zeit nutze ich das Modul mod_admin_web. Auch hier konnte ich mich nicht mehr im Webinterface einwählen.

Prosody – Admin Web

Die Ursache bestand darin, dass ich das Modul wie in der offiziellen Beschreibung

zwar in die prosody.cfg.lua eingebunden hatte, jedoch die Installation im Nachgang nicht ausgeführt hatte.

Da meine Community-Module in /usr/lib/prosody/prosody-modules liegen, sah die Lösung dann wie folgt aus:

Der Systemstatus sah danach nun wieder unauffällig aus:

Mail Relay für Mailcow Dockerized

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

Was kann man tun?

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

Wie löst man das Problem zufriedenstellend?

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

Dazu habe ich Postfix installiert.

Postfix, Debian
Postfix Konfiguration

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

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

Vorsicht: Nicht die Domain eingeben!

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

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

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

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

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

GnuPG Schlüssel umziehen

Den geheimen sowie den öffentlichen GnuPG Schlüssel hatte ich damals gut in meinen persönlichen Daten gesichert. Diese Sicherungen konnte ich nun auf einem weiteren Rechner wie folgt einspielen:

Hierzu musste ich nun noch meinem geheimen Schlüssel auf dem neuen System vertrauen.

Dazu wurde Option „5 = Ich vertraue ihm absolut“ gewählt und mit 

bestätigt. Um nun mit Evolution verschlüsselte Nachrichten senden zu können, wurden folgende Einstellungen gewählt.

Evolution,Debian
Evolution

Ich versende nun als Standard signierte eMails. Bei Bedarf kann ich diese verschlüsseln. Hierzu füge ich die entsprechenden Adressen via Seahorse hinzu, mit denen ich chiffriert über GnuPG eMails austauschen möchte.

Seahorse, Debian
Seahorse

Reverse Proxy für Mailcow-Dockerized

Mit dem Aufsetzen eines neuen Servers auf Basis von Debian 9 kamen wieder einige neue Dinge auf mich zu. Da ich mich für die Mailserver-Groupware Mailcow-Dockerized von André Peters entschieden hatte, musste ich mich erstmals mit einem Reverse Proxy auseinander setzten.

Wozu brauche ich einen Reverse Proxy?

Auf dem neuen Server sollte neben dem Webserver ein Mailserver installiert werden. Da Mailcow-Dockerized eine Container-Lösung ist und in diesem Container neben Postfix, Dovecot und Co. auch der Webserver Nginx läuft, würden aber die Ports 443 und 80 mit dem zuvor installierten Apache, auf dem eine Test-Webseite aktiv ist, kollidieren. 

Mailcow, Servercow
Mailcow UI

Um Mailcow zu installieren, musste zuerst der Apache gestoppt werden. Der Mailserver wurde dann in ein paar Minuten aufgesetzt und eingerichtet. Das Mailcow UI konnte wie gewünscht via HTTP und HTTPS erreicht werden. Im Anschluss wurde die Konfiguration nochmals geöffnet, um die Bindung an die Ports 80 und 443 entsprechend in 8080 und 8443 in der /root/mailcow.dockerized/mailcow.conf zu ändern. 

Natürlich hätte man das auch während der Installation durchführen können, jedoch wollte ich zuvor die testen, ob der Mailserver ordnungsgemäß läuft.

Nach dem nochmaligen Durchlauf der Konfigurationsänderungen, konnte nun das Mailcow UI natürlich von außen nicht mehr aufgerufen werden.

Nun wurde der Apache wieder gestartet und die Test-Websites ging wieder online.

Erstellen eines neuen Virtual Host

Um nun auch den Nginx in Mailcow-Dockerized zu erreichen, musste ein Reverse Proxy eingerichtet werden. Dazu habe ich einen Virtual Host, welcher auf Port 80 und Port 443 lauscht, in einer neu erstellten /etc/apache2/sites-available/proxy.conf mit folgendem Inhalt eingerichtet. Dieser leitet die Anfragen von mail.domain.tld an den Nginx im Container weiter. Das hatte zur Folge, dass die alten Zertifikate aus Mailcow-Dockerized unbrauchbar wurden. Ich habe darauf hin mein bestehendes Zertifikat um die Subdomain https://mail.domain.tld erweitert. Der Ort, wo die Zertifikate hinterlegt sind, musste im Codeblock (siehe unten) noch eingetragen werden.

Nach einem erneuten Neustart des Apache2 lief alles wie gewünscht, sowohl die Test-Webseite, als auch das Mailcow UI.

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

TUXEDO InfinityBook Pro 13 – Teil 6

Zuletzt wurde im Artikel „TUXEDO InfinityBook Pro 13 – Teil 5“ das von TUXEDO angepasste Xubuntu auf dem TUXEDO InfinityBook Pro 13 etwas näher beleuchtet. Einige Schwächen konnten, am sonst durchaus überzeugenden Betriebssystem, aufgezeigt werden. 

Nun habe ich mir im Vergleich zu Xubuntu Debian Testing mit Xfce auf dem Pro 13 angesehen.

Wie schlägt sich Debian Testing Xfce auf dem InifityBook?

Um alle Funktionstasten auf dem InfinityBook ansprechen zu können, habe ich den Grub 2 etwas angepasst. Hierzu wurden die Einstellungen analog der tuxedoeigenen Xubuntu-Version verwendet. Der Eintrag in /etc/default/grub wurde von

in

geändert. Zu beachten hierbei ist, dass im Nachgang  

ausgeführt werden muss. Nach einem Neustart kann man dann u.a. auch den Flugmodus über die entsprechende Funktionstaste einschalten. Diese Funktion ist ohne die erwähnte Anpassung nicht über die Taste F11 möglich.

Debian Xfce sieht nach der Installation etwas altbacken und nicht ganz so schick aus wie ein Xubuntu. Der Xfce-Desktop kann aber nach Belieben angepasst werden. Der zum Artikel verwendete Desktop-Hintergrund stammt von WalOps.com.

Debian startet in der oben erwähnten Konfiguration in ca. 22 Sekunden. Die Akkulaufzeit konnte ich mit minimaler Helligkeit, abgeschalteter Tastaturbeleuchtung und angeschlossener Funkmaus auf bis zu 8h heraus zögern. Im Standby-Test hielt der Akku knapp 12h durch. Wird am Gerät durch Zuklappen des Deckels der Bildschirm abgedunkelt, so ist dieser nach dem Aufklappen erwartungsgemäß mit voreingestellter Helligkeit wieder aktiv. Wird das Gerät allerdings in den Bereitschaftsmodus versetzt, so ist die Tastaturbeleuchtung nach dem Aufwachen wieder eingeschaltet und das Display des InfinityBook Pro 13 arbeitet mit mittlerer Helligkeit weiter. So entsteht nicht wie bei Xubuntu der Eindruck, als wäre es im Bereitschaftsmodus zu einem Systemabsturz gekommen.

Debian, Tuxedo; InfinityBook, Xfce
angepasster Desktop – Debian Testing Xfce

Zur Installation kam Testing noch mit dem Kernel 4.12, der dann über die Paketverwaltung kürzlich durch Version 4.13 ersetzt wurde. Hier traten dann allerdings wieder massive Bluetooth-Probleme auf. 

Debian, Tuxedo; InfinityBook, Xfce
Debian Testing noch mit Kernel 4.12

Die Temperatur der CPU liegt im Normalbetrieb bei 44°C. Der Lüfter ist dabei nicht zu hören, was ein geräuschloses Arbeiten möglich macht. Da das InfinityBook nun schon über ein halbes Jahr mit den unterschiedlichsten Betriebssystemen im Einsatz war, werde ich in Zukunft auf Dauertests zur Akkulaufleistung verzichten. Die Erfahrung zeigt, dass bei normaler Nutzung von Standardanwendungen und dem Einsatz eines aktuellen Kernels Laufzeiten von bis zu 7-8h durchaus möglich sind.

Fazit

Alles in Allem hat man mit Debian Testing Xfce ein gutes System auf dem InfinityBook Pro 13. Mit ein paar Handgriffen lassen sich alle Funktionstasten ansteuern. Bei der Wahl des Kernels sollte man jedoch aufpassen. Nicht automatisch bringt eine neuere Version nur Vorteile auf das Notebook. Da Debian Testing bis zum Freeze noch neuere Kernel einpflegt, besteht hier allerdings Hoffnung, dass die Bluetooth-Probleme wieder beseitigt werden.

Was mich generell an Xfce auf diesem Gerät etwas stört, ist die Darstellung. Alles wirkt sehr klein, sodass man sehr nah am Gerät arbeiten muss.

Vorschau

In den nächsten Artikeln werde ich berichten, wie sich das TUXEDO InfinityBook Pro 13 im ganz normalen Alltag schlägt.

Und immer wieder Servercow

Mein Umstieg auf Debian 9

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

vServer, Servercow
Übersicht der laufenden Prozesse mit htop

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

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

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

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

Fazit

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

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

Uberspace 7 – Public Beta

Der erste Eindruck

Shell, SSH, Uberspace
Übersicht der laufenden Prozesse mit htop

Uberspace, der nerdige Hoster von Jonas Pasche aus Mainz, hat nun erstmals Uberspace 7 (U7) der Allgemeinheit vorgestellt. Nach einem Test der Closed Beta mit 50 Usern, ging nun die Public Beta an den Start. Zeit sich das Ganze mal etwas näher anzusehen. Da ich selbst eine ganze Weile meine Seite auf Uberspace betrieben habe, war die Einrichtung nicht ganz so schwer. Die neue Doku unter https://manual.uberspace.de soll dem U7-Neuling beim ersten Umgang etwas unter die Arme greifen. Leider ist die Dokumentation noch sehr übersichtlich gehalten und auch nur in englischer Sprache verfügbar. Trotz alledem sind die notwendigsten Schritte zum Aufsetzen einer eigenen Webseite auf Uberspace 7 recht gut erklärt. Anfänger, denen der Umgang mit der Shell nicht so vertraut ist, werden es jedoch auch mit U7 weiterhin recht schwer haben. Da Uberspace aus meiner Sicht hauptsächlich durch Mund-zu-Mund-Propaganda wächst, steht hier aber meist ein erfahrener Uberspace-User helfend zu Seite.

Kurz und knapp gesagt bzw. geschrieben, ist es kein Hexenwerk eine Domain aufzuschalten und eine Webseite bzw. eine eMail-Adresse in der Public Beta einzurichten. Noch fehlen zwar einige Dinge, wie Spamfilter, Webmail, phpMyAdmin, Adminer oder die Möglichkeit virtuelle Mailuser anzulegen. Dafür muss man sich aber in Zukunft keine Gedanken mehr um SSL-Zertifikate und deren Verlängerung auf dem neuen Uberspace machen. Let’s Encrypt ist Standard. Weiterhin wird von Haus aus von HTTP auf HTTPS umgeleitet. Als Datenbank­-Verwaltungs­-System wird nun MariaDB, welches kompatibel zu MySQL ist, verwendet.

Wo bekommt man das alles?

Hierzu verweise ich erst einmal auf den Blog, der über alle News rund um Uberpace informiert. https://blog.uberspace.de

Zur Registrierung eines U7-Account geht’s hier: https://uberspace.de/register?u7=1

Fazit

Mit ein wenig Bastelei konnte ich in kürzester Zeit eine Testseite sowie eine eMail-Adresse im neuen Uberspace 7 migrieren. Das Aufschalten der für den Test verwendeten Domain lief ebenfalls völlig unspektakulär. Zwar fehlen noch einige Features im neuen System, dennoch öffnet Uberspace mit der U7 Public Beta eine neue Tür.

Der Preis zum Hosting, kann nach wie vor selbst bestimmt werden. Man bekommt einen kompetenten Hoster mit super Support zu einem fairen Preis.

TUXEDO InfinityBook Pro 13 – Teil 5

Vor einigen Wochen ging die Nachricht durch die Community, dass TUXEDO eine eigene Distribution veröffentlicht.

Was ist da nun genau dran?

Hierzu TUXEDO im eigenen Blog:

Nein, eine eigene Distribution haben wir nicht aus der Taufe gehoben. Das würde auch gar keinen Sinn ergeben – denn auf den nächsten Fork von Ubuntu oder ähnliches hat sicher niemand gewartet!

Was wir aber gemacht haben, ist ein stark an die Bedürfnisse unserer User angepasster Desktop. Mit eigenem Theme, eigenen Icons, eigenem Boot-Logo und und und. Natürlich haben wir hier auch direkt die neueste Firmware, die neuesten NVIDIA-Treiber (falls notwendig) und bereits Kernel 4.11 vorinstalliert! Von unseren Konfigurationsanpassungen am GRUB und Optimierungen an anderen systemrelevanten Dateien ganz zu schweigen.
Durch diese Anpassungen und die neuesten Treiber & Kernel kommen wir auf deutlich gesteigerte Leistungswerte und Akkulaufzeiten unserer Geräte gegenüber einer Standardinstallation. Diese Auswirkungen sollte man nicht unterschätzen!

Das wollte ich mir jetzt einmal etwas genauer auf dem TUXEDO InfinityBook Pro 13 ansehen. Dazu habe ich mich des tuxedoeigenen Tools WebFAI bedient, welches es ermöglicht die optimierte TUXEDO-Version von Xubuntu für das InfinityBook aus dem Netz zu installieren.

WebFAI – Auswahl der installierbaren Betriebssysteme

Wie kommt das modifizierte Xubuntu nun auf das InfinityBook Pro 13?

Dazu verbindet man das Notebook via LAN mit dem Internet und steckt einen FAT32-formatierten USB-Stick mit den WebFAI-Daten in das Gerät. Das Pro 13 wird gestartet und die Einstellungen dahingehend geändert, dass das InfinityBook vom Stick bootet. Wie auf der Abbildung zu sehen ist, kann nun das zu installierende Betriebssystem ausgewählt werden. In diesem Fall Xubuntu 16.04 LTS. Neben Xubuntu stehen übrigens noch weitere Distributionen wie Ubuntu Cinnamon, Ubuntu, Ubuntu Mate, Kubuntu oder elementary OS zur Auswahl bereit. Die entsprechenden Daten zieht sich dann das Notebook aus dem Netz und installiert die angepasste Xubuntu-Version.

Xubuntu Desktop mit aufgeklapptem Menü
Xubuntu mit Kernel 4.11

Bevor jedoch Xubuntu auf dem Testgerät installiert wurde, habe ich die BIOS und EC Firmware noch auf den neuesten Stand gebracht.

Firmwareupdate

Xubuntu kam zum Zeitpunkt der Installation mit dem Kernel 4.11. Inzwischen wurde jedoch die Version 4.12 über die Paketquellen eingespielt. 

Wie läuft die modifizierte Version?

Das InfinityBook startet in knapp 28 Sekunden. Das ist nicht so flott wie unter Ubuntu oder Debian. Die Akkulaufzeit konnte mit deaktivierter Tastaturbeleuchtung, abgeschaltetem Bluetooth und minimaler Displayhelligkeit bei normaler Anwendung (Internet, Text- und Grafikbearbeitung) auf immerhin 8:00h gesteigert werden. Im üblichen Standby-Test schafft das Pro 13 ca. 14:00h. Das TUXEDO-Xubuntu sieht sehr angenehm aus, lässt sich gut bedienen und ist nicht so ressourcenhungrig wie ihre größeren Brüder. Das Betriebssystem ist schick, arbeitet gut und ohne größere Probleme. Im Normalbetrieb lief der Intel Core i7-7500U mit 44°C. Die Temperaturen lagen so ca. 2°C unter denen von Ubuntu und Debian.

Negativ fielen allerdings zwei Dinge auf. Zum Einen hatte ich Probleme mit meiner zwischenzeitlich angeschlossenen Bluetooth-Maus. Diese fängt plötzlich an zu hängen und streikt. Nach ein paar Sekunden war sie aber immer wieder einsatzbereit. So konnte ich mit diesem Eingabegerät nicht wirklich arbeiten. Unter den zuvor auf diesem Gerät getesteten Systemen Ubuntu, Debian und Windows gab es hingegen keine Schwierigkeiten mit dem selbigen Modell. Die Bluetooth-Maus wurde gegen eine Funkmaus ausgetauscht, welche problemlos arbeitete. Ein zweites Problem tat sich auf, als sich das InfinityBook in den Bereitschaftszustand versetzt hat. Das Gerät ließ sich zwar aufwecken, jedoch blieb dann der Bildschirm dunkel. Erst wenn man über die Funktionstasten die Helligkeit um eine Stufe erhöht, lässt sich das Bild zurück bringen, um mit dem Gerät weiter arbeiten zu können. Diese Problem gab es allerdings nur mit einem auf niedrigster Helligkeitsstufe angesteuertem Display (siehe Bild).

Xubuntu 16.04 auf niedrigster Helligkeitsstufe

Fazit

Das von TUXEDO modifizierte Xubuntu ist für das InfinityBook Pro 13 optimiert. Mit dieser Version kann die Akkulaufleistung noch einmal deutlich gesteigert werden. Das OS tut ansonsten genau das was der Anwender erwartet. Probleme gibt es allerdings beim Aufwecken aus dem Bereitschaftszustand, wenn das Display mit minimaler Helligkeit angesteuert wird. Der Bildschirm bleibt nach dem Aufwecken schwarz. Des Weiteren können Bluetooth-Verbindungen abreißen. Hier ist etwas Handarbeit am System notwendig.

Xubuntu auf dem InfinityBook Pro 13 ist sicher Geschmacksache. Ein Ubuntu, Debian oder sogar Windows laufen auf dem Gerät aus meiner Sicht deutlich stabiler. In Puncto Mobilität ist aber die von TUXEDO angepasste Version kaum zu schlagen.

Vorschau

Im nächsten Artikel werde ich berichten, wie sich das TUXEDO InfinityBook Pro 13 mit Debian Testing Xfce schlägt. 

Nextcloud-Client – Quelle kaputt

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.

Terminalausgabe

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

Nun wird die Zeile

durch

ersetzt und die neue Quelle mit

verifiziert.

Viel Spaß!