Der Xbox One Digital TV Tuner ist mit ~15€ der günstigste DVB-T2 & DVB-C USB-Stick, welcher auch unter Linux nutzbar ist. In diesem Beitrag zeige ich euch, wie ihr den benötigten Treiber unter CoreELEC...
Ich habe mir vor kurzem den „SONOFF Zigbee 3.0 USB Dongle Plus“ gekauft. Dieser wird standardmäßig mit der Z-Stack 3.x.0 Firmware Version „20210120“ ausgeliefert, die (Stand August 2024) aktuelle Z-Stack Firmware Version ist „20240710“....
Durch diesen Blogbeitrag auf LinuxNews bin ich auf das Tool trash-cli aufmerksam geworden. Installation: # Arch Linux sudo pacman -S trash-cli # Debian/Ubuntu sudo apt install trash-cli # Fedora sudo dnf install trash-cli Befehle:...
Pika Backup ist eine Anwendung für einfache Updates über „BorgBackup„. Der Name „Pika Backup“ hat nichts mit dem Pokémon „Pikachu“ zu tun. Auf GitLab steht hierzu folgendes: The name “Pika Backup” derives from the...
Ich besitze seit kurzem ein TUXEDO InfinityBook Pro 14 Gen6 mit 3K „Omnia“ Display. Dieses Display besitzt eine Auflösung von 2880 x 1800 Pixeln. Für HiDPI Displays können unter Gnome dank des „Fractional Scaling“...
Mit Firefox 89 führt Mozilla (mal wieder) ein neues Design ein, welches nicht allen Nutzern und Nutzerinnen gefällt. Es gibt aber bereits einen „Fix“ mit welchem einige Teile des neuen Designs deaktiviert werden können....
Andreas hat einen Nextcloud-Server auf Debian-Basis installiert und dabei seine Vorgehensweise dokumentiert. Diese basiert zum großen Teil, aber nicht ausschließlich auf meinem Homeserver-Tutorial zu Ubuntu 18.04 [Homeserver/NAS mit Ubuntu 18.04: Teil 1, Einleitung, Hardware und Kosten]. Jedoch mit einigen Abweichungen, da sich Debian und Ubuntu doch in einigen Details unterscheiden. Die Dokumentation seiner Vorgehensweise hat [...]
Gastbeitrag: Debian Server mit Nextcloud ist ein Beitrag von .
Mittlerweile ist Ubuntu 20.04 erschienen. Hierbei handelt es sich wieder um eine LTS-Version (long term support), die 5 Jahre mit Updates versorgt wird. Also bis April 2025. Damit wird Ubuntu 18.04 abgelöst, auf welchem die bisherige Homeserver-Anleitung basiert. Ubuntu 18.04 war ebenfalls eine LTS-Version und wird noch bis April 2023 mit Sicherheitsupdates versorgt. Wer also [...]
Übersicht: Ubuntu 20.04 Homeserver/NAS, Teil 1 ist ein Beitrag von .
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Zuerst wird das Betriebssystem Ubuntu Server 20.04 (Focal Fossa) installiert. Mit dieser Version wurde ein neues Installationsprogramm eingeführt, sodass sich die Installation von den Vorgängerversionen unterscheidet. Das Kapitel zur Partitionierung der Festplatten unterteilt sich in zwei Teile. Je nachdem ob man ein System mit internen [...]
Installation des Betriebssystems: Ubuntu 20.04 Homeserver/NAS, Teil 2 ist ein Beitrag von .
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS In den beiden vorherigen Teilen wurde die Hardware eingerichtet und das Betriebssystem installiert. Bevor es nun an das Installieren und Einrichten der eigentlichen Dienste geht, sollten noch ein paar Grundeinstellungen vorgenommen werden. Außerdem gilt es ein paar grundlegende Dinge bei der Administration zu beachten. Gleichbleibende [...]
Grundkonfiguration: Ubuntu 20.04 Homeserver/NAS, Teil 3 ist ein Beitrag von .
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Das Betriebssystem wurde in den letzten Teilen installiert und die wichtigsten Grundkonfigurationen vorgenommen. Nun können die ersten Dienste auf dem Homeserver installiert werden. In diesem Teil werden die Ordnerfreigaben für das lokale Heimnetz erstellt. Die Software, die hierfür verwendet wird, ist SAMBA-Server. Damit können über [...]
Ordnerfreigaben: Ubuntu 20.04 Homeserver/NAS, Teil 4 ist ein Beitrag von .
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Nextcloud hat sich mittlerweile zum Quasi-Standard für selbstgehostete Cloudanwendungen entwickelt. Nextcloud kann uneingeschränkt kostenlos genutzt werden. In Nextcloud können Kalender und Kontakte gespeichert und mit dem Smartphone synchronisiert werden. So kann man Dienste wie Google Calender komplett ersetzen. Außerdem gibt es einen Deskop-Client, mit welchem [...]
Nextcloud: Ubuntu 20.04 Homeserver/NAS, Teil 5 ist ein Beitrag von .
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Zur Organisation und Wiedergabe von Musik und Videos wird Plex verwendet. Plex besteht aus zwei Komponenten, dem Server und den Clients. Die Serverkomponente wird auf dem Homeserver installiert. Hier werden alle Audio- und Videodateien zentral verwaltet und der Mediaserver organisiert. Die Clients sind die Wiedergabegeräte. [...]
Plex Mediaserver: Ubuntu 20.04 Homeserver/NAS, Teil 6 ist ein Beitrag von .
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Im letzten Kapitel geht es um die Datensicherung. Der Homeserver dient als zentrale Ablage für eine Vielzahl wichtiger Dateien. Eventuell sogar von mehreren Personen. Ein Verlust der Daten wäre daher verheerend. Das RAID-System schützt zwar vor dem Verlust der Daten durch einen Hardwaredefekt an einer [...]
Backup: Ubuntu 20.04 Homeserver/NAS, Teil 7 ist ein Beitrag von .
Converseen ist ein Tool, mit dem sich mehrere Bilder stapelweise verarbeiten lassen. Das Programm bietet die Möglichkeit viele Bilder auf einmal zu vergrößern, zu verkleinern, in ein anderes Format zu konvertieren oder Bilder zu drehen. Zur Bildbearbeitung verwendet Converseen ImageMagick.
Ich speichere die Bilder meiner Kamera im RAW-Format und als JPEG. Die RAW-Bilder verwende ich zur Bearbeitung. Die JPEGs importiere ich beispielsweise in die Fotobibliothek des Smartphones, ohne sie weiter zu bearbeiten. Sie dienen als Erinnerungen.
Irgendwann fiel mir auf, dass ich die JPEG-Version der Bilder nicht in derselben, hohen, Auflösung benötige wie die RAW-Bilder. Also änderte ich die Einstellung in der Kamera, sodass die JPEG-Versionen speicherplatzsparend in einer niedrigeren Auflösung gespeichert werden.
Allerdings wollte ich auch die alten, bereits gespeicherten Bilder verkleinern um Speicherplatz zu sparen, der ja gerade auf dem Smartphone gerne knapp wird.
Alle Bilder mit einem Bildbearbeitungsprogramm wie GIMP zu öffnen, zu verkleinern und wieder zu speichern kam nicht in Frage. Das wäre viel zu zeitaufwändig gewesen. Also habe ich mich auf die Suche nach einem Programm gemacht, dass möglichst alle Bilder auf einmal verkleinern kann.
Gefunden habe ich Converseen, dass genau diese Aufgabe erfüllt.
Bei Ubuntu ist Converseen in den Paketquellen enthalten und kann somit direkt installiert werden. Wer die aktuellste Version möchte, der findet ein entsprechendes Repository auf der Projekthomepage (http://converseen.fasterland.net). Dort findet man auch den Quellcode von Converseen, sowie die Windows-Version.
Eigentlich ist Converseen selbsterklärend. Allerdings habe ich nicht auf Anhieb kapiert, dass man links, wo das Vorschaubild gezeigt wird, nach unten scrollen muss, um zu den Bearbeitungsoptionen zu gelangen. Stattdessen habe ich mehrere Minuten damit verbracht, diese in den Menüs zu suchen. Dort findet sich jedoch nichts.
Man muss also im „Actions Panel“ nach unten scrollen, um zu den Bearbeitungsoptionen zu gelangen. Dort kann man beispielsweise die gewünschte Bildgröße in % vom Original, oder in Pixeln angeben.
Außerdem kann der Speicherort für die neuen Bilder ausgewählt werden und die Benennung geändert werden. So kann beispielsweise ein Zusatz vor, oder nach dem ursprünglichen Dateinamen hinzugefügt werden.
Anschließend aktiviert man alle Bilder die bearbeitet werden sollen und klickt auf „Convert“. Damit startet Converseen die Bearbeitung.
Mit Converseen Bilder stapelweise verarbeiten ist ein Beitrag von techgrube.de.
Die Möglichkeiten die die Linux-Kommandozeile bietet sind nahezu unbegrenzt. Es existieren unendlich viele Tools und Befehle und nahezu unendlich viele Möglichkeiten diese zu kombinieren und zu verknüpfen.
Natürlich merkt man sich all das, was man im Alltag verwendet. Aber Funktionen die man nur selten verwendet vergisst man auch leicht. In diesem Fall durchsuche ich die History nach einem Parameter an den ich mich noch erinnere. Sofern der Befehl aber nicht mehr in der History zu finden ist, geht die Sucherei los.
Wenn man nicht gerade beruflich den ganzen Tag mit der Kommandozeile arbeitet, so kennt man deren Möglichkeiten höchstwahrscheinlich nur zum Teil. Jedenfalls geht es mir so. Ich entdecke laufend, mit jedem neuen Problem und jeder neuen Lösung neue Möglichkeiten der Linux-Kommandozeile.
Egal ob man nun etwas sucht, oder einfach nur lernen und stöbern möchte, die Linux Command Library (http://linuxcommandlibrary.com) ist eine tolle Anlaufstelle.
Die Linux Command Library ist unterteilt in drei Kategorien. Commands, Basic und Tips.
In der Kategorie Commands findet man eine riesige Liste mit Befehlen. Ein Klick auf den Befehl zeigt die Manpage des dazugehörigen Tools, ergänzt um ein praktisches TLDR mit den gängigsten Optionen.
Die Kategorie Basic zeigt weitere Unterkategorien an. Beispielsweise System Information, Files/Folders, Network, SSH und viele mehr. Ein Klick auf die Unterkategorie listet passende Befehle und Tools auf. Gerade die Kategorie Basic lädt zum Stöbern ein.
Dann gibt es noch die allgemeine und recht kurze Kategorie Tips. Hier finden sich allgemeine Tipps und Hinweise, beispielsweise zur Verkettung von Befehlen.
Die Linux Command Library gibt es nicht nur im Web, sondern auch als App für Android un iOS. Die App ist zwar Open Source und der Quellcode auf Github, trotzdem scheint es die App für Android nur über Google Play zu geben. Für das iPhone und iPad ist die Linux Command Library logischerweise nur über den App-Store verfügbar.
Der Vorteil der Apps ist, dass diese auch offline funktionieren. Ansonsten funktioniert die Webseite auch ganz hervorragend im Webbrowser auf dem Smartphone.
Zur Linux Command Library im Web
Zur Linux Command Library App für Android
Zur Linux Command Library App für iOS
Linux Command Library für Android, iOS und im Web ist ein Beitrag von techgrube.de.
Um die SSL-Konfiguration eines Webservers zu untersuchen ist SSL Labs von Qualis oft die erste Wahl. Allerdings verwenden nicht nur Webserver SSL, bzw. TLS. Und nicht jeder möchte unbedingt externe Onlinetools für jede Aufgabe verwenden.
Das Linux Magazin stellt in jeder Ausgabe kleine und praktische Tools vor und immer wieder finden sich darunter nette Helfer für den Alltag. In Ausgabe 03/2020 findet testssl.sh Erwähnung.
Testssl.sh ist ein tolles Tool zum prüfen der SSL-Konfiguration. Es läuft lokal auf der Kommandozeile und erzeugt ähnlich übersichtliche und leicht verständliche Reports wie SSL Lab. Außerdem werden verschiedene Protokolle unterstützt, so dass nicht nur Webserver, sondern beispielsweise auch Mailserver getestet werden können.
Das Skript kann direkt von Github unter https://github.com/drwetter/testssl.sh heruntergeladen werden und funktioniert direkt, ohne Installation.
Ein Aufruf von „./testssl.sh https://example.de“ prüft die SSL-Einstellungen einer Webseite mit den Standardeinstellungen.
Ein Aufruf des Skripts ohne irgendwelche Parameter zeigt eine Liste mit verfügbaren Optionen und Schaltern. Damit können bestimmte Test gewählt werden, oder auch Zugangsdaten für eine via HTTP Basic Auth versperrte Seite.
Die Ergebnisse der einzelnen Tests werden übersichtlich aufbereitet im Terminal ausgegeben. Alternativ kann man die Ergebnisse auch in eine Datei schreiben lassen. Hierfür wird eine Vielzahl an Formaten unterstützt, wie z.b. Text, HTML, CSV, und andere.
SSL-Einstellungen von Servern untersuchen ist ein Beitrag von techgrube.de.
Wenn man einen Server betreibt – und sei es nur ein Raspberry Pi – dann interessiert man sich wahrscheinlich auch dafür wie dieser ausgelastet ist und ob alle Dienste durchgehend funktionieren. Wo Tools wie Grafana oder Munin übertrieben sind, kann Monitorix punkten.
Monitorix ist Open Source, die Entwicklung des Projekts kann man auf Github verfolgen. Fertige Installationspakete für die gängigen Distributionen findet man auf der Downloadseite des Projekts. Seit Buster ist Monitorix auch in den Debian Paketquellen enthalten und kann damit auch auf dem Raspberry Pi mit Raspbian mit einem einfachen sudo apt install monitorix installiert werden.
Monitorix ist in Perl geschrieben und bringt seinen eigenen Webserver mit, der standardmäßig über Port 8080 unter http://localhost:8080/monitorix erreichbar ist und optional mit einem Passwortschutz versehen werden kann.
Für die schnelle Installation und Einrichtung eines Monitoringtools auf dem Homeserver oder Raspberry Pi ist das sicher eine brauchbare Lösung. Wer dem eingebauten Webserver nicht traut, der kann Monitorx auch über einen der bekannten Webserver erreichbar machen.
Apache und lighthttpd können mit mod_cgi den Perl-Code von Monitorix direkt ausführen. Vorschläge für eine entsprechende Serverkonfiguration liefert Monitorix im docs-Verzeichnis mit.
Alternativ kann man Apache oder Nginx als Proxy vor den eingebauten Webserver schalten. Den Zugriff auf den eingebauten Webserver sollte man dann in der Konfigurationsdatei unter /etc/monitorix/monitorix.conf auf die lokale IP-Adresse beschränken und/oder den Zugriff von außen durch Firewallregeln verbieten.
Untenstehende Konfiguration verwende ich um einen NGINX als Proxy vor den Monitorix-Webserver zu setzen und den Zugang mit einem Passwort zu sichern.
Anmelden
## Monitorix start
location /monitorix {
auth_basic "Restricted";
auth_basic_user_file /path/to/auth-basic/monitorix.htpasswd;
include proxy_params;
proxy_pass http://127.0.0.1:8080/monitorix;
allow 127.0.0.0/8;
location ~ ^/monitorix/(.+\.png)$ {
alias /var/lib/monitorix/www/$1;
}
}
## Monitorix endMonitorix sammelt aus einer Vielzahl an Quellen Daten und bereitet diese zu ansprechenden Graphen auf. Die Liste der unterstützten Datenquellen kann man auf der Webseite unter Features ansehen, die Liste ist wirklich sehr lang. So unterstützt Monitorix auch das Auswerten verschiedener Raspberry Pi Sensoren und kann so u.a. den Verlauf der Kerntemperatur und Taktfrequenz auswerten. Teilweise müssen diese aber erst in der Konfigurationsdatei aktiviert werden.
Auch das Erstellen von Emailreports und Alarmmeldungen, wenn z.B. die load average einen bestimmten Wert übersteigt oder der Speicherplatz zu Neige geht. Natürlich stößt ein ausschließlich lokal installiertes Monitoringtool hier an seine Grenzen. Fällt das System aus, kann es auch keine Warnungen mehr versenden, so dass der Ausfall im Zweifel unbemerkt bleibt.
Wenn man aber bestimmte Daten wie z.B. die Systemauslastung, die Zugriffe auf Webserver und Datenbank im Tagesverlauf visualisieren möchte, ist Monitorix eine Lösung die schnell installiert und eingerichtet ist.
Monitorix: Monitoringtool für kleine Server ist ein Beitrag von techgrube.de.
Ich erstelle regelmäßig Screenshots oder andere Grafiken, beispielsweise für diese Webseite. Um das Bild an die Farbgebung der Webseite anzupassen, benötige ich häufig den Farbcode von einer bestimmten Stelle des abgebildeten Programms oder der abgebildeten Webseite.
Mein bisheriger Weg um an den richtigen Farbcode zu kommen war etwas kompliziert. Zuerst habe ich einen Screenshot erstellt und diesen in Gimp importiert. Dann habe ich mir mit dem color picker von Gimp den Farbcode der gewünschten Stelle anzeigen lassen.
Es geht aber sehr viel einfacher, mit dem Tool “Pick“.
Pick ist ein Werkzeug, das es einem ermöglicht den Farbcode von einer beliebigen Stelle auf dem Desktop, bzw. von jeder Stelle eines Programms anzeigen zu lassen.
Die Farbe an der ausgewählten Stelle kann man sich in verschiedenen Farbcodes anzeigen lassen, beispielsweise als HEX- oder RGB-Codes. Beim picken einer Farbe auf dem Desktop erstellt Pick einen Screenshot, so dass man später nachvollziehen kann von welcher Stelle, bzw. aus welchem Programm oder Webseite man die Farbe gepickt hat.
Um die Farbe an der richtigen stelle auf dem Desktop zu wählen, öffnet Pick eine Lupe mit einem Cursor. In dieser Ansicht kann man außerdem mit dem Mausrad noch hineinzoomen, so dass man pixelgenau den richtigen Farbton picken kann.
Außerdem speichert Pick den Verlauf der gepickten Farben, so dass man diese später einfach wieder aufrufen kann. Ein Klick auf den Button “Copy” kopiert den Farbcode in die Zwischenablage. Von dort aus kann man diesen einfach im Bildbearbeitungsprogramm einfügen.
Pick ist Open Source, der Quellcode des Programms ist auf GitHub zu finden. Die Webseite des Projekts ist https://kryogenix.org/code/pick. Wer sich nicht selber um die benötigten Abhängigkeiten, bzw. um Updates für Pick kümmern möchte, der kann sich einfach das Snap-Paket installieren. Dabei handelt es sich auch um die vom Projekt empfohlene Installationsmethode.
Bei einigen Distributionen muss zuerst snapd installiert werden, damit Snaps installiert und ausgeführt werden können. Da das Snap-Paketformat maßgeblich von Canonical entwickelt wird, kann man Snaps unter Ubuntu direkt installieren und nutzen. Pick lässt sich unter Ubuntu einfach mit “sudo snap install pick-colour-picker” installieren.
Pick ist für mich ein praktisches Werkzeug um den Hex-Code einer Farbe von einer beliebigen Stelle auf dem Bildschirm herauszufinden um damit weiterarbeiten zu können. Es ist eines dieser kleinen Tools, die nur eine Aufgabe erfüllen, diese aber sehr gut.
Pick: Farbcodes von beliebiger Stelle des Desktops picken ist ein Beitrag von techgrube.de.
Standardmäßig werden USB-Sticks und andere externe Datenträger unter Linux Mint automatisch eingehängt und in einem neuen Fenster im Dateimanager geöffnet.
Da ich gerade wieder häufig mit dem Raspberry Pi herumspiele, kommt es vor, dass ich häufig dessen SD-Karte am Laptop einstecke. Dabei werden jedes mal zwei neue Dateimanagerfenster geöffnet. Einmal für die Bootpartition und einmal für die Betriebssystempartition auf der SD-Karte. Da ich normalerweise jedoch über das Terminal auf die SD-Karte zugreifen möchte, schließe ich die Fenster immer direkt nachdem sie geöffnet wurden.
In den Systemeinstellungen von Linux Mint habe ich keine Option gefunden um dieses Verhalten zu ändern. Also habe ich in der Vergangenheit das Verhalten des Betriebssystems eben akzeptiert. Immerhin handelt es sich doch nur um ein Luxusproblem.
Heute hat mich dieses Verhalten jedoch so genervt, dass ich mich auf die Suche nach einer Lösung gemacht habe. Und -Taaadaaa- nach Jahren der Nutzung habe ich die Einstellungen des Dateimanagers Nemo entdeckt.
Für den Fall dass ich nicht der einzige bin, der vor lauter Bäumen den Wald nicht sieht, schreibe ich diesen Beitrag.
Die entsprechende Option findet man nicht in den Systemeinstellungen, sondern in den Einstellungen des Dateimanagers Nemo. In einem geöffneten Fenster klickt man auf Bearbeiten > Einstellungen. Hier wäht man in der linken Menüleiste den Punkt “Verhalten” und scrollt nach unten zu “Handhabung von Datenträgern“.
Hier findet man die beiden gesuchten Optionen “Automatisch entfernbare Medien, beim Einfügen und beim Systemstart, einhängen” sowie “Für automatisch eingehängte Geräte, automatisch einen neuen Ordner öffnen“.
Wenn man bei beiden Optionen den Haken entfernt, werden externe Datenträger zukünftig zwar noch in der Seitenleiste von Nemo angezeigt, jedoch nicht mehr eingehängt und nicht mehr geöffnet.
Automatisches Öffnen von USB-Sticks unter Linux Mint deaktivieren ist ein Beitrag von techgrube.de.
Wahrscheinlich bin ich einer der wenigen Menschen, die sich regelmäßig mit dem Thema Backup beschäftigen. Aus diesem Grund schaue ich mir gerne neue, bzw. mir bisher unbekannte Backuplösungen an.
Schon lange bin ich ein großer Fan der Backupsoftware Borg. Das Tool verfügt über alle Funktionen und Eigenschaften die ich mir für eine Backuplösung wünsche. Die Backups lassen sich verschlüsseln und somit sicher auf einem entfernten Server speichern. Es unterstützt Deduplizierung, so dass die Backups nur so groß wie nötig werden. Selbstverständlich lässt sich auch die Integrität der Backups prüfen, Außerdem lassen sich die Backups via FUSE im lokalen Filesystem mounten. Somit kann man bequem durch die Backups browsen und Dateien herauskopieren.
Borg is Open Source. Der Quellcode ist auf Github zu finden und in den Repos der gängigen Distributionen. Die Dokumentation findet man unter borgbackup.readthedocs.io.
Borg ist für mich die perfekte Backuplösung. Zumindest für die Kommandozeile
Unter dem Namen Vorta existiert mittlerweile eine grafische Benutzeroberfläche für Borg. Vorta ist ebenfalls Open Source und wird hauptsächlich vom Betreiber von BorgBase entwickelt, einem Hoster für Borg Repositories. Daher verwundert der Hinweis auf das Angebot von BorgBase in der Oberfläche von Vorta wenig.
Vorta findet man auf Github, wo auch die verschiedenen Installationsmethoden beschrieben werden. In den Repos der Distributionen ist Vorta bisher nicht zu finden. Lediglich bei Arch und Arch basierten Distributionen kann Vorta aus dem AUR installiert werden. Bei anderen Distributionen bietet sich die einfach Installation mit PIP an.
Auch wenn diverse Destops mittlerweile der Meinung sind dass Tray-Icons ausgedient haben, bin ich hier entschieden anderer Meinung. Desktop-Notifications sind schön und gut um über eine gerade stattfindende Aktion zu informieren. Tray-Icons sind allerdings viel besser geeignet um einen aktuellen Zustand anzuzeigen. Ist die Nextcloud syncronisiert oder liegt ein Fehler vor. Man kann auf einen Blick erkennen ob Updates verfügbar sind, ob ein Backup läuft oder ob evtl. das letzte Backup fehlgeschlagen ist. Ein Desktop ist eben kein Smartphone.
Eines der Features von Vorta ist für mich daher das anzeigen eines Tray-Icons. Darüber lässt sich das Programm aufrufen, es lassen sich Backups starten und man wird informiert ob gerade ein Backup läuft. Leider zeigt das Icon nicht an, ob das Backup erfolgreich war oder nicht. Hierzu muss man die Anwendung öffnen.
Ansonsten ist Vorta einfach ein Tool um Borg über eine grafische Benutzeroberfläche zu steuern und unterstützt dabei alle Funktionen die ich verwende, bzw. die mir bekannt sind. Es lassen sich neue Borg Repositories erstellen oder auch bereits vorhandene Repositories einbinden. Dabei können auch mehrere Profile angelegt werden.
Ein Schwachpunkt ist für mich die Zeiplanung der Backups mit Vorta. Hier scheinen normale Cronjobs verwendet zu werden. Auf deinem Desktop oder Laptop, der normalerweise nicht durchgängig läuft kann das problematisch werden, da verpasste Sicherungen nicht nachgeholt werden. Hat man einen schlechten Zeitpunkt für die Sicherungen gewählt, so kann es sein dass tagelang keine Sicherung vorgenommen wird, weil der Computer immer außerhalb der Sicherungszeit läuft. Ob es möglich ist über Anacron oder Systemd-Timer eine Borg-Sicherung auszulösen die Vorta auch erkennt, habe ich nicht getestet.
Die Backuplogs lassen sich ebenfalls direkt über Vorta einsehen. Außerdem kann man eigene Shell-Kommandos definieren, die vor oder nach einem Backup ausgeführt werden.
Über weitere Reiter in der Anwendung kann man alte Backup manuell oder automatisiert löschen. Außerdem können einzelne Backups in einen Ordner entpackt oder im Dateisystem gemountet werden. Dann kann man ganz normal über den Dateimanager oder das Terminal auf die Daten im Backup zugreifen.
Außerdem zeigt Vorta die Größe der zu sichernden Daten an, sowie den Speicherplatz den diese nach der Deduplizierung und Komprimierung der Daten im Repo einnehmen.
Ich mag die Kommandozeile und ich mag grafische Desktopoberflächen, aus diesem Grund bin ich begeisterter Linuxnutzer. Hier muss ich mich weder bei der Nutzung der Kommandozeile noch bei der Nutzung von GUI-Software einschränken lassen.
Auch die Kombination von Borg und Vorta bringt das beste aus beiden Welten zusammen. Die hervorragende Backuplösung Borg, und die komfortable Bedienung mit Vorta auf dem Dektop. Dies ermöglicht das Einrichten einer einheitlichen Backupumgebung auf allen Systemen. Egal ob Server oder Desktop.
Vorta: Grafische Benutzeroberfläche für Borg Backup ist ein Beitrag von techgrube.de.
Normalerweise werden PHP-Skripte zur Laufzeit kompiliert. Das heißt, wenn jemand eine PHP-Seite wie WordPress aufruft, wird der PHP-Quelltext (die PHP-Datei) gelesen und vom PHP-Interpreter in sogenannten Bytecode (vorkompilierter Code) umgewandelt. Dieser Bytecode wird an eine virtuelle Maschine (die Zend Engine) übergeben, die daraus maschinenlesbaren Code erzeugt. Die Zend Engine stellt dabei eine einheitliche Laufzeitumgebung für verschiedene CPU-Architekturen und Betriebssysteme bereit.
Der Bytecode wird daraufhin verworfen und muss bei jedem Aufruf der Webseite neu generiert werden. Dies kostet Rechenzeit und verzögert den Aufruf der Webseite.
Durch die Nutzung von OPCache wird der Bytecode für die spätere Verwendung zwischengespeichert, so dass er nicht bei jedem Aufruf der Webseite neu erzeugt werden muss. Dies kann die Ladezeit von WordPress (oder anderen PHP-Projekten) spürbar beschleunigen.
Der Preis dafür ist, dass zum Zwischenspeichern des vorkompilierten Bytecodes RAM und/oder Festplattenspeicher benötigt wird. Außerdem werden (abhängig von der OPcache Knfiguration) Änderungen am PHP-Code unter Umständen nicht sofort sichtbar, da sich noch eine alte Version im Cache befindet.
Um OPCache auf einem Ubuntu-Server zu nutzen, muss das Paket php7.2-opcache installiert werden. Anschließend kann der Cache über die php.ini aktiviert werden. Die php.ini befindet sich bei Ubuntu und der Verwendung von PHP als Apache-Modul unter /etc/php/7.2/apache2/php.ini. Bei Verwendung von PHP-FPM, beispielsweise mit NGINX, findet man die Konfigurationsdatei unter /etc/php/7.2/fpm/php.ini
In der php.ini scrollt man bis zum Abschnitt [opcache].
Um OPcache zu aktivieren muss die Zeile
;opcache.enable=0
abgeändert werden in
opcache.enable=1
Außerdem können und sollten weitere Einstellungen vorgenommen werden. In untenstehender Tabelle sind einige Option beschrieben, die ich für die wichtigsten halte.
| Option | Bedeutung |
| opcache.memory_consumption=256 | Die Menge an Speicherplatz die OPcache zur Verfügung steht, in Megabytes. |
| opcache.interned_strings_buffer=16 | Speicherplatz der für string interning zur Verfügung steht, ebenfalls in Megabytes. |
| opcache.max_accelerated_files=16229 | Die maximale Anzahl an Schlüsseln (und damit PHP-Skripte) die gespeichert werden können. Der Wert sollte größer als die Anzahl vorhandener Skripte sein. Der tatsächlich verwendete Wert wird aus einem festen Set aus Primzahlen gewählt (223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987). Es wird die Primzahl verwendet, die größer oder gleich dem gesetzten Wert ist. Gibt man beispielsweise als Wert 10000 an, werden tatsächlich 16229 Schlüssel gecached. Man kann also auch direkt eine der angegebenen Primzahlen als Wert setzen. |
| opcache.max_wasted_percentage=10 | Prozentsatz an verschwendetem Speicherplatz, der akzeptiert wird, becor der Cache komplett geleert wird. “Waste” entsteht, wenn sich der Code ändert, während OPcache läuft. Der alte Cache-Eintrag wird dabei als “waste” markiert. |
| opcache.validate_timestamps=1 | Legt fest, ob OPcache in regelmäßigen Abständen prüfen soll, ob sich der PHP-Code in einer Datei geändert hat. Wenn dies deaktiviert ist, muss nach jeder Änderung am Code (z.B. ein WordPress Update) ein Reset von OPcache durchgeführt werden, oder OPcache neu gestartet werden. Wer WordPress-Updates automatisch einspielen lässt, sollte die Option aktivieren. Wer die manuell macht, kann die Option deaktivieren und zusätzlich Rechenzeit sparen. |
| opcache.revalidate_freq=300 | Zeit in Sekunden, nach der überprüft wird ob sich der PHP-Code in einen Skript keändert hat. “0” bedeutet, dass die Prüfung bei jedem Aufruf vorgenommen wird. |
| opcache.file_cache=/path/to/cache | OPcache kann Daten im Ram und/oder auf einem Datenträger speichern. Damit kann OPcache z.B. auch in Shared-Hosting Umgebungen genutzt werden. Auf dem eigenen Server hat die Nutzung dieser Option den Vorteil, dass bereits erzeugte Daten nach einem Neustart des Servers nicht verloren gehen. Das Verzeichnis muss vom PHP-Prozess beschrieben werden können. |
| opcache.file_cache_only=0 | Legt fest ob OPcache seine Daten nur auf dem Datenträger speichert (1) oder ob Daten im RAM und zusätzlich auf dem Datenträger gespeichert werden (0) |
Wenn der Server von mehreren Benutzern verwendet wird, sind evtl. die Optionen opcache.validate_permission und opcache.validate_root von Bedeutung, die standardmäßig deaktiviert sind. Erstere prüft, ob der User überhaupt Leseberechtigung für das entsprechende Skript hat. Dies verhindert, dass zwischengespeicherte Daten an andere Benutzer geleaked werden. Zweitere verhindert Namenskollisionen bei verschiedenen chroot Umgebungen.
Damit Änderungen wirksam werden, muss Apache, bzw. PHP-FPM neu gestartet werden. Dabei wird außerdem der Cache geleert.
Eine schöne Möglichkeit zum Steuern von OPcache und zum prüfen, ob OPcache überhaupt genutzt wird ist das Tool opcache-gui das auf Github zu finden ist. Es handelt sich dabei um ein PHP-Skript, das den verwendeten Speicherplatz, die Anzahl der zwischengespeicherten Skripte uvm. anzeigt. Da sich außerdem verschiedene Funktionen von OPcache steuern lassen, sollte man den Zugriff auf das Skript mit einem Passwort sichern.
Um opcache-gui zu nutzen, muss lediglich das PHP-File in den eigenen Webverzeichnis kopiert werden und über den Webbrowser aufgerufen werden.
Wer opcache-gui dauerhaft einsetzen will, der sollte den Zugang unbedingt mit einem Passwortschutz versehen.
PHP-Seiten wie WordPress mit OPCache beschleunigen ist ein Beitrag von techgrube.de.
Systemd wird häufig kritisiert, weil es größer und komplexer als bisherige Init-Systeme ist. Dafür bringt Systemd aber auch eine ganze Reihe an Tools zur Fehlerbehebung und Systemanalyse mit.
Eines davon ist systemd-analyze, mit dem sich der Bootvorgang des Systems darstellen und analysieren lässt. Die Ausgabe kann dabei textbasiert auf der Kommandozeile erfolgen, oder auch als svg-Grafik exportiert werden.
Ein simpler Aufruf von
systemd-analyze
zeigt eine Übersicht, welche Systembestandteile wie lange zum booten benötigen. Damit erhält man folgende Ausgabe.
Sofern das Betriebssystem auf einem Computer mit UEFI installiert ist, bekommt man auch die Startzeit des UEFI (firmware) präsentiert. Anschließend wird die Startzeit des Bootloaders ausgegeben (loader). Dass diese bei mir mit knapp 32 Sekunden angegeben ist, liegt (denke ich) an der Wartezeit im Grub Auswahlbildschirm. Anschließend werden die Startzeiten der systemnahen Komponenten (kernel) und der Benutzerumgebung (userland) angegeben.
Eine genauere Ausgabe erhält man mit dem Befehl
systemd-analyze blame
Damit erhält man eine Auflistung aller beim booten gestarteten Dienste, sortiert nach ihrer Startzeit. Damit lassen sich Dienste, die das starten verzögern schnell identifizieren.
Außerdem lässt sich die Ausgabe auch als SVG-Grafik exportieren. Damit erhält man noch detailliertere Ergebnisse. der Export erfolgt mit
systemd-analyze plot > boot.svg
Allerdings ist die exportierte Grafik ziemlich groß, so dass man viel scrollen muss um diese zu analysieren. Horizontal wird dabei die Startzeit in Sekunden angegeben. Vertikal werden die einzelnen Dienste aufgelistet.
Die Ausgaben von systemd-analyze sind nicht nur interessant, sondern ermöglichen auch, auf den ersten Blick zu erkennen, warum der Bootvorgang so lange dauert. Dienste, die den Bootvorgang verlangsamen lassen sich damit direkt identifizieren, wo ansonsten möglicherweise eine langwierige Fehlersuche oder Analyse notwendig wäre.
Bootzeit mit Systemd analysieren ist ein Beitrag von techgrube.de.
Vor vielen Jahren habe ich Windows auf meinem Desktop durch Linux ersetzt und mittlerweile einige Distributionen im Einsatz gehabt. Immer habe ich die schnelle und einfache Installation von Software über die Paketmanager als einen der größten Vorteile gegenüber Windows gesehen. Besonders die Möglichkeit zum Einbinden von Drittquellen fand ich immer toll. Damit war die Möglichkeit geboten, Updates an einer einzigen Stelle (dem Paketmanager) durchzuführen, ohne dass man auf den “Store” der Distribution angewiesen ist.
Ja, die Sicherheitsproblematik bei Drittquellen ist mir bewusst, dieses Problem habe ich aber in noch größerem Maße beim Download von Software über irgendwelche Webseiten. Daher hoffe ich, auch in Zeiten von Flatpaks, Snaps und Appimages, dass uns die Paketmanager noch lange erhalten bleiben.
Sicherlich ist die Aufgabe, die Paketmanager zu bewältigen haben, gewaltig. Programme bringen Abhängigkeiten mit, die wiederum Abhängigkeiten haben, die wiederum…
Bei der Installation zeigen einem die Paketmanager an, welche Software durch Abhängigkeiten zusätzlich zum gewünschten Programm installiert wird. Leider zeigen sie nicht an, welches Paket welche Abhängigkeit auslöst.
Dies kann man sehr schön mit dem Programm debtree visualisieren
In der Debian/Ubuntu/Mint-Familie lässt sich debtree direkt aus den Paketquellen installieren. Zusätzlich wird graphviz benötigt, um aus den von debtree erzeugten DOT-Files ein Bild zu erstellen.
sudo apt install debtree graphviz
Anschließend kann die erste Grafik erzeugt werden. Zum testen eignet sich ein Paket, das relativ wenige Abhängigkeiten mitbringt. Beispielsweise nano oder openssl.
$ debtree nano | dot -Tpng > nano.png
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen…. Fertig
I: The following dependencies have been excluded from the graph (skipped):
I: libc6
Wie man sieht, hat debtree zuerst die Abhängigkeiten eingelesen, davon allerdings auch welche übersprungen. In diesem Fall die libc6.
Debtree hat in der Datei /etc/debtree/skiplist einige Abhängigkeiten definiert, die standardmäßig ignoriert werden. Es handelt sich dabei um Abhängigkeiten, die so gewöhnlich sind, dass sie in einem Großteil der Grafiken auftauchen würden und diese unnötig aufblasen. Die Liste kann man nach den eigenen Wünschen anpassen.
Mit der Option –no-skip soll sich das Anwenden dieser Liste deaktivieren lassen. Leider hat dies bei mir nicht funktioniert. Das Anwenden von –no-skip hatte keinerlei Auswirkungen. Alternativ kann man die skiplist anpassen, oder mit der Option –show-all alle Abhängigkeiten anzeigen lassen. Diese Möglichkeit hat funktioniert, führt aber bei Paketen mit vielen Abhängigkeiten schnell zu einer riesigen Datei.
Zusätzlich gibt es unter /etc/debtree/endlist eine Liste mit Paketen, deren Abhängigkeiten nicht weiter verfolgt werden. Im Gegensatz zu den Paketen in der Skiplist, die gar nicht in der Grafik auftauchen, werden die Pakete in der endlist in der Grafik angezeigt. Allerdings endet die Linie mit Abhängigkeiten nach diesem Paket.
Nach dem Ausführen des Befehls erhält man folgende Grafik.
Bei Paketen mit vielen Anhängigkeiten wird die Grafik schnell sehr riesig und unübersichtlich. Dies sieht man beispielsweise, wenn man sich die Abhängigkeiten des Webservers NGINX, ohne das setzen zusätzlicher Optionen, anzeigen lässt. Dabei handelt es sich auch bei NGINX noch um ein Paket mit relativ wenigen Abhängigkeiten. Möchte man die Abhängigkeiten des Pakets gnome-shell anzeigen, kapituliert dot mit folgender Meldung “dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.533022 to fit” Auch angepasste Image ist anschließend noch knapp 55 MB groß.
Um zu vermeiden, dass man riesige und damit unbrauchbare Grafiken erhält, bietet Debtree einige Optionen um die Ausgabe zu beeinflussen.
| –no-recommends | Empfohlene Pakete werden nicht angezeigt. |
| –no-alternatives | Wenn verschiedene Pakete eine Abhängigkeit erfüllen können, wird nur die erste angezeigt. |
| –no-provides | Keine virtuellen Pakete anzeigen. |
| –no-conflicts | Pakete die mit dem abgefragten Paket in Konflikt stehen werden nicht angezeigt |
| –max-depth=number | Abhängigkeiten werden nur bis zu einer bestimmten Ebene angezeigt |
Natürlich finden sich in der Manpage noch eine Vielzahl weiterer Optionen, mit denen sich die Ausgabe beeinflussen lässt. Hierbei handelt es sich meiner Meinung nach um die wichtigsten.
Die verschiedenen Pfeile, Farben und Formen haben folgende Bedeutungen.
| Farbe der Pfeile | Bedeutung |
| Blau | Direkte Abhängigkeit |
| Schwarz | Empfohlenes Paket (recommends) |
| Schwarz, gepunktet | Vorgeschlagenes Paket (suggests) |
| Grün | Stellt zur Verfügung (provides) |
| Rot | Konflikt |
| Form der Kästen | Bedeutung |
| Rechteckig, fetter Rand | Das Paket, welches untersucht wird |
| Rechnteckig, normaler Rand | Normale Pakete |
| Rechteckig, direkt untereinander | Alternative Pakete mit der selben Funktion |
| Raute | Paket, dessen Abhängigkeit nicht weiter verfolgt wird. |
| Achteckig | Virtuelles Paket |
Paketmanager haben ja im Normalfall die tolle Eigenschaft, wie durch Magie die benötigten Abhängigkeiten bereit zu stellen. Mit debtree lässt sich schön darstellen, wie diese Magie funktioniert, wie komplex die Abläufe sind und mit welchen Entscheidungen ein Paketmanager unter Umständen zu kämpfen hat.
Debtree visualisiert die Abhängigkeit von Paketen ist ein Beitrag von techgrube.de.
Als einen großen Vorteil von Linux-Systemen gegenüber Windows habe ich immer die Paketmanager empfunden. Schnell und einfach lässt sich darüber Software installieren und updaten, ohne auf Downloads von irgendwelchen Webseiten zurückgreifen zu müssen.
Genau so schnell wie man eine Software installieren kann, so schnell kann man auch vergessen dass sie installiert ist. Wenn irgendwann der Speicherplatz knapp wird, kann es interessant sein welche Pakete am meisten Platz auf dem Datenträger verbrauchen.
Die Antwort darauf kann das Kommandozeilentool dpigs aus dem Paket debian-goodies liefern.
Wenn man dpigs ohne zusätzliche Parameter aufruft, werden die zehn Speicherhungrigsten Programme aufgelistet. Der Speicherplatzverbrauch wird in Bytes vor dem Paketnamen angezeigt.
Mit der Option -n kann die Liste verlängert werden. Der Befehl “dpigs -n 20” listet 20 Programme auf.
Um die Ausgabe besser lesbar zu machen, kann man die Option -H verwenden. Damit werden die Speicherplatzangaben in Megabyte und Kilobyte angegeben.
Mit dem Befehl
dpigs -n 30 -Hwerden die 30 installierten Pakete aufgelistet, die am meisten Speicherplatz verbrauchen. Die Dateigröße wird dabei im menschenlesbaren Format ausgegeben.
Mit Dpigs die Größe von installierten Paketen anzeigen ist ein Beitrag von techgrube.de.
