Product SiteDocumentation Site

2. Modifications dans Fedora pour les administrateurs systèmes

2.1. Installation

2.1.1. Prise en charge de l'allocation fine LVM dans Anaconda

Le programme d'installation Fedora prend maintenant en charge les volumes LVM alloués finement tant dans l'interface graphique que dans les installations automatisées avec kickstart. Ce changement introduit une nouvelle variante de partitionnement automatique de même que de nouvelles options permettant la création de volumes alloués finement dans le partitionnement personnalisé.

2.1.2. Répertoire documentation sans version

La documentation associée à chaque paquet est maintenant installée dans les répertoires /usr/share/doc/nom_paquet sans mention de numéro de version. Auparavant, le répertoire\ncomportait le numéro de version en plus du nom du paquet.

2.2. Sécurité

2.2.1. FreeIPA ajoute les relations d'approbation transitives

FreeIPA 3.3.2 ajoute la prise en charge de forêts complexes Active Directory contenant plusieurs domaines. Les utilisateurs provenant de multiples domaines AD peuvent accéder aux ressources de FreeIPA. Les administrateurs FreeIPA peuvent bloquer les accès de manière sélective par domaine AD.

2.2.2. Association d'identifiants pour les partages CIFS dans SSSD

Le démon des services de sécurité système de Fedora 20 (SSSD, System Security Services Daemon) gagne la prise en charge de l'association d'identifiants entre les SID Windows et les identifiants POSIX. Les administrateurs utilisant SSSD sur leurs réseaux peuvent établir un contrôle d'accès en utilisant deux nouveaux utilitaires, setcifsacl et getcifsacl.
Plus d'informations sont disponibles dans le document de conception amont à https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient ainsi que dans les pages de manuel de setcifsacl, getcifsacl, et autres paquets se rapportant à SSSD.

2.2.3. Outils pour les certificats systèmes partagés

La fonctionnalité de gestion de certificats systèmes partagés de Fedora a été améliorée pour cette version avec l'ajout de l'application p11-kit-trust. Ce paquet permet la modification des ancrages d'approbations, des listes noires, et des certificats. Avec une commande unique, les administrateurs peuvent modifier la base de certificats de leurs systèmes au lieu d'ajouter des fichier à des répertoires spéciaux suivie d'une commande spécifique. Ce nouvel outil continue le développement entrepris sur la fonctionnalité de gestion de certificats systèmes partagés.

2.3. Systèmes de fichiers

2.3.1. Mise en cache SSD pour les périphériques blocs

Fedora 20 apporte la prise en charge expérimentale de l'utilisation de disques électroniques (SSD) comme des caches rapides et transparents de disques durs rotatifs traditionnels. Les systèmes de fichiers sur ces dispositifs utilisant un cache SSD conjuguent la rapidité des disques SSD et la volumétrie des disques durs classiques. Cette fonctionnalité peut être utilisée sur des périphériques partitionnés classiques et sur des périphériques LVM.

Faites vos sauvegardes !

Faites toujours des sauvegardes de vos données avant de faire des modifications de bas niveau, comme la migration vers un périphérique bcache. Avant que des outils comme blocks soient emballés pour Fedora, il est conseillé de mettre en œuvre bcache en créant de nouveaux périphériques bcache et de peupler leurs systèmes de fichiers à partir d'une sauvegarde récente.

2.4. Virtualisation

2.4.1. Émulation ARM sur hôtes x86

Des modifications ont été apportées pour avoir une meilleure émulation des machines virtuelles ARM invitées fonctionnant sur des hôtes x86 avec les outils standards libvirt, incluant virsh, virt-manager and virt-install. qemu a un émulateur ARM qui fonctionne bien et est fortement utilisé dans le projet Fedora ARM. Cependant, libvirt and virt-manager ont, actuellement, des problèmes pour démarrer les machines virtuelles qemu-system-arm, principalement à cause d'une supposition d'encodage x86 dans la ligne de commande générée qui provoque un échec de démarrage pour qemu-system-arm. Des modifications ont été apportées pour régler ce problème. Plus d'informations sont disponibles à l'adresse https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86.

2.4.2. Contrôle d'accès du client libvirt

Le client libvirt permet de définir les règles de permissions pouvant s'appliquer aux objets gérés et aux opérations sur l'API, permettant ainsi à toutes les connexions clientes d'être limitées à un jeu minimum de règles et de privilèges. Trois niveaux d'accès peuvent être définis.
Un accès Unauthenticated est initialement employé pour toutes les connexions. Cet état permet toutes les opérations sur l'API permettant de terminer l'authentification. Après une authentification réussie, deux niveaux supplémentaires sont définis : Unrestricted, donnant un accès complet à toutes les opérations sur l'API et Restricted, donnant un accès en lecture seule.
Les administrateurs système peuvent définir des règles de permission pour les connexions authentifiées. Chaque appel à libvirt au travers de l'API a un jeu de permissions qui est validé pour l'objet en cours d'utilisation. Par exemple, l'utilisateur A veut changer un paramètre dans le domaine objet. Quand l'utilisateur essaye de sauvegarder la modification, la méthode virDomainSetSchedulerParametersFlags vérifie si le client a les autorisations en écriture sur le domaine objet. Des vérifications supplémentaires et paramètres de permissions peuvent être aussi exécutés. Un filtrage peut aussi être effectué pour voir quels clients ont les permissions sur quel objet pour autoriser une meilleure administration des permissions. Les documentations des contrôles d'accès polkit peuvent être trouvées à l'adresse http://libvirt.org/aclpolkit.html.
Le fichier de configuration libvirtd.conf gère les paramètres pour les permissions d'accès. Il utilise le paramètre access_drive pour activer cette opération. Veuillez noter que si plusieurs pilotes d'accès sont nécessaires, ils doivent tous être validés pour autoriser la connexion.
Plus d'informations peuvent être trouvées aux adresses https://fedoraproject.org/wiki/Changes/Virt_ACLs et http://libvirt.org/acl.html.

2.4.3. Instantanés virt-manager

Virtual Machine Manager ou virt-manager, permet une gestion et un contrôle simplifié des instantanés des machines virtuelles invitées de KVM. Veuillez noter que virt-manager va mettre en pause la machine virtuelle invitée pendant quelques secondes pendant la prise de l'instantané. Plus d'informations sont disponibles ici :
http://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots
http://libvirt.org/formatsnapshot.html
Chapitre sur les instantanés de man 1 virsh
http://fedoraproject.org/wiki/QA:Testcase_Virt_Snapshot_UI

2.4.4. Ryu Software Defined Networking

Fedora 20 met en avant Ryu, un logiciel efficace de réseau défini logiciel (software defined networking) pour la virtualisation OpenStack. En tant que brique élémentaire du contrôleur OpenFlow, Ryu fournit un réseau de niveau 2 isolé pour Openstack.

2.5. Serveurs de base de données

2.5.1. MongoDB

MongoDB a ét émis à jour en version 2.4, apportant la recherche texte, la prise en charge d'un plus\ngrand nombre d'index géospatiaux, ainsi que des améliorations sur la sécurité. Pour plus d'informations au sujet de\ncette version, lire les notes de version disponibles à http://docs.mongodb.org/manual/release-notes/2.4/.

2.5.2. Hadoop

Fedora 20 apporte le cœur de la florissante plate-forme Hadoop et de nombreux paquets associés. Pour une revue de détail de Hadoop dans Fedora, consulter https://fedoraproject.org/wiki/Changes/Hadoop
La création des paquets de la plate-forme Hadoop est le dernier travail en date du groupe de travail Fedora Big Data SIG. Vous pouvez retrouver ce Special Interest Group à l'adresse https://fedoraproject.org/wiki/SIGs/bigdata, qui est votre porte d'entrée vers l'utilisation et la participation à cet effort.

2.6. Serveurs de messagerie

2.6.1. Pas de sendmail par défaut

Fedora 20 n'inclut plus par défaut un agent de transfert de messagerie. Les versions précédentes de Fedora comprenait le paquet\nsendmail, mais il a une utilité limitée sans une configuration manuelle.

2.7. Samba

2.7.1. Association d'identifiants pour les partages CIFS dans SSSD

Pour plus d'informations sur cette fonctionnalité, consulter le chapitre Security.

2.8. Démons du système

2.8.1. Syslog est retiré de l'installation par défaut

syslog n'est plus inclus dans les installations par défaut. La journalisation avec journald couvre la plupart des cas d'usage aussi bien, sinon mieux que syslogd.
Les utilisateurs habitués à regarder les journaux systèmes dans /var/log/messages doivent maintenant utiliser journalctl.
Exemples de commandes journalctl
Maintenant avec journalctlAvant avec messages
journalctlless /var/log/messages
journalctl -ftail -f /var/log/messages
journalctl --unit named.servicegrep named /var/log/messages
journalctl -bAffiche les journaux de la séquence de démarrage actuelle, pas d'équivalent simple.

2.8.2. systemd

2.8.2.1. Nouveau type d'unité : Scope
Systemd possède maintenant deux types d'unités, scope et slice.
Les unités scope sont créées automatiquement par systemd à partir des processus existants. En regroupant un processus et ses enfants, une unité scope peut être utilisée pour organiser les processus, appliquer des unités de ressource, ou tuer un groupe de processus. Les sessions utilisateurs sont un exemple de processus contenus dans une unité de type scope.
Les unités slice sont utilisées pour regrouper des unités gérant les processus dans une hiérarchie permettant le contrôle des ressources allouées à la tranche (au slice). Les tranches par défaut sont machine.slice, pour les machines virtuelles et les conteneurs ; system.slice, pour les services du système ; et user.slice, pour les sessions utilisateurs. Ces tranches par défaut sont automatiquement peuplées.
Les unités Instance, comme getty@.service, sont lancées à la demande à l'aide du modèle défini dans leur fichier de configuration. Chaque type de modèle se voit attribuer une sous-tranche de la tranche system slice, et les instances sont confinées dans cette tranche.
Les unités scope et service assignées à une tranche sont les descendants du nœud de cette tranche dans l'arbre des groupes de contrôle. Un nom de tranche décrit sa position relative à la tranche racine. La sortie ci-dessous montre comment user-1000.slice est l'enfant de user.slice, qui est à son tour un enfant de ., la tranche racine. Chaque session est de plus confinée dans une unité scope au sein de la tranche de l'utilisateur.
	    systemctl status user.slice

  Loaded: loaded (/usr/lib/systemd/system/user.slice; static)
  Active: active since Sun 2013-09-08 01:23:40 MDT; 18h ago
    Docs: man:systemd.special(7)
  CGroup: /user.slice
          ├─user-1000.slice
          │ ├─session-21.scope
          │ │ ├─9226 sshd: pete [priv]
          │ │ ├─9229 sshd: pete@pts/4
          │ │ ├─9230 -bash
          │ │ ├─9262 sudo su -
          │ │ ├─9270 su -
          │ │ ├─9271 -bash
          │ │ └─9509 screen -R
          │ ├─session-18.scope
          │ │ ├─ 7939 sshd: pete [priv]
          │ │ ├─ 7942 sshd: pete@pts/0
          │ │ ├─ 7943 -bash
          │ │ ├─ 7982 sudo su -
          │ │ ├─ 7988 su -
          │ │ ├─ 7989 -bash
          │ │ ├─ 8206 SCREEN
          │ │ ├─ 8207 /bin/bash
          │ │ ├─ 8237 /bin/bash
          │ │ ├─ 8486 less NEWS
          │ │ ├─ 8489 /bin/bash
          │ │ └─10637 systemctl status user.slice
          ## truncated ##

Les services peuvent être ajoutés à une tranche avec la directive Slice=nom_tranche dans le fichier de configuration de leur unité. Les arguments permettant la limitation de ressources dans une tranche ou une unité de service sont décrits dans man systemd.directives. Se reporter aussi à man systemd.slice et man systemd.cgroup.
2.8.2.2. systemd-cryptsetup pour TrueCrypt
La prise en charge de TrueCrypt dans Fedora est étendue par la prise en charge de la technologie par systemd-cryptsetup, permettant une authentification facilitée pendant la phase de démarrage.
2.8.2.3. Filtrage par état d'unité avec systemctl
systemctl prend maintenant en charge le filtrage de l'énumération de la liste des unités par état de chargement. L'option --state accepte toute valeur, ou une liste de valeurs séparées par des virgules parmi les états LOAD, SUB, ou ACTIVE. Par exemple :
	   systemctl --state failed 

2.8.3. journald

2.8.3.1. Affichage des journaux d'un démarrage spécifique
journalctl peut maintenant être utilisé pour afficher les journaux d'un démarrage spécifique. Pour voir par exemple les journaux du démarrage actuel :
	  journalctl -b
Ou encore, pour voir ceux du précédent démarrage :
	  journalctl -b -1
Au delà du numéro de séquence relatif, journald assigne un identifiant de démarrage de 128 bit qui peut être utilisé pour le référencer. Par exemple :
	  journalctl -b 38fd9c3303574ed38e822233457f6b77
2.8.3.2. Référencement du journal avec des curseurs
journalctl peut référencer le contenu du journal par un identifiant d'enregistrement, aussi nommé curseur. De même pour un hachage git, le curseur identifie de manière unique un point dans le journal.
Si vous ajoutez l'option --show-cursor à une requête journalctl, la dernière ligne de l'affichage contient la valeur du curseur :
	  journalctl -b -u network --show-cursor --since 15:00
	  Sep 08 15:37:59 localhost.localdomain network[4074]: [FAILED]
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Unit network.service entered failed state.
	  -- cursor: s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831
Le curseur peut être utilisé pour identifier le point dans le journal dans une requête plus large afin de fournir du contexte :
	  journalctl -c "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"
Les scripts analysant la sortie de journalctl peuvent enregistrer la valeur du curseur et l'utiliser à la prochaine exécution pour reprendre là où ils s'étaient arrêtés :
	  journalctl --after-cursor "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"