Product SiteDocumentation Site

2. Modifications dans Fedora pour les administrateurs systèmes

2.1. Le noyau Linux

Fedora 19 est équipé du noyau 3.9.0.

2.2. Installation

2.2.1. Résolution minimale d'écran

L'installation graphique requiert une résolution 800x600 ou supérieure

L'installation graphique de Fedora 19 nécessite une résolution d'écran minimale de 800x600. Les possesseurs d'écrans de plus faible résolution, comme certains ordinateurs portables, doivent utiliser l'installation en mode texte ou au travers de VNC.
Une fois installé, Fedora prendra en charge ces écrans de résolution inférieure. Le minima requis sur la résolution ne s'applique que lors de l'installation.

2.2.2. Syslinux

Fedora 19 inclut la possibilité d'utiliser le chargeur de démarrage Extlinux, qui fait partie de la famille Syslinux. Ce chargeur de démarrage n'est pas aussi avancé que le chargeur par défaut Grub2 et pourra ne pas fonctionner dans certaines circonstances. Le cas d'usage cible pour F19 est celui des images cloud légères, mais Extlinux peut être utile pour vous dans d'autres situations.
Actuellement, Extlinux ne prend pas LVM en charge, et quoiqu'il prenne en charge btrfs, celle prise en charge est limitée. Une partition de démarrage ext2, ext3 ou ext4 est requise, soit sur le système de fichier racine, soit dans une partition séparée. De plus, seules les architectures x86 sont prises en charge.
Pour activer Extlinux, utiliser au choix le mot-clé extlinux sur la ligne de commande de Anaconda, ou utiliser l'option « --extlinux » de la commande « bootloader » dans kickstart. Cette fonctionnalité n'est pas rendue visible à l'utilisateur dans les interfaces textuelle et graphique du programme d'installation.

Syslinux n'est pas préférable à grub pour la plupart des utilisateurs.

Cette prise en charge est actuellement limitée à un cas d'usage restreint, principalement les machines virtuelles, et Extlinux ne fonctionnera pas dans la plupart des cas dans Fedora 19.

2.2.3. Configuration firstboot

Les écrans de configuration initiaux ont été revus pour Fedora 19. GNOME permet maintenant la création d'utilisateur et la configuration au premier démarrage. Les autres environnements utilisent à la place la nouvelle fonctionnalité du programme d'installation.

2.2.4. La prise en charge de l'authentification distante est limitée

Le programme d'installation de Fedora 19 ne prend actuellement pas en charge la configuration de l'authentification distante pendant l'installation. Cependant, si GNOME est installé et qu'aucun utilisateur n'est créé par le programme d'installation, le premier démarrage de GNOME fournira un dialogue de création d'utilisateur qui prend en charge tant FreeIPA que AD.
Les utilisateurs qui ont besoin d'une autre modalité d'authentification distante doivent la configurer dans un fichier kickstart, ou après que l'installation se soit terminée.

2.2.5. Stockage avancé

La réécriture du programme d'installation anaconda qui a démarré dans Fedora 18 continue. Fedora 19 apporte la prise en charge pendant l'installation de modalités de stockage avancées, comme fcoe, iscsi, et multipath. Le mode texte du programme d'installation a été amélioré.

2.2.6. Intégration dans un domaine AD

Fedora peut maintenant rejoindre un domaine depuis un fichier kickstart ou depuis anaconda, en utilisant des mots de passe à usage unique et une syntaxe simple.
        # exemple de ligne kickstart pour rejoindre un domaine:
        network --hostname=machine.ad.example.com
        realm join --one-time-password=MyPassword ad.example.com

2.3. Démarrage

2.3.1. Démarrage plus rapide avec l'initramfs spécifique à l'hôte.

Secours et reconstruction pour des modifications majeures

La vitesse de démarrage est améliorée par la suppression de fonctionnalités inutilisées de l'initramfs. Si un nouveau périphérique est ajouté, démarrer avec l'initramfs de secours puis utiliser la commande dracut --regenerate-all pour le reconstruire et remplacer l'ancien initramfs.
Cette version de Fedora construit un initramfs spécialement adapté à votre matériel informatique, autorisant un démarrage rapide. Si vous modifiez votre machine, ou un matériel important, vous devrez démarrer avec l'entrée Rescue et exécuter la commande dracut --regenerate-all. Si vous souhaitez que votre initramfs soit indépendant de votre matériel, installez le paquet dracut-nohostonly. Si vous ne souhaitez pas d'image de secours (comme sur une machine virtuelle) installez le paquet dracut-norescue.

2.3.2. Modifications visuelles de GRUB

L'apparence de GRUB et des menus de GRUB ont été modifié pour offrir un apect transparent et plus attrayant.

2.4. Sécurité

2.4.1. Restrictions sur les liens physiques et symboliques

Une des classes de problèmes de sécurité de longue date est celui de la course sur les liens, entre heure de vérification et heure d'utilisation, que l'on observe souvent dans les répertoires où l'accès en écriture est ouvert à tous, comme /tmp. La méthode habituelle d'exploitation de cette faille est de dépasser les limites de privilèges lorsque l'on suit un lien donné, comme par exemple lorsque un processus exécuté en tant que root suit un lien appartenant à un autre utilisateur. Dans Fedora 19, les liens ne peuvent être suivis que lorsqu'ils ne sont pas dans un répertoire sticky en écriture pour tous, ou lorsque l'uid du lien est identique à celui du processus qui le suit, ou lorsque le propriétaire du répertoire est le même que celui du lien. Dans les versions précédentes, ce respect était assuré par une stratégie SELinux, et dans cette version, les restrictions sont activées par un paramétrage sysctl dans /usr/lib/sysctl.d/00-system.conf, fournissant ainsi une couche de protection additionnelle :
        fs.protected_hardlinks = 1
        fs.protected_symlinks = 1

2.4.2. Certificats systèmes partagés

Les certificats des autorités de certification racines sont utilisés depuis un emplacement central, et partagés par la plupart des applications, à moins que ces applications soient explicitement configurées avec d'autres certificats.
Un administrateur système peut maintenant une autorité de certification non-standard destinée à être digne de confiance dans un répertoire. Après avoir lancé un outil, cette autorité sera utilisée par la plupart des applications comme attendu, sauf pour celles configurées pour ne pas le faire.
Pour plus d'informations sur la mise en œuvre, consulter http://fedoraproject.org/wiki/Features/SharedSystemCertificates:Testing.

2.4.3. FreeIPA

2.4.3.1. Prise en charge de realmd par FreeIPA
Il est maintenant possible de configurer simplement un client afin d'utiliser un domaine FreeIPA pour l'authentification, en utilisant le Centre de contrôle GNOME, kickstart, ou la ligne de commande :
          realm join myipadomain.com
2.4.3.2. Améliorations sur les relations d'approbations dans FreeIPA
Lors de l'utilisation de FreeIPA afin de créer une relation d'approbation avec un domaine Active Directory, il est maintenant possible de désigner plusieurs contrôleurs de domaine dans FreeIPA pour les clients de serveur Windows.
FreeIPA ajoute l'administration de suffixes de domaines supplémentaires visibles pour les clients des domaines Active Directory approuvés.
FreeIPA met maintenant en œuvre un service Global Catalog afin de permettre aux administrateurs de domaines Active Directory d'autoriser les utilisateurs FreeIPA.

2.4.4. SSSD améliore l'intégration AD

Avec la dernière version majeure de SSSD, l'intégration dans les domaines Active Directory a été améliorée. Les sites AD sont respectés, et SSSD tente d'accéder le contrôleur de domaine le plus proche. Les utilisateurs et les groupes des domaines approuvés sont disponibles.

2.4.5. Amélioration de la résilience de Kerberos

Kerberos a été amélioré dans Fedora 19. Il est maintenant possible de s'authentifier en utilisant kerberos indépendamment du fait que l'heure du système local est synchronisée avec celle du serveur kerberos.
Plusieurs anomalies kerberos, dont la gestion des enregistrements DNS inverses, ont été corrigés de façon à simplifier l'expérience utilisateur des applications kerberos.

2.4.6. gssproxy

Fedora 19 comporte gssproxy, un projet open source visant à améliorer l'utilisation GSSAPI tant du noyau pour l'authentification de l'accès à des systèmes de fichiers distants, que des applications en espace utilisateur. Il fournit un contrôle d'accès fin sur l'accès au keytab Kerberos, et permet de s'affranchir de diverses limitations que le noyau peut avoir lors de son utilisation de tickets Kerberos.

2.5. Virtualisation

2.5.1. open-vm-tools

open-vm-tools, le projet open source visant à remplacer lesVMware Tools, est maintenant disponible dans Fedora.

2.5.2. Ressources conteneurs hautement disponibles

Pacemaker prend maintenant en charge la capacité de gérer des ressources distantes sur des nœuds hors du cluster par le biais de l'utilisation du service pacemaker_remote. Cette fonctionnalité permet à pacemaker de gérer à la fois des invités virtuels et les ressources de ces invités, et ce depuis le nœud hôte du cluster sans nécessiter aux invités de faire fonctionner la pile logicielle cluster.
Se reporter à http://clusterlabs.org/doc/ et le résumé d'utilisation àhttp://fedoraproject.org/wiki/Features/High_Availability_Container_Resources pour plus d'informations.

2.5.3. Migration de stockage de machines virtuelles

KVM et libvirt prennent maintenant en charge de manière performante la migration de machine virtuelle sans stockage partagé entre les hôtes. Une machine virtuelle en cours d'exécution et ses images disques sont relocalisées vers une nouvelle machine sans arrêt de service.

2.5.4. Virtio Générateur de nombres aléatoires

KVM et libvirt fournissent maintenant un générateur de nombres aléatoires (random number generator, RNG, en anglais) paravirtualisé.Cela permet d'éviter la famine d'entropie dans les machines virtuelles.

2.6. Serveurs web

2.7. Cloud

2.7.1. Images cloud prêtes à l'emploi

Des images prêtes à l'emploi sont maintenant fournies avec Fedora 19. Celles-ci sont disponibles dans Amazon EC2 ou en téléchargement direct. Les images téléchargeables sont disponibles soit en format brut compressé, soit en format qcow2, pour une utilisation directe avec EC2, OpenStack, CloudStack ou Eucalyptus. Les images sont configurées avec cloud-init, et utiliseront les services de meta-données compatibles EC2 pour l'approvisionnement des clés SSH.

2.7.2. OpenShift Origin

OpenShift Origin, la version communautaire de Red Hat OpenShift, est disponible pour la première fois dans Fedora 19.

2.7.3. OpenStack Grizzly

OpenStack est mis à jour vers la dernière version stable, du nom de code « Grizzly ». OpenStack Grizzly inclut les projets en incubation Heat et Ceilometer, ainsi que de nombreuses améliorations et mises à jour. Une liste détaillée de ces modification est disponible sur https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly
Plusieurs sous-projets sont aussi disponibles, comme indiqué ci-dessous.
2.7.3.1. Ceilometer
Ce projet OpenStack en incubation vient d'apparaître dans cette version. Merci de consulter les notes préliminaires de configuration de Ceilometer.
2.7.3.2. Heat
Ce projet OpenStack en incubation vient d'apparaître dans cette version. Merci de consulter les notes préliminaires de configuration de Heat
2.7.3.3. Nova
Les volumes Nova ont été retirés et remplacés parcinder, cf. https://blueprints.launchpad.net/nova/+spec/delete-nova-volume
Les nœuds d'exécution n'accèdent désormais plus à la base de données afin de permettre une meilleure capacité de montée en charge et une meilleure sécurité, cf. https://blueprints.launchpad.net/nova/+spec/no-db-compute
Les instantanés peuvent être pris sur des périphériques blocs comme sur des fichiers qcow2, cf. https://blueprints.launchpad.net/nova/+spec/snapshots-for-everyone
La fonctionnalité compute cells a été intégrée afin de permettre une meilleure montée en charge, cf.https://blueprints.launchpad.net/nova/+spec/nova-compute-cells
libvirt prend maintenant en charge SPICE comme VNC, cf. https://blueprints.launchpad.net/nova/+spec/libvirt-spice
2.7.3.4. Quantum
Les groupes de sécurité sont maintenant pris en charge, les détails sont disponibles sur https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups
2.7.3.5. Cinder
La sauvegarde de volumes sur swift est maintenant disponible, consulter https://blueprints.launchpad.net/cinder/+spec/volume-backups
Prise en charge des cibles iSCSI LIO, cf. https://blueprints.launchpad.net/cinder/+spec/lio-iscsi-support
2.7.3.6. Keystone
Une nouvelle API V3 a été développée, les détails sont disponibles à https://blueprints.launchpad.net/keystone/+spec/implement-v3-core-api
Un nouveau moteur LDAP a été intégré, les informations à son sujet sont disponibles sur la page https://blueprints.launchpad.net/keystone/+spec/ad-ldap-identity-backend
2.7.3.7. Horizon
Le téléversement de fichiers a été amélioré, cf. https://blueprints.launchpad.net/horizon/+spec/file-upload-redux
Une configuration unifiée a été mise en œuvre afin de simplifier l'administration, cf. https://blueprints.launchpad.net/horizon/+spec/unify-config
Un panneau d'informations système a été ajouté, les détails sont donnés à https://blueprints.launchpad.net/horizon/+spec/system-info-panel

2.8. Serveurs de base de données

2.8.1. MariaDB

Fedora 19 inclut maintenant MariaDB, une branche améliorée et plus ouverte de MySQL qui possède une communauté prospère. MariaDB est utilisé comme moteur de base de données compatible mysql par défaut, le changement devant être transparent pour la plupart des utilisateurs MySQL. Si nécessaire, les paquets MySQL sont toujours disponibles en tant que community-mysql.

2.8.2. Derby

Apache Derby, une base de données relationnelle open source totalement écrite en Java, a été mise à jour à la version 10.9.1.0. Pour les informations détaillées sur les changements apportés àDerby, consulter le site web du projet à http://db.apache.org/derby/

2.8.3. sqlite

Les fonctionnalités de sqlite ont été étendues et améliorées avec la mise à jour à la version 3.7.15. Le projet fournit l'historique des versions sur http://www.sqlite.org/changes.html

2.9. Serveurs de fichiers

2.9.1. NFSTest

Fedora 19 apporte NFSTest, une suite d'outils permettant de tester serveurs et clients NFS. Les informations détaillées sont disponibles surhttp://wiki.linux-nfs.org/wiki/index.php/NFStest

2.10. Démons du système

2.10.1. Disponibilité des répertoires temporaires privés

Les services comportant un répertoire PrivateTmp= défini dans leur configuration font usage d'un répertoire privé temporaire, qui est partagé entre tous les processus du service. Les fichiers temporaires sont supprimés lorsque le service est arrêté.

2.10.2. systemd

2.10.2.1. Configuration modulaire de service par dépôt de fichier
systemd cherchera dorénavant des directives de configuration pour un service dans /etc/systemd/system/foo.service.d/bar.conf, rendant les modifications spécifiques à une installation plus simples à organiser et à déployer.
2.10.2.2. conteneurs légers systemd
Les conteneurs nspawn ont été améliorés de façon à permettre l'installation d'une distribution Fedora non-modifiée à fin de tests, de débogage et de développement.
2.10.2.3. Catalogue de messages systemd
Le catalogue de messages systemd utilise des identifiants globaux uniques de messages afin d'associer des messages d'erreurs spécifiques à des informations supplémentaires comme des explications détaillées et des liens vers des informations externes.
2.10.2.4. Contrôle de ressource systemd
Dans Fedora 19, systemd ajoute la capacité de modifier dynamiquement les ressources des services contrôlées par cgroups.
2.10.2.5. timers systemd
systemd ajoute la prise en charge d'événements de calendrier, en plus de la prise en charge existante pour des événements périodiques monotones.
2.10.2.6. systemd-analyze
systemd-analyze peut maintenant utiliser l'outilGraphViz dot afin de créer des graphiques du processus de démarrage. GraphViz peut être installé par la commande yum install graphviz et créera une représentation du processus complet de démarrage avec la commande systemd-analyze dot | dot -Tsvg > systemd.svg. Des graphiques plus détaillés peuvent être créés avec les arguments optionnels --order, --require, --from-pattern=, et --to-pattern=
Pour plus de détails et quelques exemples, se reporter à la page de manuel man 1 systemd-analyze.
2.10.2.7. Outils de sockets
systemd fournit maintenant quelques outils pour travailler sur les unités sockets :
systemctl list-sockets qui permet d'afficher les sockets sur lesquels systemd est en écoute, les composants auxquelles ils appartiennent, et celles qu'ils activent.
systemd-activate pour tester l'activation de socket.
2.10.2.8. Modifications dans les journaux
Les fichiers journaux sont maintenant la propriété du groupe dédié « systemd-journal » au lieu du groupe « adm ».
Les modifications apportées à l'utilisation de journalctl comprennent :
journalctl -r pour voir les entrées les plus récentes en premier.
journalctl -e pour aller à la fin de la liste.
journalctl --user-unit="foo" pour filtrer les unités par utilisateur.
Un nouveau module dans l'API python systemd pour lire le journal.
journalctl enregistre maintenant les données des journaux dans /var/log/journal. Dans les versions précédentes, les données des journaux étaient stockées dans /var/run/journal, qui est volatile et nettoyé à chaque redémarrage du système. À partir de Fedora 19, les données des journaux sont maintenant persistantes aux redémarrages.

2.11. Outils de configuration serveur

2.11.1. yum-presto a été fusionné dans yum

Le greffon yum-presto, utilisé pour la prise en charge des fichiers delta RPM, a été fusionné dans yum. Pour désactiver l'utilisation de paquets delta RPM, configurer deltarpm=0 dans /etc/yum.conf. Cf. man yum.conf pour plus d'informations.

2.11.2. Clichés LVM activés par yum

En utilisant le paquet yum-plugin-fs-snapshot, les systèmes de fichiers en mode thin provisioning peuvent être pris en cliché automatiquement lors d'une mise à jour de paquets.
L'existance de volumes en mode thin provisioning sont un prérequis. Les clichés sont activés dans le fichier de configuration du greffon /etc/yum/pluginconf.d/fs-snapshot.conf :
Paramétrer enabled=1 dans la section [lvm] pour activer la fonctionnalité.
paramétrer create_snapshots_in_post=1 dans la section [main] afin de créer un cliché après la transaction yum.

2.11.3. Groupes yum en tant qu'objets

En traitant les groupes de paquets en tant qu'objets plutôt que des listes statiques, les gestionnaires de paquets tels que yum vont maintenant stocker l'information, et l'utiliser pour les commandes ultérieures relatives aux groupes, apportant les nouveaux paquets ajoutés au groupe lors des mises à jour.

2.11.4. Administration facilitée avec OpenLMI

L'infrastructure OpenLMI a été grandement améliorée. Ont été ajoutés une nouvelle API de gestion du stockage, ainsi que des fournisseurs de supervision, d'information sur le matériel, sur realmd, et le pare-feu. Des améliorations ont aussi été apportées aux fournisseurs existants. L'information intégrée a été mise à jour afin de refléter les nouvelles fonctionnalités.

2.12. Solutions de supervision et d'administration

2.12.1. Performance Co-Pilot

Performace Co-Pilot, une suite de serveurs et un cadragiciel pour l'administration, la supervision et la métrologie du système, a été mis à jour à la version 3.7. Consulter les notes de version du projet à http://oss.sgi.com/projects/pcp/news.html ainsi que la documentation à http://oss.sgi.com/projects/pcp/pcp-gui.git/man/html/index.html

2.12.2. Puppet

Fedora 19 livre la version 3.x de la boîte à outils puppet. Pour plus d'informations sur puppet 3, consulter la documentation du projet à http://docs.puppetlabs.com/puppet/3/reference/release_notes.html