Des Logiciels Libres

Mais où est passé systemd-analyze?

Edouard — Tue, 05 Feb 2013 00:37:00 +0100

Si vous venez de faire une installation toute fraîche de Fedora 18 vous serez peut être étonné que la commande systemd-analyze n'est plus disponible de base. Cette commande très utile est dans le paquet "systemd-analyze", qu'il suffit d'installer:

yum install systemd-analyze

Et voilà! Utile pour diagnostiquer un démarrage lent:

$ systemd-analyze blame
  2055ms postfix.service
   601ms systemd-udev-settle.service
   530ms firewalld.service
   476ms fedora-storage-init.service
   451ms iscsid.service
   335ms bluetooth.service
   229ms abrt-ccpp.service
   222ms systemd-binfmt.service
   204ms NetworkManager.service
   199ms fedora-storage-init-late.service
   195ms systemd-logind.service
   185ms avahi-daemon.service
   169ms ntpd.service
   162ms cpupower.service
   159ms acpid.service
   158ms fedora-loadmodules.service
   127ms systemd-udev-trigger.service
   105ms sshd.service
   103ms systemd-readahead-collect.service
   101ms abrt-vmcore.service
    98ms ksmtuned.service
    93ms gdm.service
    93ms lvm2-monitor.service
    92ms sys-kernel-debug.mount
    90ms systemd-readahead-replay.service
    85ms ksm.service
    80ms dev-mqueue.mount
    79ms udisks2.service
    78ms proc-sys-fs-binfmt_misc.mount
    68ms dev-hugepages.mount
    67ms systemd-vconsole-setup.service
    66ms systemd-remount-fs.service
    66ms systemd-tmpfiles-setup.service
    65ms home.mount
    62ms rpcbind.service
    60ms fedora-readonly.service
    59ms bacula-fd.service
    53ms colord.service
    52ms iscsi.service
    51ms tmp.mount
    51ms systemd-sysctl.service
    48ms polkit.service
    47ms systemd-modules-load.service
    45ms boot.mount
    45ms auditd.service
    42ms sys-kernel-config.mount
    29ms wpa_supplicant.service
    27ms accounts-daemon.service
    27ms systemd-udevd.service
    23ms upower.service
    12ms rtkit-daemon.service
     9ms systemd-user-sessions.service

Pas mal cette Fedora 18, assez propre sans rien faire (et encore j'ai perdu 2 secondes au boot en installant postfix). La transition vers systemd est de plus en plus complète, vu ce qu'il reste dans init.d:

$ ls /etc/init.d/
ebtables  functions  iscsi  iscsid  libvirt-guests  netcf-transaction  netconsole  network  README

A suivre!

Automount via systemd

Edouard — Mon, 04 Feb 2013 19:44:00 +0100

Quand il est nécessaire d'accèder à des systèmes de fichiers particuliers, à travers le réseau (NFS, CIFS, etc) ou sur une ressource pas toujours disponible (disque externe USB), voire même pour soulager les requêtes sur ce montage, il est utile de passer par la fonctionnalité "automount". Comme son nom l'indique, cela permet de monter automatiquement un point de montage, dès la première requête d'accès sur ce dernier. L'inverse est aussi de mise, démonter le point de montage quand celui-ci n'a pas été accédé depuis un certain temps (timeout).

Avant il fallait passer par autofs/automount, et configurer un ou plusieurs fichiers de configuration pour indiquer les points de montage à gérer. Rien de très complexe ceci dit. Mais aujourd'hui, le fameux remplaçant de SystemVinit, systemd, a de nombreux avantages dont celui de prendre en charge nativement les points de montage, particulièrement pratique pour remplacer autofs/automount.

Il y a deux possibilités pour configurer un point de montage automatique avec systemd:

via les fichiers unit de systemd, avec la création d'un fichier .automount et son associé en .mount
via directement le fichier /etc/fstab

Comme ici, le but est de faire plus simple qu'à l'époque de autofs, nous allons juste voir la méthode via fstab. Attention c'est simple, il suffit d'ajouter une ligne classique du montage souhaité, et dans les options d'ajouter la mention x-systemd.automount. Et voilà le tour est joué.

Exemple avec un montage nfs4:

srvnfs:/nfs/exports/home /mnt/nfs/home nfs4 x-systemd.automount 0 0

Exemple avec un disque externe usb (ex /dev/sdb1):

UUID=a2969b8d-c90a-432e-8198-f697c23f8c96 /mnt/externe		  ext4	  noauto,x-systemd.automount 0 0

(blkid /dev/sdb1 pour avoir l'UUID).

Au prochain reboot, au moindre accès dans le point de montage indiqué par x-systemd.automount, ce dernier sera automatiquement monté. C'est magique!

Fin de vie de la Fedora 16

Edouard — Thu, 17 Jan 2013 16:43:00 +0100

La Fedora 18 étant disponible depuis le 15 janvier dernier, il va falloir penser à mettre à jour si vous êtes en retard. En effet, chez Fedora, la version n-2 devient obsolète et n'est plus maintenue.

Alors si vous utilisez encore une Fedora 16, notez bien dans vos agenda qu'elle sera considérée comme morte à partir du 12 février prochain (EOL: End Of Life). Donc plus de mises à jour pour cette version, plus de correctifs de bugs ou de sécurité (le plus gênant). Il est donc important de passer à une version plus récente (Fedora 18 par exemple, autant prendre la dernière).

Pour télécharger une Fedora récente: Le site officiel

Pour mettre à jour votre Fedora: Procédure de mise à jour

Un GO pour la Fedora 18

Edouard — Wed, 09 Jan 2013 23:43:00 +0100

Enfin! Le GO vient d'être donné pour la sortie officielle de la Fedora 18 (Spherical Cow), la date sera donc le 15 janvier prochain.

Après plusieurs mois de retard, principalement lié à la refonte importante du programme d'installation Anaconda, cette prochaine version qui commençait à se faire attendre arrive enfin. Il aura fallu reporter sa sortie près de 7 fois, ce qui est surement une première chez Fedora, pour enfin corriger les derniers bugs bloquants. Vivement le 15!

Tout plein de nouveautés comme à chaque fois:

Gnome 3.6
Firewalld
toujours plus de systemd
DNF
oVirt 3.1
Samba 4
MATE, xfce etc

J'en oublie surement, la liste est longue: ici

Plus que quelques jour à attendre.

La Fedora 18 est disponible en beta

Edouard — Thu, 29 Nov 2012 08:20:00 +0100

La Fedora 18 vient de passer une étape importante en vue de sa sortie finale avec la sortie de sa Beta. L'arrivée de cette Beta a été reporté plusieurs fois suite à quelques bugs importants, principalement dans l'installeur. Mais après quelques semaines de retard, la Beta est enfin là! Vous pouvez donc contribuer à son amélioration en testant cette version.

Pour télécharger la beta: http://fedoraproject.org/get-prerelease

Il peut bien entendu rester quelques problèmes, qui sont normalement référencés sur cette page: F18 Common Bugs (par exemple l'installation de MATE depuis le DVD d'installation est HS).

Plusieurs méthodes sont disponibles pour installer une Fedora 18:

soit directement depuis un média d'installation ou un liveCD (le DVD d'installation a souvent moins de problèmes)
soit avec preupgrade depuis une ancienne Fedora (depuis la 17 ce sera plus facile)
soit avec yum en suivant la procédure habituelle, décrite ici
soit avec le nouvel outil FedUp

Pour les fonctionnalités apportées par la Fedora 18, beaucoup de choix concernant l'environnement graphique:

Gnome 3.6
Nouvelles versions pour KDE, XFCE, Sugar
Arrivée de MATE (fork de Gnome2)
Cinnamon est toujours présent (fork de Gnome3)

Mais aussi un nouvel installeur, complètement repensé. Cf Anaconda 18

Pour avoir un aperçu plus détaillé des nouveautés: http://fedoraproject.org/wiki/Releases/18/FeatureList

Pour rappel la Fedora 18 "Spherical Cow" est prévue pour le 8 janvier 2013.

Bon test!

La Fedora 19 s'appellera...

Edouard — Fri, 09 Nov 2012 10:52:00 +0100

Si vous êtes contributeurs Fedora, pensez à aller voter pour le nom de la prochaine Fedora, la version 19. Après le "Spherical Cow" de la Fedora 18, on commence enfin à s'éloigner de la bouffe américaine! Voici les noms proposés au vote:

Cubical Calf
Higgs Boson
Loch Ness Monster
Martian Blueberries
Newtonian Dynamics
Parabolic Potassium
Schrödinger's Cat
Tiddalik

Par contre, l'influence ubuntuesque reste encore un peu présente. Certains noms risquent en plus d'être difficile pour les graphistes (surtout pour le Schrödinger's Cat), mais on commence à avoir l'habitude de ne plus avoir de thèmes graphiques en rapport avec le nom de notre Fedora, ce qui est un peu dommage. Pour ma part j'ai une préférence pour Higgs Boson et Tiddalik, et vous?

source: ici (pour voter)

Adieu yum, bonjour dnf!

Edouard — Sat, 20 Oct 2012 10:51:00 +0200

Adieu yum, ce n'est peut être pas pour tout de suite quand même! Mais cela approche...

Le fabuleux gestionnaire de paquets yum (YellowDog Updater Modified), que nous utilisons depuis les débuts de Fedora, n'a jamais cessé de s'améliorer au fil du temps. Il a toujours été simple à utiliser, pas forcément rapide ni efficace dans la gestion des dépendances au tout début, mais il est maintenant un des meilleurs gestionnaires de paquets disponibles. Son succès l'amène d'ailleurs sur la plus part des distributions basées sur des RPMs.

Ses avantages aujourd'hui sont à mon avis les suivants:

Une seule commande comme point d'entrée (yum)
Une gestion automatique de son cache
Un affichage clair et efficace
Programmé en python
Fichiers de configuration simples et clairs
Facilité pour développer des plugins
Sa rapidité

Mais, bien souvent quand un produit arrive à une telle maturité, il peut être intéressant d'explorer de nouvelles pistes. Peut être pour contrer l'ennui de ses développeurs qui sait... Du coup, un fork a été crée, pas forcément avec délicatesse vis à vis des mainteneurs du yum originel, mais ça c'est fait. Le nouveau projet s'appelle DNF, ce qui ne veut rien dire car le nom est peut être temporaire. Il est censé améliorer certains points, déjà du point de vue des performances (ah?), de l'utilisation possible d'autres langages que python, et d'une mise à disposition d'une API claire et propre.

DNF est déjà disponible dans la Fedora 18, ce sera donc l'occasion de le tester. Mais il ne faudra pas s'attendre non plus à une révolution, l'ensemble du projet DNF étant un fork de yum il en utilise encore une très grande partie. D'ailleurs la commande dnf s'appellera peut être de nouveau yum quand elle pourra complètement le remplacer dans une future Fedora.

Le but premier de dnf est de fournir la bibliothèque hawkey qui s'appuie sur libsolv pour la résolution des dépendances. Pour information libsolv vient du monde openSuse. A terme toutes les résolutions de dépendances, pas forcément dans yum/dnf, s’appuieront sûrement sur libsolv.

Proposer une nouvelle API, plus propre/précise, permettra aussi une meilleure intégration dans l'environnement graphique. A voir ce que cela donnera dans Gnome par exemple.

Pour tester dnf, il suffit de l'installer:

yum install dnf

Les commandes dnf sont identiques (pour l'instant?) à yum, pas la peine d'en parler:

dnf help

Le fichier de conf se trouve logiquement dans /etc/dnf/dnf.conf. A voir sur le long terme ce que donnera dnf.

Configurer sysctl avec systemd

Edouard — Fri, 19 Oct 2012 19:51:00 +0200

Sur la prochaine Fedora 18, l'ancestral fichier /etc/sysctl.conf n'existe plus. Il faut maintenant déposer les modifications souhaitées dans un fichier .conf dans le répertoire /etc/sysctl.d.

Ce qui est dommage pour l'instant, c'est que la commande sysctl -p, que nous avions l'habitude de lancer pour prendre en compte les nouvelles modification, n'a pas connaissance de tout ceci. Elle finit donc en erreur. Ceci est dû au fait que les fichiers présents dans /etc/sysctl.d sont en réalité pris en charge par le service systemd-sysctl. Donc pour activer tout changement:

systemctl restart systemd-sysctl.service

Exemple concret pour l'activation des Magic Sysrq Keys:

echo "kernel.sysrq = 1" > /etc/sysctl.d/magic.conf
systemctl restart systemd-sysctl.service

Pour vérifier:

sysctl kernel.sysrq

Que de surprises avec cette Fedora 18!

Adieu Smolt, bonjour Census!

Edouard — Thu, 11 Oct 2012 06:10:00 +0200

Smolt pour ceux qui ne connaîtraient pas, est un projet pour collecter les informations matériels des utilisateurs Fedora/RedHat (et OpenSuse, merci Pingou). Le but étant d'avoir des statistiques détaillées sur le parc d'ordinateurs tournant sous un des OS au chapeau. Cela se présentait sous forme d'une page lors du premier démarrage de la machine, après son installation, demandant si les statistiques pouvaient être envoyées sur le serveur Smolt. Les informations envoyées étaient bien sûr anonymes, et l'utilisateur, s'il le souhaitait, pouvait les compléter, principalement pour indiquer le niveau de support du matériel (bref si son pc fonctionnait sans rien faire).

Exemple de page Smolt.

Malheureusement, Smolt n'est pas super bien maintenu. Par exemple il ne fonctionne pas sous RedHat 6. L'infrastructure hébergeant le service a aussi été mal conçue à la base, et est bien trop souvent inaccessible. De plus, tout le travail sur les statistiques collectées, le besoin d'origine, est que trop difficilement exploitable. Partant de ce constat, Smolt ne sera plus utilisé et va devoir bientôt prendre sa retraite.

Ce départ en retraite sera progressif, mais il est déjà prévu pour la fin de l'année. Les requêtes seront redirigées vers des serveurs expliquant tout ceci. Ces redirections disparaîtront totalement fin 2013.

La Fedora 18 (dont la beta a été retardé) ne devrait donc logiquement plus nous proposer l'envoie des données vers Smolt.

Bien sûr le besoin d'origine, disposer de statistiques sur le matériel des utilisateurs et son bon support est toujours présent. Un remplaçant de Smolt est donc déjà prévu, ce sera le projet "Census". Pour l'instant pas plus d'information sur ce dernier.

Anaconda 18

Edouard — Thu, 27 Sep 2012 19:53:00 +0200

Un des changements qui sera sûrement le plus visible dans la prochaine Fedora sera celui concernant le programme d'installation Anaconda.

Ce dernier a été complètement repensé et s'oriente vers un menu principal, puis des éléments à configurer dans l'ordre qu'on veut, avant de lancer l'installation (un peu à la slackware, en plus jolie). Fini l’enchaînement d'étapes linéaires. Bien sûr tant que les éléments obligatoires n'ont pas tous été configuré, l'installation ne se lance pas.

En image pour mieux se rendre compte, avec l'écran principal:

Un exemple de page de configuration:

Notez l'emplacement du bouton "back", peut être pas le meilleur emplacement.

Enfin sur le DVD d'installation, la page pour choisir son environnement (Gnome, KDE, etc):

Je dois dire que l'aspect global est plutôt réussi, et la configuration de l'installation semble se faire en un minimum d'étapes, ce qui la rend beaucoup plus simple. Le travail n'est bien sûr pas terminé (le partitionnement est une horreur), mais c'est déjà prometteur.

L'installation en mode texte a aussi été revu sur le même principe, encore plus light du coup (style *BSD):

Faudra voir ce qu'en penses les utilisateurs??

Les nouveautés attendues pour Gnome 3.6

Edouard — Mon, 24 Sep 2012 08:48:00 +0200

Je dois avouer que j'ai toujours aimer l'environnement Gnome, dès ces premières versions. Peut être pour son aspect différent, son orientation simpliste, ou encore l'énorme potentiel en terme de personnalisation. Il fait bien entendu partie des meilleurs environnements graphiques sous Linux (et autres Unix/BSD/etc), et certainement un des plus connus avec KDE. J'essaye toujours de donner leur chance à d'autres bureaux, que ce soit sur mes machines personnelles ou au travail (2 cadres d'utilisation bien distincts). C'est d'ailleurs toute la puissance de Linux ici de pouvoir proposer ce genre de choix, certains sont concurrents (MATE, Gnome, XFCE, Cinnamon), d'autres visent des orientations complètement différentes (Gnome vs KDE). Pourvu que ça dure!

Pour en revenir au sujet, Gnome 3.6 sera de la partie avec la prochaine Fedora 18, prévue pour le mois de novembre (la version alpha vient de sortir si vous voulez tester). Voici quelques nouveautés attendues.

Une des grosses avancés dans Gnome 3 concerne l'uniformisation des notifications. Le bas de l'écran est en effet dédié à tous les petits messages qui avant nous popaient à la figure en nous empêchant d'être productif... Maintenant avec Gnome 3, les notifications sont plus discrètes, voire peut être un peu trop. Dans la version 3.6 cette barre de notification sera plus accessible, à la souris dès que celle-ci restera un moment en bas de l'écran (et pas que dans le coin inférieur droit). J'ai cru même comprendre qu'un système de "pression" sera présent, c'est à dire que plus vous forcerez le curseur vers le bas de l'écran, plus le système comprendra que vous souhaitez voir les notifications, afin d'éviter l'affichage non voulu dès que la souris passe en bas. Le look a été aussi relifté avec des icônes plus lisibles, avec un panneau qui remonte et non plus qui se superpose (avec l'effet brumeux qu'on connait). Il y a de grande chance que ce soit meilleur à l'usage, ne serait-ce que de ne plus avoir à aller dans le coin inférieur droit.

Le panneau activités a été lui aussi retravaillé, mais très légèrement. On y gagne en homogénéité et en accessibilité, tout peut se naviguer au clavier maintenant.

L'écran de verrouillage est complètement retravaillé, l'effet de mode Windows 8 et/ou tablette étant très fort en ce moment, un effet de glisser est proposé pour déverrouiller. J'avoue ne pas être fan des écrans qui semblent être plus simple à utiliser au tactile quand on est sur un écran classique, la souris ne se prête pas trop à ce jeu. Mais il faut dire que nous sommes en ce moment dans une période de transition vers le tactile (ou non), même les industriels se cherchent (ne serait-ce que sur les smartphones qui sont de plus en plus grand, ou les pc portables tactiles...). Et peut être qu'un jour nous aurons des tablettes où l'on peut installer n'importe quel OS, et donc Gnome... De toute façon avec Gnome, pas d'inquiétude ce sera forcément personnalisable. En dehors de ceci, l'écran de verrouillage propose l'affichage de l'heure de manière bien visible, et laisse certains raccourcis accessibles (par exemple pour la musique), un peu comme sous Android (une cible pour Gnome OS?). Les notifications seront aussi présentes.

Les options d'accessibilité seront activées par défaut. Les méthodes d'entrées ont encore été amélioré, si vous aimez écrire dans d'autres langues.

Une des parties les plus améliorée dans cette version 3.6 concerne le gestionnaire de fichiers Nautilus. En dehors de quelques retouches de mise en forme, principalement sur le panneau latéral, il propose désormais un vrai moteur de recherche. Certaines fonctionnalités ont été retravaillé (par exemple copier vers, déplacer vers), à voir à l'usage si cela va dans le bon sens.

Cette nouvelle itération pour Gnome semble apporter à son tour pas mal de bonne choses, qui seront confirmées (ou pas) dès les premiers mois d'utilisation. La prochaine Fedora 18 sera donc la première version à intégrer Gnome 3.6, il ne reste plus qu'à attendre la sortie finale.

Fedora 18 alpha

Edouard — Tue, 18 Sep 2012 16:40:00 +0200

Juste une brève information pour signaler la sortie "officielle" de la Fedora 18 alpha.

Voici une liste non exhaustive des nouveautés:

Pour l'environnement graphique

NetworkManager Hotspots facilite la création de hotspot wifi
Conception nouvelle pour le système d'installation, plus de flexibilité en simplifiant l'interface
Gnome 3.6, KDE 4.9, Xfce 4.10, Sugar 0.98, ainsi que l'arrivée de MATE (fork de Gnome2)

Pour les sysadmins

Base de données NoSQL Riak
Samba 4 pour le support SMB3 et des domaines de confiance FreeIPA
Système de mises à jour offline pour installer les paquets au démarrage
Fedora 18 sera capable de joindre facilement un domaine AD ou un royaume FreeIPA

Pour les développeurs

Python 3.3
Rails 3.2
Perl 5.16 supporte l'Unicode 6.1
L'optimisation Power7 ppc64p7 est ajoutée comme plateforme supportée pour les paquets Fedora 18

Nuage et Virtualisation

OpenShift Origin (PaaS)
Eucalyptus pour les infrastructures privées compatibles AWS (IaaS)
Les paquets OpenStack sont synchronisés avec la version "Folsom" prévue pour la fin septembre
Heat pour fournir une API d'orchestration pour les applications dans le nuage. Il s'agit d'un projet en rapport avec OpenStack.
Virt Live Snapshots permet de faire des snapshots de machines virtuelles QEMU/libvirt sans avoir à les arrêter
oVirt est mis à jour en version 3.1 avec de nouveaux outils graphiques

Pour en savoir plus, ou si vous souhaitez contribuer en essayant cette version, n'hésitez pas à lire la release note ainsi que les bugs connus. La liste des fonctionnalités de la Fedora 18 est ici.

Version finale de la Fedora 18 prévue en novembre 2012.

Compiler OpenElec pour Raspberry Pi

Edouard — Fri, 14 Sep 2012 17:49:00 +0200

Les pré-requis pour la compilation

Pour récuperer les sources il faut un client git:

yum install git

Il faut ensuite les paquets classiques pour compiler:

yum install gcc-c++ flex bison gawk gperf autoconf automake m4 \
cvs libtool texinfo gettext libxslt expat zlib-devel ncurses-devel zip

La commande pour récupérer les sources est la suivante:

git clone git://github.com/OpenELEC/OpenELEC.tv.git

Avant de compiler il faut se placer dans la repertoire des sources:

cd OpenELEC.tv

Pour mettre à jour de temps en temps les sources, il suffira de faire un git pull.

La compilation

Les sources d'OpenElec peuvent couvrir plusieurs projets, celui qui nous interesse ici est le projet "RPi". L'architecture pour la compilation sera "arm". La commande pour la compilation (spécifique à OpenElec) est la suivante:

PROJECT=RPi ARCH=arm make

La compilation peut être assez longue. Si tout ce passe bien, la compilation se termine par la création de l'image système au format SquashFS. Ce qui nous intéresse maintenant se découpe en 3 parties:

Une partie qui gère le boot
le kernel
le système incluant xbmc

Ces 3 parties vont être copiées dans la partition "System" qui peut être vu comme une partition /boot en gros.

Préparation de la carte SD

Pour fonctionner, il faut une carte SD partitionnée (avec fdisk par exemple) comme suit:

une partition vfat de 128Mo, flaguée bootable
une partition ext4 utilisant le reste de la carte SD

La partition en vfat de 128Mo devra être labelisée en tant que "System", l'autre partition en ext4 en tant que "Storage".

Pour formater en vfat avec le label "System":

mkfs.vfat -n System /dev/<carte SD partition 1>

Pour formater en ext4 avec le label "Storage":

mkfs.ext4 -L Storage /dev/<carte SD partition 2>

L'installation sur la carte SD

Le bootloader

La première partie à copier sur la carte SD gère le boot, elle se décompose en 3 fichiers:

arm128_start.elf
bootcode.bin
loader.bin

Ces 3 fichiers sont à copiés sur la carte SD dans la partition System, par exemple montée dans /media/System. Le arm128_start.elf est à renommer en start.elf. Les commandes de copies sont les suivantes:

cp build.OpenELEC-RPi.arm-devel/bcm2835-bootloader-*/arm128_start.elf /media/System/start.elf
cp build.OpenELEC-RPi.arm-devel/bcm2835-bootloader-*/bootcode.bin /media/System/
cp build.OpenELEC-RPi.arm-devel/bcm2835-bootloader-*/loader.bin /media/System/

Le répertoire bcm2835-bootloader-* contient dans son nom un numero de release qui varie en fonction des sources récupérées, d'où le "*". Si un "make clean" est exécuté avant chaque compilation, il n'y aura qu'un seul répertoire bcm2835-bootloader-<release>, dans le cas contraire, et si les sources concernant le bootloader ont été mises à jours, il pourrait y en avoir plusieurs.

Le kernel

Le kernel sous format de fichier image, se trouve dans le répertoire target. Son nom de fichier contient un numero de release et peut donc varier en fonction des sources utilisées. Il est à copier sur la carte SD dans la partition System, en le renommant en kernel.img. La commande est la suivante:

cp target/OpenELEC-RPi.arm-devel-*.kernel /media/System/kernel.img

Le système

Le système est dans un fichier image au format SquashFS. Cette image est créée en fin de compilation et se trouve dans le repertoire target. Son nom de fichier contient lui aussi un numéro de release, qui peut donc varier en fonction des sources utilisées. Cette image du système est à copier sur la carte SD, toujours dans la partition System, renommée en SYSTEM. La commande est donc la suivante:

cp target/OpenELEC-RPi.arm-devel-*.system /media/System/SYSTEM

Conclusion

Rien de bien compliqué en soit, grâce au fichier configurant le projet "RPi" et à l'excellent travail de l'équipe OpenElec. Il ne reste plus qu'à démonter la carte SD et l'insérer dans le Raspberry Pi.

Ce billet est en gros une traduction allegée de la documentation issue du wiki officiel consultable ici.

OpenElec/XBMC pour Raspberry Pi

Edouard — Sat, 08 Sep 2012 11:50:00 +0200

Pour ceux que ça intéresse, je compile régulièrement depuis peu la version d'OpenElec avec XBMC 12 alpha (frodo) pour Raspberry Pi. Les fichiers sont disponibles à cette adresse.

Pour se servir de ces fichiers, il faut:

1 raspberry pi
1 carte SD (512Mo minimum)

Après voir récupéré une des archives et l'avoir décompressée, voici la procédure à suivre:

Sur la carte SD, creer 2 partitions:

la 1ere de 128Mo en fat32 flag bootable, label System (mkfs.vfat -n System /dev/SDCARDp1)
la 2e du reste de la carte en ext4, label Storage (mkfs.ext4 -L Storage /dev/SDCARDp2)

Copier les fichiers presents dans le repertoire System dans la racine de la partition vfat de 128Mo. Au final cette partition doit contenir:

bootcode.bin
cmdline.txt
kernel.img
loader.bin
start.elf
SYSTEM

Le premier boot peut être plus long vu que certains fichiers vont être créés sur la partition Storage.

Normalement je teste tout ça avant d'uploader, avoir une version très à jour permet de tester pas mal de chose, comme le support CEC, le nouveau moteur Audio d'XBMC etc. Même si tout ceci est en version alpha, cela reste très utilisable.

Je ferais un autre billet sur la compilation de tout ça, car ce n'est pas bien compliqué au final.

Monter un PC de salon, le choix du matériel

Edouard — Mon, 03 Sep 2012 08:47:00 +0200

L'objectif du PC de salon (ou HTPC pour faire court), c'est de pouvoir regarder ses films de vacances, des photos ou encore écouter de la musique, le tout confortablement installé dans son salon. Une interface logiciel visuellement agréable est souhaitable, ce qui correspond complètement à XBMC.

XBMC permet de gérer sa médiathèque en tout simplicité, les fichiers pouvant être stockés sur différents support, du disque interne/externe, au partage samba/NFS/aFS etc. Il gère en plus des profils utilisateurs ce qui est bien pratique. Les gros avantages de XBMC sont qu'il récupère certaines informations sur le net, vous avez donc ainsi un résumé du film, une note (imdb), la durée, la qualité etc et surtout il retient où vous vous êtes arrêté dans le film et coche quand ce dernier a été vu en entier. Extrêment pratique. Il est hautement personnalisable via des addons et autres thèmes directement installables depuis l'interface XBMC.

Revenons au matériel. Ce PC est donc forcément relié à une TV (ou vidéoprojecteur) et éventuellement à un kit Home Cinema pour le son. Le plus consommateur en ressource étant les films, qui sont de plus en plus souvent en HD maintenant. De ce constat simple, nous pouvons déjà établir quelques critères:

1 connexion HDMI (incontournable) vers l'ampli ou la TV
Assez de ressources pour lire des video HD

Ces critères vont nous aider à choisir le bon matériel. En fait, c'est assez simple, et pas forcément coûteux vu qu'il n'est pas du tout nécessaire d'avoir le dernier i7 pour s'en sortir (au contraire). Pour affiner notre sélection, rajoutons qu'il faut que l'ensemble soit très silencieux et plutôt faiblement encombrant, installation dans un salon oblige. Pour être sûr du silence, le plus simple est d'opter pour un PC faible consommation. Qui dit faible consommation, dit faible dégagement thermique et donc peu ou pas de ventillation, parfait pour notre usage. Il vaut mieux aussi opter pour une alimentation externe si c'est possible, toujours dans l'idée d'éviter du bruit. Si nous complétons notre liste de critères, cela donne:

1 connexion HDMI vers l'ampli ou la TV
Assez de ressources pour lire des video HD
Peu coûteux
Petit
Silencieux
Faible consommation électrique
Alimentation externe

Le choix est donc simple car avec ces critères, il ne reste plus grand chose. Il sera difficile de faire tenir un i7 ou autre machine de course la dedans. Heureusement, depuis quelques années maintenant, avec l'arrivée des netbooks, une gamme de PC de bureau, utilisant le même matériel, (dit nettop) convient parfaitement. Au niveau CPU, il s'agit d'Intel ATOM au minimum double-coeur tournant autour des 1.5Ghz. Largement suffisant pour lire des videos en qualité standard, de la musique et des photos. Il existe l'équivalent chez AMD (avec les NEO). En tout cas c'est bien cette catégorie de PC qui nous intéresse mais il reste la partie video HD à traiter.

Concernant la partie video HD, c'est sur ce point qu'il faut faire attention. XBMC supporte depuis assez longtemps l’accélération video. La première couche a avoir été supporté est VDPAU pour les cartes NVIDIA. Le support pour les cartes AMD est arrivé il y a quelques mois. Pour le reste c'est un peu le néant à part quelques projets exotiques (le Raspberry Pi par exemple). Je n'ai pas eu le temps de tester complètement avec une carte AMD/ATI, donc pour être sûr d'éviter les galères, il vaut mieux partir sur du NVIDIA. Mais attention, une carte à 30€ suffit du moment qu'elle prend en charge le décodage video.

Pour la mémoire, 1 ou 2Go sera largement suffisant. Ce qui nous donne la liste suivante:

1 connexion HDMI vers l'ampli ou la TV
Assez de ressources pour lire des video HD
Peu coûteux
Petit
Silencieux
Faible consommation électrique
Alimentation externe
Carte graphique NVIDIA

Normalement avec cette liste, le budget devrait tourner autour des 200, 300€ max. J'avais pour ma part opter il y a un peu plus de 3 ans pour un PackardBell Imax Mini (équivalent d'un Acer Aspire Revo), comprenant un Intel Atom 230, un chipset ION, 2Go de RAM et 160Go de disque dur. Le tout à l'époque en promo à Carrefour pour 209€. Avec un câble HDMI à 4€ le budget total était de 213€. Dur à l'époque de faire moins. Je parlerais surement dans un futur article de la solution Raspberry Pi pour faire un mediacenter à 30€. Aujourd'hui, j'hésiterais surement avec différentes marques mais en restant sur le même type de matériel (ATOM + chipset NVIDIA ION), comme Asus, Zotax, ou même Shuttle qui propose un modèle complètement passif!

Pour le système d'exploitation, la dernière Fedora 17 est parfaite pour cet usage, forcément. L'installation des pilotes NVIDIA et d'XBMC se faisant depuis les dépôts RPMFUSION. Le fait de disposer d'un vrai PC avec un vrai OS permet de pouvoir utiliser la TV comme écran, pour par exemple surfer, lire ses mails etc. Le tout étant aussi bien plus souple qu'une solution matériel type divx box.

Les paquets PHP n'imposeront bientôt plus Apache

Edouard — Fri, 31 Aug 2012 17:08:00 +0200

Les dépendances avec les RPMs c'est toujours du bonheur, surtout quand on se rappelle que l'époque où il fallait gérer tout ça à la mimine n'est pas si lointaine. Mais dès que l'on sort des clous, on se rend vite compte que ce n'est pas tout rose.

L'explication est simple, un mainteneur de paquet est bien souvent une grosse loutre oisive. Donc si le paquet marche chez lui, ça marchera chez tout le monde. CQFD.

Typiquement cela concerne les modules ou logiciels optionnels habituellement fait pour un logiciel ou moteur X mais qui peuvent tout à fait fonctionner avec un logiciel/moteur Y. Concrètement, le cas de figure le plus courant étant les paquets PHP. Si vous faites comme tout le monde et que vous utilisez Apache, pas de problème. Mais si vous êtes au choix aventureux, russe ou rusé, il est possible que vous utilisez Nginx par exemple, qui est une solution alternative à Apache. Et du coup, installer un paquet d'un logiciel en PHP qui par dépendance vous installe Apache, ça peut vite vous rendre nerveux...

Heureusement, et mieux vaut tard que jamais, le guide des bonnes pratiques pour les paquets PHP vient d'être mis à jour chez Fedora, indiquant enfin, qu'il n'était pas normal d'imposer une dépendance sur httpd (=Apache). Que la vie va être belle maintenant!

A lire: Packaging Guidelines

NB: ceci devrait aussi impacter les paquets RPM sur RedHat et clones, à plus ou moins long terme...

NB2: Mon avocat me signale qu'il reste cependant une petite feinte digne d'un contrat d'assurance: les paquets PHP pourront toujours avoir une dépendance sur Apache du moment qu'ils proposent un fichier de configuration pour ce dernier. J'espère que ces paquets créeront rapidement un paquet <variante>-apache sinon tout cela ne changera pas grand chose...

Fonctionnalités de la Fedora 18

Edouard — Wed, 08 Aug 2012 15:35:00 +0200

This is not a bug! It's a feature!

Depuis le 7 août, les fonctionnalités pour la future Fedora 18 (nom de code: "vache sphérique"...) sont gelées, non pas pour actes de terrorisme ou autre fricotage avec wikileaks mais bien parce que c'est prévu dans le processus classique du cycle de vie de chaque version de Fedora. Donc plus aucune proposition ne sera acceptée (même les plus indécentes), ce qui permettra aux différents contributeurs du projet de pouvoir se focaliser sur leurs intégrations. Le but étant de peaufiner de manière complètement assumée et décontractée les détails pour la sortie finale, toujours prévue pour début novembre 2012 (le 6/11/2012 pour l'instant).

Nous en savons donc un peu plus sur ce que cette prochaine version nous proposera:

Le tout jeune Samba 4 (s'il sort à temps)
Le fork de Gnome 2 aka "MATE", pour les conservateurs allergiques à Gnome 3 (il en faut)
Python en version 3.3 (on ne l'arrête plus)
(Free)IPA pour le support de délégation de confiance sur des domaines Active Directory (pour les gens encore sous Windows)
Quelques bonnes choses pour la virtualisation (QXL/Spice, oVirt, OwnCloud etc)
Pour la sécurité, firewalld, SELinux intégré à Systemd pour la gestion des accès

Mais les plus remarquables sont:

DNF, qui à terme remplacera le gestionnaire de paquets yum après de si longues années de service (snif)
Le support de 256 couleurs pour les terminaux (youhou!!!! comment on a pu vivre sans jusqu'à présent??)
KDE 4.9, Gnome 3.6, XFCE 4.10 pour les principaux enjoliveurs de bureau

Et le meilleur pour la fin, remarquable par son absence: BtrFS (ou le Duke Nukem Forever des Files System)... Aller on y croit ce sera pour la Fedora 19!

Pour suivre le calendrier de la Fedora 18, c'est par ici.

Pour en apprendre plus sur ses fonctionnalités, c'est par là.

Virtualiser dans une VM

Edouard — Tue, 17 Jul 2012 16:03:00 +0200

Il peut être intéressant de pouvoir virtualiser à l'intérieur même d'une VM, que l'on soit adepte des scénario type Inception, des poupées russes, ou tout simplement pour tester des choses, comme les solutions logiciels de gestion de datacenter virtualisé (ou autres termes fumeux, tel que cloud, private cloud, etc). Heureusement, depuis quelques temps il est possible d'activer le support de la virtualisation dans une VM avec KVM, en anglais, nested kvm.

Pour l'activer, il faut créer un fichier /etc/modprobe.d/kvm_nested.conf avec le contenu suivant:

options kvm_intel nested=1
options kvm_amd nested=1

Au prochain chargement du module kvm que vous utilisez, l'option sera prise en compte. Ne pas oublier d'activer le flag svm (pour Amd) ou vmx (pour Intel) dans la configuration de la VM (dans virt-manager, details de la VM, Processor, Configuration, CPU Features).

Dans la VM, un cat /proc/cpuinfo permet de voir le flag souhaité:

flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc up arch_perfmon rep_good nopl pni __vmx__ ssse3 cx16 sse4_1 __hypervisor__ lahf_lm

En terme de performance, il ne devrait pas y avoir de soucis, cela donne bien accès aux registres CPU dédiés à la virtualisation, ce n'est pas une émulation/encapsulation.

Ralonger l'historique du shell

Edouard — Thu, 05 Jul 2012 10:21:00 +0200

En shell, l'historique joue un rôle bien pratique en nous permettant de rappeler et/ou de retrouver d'anciennes commandes. Par défaut il ne conserve que 1000 entrées, ce qui suffit bien souvent. Mais sur des serveurs très utilisés, ou pour n'importe quelle autre raison, il est possible de changer cette valeur. Pour cela il suffit d'ajouter dans votre ~/.bashrc la ligne suivante (où de la corriger si elle existe déjà):

export HISTSIZE=3000

Cette valeur sera prise en compte au prochain login, mais pour que ce soit pris en compte immédiatement, au choix:

source ~/.bashrc
ou taper la commande export HISTSIZE=3000

Pour s'en assurer:

echo $HISTSIZE

Pour voir la taille actuelle de l'historique:

history | wc -l

J'avais déjà cité il y a quelques temps des raccourcis bien pratiques, certains utilisent l'historique.

PS: cette méthode a été testé sous bash uniquement.

Fin de vie de la Fedora 15

Edouard — Fri, 01 Jun 2012 11:58:00 +0200

A chaque nouvelle sortie de Fedora, la même histoire recommence. La version n-2 devient obsolète et n'est plus maintenue. Alors si vous utilisez une Fedora 15, notez bien dans vos agenda qu'elle sera concidérée comme morte à partir du 26 juin prochain (EOL: End Of Life). Donc plus de mises à jour pour cette version, plus de correctifs de bugs ou de sécurité (le plus gênant). Il est donc important de passer à une version plus récente (Fedora 17 par exemple, autant prendre la dernière).

Pour télécharger une Fedora récente: Le site officiel