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

La version de glibc fournie avec Red Hat Enterprise Linux 4 effectue des contrôles de sanité internes supplémentaires afin d'éviter et de détecter toute corruption de données dès que possible. Par défaut, en cas de corruption détectée, un message semblable à celui reproduit ci-dessous sera affiché lors d'une erreur standard (ou journalisé via syslog si stderr n'est pas ouvert):

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

Par défaut, le programme qui a généré cette erreur sera également arrêté; cependant, cette situation (et la création ou non d'un message d'erreur) peut être contrôlée par le biais de la variable d'environnement MALLOC_CHECK_. Les paramètres suivants sont pris en charge:

Si vous possédez un programme d'un ISV tiers qui déclenche ce genre de contrôle de corruption et affiche un message, vous devriez soumettre un rapport de défaut au vendeur de l'application étant donné qu'il sagit d'un bogue grave.

Red Hat Enterprise Linux 4 inclut un nouveau noyau connu sous le nom noyau hugemem. Ce noyau prend en charge un espace utilisateur de 4 Go par processus (par rapport à 3 Go pour les autres noyaux) et un espace noyau direct de 4 Go. L'utilisation de ce noyau permet à Red Hat Enterprise Linux de tourner sur des systèmes dont la mémoire principale peut atteindre jusqu'à 64 Go. Le noyau hugemem est requis afin d'utiliser toute la mémoire dans les configurations de systèmes contenant plus de 16 Go de mémoire. Il peut également être avantageux pour des configurations exécutées avec moins de mémoire (par exemple, dans le cas d'une application exécutée qui pourrait bénéficier d'un espace utilisateur par processus plus important).

Pour installer le noyau hugemem, saisissez la commande suivante en étant connecté en tant que super-utilisateur:

rpm -ivh <kernel-rpm>

            

(Où <kernel-rpm> représente le nom du fichier RPM du noyau hugemem — kernel-hugemem-2.6.9-1.648_EL.i686.rpm, par exemple.)

Une fois l'installation terminée, redémarrez votre système, en vous assurant de sélectionner le noyau hugemem nouvellement installé. Après avoir vérifié que votre système fonctionne correctement tout en exécutant le noyau hugemem, vous devriez modifier le fichier /boot/grub/grub.conf afin de démarrer le noyau hugemem par défaut.

Bien que Red Hat Enterprise Linux 4 inclue la prise en charge pour rawio, il s'agit désormais d'une interface obsolète. Si votre application s'octroie l'accès aux périphériques à l'aide de cette interface, Red Hat vous encourage à modifier votre application afin d'ouvrir le périphérique bloc à l'aide de la balise O_DIRECT. L'interface rawio existera pour la durée de vie de Red Hat Enterprise Linux 4, mais sera certainement supprimée lors de prochaines versions.

E/S Asynchrone (ou AIO de l'anglais Asynchronous I/O ) sur des systèmes de fichiers n'est actuellement prise en charge que dans O_DIRECT ou en mode non-tamponné. Notez également que l'interface de sondage asynchrone n'existe plus et que l'AIO sur les tubes n'est plus prise en charge.

Le sous-système audio est désormais basé sur ALSA; les modules OSS ne sont plus disponibles.

Des environnements système utilisant la fonctionnalité du noyau "hugepage" devraient reconnaître que le nom de l'entrée /proc/ contrôlant cette fonction a changé entre Red Hat Enterprise Linux 3 et Red Hat Enterprise Linux 4:

Le noyau faisant partie de Red Hat Enterprise Linux 4 inclut désormais la prise en charge pour le sondage avec Enhanced Disk Device (EDD), qui effectue cette opération afin d'obtenir des informations sur les périphériques disque amorçables directement du BIOS du contrôleur de disque et conserve ces dernières en tant qu'entrée dans le système de fichiers /sys.

Deux options de ligne de commande de noyau importantes et liées à l'EDD ont également été ajoutées:

La version initiale de Red Hat Enterprise Linux 4 ne prend pas en charge les lecteurs de disque dur USB. Cependant, d'autres périphériques de stockage USB, comme flash media, les CD-ROM et les périphériques DVD-ROM sont actuellement pris en charge.

Le noyau faisant partie de Red Hat Enterprise Linux 4 inclut le nouveau pilote megaraid_mbox de LSI Logic, qui remplace le pilote megaraid. Le pilote megaraid_mbox qui est d'une conception améliorée, est compatible avec le noyau 2.6 et inclut la prise en charge pour le matériel le plus récent. Cependant, megaraid_mbox ne prend pas en charge le matériel plus ancien qui était supporté par le pilote megaraid.

Les adaptateurs portant l'ID de vendeurs PCI et les paires d'ID de périphériques suivantes ne sont pas pris en charge par le pilote megaraid_mbox:

vendor, device

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

La commande lspci -n peut être utilisée pour afficher les ID des adaptateurs installés sur une machine spécifique. Les produits possédant ces ID sont connus sous les noms de modèle suivants (mais pas uniquement):

Dell et LSI Logic ont indiqué qu'ils ne prennent plus en charge ces modèles dans le noyau 2.6. Par conséquent, ces adaptateurs ne sont plus pris en charge sous Red Hat Enterprise Linux 4.

La version orginale de Red Hat Enterprise Linux 4 n'inclut ni l'initiateur du logiciel iSCSI ni sa prise en charge cible. La prise en charge de iSCSI est en cours d'évaluation pour une mise à jour et un ajout ultérieur dans Red Hat Enterprise Linux 4.

Le pilote Emulex LightPulse Fibre Channel (lpfc) fait actuellement l'objet de révision publique pour une inclusion possible dans le noyau Linux 2.6. Il est inclus dans Red Hat Enterprise Linux 4 à des fins de test. Des changements au niveau du pilote sont attendus. S'il y a des problèmes avec le pilote ou, si pour une raison quelconque son inclusion n'est pas possible dans le noyau Linux 2.6, il se peut que le pilote soit retiré de la version finale de Red Hat Enterprise Linux.

Le pilote lpfc connaît actuellement les problèmes suivants:

Dans le passé, le processus de mise à jour du noyau ne changeait pas le noyau par défaut dans la configuration du chargeur de démarrage du système.

Red Hat Enterprise Linux 4 change ce comportement afin que des noyaux nouvellement installés deviennent la valeur par défaut. Ce comportement s'applique à toutes les méthodes d'installation (y compris rpm -i).

Ce comportement est contrôlé par deux lignes dans le fichier /etc/sysconfig/kernel :

Afin d'éliminer la redondance inhérente à la présence d'un paquetage séparé pour le code source du noyau, alors que ce même code source existe déjà dans le fichier .src.rpm du noyau, Red Hat Enterprise Linux 4 n'inclut plus le paquetage kernel-source. Les utilisateurs ayant besoin d'accéder aux sources du noyau peuvent les trouver dans le fichier noyau .src.rpm. Pour créer une arborescence source éclatée à partir de ce fichier, effectuez les étapes suivantes (notez bien que <version> fait référence à la spécification de la version relative au noyau actuellement en cours d'exécution) :

Vous pouvez alors continuer comme d'habitude.

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 inclut une version mise à jour du client de messagerie graphique Evolution. Cette version contient un certain nombre de nouvelles fonctionnalités, y compris :

Le paquetage gimp-perl a été supprimé de Red Hat Enterprise Linux 4 parce que GIMP a été mis à jour vers la version 2.0 et parce que les liaisons Perl n'étaient ni prêtes, ni incluses dans le paquetage principal.

Les utilisateurs de scripts Perl dans GIMP devraient installer le module Gimp Perl depuis l'adresse suivante : http://www.gimp.org/downloads/.

ja_JP.eucJP devient ja_JP.UTF-8

ko_KR.eucKR devient ko_KR.UTF-8

zh_CN.GB18030 devient zh_CN.UTF-8

zh_TW.Big5 devient zh_TW.UTF-8

Langues indiennes — iiimf-le-unit

Japonais — iiimf-le-canna

Coréen — iiimf-le-hangul

Chinois simplifié — iiimf-le-chinput

Chinois traditionnel — iiimf-le-xcin

ami entraîne l'installation de iiimf-le-hangul

kinput2 entraîne l'installation de iiimf-le-canna

miniChinput entraîne l'installation de iiimf-le-chinput

xcin entraîne l'installation de iiimf-le-xcin

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 que les périphériques réseau soient acceptés (ou vous pouvez mettre en commentaire toute 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.

Sous la configuration de sécurité SELinux par défaut, ce démon est couvert par la politique ciblée (ou targeted policy). Ce faisant, la sécurité est considérablement améliorée en accordant ou refusant spécifiquement l'accès httpd aux objets système. Cependant, étant donné que cette situation a le potentiel de créer des problèmes avec des applications qui fonctionnaient parfaitement auparavant (telles que celles qui utilisent PHP), il est essentiel de bien comprendre comment SELinux fonctionne afin de garantir que votre configuration soit à la fois sécurisée et fonctionnelle.

Par exemple, une valeur booléenne peut être paramétrée de manière à donner une permission spécfique à httpd pour qu'il lise les objets dans ~/public_html/ pour autant que ces derniers soient identifiés avec le contexte de sécurité httpd_sys_content_t. Le démon d'Apache ne peut pas avoir accès à des objets (fichiers, applications, périphériques et autres processus) qui ont un contexte de sécurité dont l'accès à httpd n'est pas spécifiquement accordé par SELinux.

En accordant à Apache l'accès seulement à ce dont il a besoin pour remplir son rôle, le système est protégé contre des démons httpd compromis ou mal configurés.

En raison de la présence nécessaire de répertoires Linux standard et de permissions de fichiers ainsi que celle d'étiquettes de contexte SELinux pour les fichiers, les administrateurs et les utilisateurs devront savoir comment changer les étiquettes des fichiers. Parmi des exemples de ré-étiquetage figurent les commandes suivantes (une commande pour ré-étiqueter récursivement le contenu d'un répertoire et une commande pour le ré-étiquetage d'un seul fichier) :

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

            

Un fichier ou répertoire qui n'est pas étiqueté avec un contexte dans la liste des types possibles d'Apache créera une erreur de type 403 Forbidden (403 Interdit).

Vous pouvez configurer des valeurs booléennes ou désactiver de manière sélective la couverture de politique ciblée seulement pour Apache (ou tout démon couvert) à l'aide de system-config-securitylevel. Sous l'onglet SELinux, dans la section Modifier la politique SELinux, vous pouvez changer les valeurs booléennes pour Apache. Si vous le souhaitez, vous pouvez sélectionner Désactiver protection SELinux pour le démon httpd, qui désactive la transition de unconfined_t (le type par défaut qui agit de manière transparente comme sécurité Linux standard sans SELinux) au type de démon spécifique, c'est-à-dire httpd_t. La désactivation de cette transition annule en fait la couverture de SELinux pour ce démon précis, revenant ainsi à la sécurité Linux standard seulement.

Pour obtenir de plus amples informations sur Apache et la politique SELinux, reportez-vous au guide de politique SELinux intitulé Red Hat SELinux Policy Guide qui est disponible dans sa version anglaise à l'adresse suivante : http://www.redhat.com/docs.

Par défaut, le démon httpd est maintenant démarré en utilisant le paramètre de lieu C (locale C), plutôt que la valeur du paramètre de lieu (locale) configurée du système. Ce comportement peut être modifié en paramétrant la valeur HTTPD_LANG dans le fichier /etc/sysconfig/httpd.

Le fichier de configuration /etc/php.ini par défaut a été modifié afin d'utiliser les valeurs par défaut de "production" plutôt que celles de "developpement" ; parmi les différences importantes figurent :

Le paquetage utilise désormais l'interface SAPI "apache2handler" pour l'intégration avec Apache httpd 2.0 plutôt que l'interface SAPI "apache2filter". Lors de la mise à niveau depuis des versions précédentes, les directives SetOutputFilter devraient être supprimées du fichier /etc/httpd/conf.d/php.conf.

Les modifications suivantes ont été effectuées sur les modules d'extension PHP :

Red Hat Enterprise Linux 4 inclut le nouveau paquetage xorg-x11-deprecated-libs. Ce dernier contient des bibliothèques en relation avec X11 qui sont désormais obsolètes et risquent d'être retirées des versions futures de Red Hat Enterprise Linux. En incluant ainsi des bibliothèques obsolètes, la compatibilité binaire avec des applications existantes est maintenue tout en donnant aux fournisseurs de logiciels tiers le temps nécessaire pour effectuer la transition de leurs applications afin qu'elles n'utilisent plus ces bibliothèques.

Actuellement, ce paquetage contient la bibliothèque Xprint (libXp). Cette dernière ne devrait pas être utilisée dans le développement de nouvelles applications. Les applications qui utilisent actuellement cette bibliothèque devraient commencer à migrer vers les API d'impression prises en charge, libgnomeprint/libgnomeprintui.

Il y a eu une certaine confusion par rapport à des problèmes relatifs aux polices de caractères sous X Window System dans des versions récentes de Red Hat Enterprise Linux (et des versions précédentes de Red Hat Linux). À l'heure actuelle, il existe deux sous-systèmes de polices, chacun d'eux contenant des caractèristiques différentes :

- Le sous-système original (datant d'il y a plus de 15 ans) auquel on fait référence en tant que "core X font subsystem". Les polices de caractères rendues 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 Enterprise Linux ne prenne en charge que fontconfig/Xft au lieu du serveur de polices XFS comme la méthode d'accès par défaut, aux polices de caractères locales.

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 de rendu des polices).

Si vous souhaitez ajouter de nouvelles polices de caractères à votre système Red Hat Enterprise Linux 4, 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 déjà) :

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'en raison de restrictions de formatage, les commandes suivantes peuvent apparaître sur plusieurs lignes ; lors de leur utilisation cependant, 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/

L'ajout 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 personnelle de polices 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 des informations de polices :

fc-cache <directory>

(Où <directory> devrait correspondre 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 du 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 vers 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-*-*-*-*-*-*".)

L'ensemble complet des commandes LVM2 est désormais installé dans /usr/sbin/. Dans des environnements de démarrage où /usr/ n'est pas disponible, il est nécessaire d'ajouter /sbin/lvm.static devant chaque commande (/sbin/lvm.static vgchange -ay, par exemple).

Dans des environnements où /usr/ n'est pas disponible, il n'est plus nécessaire d'ajouter lvm devant chaque commande (/usr/sbin/lvm vgchange -ay devient donc /usr/sbin/vgchange -ay, par exemple).

Les nouvelles commandes LVM2 (telles que /usr/sbin/vgchange -ay et /sbin/lvm.static vgchange -ay) détectent si vous exécutez un noyau 2.4 et invoque de manière transparente les anciennes commandes LVM1 si nécessaire. Les commandes LVM1 ont été rebaptisées et se terminent désormais par ".lvm1" (par exemple, /sbin/vgchange.lvm1 -ay).

Le démon du cache des services de noms nscd a la possibilité de maintenir un cache persistant lors de son redémarrage ou lors de redémarrages du système. Chaque base de données (respectivement utilisateur, groupe et hôte) peut faire l'objet de persistance en paramétrant la ligne appropriée dans /etc/nscd.conf sur "yes". Les entrées ne sont pas supprimées du cache tant qu'elles n'ont pas été déclarées comme étant sans intérêt. Toutes les entrées dont la durée de vie expire mais qui sont tout de même dignes d'intérêt sont automatiquement rechargées, ce qui est d'une grande aide lors de situations où le répertoire et des services de noms ne sont pas disponibles temporairement.

Sous la configuration de sécurité SELinux par défaut, ce démon est couvert par la politique ciblée (ou targeted policy). Ainsi, la sécurité est considérablement améliorée en accordant ou refusant spécifiquement l'accès aux objets système que le démon utilise normalement. Cependant, étant donné que cette situation a le potentiel de créer des problèmes avec des applications qui fonctionnaient parfaitement auparavant, il est essentiel de bien comprendre comment SELinux fonctionne afin de garantir que votre configuration soit à la fois sécurisée et fonctionnelle.

Pour obtenir davantage d'informations sur la politique SELinux, reportez-vous au manuel Red Hat SELinux Policy Guide disponible dans sa version anglaise à l'adresse suivante : http://www.redhat.com/docs.