Der langjährige Nginx-Entwickler Maxim Dounin hat mit Freenginx einen Fork des populären freien Webservers Nginx angekündigt. Dounin zeigt sich unzufrieden mit dem Nginx-Eigner F5.
Nachdem nun unsere Community-Cloud endlich wieder lief, habe ich versucht innerhalb der Gemeinschaft unseren Cloud-Speicher etwas zu bewerben. Bei einigen Nutzern war dieser inzwischen etwas in Vergessenheit geraten, samt den nötigen Passwörtern.
Es kommt natürlich immer wieder vor, dass Zugangsdaten nicht richtig verwahrt werden oder gar ganze Passwörter nicht mehr auffindbar sind. Mehrfache fehlerhafte Eingaben können jedoch, wie im Fall der Nextcloud, dazu führen, dass Nutzer-IPs ausgesperrt bzw. blockiert werden. Diesen Schutz nennt man Bruteforce-Schutz.
Nextcloud bietet einen eingebauten Schutzmechanismus gegen Bruteforce-Angriffe, der dazu dient, das System vor potenziellen Angreifern zu sichern, die wiederholt verschiedene Passwörter ausprobieren. Diese Sicherheitsvorkehrung ist standardmäßig in Nextcloud aktiviert und trägt dazu bei, die Integrität der Daten zu wahren und unautorisierten Zugriff auf das System zu verhindern.
Die Funktionsweise des Bruteforce-Schutzes wird besonders deutlich, wenn man versucht, sich auf der Anmeldeseite mit einem ungültigen Benutzernamen und/oder Passwort anzumelden. Bei den ersten Versuchen mag es unauffällig erscheinen, doch nach mehreren wiederholten Fehlversuchen wird man feststellen, dass die Überprüfung des Logins mit zunehmender Häufigkeit länger dauert. An dieser Stelle tritt der Bruteforce-Schutz in Kraft, der eine maximale Verzögerung von 25 Sekunden für jeden Anmeldeversuch einführt. Nach erfolgreicher Anmeldung werden sämtliche fehlgeschlagenen Versuche automatisch gelöscht. Wichtig zu erwähnen ist, dass ein ordnungsgemäß authentifizierter Benutzer von dieser Verzögerung nicht mehr beeinträchtigt wird, was die Sicherheit des Systems und die Benutzerfreundlichkeit gleichermaßen gewährleistet.
Hat nun einmal die Falle zugeschnappt und ein Anwender wurde aus der Nextcloud ausgesperrt, so kann sich das Problem über die Zeit von selbst lösen. Es gibt aber auch die Möglichkeit die Datenbank entsprechend zurückzusetzen.
Zuerst wechselt man in das Nextcloud-Verzeichnis. Danach werden über den folgenden OCC-Befehl die Bruteforce-Einträge der Datenbank resetet.
cd /var/www/html/nextcloud/ sudo -u www-data php occ security:bruteforce:reset 0.0.0.0
Neue Bruteforce-Attacken werden natürlich danach wieder geloggt und verdächtige IPs ausgesperrt.
Viel Erfolg!
Heute möchte ich noch einmal ein Thema aus der Mottenkiste holen, welches ja eigentlich schon abgehakt sein sollte. Es geht um das Upgrade von Raspbian 10 auf das Raspberry Pi OS 11.
Anlass des Ganzen ist unsere Community-Cloud mit über 25 Nutzern. Diese Cloud wurde vor über fünfeinhalb Jahren zum Zwecke des Datenteilens ins Leben gerufen. Durch einen bedingten öfteren Standortwechsel verblieb das System auf einem Softwarestand von vor über zwei Jahren. Jetzt im neuen Zuhause stand dadurch ein gründlicher Tapetenwechsel an. D.h., dass im ersten Schritt das Betriebssystem auf Raspberry Pi OS 11 Bullsleye angehoben werden musste, bevor die Nextcloud von Version 22 auf 27 aktualisiert wurde. Weiterhin musste parallel PHP 7.3 auf Version 8.1 gezogen werden, um wieder in sicheres Fahrwasser zu gelangen. Bei der Hardware handelt es sich um einen Raspberry Pi 3 Model B. Auch dieses Gerät soll im laufe des Jahres noch ein Refresh erhalten.
Nun zum Upgrade auf das erwähnte Raspberry Pi OS 11.
Hilfreich bei der Installation war die Anleitung von linuxnews.de, die ich abschließend noch um zwei Punkte ergänzen musste. Hierbei konnte ich mich noch an mein erstes Upgrade dieser Art erinnern, dass es zu Unverträglichkeiten mit dem Desktop kam. Dieses Problem wird ganz am Ende des Artikels behandelt.
Zuerst wurde ein vollständiges Upgrade auf die aktuellste Version Raspbian 10 durchgeführt.
sudo apt update sudo apt full-upgrade sudo rpi-update
Danach wurden die Quellen auf Bullseye angepasst.
sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/raspi.list
Im Anschluss folgte ein Update der Quellen und die erforderliche Installation von gcc-8.
sudo apt update && sudo apt install libgcc-8-dev gcc-8-base sudo apt full-upgrade sudo apt -f install
Danach wurden unnötige Pakete und verbliebene heruntergeladene Pakete entfernt.
sudo apt autoremove sudo apt clean
Nun mussten noch die Kernelbased Mode-Setting (KMS) in der /boot/config.txt angepasst werden. Hierzu wurden folgende zwei Befehle ausgeführt:
sudo sed -i 's/dtoverlay=vc4-fkms-v3d/#dtoverlay=vc4-fkms-v3d/g' /boot/config.txt sudo sed -i 's/\[all\]/\[all\]\ndtoverlay=vc4-kms-v3d/' /boot/config.txt
Nach dem Reboot mit angeschlossenem Monitor fiel auf, dass sich das Programm Parcellite in der Menüleiste verewigt hatte. Parcellite war vor dem Systemupgrade auf Raspberry Pi OS 11 Bullseye nicht an Bord. Aus diesem Grund konnte es auch ohne Bedenken gelöscht werden.
sudo apt remove parcellite
Weiterhin fiel auf, dass die ganze Menüleiste des Desktops etwas vermurkst aussah. Diese wurde auf die Grundeinstellungen mit
cd ~/ sudo rm -rf .cache
zurückgesetzt.
Nach einem erneuten Reboot läuft Raspberry Pi OS 11 wie gewünscht.
sudo reboot
Um unsere Community-Cloud wieder sicher zu machen, war ein wenig Wochenendarbeit nötig. Die so investierte Zeit hat sich aber durchaus gelohnt. Im nächsten Schritt erfolgt dann der Tausch des Raspberry Pi und ein Wechsel der Daten-SSD gegen ein größeres Modell.
Dieser Beitrag baut auf dem Artikel „PHP7.4-fpm auf PHP8.1-fpm für Nextcloud“ auf.
Im Januar 2023 hatte ich erklärt, wie ich mein Raspberry Pi OS 11 (basierend auf Debian 11 Bullseye), durch Einbinden einer Fremdquelle, von PHP7.4-fpm auf PHP8.1-fpm aktualisiert habe. Warum ich zu diesem Zeitpunkt die Version 8.1 installiert habe, ist recht einfach zu beantworten. Die aktuelle Version Nextcloud 25 war noch nicht kompatibel zu PHP 8.2. Erst mit Nextcloud 26 war ein Upgrade möglich.
Nun habe ich mich nach der Aktualisierung auf Nextcloud 28 entschieden auf PHP 8.2 zu wechseln. Da ich den FastCGI-Prozessmanager FPM bevorzuge, unterscheidet sich das Upgrade etwas von einer herkömmlichen PHP-Installation.
Zuerst wird das System auf den aktuellen Stand gebracht.
sudo apt update && sudo apt upgrade -y
Ein Check zeigt, welche PHP-Version momentan aktiv ist.
php -v
Hier die Ausgabe:
PHP 8.1.27 (cli) (built: Dec 21 2023 20:17:59) (NTS) Copyright (c) The PHP Group Zend Engine v4.1.27, Copyright (c) Zend Technologies with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies
Jetzt werden alle benötigten Pakete nachinstalliert (auch das von Nextcloud 28 verlangte bz2 und der von mir eingesetzte Redis-Server).
sudo apt install php8.2 php8.2-mbstring php8.2-gd php8.2-curl php8.2-imagick php8.2-intl php8.2-bcmath php8.2-gmp php8.2-mysql php8.2-zip php8.2-xml php8.2-apcu libapache2-mod-php8.2 php8.2-bz2 php8.2-redis
Nun wird via CLI die PHP-Version von 8.1 auf 8.2 mit
sudo update-alternatives --config php
umgestellt.
sudo update-alternatives --config php Es gibt 5 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen). Auswahl Pfad Priorität Status ------------------------------------------------------------ 0 /usr/bin/php.default 100 automatischer Modus 1 /usr/bin/php.default 100 manueller Modus 2 /usr/bin/php7.4 74 manueller Modus * 3 /usr/bin/php8.1 81 manueller Modus 4 /usr/bin/php8.2 82 manueller Modus 5 /usr/bin/php8.3 83 manueller Modus
sudo update-alternatives --config php Es gibt 5 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen). Auswahl Pfad Priorität Status ------------------------------------------------------------ 0 /usr/bin/php.default 100 automatischer Modus 1 /usr/bin/php.default 100 manueller Modus 2 /usr/bin/php7.4 74 manueller Modus 3 /usr/bin/php8.1 81 manueller Modus * 4 /usr/bin/php8.2 82 manueller Modus 5 /usr/bin/php8.3 83 manueller Modus
Ein abschließender Check zeigt die aktuelle Version.
php -v
PHP 8.2.14 (cli) (built: Dec 21 2023 20:18:00) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.14, Copyright (c) Zend Technologies with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies
Ist die Ausgabe korrekt, kann PHP8.1-fpm deaktiviert, PHP8.2-fpm installiert und aktiviert werden.
sudo a2disconf php8.1-fpm sudo apt install php8.2-fpm sudo a2enconf php8.2-fpm
Der Restart des Webservers führt nun die Änderungen aus.
sudo service apache2 restart
Da in der Nextcloud nun wieder die bekannten Fehlermeldungen auftauchen, heißt es, diese schrittweise abzuarbeiten. Dazu wird die neue php.ini geöffnet
sudo nano /etc/php/8.2/fpm/php.ini
und die Werte für memory_limit sowie session_lifetime wie empfohlen angepasst.
memory_limit = 512M session.gc_maxlifetime = 3600
Der Block
opcache.enable=1 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=10000 opcache.memory_consumption=256 opcache.save_comments=1 opcache.revalidate_freq=1
für den Zwischenspeicher OPchache wird ans Ende der php.ini gesetzt.
Zur Optimierung von PHP8.2-fpm werden speziell für das Modell Raspberry Pi 4 mit 4GB RAM in der Datei www.conf mit
sudo nano /etc/php/8.2/fpm/pool.d/www.conf
folgende Werte von
pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3
auf
pm = dynamic pm.max_children = 120 pm.start_servers = 12 pm.min_spare_servers = 6 pm.max_spare_servers = 18
angepasst und der Dienst neu gestartet.
sudo service php8.2-fpm restart
Danach muss in der apcu.ini das Command Line Interface des PHP Cache noch aktiviert werden, indem
sudo nano /etc/php/8.2/mods-available/apcu.ini
folgende Zeile am Ende eingetragen wird.
apc.enable_cli=1
Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet.
sudo service apache2 restart
Die Umstellung bringt zwar im Moment keine erkennbaren Vorteile, jedoch verschafft es wieder ein wenig Zeit und senkt den Druck das eigentliche Raspberry Pi OS 11 Bullseye durch die aktuelle Version 12 Bookworm zu ersetzen.
PHP-FPM (FastCGI Process Manager) ist eine leistungsstarke Erweiterung für den PHP-Interpreter, die die Ausführung von PHP-Skripten optimiert und verbessert. Entwickelt, um die Skalierbarkeit von PHP-basierten Webanwendungen zu erhöhen, spielt PHP-FPM eine entscheidende Rolle in modernen Webserver-Umgebungen.
Traditionell wurde PHP als Modul für Webserver wie Apache bereitgestellt. Dieser Ansatz hatte jedoch seine Einschränkungen, insbesondere wenn es um die Verwaltung von Ressourcen und die Skalierung von Webanwendungen ging. PHP-FPM wurde als Lösung für diese Herausforderungen entwickelt, indem es die FastCGI-Protokollspezifikation implementiert und PHP-Skripte als separate Prozesse ausführt.
PHP-FPM ermöglicht eine effiziente Verwaltung von Ressourcen, indem es separate Prozesse für jede Anforderung erstellt. Dadurch wird der Arbeitsspeicher besser genutzt und die Gesamtleistung der Webanwendung verbessert.
Durch die Nutzung von PHP-FPM können Webentwickler ihre Anwendungen leichter skalieren, da sie die Anzahl der gleichzeitig ausgeführten PHP-Prozesse steuern können. Dies ist besonders wichtig in Umgebungen mit starkem Datenverkehr.
Jede PHP-Anwendung wird in ihrem eigenen Prozess isoliert, wodurch Konflikte zwischen verschiedenen Anwendungen vermieden werden. Dies trägt zur Stabilität des Gesamtsystems bei.
PHP-FPM bietet eine umfangreiche Konfiguration, die es Administratoren ermöglicht, Parameter wie Prozessprioritäten, Anzahl der Kinderprozesse und andere Einstellungen zu optimieren.
Die Konfiguration von PHP-FPM erfolgt über die php-fpm.conf-Datei und optionale Pool-Konfigurationsdateien. Administratoren können Parameter anpassen, um die Leistung und Ressourcennutzung nach den Anforderungen ihrer Anwendung zu optimieren.
Die Integration von PHP-FPM in Webserver wie Nginx oder Apache erfolgt durch die Konfiguration von FastCGI-Servern. Dies ermöglicht eine reibungslose Kommunikation zwischen dem Webserver und PHP-FPM.
PHP-FPM hat sich als wesentliches Werkzeug für die Verwaltung von PHP-Anwendungen in produktiven Umgebungen etabliert. Durch die Bereitstellung von effizienter Ressourcennutzung, Skalierbarkeit und Anwendungsisolierung spielt PHP-FPM eine Schlüsselrolle bei der Gewährleistung der Leistungsfähigkeit von PHP-Webanwendungen. Bei der Entwicklung und Verwaltung von Webanwendungen ist es wichtig, die Vorteile von PHP-FPM zu verstehen und richtig zu konfigurieren, um eine optimale Leistung zu gewährleisten.
Weiter geht es mit der Artikelserie "Host it yourself". Diesmal geht es um die Organisation des Community-Projekts
In diesem Artikel stelle ich euch die RHEL System Role nbde_server vor, mit welcher sich Tang-Server für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese zuerst:
Im folgenden Text verwende ich die Begriffe NBDE-Server und Tang-Server synonym. Bitte lasst euch dadurch nicht verwirren.
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
Anmelden
ansible-corerhel-system-rolesDie Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_server/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_server/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
Ich möchte mit dieser Rolle Folgendes erreichen:
enforcingDas Playbook ist recht übersichtlich. tang bezeichnet eine Gruppe aus meinem Ansible-Inventory, welche die Systeme enthält, die ich als NBDE-Server konfigurieren möchte.
---
- name: Manage nbde server with selinux and firewall
hosts: tang
vars:
nbde_server_manage_firewall: true
nbde_server_manage_selinux: true
roles:
- rhel-system-roles.nbde_serverNach der Anwendung der Rolle lauscht der Tang-Service auf Port 80/tcp der Zielsysteme und ist aus dem Netzwerk erreichbar.
Leider läuft es dieses Mal nicht ganz so rund wie üblich. Der Task [redhat.rhel_system_roles.selinux : Set an SELinux label on a port] schlägt auf dem RHEL 8 Host mit folgender Fehlermeldung fehl: „Failed to import the required Python library (libselinux-python)“
Das Problem und die Lösung beschreibt Red Hat in dem Solution Article: Ansible playbook fails with libselinux-python aren’t installed on RHEL8 (Login required)
Diesmal lief es nicht ganz so reibungslos wie gewohnt.
Letztendlich konnten die beiden NBDE-Server dennoch schneller konfiguriert werden, als wäre ich der manuellen Prozedur in Chapter 12. Configuring automated unlocking of encrypted volumes using policy-based decryption gefolgt.
Die Server sind damit aufgesetzt, nächste Woche beschreibe ich, wie die Clients konfiguriert werden.
Bereits Mitte Juli wurde die Sicherheitslücke in den Microsoft LNK Dateien bestätigt. LNK Dateien kennt jeder und benutzt jeder. Eine einfache Verknüpfung auf dem Desktop ist z.B. eine .lnk Datei. Bei der neuen Sicherheitslücke genügt es, auf so eine Datei zu klicken, um sich Schadsoftware einzufangen. Microsoft hat jedoch, wie angekündigt, nun einen Patch veröffentlicht, der diese Lücke schließt. Jeder sollte also den Patch manuell herunterladen oder das MS Update anwerfen, um sein System zu aktualisieren. Auf der Microsoft Seite Security Bulletin MS10-046 findet ihr den passenden Patch für eure Windows Versionen. Der Patch ist für die Systeme Windows XP, Vista, Windows 7 sowie Windows Server 2003 und 2008 zu haben
Ein weiterer dedizierter Server wurde gestern zur Verstärkung der vier bestehenden Proxmox VE Server hinzugezogen. Ziel ist es, die immer weiter wachsenden adminForge Services zu entlasten, um euch eine gleichbleibende Performance bieten zu können....
by adminForge.
Wer von euch die Proxmox-no-Subscription Repo’s nutzt und das Popup mit dem Hinweis auf die Subscription einen nervt, kann diese mit nur einer Befehlszeile ausblenden. Hinweis Fenster ausblenden: [crayon-65501bf7aa511754117157/] Danach das jeweilige Proxmox Webinterface...
by adminForge.
IBM baut die Integration mit der Konzerntochter Red Hat aus. Neue Open Source Lösungen sind jetzt auf der IBM Power Plattform verfügbar.
Kodi dürfte den meisten von euch bekannt sein. Einige von euch setzen Kodi wahrscheinlich ebenfalls als Mediacenter ein. Wenn man mehrere Kodi-Installationen im Netzwerk hat ist es sinnvoll eine zentrale Datenbank für Kodi im...
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.
