WordPress und Nginx: Alte Permalinks umleiten
Mit NGINX Rewrite-Regeln alte WordPress-Permalinks wie /YYYY/MM/dd/postname auf die neue Struktur umleiten – ohne Plugins und SEO-freundlich. Archive bleiben intakt!
Mit NGINX Rewrite-Regeln alte WordPress-Permalinks wie /YYYY/MM/dd/postname auf die neue Struktur umleiten – ohne Plugins und SEO-freundlich. Archive bleiben intakt!
Mit einer cleveren Kombination aus Syncthing und WebDAV auf einem Raspberry Pi synchronisieren wir unsere KeePass-Datenbanken plattformübergreifend und zuverlässig – ohne Abhängigkeit von klassischen Cloud-Diensten.
Mit Surfraw lassen sich vom Terminal aus über 100 Suchmaschinen und Webseiten befragen. Antworten gibt es textbasiert oder grafisch.
Wer des Öfteren Proxmox aufsetzen muss, dem kommt dieses kleine Script vermutlich gerade recht. Es installiert Proxmox und hilft bei Bedarf bei der Integration in einen Cluster.
Diese Einführung gibt Antworten auf die folgenden Fragen:
In dieser Einführung verwendete Betriebssysteme:
Um dieser Einleitung folgen zu können, solltet ihr mit den Grundlagen der Linux-Systemadministration vertraut sein und zumindest mit den folgenden Begriffen etwas anfangen können:
Ein Intrusion Detection System (englisch intrusion „Eindringen“, IDS) bzw. Angriffserkennungssystem ist ein System zur Erkennung von Angriffen, die gegen ein Computersystem oder Rechnernetz gerichtet sind. Das IDS kann eine Firewall ergänzen oder auch direkt auf dem zu überwachenden Computersystem laufen und so die Sicherheit von Netzwerken und Computersystemen erhöhen. Erkannte Angriffe werden meistens in Log-Dateien gesammelt und Benutzern oder Administratoren mitgeteilt; hier grenzt sich der Begriff von Intrusion Prevention System (englisch prevention „Verhindern“, IPS) ab, welches ein System beschreibt, das Angriffe automatisiert und aktiv verhindert.
Quelle: https://de.wikipedia.org/wiki/Intrusion_Detection_System (Letzter Abruf: 2023-09-08)
Die Gruppe der Intrusion Detection Systems (IDS) untergliedert sich in:
Beim AIDE handelt es sich um ein Host-basiertes IDS. Es ist unter der GPL-2.0 lizenziert.
Aus dem vorhergehenden Abschnitt ist bekannt, dass es sich bei AIDE um ein Host-basiertes System zur Angriffs- bzw. Einbruchserkennung für Linux-Systeme handelt. Es stellt ein kostengünstiges Werkzeug dar, mit dem die Integrität eines Systems überprüft werden kann.
Es soll dem Administrator helfen, zu erkennen, ob Dateien oder Verzeichnisse eines Systems hinsichtlich ihres Inhalts und bzw. oder ihrer Eigenschaften wie z.B. Berechtigungen, SELinx-Kontext, erweiterte Attribute, etc. verändert wurden.
/var/log/aide/aide.log protokolliertUm diese Schwäche zu minimieren, sind folgende Maßnahmen durch Administratoren in Erwägung zu ziehen:
Wie diese Maßnahmen umgesetzt werden können, beschreibe ich in einem folgenden Beitrag.
Werden beispielsweise Konfigurationsdateien unterhalb von /etc auf Änderungen hin überwacht, wird auch jede beabsichtige Änderung protokolliert. Das Programm kann zwischen legitimen und unautorisierten Änderungen nicht unterscheiden.
Daher ist nach jeder legitimen Änderungen die Referenzdatenbank zu aktualisieren. Ich empfehle, dies als einen Schritt in den Konfiguration-Management-Workflow zu integrieren und diese Aufgabe einen Automaten wie Ansible, Chef, Puppet o.ä. erledigen zu lassen. Dies erscheint mir weniger fehleranfällig zu sein als bei einer manuellen Durchführung, wo dieser Schritt sicher gern einmal vergessen wird.
AIDE ist in den Paketquellen der meisten Distributionen vorhanden und kann wie folgt installiert werden.
$ sudo dnf in aide
[sudo] password for tronde:
Updating Subscription Management repositories.
Last metadata expiration check: 2:26:44 ago on Fri 08 Sep 2023 08:16:28 PM CEST.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
aide x86_64 0.16-100.el9 rhel-9-for-x86_64-appstream-rpms 154 k
Transaction Summary
================================================================================
Install 1 Package
Total download size: 154 k
Installed size: 354 k
Is this ok [y/N]:
/etc/aide.conf besitzt im Auslieferungszustand bereits 303 Zeilen; ohne Kommentare und Leerzeilen sind es immerhin noch 161aide.conf(5)/etc/aide.conf vertraut machen; oder würdet ihr einem Firewall-Regelwerk vertrauen, das ihr nicht kennt?$ sudo apt install aide
[sudo] password for jkastning:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
aide-common liblockfile-bin liblockfile1 libmhash2
Suggested packages:
figlet
The following NEW packages will be installed:
aide aide-common liblockfile-bin liblockfile1 libmhash2
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 372 kB of archives.
After this operation, 1064 kB of additional disk space will be used.
Do you want to continue? [Y/n]
aide werden noch die Pakete aide-common, liblockfile-bin, liblockfile1 und `libmhash2` installiert
/etc/aide/aide.conf installiert Debian auch das Verzeichnis /etc/aide/aide.conf.d, in welchem sich direkt nach der Installation schon etliche Konfigurationsdateien befinden:$ ls -l /etc/aide/aide.conf.d/ | wc -l
212
Während AIDE in RHEL über eine einzige Datei (/etc/aide.conf) konfiguriert wird, gibt es in Debian eine Konfigurationsdatei (/etc/aide/aide.conf) und die Verzeichnisse /etc/aide/aide.conf.d sowie /etc/aide/aide.settings.d, welche weitere Dateien zur Konfiguration und Einstellungen beinhalten.
Eine AIDE-Konfigurationsdatei aide.conf besteht aus drei verschiedenen Arten von Zeilen:
Parameter = Wert bzw. Gruppenname = Wert@@define foo bar die Variable foo mit dem Wert barAIDE kann die folgenden Attribute bzw. Elemente von Dateien auf Änderungen hin überwachen:
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#acl: Access Control Lists
#selinux SELinux security context
#xattrs: Extended file attributes
#md5: md5 checksum
#sha1: sha1 checksum
#sha256: sha256 checksum
#sha512: sha512 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
Der folgende Code-Block zeigt die Definition der beiden Gruppen NORMAL und DIR (aus der /etc/aide.conf in RHEL 9), welche spezifizieren, welche Attribute überwacht werden sollen, wenn die jeweilige Gruppe in einer Regel verwendet wird.
NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs
Welche Dateien und Verzeichnisse in die AIDE-Datenbank aufzunehmen bzw. auszuschließen sind durch reguläre Ausdrücke bestimmt. Der nächste Code-Block zeigt drei Beispiele, die anschließend erläutert werden:
/etc NORMAL
=/var/log/ DIR
=/home DIR
!/dev
/etc und alle darunterliegenden Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit den Regeln aus der Gruppe NORMAL verknüpft/var/log/ und die direkt darunter befindlichen Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit der Gruppe DIR verknüpft; der Inhalt der Unterverzeichnisse wird nicht in die Datenbank aufgenommen/home wird aufgenommen; nicht jedoch der Inhalt davon/dev und alle darunterliegenden Dateien und Verzeichnisse werden nicht in die AIDE-Datenbank aufgenommenMit Sicherheit und Vertrauen ist das immer so eine Sache. Am besten ist es stets, wenn Vertrauen für Sicherheit nicht erforderlich ist. Daher rate ich an dieser Stelle nochmals ausdrücklich, die AIDE-Konfiguration zu überprüfen und ggf. den eigenen Bedürfnissen anzupassen… Nur um direkt gegen meinen eigenen Rat zu verstoßen.
Der Umfang an Regeln ist in beiden Systemen so groß, dass ich in dieser Einführung nicht alle einzeln erläutern kann. Ich vertraue für diese Einführung daher darauf, dass die Distributionen eine sinnvolle Konfiguration ausliefern.
Initialisiert wird die Datenbank je nach Distribution mit einem leicht abgewandelten Befehl.
$ sudo time aide --init
Start timestamp: 2023-09-18 20:50:06 +0200 (AIDE 0.16)
AIDE initialized database at /var/lib/aide/aide.db.new.gz
Number of entries: 54290
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.new.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-18 20:50:19 +0200 (run time: 0m 13s)
Die erzeugte Datenbank wird umbenannt, indem das new aus dem Dateinamen entfernt wird.
$ sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Die umbenannte Datei stellt die Referenzdatenbank dar, gegen die mit dem Befehl aide --check geprüft werden kann, ob es Änderungen im Dateisystem gab.
In diesem Artikel gebe ich mich damit zufrieden, dass die Datenbank auf dem zu überwachenden Host liegt und damit dem Risiko unterliegt, von einem Angreifer manipuliert zu werden (siehe zu den Schwächen oben). Ich gehe in einem Folgeartikel darauf ein.
Unter Debian wird die AIDE-Datenbank mit dem Wrapper-Script aideinit (siehe aideinit(8)) initialisiert. Das README unter /usr/share/doc/aide-common/README.Debian.gz warnt bereits davor, dass Debian mit zu restriktiven Einstellungen daherkommt:
Configuring AIDE the Debian way
/usr/share/doc/aide-common/README.Debian.gz
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AIDE’s Debian default configuration takes a very paranoid stance and
is likely to report more changes than you will need to focus your
attention on.
Lassen wir uns überraschen…
$ sudo time aideinit
Running aide --init...
7044.57user 54.97system 2:00:40elapsed 98%CPU (0avgtext+0avgdata 132408maxresident)k
231120192inputs+88320outputs (12major+66397minor)pagefaults 0swaps
Das hat deutlich länger gedauert und endete mit einer deutlich kürzeren Ausgabe. Die erzeugte Datenbank ist jedoch wie bei RHEL im Verzeichnis /var/lib/aide/ zu finden.
:~# ls -l /var/lib/aide/
total 43536
-rw------- 1 root root 22286930 Sep 19 15:13 aide.db
-rw------- 1 _aide _aide 22286930 Sep 19 15:13 aide.db.new
:~# qm start 102
:~# file /var/lib/aide/aide.db.new
/var/lib/aide/aide.db.new: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215
:~# file /var/lib/aide/aide.db
/var/lib/aide/aide.db: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215
Warum die Erstellung so viel länger gedauert hat, weiß ich nicht. Ich habe keine Idee dazu. Auch Debian erzeugt eine gzip-komprimierte Datenbank, auch wenn hier keine Dateiendung darauf hinweist. Ich finde das etwas seltsam, behalte die Standardeinstellung für diese Einführung jedoch bei. Dafür muss die Datei nicht manuell umbenannt werden, da direkt eine Kopie erstellt wird, die als Referenzdatenbank genutzt werden kann.
Im Gegensatz zu RHEL wird unter Debian auch ein Timer namens dailyaidecheck.timer installiert, welcher täglich einen automatischen Check auf Veränderungen durchführt. Allerdings ist es für einen Angreifer ein Leichtes, diese Timer-Unit zu deaktivieren.
Unter Debian und RHEL werden die in der Referenzdatenbank enthaltenen Elemente mit folgendem Befehl auf Änderungen überprüft:
:~# aide --check # unter RHEL
:~# aide --check --config /etc/aide/aide.conf # unter Debian
Ich habe meine Testsysteme ein paar Tage laufen lassen und einen AIDE-Integritätscheck durchgeführt. Hier das Ergebnis für ein RHEL 9 System:
$ sudo aide --check
Start timestamp: 2023-09-26 19:54:59 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-26 19:55:12 +0200 (run time: 0m 13s)
Die Integritätsprüfung in obigen Code-Block führt Änderungen an drei Dateien auf:
summarize_changes in aide.conf(5).Abbruch meiner Tests unter Debian 12 (Bookworm)
Unter Debian hat die Integritätsprüfung über Stunden einen CPU-Kern blockiert. Der Prozess ist in einem futex Syscall hängen geblieben.
Ob es an meinem System liegt oder AIDE unter Debian generell ein Problem hat, kann ich nicht sagen. Ich bin der Sache nicht weiter nachgegangen.
Falls jemand von euch AIDE unter Debian einsetzt und dies liest, freue ich mich, wenn ihr eure Erfahrungen mit mir teilt.
Mit dem Befehl aide --update wird die Datenbank-Integrität geprüft und eine neue Datenbank /var/lib/aide/aide.db.new.gz erzeugt. Die bestehende Referenzdatenbank /var/lib/aide/aide.db.gz wird dabei nicht überschrieben und bleibt zunächst erhalten. Möchte man diese länger aufbewahren, kann man sie umbenennen und bspw. einen Zeitstempel anhängen. Anschließend erzeugt man mit mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz eine neue Referenzdatenbank.
Der folgende Code-Block zeigt die Ausgabe von aide --update unter RHEL 9.
~]# aide --update
Start timestamp: 2023-09-26 20:13:52 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
New AIDE database written to /var/lib/aide/aide.db.new.gz
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3 [0/100]
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
/var/lib/aide/aide.db.new.gz
MD5 : Dgoc1/L5F1UfXPAQRvMdTg==
SHA1 : 23RFwEBIh0kw/3TiiVAh39Fzx0Q=
RMD160 : 1szie2CW1dyLmaKFg01j48Fr+Us=
TIGER : TgdG3zNAOSZH2D9jkyvBves8PtjC0lCR
SHA256 : hjn9vxFxg4KoVwT3YvgU347EhvTCg5ey
lfktpr/OrcA=
SHA512 : x6E3YPa0eILD3nZqDt6N755KSmPRFOz8
lhKD9CimYScSpxyoVxJAVWiozR8KUwkt
Ao7mgy3BgtUA0MZuNMv43w==
End timestamp: 2023-09-26 20:14:03 +0200 (run time: 0m 11s)
~]# ls -l /var/lib/aide
total 6184
-rw-------. 1 root root 3163359 Sep 18 20:50 aide.db.gz
-rw-------. 1 root root 3163384 Sep 26 20:14 aide.db.new.gz
An dieser Stelle endet die Einführung in das Advanced Intrusion Detection Environment (AIDE). Kommt das Ende für euch abrupt? Ist es ein Ende mit Schrecken? Lasst es mich gern wissen.
In dieser Einführung habe ich beschrieben, was Intrusion-Detection-Systeme im Allgemeinen und AIDE im Speziellen sind. Ich bin auf deren Nutzen eingegangen und habe die Schwächen von AIDE als Host-basiertem IDS benannt. Installation, Konfiguration, Integritäts-Check und Aktualisierung der Datenbank wurden erklärt und mit Beispielen belegt.
Was ist nun von AIDE zu halten?
Nun, es ist besser als nichts. Man besitzt damit ein Werkzeug, mit dem sich Änderungen im Dateisystem erkennen lassen. Man muss sich jedoch der Schwächen Host-basierter IDS bewusst sein. Ein Angreifer mit lokalen root-Rechten kann dieses Werkzeug mit wenig Aufwand unschädlich machen bzw. die eigenen Änderungen verschleiern.
Sicher kann man einen Integritätscheck automatisiert alle 5 Minuten durchführen und für Änderungen eine E-Mail-Benachrichtigung einrichten. Doch wirkt dies etwas hemdsärmelig. Daher werde ich dieses Thema in einem späteren Artikel aufgreifen und zeigen, wie man AIDE in einen Automations- bzw. Konfigurations-Management-Prozess einbinden kann.
Seit vielen Jahren bin ich zufriedener Linux Mint Nutzer. Immer wieder stoße ich auf Software die als Snap-Paket angeboten wird und die dich gerne nutzen möchte. Das ist unter Mint allerdings standardmäßig nicht möglich, denn die Installation dieser Pakete wird von Mint aktiv verhindert. Das Mint entschieden hat, dass sie Snaps doof finden, nicht unterstützen [...]
Snap-Pakete unter Linux Mint installieren ist ein Beitrag von .
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 .

Auf dieser und anderen Webseite von mir setze ich manchmal sogenannte Partnerlinks ein. Dabei wird ein im Beitrag erwähntes Produkt direkt mit einem Onlineshop verlinkt. Kauft jemand über diesen Link ein Produkt, erhält der Webseitenbetreiber eine Provision.
Es handelt sich dabei um eine Möglichkeit mit der Webseite Einnahmen zu erzielen, ohne die Seite mit Werbung zu überfrachten, oder sich für sogenannte Sonsored Posts zu verkaufen.
Üblicherweise wird beim Aufruf des Shops über den Partnerlink ein Cookie gesetzt. Dadurch können auch Einkäufe vergütet werden, die erst später getätigt werden. Dementsprechend gibt es schwarze Schafe, die versuchen um jeden Preis diesen Cookie zu setzen.
Dies passiert beispielsweise indem die Seite des Shops in einem Pop-Up oder in einem unsichtbaren Iframe geladen wird. Oder es wird versucht Besucherinnen und Besucher mit mehr oder weniger zweifelhaften Methoden dazu zu bringen, selbst auf den Link zu klicken. Beispielsweise indem man verschleiert dass es sich um einen Partnerlink handelt.
Um die eigene Glaubwürdigkeit nicht zu gefährden und auch um rechtlichen Problemen mit ungekennzeichneter Werbung aus dem Weg zu gehen, ist man also gut beraten, Partnerlinks auch als solche ersichtlich zu machen.
Bisher habe ich Partnerlinks immer manuell mit einem Sternchen markiert. Die Bedeutung des Sternchens habe ich in der Seitenleiste oder im Footer erläutert. Mittlerweile bin ich eher dazu übergegangen Partnerlinks mit dem Icon eines Einkaufswagens zu versehen.
Ich bin mir noch nicht sicher was die bessere Version ist. Ich denke der Einkaufswagen ist unmissverständlich. Das Sternchen funktioniert hingegen immer, auch wenn keine Bilder geladen werden.
Um mir die Arbeit zu erleichtern und um ggf. an einer zentralen Stelle die Art der Kennzeichnung ändern zu können, war ich auf der Suche nach einer Möglichkeit die Kennzeichnung zu automatisieren. Wie sich herausstellt, lässt sich dies mit einer Zeile CSS lösen.
/* Sternchen hinter Amazon Partnerlinks */
a[href*="amazon.de"]:after , a[href*="amzn.to"]:after { content: "*"; }
/* Icon hinter Amazon Partnerlinks */
a[href*="amazon.de"]:after , a[href*="amzn.to"]:after { content: url(path/to/icon.png); }
Das Ganze sieht dann so aus:

Partnerlinks automatisch mit * oder Icon markieren 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.

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.

Der SoC des Raspberry Pi kann bei starker Nutzung sehr heiß werden. Wenn man ihn mit dem Finger berührt kann die Temperatur des Chips doch unangenehm hoch werden.
Ich wollte daher wissen wie hoch die Temperatur des Chips tatsächlich ist und habe nach einer einfachen Möglichkeit gesucht die Temperatur auszulesen.
Erfreulicherweise bringt Raspbian bereits ein Tool mit, mit welchem man die Temperatur und viele weitere Daten des Systems auslesen kann. Das Tool hört auf den Namen vcgencmd. Unter https://github.com/nezticle/RaspberryPi-BuildRoot/wiki/VideoCore-Tools findet man unter der Überschrift “vcgencmd Commands “eine schöne Übersicht über die Möglichkeiten die das Tool bietet.
Die Temperatur lässt sich mit folgendem Befehl auslesen.
vcgencmd measure_temp
Raspberry Pi Temperatur des Prozessors auslesen ist ein Beitrag von techgrube.de.

Auf meinem Desktop habe ich sowohl Linux, als auch Windows installiert. Zwar ist Linux seit vielen Jahren mein Hauptsystem, beim zocken führt für mich aber leider nach wie vor kein Weg an Windows vorbei.
Da ich Windows fast ausschließlich zum spielen verwende und somit keine Daten zwischen der Linux- und der Windowsinstallation austauschen muss, stört es mich dass die Windowspartitionen im Dateimanager unter Linuxmint angezeigt werden. Zugegeben kein großes Problem, aber mich stört es. Abgesehen davon dass einem ständig vor Augen geführt wird dass auf dem Rechner auch eine Windowsinstallation existiert, erhöht es auch die Gefahr versehentlich Dateien auf der Windowspartition zu löschen, oder die Installation versehentlich zu zerstören.
Schön, dass mit einer udev-Regel der Kernel angewiesen werden kann bestimmte Partitionen zu ignorieren. Das schöne an dieser Lösung ist, dass sie Distributionsübergreifend und unabhängig vom verwendeten Dateimanager funktionierten sollte.
Zuerst muss unter /etc/udev/rules.d eine neue Datei mit der Endung .rules angelegt werden. Beispielsweise /etc/udev/rules.d/hiddendevices.rules
In meinem Fall soll /dev/sdf4 ausgeblendet, bzw. ignoriert werden. Dafür wird die soeben angelegte Datei mit folgendem Inhalt befüllt.
KERNEL=="sda4", ENV{UDISKS_IGNORE}="1"
Nach einem Neustart ist die Windowspartition auf dem Dateimanager verschwunden.
Windows Partitionen unter Linux ignorieren ist ein Beitrag von techgrube.de.