Paquet Fedora du jour - Le "pourquoi" du Mercredi

Le "pourquoi" du mercredi : les menus

Pikachu_2014 — Wed, 25 Jun 2008 07:00:00 +0200

Ce billet est une traduction libre de l'article : Wednesday Why: Menus écrit par Chris Tyler.

Les menus des applications de Fedora listent différents programmes provenant de paquetages variés. Fedora fournit de nombreux environnements de bureaux, dont GNOME, KDE et XFCE ; chacun d'entre eux utilise sa propre structure de menu pouvant inclure ou exclure certains programmes, tels que les panneaux de contrôle propres à chacun d'eux. Chaque titre de menu ainsi que les entrées sont affichés dans la langue courante de la session. En outre, la disposition des menus fait souvent l'objet d'affinements à chaque nouvelle version de Fedora, alors que certains paquetages n'ont pas varié d'un iota au cours de la transition. Voilà quelques propriétés de ces menus dont on s'attachera à décrire les mécanismes en jeu.

Les spécifications des entrées du menu sont définies de façon collaborative au sein du projet freedesktop.org. Toute paquetage Fedora induisant l'apparition d'une entrée dans le menu contient un ou plusieurs fichiers .desktop décrivant ces entrées. Par exemple, le paquetage evolution contient un fichier .desktop (ici tronqué, compte-tenu du nombre important de traductions du nom et des commentaires qu'il contient) :

$ rpm -ql evolution | grep desktop
/usr/share/applications/evolution.desktop

Celui-ci contient ainsi les informations nécessaire à l'affichage de l'entrée Evolution dans le menu :

[Desktop Entry]
Encoding=UTF-8
Name=Evolution Mail and Calendar
Name[ar]=بريد و تقويم إيفُليوشِن
Name[as]=Evolution মেইল বৰ্ষপঞ্জি
...
Name[fr]=Messagerie et calendrier d'Evolution
...
Name[zh_HK]=Evolution 郵件與行事曆
Name[zh_TW]=Evolution 郵件與行事曆
...
Comment=Manage your email, contacts and schedule
Comment[ar]=قُم بإدارة بريدك الكتروني، مراسليك وجدولك
Comment[as]=আপোনাৰ ই-মেইল অ্যাকাউন্টসমূহকে এখানে বিন্যাস কৰক
...
Comment[fr]=Gérer vos courriels, contacts et agendas
...
Comment[zh_HK]=管理你的郵件、聯絡人和行程
Comment[zh_TW]=管理您的郵件、連絡人和行程
Exec=evolution
Icon=evolution
Terminal=false
Type=Application
Categories=GNOME;GTK;Office;Email;Calendar;ContactManagement;X-Red-Hat-Base;
StartupNotify=true
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=Evolution
X-GNOME-Bugzilla-Component=BugBuddyBugs
X-GNOME-Bugzilla-Version=2.22.x
X-GNOME-Bugzilla-OtherBinaries=evolution-data-server-2.22;evolution-exchange-storage;evolution-alarm-notify;

Comme on peut le voir, ce fichier contient le nom et la description du programme par défaut (en anglais) et celle spécifique à la langue de l'environnement choisie. Il indique également la commande lancée par l'entrée, l'icône à afficher (qui est celle du thème choisi si celui-ci propose une icône correspondant au nom spécifié), si le programme doit être lancé depuis un terminal, l'encodage à utiliser pour l'affichage du nom et de la description, la catégorie à laquelle appartient l'application, et si le programme supporte le protocole Startup Notify (grosso modo, une application implémentant ce protocole enverra chaque fois qu'elle sera lancée ou quittée un message de notification au serveur X, qui pourra être intercepté par une autre application comme une applet, etc). Quant aux champs X-GNOME-Bugzilla-* à la fin de ce fichier, ils caractérisent une entrée propre à un environnement de bureau, et qui seront ignorés par les autres (le préfixe « X- » indique que le champ n'est pas standard ou est expérimental).

Les informations contenues dans ce fichier peuvent par ailleurs être indifféremment utilisées pour décrire une entrée de menu, une icône sur un tableau de bord ou sur le bureau. L'emplacement du fichier .desktop détermine en quelque sorte la représentation associée : un fichier placé dans les répertoires /usr/share/applications/ décrira une entrée dans le menu, tandis que le même fichier placé dans le répertoire du bureau (~/Bureau/) affichera un lanceur sur ce dernier. Pour placer sur le bureau un lanceur d'une application présente dans le menu, il suffit donc simplement de copier le fichier .desktop correspondant dans /usr/share/applications/ vers ~/Bureau/.

L'organisation du menu est régie par des fichiers de configuration placés dans le répertoire /etc/xdg/menus (les spécifications de ces fichiers, au format XML, sont définies sur http://standards.freedesktop.org/me...). Ces fichiers décrivent la hiérarchie des catégories présentes dans le menu « Applications » ou « Système » par exemple, les emplacements de recherche des fichiers .desktop à afficher, etc.

Par exemple, le fichier /etc/xdg/menus/applications.menu, correspondant au menu « Applications », contient une section relative à la catégorie « Bureautique » (« Office » en anglais) :

  <!-- Office -->
  <Menu>
    <Name>Office</Name>
    <Directory>Office.directory</Directory>
    <Include>
      <And>
        <Category>Office</Category>
      </And>
    </Include>
  </Menu> <!-- End Office -->

L'entrée « Evolution » décrite plus haut est ainsi affichée dans cette catégorie, puisque défini dans le champ Categories comme appartenant à la catégorie Office. Le tag <INCLUDE> mérite qu'on s'y attarde : il spécifie quels fichiers .desktop y seront incorporés, en l'occurence, tous ceux de catégorie « Office ». Si l'on considère cette fois la section relative à la catégorie « Outils système » (« Categories ») :

<!-- Accessories submenu -->
  <Menu>
    <Name>Accessories</Name>
    <Directory>Accessories.directory</Directory>
    <Include>
      <And>
        <Category>Utility</Category>
        <Not>
          <Category>System</Category>
        </Not>
      </And>
    </Include>
  </Menu> <!-- End Accessories -->

on constate que le bloc <Include> contient un sous-bloc Utility : tous les fichiers .desktop de catégorie « Utility » seront affichés dans le menu dans cette catégorie. En révanche étant suivi d'un bloc <Not> de négation contenant la catégorie System, un fichier marqué à la fois Utility ET System ne sera pas affiché (ceux-ci étant affichés sous Fedora dans le menu dans le menu « Système »).

Le "pourquoi" du Mercredi : Changement d'utilisateur rapide

Nagha — Wed, 23 Apr 2008 08:00:00 +0200

Ce billet est une traduction du billet Wednesday Why: Fast User Switching rédigé par Chris Tyler.

Le changement d'utilisateur permet à plusieurs utilisateurs d'ouvrir simultanément une session personnelle sur un ordinateur partagé et permet également de passer rapidement d'une session ouverte à l'autre.

Sous Fedora, avec Gnome, le changement d'utilisateur rapide est accessible via une petite application de bureau visible dans la barre de menu. Avec KDE, cette fonction est accessible dans le menu K. Dans les deux cas, vous aurez la possibilité de passer sur une session préalablement ouverte ou bien d'en ouvrir une nouvelle.

Lorsque vous demanderez l'ouverture d'une nouvelle session, gdm (Gnome Display Manager, ndlr) démarre un server X supplémentaire sur un nouveau terminal virtuel ( ou console virtuelle) et y affiche un écran d'identification. Il y a jusqu'à 63 terminaux virtuels disponibles ; l'utilisateur peut accéder à chacun des 12 premiers d'entre eux en pressant Ctrl+Alt+une des touches F1 à F12. Dans la configuration par défaut, Fedora démarre en mode console sur les terminaux virutels 1 à 6, ainsi les serveurs X démarrent sur les terminaux virtuels 7 et suivant. Lors des utilisateurs supplémentaires s'identifient, ConsolKit établi l'accès aux prériphériques tels que la carte son et le lecteur optique (CD/DVD), et relie chaque utilisateur à son terminal virtuel et son affichage respectif. Le passage à une autre session déjà ouverte est géré par simple changement de terminal virtuel, exactement comme cela se passerait si vous utilisiez la combinaison de touches pour sélectionner ce terminal virtuel.

Vous pouvez lancer une nouvelle session en ligne de commande en utilisant la commande gdmflexiserver. Si Xnest est installé, vous pouvez également lancer une nouvelle session sur un affichage Xnest en utilisant l'option -n. La commande chvt vous permet de passer d'un terminal virtuel à un autre.

Le changement d'utilisateur rapide utilise des fonctionnalités qui existent depuis de nombreuses années dans le noyau Linux et X Window System les rend simplement facilement accessibles et faciles d'utilisation.

La page Wiki de Fedora à propos de du changement d'utilisateur rapide (discution antérieure à F7) : http://fedoraproject.org/wiki/Desktop/FastUserSwitching

Le "pourquoi" du Mercredi: Page d'accueil d'Apache

slobberbone — Wed, 07 Nov 2007 20:16:00 +0100

Ce billet est une traduction de l'article «Wednesday Why: The Apache Welcome Page» écrit par Chris Tyler.

Si vous installez le serveur web Apache sur votre système Fedora, démarrez-le, puis accédez-y avant d'ajouter n'importe quel contenu, vous verrez alors "la page d'essai de Fedora" ou "la page bienvenue" comme montré ici.
D'où cette page vient-elle ? où est-elle configurée ? et comment disparaît-elle une fois que vous ajoutez le contenu ?

Cette page n'est pas configurée dans le fichier principal de configuration d'Apache, /etc/httpd/conf/httpd.conf -- il n'y a aucune mention d'elle du tout dans ce document, celui-ci ne sert qu'à la configuration du serveur uniquement. La configuration pour cette page est indiquée dans /etc/httpd/conf.d/welcome.conf, qui ressemble à ceci :

   #
   # This configuration file enables the default "Welcome"
   # page if there is no default index page present for
   # the root URL. To disable the Welcome page, comment
   # out all the lines below.
   #
   <LocationMatch "^/+$">
       Options -Indexes
       ErrorDocument 403 /error/noindex.html
   </LocationMatch>

La directive LocationMatch s'assure que cette configuration s'applique seulement aux demandes avec le chemin de / (ou de plusieurs / ), qui redirige seulement les demandes au DocumentRoot (http://ServerName/).
Pour une telle demande, l'option Indexes est désactivée, ainsi vous ne pouvez pas obtenir une liste automatique d'index ou d'annuaire. Si une page pré-construite d'index existe, comme index.html ou index.html.var, alors l'accès au fichier est fait ; mais si elle n'existe pas, une erreur du type HTTP 403 est produite ("interdit"). La directive d'ErrorDocument indique la page à présenter dans ce cas : /var/www/error/noindex.html. Dès que vous créerez une page d'index, l'erreur 403 n'est plus produite, et la page bienvenue disparaît.

Le dossier de configuration /etc/httpd/conf.d/welcome.conf appartient au paquet httpd (Apache). La plupart des autres dossiers de configuration situés dans /etc/httpd/conf.d appartiennent quant à eux à d'autres applications web tels que webalyzer, BackupPC, gallery2, ou lsquirrelmail, et configurent spécifiquement Apache ; la suppression du paquet httpd enlève ce fichier de configuration spécifique de l'application Apache.

Le "pourquoi" du Mercredi: Catégories des paquets

slobberbone — Wed, 17 Oct 2007 22:40:00 +0200

Ce billet est une traduction de l'article «Wednesday Why: Package Categories» écrit par Chris Tyler.

Pendant l'installation du système avec Anaconda et lorsque vous passez par le gestionnaire de paquets (Pirut) (qui apparaît dans le menu Applications -> Ajouter/Enlever des logiciels et s'identifie comme gestionnaire de paquet dans son titre de fenêtre), il vous est donné la possibilité de choisir des paquets par groupes, eux-même disposés dans des catégories. Chaque groupe peut contenir des paquets obligatoires et facultatifs, et les paquets facultatifs dans chaque groupe peuvent être inclus ou exclus lors de l'installation par défaut.

Certains paquets ne sont inclus dans aucune catégorie et ne peuvent pas être installés via ce système de catégories, il faudra donc lister l'ensemble des paquets afin que le gestionnaire de paquets les propose.

Le classement des paquets se fait dans le fichier XML comps.xml, qui se trouve dans /var/cache/yum/*/comps*.xml -- chaque dépôt peut avoir son propre fichier comps.xml. Ces fichiers sont dans un format XML qui ressemble à ceci :

<?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">
   <comps xmlns="">
       <group>
           <id>short-group-id</id>
           <name>human-readable-group-name</name>
           <uservisible>true</uservisible>
           <packagelist>
               <packagereq type="mandatory">always-installed-package</packagereq>
               <packagereq type="default">installed-by-default-package</packagereq>
               <packagereq type="optional">not-installed-by-default-package</packagereq>
               <packagereq type="conditional" requires="other-package">conditional-installed-package</packagereq>
               . . .
           </packagelist>
       </group>
       . . .
       <category>
           <id>simple-category-id</id>
           <name>human-readable-category-name</name>
           <description>category-description</description>
           <display_order>5</display_order>
           <grouplist>
               <groupid>short-group-id</groupid>
               . . .
           </grouplist>
       </category>
       . . .
   </comps>

Comme vous pouvez le voir, la balise <category> définit les groupes et la balise <group>, elle, définit les groupes de paquets Le texte tels que le nom et la description de chaque catégorie et groupe, est fourni dans différentes langues grâce à l'utilisation de l'attribut : xml:lang.

Les paquets identifiés en tant que type obligatoire sont inclus entre les balises <packagereq>, ceux-ci sont toujours installés si le groupe est installé.

Les paquets facultatifs sont traités comme type de paquet obligatoire s'ils requièrent une dépendance d'un paquet de type obligatoire : par exemple, si vous installez le groupe de langue française et avez Moodle installé, alors le support de la langue française de Moodle sera automatiquement installé.
Les paquets avec un type défaut ou facultatif apparaissent sur la liste des paquets facultatifs avec le groupe associé ; initialement, les paquets par défaut sont séléctionnés et les paquets facultatifs ne le sont pas.

Le "pourquoi" du Mercredi: Crontab

Lokthare — Wed, 18 Jul 2007 20:46:00 +0200

Ce billet est une traduction de l'article «Wednesday Why: Crontab» écrit par Chris Tyler.

Cron est le programmateur de tâches d'Unix/Linux. Il utilise les fichiers crontab pour déterminer la date et l'heure à laquelle une tâche va être exécuté. Le fichier crontab principal est /etc/crontab; les fichiers contrab supplémentaires sont placés dans /etc/cron.d/ et les fichiers crontab personnels dans /var/spool/cron/.

Le fichier crontab principal ressemble à ça:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Les paires noms et valeurs au début du fichier configure les variables d'environnement. Les lignes restantes contiennent les champs de date et d'heure, le nom du compte sous lequel la commande va être exécutée et le nom de la commande. Les fichiers crontab personnels sont installé avec la commande crontab et ne contienne pas de champ indiquant le nom du compte.

Le script run-parts lance simplement les scripts contenu dans le dossier spécifié. Un des scripts de chaque répertoires est nommé 0anacron qui met à jour l'estampille temporelle des fichiers enregistré dans /var/pool/anacron. Ces estampilles temporelles sont utilisé par le système anacron au démarage de l'ordinateur pour s'assurer au démarrage de l'ordinateur que les tâches sont bien été exécutées même si l'ordinateur n'est jamais allumé entre 4h et 5h du matin.

Par exemple, un ordinateur de bureau qui est coupé tout les soirs et allumé tout les matins à 9h ne serra jamais allumé à 4h22 lorsque les scripts contenus dans /etc/cron.weekly doivent être exécuté. L'une des tâches opérer hebdomadairement est makewhatis, qui reconstruit la base de donnée whatis qui est utilisé par les commandes apropos, man -k et whatis. Ces commandes ne devraient donc jamais avoir accès à index à jour. Pour résoudre ce problème, lorsque le système démarre, le script d'initiation /etc/rc.d/init.d/anacron vérifie le fichier /var/spool/anacron/cron.weekly pour voir quand les scripts contenu dans /etc/cron.weekly ont été lancé pour la dernière fois. Si cela fait plus de 7 jours, les scripts sont exécuté après un bref délai par run-parts.

Les paquets nécessitant la programmation de tâche peuvent faire cela de deux manières: inclure un fichier crontab qui sera placé dans /etc/cron.d (qui est l'approche utilisé par le paquet smolt) ou inclure un script qui sera placé dans /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly ou /etc/cron.mounthly (qui est l'approche utilisé par cups).