2. Modifications dans Fedora pour les administrateurs systèmes
Il y a des modifications significatives lors d'une installation via le démarrage direct sur le noyau tel que PXE. Une installation normale à partir d'un média d'installation n'est pas concernée.
Les utilisateurs avancés peuvent faire un certain nombre d'installations réseau différentes, impliquant généralement la mise en place d'un environnement minimal du noyau pour procéder à l'installation. Cette opération a subit des modifications significatives dans Fedora 17.
Dans F16, en général, il suffit de préciser l'emplacement du noyau et de initrd, et l'installation devrait fonctionner - kernel/initrd va chercher stage1 et stage1 va chercher stage2.
Sans chargeur, ce n'est plus le cas : quand on démarre directement sur le noyau, l'emplacement de stage2 doit être précisé. Dit autrement : utilisez repo= ou stage2= (ou inst.repo= ou inst.stage2=, comme il est recommandé) en pointant vers un dépôt. Si l'image de stage2 est sur un serveur mais que les paquets pour l'installation sont sur un autre serveur, stage2= doit être utilisé : repo= devrait seulement être employé si le serveur contenait tout ce qui est nécessaire à l'installation (à la fois l'image de stage2 et tous les paquets à installer). Notez que stage2= s'attend toujours à voir l'arborescence d'un « dépôt ». Vous ne pouvez pas juste indiquer le chemin direct vers un fichier squashfs.img (ce qui était la façon d'utiliser stage2= jusqu'à F15 quand c'était possible).
Par exemple :
label linux
kernel vmlinuz
append initrd=initrd.img
n'est plus valide. Il faut préciser le miroir avec
repo :
label linux
kernel vmlinuz
append initrd=initrd.img repo=http://dl.fedoraproject.org/pub/fedora/linux/development/17/x86_64/os/
ou
stage2 :
label linux
kernel vmlinuz
append initrd=initrd.img stage2=http://my.internal.server/17/x86_64/os/
(ou tout autre miroir valide).
2.3.1. Vérification de la qualité du mot de passe
Fedora dispose désormais d'une bibliothèque configurable unique,
libpwquality, pour vérifier la qualité des nouveaux mots de passe utilisés par les comptes du système. La totalité des contrôles de qualité fournis par cette bibliothèque est configurée en modifiant le fichier de configuration
/etc/security/pwquality.conf.
Les développeurs souhaitant appeler cette API à partir de leurs applications trouveront sa description dans le fichier pwquality.h fourni par le paquet libpwquality-devel. Un wrapper python, python-pwquality, est aussi fourni.
2.3.2. SELinux Deny Ptrace
Un nouveau booléen SELinux, deny_ptrace, a été ajouté. Il est recommandé aux utilisateurs qui n'ont pas l'intention de déboguer des applications sur leur machine de définir cette valeur. Ce booléen empêche les processus malveillants d'être capable de lire la mémoire, voire d'attaquer d'autres processus utilisant les outils de débogages, y compris ptrace et gdb.
De telles attaques sont ainsi empêchées même si le processus malveillant est lancé en tant que root ou s'il attaque un processus en cours ayant le même contexte SELinux ou le même label. Pour activer en permanence la protection prévue par le booléen
deny_ptrace, exécuter la commande suivante en tant que root :
# setsebool -P deny_ptrace 1
Pour désactiver temporairement la protection prévue par le booléen deny_ptrace, exécuter la commande suivante en tant que root :
# setsebool deny_ptrace 0
2.3.3. Répertoire privé /tmp pour les services
Un certain nombre de services gérés par systemd ont été modifiés pour utiliser sa capacité à fournir un répertoire /tmp privé. On a trouvé des services privilégiés utilisant /tmp et /var/tmp interférant avec des utilisateurs non privilégiés, pouvant conduire à une augmentation des privilèges. Utiliser des répertoires /tmp privés pour ces services empêche ce type d'attaque.
La directive à ajouter au fichier
systemd pour les services modifiés est :
[Service]
PrivateTmp=true
2.3.4. Conteneurs sécurisés
Un nouvel outil, sandbox, a été créé afin de simplifier la création de conteneurs libvirt sécurisés. Lorsqu'il est lancé avec un exécutable, sandbox détermine les points de montage et les informations libvirt nécessaires pour lancer l'application dans un conteneur. Le conteneur est ensuite lancé par libvirt avec un contexte SELinux qui l'empêche d'interagir avec d'autres processus du système, y compris d'autres conteneurs, tout en étant capable de partager les données du système.
Cela permet à un administrateur de lancer plusieurs instances d'un même service simultanément, tout en les empêchant de casser la machine hôte ou d'autres processus du système, même lorsqu'ils sont exécutés en tant que root. Pour utilisersandbox, installer le paquet libvirt-sandbox.
2.3.4.1. krb5-workstation
Fedora 17 met à niveau le système d'authentification Kerberos vers la version 1.10. Cela ajoute la prise en charge de la modification des mots de passe à travers un NAT et celle de la localisation. La commande kswitch est ajoutée pour basculer entre plusieurs caches d'informations d'authentification. La prise en charge de caches additionnels a été ajoutée à d'autres commandes. Le choix des informations d'authentification peut être contrôlé avec le fichier $HOME/.k5identity.
2.4. Systèmes de fichiers
2.4.1. Systèmes de fichiers volumineux
Fedora 17 prend en charge les systèmes de fichiers supérieurs à 16 téraoctets sur le système de fichiers par défaut (ext4). Avec la dernière version de e2fsprogs, les systèmes de fichiers ext4 peuvent désormais atteindre 100 To.
2.4.2. Systèmes de fichiers chiffrés
Fedora 17 utilise la version 1.4.1 du paquet cryptsetup, qui supprime les appels aux API obsolètes. De plus, il prend en charge le positionnement des en-têtes LUKS sur des périphériques distincts et la création de secteurs chiffrés non-imbriqués partagés sur un seul périphérique.
btrfs n'est pas disponible comme système de fichiers durant l'installation. Ceci est une situation temporaire qui sera résolue dans Fedora 18. btrfs est toujours disponible après l'installation.
Autre nouveauté de Fedora 17, OpenNebula. OpenNebula fournit une plate-forme IaaS destinée à la virtualisation de centre de données. La gestion de cet environnement peut être effectuée en ligne de commande ou à l'aide d'une interface graphique. La compatibilité avec Amazon EC2, l'interface Open Cloud Computing (OCCI), est assurée.
Fedora 17 comprend la dernière version de la suite OpenStack dont le nom de code est « Essex ». La dernière version des l'interfaces de gestion internet (« Horizon ») et de la mise en réseau virtuelle (« Quantum ») sont présentes dans cette nouvelle version. L'utilisation de Qpid comme alternative à RabbitMQ comme moteur AQMP est une nouveauté de Fedora 17. En outre, la disponibilité de libguestfs qui permet de prendre en charge plusieurs formats de disque virtuel offrira plus de flexibilité à l'offre OpenStack de Fedora.
Fedora 17 intègre Open vSwitch, un commutateur réseau logiciel utilisé pour fournir des services réseau aux machines virtuelles. Open vSwitch prend en charge OpenFlow pour faciliter son administration.
2.7. Serveurs de base de données
Fedora 17 inclut mysql 5.5.20, mis à jour depuis la version 5.5.14 de Fedora 16.
postgresql a été mis à jour en 9.1.2
Cette mise à jour est principalement corrective.
sqlite a été mis à jour en 3.7.9
Si un jeton de recherche (à la droite de l'opérateur MATCH) dans FTS4 commence par un « ^ », alors ce jeton doit être le premier dans ce champ du document.
Il y a beaucoup de changements et d'améliorations :
améliorations conséquentes de la performance de CREATE INDEX sur les très grosses tables ;
amélioration des fenêtres du système de fichier virtuel (VFS) pour mieux se protéger contre des interférances venant des logiciels antivirus ;
optimisation du plan de requête quand le mot-clé DISTINCT est présent ;
permet de surcharger plus d'appels systèmes dans le VFS unix - pour une meilleure prise en charge du bac-à-sable de chromium ;
aggrandissement de la taille par défaut d'une ligne de cache anticipée (lookahead) de 100 à 128 octets ;
améliorations sur le module test_quota.c pour qu'il puisse traquer les fichiers préexistants ;
ajout des options SQLITE_DBSTATUS_CACHE_HIT et SQLITE_DBSTATUS_CACHE_MISS à l'interface sqlite3_db_status() ;
suppression de la prise en charge de SQLITE_ENABLE_STAT2, remplacé par l'option plus complète SQLITE_ENABLE_STAT3 ;
améliorations sur l'utilitaire sqlite3_analyzer, incluant les options --pageinfo et--stats ainsi que la prise en charge des bases de données multiplexées ;
amélioration de l'interface sqlite3_data_count() pour qu'elle puisse être utilisée pour déterminer si SQLITE_DONE a été vue dans l'instruction préparée ;
ajout du contrôle de fichier SQLITE_FCNTL_OVERWRITE avec lequel le cœur SQLite indique au VFS que la transaction actuelle écrasera entièrement le fichier de base de donnée ;
aggrandissement de la taille d'allocation par défaut de la mémoire récente (lookaside) de 100 à 128 octets ;
amélioration du planificateur de requête pour qu'il puisse factoriser des termes entrants ou sortants des expressions OR dans la clause WHERE afin de trouver les meilleurs index ;
ajout de l'option à la compilation SQLITE_DIRECT_OVERFLOW_READ, permettant aux pages débordant de la mémoire d'être lues directement depuis le fichier de base de donnée, outrepassant le cache de pages ;
suppression des limites sur la précision et largeur dans les spécificateurs de la famille de routine de rendement de chaînes de caractères sqlite3_mprintf().
2.8. Modification de l'emplacement des notes de version
À partir de la prochaine version, les notes de version seront à un nouvel emplacement.
Par tradition, les notes de version étaient installées dans /usr/share/doc/HTML/fedora-release-notes/. Au fil du temps, la plupart des documents situés dans l'arborescence /usr/share/doc/HTML/ ont été déplacés vers les répertoires spécifiques des applications.
Pour la plupart des utilisateurs, cette modification est invisible car on peut trouver les notes de version en sélectionnant le choix dans le menu. Cependant, certaines personnes ouvrent le fichier directement ou bien ont leurs propres liens en interne. Dans ce cas, changer l'emplacement sans prévenir pourrait être un problème, donc les notes de version ne sont pas déplacer cette fois-ci.
À partir de Fedora 18, les notes de version seront situées dans /usr/share/doc/fedora-release-notes-18.0/.
Le paquet pciutils, qui fournit les outils pour l'inspection et la configuration des périphériques PCI, a été mis à jour vers la version 3.1.9 dans Fedora 17. Il ajoute la prise en charge de la vitesse de lecture et des champs d'état de liaison pour le matériel PCI Express de 3ème génération.
Fedora 17 inclut la version 4.3 de brltty, le démon de gestion d'un afficheur braille. Cette version 4.3 comprend de nouvelles options de configuration et de journalisation ainsi que la prise en charge de périphériques supplémentaires.
2.10.1. Rendu logiciel pour GNOME Shell
L'expérience GNOME Shell est maintenant disponible pour tous les matériels, même pour les périphériques utilisant le rendu logiciel. Les utilisateurs souhaitant utiliser le mode dégradé de GNOME peuvent l'activer manuellement à partir du panneau de contrôle Paramètres Système, puis en sélectionnant Carte Graphique du menu Détails et en paramétrant l'option Mode restreint forcé sur 1.
2.10.2. Prise en charge des écrans multipoint
Le serveur X et les bibliothèques de Fedora 17 prennent en charge la version 2.2 de l'extension XInput, qui inclut la prise en charge des écrans multipoints. Les applications qui la choisiront seront maintenant en mesure d'en tirer tous les avantages.
2.10.3. Prise en charge du défilement doux
La mise à jour du serveur X fournit aussi le défilement doux pour les pilotes et les périphériques qui le prennent en charge. On peut maintenant exporter le défilement des données en tant que valeurs des axes en plus de l'ancien événement d'appui de bouton. Cela permet aux applications de tenir compte de la vitesse et de fournir une expérience plus douce du défilement. Comme pour le multipoint, pour profiter du défilement doux il faut qu'il soit écrit dans les applications elles-mêmes.
Les pilotes DRI i810, mga, r128, savage, sis, tdfx et unichrome ne sont plus maintenus depuis longtemps, car ils ne sont pas intégrés dans Mesa. Le matériel affecté inclut les variantes des périphériques suivant :
cartes mère avec chipsets Intel i810 et i815 ;
cartes Matrox MGA G200, G400, G450 et G550 ;
cartes ATI Rage 128 ;
cartes S3 Savage 3D et Savage 4 ;
chipsets SiS 300, 540, 630 et 730 ;
cartes 3dfx Voodoo 3, Voodoo 4 et Voodoo 5 ;
chipsets VIA Unichrome et Unichrome Pro.
Ce matériel est maintenant pris en charge par le pilote 3D llvmpipe qui, contrairement aux anciens pilotes DRI, rend fonctionnel OpenGL 2.x.
