Red Hat Enterprise Linux AS 4 Release Notes

Die Version von glibc, die mit Red Hat Enterprise Linux 4 ausgeliefert wird, führt zusätzliche interne Sanity-Checks durch, um Beschädigung von Daten zu verhindern und so früh wie möglich ausfindig zu machen. Sollte eine Beschädigung ausfindig gemacht werden, so wird standardmäßig eine Nachricht wie die Folgende für Standardfehler angezeigt (oder via syslog protokolliert, wenn stderr nicht offen ist):

*** glibc detected *** double free or corruption: 0x0937d008 ***

Standardmäßig wird auch das Programm, das diesen Fehler hervorgerufen hat, gewaltsam beendet. Dies (und ob eine Fehlermeldung generiert werden soll oder nicht) kann jedoch mittels der MALLOC_CHECK_-Umgebungsvariable kontrolliert werden. Die folgenden Einstellungen werden unterstützt:

Sollten Sie bereits ein Programm eines Dritten besitzen, welches diese Überprüfung von Beschädigungen auslöst und eine entsprechende Nachricht anzeigt, sollten Sie einen Fehlerbericht beim Verkäufer dieser Applikation einreichen, da dies auf einen gravierenden Fehler hinweist.

Red Hat Enterprise Linux 4 enthält einen neuen Kernel, der als hugemem-Kernel bekannt ist. Dieser Kernel unterstützt 4 GB/Prozess Userspace (im Vergleich zu den 3 GB anderer Kernel) und 4 GB Direct-Kernel-Space. Mit diesem Kernel läuft Red Hat Enterprise Linux auf Systemen mit bis zu 64 GB Hauptspeicher. Der hugemem-Kernel ist erforderlich, um bei Systemkonfigurationen mit mehr als 16 GB den gesamten Speicher zu verwenden. Der hugemem-Kernel kann auch für Konfigurationen, die mit weniger Speicher ablaufen von Vorteil sein (wenn beispielsweise Applikationen ablaufen, die vom größeren Userspace pro Prozess profitieren könnten).

Um den hugemen-Kernel zu installieren, geben Sie den folgenden Befehl ein, während Sie als Root eingeloggt sind:

rpm -ivh <kernel-rpm>

            

(wobei <kernel-rpm> den Namen der RPM-Datei des hugemem-Kernels darstellt — z. B. kernel-hugemem-2.6.9-1.648_EL.i686.rpm.)

Nachdem die Installation abgeschlossen ist, starten Sie Ihr System neu und wählen Sie den neu installierten hugemem-Kernel. Nachdem Sie Ihr System unter dem hugemem-Kernel erfolgreich getestet haben, sollten Sie /boot/grub/grub.conf ändern, um in den hugemem-Kernel als Vorgabe zu booten.

Obwohl Red Hat Enterprise Linux 4 Unterstützung für rawio beinhaltet, stellt diese ab sofort eine nicht mehr verwendete Schnittstelle dar. Wenn Ihre Applikation Geräte-Zugang mittels dieser Schnittstelle ausführt, so rät Ihnen Red Hat an, Ihre Applikation dahingehend zu modifizieren, dass diese das Blockgerät mit dem O_DIRECT-Flag öffnet. Die rawio-Schnittstelle wird während der Lebensdauer von Red Hat Enterprise Linux 4 weiterexistieren, ist jedoch ein Kandidat für die Entfernung im Rahmen zukünftiger Releases.

Asynchrones I/O (AIO) auf Dateisystemen wird derzeit nur in O_DIRECT oder nicht-gepuffertem Modus unterstützt. Beachten Sie bitte auch, dass die asynchrone Poll-Schnittstelle nicht mehr länger vorhanden ist und dass AIO auf Pipes nicht mehr länger unterstützt wird.

Das Sound-Subsystem basiert nun auf ALSA. Die OSS-Module sind nicht länger verfügbar.

Systemumgebungen, welche die "hugepage"-Funktionalität des Kernels benutzen, sollten davon Kenntnis besitzen, dass der Name des /proc/-Eintrags, der dieses Feature kontrolliert, sich zwischen Red Hat Enterprise Linux 3 und Red Hat Enterprise Linux 4 geändert hat:

Der mit Red Hat Enterprise Linux 4 ausgelieferte Kernel beinhaltet nunmehr Unterstützung für Enhanced Disk Device (EDD) Polling, wobei Informationen über bootfähige Disk-Geräte direkt vom Disk-Controller-BIOS abgefragt werden und als Eintrag im /sys-Dateisystem gespeichert werden.

Zwei wesentliche Kommandozeilenoptionen für den Kernel in Zusammenhang mit EDD wurden außerdem hinzugefügt:

Das erste Release von Red Hat Enterprise Linux 4 beinhaltet keine Unterstützung von USB-Festplatten. Andere USB-Speichergeräte, wie z. B. Flash-Medien, CD-ROM- und DVD-ROM-Geräte werden derzeit unterstützt.

Der Red Hat Enterprise Linux 4 Kernel beinhaltet den neuen megaraid_mbox-Treiber von LSI Logic, welcher den megaraid-Treiber ersetzt. Der megaraid_mbox-Treiber besitzt ein verbessertes Design, ist kompatibel mit dem 2.6 Kernel und beinhaltet Unterstützung für die neueste Hardware. Es kann jedoch sein, dass etwas ältere Hardware, die vom megaraid-Treiber unterstützt wurde, von megaraid_mbox nicht mehr unterstützt wird.

Adapter mit folgenden PCI Hersteller-ID und Geräte-ID Paaren werden nicht vom megaraid_mbox-Treiber unterstützt:

vendor, device

0x101E, 0x9010
0x101E, 0x9060
0x8086, 0x1960

Der Befehl lspci -n kann dazu benutzt werden, um die IDs für Adapter anzeigen zu lassen, die in einem bestimmten Rechner installiert sind. Produkte mit diesen IDs sind (nicht nur ausschließlich) unter folgenden Model-Namen bekannt:

Sowohl Dell, als auch LSI Logic haben signalisiert, diese Modelle im 2.6 Kernel nicht mehr länger zu unterstützen. Deshalb werden diese Adapter nicht in Red Hat Enterprise Linux 4 unterstützt.

Das ursprüngliche Red Hat Enterprise Linux 4-Release beinhaltet keine SCSI Software-Initiator- oder Target-Unterstützung. Unterstützung für iSCSI wird derzeit zur Aufnahme in einem der zukünftigen Red Hat Enterprise Linux 4-Updates evaluiert.

Der Emulex LightPulse Fibre Channel Treiber (lpfc) unterliegt derzeit einem öffentlichen Review für eine mögliche Einbindung in den Linux 2.6 Kernel. Er ist in Red Hat Enterprise Linux 4 für Testzwecke enthalten. Änderungen in Bezug auf den Treiber sind zu erwarten. Sollten Probleme auftreten oder der Treiber aus irgendwelchen Gründen nicht mehr länger zur Einbindung in den Linux 2.6 Kernel vorgesehen sein, so kann es sein, dass der Treiber vom entgültigen Red Hat Enterprise Linux-Release entfernt wird.

Mit dem lpfc-Treiber gibt es derzeit die folgenden bekannten Probleme:

In der Vergangenheit veränderte der Update-Prozess des Kernels den Standard-Kernel in der Bootloader-Konfiguration des Systems nicht.

Red Hat Enterprise Linux 4 ändert dieses Verhalten, um neuinstallierte Kernel als Standard zu setzen. Dieses Verhalten findet bei allen Installationsmethoden Anwendung (inklusive rpm -i).

Dieses Verhalten wird von zwei Zeilen in der /etc/sysconfig/kernel-Datei bestimmt:

Um die Redundanz zu eliminieren, die daraus resultiert, dass ein separates Paket für den Kernel-Quellcode zur Verfügung gestellt werden muss, wenn dieser Quellcode bereits in der Datei .src.rpm des Kernels besteht, beinhaltet Red Hat Enterprise Linux 4 nicht mehr länger das kernel-source-Paket. Benutzer, die Zugang zu den Kernel-Quellen benötigen, können diese in der Datei kernel .src.rpm finden. Um einen weitläufigen Quelltextverzeichnisbaum von dieser Datei zu erzeugen, führen Sie folgende Schritte aus (beachten Sie, dass <version> sich auf die Versionsbezeichnung Ihres derzeit laufenden Kernels bezieht):

Danach können Sie wie gewohnt fortfahren.

obj-m    := foo.o

KDIR    := /lib/modules/$(shell uname -r)/build
PWD    := $(shell pwd)

default:
    $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

              

Red Hat Enterprise Linux 4 beinhaltet eine aktualisierte Version des grafischen E-Mail-Client "Evolution". Diese Version besitzt eine Reihe neuer Features, wie z.B.:

Das gimp-perl-Paket wurde aus Red Hat Enterprise Linux 4 entfernt, da GIMP auf 2.0 aktualisiert wurde und die Perl-Bindungen weder komplett, noch Teil des Hauptpaketes waren.

Benutzer von Perl-Skripten in GIMP sollten das Gimp Perl-Modul von http://www.gimp.org/downloads/ installieren.

ja_JP.eucJP wird zu ja_JP.UTF-8

ko_KR.eucKR wird zu ko_KR.UTF-8

zh_CN.GB18030 wird zu zh_CN.UTF-8

zh_TW.Big5 wird zu zh_TW.UTF-8

Indische Sprachen — iiimf-le-unit

Japanisch — iiimf-le-canna

Koreanisch — iiimf-le-hangul

Vereinfachtes Chinesisch — iiimf-le-chinput

Traditionelles Chinesisch — iiimf-le-xcin

ami bewirkt, dass iiimf-le-hangul installiert wird

kinput2 bewirkt, dass iiimf-le-canna installiert wird

miniChinput bewirkt, dass iiimf-le-chinput installiert wird

xcin bewirkt, dass iiimf-le-xcin installiert wird

Standardmäßig akzeptiert der Sendmail Mail Transport Agent (MTA) keine Netzwerkverbindungen von Hosts, anders als dem lokalen Computer (localhost). Wenn Sie Sendmail als Server für andere Clients konfigurieren möchten, müssen Sie /etc/mail/sendmail.mc bearbeiten und die DAEMON_OPTIONS Zeile ändern, um auch auf Netzwerkgeräten zu horchen (oder kommentieren Sie diese Option vollständig mit dnl im Kommentar-Delimiter aus). Sie müssen dann /etc/mail/sendmail.cf durch den folgenden Befehl (als Root) neu erstellen:

make -C /etc/mail

Bitte beachten Sie, dass Sie für diese Funktion das Paket sendmail-cf installiert haben müssen.

Unter der standardmäßigen SELinux-Sicherheitskonfiguration, wird httpd von der "targeted policy" abgedeckt. Dies steigert den Sicherheitsfaktor und die Web-Server-Stabilität, indem ausdrücklich httpd-Zugang zu System-Objekten gewährt oder verweigert wird. Da dies jedoch dazu führen kann, dass zuvor einwandfrei funktionierende Konfigurationen (wie jene, die PHP benutzen) nicht mehr länger funktionstüchtig sind, müssen Sie ein Verständnis dafür besitzen, wie SELinux arbeitet, um sicherzustellen, dass Ihre Konfiguration sowohl sicher als auch funktionell ist.

Beispielsweise kann ein Boolescher Wert so gesetzt werden, dass eine spezifische Berechtigung für httpd besteht, Objekte in ~/public_html/ zu lesen, solange diese mit dem Sicherheitskontext httpd_sys_content_t gekennzeichnet sind. Der Apache-Daemon kann nicht auf Objekte zugreifen (Dateien, Applikationen, Geräte und andere Prozesse), die einen Sicherheitskontext besitzen, der nicht ausdrücklich Zugang durch SELinux auf httpd gewährt.

Indem Apache lediglich Zugang zu dem gewährt wird, was Apache dazu benötigt, um einwandfrei zu funktionieren, ist das System vor kompromittierten oder miskonfigurierten httpd-Daemons geschützt.

Da beides benötigt wird, sowohl Standard Linux Verzeichnis- und Dateiberechtigungen sowie auch SELinux Datei-Kontext-Labels, müssen Administratoren und Benutzer über das Neu-Kennzeichnen von Dateien Bescheid wissen. Beispiele zum Neu-Kennzeichnen umfassen die folgenden Befehle (einen für rekursives Neu-Kennzeichnen der Inhalte eines Verzeichnisses und einen für das Neu-Kennzeichnen einer einzelnen Datei):

chcon -R -h -t httpd_sys_content_t public_html
chcon -t httpd_sys_content_t public_html/index.html

            

Eine Datei oder ein Verzeichnis, welche/s nicht mit einem Kontext auf der Liste von Apache's erlaubten Typen gekennzeichnet ist, generiert einen 403 Forbidden-Fehler.

Sie können Boolesche Werte konfigurieren oder wahlweise die Targeted-Policy-Abdeckung nur für Apache (oder jedem der darin enthaltenen Deamons) mittels system-config-securitylevel deaktivieren. Innerhalb des Modify SELinux Policy Bereichs, können Sie Apache modifizieren. Wenn Sie möchten, haben Sie die Wahl, Deaktiviere SELinux Schutz für http Daemon (Disable SELinux protection for httpd daemon) auszuwählen, wobei der Wechsel von unconfined_t (Standard-Typ, der sich transparent wie Standard Linux Security ohne SELinux verhält) auf den spezifischen Daemon-Typ, zB. httpd_t deaktiviert wird. Das Deaktivieren schaltet SELinux für diesen Daemon ab, wobei dieser nur zur standardmäßigen Linux-Security zurückkehrt.

Weitere Informationen zu Apache und der SELinux-Policy finden Sie im Red Hat SELinux Policy-Handbuch unter http://www.redhat.com/docs.

Standardmäßig wird der httpd-Daemon nunmehr unter Verwendung der C-Locale gestartet und benutzt nicht mehr die konfigurierte Einstellung der Regionsdaten (locales) des Systems. Dieses Verhalten kann dadurch verändert werden, indem die HTTPD_LANG-Variable in der Datei /etc/sysconfig/httpd eingestellt wird.

Die standardmäßige /etc/php.ini-Konfigurationsdatei wurde so verändert, dass eher die "production"-Standards und nicht die "development"-Standards benutzt werden. Erwähnenswerte Unterschiede sind:

Das Paket benutzt nunmehr "apache2handler" SAPI für die Integration mit Apache httpd 2.0 und nicht mehr "apache2filter" SAPI. Wenn Sie von vorherigen Releases aktualisieren möchten, sollten die SetOutputFilter-Anweisungen aus der Datei /etc/httpd/conf.d/php.conf entfernt werden.

Die folgenden Änderungen wurden hinsichtlich der Paketierung von Modulen der PHP-Erweiterung durchgeführt:

Red Hat Enterprise Linux 4 beinhaltet das neue xorg-x11-deprecated-libs-Paket. Dieses Paket beinhaltet auf X11 bezogene Bibliotheken, die nicht mehr länger verwendet werden und eventuell von zukünftigen Versionen von Red Hat Enterprise Linux entfernt werden. Indem nicht mehr verwendete Bibliotheken auf diese Art in ein Paket gepackt werden, bleibt Binärdatei-Kompatibilität mit bestehenden Applikationen erhalten, wobei anderen Software-Anbietern genügend Zeit bleibt, deren Applikationen weg von diesen Bibliotheken umzuwandeln.

Derzeit beinhaltet dieses Paket die Xprint-Bibliothek (libXp). Diese Bibliothek sollte nicht zur Entwicklung neuer Software verwendet werden. Applikationen, welche zur Zeit diese Bibliothek verwenden, sollten damit beginnen, zu den unterstützten libgnomeprint/libgnomeprintui Druck-APIs zu migrieren.

Es gab einige Verwirrung hinsichtlich Font-bezogener Fragen unter dem X-Window-System in neueren Versionen von Red Hat Enterprise Linux (und davor Versionen von Red Hat Linux). Derzeit gibt es zwei Font-Subsysteme, wobei jedes unterschiedliche Charakteristika aufweist:

- Das ursprüngliche (mehr als 15 Jahre alte) Subsystem wird als "Core X Font Subsystem" bezeichnet. Fonts in diesem Subsystem besitzen kein "Antialiasing", werden vom X-Server gehandhabt und werden wie folgt genannt:

-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1

Das neuere Font-Subsystem ist bekannt als "fontconfig" und erlaubt Applikationen den direkten Zugang zu den Font-Dateien. Fontconfig wird häufig zusammen mit der "Xft"-Bibliothek verwendet, die es Applikationen erlaubt, fontconfig-Fonts auf dem Bildschirm mit "Antialiasing auszugeben". Fontconfig verwendet benutzerfreundlichere Namen wie:

Luxi Sans-10

Mit der Zeit wird fontconfig/Xft das "Core X-Font-Subsystem" ersetzen. Zur Zeit verwenden Applikationen, die Qt 3 oder GTK 2 Toolkits verwenden (einschließlich KDE- und GNOME-Applikationen), die Subsysteme fontconfig und Xft-font. In allen anderen Fällen werden fast immer die "Core X-Fonts" verwendet.

Zukünftig wird Red Hat Enterprise Linux wahrscheinlich nur noch fontconfig/Xft anstelle des XFS Font-Servers als Standard für den lokalen Zugriff auf Fonts unterstützen.

HINWEIS: Eine Ausnahme für die Nutzung der oben angegebenen Font-Subsysteme sind OpenOffice.org (das eine eigene Font-Rendering-Technologie verwendet).

Wenn Sie neue Fonts zu Ihrem Red Hat Enterprise Linux 4 System hinzufügen möchten, beachten Sie bitte, dass die jeweiligen durchzuführenden Schritte von dem Font-Subsystem, das die neuen Fonts verwenden soll, abhängen. Für das "Core X Font-Subsystem" müssen Sie:

1. Das Verzeichnis /usr/share/fonts/local/ erstellen (falls noch nicht vorhanden):

mkdir /usr/share/fonts/local/

2. Die neue Font-Datei nach /usr/share/fonts/local/ kopieren

3. Die Font-Informationen durch Eingabe der folgenden Befehle aktualisieren (beachten Sie, dass aufgrund von Formatierungseinschränkungen die folgenden Befehle über eine Zeile hinausreichen können. Jeder Befehl sollte jedoch in einer einzelnen Zeile stehen):

ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale

mkfontdir /usr/share/fonts/local/

4. Wenn Sie das Verzeichnis /usr/share/fonts/local/ neu erstellen mussten, müssen Sie dies nun zum Pfad des X Font-Servers (xfs) hinzufügen:

chkfontpath --add /usr/share/fonts/local/

Das Hinzufügen neuer Fonts zum fontconfig Font-Subsystem ist einfacher. Die neue Font-Datei muss nur in das Verzeichnis /usr/share/fonts/ hineinkopiert werden (einzelne Benutzer können ihre persönliche Fontkonfiguration ändern, indem sie die Font-Datei in das ~/.fonts/-Verzeichnis hineinkopieren).

Nachdem der neue Font kopiert wurde, geben Sie den Befehl fc-cache ein, um das Cache für Font-Informationen zu aktualisieren:

fc-cache <directory>

(<directory> wäre hier /usr/share/fonts/ oder ~/.fonts/.)

Einzelbenutzer können Fonts auch über die grafische Oberfläche installieren, in dem sie zu fonts:/// in der Anwendung Nautilus gehen und die neuen Font-Dateien herüberziehen.

HINWEIS: Endet der Name der Font-Datei mit ".gz", wurde diese mit gzip komprimiert und muss erst dekomprimiert werden (mit Hilfe des Befehls gunzip), bevor das fontconfig Font-Subsystem diesen Font verwenden kann.

Durch den Übergang zum neuen Font-System basierend auf fontconfig/Xft sind GTK+ 1.2 Applikationen nicht von jeglichen Änderungen, die über den Dialog Font-Präferenzen durchgeführt wurden, betroffen. Für diese Applikationen können Fonts konfiguriert werden, indem Sie folgende Zeilen zu der Datei ~/.gtkrc.mine hinzufügen:

style "user-font" {

fontset = "<font-specification>"

}

widget_class "*" style "user-font"

(Wobei <font-specification> eine Font-Spezifikation im Stil traditioneller X-Applikationen wie zum Beispiel "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*" darstellt).

Das volle Set an LVM2-Befehlen ist nunmehr in /usr/sbin/ installiert. In Boot-Umgebungen, in denen /usr/ nicht erhältlich ist, ist es notwendig, jedem Befehl /sbin/lvm.static voranzustellen (beispielsweise /sbin/lvm.static vgchange -ay).

In Umgebungen, in denen /usr/ erhältlich ist, ist es nicht mehr länger notwendig, jedem Befehl lvm voranzustellen (/usr/sbin/lvm vgchange -ay wird beispielsweise zu /usr/sbin/vgchange -ay).

Die neuen LVM2-Befehle (wie /usr/sbin/vgchange -ay und /sbin/lvm.static vgchange -ay) stellen fest, ob ein 2.4er Kernel läuft und rufen transparent die alten LVM1-Befehle auf, falls angebracht. Die LVM1-Befehle wurden so umbenannt, dass sie auf ".lvm1" enden (beispielsweise /sbin/vgchange.lvm1 -ay).

Der nscd Namensdienst Cache-Daemon kann nunmehr persistenten Cache quer durch Neustarts oder System-Reboots beibehalten. Jede Datenbank (Benutzer, Gruppe und Host) kann als persistent ausgewählt werden, indem die entsprechende Zeile in /etc/nscd.conf auf "yes" gesetzt wird. Einträge werden nicht aus dem Cache entfernt, bis diese nachweisbar nicht länger von Interesse sind. Alle Einträge, deren 'Lebenszeit' abläuft, die jedoch immer noch von Interesse sind, werden neu geladen, was in Situationen hilfreich sein kann, in denen Verzeichnis- und Namensdienste vorübergehend nicht verfügbar sind.

Unter der standardmäßigen SELinux-Sicherheitskonfiguration ist dieser Daemon in der sogenannten "targeted policy" enthalten. Dies erhöht die Sicherheit, indem sehr ausdrücklich der Zugang zu System-Objekten gewährt oder abgelehnt wird, welche der Daemon normalerweise benutzt. Da dies jedoch dazu führen kann, dass zuvor einwandfrei funktionierende Konfigurationen nicht mehr länger funktionieren, müssen Sie verstehen wie SELinux arbeitet, um sicherzugehen, dass Ihre Konfiguration gleichzeitig sicher und auch funktionell ist.

Für weitere Informationen über die SELinux Policy (Sicherheitsrichtlinien) werfen Sie einen Blick auf das Red Hat SELinux Policy-Handbuch unter http://www.redhat.com/docs.