Red Hat Enterprise Linux AS 3 Release Notes

Booting Anaconda

Installationsbezogene Hinweise

Anmerkungen zu Eingabemethoden

Allgemeine Hinweise

Kernelhinweise

Die Abfolge der Verarbeitung von CD-ROMS hat sich bei Red Hat Enterprise Linux 3 geändert. Die erste CD-ROM wird zum Booten des Installationsprogramms und nach dem Verarbeiten der darauffolgenden CD-ROMS wieder benötigt.

Das Red Hat Enterprise Linux-Installationsprogramm ist in der Lage, die Integrität der Installationsmedien zu überprüfen. Es unterstützt die Installation von CD, Festplatten-ISO und NFS-ISO. Red Hat empfiehlt, vor Beginn der Installation alle Installationsmedien zu prüfen. Dies sollte geschehen, bevor installationsbezogene Fehler gemeldet werden (viele der gemeldeten Fehler sind auf fehlerhaft gebrannte CDs zurückzuführen). Um diesen Test auszuführen, geben Sie linux mediacheck am boot:-Prompt ein.

Red Hat Enterprise Linux 3 bietet Support für Logical Volume Management (LVM). LVM ermöglicht das Zusammenfassen von Speicherplatz in ein logisches Volumen oder mehrere logische Volumen, die dann dazu verwendet werden können,Dateisysteme einzurichten, deren Größe ziemlich einfach geändert werden kann.

Installationen im Textmodus und einem seriellen Terminal arbeiten am Besten, wenn der Terminal UTF-8 unterstützt. Unter UNIX und Linux unterstützt Kermit UTF-8. Unter Windows funktioniert Kermit '95 sehr gut. Nicht-UTF-8 fähige Terminals funktionieren, solange nur Englisch als Sprache während der Installation verwendet wird. Ein erweitertes serielles Display kann verwendet werden, wenn Sie "utf8" dem Installationsprogramm als Boot-Option angeben. Zum Beispiel:

linux console=ttyS0 utf8

Der Bildschirm zur Konfiguration der Firewall im Red Hat Enterprise Linux Installationsprogramm wurde vereinfacht. Die alten "Hoch", "Mittel" und "Keine Firewall"-Einstellungen wurden direkter, im Ein/Aus-Typ, dargestellt. Zusätzlich ermöglicht die Standard-Konfiguration der Firewall Benutzern von NIS Authentifizierung, NFS und DNS eine Firewall einzusetzen, ohne dass zusätzliche benutzerdefinierte Einstellungen erfordert wären (das Angeben von bestimmten Portnummern und Protokollen ist allerdings noch möglich).

HINWEIS: Diese Änderung trifft auch auf das Security Level Configuration Tool (redhat-config-securitylevel) zu.

Installationen über VNC werden jetzt unterstützt. Um eine VNC-basierte Installation zu starten, geben Sie vnc als Boot-Option ein. Wenn nötig kann ein Passwort gesetzt werden, in dem Sie "vncpassword=<password>" zu den Optionen zum Bootzeitpunkt hinzufügen. Die VNC-Anzeige ist dann "<host>:1", wobei <host> der Hostname oder die IP-Adresse des Systems ist, das Red Hat Enterprise Linux installiert.

Das Red Hat Enterprise Linux Installationsprogramm kann auch eine Verbindung zu einem abhörenden VNC-Client aufbauen. Dies wird durch die vncconnect Boot-Option erreicht:

linux vnc vncconnect=<client>[:<port>]

(Wobei <client> der Hostname oder die IP-Adresse des Systems ist, dass den VNC-Client ausführt, und <port> ist eine optionale Port-Angabe, die gegeben wird, wenn der VNC-Client nicht den Port 5500 abhört, der den Standard-Port für diesen Typ von Verbindung darstellt). Die folgenden Beispiele zeigen wie die Boot-Option für nicht-Standard-Ports angegeben wird:

linux vnc vncconnect=pigdog.example.com

linux vnc vncconnect=pigdog.example.com:27910

Das System, das den abhörenden VNC-Client ausführen wird, muss dann die entsprechende Software starten, um den VNC-Client im abhörenden Modus auszuführen. Für den mit Red Hat Enterprise Linux 3 gelieferten VNC-Client ist der folgende Befehl ausreichend:

vncviewer -listen

Zusätzlich wurde eine neue Kickstart-Anweisung hinzugefügt, um VNC-basierte Installationen zu unterstützen:

vnc [--password <password>] [--connect <host>[:<port>]]

(Wobei --password <password> ein optionaler Parameter für die Angabe eines VNC-Passwortes ist, und [--connect <host>[:<port>]] ein optional Parameter zur Angabe des Host (und optional, Port) eines Systems, dass den abhörenden VNC-Client ausführt.

HINWEIS: Wenn Sie irgendeine der VNC-bezogenen Boot-Optionen angeben, werden diese den entsprechenden Optionen in der Kickstart-Datei voran gehen.

Chinesisch (Einfach und Traditionell)

Japanisch

Koreanisch

Einfaches Chinesisch

Um Zeichen in einfachem Chinesisch einzugeben, müssen Sie die miniChinput Eingabemethode verwenden. Um diese zu aktivieren, drücken Sie Strg-Leertaste.

Die miniChinput Eingabemethode unterstützt folgende Module:

· intelligent pinyin input

· gbk pinyin input

· shuang pin input

· internal code (gb18030 code) input

Das miniChinput-Paket ist installiert, wenn Support für Einfaches Chinesisch während der Installation ausgewählt wurde.

Traditionelles Chinesisch

Um Zeichen in traditionellem Chinesisch einzugeben, verwenden Sie die xcin Eingabemethode. Um diese zu aktivieren, drücken SieStrg-Leertaste. Drücken von Shift-Strg oder Strg-Alt-Num erlaubt Ihnen zwischen Eingabemethoden zu wechseln.

Die xcin Eingabemethode unterstützt folgende Module:

· CJ

· Simplex

· Phone

· CantonPing

· Bimsphone

· Bimspinyin

· Array30

· Cantonping (Keine Intonation)

Das xcin-Paket ist installiert, wenn Sprachensupport für Traditionelles Chinesisch während der Installation ausgewählt wurde.

Japanisch

Um Japanische Zeichen einzugeben, können Sie die Canna, FreeWnn oder skk Eingabemethode verwenden. Um diese zu Aktivieren, drücken Sie Shift-Leertaste.

Die folgenden Module sind unterstützt:

· romaji

· kana (nur Canna — von der Konfigurationsdatei abhängig)

Die Canna, FreeWnn und skkinput-Pakete sind installiert, wenn Sprachensupport für Japanisch während der Installation ausgewählt wurde.

Koreanisch

Um Koreanische Zeichen einzugeben, verwenden Sie die ami Eingabemethode. Um diese zu aktivieren, drücken Sie Shift-Leertaste.

Das ami-Paket ist installiert, wenn Sprachensupport für Koreanisch während der Installation ausgewählt wurde.

Der Apache HTTP Server wurde auf Version 2.0 aktualisiert. Das aktualisierte Paket ersetzt Version 1.3 und wurde in httpd umbenannt.

· Die Module auth_ldap, mod_put, mod_roaming, mod_auth_any, mod_bandwidth, mod_throttle und mod_dav wurden entfernt.

· Die WebDAV Funktionalität ist jetzt im httpd-Paket enthalten.

HINWEIS: Einige Änderungen an den bestehenden Konfigurationsdateien waren nötig. Apache-Module von Drittherstellern müssen u.U. auch aktualisiert werden. Weitere Informationen finden Sie im Migrations-Handbuch unter /usr/share/doc/httpd-*/migration.html.

Der LPRng Spooler wurde durch CUPS ersetzt und das Printer Configuration Tool (redhat-config-printer) ist das empfohlene Konfigurations-Tool. Es kann vom Menü Systemeinstellungen aus mittels des Menüeintrags Drucken gestartet werden.

Security Level Configuration Tool (redhat-config-securitylevel) wurde vereinfacht. Die alten "Hoch", "Mittel" und "Keine Firewall"-Einstellungen wurden durch eine direktere Ein/Aus Methode ersetzt. Zusätzlich mach es die Vorgabe zur Firewall-Konfiguration für Benutzer von NIS-Authentifizierung, NFS und DNS einfacher eine Firewall einzusetzen, ohne weitere benutzerdefinierte Einstellungen zu benötigen (die Angaben von Ports und Protokollen ist allerdings noch möglich).

HINWEIS: Diese Änderung trifft auch auf das Red Hat Enterprise Linux Installationsprogramm zu.

GNOME Druck-Manager, ein einfaches, grafisches Verwaltungstool für Druck-Wartenschlangen, wurde hinzugefügt. Es kann vom Menü Systemeinstellungen mittels des Menüeintrags Print Manager gestartet werden. Zusätzlich dazu erscheint ein Symbol im Benachrichtigungsfeld des Panels, wenn sich ein Druckauftrag in der Warteschlange befindet.

Red Hat Enterprise Linux 3 enthält das Setarch Utility. Setarch ermöglicht es, die Ausgaben des Befehls uname zu ändern. Dies ist aus einer Reihe von Gründen nützlich, wie dem Ausführen von 32-Bit Applikationen (denen, die einen bestimmten Wert vom Befehl uname -m erwarten) in 64-Bit Umgebungen.

Das Format des Setarch-Befehls ist:

setarch <arch> <command>

(Wobei <arch> der String der Architektur (wie i386) ist, und <command> den Befehl darstellt, der beim Ändern der Architektur ausgeführt wird.) Beachten Sie, dass <command> ausgelassen werden kann, in welchem Fall /bin/sh ausgeführt wird.

Zusätzlich, sind einige Applikationen (wie ältere Java-Versionen) so geschrieben, dass diese 3GB virtuellen Adressraum erwarten. Wenn auf Systemen mit größeren virtuellen Adressräumen ausgeführt (wie 64-Bit AMD64-basierte Systeme oder 32-Bit Systeme mit dem hugemem-Kernel), können diese Applikationen fehlschlagen. Das setarch-Utility macht es möglich 3GB virtuellen Adressraum zu emulieren, sodass solche Applikationen fehlerfrei laufen können:

setarch -3 java

Red Hat Enterprise Linux 3 enthält die Native POSIX Thread Library (NPTL), eine neue Sammlung von POSIX Threads für Linux. Diese Library bietet Leistungsverbesserungen und erhöhte Anpassbarkeit.

Diese Thread Library ist binär-kompatibel zu den alten LinuxThreads; Applikationen, die jedoch auf den Stellen beruhen, bei denen LinuxThreads vom POSIX Standard abweichen, müssen geändert werden. Sichtbare Unterschiede sind unter anderem:

· die Signalverarbeitung wurde von der Verarbeitung pro Thread zur POSIX Prozess-Signalverarbeitung geändert.

· getpid() gibt in alle Threads den gleichen Wert aus.

· Thread-Handlers, die mit dem Befehl pthread_atfork registriert werden, werden nicht gestartet, wenn vfork() verwendet wird.

· Kein Manager-Thread.

Wenn eine Applikation nicht ordnungsgemäß mit NPTL arbeitet, kann es mit der alten Linux Threads Implementierung gestartet werden, in dem Sie folgende Umgebungsvariable einstellen:

LD_ASSUME_KERNEL=<kernel-version>

Es sind folgende Versionen erhältlich:

· 2.4.19 — Linuxthreads mit Floating Stacks

Beachten Sie, dass Software, die errno, h_errno und _res verwendet, die richtigen Headerdateien (errno.h, netdb.h und resolv.h) in einer #include-Anweisung enthalten muss. LD_ASSUME_KERNEL=2.4.19 kann jedoch als Workaround verwendet werden, bis ein Fix der Software durchgeführt werden kann.

Multi-threaded C++ Programme, die Thread-Cancellation verwenden, müssen eventuell dazu gezwungen werden die LinuxThreads Bibliothek mit der Umgebungsvariable LD_ASSUME_KERNEL=2.4.19 zu verwenden.Andernfalls wird das Programm abstürzen, wenn auf eine Cancellation reagiert wird (da die erzeugte Exception nicht abgefangen wird).

Neu geschriebener C++ Code, der Funktionen der C Runtime-Umgebung verwendet, muss eventuell angepasst werden, um Cancellation zu berücksichtigen. Dies kann durch folgende Methoden erzielt werden:

· Die C++ Funktion nicht mit throw() markieren (damit Callers wissen, dass eine Exception auftreten kann) und den Code mit Exceptions kompilieren. Dies ist die Standard-Option bei der Kompilierung; Benutzer sollten nicht -fno-exceptions bei der Kompilierung angeben.

· Cancellation-Modus vollständig ausschalten, bevor Sie in die Funktionen eintreten, die die "cancel-able" (abbrechbaren) C Runtime Funktionen aufrufen. Die kann durch folgenden Aufruf erzielt werden:

pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &oldstate)

Nachdem die C Funktionen aufgerufen wurden, kann Cancellation durch den folgenden Aufruf wieder aktiviert werden:

pthread_setcancelstate (oldstate, NULL)

HINWEIS: Zu diesem Punkt wird auf Cancellations reagiert und die Funktion, die pthread_setcancelstate() aufruft, muss mit Exceptions aktiviert und mit Throwing Exceptions markiert kompiliert werden.

Eine neue Systemmitteilung wurde zu Red Hat Enterprise Linux 3 hinzugefügt:

Applikationsfehler: Bei <app-name>(<app-pid>) ist SIGCHLD auf SIG_IGN gesetzt, ruft jedoch wait() auf. (siehe den Abschnitt NOTES des 'man 2 wait'). Workaround aktiviert.

Diese Meldung (die auf der Systemkonsole und/oder in den System-Logdateien angezeigt wird) zeigt an, dass die Applikation nicht vollständig mit den Standards in Bezug auf die Child-Prozesse übereinstimmt . Wenn Sie diese Nachricht sehen, sollten Sie die Entwickler dieser Applikation benachrichtigen.

Red Hat Enterprise Linux 3 schließt die Fähigkeit zur Produktion von Position Independent Executables (PIE) für C, C++ und Java ein. Dieses Feature ist mit den -fpie und -fPIE GCC Optionen zu kompilieren, die in der Benutzung ähnlich den -fpic und -fPIC Option sind, und zur Link-Zeit, der -pie Option.

Die fileutils, textutils, sh-utils undstat Pakete wurden durch das neuere coreutils Paket ersetzt.

Die RPMs, die das Network Administration Tool (redhat-config-network)enthalten, haben einen neuen Namen und neue Funktionalität. Das RPM redhat-config-network enthält die graphische Benutzerschnittstelle des Tools und redhat-config-network-tui enthält das Tool selbst (zusammen mit dessen Text-basierten Benutzerschnittstelle).

Der Support für XHTML1 — die neue Darlegung von HTML in XML — wurde verbessert. Dies wurde durch das Hinzufügen des xhtml1-dtd Pakets, die Installation der DTDs im Systemkatalog und das Hinzufügen von Native Support zu den libxml2 und xsltproc Tools erreicht.

Das XML-Toolkit wurde erweitert, um eine Relax-NG Validierung und Streaming-Fähigkeiten großer Dateien zu unterstützen.

Der systemweite Profiler Oprofile wurde zu Red Hat Enterprise Linux 3 hinzugefügt. OProfile ist ein Programmiertool zur Analyse der Systemleistung unter Verwendung besonderer Hardware, die in vielen modernen Computern vorhanden ist. Die Dokumentation hierzu befindet sich im oprofile Paket. Nach dem Sie Red Hat Enterprise Linux 3 installiert haben, geben Sie den Befehl rpm -qd oprofile ein, um eine Liste der verfügbaren Dokumentation zu erhalten. Weitere Informationen finden Sie auch auf der OProfile-Webseite unter http://oprofile.sourceforge.net.

HINWEIS: Kernel-Support für OProfile in Red Hat Enterprise Linux 3 basiert auf den vom 2.5 Entwicklungskernel zurück portierten Quellen. Beachten Sie deswegen bitte, dass die in der OProfile Dokumentation als 2.5-spezifische Eigenschaften auch für den Red Hat Enterprise Linux-Kernel gelten, obwohl dieser Version 2.4 ist. Das heisst auch, dass 2.4-spezifische Eigenschaften nicht für den Red Hat Enterprise Linux-Kernel gelten.

Zur Zeit gibt es zwei Font-Subsysteme im X Window System, jedes mit besonderen Eigenschaften:

· 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 wie folgt benannt:

-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" Library 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 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; fast alles andere verwendet core X fonts.

Zukünftig wird Red Hat 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-Technologie verwendet).

Wenn Sie neue Fonts zu Ihrem Red Hat Enterprise Linux 3 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 (wenn 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 Font-Informations-Cache 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 browsen und die neue Font-Datei hier 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).

Standardmäßig akzeptiert der Sendmail Mail Transport Agent (MTA) keine Netzwerkverbindungen von anderen Hosts als die des lokalen Computers. 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 Netzwerkgeräte abzuhören (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) regenerieren:

make -C /etc/mail

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

Der Standard-FTP-Server in Red Hat Enterprise Linux 3 ist nun vsftpd, der einen SysV-Service ausführt.

Änderung zu fdisk's Interpretation von Partitionsgrößen-Multiplikatoren

Der Befehl fdisk hat nun eine andere Interpretation der Größen-Multiplikatoren, die beim Erzeugen neuer Plattenpartitionen verwendet werden können. Die Größenangaben K, M und G beziehen sich nun auf Mehrfache von Tausend, Millionen und Milliarden Bytes. Dies ist konsistenter mit den Angaben der FestplattenlaufwerkHersteller.

Wenn ein Benutzer eine 512MB Partition erzeugen will, wäre die Größenangabe mit nachgestelltem "M" 512*1024*1024 (536,870,912), aufgerunded auf mehrfache von Tausend (537,000,000), und dann durch eine Million (537) geteilt, was eine tatsächliche Größenangabe von +537M zur Folge hat.

Obwohl Kompatibilität zu ausführbaren Dateien und Dynamic Shared Objects (DSOs, auch als gemeinsame Bibliotheken bekannt), die auf früheren Red Hat Linux und Red Hat Enterprise Linux Version erzeugt wurden, gegeben ist, trifft dies nicht auf Objektdateien zu (.o). Auf früheren Versionen erzeugte Objektdateien können auf Red Hat Enterprise Linux 3 nur dann zum Erzeugen von ausführbaren Dateien oder DSOs verwendet werden, wenn diese beim Kompilieren alle System-Headerdateien enthielten.

Andernfalls ist der einizge Weg diese Dateien zu verwenden, die Objektdateien zu der Kompatibilitäts-Version von glibc (Teil des Pakets compat-glibc) zu linken. Eine neu erstellte Objektdatei muss die Header des Kompatibilitäts-Pakets verwenden. Um, zum Beispiel, Objektdateien zu kompilieren, fügen Sie Folgendes an den Anfang der Kompiler-Befehlszeile hinzu:

-I/usr/lib/i386-redhat-linux7/include

Um die resultierenden ausführbaren Dateien oder DSOs zu linken, fügen Sie Folgendes zur Befehlszeile hinzu:

-L/usr/lib/i386-redhat-linux7/lib

Jegliche Kombination von alten und neuen Objektdateien kann negative Auswirkungen haben. Das Linken von alten Objektdateien mit den regulären Systemheadern kann nicht verwendbare ausführbare Dateien zur Folge haben, oder solche, die schwere unerkannte Fehler enthalten (wie Auftreten von Datenkorruption).

Der Red Hat Enterprise Linux 3 Kernel macht Verwendung einer neuen Kernel-Packaging Methode. Wegen den unzähligen Möglichkeiten an verfügbarer Hardware ist es Red Hat nicht möglich alle Hardware-Komponenten zu unterstützen. Deswegen, während Kernel-Module für unterstützte Hardware im Standard kernel-Paket bleiben, sind einige nicht-unterstützte Kernel-Pakete in Red Hat Enterprise Linux 3 enthalten.

Für jedes gelieferte Kernel-Paket existiert ein entsprechendes nicht-unterstütztes Kernel-Paket. Das nicht-unterstützte Kernel-Paket für kernel-smp-2.4.21-3.EL.i686.rpm ist kernel-smp-unsupported-2.4.21-3.EL.i686.rpm.

HINWEIS: Die nicht-unterstützten Kernel-Pakete werden nicht vom Red Hat Enterprise Linux Installationsprogramm installiert. Deswegen müssen Sie die nicht-unterstützten Kernel-Pakete entsprechend Ihren Anforderungen manuell installieren.

Nach dem Installieren der gegebenen nicht-unterstützten Kernel-Pakete, müssen Sie den folgenden Befehl ausführen, um den Abhängigkeitsbaum und initrd zu aktualisieren:

/sbin/new-kernel-pkg --mkinitrd --depmod --install <kernel-version>

(wobei <kernel-version> die Version des installierten Kernel ist.)

In nicht-unterstützten Kernel-Paketen enthaltene Treiber werden auf einer "größte Mühe" Basis angeboten. Das heisst, dass Updates und Fixes eingearbeitet werden können, aber nicht müssen und dass keine Erwartung an den Support dieser Treiber gestellt werden kann, wie an die unterstützten Treiber. Benutzerspezifische Arrangements zu Treibern in den nicht-unterstützten Paketen können in einigen Fällen mit Red Hat ausgearbeitet werden.

Der Red Hat Enterprise Linux 3 Kernel enthält eine genauere Process-Timing-Funktionalität. Dieser neue Process-Timing-Modus verwendet Timestamps, um ein genaueres Timing von Idle- und Prozess-Zeit zu erhalten. Wenn aktiviert, ist diese Information über die üblichen Überwachungstools (wie top, vmstat und procinfo) und den getrusage Systemaufruf verfügbar.

Um Timestamp-basiertes Process-Timing zu aktivieren, müssen Sie Ihr System mit der folgenden Boot-Time Option booten:

process_timing=<value>

Wobei <value> eine oder mehrere der Folgenden sein kann, mehrere Werte dabei durch Kommas getrennt:

· irq — Verwende Timestamps, um IRQ Interrupte zu berücksichtigen

· softirq — Benutze Timestamps, um softirq-Zeit im Kernel zu berücksichtigen

· process — Erlaube Prozessen sich selbst für Timestamp-basiertes Process-Timing zu aktivieren (es ist dann als Vorgabe für alle Prozesse ausgeschaltet)

· all_process — Forciere Timestamp-basiertes Process-Timing für alle Prozesse (einschließlich der Idle-Tasks)

· everything — Selbe Funktion wie irq,softirq,all_process

Wird das System mit der Option process gebootet, hat keiner der Prozesse Timestamp-basiertes Process-Timing aktiviert. Jeder Prozess kann jedoch den prctl() Systemaufruf verwenden, um deren Process-Timing-Modus festzustellen und zu ändern. Der Systemaufruf zum Bestimmen des Process-Timing-Modus ist:

mode = prctl(PR_GET_TIMING, 0, 0, 0, 0);

Der Systemaufruf zum Setzen des Process-Timing-Modus ist:

status = prctl(PR_SET_TIMING, <mode>, 0, 0, 0)

(Wobei <mode> PR_TIMING_STATISTICAL ist für den traditionellen Process-Timing-Modus, oder PR_TIMING_TIMESTAMP, um den Timestamp-basierten Process-Timing-Modus zu aktivieren.) Beachten Sie, dass das aktivieren eines Modus den anderen deaktiviert.

HINWEIS: Der prctl() Systemaufruf kann lediglich auf Systemen verwendet werden, die mit process gebootet wurden. Andernfalls, wird der Systemaufruf -EINVAL zurück geben. Dies schließt Versuche das Timestamp-basierte Process-Timing auf Systemen, die mit der all_process Option gebootet wurden, zu deaktivieren mit ein.

Der Timing-Modus eines Child-Prozesses wird vom Parent-Prozess übernommen; der Child-Prozess kann jedoch den prctl() Systemaufruf verwenden, um seinen eigenen Timing-Modus zu ändern (abhängend von den in der vorherigen Anmerkung beschriebenen Einschränkungen).

Der BusLogic-Treiber (für bestimmte Mylex SCSI Host-Bus-Adapter) ist im Standard Kernel-Paket enthalten, wird jedoch nur unterstützt, wenn der Kernel ein Guest-Betriebssystem innerhalb der VMWare™ Virtual Machine Software ist. Dies ist der Fall, da VMWare dem BusLogic-Treiber einen emulierten SCSI-Adapter zur Verfügung stellt, und diese Umgebung wurde ausführlich getestet und ist von VMWare, Inc. unterstützt. Der BusLogic-Treiber ist nicht auf physikalischen SCSI Host-Adaptern unterstützt, da dieser seit einigen Jahren nicht im offiziellen Linux-Kernel gewartet wird und noch nicht genügend Tests im Red Hat Enterprise Linux Kernel untergangen ist.

Der qla1280-Treiber (für Qlogic ISP1x80/1x160 SCSI Adapter) wurde seit einigen Jahren im offiziellen Linux Kernel nicht gewartet. Obwohl dieser Treiber fehlerfrei mit der Intel x86 Architektur arbeitet, trifft dies nicht auf andere Architekturen zu. Red Hat unterstützt deswegen lediglich den qla1280 Treiber auf Intel x86 Plattformen.

Die netdump-Fähigkeiten sind augenblicklich ausgeschaltet. Das Paket netdump ist enthalten, so dass, wenn netdump-Fähigkeiten in einem zukünftigen Kernel-Update eingeschaltet werden, diese verfügbar sind.

Neuer Kernel-Support wurde hinzugefügt, um IPv6-Fähigkeiten bereit zu stellen. Dieser Support ist mit der Upstream 2.6-basierten Implementation, wie von 2.6.0-test3, konsistent.

Beachten Sie, dass Red Hat keine weiteren IPv6-Features (wie zum Beispiel die Standards für Mobile IP) in dieser Version von Red Hat Enterprise Linux unterstützt; unser Ziel ist es, uns völlig auf die Bugs in den bestehenden Features zu konzentrieren.

EA (Extended Attributes) und ACL (Access Control Lists) sind jetzt für ext3 und NFS erhältlich. Zusätzlich dazu ist ACL für NFS erhältlich.

Red Hat Enterprise Linux 3 enthalten einen Kernel, der EA und ACL für das ext3 Dateisystem unterstützt. Es wurden desweiteren Protokoll-Erweiterungen zu NFS hinzugefügt, die ACL-bezogene Operationen für NFS-exportierte Dateisysteme unterstützen.

Um ACLs auf einem lokal-gemounteten Dateisystem zu aktivieren, muss das Dateisystem mit der -o acl Mountoption gemountet werden. Um dem NFS-Server mitzuteilen, bei Ermittlung der Dateiberechtigungen auf ACLs zuzugreifen, müssen die Dateisysteme mit der acl Exportoption exportiert werden.

EAs sind für ACL-Support intern verwendet. Um EAs separat zu verwenden, muss das Dateisystem mit der Option -o user_xattr gemountet werden.

Der Support hierfür wird in mehreren Paketen geliefert:

· kernel — Bietet Support für das Speichern von EAs und ACLs auf der Festplatte für ext3 Dateisysteme und desweiteren Systemaufrufe, um EAs und ACLs zu ändern. Außerdem enthält das Kernel-Paket Mechanismen, die ACLs beim Zugriff auf Dateien verstärken.

· e2fsprogs — Beinhaltet Angaben zu den neuen erweiterten Attributformaten auf der Festplatte, so dass fsck Dateisysteme mit dem neuen Feature überprüfen kann.

· attr, libattr — Bietet Zugang zu den erweiterten Attributen, die an Dateien angefügt sind.

· acl, libacl — Bietet Tools zum Einstellen, Ändern und Abfragen der ACLs in Dateien.

· libattr-devel, libacl-devel — Libraries und Dateien zum Erstellen von Programmen mit Hilfe von acl und attr Libraries.

· star — Ein Archivierungstool, das Archive im tar und pax-Format erstellen und entpacken und außerdem Backups und Wiederherstellungen von EAs und ACLs erstellen kann.

HINWEIS: Die für star verfügbaren Optionen sind nicht vollständig mit denen für tar identisch; sehen Sie sich deswegen bitte die man-Seiten zu star an.

· samba — Samba kann die ACL-Funktionalität in dieser Version exportieren. Weitere Informationen zum Aktivieren dieser Funktion in Ihrer Konfiguration finden Sie in der Dokumentation zu Samba.

Zusätzlich dazu wurde das Paket coreutils aktualisiert, so dass die Befehle cp und mv die ACLs und EAs für eine Datei kopieren.

Weitere Informationen zum Einrichten und Lesen von ACLs finden Sie in den man-Seiten zu setfacl und getfacl. Allgemeine Informationen zu ACLs kann auf der man-Seite zu acl gefunden werden.

HINWEIS: Die regulären Befehle tar und dump führen kein Backup von ACLs und EAs durch.

Kompatibilität zu älteren Systemen:

Alle ext3-Dateisysteme, die keine ACLs oder EAs zugewiesen haben, können unverändert auf älteren Kerneln funktionieren und können mit älteren e2fsprogs Utilities geprüft werden.

Sobald ein EA oder ein ACL auf eine Datei in einem Dateisystem gesetzt wurde, bekommt dieses Dateisystem das Attribut ext_attr. Dieses Attribut kann durch folgenden Befehl angezeigt werden:

tune2fs -l <filesystemdevice>

Ein Dateisystem, das das ext_attr Attribut erhalten hat, kann mit älteren Kerneln gemountet werden, diese Kernel können jedoch die gesetzten ACLs nicht verstärken.

HINWEIS: Ältere Versionen des Dateisystem-Prüfprogramms e2fsck verweigern die Prüfung von Dateisystemen, die das ext_attr Attribute gesetzt haben. Dies entspricht den Versionen des e2fsprogs-Pakets vor 1.22.

Der Red Hat Enterprise Linux 3 Kernel enthält jetzt Support für NFS über TCP. Um NFS über TCP zu verwenden, müssen Sie die Option "-o tcp" zu mount angeben, wenn das NFS-exportierte Dateisystem auf dem Client-System gemountet wird.

HINWEIS: Das standardmäßige Transportprotokoll für NFS verbleibt UDP. Benutzen sie den Befehl mount-Befehls mit der Option "-o tcp", um ein NFS-exportierte Dateisystem über TCP zu mounten; andernfalls wird UDP verwendet.

Für diesen Kernel wurde der folgende Befehl hinzugefügt, um alle angeschlossenen SCSI-Hostadapter auf neue Geräte zu scannen:

echo "scsi scan-new-devices" > /proc/scsi/scsi

Dies ist bisher nicht standardisiert. In zukünftigen Kerneln kann ein anderer Parameter für die gleiche Fähigkeit eingesetzt werden, oder die Semantik dieses Parameters (scan-new-devices) kann sich ändern, wenn Red Hat den offiziellen Linux-Kernel für diesen Bereich verfolgt.

Änderungen in der Berechtigungssemantik für das Speicher-Lock im Benutzermodus

Red Hat Enterprise Linux 3 ermöglicht nun auch nicht-root Prozessen das Verwenden von Speicher-Lock-Aufrufen im Benutzermodus innerhalb der RLIMIT_MEMLOCK Ressourcen-Grenze. Die Standard-Grenze kann vom Systemadministrator auf Basis der User-ID, Gruppen-ID oder systemweit über die Datei /etc/security/limits.conf festgelegt werden. Root-Prozesse sind nicht länger von dieser Ressourcen-Grenze betroffen.

Die Systemaufrufe, die semantisch von dieser Änderung betroffen sind, sind mlock(2), munlock(2), mlockall(2), munlockall(2) und shmctl(2).