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 Daten-Korruption zu verhindern und so früh als möglich ausfindig zu machen. Sollte Korruption ausfindig gemacht werden, so wird standardmäßig eine Nachricht wie die Folgende auf 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 abgebrochen; 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 Korruptions-Checks auslöst und eine dahingehende Nachricht anzeigt, so sollten Sie einen Fehlerbericht beim Verkäufer dieser Applikation einreichen, da dies auf einen gravierenden Fehler hinweist.

Obwohl Red Hat Enterprise Linux 4 Unterstützung für rawio beinhaltet, ist dies nunmehr eine nicht mehr verwendete Schnittstelle. 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 für Red Hat Enterprise Linux 4 erhalten bleiben, jedoch ist geplant sie aus zukünftigen Versionen zu entfernen.

Asynchrones I/O (AIO) auf Dateisystemen wird derzeit nur imO_DIRECT oder nicht-gepufferten 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 fehlerfreie Subsystem basiert nunmehr auf ALSA; die OSS-Module sind nicht mehr länger erhältlich.

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:

Das ursprüngliche Release von Red Hat Enterprise Linux 4 unterstützt keine USB-Festplattenlaufwerke. Jedoch werden andere USB Speichergeräte, wie z.B. Flash Media, CD-ROM und DVD-ROM Geräte 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 lspci -n-Befehl kann dazu benutzt werden, um die IDs für Adapter anzeigen zu lassen, die in einem bestimmten Rechner installiert sind. Produkte wie diese IDs sind (nicht nur ausschließlich) unter folgenden Model-Namen bekannt:

Dell sowie auch LSI Logic haben zu erkennen gegeben, dass sie diese Modelle im 2.6 Kernel nicht mehr länger 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) wird derzeit öffentlich für eine mögliche Einbindung in den Linux 2.6 Kernel geprüft. Er wird mit Red Hat Enterprise Linux 4 aus Testzwecken ausgeliefert. Ä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 endgültigen Red Hat Enterprise Linux-Release entfernt wird.

Der lpfc-Treiber wirft derzeit folgende bekannte Probleme auf:

In der Vergangenheit hat der Prozess des Updatens des Kernels den Standard Kernel in der Bootloader-Konfiguration des Systems nicht geändert.

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 kernel .src.rpm Datei finden. Um ein erweitertes Quelltextverzeichnis 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 von Evolution. Diese Version besitzt eine Anzahl neuer Features, wie z.B.:

Das gimp-perl-Paket wurde von Red Hat Enterprise Linux 4 entfernt, da GIMP auf 2.0 aktualisiert wurde und die Perl-Bindungen nicht mehr 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 Servern, anders als der lokale Computer. 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 um die Netzwerk-Kommunikation nachzuverfolgen (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 sendmail-cf Paket installiert haben müssen.

Unter der Standard 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 abgelehnt wird. Da dies jedoch mit sich bringen 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 Relabeln von Dateien Bescheid wissen. Beispiele von Relabeln beinhalten die folgenden Befehle (einen für rekursives Relabeln der Inhalte eines Verzeichnisses und einen für das Relabeln 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 ist, wird einen 403 Forbidden-Fehler generieren.

Sie können Boolesche Werte konfigurieren oder wahlweise Targeted-Policy-Reichweite für lediglich Apache (oder jedem der darin enthaltenen Deamons) mittels system-config-securitylevel deaktivieren. Innerhalb des Modify SELinux Policy Bereiches, können Sie Apache modifizieren. Wenn Sie möchten, können Sie Deaktiviere SELinux Schutz für http Daemon (Disable SELinux protection for httpd daemon) auswä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 rein zur Standard Linux Security zurückkehrt.

Für weitere Informationen über Apache und SELinux Policy siehe Red Hat SELinux Policy Guide at http://www.redhat.com/docs.

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

Die Standard /etc/php.ini-Konfigurationsdatei wurde dahingehend verändert, um eher die "production"-Defaults und nicht die "development"-Defaults zu benutzen; beträchtliche 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, so sollten die SetOutputFilter-Anweisungen von der Datei /etc/httpd/conf.d/php.conf entfernt werden.

Die folgenden Änderungen wurden beim Zusammenstellen der PHP Erweiterungsmodule vorgenommen:

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 hat einige Verwirrung hinsichtlich Font-bezogenen Fragen unter dem X Window System in neueren Versionen von Red Hat Enterprise Linux (und davor Versionen von Red Hat Linux) gegeben. 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 haben kein Anti Aliasing, werden vom X Server unterstützt 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 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 Anti-Aliasing auszugeben. Fontconfig verwendet benutzerfreundlichere Namen wie:

Luxi Sans-10

Mit der Zeit wird fontconfig/Xft das derzeitige 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 Standard 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 auf einer 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 werden GTK+ 1.2 Applikationen nicht von jeglichen Änderungen, die über den Dialog Font-Präferenzen durchgeführt wurden, betroffen. In diesen 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).

Der volle Satz 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.4 Kernel läuft und rufen transparent die alten LVM1-Befehle auf. Die LVM1-Befehle enden nun alle mit der Erweiterung ".lvm1" (beispielsweise /sbin/vgchange.lvm1 -ay).

Der nscd Namensdienst Cache Daemon ist nun in der Lage auch nach Neustart oder System-Reboots seinen Cache beizubehalten. Jede Datenbank (Benutzer, Gruppe und Host) kann 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) siehe den Red Hat SELinux Policy Guide unter http://www.redhat.com/docs.