Notes de mise à jour de Red Hat Enterprise Linux AS 3

Booting Anaconda

Notes concernant l'installation

Notes sur les méthodes d'entrée

Notes générales

Notes sur le noyau

La séquence de traitement des CD-ROM a changé pour Red Hat Enterprise Linux 3. Le premier CD-ROM est requis au lancement du programme d'installation et de nouveau une fois que les CD-ROM suivants ont été utilisés.

Le programme d'installation de Red Hat Enterprise Linux a la possibilité de tester l'intégrité des supports d'installation. Il fonctionne avec les méthodes d'installation CD-ROM, DVD, disque dur ISO et NFS ISO. Red Hat vous recommande de tester tout support d'installation avant de commencer le processus d'installation et avant de rapporter tout bogue relatif à l'installation (bien des bogues rapportés sont en fait dûs à des CD-ROM qui n'ont pas été gravés correctement). Pour utiliser ce test, saisissez linux mediacheck à l'invite boot:.

Red Hat Enterprise Linux 3 inclut désormais la prise en charge de la gestion de volumes logiques (LVM, de l'anglais Logical Volume Management). LVM est une méthode d'allocation d'espace disque dans un ou plusieurs volumes logiques qui peuvent alors être utilisés pour implémenter des systèmes de fichiers faciles à redimensionner.

Les installations en mode texte utilisant un terminal en série fonctionnent le mieux lorsque le terminal supporte UTF-8. Sous UNIX et Linux, Kermit supporte UTF-8. Pour Windows, Kermit '95 fonctionne bien. Les terminaux non-UT8 fonctionneront à condition que seul l'anglais est utilisé durant l'installation. Un affichage en série amélioré peut être utilisé en passant "utf8" comme une option de démarrage au programme d'installation. Par exemple :

linux console=ttyS0 utf8

L'écran de configuration du pare-feu dans le programme d'installation de Red Hat Enterprise Linux a été simplifié. Les anciens paramètres "Élevé", "Moyen" et "Aucun pare-feu" ont été remplacés par un contrôle plus direct de style activé / désactivé. De plus, la configuration du pare-feu par défaut reconnaît désormais différents états, la rendant plus sécurisée. Le nouveau concept permet également aux utilisateurs d'authentification NIS/LDAP, NFS et DNS de déployer un pare-feu sans aucune personnalisation supplémentaire nécessaire (bien qu'il soit toujours possible de personnaliser le port et le protocole).

REMARQUE : Ce changement s'applique également à l'Outil de configuration du niveau de sécurité (redhat-config-securitylevel).

L'installation via VNC est maintenant prise en charge. Pour lancer une installation basée sur VNC, utilisez vnc comme une option de démarrage. Un mot de passe peut également être défini en ajoutant "vncpassword=<password>" aux options de démarrage. L'affichage VNC sera "<host>:1", où <host> représente le nom d'hôte ou l'adresse IP du système qui installe Red Hat Enterprise Linux.

Il est également possible que le programme d'installation Red Hat Enterprise Linux mette en oeuvre une connexion sur un client VNC en écoute. L'option de démarrage vncconnect est utilisée dans ce but :

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

(où <client> est le nom d'hôte ou l'adresse IP du système exécutant le client VNC en écoute et où <port> est une spécification de port facultative utilisée si le client VNC n'est pas en écoute sur le port 5500, qui est le port par défaut pour ce type de connexion). Les exemples suivants montrent comment l'option de démarrage est spécifiée pour les ports (standards ou non) :

linux vnc vncconnect=pigdog.example.com

linux vnc vncconnect=pigdog.example.com:27910

Le système qui exécutera le client VNC en écoute doit alors lancer le logiciel adéquat pour exécuter le client VNC en mode d'écoute. Pour le client VNC fourni avec Red Hat Enterprise Linux 3, la commande suivante est suffisante :

vncviewer -listen

De plus, une nouvelle directive kickstart a été ajoutée pour prendre en charge les installations basées sur VNC :

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

où --password <password> est un paramètre facultatif pour spécifier un mot de passe VNC et où [--connect <host>[:<port>]] est un paramètre facultatif pour spécifier l'hôte (et le port, facultativement) d'un système exécutant un client VNC en écoute.

REMARQUE : Si vous spécifiez des options de démarrage relatives à VNC, elles écraseront les options correspondantes présentes dans le fichier kickstart.

Chinois (simplifié ou traditionnel)

Japonais

Coréen

Chinois simplifié

Pour saisir des caractères chinois simplifiés, utilisez la méthode d'entrée miniChinput. Pour activer cette méthode, appuyez sur Ctrl-Espace.

La méthode d'entrée miniChinput prend en charge les modules suivants :

· entrée intelligent pinyin

· entrée gbk pinyin

· entrée shuang pin

· entrée de code interne (code gb18030)

Le paquetage miniChinput est installé par défaut si la prise en charge du chinois simplifié est sélectionnée durant l'installation.

Chinois traditionnel

Pour saisir des caractères chinois traditionnels, utilisez la méthode d'entrée xcin. Pour activer cette méthode, appuyez sur Ctrl-Espace. Si vous appuyez sur Shift-Ctrl ou Ctrl-Alt-Num, vous pourrez passer d'un module d'entrée à l'autre.

La méthode d'entrée xcin prend en charge les modules suivants :

· CJ

· Simplex

· Phone

· CantonPing

· Bimsphone

· Bimspinyin

· Array30

· Cantonping (aucune intonation)

Le paquetage xcin est installé par défaut si la prise en charge du chinois traditionnel est sélectionnée durant l'installation.

Japonais

Pour saisir des caractères japonais, utilisez les méthodes d'entrée Canna, FreeWnn ou skk. Pour activer cette méthode, appuyez sur Shift-Espace.

Les modules suivants sont pris en charge :

· romaji

· kana (uniquement Canna — selon le fichier de configuration)

Les paquetages Canna, FreeWnn et skkinput sont installés par défaut si la prise en charge du japonais est sélectionnée durant l'installation.

Coréen

Pour saisir des caractères coréens, utilisez la méthode d'entrée ami. Pour activer cette méthode, appuyez sur Shift-Espace.

Le paquetage ami est installé par défaut si la prise en charge du coréen est sélectionnée durant l'installation.

Le serveur HTTP Apache a été mis à jour et correspond maintenant à la version 2.0. Le paquetage mis à jour qui remplace la version 1.3 a été renommé httpd.

· Les modules auth_ldap, mod_put, mod_roaming, mod_auth_any, mod_bandwidth, mod_throttle et mod_dav ont été supprimés.

· La fonctionnalité WebDAV fait désormais partie du paquetage httpd.

REMARQUE : Il est nécessaire d'apporter des changements aux fichiers de configuration existants. Les modules tiers d'Apache peuvent également avoir besoin d'une mise à jour. Reportez-vous au guide de migration contenu dans /usr/share/doc/httpd-*/migration.html pour de plus amples informations.

Le spouleur d'imprimante LPRng a été remplacé par CUPS et l'Outil de configuration de l'imprimante (redhat-config-printer) est l'outil recommandé pour sa configuration. Il peut être lancé à partir du menu Paramètres de système à l'aide de l'entrée Impression.

L'Outil de configuration du niveau de sécurité (redhat-config-securitylevel) a été simplifié. Les anciens paramètres "Élevé", "Moyen" et "Aucun pare-feu" ont été remplacés par un contrôle plus direct de style activé / désactivé. De plus, la configuration du pare-feu par défaut reconnaît désormais différents états, la rendant plus sécurisée. Le nouveau concept permet également aux utilisateurs d'authentification NIS/LDAP, NFS et DNS de déployer un pare-feu sans qu'aucune personnalisation supplémentaire ne soit nécessaire (bien qu'il soit toujours possible de personnaliser le port et le protocole).

REMARQUE : Ce changement s'applique également au programme d'installation de Red Hat Enterprise Linux.

GNOME Print Manager est un simple outil de gestion graphique des files d'attente d'impression qui est désormais inclus. Il peut être lancé à partir du menu Outils de système à l'aide de l'entrée Gestionnaire d'impression. De plus, lorsqu'une tâche d'impression est dans la file d'attente, une icône apparaîtra dans la zone de notification système du tableau de bord.

Red Hat Enterprise Linux 3 inclut l'utilitaire setarch. Setarch permet de changer la sortie produite par la commande uname. Cela est utile pour un certain nombre de raisons, comme l'exécution d'applications 32-bit (écrites pour s'attendre à une valeur donnée de uname -m) dans des environnements 64-bit.

Voici le format de la commande setarch :

setarch <arch> <command>

(où <arch> représente la chaîne d'architecture désirée (comme i386) et où <command> représente la commande à exécuter alors que l'architecture a été modifiée.) Notez bien que <command> peut être omis, dans quel cas /bin/sh est exécuté.

De plus, certaines applications (comme des versions précédentes de Java) sont écrites en assumant un espace d'adressage virtuel de 3 Go ; lorsqu'elles sont exécutées sur des systèmes disposant d'espaces d'adressage virtuel plus important (comme des systèmes 64-bit basés sur x86-64 ou des systèmes 32-bit exécutant le noyau hugemem), ces applications peuvent mal fonctionner. L'utilitaire setarch permet d'émuler un espace d'adressage virtuel de 3 Go, permettant ainsi à de telles applications de fonctionner correctement :

setarch -3 java

Red Hat Enterprise Linux 3 inclut Native POSIX Thread Library (NPTL), une nouvelle implémentation des threads POSIX de Linux. Cette bibliothèque offre des améliorations de performance et une modulabilité accrue.

Cette bibliothèque de threads est conçue pour être compatible en binaire avec l'ancienne implémentation de Linux Thread ; toutefois, les applications qui dépendent des endroits où l'implémentation de Linux Thread diffère du standard POSIX devront être corrigées. Parmi les différences importantes figurent :

· La gestion des signaux est passée d'une gestion par thread à une gestion des signaux selon le processus POSIX.

· getpid() renvoie la même valeur dans tous les threads.

· Les gestionnaires de threads enregistrés avec pthread_atfork ne sont pas exécutés si vfork() est utilisé.

· Aucun gestionnaire de threads.

Si une application ne fonctionne pas correctement avec NPTL, elle peut être exécutée à l'aide de l'ancienne implémentation de LinuxThreads, en réglant la variable d'environnement suivante :

LD_ASSUME_KERNEL=<kernel-version>

Les versions suivantes sont disponibles :

· 2.4.19 — Linuxthreads avec piles flottantes

Notez bien que les logiciels qui utilisent errno, h_errno et _res doivent inclure à l'aide de #include le fichier d'en-tête approprié (errno.h, netdb.h et resolv.h respectivement) avant qu'ils ne soient utilisés. Toutefois, LD_ASSUME_KERNEL=2.4.19 peut être utilisé comme un détour jusqu'à ce que le logiciel soit corrigé.

Les programmes C++ à plusieurs threads utilisant l'annulation de thread peuvent devoir être forcés à utiliser la bibliothèque LinuxThreads à l'aide du paramètre de la variable d'environnement LD_ASSUME_KERNEL=2.4.19. Dans le cas contraire, le programme se terminera de façon anormale si l'annulation n'est pas tenue en compte (vu que l'exception produite n'est pas détectée).

Il est possible que du code C++ nouvellement écrit, qui utilise des fonctions de l'environnement d'exécution C, doive être ajusté de façon à ce qu'il prenne en compte l'annulation. Pour ce faire, utilisez l'une des méthodes suivantes :

· Ne pas marquer la fonction C++ avec throw() (ainsi, les personnes qui appellent savent bien qu'une exception puisse se produire) et compiler le code sans exception. Ceci est l'option de compilation par défaut ; les utilisateurs ne devraient pas spécifier -fno-exceptions lors de la compilation.

· Désactiver complètement l'annulation avant d'entrer les fonctions qui appellent les fonctions C capables d'annulation. Pour ce faire, utilisez l'appel suivant :

pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &oldstate)

Une fois les fonctions C appelées, l'annulation peut être de nouveau activée grâce à l'appel suivant :

pthread_setcancelstate (oldstate, NULL)

REMARQUE : À ce stade, les annulations sont prises en compte et donc la fonction qui appelle pthread_setcancelstate() doit être compilée avec les exceptions activées et doit être marquée comme exception de rejet (throwing).

Un nouveau message système a été ajouté à Red Hat Enterprise Linux 3 :

application bug: <app-name>(<app-pid>) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated.

Ce message (qui est affiché sur la console du système et/ou dans les fichiers journaux du système) indique que l'application n'est pas complètement conforme aux normes concernant la manière dont elle traite les processus enfants. Si vous voyez ce message, vous devriez avertir les développeurs de l'application.

Red Hat Enterprise Linux 3 inclut la possibilité de produire des PIE (Position Independent Executables) pour C, C++ et Java. Cette fonction est activée avec les options GCC -fpie et -fPIE pour compiler, qui sont similaires en utilisation aux options -fpic et -fPIC, respectivement, et au moment du lien à l'option -pie.

Les paquetages fileutils, textutils, sh-utils et stat ont été remplacés par le tout nouveau paquetage coreutils.

Les RPM contenant l'Outil d'administration réseau (redhat-config-network) ont changé de noms et de fonctions. Le RPM redhat-config-network contient l'interface utilisateur graphique des outils, alors que redhat-config-network-tui contient l'outil lui-même (avec son interface utilisateur en mode texte).

Le support pour XHTML1 — la conversion de HTML en XML — a été amélioré. Pour ce faire, le paquetage xhtml1-dtd a été ajouté, les DTD ont été installés dans le catalogue système et un support spécifique a été ajouté dans les outils libxml2 et xsltproc.

La boîte à outils XML a été étendue pour prendre en charge la validation Relax-NG et les capacités de streaming sur des grands fichiers.

Le profileur de tout le système Oprofile a été ajouté à Red Hat Enterprise Linux 3. OProfile est un outil pour les programmeurs, permettant d'analyser les performances du système à l'aide de matériel spécifique intégré dans la plupart des ordinateurs modernes. De la documentation sur OProfile existe dans le paquetage oprofile ; après avoir installé Red Hat Enterprise Linux 3, exécutez la commande rpm -qd oprofile pour obtenir une liste de la documentation disponible. Pour de plus amples informations, consultez le site Web OProfile à l'adresse suivante : http://oprofile.sourceforge.net

REMARQUE : Le support du noyau pour OProfile dans Red Hat Enterprise Linux 3 est basé sur le code pris du noyau de développement 2.5. Ainsi, si vous faites référence à la documentation de OProfile, n'oubliez pas que les caractéristiques affichées comme étant spécifiques à 2.5 s'appliquent en fait au noyau de Red Hat Enterprise Linux, même si la version du noyau est 2.4. Il en est de même pour les caractéristiques affichées comme étant spécifiques à 2.4 qui, en fait, ne s'appliquent pas au noyau de Red Hat Enterprise Linux.

À l'heure actuelle, le système X Window utilise deux sous-systèmes pour les polices de caractères, chacun d'eux étant doté de caractéristiques différentes :

· On fait référence au sous-système original (datant d'il y a plus de 15 ans) en tant que "core X font subsystem". Les polices de caractères produites par ce sous-système ne sont pas lissées, sont traitées par le serveur X et portent des noms comme :

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

- Le sous-système de polices le plus récent est connu en tant que "fontconfig" et permet aux applications d'avoir un accès direct aux fichiers de polices de caractères. Fontconfig est souvent utilisé avec la bibliothèque "Xft" qui permet aux applications de produire les polices de caractères fontconfig à l'écran avec lissage. Fontconfig utilise des noms plus simples comme :

Luxi Sans-10

Avec le temps, fontconfig/Xft remplacera le sous-système de polices de caractères X. En ce moment, les applications utilisant les kits de programmes Qt 3 ou GTK 2 (y compris les applications KDE et GNOME) utilisent les sous-systèmes de polices de caractères fontconfig et Xft ; la plupart des autres applications utilisent la police de caractères X.

Dans le futur, il se peut que Red Hat prenne en charge seulement fontconfig/Xft au lieu du serveur de polices XFS comme la méthode d'accès local, par défaut, aux polices de caractères.

REMARQUE : Il existe une exception à l'utilisation de sous-systèmes de polices de caractères soulignée ci-dessus, à savoir, OpenOffice.org, qui utilise sa propre technologie pour produire les polices.

Si vous souhaitez ajouter de nouvelles polices de caractères à votre système Red Hat Enterprise Linux 3, vous devez savoir que les étapes nécessaires à cette opération dépendent du sous-système de polices utilisé par les nouvelles polices de caractères. Pour le sous-système de polices X, vous devez :

1. Créer le répertoire /usr/share/fonts/local/ (s'il n'existe pas encore) :

mkdir /usr/share/fonts/local/

2. Copier le nouveau fichier de polices de caractères dans /usr/share/fonts/local/

3. Mettre à jour les informations de polices en exécutant les commandes suivantes (notez qu'à cause de restrictions de formatage, les commandes suivantes peuvent apparaître sur plus d'une ligne ; chaque commande devrait être saisie sur une seule ligne) :

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

mkfontdir /usr/share/fonts/local/

4. Si vous avez dû créer /usr/share/fonts/local/, vous devez ensuite l'ajouter au chemin d'accès du serveur de polices X (xfs) :

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

Ajouter de nouvelles polices au sous-système de polices fontconfig est une opération plus simple ; en effet, il suffit de copier le nouveau fichier de polices dans le répertoire /usr/share/fonts/ (les utilisateurs individuels peuvent modifier leur configuration de polices personnelle en copiant le fichier de polices dans le répertoire ~/.fonts/).

Une fois la nouvelle police copiée, utilisez fc-cache pour mettre à jour le cache d'informations de polices :

fc-cache <directory>

(où <directory> correspondrait au répertoire /usr/share/fonts/ ou ~/.fonts/.)

Les utilisateurs individuels peuvent également installer des polices de manière graphique, en navigant dans fonts:/// sous Nautilus et en y faisant glisser le nouveau fichier de polices.

REMARQUE : Si le nom de fichier de polices se termine par ".gz", il a été compressé avec gzip et doit donc être décompressé (avec la commande gunzip) avant que le sous-système de polices fontconfig ne puisse utiliser la police.

En raison de la transition sur un nouveau système de polices basé sur fontconfig/Xft, les applications GTK+ 1.2 ne sont touchées par aucun changement effectué au moyen du dialogue Préférences de polices. Pour ces applications, une police peut être configurée en ajoutant les lignes suivantes au fichier ~/.gtkrc.mine :

style "user-font" {

fontset = "<font-specification>"

}

widget_class "*" style "user-font"

(où <font-specification> correspond à la spécification de police dans le style utilisé par les applications traditionnelles comme "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)

Par défaut, l'agent de transport de courrier (MTA) Sendmail n'accepte pas les connexions réseau venant d'hôtes autres que l'ordinateur local. Si vous voulez configurer Sendmail comme serveur pour d'autres clients, vous devez éditer /etc/mail/sendmail.mc et changer la ligne DAEMON_OPTIONS pour qu'il accepte les périphériques réseau (ou vous pouvez entièrement mettre en commentaire cette option en utilisant le délimiteur de commentaire dnl). Vous devez ensuite recréer /etc/mail/sendmail.cf en lançant la commande suivante (en tant que super-utilisateur) :

make -C /etc/mail

Notez bien que le paquetage sendmail-cf doit être installé pour que cette opération réussisse.

Le serveur FTP par défaut dans Red Hat Enterprise Linux 3 est désormais vsftpd et est exécuté comme un service SysV.

Passez à l'interprétation de fdisk sur les multiplicateurs de taille de partition

La commande fdisk adopte désormais une différente interprétation des multiplicateurs de taille qui peuvent être utilisés lors de la création de nouvelles partitions de disque. Les suffixes de taille K, M et G font maintenant référence à des multiples de milliers, de millions et de billions d'octets, respectivement. Cela est plus consistant avec les spécifications de taille de disque fournies par les fabricants de disques.

Ainsi, si un utilisateur souhaite créer une partition de 512 Mo, la valeur de la taille spécifiée par un suffixe "M" serait égale à 512*1024*1024 (536,870,912), arrondie à un multiple de million (537,000,000), puis divisée par un million (537), le résultat étant alors une spécification de taille de +537M.

Alors que la compatibilité pour les exécutables et les objets partagés dynamiquement (DSO, également connus en tant que bibliothèques partagées) créés sur des versions précédentes de Red Hat Linux et Red Hat Enterprise Linux est prise en charge, il n'en est pas de même pour les fichiers objets (.o). Ces fichiers créés sur des versions précédentes peuvent être utilisés sur Red Hat Enterprise Linux 3 pour créer de nouveaux exécutables ou DSO uniquement si ils sont construits sans aucun fichier d'en-tête système.

Dans le cas contraire, la seule manière d'utiliser ces fichiers est de lier les fichiers objets à la version de compatibilité de glibc (faisant partie du paquetage compat-glibc). Tout fichier objet nouvellement généré doit utiliser les en-têtes du paquetage de compatibilité. Par exemple, pour compiler les fichiers objets, ajoutez la ligne suivante au début de la ligne de commande du compilateur :

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

Afin de lier l'exécutable ou le DSO résultant, ajoutez la ligne suivante à la ligne de commande :

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

Tout mélange d'anciens fichiers objets et de fichiers compilés sur les en-têtes système courants peut avoir des résultats négatifs. Le fait de lier d'anciens fichiers objets avec des bibliothèques de système régulières peut résulter en des exécutables complètement inutilisables ou des exécutables avec des bogues (comme la corruption de mémoire).

Le noyau Red Hat Enterprise Linux 3 utilise une nouvelle technique de paquetage de noyau. Vu que la variété de matériel disponible est pratiquement illimitée, Red Hat ne peut pas complètement prendre en charge tous les composants matériels. Ainsi, alors que les modules de noyau pour le matériel supporté, restent dans les paquetages kernel standards, une série de nouveaux paquetages de noyau non supportés est incluse avec Red Hat Enterprise Linux 3.

Pour chaque paquetage de noyau vendu, il existe un paquetage de noyau non supporté correspondant. Par exemple, le paquetage de noyau non supporté pour kernel-smp-2.4.21-3.EL.i686.rpm est kernel-smp-unsupported-2.4.21-3.EL.i686.rpm.

REMARQUE : Les paquetages de noyau non supportés ne sont pas installés par le programme d'installation de Red Hat Enterprise Linux. Ainsi, afin d'utiliser les modules de noyau non supportés, vous devez installer manuellement le paquetage de noyau non supporté correspondant au noyau utilisé par votre système.

Une fois installé, vous devez utiliser la commande suivante pour mettre à jour l'arborescence de dépendances de modules et votre initrd.

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

où <kernel-version> représente la version du noyau installé.

Les pilotes contenus au sein des paquetages de noyau non supportés sont offerts selon les efforts fournis. Cela signifie que les mises à jour et les corrections seront peut-être incorporées au fil du temps et que les pilotes ne sont pas couverts par les mêmes prévisions de support que les pilotes complètement pris en charge. Des accords de prise en charge personnalisés couvrant les pilotes dans le paquetage non supporté peuvent être arrangés avec Red Hat dans certaines situations.

Le noyau Red Hat Enterprise Linux 3 inclut une fonctionnalité de mesure de processus plus précise. Ce nouveau mode de mesure de processus utilise des estampilles pour offrir une mesure plus précise des temps morts et des temps de processus. Lorsqu'elle est activée, ces informations sont disponibles au moyen des outils de contrôle habituels (comme top, vmstat et procinfo) et l'appel système getrusage.

Pour activer la mesure de processus basée sur les estampilles, vous devez démarrer votre système à l'aide de l'option de démarrage suivante :

process_timing=<value>

où <value> peut être l'une ou plusieurs des valeurs suivantes. Plusieurs valeurs seront alors séparées par des virgules :

· irq — utiliser des estampilles pour représenter les interruptions IRQ

· softirq — utiliser des estampilles pour représenter les temps softirq dans le noyau

· process — permettre aux processus d'activer la mesure de processus basée sur les estampilles sur eux-mêmes (elle sera alors désactivée pour tous les processus par défaut)

· all_process — forcer la mesure de processus basée sur les estampilles sur tous les processus (y compris les tâches inactives)

· everything — équivalent à spécifier irq,softirq,all_process

Si le système est démarré avec l'option process, aucun processus n'a initialement la mesure de processus basée sur les estampilles activée par défaut. Toutefois, les processus peuvent alors utiliser l'appel système prctl() pour déterminer ainsi que modifier le mode de mesure de processus. L'appel système pour déterminer le mode de mesure de processus est le suivant :

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

L'appel système pour définir le mode de mesure de processus est :

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

(où <mode> est PR_TIMING_STATISTICAL pour activer le mode de mesure de processus traditionnel ou PR_TIMING_TIMESTAMP pour activer le mode de mesure de processus basé sur les estampilles.) Notez que si vous activez un mode de mesure de processus, l'autre mode sera automatiquement désactivé.

REMARQUE : L'appel système prctl() peut être utilisé uniquement sur les systèmes démarrés avec la valeur process. Sinon, l'appel système renverra -EINVAL. Cela inclut les tentatives de désactivation de la mesure de processus basée sur les estampilles sur les systèmes démarrés avec l'option all_process.

Le mode de mesure d'un processus enfant est hérité de son parent ; cependant, l'enfant peut utiliser l'appel système prctl() pour modifier son propre mode de mesure de processus (selon les conditions décrites dans la remarque précédente).

Le pilote BusLogic (pour certains adaptateurs bus hôte SCSI Mylex) est fourni dans les paquetages du noyau standards, mais n'est pris en charge que lorsque le noyau est un système d'exploitation hôte au sein du logiciel de machine virtuelle VMWare™. Cela est dû au fait que VMWare présente un adaptateur SCSI émulé au pilote BusLogic et cet environnement a été proprement testé et pris en charge par VMWare, Inc. Le pilote BusLogic n'est pas pris en charge sur les adaptateurs hôtes SCSI physiques parce que ce pilote n'a pas été maintenu dans le noyau Linux officiel depuis plusieurs années et n'a pas reçu de tests intensifs dans le noyau Red Hat Enterprise Linux.

Le pilote qla1280 (pour les adaptateurs SCSI ISP1x80/1x160 Qlogic) n'a pas été maintenu dans le noyau Linux officiel depuis plusieurs années. Bien que ce pilote fonctionne correctement avec l'architecture x86 Intel, il ne fonctionne pas correctement avec les autres architectures. Ainsi, Red Hat ne prend en charge que le pilote qla1280 sur les plates-formes x86 Intel.

La fonction netdump est actuellement désactivée. Le paquetage netdump est inclus. Ainsi, si la fonction netdump est activée dans une prochaine mise à jour du noyau, elle deviendra disponible une fois le noyau capable de netdump installé.

Des nouveaux supports de noyau ont été ajoutés afin d'offrir des fonctionnalités IPv6. Ce support est consistant avec l'implémentation basée sur 2.6 comme 2.6.0-test3.

Notez que Red Hat n'implémentera pas de fonctionnalités IPv6 supplémentaires (comme les "draft standards" pour Mobile IP) pour cette version de Red Hat Enterprise Linux ; notre but est de nous concentrer exclusivement sur les bogues des fonctionnalités existantes.

Les AE (Attributs Étendus) et les LCA (Listes de Contrôle d'Accès) sont maintenant disponibles pour ext3 et NFS. De plus, la fonctionnalité de LCA est disponible pour NFS.

Red Hat Enterprise Linux 3 contient un noyau fournissant la prise en charge d'AE et de LCA pour le système de fichiers ext3. Des extensions de protocoles ont également été ajoutées à NFS pour le support d'opérations de LCA pour les systèmes de fichiers exportés de façon NFS.

Pour activer les LCA sur un système de fichiers monté localement, le système de fichiers doit être monté avec l'option de montage -o acl. Par défaut, le serveur NFS utilise les LCA si le système de fichiers sous-jacent les prend en charge. Pour désactiver cette fonction, vous devez spécifier l'option d'export no_acl.

Les AE sont utilisés intrinsèquement pour le support LCA. Afin d'utiliser les AE séparément, le système de fichiers doit être monté avec l'option de montage -o user_xattr.

La prise en charge pour ceci fait partie de plusieurs paquetages :

· kernel — Fournit une prise en charge pour le stockage sur disque des AE et LCA pour les systèmes de fichiers ext3, ainsi que les appels de système pour manipuler les AE et LCA. Finalement, le paquetage du noyau fournit des mécanismes pour appliquer les LCA sur l'accès aux fichiers.

· e2fsprogs — Inclut des informations sur les formats des nouveaux attributs étendus sur disque afin que fsck puisse vérifier des systèmes de fichiers utilisant la nouvelle fonction.

· attr, libattr — Fournit l'accès aux attributs étendus attachés aux fichiers.

· acl, libacl — Fournit des outils pour établir, modifier et interroger les LCA définies sur les fichiers.

· libattr-devel, libacl-devel — Ces bibliothèques incluent des fichiers pour la construction de programmes utilisant les bibliothèques acl et attr.

· star — Un outil d'archivage qui peut créer et décompresser aussi bien des archives de format tar que pax et qui peut également sauvegarder et restaurer les AE et LCA.

REMARQUE : Les options disponibles pour star ne sont pas complètement équivalentes à celles disponibles pour tar ; assurez-vous donc de relire la page de manuel pour star.

· samba — Samba peut exporter la fonctionnalité LCA dans cette version. Consultez la documentation de samba pour toute information concernant l'activation de cette dernière dans votre configuration.

De plus, le paquetage coreutils a été mis à jour afin que les commandes cp et mv copient les LCA et AE associés à un fichier.

Pour de plus amples informations sur l'établissement et la lecture des LCA, consultez les pages de manuel relatives à setfacl et getfacl. Vous trouverez des informations générales sur les LCA dans la page de manuel de acl.

REMARQUE : Les commandes normales tar et dump ne sauvegarderont pas les LCA et AE.

Compatibilité avec d'anciens systèmes :

Tout système de fichiers ext3 ne contenant pas de LCA ou AE définis, fonctionnera de manière inchangée sur d'anciens noyaux. Il peut être vérifié au moyen des anciens utilitaires e2fsprogs.

Une fois un AE ou une LCA défini(e) sur un fichier quelconque d'un système de fichiers donné, ce système de fichiers prendra l'attribut ext_attr. Cet attribut peut se voir en utilisant la commande suivante :

tune2fs -l <filesystemdevice>

Un système de fichiers ayant acquis l'attribut ext_attr peut être monté avec d'anciens noyaux, mais ces derniers ne pourront bien sûr appliquer aucune des LCA qui ont été établies.

REMARQUE : Les anciennes versions du programme de vérification de systèmes de fichiers e2fsck refuseront de vérifier un tel système de fichiers avec l'attribut ext_attr. Cela correspond aux versions du paquetage e2fsprogs avant 1.22.

Le noyau Red Hat Enterprise Linux 3 prend maintenant en charge NFS sur TCP. Pour utiliser NFS sur TCP, vous devez inclure l'option "-o tcp" à la commande mount lors du montage du système de fichiers exporté de façon NFS sur le système client.

REMARQUE : Le protocole de transport par défaut pour NFS est toujours UDP. Utilisez la commande mount avec l'option "-o tcp" afin de monter un système de fichiers exporté de façon NFS à l'aide de UDP ; sinon, UDP sera utilisé par défaut.

Dans ce noyau, la commande suivante a été ajoutée pour rechercher tout nouveau périphérique sur tous les adaptateurs hôte SCSI attachés :

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

Cette ajout n'est pas actuellement standard. Dans les futurs noyaux, un paramètre différent pourrait être utilisé pour offrir la même capacité, ou les sémantiques du même paramètre (scan-new-devices) pourraient changer, vu que Red Hat recherche le noyau Linux à cet endroit.

Changement de sémantique de permissions pour le verrouillage de mémoire en mode utilisateur

Red Hat Enterprise Linux 3 permet maintenant aux processus autres que ceux de root d'utiliser des appels système de verrouillage de mémoire en mode utilisateur tout en respectant leurs limites de ressources RLIMIT_MEMLOCK. La limite par défaut est d'une page physique par processus. Les limites peuvent être de nouveau assignées par l'administrateur système par id d'utilisateur, id de groupe ou sur tout le système grâce au fichier /etc/security/limits.conf. Les processus root ne sont plus affectés par cette limite de ressources.

Les appels système affectés par ce changement de sémantique sont mlock(2), munlock(2), mlockall(2), munlockall(2) et shmctl(2).