Red Hat hat vorgeschlagen, dass Kunden, die über das bevorstehende Lebensende von CentOS 7 besorgt sind, möglicherweise über seinen Insights-Dienst auf Red Hat Enterprise Linux (RHEL) migrieren möchten. Der Support für CentOS Linux 7 endet am 30. Juni 2024. Eine Entscheidung, die Red Hat Ende 2020 getroffen hat. Jetzt ist die IBM-Tochter besorgt über das...
Mit der Veröffentlichung der Version 9.3 geht AlmaLinux seinen kürzlich beschlossenen Weg weg vom 1:1-RHEL-Klon und hin zur Kompatibilität zu Red Hat Enterprise Linux.
AlmaLinux hatte sich, anders als der Verbund aus Suse, Oracle und Rocky Linux dazu entschlossen, nach der Umwidmung von CentOS zum Upstream von Red Hat Enterprise Linux und der erschwerten Zugänge zu den Quellcodes lediglich Kompatibilität mit RHEL anzustreben.
Das biete diverse Vorteile, hatte das AlmaLinux-Team verlautbart. So lasse sich das neue Synergy Repository für alle möglichen Pakete nutzen, die noch nicht in RHEL vorhanden seien, aber von einem Mitglied der AlmaLinux Community für die Gemeinschaft angefordert wurden.
Das nun veröffentliche AlmaLinux 9.3 alias Shamrock Pampas Cat kommt mit dem Kernel 5.14.0-362.8.1.el9_3 und GCC 11.4.1. Das Team verspricht mit AlmaLinux 9.3 mehr Flexibilität und Zuverlässigkeit sowie Sicherheit in hybriden Umgebungen. Mit dieser Version werde zudem die Automatisierung und das Systemmanagement weiter vereinfacht. Verbesserungen an der Web-Konsole würden Verwaltungsaufgaben erleichtern. Darüber hinaus können Benutzer Health Check-Aktionen für Podman-Container und vsock-Geräte in virtuellen Maschinen konfigurieren.
Die Ankündigung verlinkt die diversen Images zum Download.
AlmaLinux verabschiedet sich mit Version 9.3 davon, ein reiner RHEL-Klon zu sein. Das neue Entwicklungsmodell eröffnet auch Perspektiven für die Zukunft.
Die Open Enterprise Linux Association hat ihre Ankündigung umgesetzt und stellt Repositories mit dem Quellcode von RHEL zum Nachbau für jedermann bereit.
AlmaLinux geht einen eigenen Weg, um weiterhin eine mit RHL ABI-kompatible Distribution herausgeben zu können. Trotz Mehrarbeit sehen die Entwickler auch Vorteile.
CIQ, Oracle und SUSE haben vor wenigen Wochen die Gründung der Open Enterprise Linux Association (OpenELA) angekündigt, um RHEL-basierte Distributionen zu unterstützen. Die Entscheidung von Red Hat, den Zugang zu seinem Quellcode einzuschränken, ist eines der wichtigsten und zeitgleich negativen Ereignissen, aus der Open-Source-Welt in diesem Jahr. Diese Nachricht polarisierte und löste einen Sturm an...
CIQ, Oracle und SUSE haben vor wenigen Wochen die Gründung der Open Enterprise Linux Association (OpenELA) angekündigt, um RHEL-basierte Distributionen zu unterstützen. Die Entscheidung von Red Hat, den Zugang zu seinem Quellcode einzuschränken, ist eines der wichtigsten und zeitgleich negativen Ereignissen, aus der Open-Source-Welt in diesem Jahr. Diese Nachricht polarisierte und löste einen Sturm an...
AlmaLinux sucht seinen eigenen Weg aus dem Dilemma, dass Red Hat mit seiner Entscheidung schuf, die Quellen für RHEL nicht mehr öffentlich zugänglich zu machen.
Dass Red Hat angekündigt hat, keinen Quellcode für Downstream-Klone bereitzustellen, damit diese 1:1-Binärkopien von Red Hat Enterprise Linux (RHEL) erstellen können, hat bei den betroffenen AlmaLinux und Rocky Linux und auch Oracle Linux für Aufregung gesorgt. AlmaLinux werde das Ziel, aufgeben, 1:1 kompatibel mit RHEL zu sein, teilt die hinter der Distribution stehende Foundation nun mit.
Man werde aber weiterhin versuchen, eine unternehmenstaugliche, langfristige Linux-Distribution zu entwickeln, die auf die Bedürfnisse der Community abgestimmt und – soweit möglich – ABI-kompatibel mit RHEL sei, berichtet Benny Vasquez, Chair of the Board der AlmaLinux OS Foundation aus der Vorstandsitzung.
Für den typischen Nutzer bedeute dies kaum eine Änderung, schreibt Vasquez weiter. Red Hat-kompatible Anwendungen würden weiterhin auf AlmaLinux OS laufen können, und AlmaLinux-Installationen würden weiterhin rechtzeitig Sicherheitsupdates erhalten. Die bemerkenswerteste potentielle Auswirkung der Änderung sei, dass AlmaLinux nicht mehr an die Linie der “Bug-for-Bug-Kompatibilität” mit Red Hat gebunden sei. Damit könne man Fehlerbehebungen außerhalb von Red Hats Veröffentlichungszyklus akzeptieren. können. Das bedeute zwar, dass einige AlmaLinux OS Nutzer auf Fehler stoßen können, die nicht in Red Hat enthalten sind, auf der anderen Seite könnten sie aber auch von früheren Bugfixes profitieren, die bei Red Hat noch nicht aufgenommen worden seien.
In den Entwicklungs- und Build-Prozessen werde sich einiges ändern. Eines der ersten Dinge seien Kommentare in den Patches einfügen werden, die einen Link zum Ursprung des Patches enthalten. Diese Änderung sei aus mehreren Gründen hilfreich, diene aber insbesondere dem Ziel Transparenz zu schaffen.
Zudem werde man jeden, der Fehler in AlmaLinux OS meldet, darum bitten, das Problem auch in CentOS Stream zu testen und zu replizieren, damit AlmaLInux seine Energie darauf konzentrieren könne, das Problem an der richtigen Stelle zu beheben.
Man wolle auch klarstellen, dass man weiterhin Upstream-Beiträge zu Fedora und CentOS Stream und zum größeren Enterprise-Linux-Ökosystem leisten werde, so wie es seit der Gründung der Foundation geschehen sei.
Das Linux-System BlendOS kann Pakete aus mehreren anderen Distributionen installieren und verwalten. Die neue Version 3 jongliert auch Nix-Pakete und erlaubt nahtlose Updates im Hintergrund.
Bei einer Systemaktualisierung lädt BlendOS v3 zunächst das komplette Basissystem herunter. Da ein Differenzabbild mit Zsync zum Einsatz kommt, soll der Download nur zwischen 10 und 100 MByte umfassen. Beim nächsten Neustart tauscht die Distribution das Root-Dateisystem gegen die aktualisierte Fassung aus. Die vom Nutzer bereits installierten Pakete bleiben dabei unangetastet. BlendOS v3 geht damit den Weg von anderen „unzerstörbaren“ Distributionen wie Fedora Silverblue.
Ab sofort genügt ein Doppelklick auf ein DEB-, RPM-, pkg.tar.zst- der APK-Paket, um die darin enthaltene Software zu installieren. Android-Apps unterstützen allerdings derzeit nur die BlendOS-Varianten mit Plasma- oder Gnome-Desktop.
BlendOS v3 führt mit „user“ und „system“ zwei neue Kommandozeilenbefehle ein. Letztgenanntes dient dazu, Pakete direkt auf dem Host-System zu installieren. Dazu bedient sich „system“ bei den Arch-Linux-Repositories.
Darüber hinaus hilft „system“ bei der Wahl des Desktops: BlendOS v3 unterstützt sieben Desktop-Umgebungen, zwischen denen man schnell mit dem Kommandozeilenbefehl „system track“ wechselt. Die Entwickler rufen zudem Anwender auf, weitere Desktops vorzuschlagen. Dazu müssen sie lediglich eine einfach aufgebaute Konfigurationsdatei erstellen und auf GitHub per Pull-Request einreichen.
Das Tool „user“ ersetzt das alte „blend“-Kommando. Unter anderem kann es Container starten und diese auf ein anderes BlendOS-System verschieben. In Containern erlaubt sind jetzt Arch Linux, AlmaLinux 9, Crystal Linux, Debian, Fedora 38, Kali Linux (in der Rolling-Variante), Neurodebian Bookworm, Rocky Linux, Ubuntu 22.04 und Ubuntu 23.04.
Konfigurationsdateien und Container lassen sich über eine YAML-Datei beschreiben und so auf mehreren Systemen reproduzieren. Das genaue Vorgehen beschreibt ein Eintrag in der Knowledge Base.
Wir sprechen über Red Hat und SUSE und die dazugehörigen Meldungen der letzten Tage und Wochen. Was die jüngsten Entscheidungen bedeuten und welche Reichweite das haben könnte. All das gibts im Podcast.
Im Hause Red Hat scheint man es nicht mehr so gerne zu sehen, dass alle binärkompatiblen Klone von der eigenen Arbeit kostenlos profitieren. Anders als bei CentOS Stream könnten sich Klone wie AlmaLinux oder RockyLinux künftig mit erschwerten Bedingungen konfrontiert sehen. Denn für CentOS Stream kündigen sich Änderungen an, die den Zugirff auf den RHEL-Quellcode...
Der Coup von Red Hat, die Sourcen für RHEL nicht mehr öffentlich bereitzustellen, wird Gewinner und Verlierer haben. Die Verlierer stehen fest, wer wird gewinnen?
Die Einstellung des Git-Repos mit den RHEL-Quellen (siehe auch Ärger für Red-Hat-Klone) hat im Netz erwartungsgemäß für hitzige Diskussionen gesorgt. Ein wenig irritiert haben mich die Kommentare auf lwn.net, eigentlich der seriösesten Linux-News-Quelle: Dort wurden AlmaLinux, Rocky Linux und speziell Oracle von manchen Autoren als »Parasiten« bezeichnet.
Nun ist es unbestritten, dass die Zusammenstellung einer Distribution wie RHEL mit richtig viel Arbeit verbunden ist. Noch viel mehr Mühe bereitet es, das Software-Angebot über 10 Jahre zu warten und auch bei veralteter Software Sicherheits-Patches rückzuportieren. (Python 2.7 ist ein klassisches Beispiel.)
Wenn nun die RHEL-Klone die Quellen einfach kopieren und daraus ein kostenloses Produkt machen (oder, wie im Falle von Oracle, wahlweise kostenlos oder kostenpflichtig mit Support), ist das noch fair? Ist die Bezeichnung »Parasiten« womöglich zutreffend?
Anmerkung: Dieser Artikel wurde zwischen 23.6. und 24.6.2023 mehrfach aktualisiert.
Open Source ist keine Einbahnstrasse
ABER: Linux ist Open-Source-Software. Und das gilt nicht nur für den Kernel, das gilt auch für alle weitere Komponenten: Apache, NGINX, PHP, PostgreSQL, Samba, Postfix, Java, die Bash, der C-Compiler, Python, GRUB usw. Ich könnte hier vermutlich 1000 Open-Source-Komponenten aufzählen, die in RHEL zum Einsatz kommen. Ja, Red Hat arbeitet intensiv an manchen Open-Source-Projekten mit (dem Kernel, systemd, Gnome usw.) und unterstützt viele weitere finanziell. Von anderen Projekten profitiert es, ohne etwas zurückzugeben.
Dazu noch eine Anmerkung aus meiner beruflichen Praxis: Red Hat hat mit Podman ein Konkurrenzprodukt zu Docker geschaffen. Beide Programme stehen unter Open-Source-Lizenzen, beide halten sich an den öffentlichen OCI-Standard und beide funktionieren großartig. In der Presse genießt Docker aber einen zweifelhaften Ruf, weil es versucht, Geld zu verdienen. (Gerade c’t und iX bzw. einige Heise-Autoren sind sehr Docker-kritisch eingestellt.) Übersehen wird dabei: Die Firma Docker betreibt — mit beträchtlichem finanziellem Aufwand — den Docker Hub, die weltweit größte Quelle von Container-Images. Red Hat betreibt zwar auch Registries für ein paar eigene Software-Projekte, aber davon abgesehen gilt: Wer Podman anwendet, bezieht in aller Regel die Images vom Docker Hub (also von docker.io) und verursacht so weitere Kosten für Docker. Red Hat und Podman sind hier also Nutznießer einer Infrastruktur, die von einer anderen Firma geschaffen wurde. (Und ja, das ist Open Source. Das bessere Angebot wird sich langfristig durchsetzen.)
Das Open-Source-Modell funktioniert dann am besten, wenn Einsatz/Aufwand und Nutzen einigermaßen fair verteilt sind. Das Linux-Ökosystem als Ganzes profitiert von erfolgreichen Open-Source-Firmen, und Red Hat war ohne Zweifel die erfolgreichste. (Seit 2018 ist Red Hat Teil von IBM.) Red Hat wiederum profitiert vom riesigen Angebot exzellent gewarteter Open-Source-Software.
Wenn nun umgekehrt kleine Entwickler, Organisationen ohne riesige Finanzmittel, Schulen usw. RHEL-kompatible Software über den Umweg von AlmaLinux, Rocky Linux und Co. kostenfrei nutzen dürfen, erscheint mir das fair. Wiederum profitieren alle, letztlich sogar Red Hat bzw. IBM, weil ihre Software von vielen Anwendern genutzt und getestet wird, weil Studenten die Administration von RHEL-kompatiblen Systemen lernen (und nicht etwas die von Debian oder Ubuntu) usw.
Ohne Not in den Shit Storm
Der Schritt von Red Hat, die Quellen zu RHEL (soweit es GPL-technisch überhaupt möglich ist) zu kappen, wäre verständlich, wenn man sich um die finanzielle Stabilität von Red Hat Sorgen machen müsste. Aber soweit man den Finanzberichten trauen kann, ist das nicht der Fall. IBM hat 2018 Red Hat für 34 Mrd. Dollar gekauft. Damals machte Red Hat 2,9 Mrd Dollar Umsatz und 259 Mil. Dollar Gewinn (Quelle). Seither werden keine eigenen Red-Hat-Zahlen mehr veröffentlicht, aber die Red-Hat-Sparte innerhalb von IBM hat sich offenbar prächtig weiterentwickelt (Quelle). Red Hat kämpft also nicht um sein finanzielles Überleben. Eher ist es wohl die Gier (IBMs?), aus einem gut gehenden Geschäft noch mehr rauszuholen. Auch wenn dabei die Fairness auf der Strecke bleibt.
Und eines muss man schon sagen: Das Timing ist bösartig, ein freundlicheres Wort fällt mir nicht ein. Sowohl die Kommunikation über das CentOS-Ende (Ende 2020) als auch der Stopp der Veröffentlichung der RHEL-Quellen unter git.centos.org (Juni 2023) erfolgte jeweils äußerst kurzfristig mitten im Release-Zyklus. Es ist beabsichtigt, die Anwender von (damals) CentOS und (heute) AlmaLinux, Rocky Linux, Oracle Linux ganz bewusst zu verunsichern und vor den Kopf zu stoßen.
fosspost.org hat die Aktion Red Hat als Schuss ins Knie bezeichnet. Mir erscheint diese Einschätzung zutreffend. Ansible-Entwickler Jeff Geerling fragt: »Are you dumb?« und überlegt, ob er sich überhaupt noch die Mühe machen soll, RHEL zu unterstützen (also z.B. Fehlermeldungen zu bearbeiten, die sich auf RHEL beziehen).
Als Red Hat das CentOS-Projekt in seiner bisherigen Form stoppte, hatte ich Sorgen um die freie Verfügbarkeit von RHEL-Klonen. Dann erlebte das Konzept in Form von AlmaLinux und Rocky Linux eine Wiedergeburt und funktioniert heute besser denn je. Womöglich wird sich dieses Spiel wiederholen. An den Regeln der GNU Public Licence geht auch für Red Hat/IBM kein Weg vorbei. Sicher ist aber schon jetzt: Red Hat (IBM) verliert in der Open-Source-Community gerade massiv Reputation und Gunst.
Im Hause Red Hat scheint man es nicht mehr so gerne zu sehen, dass alle binärkompatiblen Klone von der eigenen Arbeit kostenlos profitieren. Anders als bei CentOS Stream könnten sich Klone wie AlmaLinux oder RockyLinux künftig mit erschwerten Bedingungen konfrontiert sehen. Denn für CentOS Stream kündigen sich Änderungen an, die den Zugirff auf den RHEL-Quellcode...
Red Hat Enterprise Linux (RHEL) besteht aus Open-Source-Code, der öffentlich zugänglich ist. Diesen Umstand nutzen AlmaLinux, Oracle Linux, Rocky Linux und einige weitere Distributionen, um zu RHEL kompatible Distributionen anzubieten. Es ist verständlich, dass dies Red Hat (oder noch mehr IBM?) ein Dorn im Auge ist. Die Klons funktionieren so gut wie das Original, und wer keinen Support braucht oder mit externen Support-Angeboten das Auslangen findet, kann sich viel Geld für Lizenzen sparen.
Nachdem Red Hat schon 2020 das CentOS-Projekt (quasi einen Red-Hat-eigener RHEL-Klon) beendet hat und durch das für den Produktivbetrieb weniger attraktive CentOS Stream ersetzt hat, hat die Firma Ende Juni verkündet, den öffentlichen Zugang auf die RHEL-Quellen unter https://git.centos.org zu beenden. Den RHEL-Quellcode erhalten dann möglicherweise nur noch zahlende Kunden. Das Ganze wurde in bestem Marketing-Sprech als Aufwertung des CentOS-Stream-Projekts verkündet. Die zentrale Aussage lautet: CentOS Stream will now be the sole repository for public RHEL-related source code releases.
Aktuell ist noch unklar, was das für AlmaLinux, Rocky Linux & Co. bedeutet. Grundsätzlich könnten die hinter den Projekt stehenden Organisationen einfach ein RHEL-Abo abschließen. Die Frage ist aber, in welcher Form der Zugang auf den Quellcode dann erfolgt (über SRPM-Pakete?), und wie flott diese Pakete aktualisiert werden. Letztlich könnte die ganze Aktion darauf hinauslaufen, die natürlich weitgehend automatisierten Build-Prozesse der Klone zu behindern oder zu verzögern.
Eine weitere Frage ist, ob irgendwelche EULA-Regeln die Verwendung dieses Codes zum Nachbau anderer Distributionen verbieten können. Das erscheint mir — ohne juristisches Wissen — eher unwahrscheinlich. Es galt immer und es gilt weiterhin die GNU Public License.
Es bleibt also spannend. AlmaLinux verkündet auf Twitter: Don’t panic. Wahrscheinlich eine gute Idee.
Sie wollen WordPress auf einem Server mit RHEL 9 oder einem Klon installieren? Diese Anleitung fasst alle erforderlichen Schritte zusammen. Dabei gehe ich davon aus, dass Sie über eine minimale Installation auf einem Root-Server oder in einer virtuellen Maschine verfügen. Ich habe meine Tests mit AlmaLinux 9 in einer Hetzner-Cloud-Instanz durchgeführt.
DNS-Einträge
Nachdem Sie Ihren Server in Betrieb genommen und sich mit SSH eingeloggt haben, ermitteln Sie die IP-Adressen, unter denen der Server nach außen hin erreichbar ist. Beachten Sie, dass das an sich nützliche Kommando hostname -I nicht in jedem Fall zielführend ist. Wenn Ihre virtuelle Maschine als EC2-Instanz in der Amazon Cloud (AWS) läuft, liefert das Kommando eine Adresse in einem privaten Netzwerk. Diese Adresse gilt aber nur AWS-intern! Sie müssen in der AWS-Konsole ergründen, welche IP-Adresse nach außen gilt.
Ich gehe hier davon aus, dass Ihre WordPress-Installation unter den Adressen example.com und www.example.com zugänglich sein soll und dass Sie IPv4 und IPv6 unterstützen. Dann müssen Sie für Ihre Domain example.com vier DNS-Einträge definieren. Naturgemäß müssen Sie die Beispiel-IP-Adressen durch Ihre echten IP-Adressen ersetzen. Normalerweise dauert es eine Weile (fünf Minuten bis hin zu mehreren Stunden), bis diese DNS-Änderungen wirksam werden.
Typ Name Zieladresse
----- ------- -------------------
A @ 1.2.3.4
A www 1.2.3.4
AAAA @ 2345:1234:1234::1
AAAA www 2345:1234:1234::1
Software-Installation
Auf Ihrem Server müssen Sie nun einen Webserver, einen Datenbank-Server sowie PHP installieren. Ich gehe hier davon aus, dass Sie Apache und MySQL verwenden. Statt Apache wäre natürlich auch NGINX denkbar, statt MySQL auch MariaDB. (Beachten Sie aber, dass die mit RHEL 9 uralte MariaDB-Versionen ausgeliefert werden. Wenn Sie MariaDB einsetzen möchten, sollten Sie den Datenbank-Server aus dem Repository von MariaDB installieren, siehe https://mariadb.org/download/?t=repo-config.)
Bei Cloud-Instanzen entfällt dieser Schritt normalerweise: Die meisten Cloud-Anbieter haben in ihren Instanzen die RHEL-interne Firewall deaktiviert und verwenden stattdessen Firewalls auf Cloud-Ebene, die über die Web-Oberfläche des Cloud-Systems konfiguriert werden muss.
Apache ausprobieren
Um zu testen, dass Ihre Website im Internet zugänglich ist, schreiben Sie »Hello World« in eine Datei im Webverzeichnis /var/www/html:
echo "Hello World" > /var/www/html/index.html
Nun öffnen Sie im Webbrowser auf Ihrem Notebook die Adresse www.example.com oder example.com. Statt »Hello World« wird der Webbrowser eine Sicherheitswarnung anzeigen, weil Ihr Server noch über kein richtiges Zertifikat verfügt. Das ist ein gutes Zeichen: Der Web-Server an sich funktioniert. Ihr Webbrowser erkennt, dass Ihr Server HTTPS unterstützt und will dieses verwenden.
Let’s-Encrypt-Zertifikat für HTTPS einrichten
Es gibt verschiedene Tools, um Zertifikate von Let’s Encrypt zu installieren. Meiner Ansicht nach funktioniert acme.sh am besten. Zur Installation führen Sie die folgenden Kommandos aus:
dnf install tar socat
curl https://get.acme.sh -o acme-setup
less acme-setup (kurze Kontrolle)
sh acme-setup email=admin@example.com
An die E-Mail-Adresse werden Warnungen verschickt, sollte in Zukunft die automatische Erneuerung von Zertifikaten nicht funktionieren. Damit Sie das frisch installierte Script verwenden können, müssen Sie sich aus- und neu einloggen. Jetzt fordern Sie das gewünschte Zertifikat an, wobei Sie natürlich example.com wieder durch Ihren tatsächlichen Hostnamen ersetzen:
acme.sh --issue -d --server letsencrypt example.com -d www.example.com -w /var/www/html
Your cert is in
/root/.acme.sh/example.com/example.com.cer
...
acme.sh speichert das Zertifikat also vorerst in Ihrem Heimatverzeichnis. Sie könnten die Zertifikatsdateien einfach in das /etc-Verzeichnis kopieren, aber das wäre keine gute Idee: Das Zertifikat muss regelmäßig erneuert werden, und acme.sh muss wissen, wohin die neuen Zertifikate dann kopiert werden müssen. Daher weisen Sie acme.sh an, die Zertifikate in das Verzeichnis /etc/mycert zu kopieren:
acme.sh merkt sich den Installationsort und berücksichtigt ihn in Zukunft automatisch bei Updates der Zertifikate. Für diese Updates ist das Kommando acme.sh --cron zuständig, das automatisch einmal täglich durch /var/spool/cron/root ausgeführt wird.
Die Zertifikatsdateien sind nun im /etc-Verzeichnis, aber Apache weiß noch nichts davon. Sie müssen also in der Webserver-Konfiguration angeben, wo sich die Verzeichnisse befinden. Dazu verändern Sie zwei Zeilen in ssl.conf:
# in /etc/httpd./conf.d/ssl.conf zwei Zeilen ändern
SSLCertificateFile /etc/mycert/example.com.fullchain
SSLCertificateKeyFile /etc/mycert/example.com.key
Jetzt starten Sie Apache neu:
systemctl restart httpd
Danach versuchen Sie nochmals, die Seite example.com im Webbrowser zu öffnen. Jetzt sollte alles klappen, d.h. »Hello World« wird verschlüsselt vom Webserver zum Webbrowser übertragen und der Webbrowser ist mit dem Zertifikat zufrieden.
MySQL absichern
Unbegreiflicherweise ist die MySQL-Installation von RHEL 9 und all seinen Klonen offen wie ein Scheunentor. Jeder Benutzer, der sich auf dem Linux-System anmelden kann, erhält mit mysql -u root ohne Passwort Root-Rechte für MySQL. Abhilfe schafft das Kommando mysql_secure_installation. Die folgenden Zeilen fassen stark gekürzt die wichtigsten Eingaben zusammen:
mysql_secure_installation
Would you like to setup VALIDATE PASSWORD component? n
New password: xxxxxx
Re-enter new password: xxxxxx
Remove anonymous users? y
Disallow root login remotely? y
Remove test database and access to it? y
Reload privilege tables now? y
MySQL-Datenbank einrichten
WordPress braucht eine Datenbank, in der Ihre Einstellungen, den HTML-Code Ihrer Blog-Beiträge, die Kommentare anderer Benutzer usw. speichern kann. Diese Datenbank sowie ein Datenbank-Nutzer, der darauf zugreifen darf, wird jetzt eingerichtet. Ich habe für die Datenbank und den Benutzer jeweils den Namen wp verwendet, aber natürlich sind Sie bei der Namenswahl frei.
mysql -u root -p
Password: xxxxxxx (gleiches Passwort wie bei mysql_secure_installation)
mysql> CREATE DATABASE wp;
mysql> CREATE USER wp@localhost IDENTIFIED BY 'strengGeheim';
mysql> GRANT ALL ON wp.* TO wp@localhost;
mysql> exit
WordPress-Dateien installieren
WordPress steht nicht als Paket zur Verfügung, sondern muss manuell installiert werden. Dazu laden Sie die Dateien herunter, packen Sie aus und weisen Ihnen die richtigen Zugriffsrechte samt SELinux-Kontext zu.
cd /var/www/html
rm index.html
wget https://de.wordpress.org/latest-de_DE.tar.gz
tar xzf latest-de_DE.tar.gz
chown -R apache wordpress
chcon -R system_u:object_r:httpd_sys_content_rw_t:s0 wordpress
rm latest-de_DE.tar.gz
Mit der Installation der WordPress-Dateien in /var/www/html/wordpress soll dieses Verzeichnis der Startpunkt für die Dateien in Apache sein. Daher mussdie Variable DocumentRoot von /var/www/html auf /var/www/html/wordpress umgestellt werden. Bei der Gelegenheit können Sie auch gleich den Server-Namen einstellen:
# in /etc/httpd/conf/httpd.conf zwei Zeilen ändern
DocumentRoot "/var/www/html/wordpress"
ServerName example.com
Damit die Einstellungen wirksam werden, ist das folgende Kommando notwendig:
systemctl reload httpd
WordPress konfigurieren
Damit ist es endlich soweit. Sie können nun mit der WordPress-Konfiguration beginnen. Dazu öffnen Sie die Seite example.com/wp-admin/setup-config.php. Im ersten Schritt müssen Sie den Namen der Datenbank, den Datenbank-User sowie dessen Passwort angeben.
Konfiguration des Datenbankzugriffs für WordPress
Im nächsten Schritt legen Sie den Namen Ihrer Website sowie einen Benutzernamen und ein Passwort für die WordPress-Administration fest. Mit diesen Daten können Sie sich danach bei Ihrer neuen Seite anmelden und die mit Inhalten füllen.
Fine Tuning
Wenn alles funktioniert, sollten Sie sich noch um die folgenden Details kümmern:
Die AlmaLinux OS Foundation hat das zu Red Hat Enterprise Linux 9.2 binärkompatible AlmaLinux OS 9.2 mit dem Codenamen “Turquoise Kodkod” veröffentlicht.
Die neue Version enthalte Sicherheitsaktualisierungen wie die Systemrolle realmd, ein SCAP-Profil und Ansible-Inhalte für erweiterte Systemprüfungen, die die Verwaltung von Sicherheit und Compliance vereinfachen, heißt es in der Ankündigung. Erweiterungen der Webkonsole und neue Systemrollen sollen zudem die Automatisierung und Standardisierung von Systemen erleichtern. Bei Containern stellen die Anbieter eine einfachere Entwicklung und Verwaltung von containerisierten Deployments in Aussicht.
Zu den Modul-Updates zählen Python 3.11, Nginx 1.22 und PostgreSQL 15. Toolchain-Updates gibt es in Form von GCC 11.3.1, Glibc 2.34 und Binutils 2.35.2.
Neu vorgestellt hat die AlmaLinux OS Foundation das Projekt Elevate, das ein Upgrade zwischen den Hauptversionen der RHEL-basierten Distributionen von 7.x auf 8.x und von 8.x auf 9.x ermöglichen soll. Es kombiniere das Leapp-Framework von Red Hat mit einer von der Community erstellten Bibliothek und einem Service für Migrationsmetadaten.
Die Enterprise-Distribution AlmaLinux 9.2 ist binär-kompatibel mit Red Hats RHEL 9.2. Neu vorgestellt wird das ELevate Projekt zur Migration zwischen RHEL-Derivaten.
AlmaLinux OS schließt die Lücke, die der Wegfall von CentOS als stabiler Nachbau von Red Hat Enterprise Linux (RHEL) aufgetan hat. Jetzt ist AlmaLinux OS 9.1 erschienen, das auf das jüngst veröffentlichte RHEL 9.1 aufbaut.
Das unter dem Codename Lime Lynx veröffentlichte AlmaLinus OS 9.1 nutzt den Quellcode von RHEL 9.1 und baut auf den Kernel 5.14.0-162.6.1.el9_1. Das Projekt hat mit PHP 8.1, Ruby 3.1 und Node.js 18 neue Modul-Streams eingeführt. Den Modul-Stream von Apache haben die Macher auf die Apache HTTP Server Version 2.4.53 aktualisiert.
Zu den Kompiler-Updates zählen das GCC Toolset 12, das LLVM Toolset 14.0.6, das Rust Toolset 1.62 und das Go Toolset 1.18. AlmaLinux unterstützt die Plattformen x86_64, Aarch64, PPC64le und S390x. Die Release Notes zählen die Weiteren Änderungen und Neuerungen auf.
Anmelden
Red Hat hat vorgeschlagen, dass Kunden, die über das bevorstehende Lebensende von CentOS 7 besorgt sind, möglicherweise über seinen Insights-Dienst auf Red Hat Enterprise Linux (RHEL) migrieren möchten. Der Support für CentOS Linux 7 endet am 30. Juni 2024. Eine Entscheidung, die Red Hat Ende 2020 getroffen hat. Jetzt ist die IBM-Tochter besorgt über das...
