Syndiquer le contenu
Mis à jour : il y a 2 heures 20 min

pkgsrc 2014Q3 est disponible

6 octobre, 2014 - 11:13

Dans un message à des listes de diffusion pkgsrc et NetBSD, Alistair Crooks a annoncé la disponibilité de la branche pkgsrc-2014Q3. Pkgsrc (prononcer package source) est une infrastructure de construction de logiciels tiers pour NetBSD, ainsi que pour d’autres systèmes de type UNIX. Il permet donc à NetBSD et à d’autres systèmes d’exploitation de disposer de nombreux logiciels sous forme source, mais aussi sous forme binaire.

Les développeurs pkgsrc fournissent une nouvelle version stable chaque trimestre. Comme son nom l’indique, pkgsrc 2014Q3 est donc la troisième sur les quatre de 2014 et est disponible depuis le 2 octobre dernier.

Plus de détails sur cette version en particulier en seconde partie de dépêche, qui reprend grandement le courriel d'annonce.

Si vous ne connaissez toujours pas pkgsrc

À force de publier des dépêches sur le sujet (suivez le tag pkgsrc), espérons que vous commencez à connaître la chanson : pkgsrc, c'est le système de paquets logiciels pour NetBSD, issu d'un fork en 1997 de celui de FreeBSD. Nos amis au drapeau orange étant adeptes de la portabilité, il est logique que leur système de paquets puisse fonctionner ailleurs et compte toujours sa vingtaine de plateformes compatibles, allant des systèmes BSD à Windows (grâce à Cygwin/Interix/Services For Unix) en passant par GNU/Linux, OS X et Solaris.

Les chiffres du trimestre

En termes de paquets, pkgsrc-2014Q3 c’est (avec entre parenthèses la différence avec pkgsrc-2014Q2) :

  • 15186 paquets possibles ;
  • 14741 paquets binaires compilés avec clang pour NetBSD-current/x86_64 (- 154) ;
  • 13120 paquets binaires compilés avec gcc pour SmartOS/i386  (+ 1083) ;
  • 13026 paquets binaires compilés avec gcc pour SmartOS/x86_64 (+ 391) ;
  • 13484 paquets binaires compilés avec gcc pour Linux-2.6.32/x86_64 (+366) ;
  • 11478 paquets binaires compilés avec gcc pour Darwin 10.8.0/i386 (+1495) ;
  • 12363 paquets binaires compilés avec clang pour FreeBSD 10/x86_64 (+ 47).

À noter aussi : 13016 paquets binaires compilés en utilisant dash (et non bash) comme shell pour la plateforme SmartOS/i386.

Ce trimestre, en termes de modifications, il y a eu :

  • 210 paquets ajoutés ;
  • 15 paquets retirés, dont 12 avec un successeur ;
  • 1 123 paquets mis à jour ;
  • 3 paquets ont été renommés.
Les changements

Parmi les ajouts ou mises à jour notables, on peut remarquer :

On dira par contre au revoir à l'ancien subversion-1.6.

Si vous utilisez NetBSD 5.x, sachez que par défaut c'est l'option X11 modulaire qui est utilisée. Cela signifie qu'au lieu d'utiliser la version de X11 qui est dans le système de base, les paquets X11 de pkgsrc, généralement plus récents, seront construits.

Bien entendu, pkgsrc-2014Q3 contient des paquets Bash patchés contre ShellShock. De plus, Christos Zoulas avait effectué un patch pour désactiver les définitions de fonctions dans les variables d'environnement.

Deux jours de rab' !

Pour amener à une nouvelle version de pkgsrc, le calendrier est généralement le suivant :

  • deux mois et demi de mises à jour diverses et variées dans pgksrc-current ;
  • deux semaines de gel (freeze dans la langue de Shakespeare) : durant cette période, les changements qu'on peut qualifier d'intrusifs ou devant être testés en profondeur ne sont pas acceptés dans pgksrc-current, comme par exemple des nouveaux paquets, des mises à jour majeures (si elles ne sont pas motivées par un correctif critique) ou des modifications d'infrastructure ;
  • à la fin de la période de gel, la branche est créée, mais n'est pas figée pour autant : elle bénéficiera de correctifs de sécurité par exemple.

Cette fois-ci, Alistair Crooks a annoncé le 29 septembre dernier deux jours supplémentaires de gel. Deux raisons ont motivé cette décision :

  • beaucoup de changements ont encore lieu dans pkgsrc et peuvent donc nécessiter un peu de temps pour que les tests soient menés correctement ;
  • Shellshock est arrivé durant la période de gel : cela a peut-être plus d'impact qu'on ne le pense.

Le courriel annonçant la décision indique que le but est d'avoir la meilleure branche possible et que prendre un peu plus de temps maintenant sera payant sur le long terme.

Télécharger ce contenu au format Epub

Lire les commentaires

systemd versions 212 à 215

6 octobre, 2014 - 09:59

systemd est un système de démarrage alternatif au démon init d’UNIX System V spécifiquement conçu pour le noyau Linux, avec une meilleure gestion des dépendances entre services et le chargement en parallèle des services au démarrage. Il est publié sous licence GNU LGPL version 2.11.

Voici une version traduite, réarrangée et non exhaustive des notes de version de systemd des versions 212 à 215. En bref, on ajoute un peu de sucre autour ! Vous pouvez même sauter ce qui ne vous intéresse pas.

N. D. M. : cette dépêche est un énorme travail d’eggman et de sinma qui méritent tous les deux des gros remerciements.

Sommaire Version 212 Divers

systemd gère désormais un état global du système qui prend la valeur starting (en cours de démarrage), running (en fonctionnement), degraded (dégradé, c’est‐à‐dire au moins un service en échec), maintenance (mode de restauration ou d’urgence) ou stopping (en train de s’arrêter), que l’on peut consulter avec systemctl status (sans donner de paramètre). Il est notamment utile lorsqu’on manipule beaucoup de systèmes ou de conteneurs à la fois.

Et puis, enfin, un changement visible par l’utilisateur lambda ! Afin d’éviter que celui‐ci se retrouve avec un écran noir au démarrage, systemd évite le réglage le plus sombre et reste au‐dessus des 5 % les plus sombres lors de la restauration de la luminosité.

Côté fonctionnement interne, logind détruit maintenant automatiquement les objets d’IPC (InterProcess Communication, communication interprocessus) appartenant à un utilisateur quand il se déconnecte complètement, pour libérer des ressources. Cela inclut sémaphores, files de messages et mémoires SysV, ainsi que les files de messages et mémoires partagées POSIX. Les objets SysV et POSIX n’ont traditionnellement pas de cycle de vie, cette fonctionnalité corrige cela.

Outils en ligne de commande

Une nouvelle commande list-machines a été ajoutée à systemctl. Elle liste tous les systèmes d’exploitation dans un conteneur ainsi que leurs états (voir le point ci‐dessus), si systemd est utilisé dans ces conteneurs.

systemctl a également été enrichi d’une option -r pour énumérer récursivement les unités de tous les conteneurs locaux, quand il est utilisé avec la commande list-units (c’est l’action par défaut quand aucun paramètre n’est donné).

On notera aussi que machinectl bénéficie d’une nouvelle commande poweroff pour éteindre proprement un conteneur local.

Journal

journald peut transférer les messages de journal sur les pseudo‐terminaux de tous les utilisateurs connectés (équivalent de la commande wall). C’est désormais la configuration par défaut pour tous les messages d’urgence.

Le nouvel outil systemd-journal-remote permet de diffuser à la volée les flux des journaux journald sur le réseau.

Unités

Les unités minuteur (timer units) ont gagné deux nouvelles options :

  • WakeSystem= : si activée, les unités minuteur configurées de cette façon provoqueront la sortie de veille prolongée (si le système le prend en charge, ce qui est majoritairement le cas de nos jours) ;

  • Persistent= : si activée, sauvegarde sur le disque la dernière fois que l’unité a été activée. Cette information permet au redémarrage suivant d’activer les évènements qui auraient dû avoir lieu pendant que le système était éteint (comportement analogue à anacron). La commande list-timers de systemctl a été mise à jour pour afficher cette nouvelle information.

Réseau

Les adresses physiques des interfaces (adresses MAC) créées avec l’option --network-interface= de la commande nspawn sont générées à partir du nom de la machine, ce qui les rend stables entre plusieurs invocations du conteneur.

systemd-networkd alloue désormais des adresses prédictibles en cas d’auto‐configuration avec IPv4LL (IPv4 link-local, une technique qui permet d’assigner une adresse IP automatiquement dans le réseau spécial 169.254.0.0/16, quand il n’y a pas de serveur DHCP).

Découverte automatique des partitions GPT

Le mécanisme de découverte automatique des partitions GPT prend désormais en compte deux indicateurs (flags) sur une partition GPT : l’un provoque son montage en lecture seule et l’autre indique que la partition doit être ignorée pendant la phase de découverte automatique.

Deux nouveaux types d’identifiant universel unique (UUID) pour GPT ont été ajoutés à la découverte automatique de partitions, pour les architectures ARM 32 et 64 bits. Ça n’est pas particulièrement utile pour découvrir le répertoire racine pendant un démarrage bare‐metal (on n’y voit pas souvent d’UEFI), mais c’est quand même très utile pour autoriser le démarrage de disques dans nspawn avec l’option -i.

Sécurité

Le répertoire /sys/fs/cgroup/ est maintenant monté en lecture seule après que tous les arbres de contrôleurs y sont montés. Notez que les répertoires montés dans une sous‐arborescence ne sont pas en lecture seule. Cette mesure de sécurité est particulièrement utile car la glibc effectue une recherche pour prendre tous les pseudo‐systèmes de fichiers tmpfs qu’elle peut trouver pour implémenter shm_open() si /dev/shm n’est pas disponible (ce qui peut très bien être le cas dans un espace de noms donné).

Les options PrivateDevices=, PrivateNetwork= et PrivateTmp= sont maintenant utilisées sur tous les services tournant pendant une longue période (quand c’est approprié). En outre, l’option PrivateDevices= est plus sécurisée (elle ne nécessite plus la capacité CAP_MKNOD et l’ensemble des capacités liées, et implique DevicePolicy=closed).

Désormais, la gestion de kdbus prend en charge la politique de téléchargement dans le noyau. sd-bus peut désormais créer des connexions de surveillance (monitoring) qui peuvent espionner toutes les communications de bus pour déboguer.

udev dans un espace de noms de montage séparé

systemd-udevd va maintenant fonctionner dans un espace de noms de montage séparé. Pour bien comprendre, quelques explications s’imposent.

udev est un programme qui permet à l’ordinateur d’effectuer automatiquement certaines actions en fonction d’évènements liés au matériel (par exemple, monter automatiquement une clef USB lorsqu’elle est branchée à l’ordinateur). Les actions à effectuer sont déterminées grâce à des règles udev (des fichiers .rules habituellement fournis par la distribution, bien qu’il soit possible de les créer soi‐même). Or, ces règles permettent d’activer un programme ou un script arbitraire, via une ligne du type RUN+="mon_executable". Pour monter une clef USB, on fera appel au programme mount, par exemple.

Les espaces de noms de montage permettent de montrer une organisation du système différente (points de montage différents, ou passage de certains montages en lecture seule) pour certains processus. C’est notamment utile pour sécuriser les conteneurs.

Depuis quelques versions, il est recommandé de passer par l’activation d’un service systemd au lieu de l’utilisation de mount ; ça sera désormais obligatoire pour monter un périphérique. On utilisera donc : ENV{SYSTEMD_WANTS}="systemd_unit.service".

Amélioration du code

La prise en charge native de tcpwrap dans systemd a été supprimée. C’était du vieux code plus vraiment maintenu et qui avait de sérieux défauts. De meilleures alternatives existent, telles que les pare‐feux.

Pour les configurations qui nécessitent l’utilisation de tcpwrap, veuillez envisager d’invoquer votre service activé par socket via tcpd, comme avec le traditionnel inetd.

Version 213 Outils en ligne de commande

Concernant systemctl, les commandes systemctl list-timers et systemctl list-sockets disposent maintenant de l’option --recursive qui permet de lister les unités du type donné dans tous les conteneurs locaux, à l’instar de systemctl list-units.

Désormais, le générateur de graphe du démarrage (pour rappel : systemd-analyze plot) peut inclure les informations cgroups.

Le (petit) démon systemd-hostnamed a été mis à jour pour exposer le nom du noyau, sa variante et sa version sur le bus. C’est utile lorsque l’on exécute des commandes telles que hostnamectl avec l’option -H. systemd-analyze se sert de cette option pour afficher correctement les détails du système, lorsque l’exécution est distante.

Enfin, machined dispose d’une nouvelle interface de programmation (API) pour interroger les adresses IP des conteneurs enregistrés. machinectl status a été mis à jour pour afficher ces adresses dans sa sortie.

Unités

Cette fois, les unités de type service ont gagné beaucoup d’options pour permettre un contrôle beaucoup plus fin du comportement et des limitations de celles‐ci :

  • RebootArgument= peut être utilisé pour définir un argument de redémarrage pour le noyau, à utiliser si l’on déclenche un redémarrage avec StartLimitAction= ;

  • FailureAction= peut être utilisé pour définir une opération à déclencher quand un service échoue : ce paramètre fonctionne de façon similaire à StartLimitAction=, mais, contrairement à celui‐ci, il vérifie ce qui est effectué immédiatement, plutôt qu’après plusieurs essais de redémarrage du service ;

  • si CPUQuota= est activé, le service ne pourra jamais obtenir plus de temps processeur que le pourcentage indiqué, même si la machine est inoccupée ;

  • StartupCPUShares= et StartupBlockIOWeight= fonctionnent de façon similaire à CPUShares= et BlockIOWeight=, mais s’appliquent uniquement au démarrage du système ; ces deux options sont utiles pour assigner des priorités différentes à certains services pendant le démarrage et pendant l’exécution normale.

Dorénavant, l’analyseur de fichiers de configuration (.ini) ignorera les sections qui commencent par X-. Elles peuvent être utilisées pour maintenir des sections spécifiques à certaines applications dans les fichiers unités.

Réseau

Cette nouvelle version accueille un nouveau démon : systemd-timesyncd. C’est un client SNTP. Contrairement à un client NTP, il s’occupe simplement d’interroger un serveur distant et de mettre à jour l’heure de la machine (il est uniquement client, et non serveur).

systemd-timesyncd tourne avec des privilèges minimaux et n’agit que lorsqu’une connexion Internet est disponible. Il peut corriger l’heure tôt dans le processus de démarrage, ce qui est utile pour les systèmes comme le Raspberry Pi et d’autres appareils embarqués qui n’ont pas d’horloge temps réel.

systemd-networkd gère maintenant les tunnels IPIP et SIT, et se dote d’un nouveau compagnon, le démon minimal systemd-resolved. Il agit pour le moment comme simple compagnon à systemd-networkd et gère le resolv.conf en se basant sur la configuration DNS par interface, potentiellement obtenue via DHCP. À long terme, nous espérons l’étendre à la gestion d’un cache DNS gérant DNSSEC et mDNS.

Petite subtilité, systemd-networkd-wait-online est dorénavant activé par défaut. Il retarde network-online.target jusqu’à ce qu’une interface réseau ait été configurée. Cet outil est conçu pour fonctionner avant tout avec networkd, mais fera son possible pour donner du sens à une configuration réseau effectuée par d’autres moyens.

Autre subtilité, hostnamed a été modifié pour préférer le nom d’hôte configuré statiquement dans /etc/hostname à celui éventuellement fourni par DHCP. Cela correspond mieux au fonctionnement global de /etc, où la configuration de l’administrateur prévaut sur n’importe quelle autre.

Autre

La nouvelle option du noyau fsck.repair= contrôle comment fsck doit se comporter avec un système de fichiers incohérent au démarrage.

Version 214

Voilà la version 214 ! Truffée de nouvelles fonctionnalités et d’améliorations dans tous les domaines, en particulier en sécurité (service de bac à sable — sandboxing — de systèmes de fichiers, diminution des privilèges de nos démons), en réseau (trois nouveaux types d’interfaces sont dorénavant pris en charge par networkd) et dans les unités socket (quatre nouveaux réglages).

Le changement que je trouve le plus excitant : un premier pas dans la direction d’un système sans état. Dorénavant, /var est reconstruit s’il est vide au démarrage. Ma nouvelle commande favorite faisant appel à ça est la suivante :
systemd-nspawn -D /srv/mycontainer --read-only --tmpfs=/var -b.

Elle engendre un conteneur nspawn avec une arborescence montée en lecture seule et un dossier /var volatile et vide, monté par dessus et vidé lorsque l’on arrête le conteneur. Avec ces éléments en place, on peut facilement lancer des centaines d’instances de conteneurs ad hoc jetables depuis la même arborescence, en étant sûr qu’elles se terminent sans interférer les unes avec les autres. Prochaine étape (planifiée pour la prochaine version) : ajouter l’infrastructure pour gérer également le démarrage avec /etc vide (c’est‐à‐dire, avec une racine en tmpfs et seulement un /usr monté depuis l’arborescence d’une distribution en lecture seule).

Outils en ligne de commande Unités

Les unités sockets ont gagné beaucoup d’options :

  • SocketUser= et SocketGroup= : indiquent le propriétaire et le groupe à utiliser pour les sockets AF_UNIX et les files d’attente FIFO sur le système de fichiers ;
  • RemoveOnStop= : si activé, tous les FIFO et les sockets sur le système de fichiers seront retirés quand l’unité correspondante est arrêtée ;
  • Symlinks= : prend une liste de liens symboliques à créer (sur le système de fichiers) des sockets système ou des FIFO créés par les sockets UNIX correspondants. Cette option est utile pour gérer les liens symboliques vers des fichiers sockets ayant le même cycle de vie que le socket lui‐même.

Concernant les unités de services, on gagne deux nouvelles options : ProtectedHome= et ProtectedSystem=. Elles rendent les données utilisateur (comme /home) inaccessibles ou en lecture seule, et le système (comme /usr) en lecture seule pour des services particuliers. Cela nous permet d’avoir un système de bac à sable très léger. Ces options ont été activées pour tous les services tournant pendant une longue période, quand c’est approprié.

De plus, l’effet de plusieurs paramètres pour les services a changé :

  • L’option on-abnormal a été ajoutée à Restart=. Si elle est définie, elle aura pour effet de déclencher des redémarrages automatiques pour toute raison « anormale » de fin d’un processus, ce qui inclut signaux d’erreur, vidanges mémoires, expirations de délai et expirations de délai de chien de garde (watchdog), mais exclut les codes de sortie propres ou non, ainsi que les signaux propres. Restart=on-abnormal est une alternative à Restart=on-failure pour les services qui doivent pouvoir s’arrêter et ne pas redémarrer lors de certaines erreurs en le signalant par un code de sortie d’erreur adéquat. Restart=on-failure ou Restart=on-abnormal est maintenant le réglage par défaut recommandé pour tous les services tournant pendant une longue période.

  • Si le réglage de l’option InaccessibleDirectories= pointe vers un point de montage (ou si le répertoire pointé contient lui‐même un point de montage), systemd essaiera de démonter totalement l’arborescence pour rendre les systèmes de fichiers vraiment indisponibles pour le service concerné.

  • Le réglage ReadOnlyDirectories= et le paramètre --read-only de systemd-nspawn sont dorénavant aussi appliqués de façon récursive à tous les sous‐points de montage.

Enfin, deux autres changements concernant les unités :

  • le socket /dev/log et la FIFO /dev/initctl ont été déplacés vers /run et ont été remplacés par des liens symboliques. Cette modification permet de se connecter à elles même si PrivateDevices=yes est utilisé pour un service — ce qui rend /dev/log inatteignable mais laisse /run accessible. Cette option a l’avantage de s’assurer que /dev contient uniquement des périphériques, des répertoires, des liens symboliques et rien d’autre ;

  • une nouvelle unité cible (target) a été ajoutée : network-pre.target. Elle est utile pour les services qui doivent être exécutés avant que le réseau ne soit configuré, par exemple les scripts de pare‐feu.

Réseau

systemd-networkd, systemd-resolved et systemd-bus-proxyd tournent maintenant sous leurs propres utilisateurs homonymes. Ils ne conservent que quelques capacités, mais ne peuvent cependant plus écrire dans des fichiers appartenant au super utilisateur root.

systemd-networkd gère maintenant la mise en place de périphériques Ethernet virtuels veth pour la connectivité des conteneurs, ainsi que les tunnels GRE et VTI.

Le fichier resolv.conf généré par systemd-resolved a été déplacé dans /run/systemd/resolve/. Si avez un lien symbolique depuis /etc/resolv.conf, il faudra peut‐être le corriger.

Amélioration du code

La dépendance à libattr a été éliminée. Les appels pour les attributs étendus ont depuis longtemps été déplacés dans la glibc, rendant libattr inutile.

La prise en charge des scripts init SysV et LSB a été supprimée du démon systemd lui‐même. À la place, un générateur crée des unités systemd natives lorsque nécessaire. Cela a permis de supprimer une portion non négligeable de code de compatibilité de « PID 1 », suivant ainsi les distributions, qui aujourd’hui ne livrent qu’un tout petit nombre de scripts init LSB ou SysV.

Virtualisation

Deux changements concernant la virtualisation :

  • la détection de la virtualisation fonctionne maintenant sans privilèges. systemd-detect-virt ne nécessite donc plus la capacité CAP_SYS_PTRACE et nos démons peuvent ainsi fonctionner avec moins de privilèges ;

  • les domaines privilégiés Xen (dom0) ne sont plus considérés comme de la virtualisation par la logique de détection de virtualisation. Après tout, ils ont en général un accès total au matériel et sont d’ordinaire utilisés pour gérer des domaines non privilégiés (domU).

Autres

À titre de fonctionnalité expérimentale, udev essaie désormais de verrouiller un périphérique disque lorsqu’il exécute des évènements pour ce disque ou l’une de ses partitions. Des applications telles que les programmes de partitionnement de disque peuvent verrouiller le disque et réclamer temporairement la propriété du périphérique de cette façon et udev ignorera complètement tous les évènements pour ce disque ou cette partition. Si le disque a été ouvert en écriture, la fermeture déclenchera une analyse de la table de partition. Ce comportement est dorénavant activé par défaut ; s’il s’avère qu’il cause d’importants problèmes, nous pourrions l’activer uniquement pour quelques périphériques particuliers ou le désactiver complètement. Ce comportement ne prend pas en compte les périphériques virtuels (device-mapper).

Des unités mount temporaires peuvent maintenant être créées par les interfaces de programmation (API) du bus.

Un bout de code tmpfiles pour recréer la structure la plus élémentaire de /var est maintenant disponible. Il est suffisant pour créer le lien symbolique /var/run → /run et créer une série de répertoires structurels. Ça permet au système de démarrer avec un /var vide ou volatile. Évidemment, si grâce à ce changement le système d’exploitation de base est dorénavant capable de faire face à un /var volatile, tous les services utilisateurs n’y sont pas encore prêts. Cependant, nous espérons que tôt ou tard, de nombreux démons de services seront modifiés en amont, de façon à créer automatiquement au démarrage les répertoires nécessaires dans /var, s’ils devaient manquer. Il s’agit d’un premier pas vers un système sans état qui nécessite uniquement une image de la distribution sur /usr pour démarrer.

systemd-nspawn dispose désormais d’une nouvelle option --tmpfs= pour monter une instance tmpfs vide sur un répertoire particulier. C’est particulièrement utile pour la reconstruction automatique de /var (voir ci‐dessus), en passant --tmpfs=/var.

Le groupe floppy [N. D. T. : disquette] qui possédait les périphériques /dev/fd* n’est plus utilisé. Le groupe disk est utilisé à la place. Les distributions devraient probablement déconseiller l’utilisation de ce groupe.

Version 215

Beaucoup de travail pour rendre fonctionnels la remise aux paramètres d’usine, les systèmes sans état et les mises à jour hors‐ligne. Beaucoup de travail autour de networkd (serveur DHCP 4 !), enfin coredumpctl est maintenant vraiment utile.

Outils en ligne de commande

Cette fois‐ci, deux nouvelles commandes :

  • systemctl is-system-running : permet de vérifier l’état général du système, par exemple s’il a fini de démarrer et est pleinement opérationnel ;

  • la nouvelle page man file-hierarchy(7) contient une version raccourcie et modernisée de l’organisation du système de fichiers attendue par systemd, semblable à la spécification FHS ou la page de man hier(5). Le nouvel outil systemd-path(1) a été ajouté pour afficher plusieurs de ces chemins concernant la machine locale et l’utilisateur local.

Par exemple, systemd-path retourne chez moi :

temporary: /tmp temporary-large: /var/tmp system-binaries: /usr/bin system-include: /usr/include system-library-private: /usr/lib system-library-arch: /usr/lib system-shared: /usr/share system-configuration-factory: /usr/share/factory/etc system-state-factory: /usr/share/factory/var system-configuration: /etc system-runtime: /run system-runtime-logs: /run/log system-state-private: /var/lib system-state-logs: /var/log system-state-cache: /var/cache system-state-spool: /var/spool user-binaries: /home/sinma/.local/bin user-library-private: /home/sinma/.local/lib user-library-arch: /home/sinma/.local/lib/x86_64-linux-gnu user-shared: /home/sinma/.local/share user-configuration: /home/sinma/.config user-runtime: /run/user/1000 user-state-cache: /home/sinma/.cache user: /home/sinma user-documents: /home/sinma/documents/ user-music: /home/sinma/musique/ user-pictures: /home/sinma/images/ user-videos: /home/sinma/vidéos/ user-download: /home/sinma/téléchargements/ user-public: /home/sinma/ user-templates: /home/sinma/modèles user-desktop: /home/sinma/ search-binaries: /usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/sinma/.cabal/bin search-library-private: /home/sinma/.local/lib:/usr/local/lib:/usr/lib search-library-arch: /home/sinma/.local/lib/x86_64-linux-gnu:/usr/lib search-shared: /home/sinma/.local/share:/usr/share:/usr/share:/usr/local/share search-configuration-factory: /usr/local/share/factory/etc:/usr/share/factory/etc search-state-factory: /usr/local/share/factory/var:/usr/share/factory/var search-configuration: /home/sinma/.config:/etc

Et deux mises à jour :

  • machined a été mis à jour pour exporter la version du système d’exploitation d’un conteneur (lue depuis /etc/os-release/ et /usr/lib/os-release) ; cette information est disponible via machinectl status ;

  • l’option -H de systemctl (permettant de se connecter à une machine distante exécutant systemd) a été étendue pour pouvoir se connecter à un conteneur spécifique de l’hôte. Par exemple, systemctl -H root at foobar:waldi permet de se connecter en tant que super utilisateur root de la machine foobar directement au conteneur_waldi_. Notez que, pour l’instant, il faut s’authentifier en tant que super utilisateur root pour que ça marche, puisqu’entrer dans un conteneur est une opération privilégiée.

systemd-coredump

systemd-coredump est l’outil qui gère les vidanges mémoires (core dumps), c’est‐à‐dire le contenu de la mémoire du programme avant son plantage.

Le comportement de systemd-coredump a pas mal changé : il génère dorénavant automatiquement une trace d’appel enregistrée dans le journal pour toutes les vidanges système (grâce à la bibliothèque libdw des elfutils). De plus, il enregistre maintenant les vidanges système directement sur le disque (sous /var/lib/systemd/coredump, si possible dans un format compressé), au lieu de les enregistrer dans le journal. Un nouveau fichier de configuration /etc/systemd/coredump.conf a été ajouté pour configurer les autres paramètres de systemd-coredump.

On utilise la commande coredumpctl pour consulter les informations collectées par systemd-coredump. Elle a été enrichie de deux nouvelles options : info, pour afficher les détails de la vidange système choisie, et -1, pour afficher uniquement les informations de la plus récente vidange au lieu de l’ensemble des entrées. En outre, vu que l’outil est utile de façon générale, le préfixe systemd- lui a été retiré. Les distributions qui veulent maintenir la compatibilité avec l’ancien nom devraient ajouter un lien symbolique de l’ancien nom vers le nouveau.

Pour finir, l’option SplitMode= de journald est maintenant uid par défaut. Cela signifie que les utilisateurs non privilégiés peuvent accéder à leurs propres coredumps avec coredumpctl, sans restrictions.

Unités

Trois nouveaux paramètres pour les unités services :

  1. RestartForceExitStatus= : si configuré avec une série de signaux de sortie ou de valeurs de retour de processus, le service sera relancé si le processus du démon principal se termine avec l’un d’entre eux (quelle que soit l’option Restart=) ;
  2. dans la section [Install], DefaultInstance= : pour définir l’instance par défaut à démarrer, si une unité modèle est activée sans instance spécifiée (normalement on a service@instance — par exemple, dhcpcd@[interface] ou openvpn@[nom_configuration_VPN] —, mais on peut avoir service sans @instance) ;
  3. ConditionNeedsUpdate= : démarre seulement les unités lorsque /etc ou /var sont plus « anciens » que les ressources de la distribution installée dans /usr. Elle est utile pour reconstruire ou mettre à jour /etc au redémarrage après une mise à jour hors‐ligne du répertoire /usr ou une remise aux paramètres d’usine. Les services qui veulent démarrer une seule fois après une mise à jour ou une remise à zéro devraient utiliser cette condition et se lancer eux‐même avant le nouveau systemd-update-done.service, qui marquera les deux répertoires comme totalement à jour. Un certain nombre de fichiers de services utilisant cette modification ont été ajoutés pour reconstruire la base de données matérielle de udev, le catalogue de messages de journald et le cache du chargeur de bibliothèques dynamiques (ldconfig). L’outil systemd-sysusers décrit plus haut fait déjà usage de cette nouveauté. Avec ces éléments en place, il est possible de démarrer proprement un système d’exploitation minimal avec un répertoire /etc vide. Pour plus d’informations sur le sujet, voir ce récent journal de Lennart.

Il y a aussi une nouvelle option pour les unités .mount, SloppyOptions=. Si elle est activée, cette dernière utilise l’option -s de mount(8) (traitement permissif des options de montage inconnues).

De plus, la nouvelle cible cryptsetup-pre.target peut être utilisée par les services qui doivent s’exécuter et se terminer avant que le premier conteneur chiffré LUKS ne soit configuré.

Réseau

Trois changements concernant systemd-network :

  1. prise en charge d’un serveur DHCPv4 minimal (en plus de l’actuel client DHCPv4), des clients DHCPv6 et des sollicitations client de routeur IPv6. Le client DHCPv4 gère désormais les routes statiques données par le serveur. Notez que la section [DHCPv4] des anciennes versions de systemd-networkd a été renommée en [DHCP] et qu’elle est également utilisée par le client DHCPv6. Les fichiers .network utilisant les paramètres de cette section devraient être mis à jour, bien que la compatibilité soit maintenue. En option, le nom d’hôte du client peut maintenant être envoyé au serveur DHCP ;
  2. gestion des réseaux virtuels VXLAN, ainsi que TUN/TAP et les périphériques factices ;
  3. allocation automatique de plages d’adresses pour les interfaces en utilisant groupe de d’adresses (pool) pour tout le système. C’est utile pour la gestion dynamique de nombreuses interfaces depuis un fichier de configuration pour un seul réseau, en particulier pour assigner des adresses IP correctes aux liens veth de nombreuses instances de nspawn.

Enfin, les noms d’interfaces réseau prédictibles de udev font désormais usage de l’attribut dev_port de sysfs, introduit dans Linux 3.15, à la place de dev_id : cela permet de distinguer les ports des mêmes fonctions PCI. dev_id devrait être utilisé uniquement pour les ports utilisant la même adresse matérielle, d’où la nécessité de dev_port.

Remise du système aux paramètres d’usine

Le nouvel outil systemd-sysusers est capable de créer les utilisateurs et groupes du système dans /etc/passwd et /etc/group en se basant sur les définitions des utilisateurs et groupes déclarés statiquement dans /usr/lib/sysusers.d/. C’est utile pour réinitialiser un système aux paramètres d’usine et pour les systèmes volatiles qui démarrent avec un répertoire /etc vide, et qui nécessitent les utilisateurs et groupes du système tôt dans le processus de démarrage. systemd fournit deux fichiers dans sysusers.d/ par défaut pour les utilisateurs et groupes indispensables à systemd et au cœur du système d’exploitation.

Un nouveau bout de code tmpfiles a été ajouté pour reconstruire les fichiers essentiels dans /etc au démarrage, s’ils sont manquants.

Une directive pour s’assurer du nettoyage automatique de /var/cache/man/ a été supprimée de la configuration par défaut. Cette instruction devrait dorénavant être fournie par l’implémentation de man. Les modifications nécessaires ont été apportées à l’implémentation de man‐db. Notez que vous devez mettre à jour votre implémentation de man vers une version qui fournit cette instruction, sans quoi le nettoyage automatique de /var/cache/man n’aura pas lieu.

Le fichier /etc/os-release doit maintenant être déplacé vers /usr/lib/os-release (un lien symbolique de l’ancien chemin au nouveau est automatiquement créé). /usr/lib est plus approprié pour accueillir ce fichier car il décrit le système fourni dans /usr, et pas la configuration stockée dans /etc.

tmpfiles gère désormais une nouvelle directive L+ qui crée un lien symbolique, mais, contrairement à L, elle efface d’abord le fichier pré‐existant, le cas échéant, ou si le lien symbolique ne pointait pas au bon endroit. De façon similaire, des directives b+, c+ et p+ ont été ajoutées, pour créer des périphériques blocs, caractères, ainsi que des files d’attente FIFO dans le système de fichiers, supprimant éventuellement n’importe quel fichier de type différent.

Pour les directives L, L+, C et C+ des tmpfiles, le dernier champ argument, utilisé jusque‐là pour spécifier la source du lien symbolique ou de la copie, est maintenant optionnel. S’il est omis, le même fichier est copié depuis /usr/share/factory/ et suffixé du chemin de destination. C’est utile pour peupler le répertoire /etc de fichiers essentiels, en les copiant depuis les réglages de la distribution fournis dans /usr/share/factory/etc.

Une nouvelle commande systemctl preset-all permet de remettre les paramètres de toutes les unités de service à leurs valeurs par défaut. Une nouvelle option --preset-mode= a de même été ajoutée pour contrôler si seules les opérations activées ou désactivées doivent être exécutées.

Lorsque le système démarre avec un répertoire /etc vide, l’équivalent de systemctl preset-all est exécuté tôt au démarrage pour s’assurer que tous les services par défaut sont activés après une réinitialisation aux paramètres d’usine.

Sécurité

systemd-nspawn filtrera dorénavant par défaut une série d’appels système pour les conteneurs, parmi lesquels, ceux requis pour charger les modules noyau, les accès directs aux ports d’entrée‐sortie x86, le contrôle du fichier d’échange (swap) et kexec. Mais surtout, open_by_handle_at() est dorénavant interdit aux conteneurs, fermant ainsi une faille similaire à celle de Docker récemment débattue, à propos de l’accès aux fichiers sur les arborescences auxquelles les conteneurs ne devraient pas avoir accès. Notez que nous ne garantissons par la sécurité de nspawn (ceci est explicitement documenté dans le manuel). Il s’agit donc juste de la solution à l’un des problèmes les plus évidents.

Autres

Le groupe input a été ajouté et tous les nœuds de périphériques d’entrée sont assignés à ce groupe. C’est utile pour les logiciels système qui veulent avoir accès aux périphériques d’entrée. Cela complète ce qui a déjà été fait pour les groupes audio et video.

Les nœuds de périphériques /dev/loop-control et /dev/btrfs-control appartiennent désormais au groupe disk par défaut.

De nouvelles options pour la ligne de commande du noyau ont été ajoutées : systemd.wants= (pour ajouter des unités additionnelles pendant le démarrage), systemd.mask= (pour masquer des unités particulières au démarrage) et systemd.debug-shell (pour activer le shell de débogage sur tty9).

Le nettoyage périodique automatique de $XDG_RUNTIME_DIR n’est plus fait, car c’est devenu inutile. En effet, le dossier a maintenant une limite de taille par utilisateur et est nettoyé à la déconnexion.

Télécharger ce contenu au format Epub

Lire les commentaires

Beyond Linux From Scratch (BLFS) 7.6 en français

4 octobre, 2014 - 15:25

myou a publié un journal pour annoncer la sortie de Beyond Linux From Scratch (BLFS, Au-delà de Linux From Scratch) 7.6 le 23 septembre dernier et pour faire son retour d'expérience sur la traduction du projet :

Comme je [myou] l'annonçais dans la dépêche de sortie de LFS 7.6, je viens vous annoncer la sortie de BLFS 7.6 en français. Cette version est sortie en anglais en même temps que LFS 7.6, mais la finalisation de la traduction m'a occupé pendant quelques jours ;o).

Il est donc possible de lire BLFS 7.6 en français.

On retrouve dans cette version l'ensemble des paquets habituels tous testés avec LFS 7.6.

NdM : dans la seconde partie de la dépêche, il revient sur pourquoi traduire un pavé de 1500 pages, pourquoi ce n'est pas inutile et pourquoi vous pourriez participer.

Mais pourquoi traduire ce pavé de 1500 pages ?

J'ai commencé à aider sur la traduction de BLFS il y a déjà 3 ans. Pour moi, il s'agissait de contribuer au libre pour donner un peu de la grosse part que je prenais. Il est vrai que j'aurais pu contribuer à un gros projet, et je l'ai fait d'ailleurs puisque j'ai commencé en contribuant à la traduction de debian qui était ma distribution de l'époque. Mais je me suis senti plus à l'aise dans la petite équipe LFS.

Le but à l'époque était de rattraper le retard afin de pouvoir avoir une version de BLFS qui soit synchronisée avec la version anglaise qui était quasiment pas maintenue à l'époque.

Et puis la version anglaise est redevenue active, je me suis alors pris au jeu de maintenir la version française synchronisée et à jour.

J'ai ensuite développé des outils (des scripts) pour nous aider dans les mises à jour.

Si, à la base, je me suis pris au jeu, je me suis également vite aperçu que cela m'apportait beaucoup de réaliser cette traduction.

veille technologique

En effet, en assurant la traduction au jour le jour, et comme BLFS est maintenant un livre très à jour par rapport aux versions des paquets, je suis informé des améliorations dans les principaux paquets assez rapidement.

une connaissance du système

Traduire, c'est lire avec l'obligation de comprendre pour retranscrire le mieux possible dans une autre langue. Traduire BLFS m'a permis d'améliorer fortement mes connaissances sur les principaux paquets, que ce soit sur leurs fonctions, ou sur la façon dont ils s'articulent entre eux (par les dépendances). De plus en traduisant BLFS, je suis amené à intervenir sur le canal IRC français afin d'aider ceux qui rencontrent des problèmes dans leur construction. Et le meilleur moyen de maîtriser un sujet est de devoir l'expliquer ou de résoudre les problèmes rencontrés par les autres.

J'ai également construit de nombreuses fois LFS… et des paquets BLFS. Mais comme le disait appzer0 dans son billet sur 0linux, l'importance d'avoir une méthode de gestion des paquets est primordiale.

LFS/BLFS propose des pistes, mais ne donne pas une méthode pour la gestion des paquets. J'ai choisi de gérer mon système en utilisant la méthode des utilisateurs-paquets. Mais les scripts donnés avec l'astuce n'étaient pas de mon point de vue suffisants, j'ai donc apporté des modifications afin de pouvoir gérer mon système selon mes règles.

Une fois ce travail effectué, j'ai pu construire mon système et il est devenu mon OS principal depuis 4 mois maintenant.

Mais c'est inutile !

Je sais que pour la majorité d'entre vous, la première remarque qui viendra sera, c'est inutile, il existe beaucoup de distributions pour ne pas avoir à faire le boulot soit même. Oui je suis d'accord avec eux. Mais il existe beaucoup de constructeurs de voitures, pourtant on trouve des personnes qui construisent dans leur garage leur propre voiture en y passant des centaines d'heures… Pour moi c'est exactement la même chose, et construire son système ne doit pas être vu en comptant le temps passé à la construction…
Par exemple, sur ma construction, je connais l'utilisation de chaque paquet. J'ai un système avec une installation minimale (comprendre dans le sens ou j'ai installé seulement ce que j'utilise !!), mais cela ne m'empêche pas d'avoir un interface graphique (openbox avec cairo-dock).
J'aurais pu avoir la même interface en faisant des apt-get dans une Debian… mais même si le résultat avait été le même, je n'aurais pas pu avoir une connaissance de mon système aussi approfondie.

Pourquoi pas vous ?

J'ai évoqué mon histoire dans le projet BLFS, mes expériences en construisant mon propre système (qui est une parenthèse par rapport à la traduction)… et pourquoi pas vous ?
Le projet de traduction accueillera volontiers ceux qui veulent aider en faisant de la traduction, de la relecture, de l'aide à la mise en place d'outils pour aider la traduction… ou pour échanger sur vos projets liés à LFS/BLFS.

Pour nous rejoindre, il y a la liste de diffusion (lfs-traducfr@lists.linuxfromscratch.org , inscription requise pour y écrire) , ou IRC (canal #lfs-fr sur freenode.org).

Télécharger ce contenu au format Epub

Lire les commentaires

Piwigo 2.7 : un chez-soi pour vos photos

4 octobre, 2014 - 12:50

Piwigo est un logiciel libre de galeries photos pour le web. La version 2.7 est sortie il y a quelques jours. Parmi les nouveautés, un nouvel uploader (téléverseur (?) en HTML5, qui remplace l'ancien en flash), une visite guidée interactive pour les débutants, un champ recherche amélioré et tout un tas de petites améliorations.

Pour éviter de répéter ici ce que l'annonce de la sortie de la version 2.7 dit déjà mieux que moi, voici une dépêche d'un point de vue subjectif assumé : j'ai moi-même franchi le pas, il y a quelques semaines, après avoir comparé Piwigo et d'autres. Voici ce que je retiens de mes premières expériences avec Piwigo et des nouveautés de la nouvelle version.

Sommaire Un logiciel communautaire et un hébergement commercial

Avant de rentrer dans les détails techniques, Piwigo un logiciel libre, gratuit et facilement auto-hébergeable (écrit en PHP). En parallèle avec l'association Piwigo, une entité commerciale Pigolabs propose un hébergement (piwigo.com) et des services autour du logiciel Piwigo.

La communauté et l'entité commerciale sont toutes les deux dans l'esprit du logiciel libre (liberté du logiciel, mais aussi conserver le contrôle de l'utilisateur sur ses données).

Si on opte pour le service d'hébergement piwigo.com, il est payant, mais sans pub et sans revente d'informations personnelles à des tiers. Clairement pas dans la même catégorie que les géants américains du domaine…

Piwigo : l'outil de galeries photos paramétrable à souhait

Ce qui distingue Piwigo d'autres solutions libres d'hébergement de photos, c'est sans doute le degré de personnalisation de l'outil.

On est à l'opposé de la philosophie des solutions de partages de photos orientés « réseaux sociaux » comme Flickr ou Google+ : en visitant deux galeries Piwigo différentes, on n'a pas du tout l'impression de voir la même chose (alors que par construction, un album Google+ ressemble à tous les autres).

Thèmes et greffons

Comme pas mal d'autres outils, Piwigo a un système de thèmes qui permet de changer l'apparence de l'ensemble de la galerie en quelque clics. 53 thèmes disponibles en version 2.6, pas encore tous portés pour la 2.7 : c'est largement assez pour faire en sorte que votre galerie photos ne ressemble pas aux autres.

Le système de greffon permet à la fois d'ajouter des fonctionnalités (comme permettre aux visiteurs d'ajouter des photos, de télécharger tout un album en une fois ou de faire leurs propres sélections de photos), mais aussi de modifier l'apparence de certaines parties de la galerie. Par exemple, je trouve l'affichage des miniatures de la plupart des thèmes assez old school, mais avec un greffon comme gThumb+ ou gdThumb, on arrive à une apparence beaucoup plus « moderne ».

Cette diversité a un prix : une fois un thème choisi, le fait qu'il en existe 52 autres n'est plus si important. Par contre, certaines fonctionnalités sont développées spécifiquement pour un thème et on se trouve parfois contraint de faire un choix sur l'apparence de la galerie pour bénéficier d'une fonctionnalité. Par exemple, le thème Modus propose une fonctionnalité similaire à celle du greffon gThumb, mais supérieure en certains points. Si vous voulez cet fonctionnalité, vous devrez vous faire à l'apparence générale de Modus.

Le fait qu'on ait une cinquantaine de thèmes et une centaine de greffons implique aussi que les couples (thème, greffons) ne peuvent pas tous être testés (50 * 100 = 5000 combinaisons…) et, sans grande surprise, il y a beaucoup de bugs liés à la compatibilité d'un thème avec un greffon. En deux mois d'utilisation, j'ai rapporté 11 bugs ; 6 sont des problèmes de compatibilité thème/greffon.

LocalFiles editor : retoucher la CSS du site

Quand un thème s'approche du résultat souhaité sans l'atteindre, il est assez facile d'ajouter quelques règles CSS pour retoucher la mise en forme.

Le greffon LocalFiles editor permet de faire ça en ligne, à travers l'interface web. On peut donc faire ces modifications même sans avoir d'accès type ftp pour éditer les fichiers sur le serveur et, bien sûr, on édite un fichier CSS séparé du reste de l'outil, qui sera conservé lors des mises à jour. En particulier, ce greffon est disponible sur l'hébergement piwigo.com. Je ne connais pas d'autre hébergeur qui propose ce genre de configuration.

Avec les greffons appropriés (PWG Stuffs, Add < head > element), on peut injecter des morceaux de HTML ou de JavaScript un peu partout dans les pages, toujours sans toucher au code de Piwigo bien sûr.

Les templates

Je n'ai pas testé, mais le moteur de génération de HTML de Piwigo est basé sur un système de templates, et l'utilisateur peut remplacer tout ou partie des templates fournis par les siens. Cette possibilité n'est pas offerte sur piwigo.com par contre.

Avec tout ça, Piwigo commence à ressembler à un gestionnaire de contenus comme SPIP ou Wordpress : le logiciel s'occupe de la base de données qu'il y a derrière et donne le cadre. Le webmestre peut en faire ce qu'il veut.

Des exemples !

Juste pour vous donner une idée du genre de choses qu'on peut faire, voici quelques exemples de galeries (style dépouillé ou chargé !) :

D'autres sont disponibles dans l'annuaire.

Bien sûr, un inconvénient du système de thèmes est aussi qu'il faut décider lequel est le plus beau, et comme chacun sait, des goûts et des couleurs, on ne discute pas ;-).

API de programmation externe

Piwigo propose aussi une API accessible à distance (pour plus de détails). C'est ce qui permet un écosystème assez riche en dehors de Piwigo, comme le client lourd pLoader ou le greffon KIPI qui permet d'uploader des images depuis Digikam, Gwenview, Kphotoalbum ou KSquirrel.

Autre exemple : intégrer une image aléatoire dans une page d'un autre site web se fait en quelques lignes de PHP.

Et les nouveautés de la 2.7 ?

La grande nouveauté technique de la 2.7, c'est le nouvel uploader. En 2.6, on avait le choix entre un upload HTML traditionnel, qui ne marche que pour un fichier à la fois, ou un uploader en flash, qui permettait de sélectionner plusieurs fichiers d'un coup (en plus, bien sûr de la possibilité d'envoyer les photos via ftp ou autre, sans passer par l'interface web). Piwigo a maintenant une solution basée sur HTML5, à la fois plus pratique que l'ancien (on peut envoyer les photos par glisser-déposer) et sans utiliser Flash.

Une autre nouveauté (qui arrive un peu tard pour moi ;-) ), c'est le greffon « take a tour », qui propose une visite guidée de l'interface pour les débutants. C'est assez bien fait, c'est vraiment un bon point de départ pour faire le tour des fonctionnalités de l'outil.

Le champ « recherche » a aussi été largement amélioré et il y a tout un tas de petites améliorations sur l'ergonomie générale : un lien direct « vider le panier » (je l'ai cherché en vain dans la 2.6, mais le voilà !), plus de filtres pour la gestion par lots, un champ recherche pour filtrer la liste des greffons… et beaucoup d'améliorations dans l'architecture interne et l'API pour les greffons.

Pour les détails, les notes de versions de Piwigo 2.7 vous raconteront tout ça en détails et en images !

Alors, Piwigo ou un autre ?

Au final, la flexibilité de Piwigo compense assez bien les défauts que je lui trouve. Esthétiquement, je n'ai pas trouvé de thème Piwigo que je trouve aussi joli que le rendu d'outils comme Lychee ou qui occupe aussi bien l'espace de l'écran que celui de PhotoShow. Mais dans les deux cas, ce sont des outils conçus pour un besoin en particulier (en général développés par une seule personne) et c'est difficile de leur faire faire autre chose que ce pour quoi ils ont été conçus. Bref, si ces outils vous conviennent, ils seront peut-être meilleurs que Piwigo pour votre utilisation et plus dans la philosophie « let one tool do one thing, and do it well », mais si vous cherchez la flexibilité alors Piwigo est probablement un meilleur candidat.

Dans la catégorie « outil libre, flexible, avec une communauté active », il n'y a pas beaucoup d'alternatives. Gallery 3 qui était une référence à une époque est abandonné par ses développeurs. Il reste Zenphoto, assez proche de Piwigo sur beaucoup de points mais pas forcément aussi complet. On peut aussi citer OwnCloud, qui propose un outil de galeries photos simple mais efficace.

Télécharger ce contenu au format Epub

Lire les commentaires

GNOME 3.14 rebat les cartes

2 octobre, 2014 - 11:32

Comme tous les six mois, l’environnement de bureau libre GNOME dévoile sa nouvelle version. S’il n’y a pas de changement révolutionnaire depuis la précédente mouture, nous verrons qu’il s’agit pourtant d’une étape particulièrement importante, dont les enjeux dépassent de loin le cadre du seul projet GNOME.

Sommaire

Note : Cette dépêche est agrémentée de liens pointant essentiellement vers des wikis, blogs, gestionnaires de bogues, sources de logiciels… Ces ressources sont dans une vaste majorité en anglais.

L’ergonomie

Comme pour la version 3.12, GNOME 3.14 n’apporte guère d’évolution notable sur le plan de l’ergonomie. Elle marque plutôt une stabilisation globale de GNOME 3, comme en témoigne la publication du guide des recommandations pour la réalisation des interfaces graphiques. Les développeurs et ergonomes disposent désormais de directives claires pour intégrer leurs applications à l’environnement de bureau. Pour l’anecdote, on a cru un moment que le raccourci clavier préconisé pour basculer d’un onglet à un autre serait aligné sur le choix de Firefox et Chromium, mais il n’en est rien.

Du côté du Shell, de nouvelles animations sont apparues, destinées à donner une impression de fluidité. Oui, il s’agit bien d’agir sur la perception de l’utilisateur, sans agir sur les performances réelles du logiciel… Plus anecdotique, il est désormais possible de consulter les informations à propos d’une application (auteurs, licence, adresse du site Web du logiciel…), directement depuis la grille de lancement d’applications. Pour en finir avec le Shell, les possesseurs d’écrans tactiles multipoints peuvent désormais le manipuler avec plusieurs doigts.

La confidentialité est l'un des aspects sur lesquels le projet GNOME met l'accent. Souvenez-vous de la levée de fonds de 2012 pour financer les développements allant dans ce sens. Dans cette logique, différentes fonctionnalités de partage (WebDAV, DLNA et VNC) peuvent maintenant être (dés)activées réseau par réseau.

Les applications

Les développeurs d’Evince ont terminé un long effort pour l’accessibilité de leur visionneuse de documents, rendant les formulaires, liens et autres images exploitables à travers les technologies d’assistance. L’interface d’Evince a de plus évolué pour se conformer aux standards définis depuis GNOME 3.10 : la barre d’en‐tête est enfin de la partie !
Elle prend désormais en charge les écrans à haute densité de pixels.
Lorsque lancé sans ouvrir de documents, Evince affiche la liste des documents récents.

Les jeux Sudoku et Mines ont eux aussi été modernisés, et utilisent maintenant les feuilles de style. Les gens en soif de casse‐têtes pourront aussi profiter du nouveau Hitori, avec tout plein de chiffres dedans.

Plusieurs logiciels se voient ajouter des fonctionnalités essentielles. Cartes devient vraiment intéressant car il permet désormais le calcul d’itinéraires. Le gestionnaire de machines virtuelles, quant à lui, propose maintenant une gestion des instantanés. Ouf !

De nouvelles sources de contenu distantes ont été intégrées à plusieurs applications. Musique, à l’instar de Vidéos ou Documents, peut présenter des œuvres accédées en ligne ; Magnatune et Jamendo sont pris en charge. Photo, de son côté, se voit ajouter la capacité de communiquer avec les serveurs de Google pour consulter les photos de Google+ ou Picasa.

La plomberie

Malgré l’absence de grande nouveauté pour les utilisateurs, cette dernière mouture pourrait bien être la plus importante depuis plusieurs années.

Lorsque l’on lançait une application GTK+ en dehors de GNOME 3, on avait l’habitude de tomber sur une fenêtre au style vieillot qui n’était pas sans rappeler Windows 95. Eh bien sachez que c’est (bientôt) fini, car l’ancien thème par défaut de GTK+, dénommé Raleigh, laisse sa place à Adwaita, le thème qui avait été créé pour GNOME 3. Ce dernier a été totalement réécrit pour l’occasion, et son intégration à GTK+ permettra à toutes les applications qui s’appuient sur cette bibliothèque graphique d’exploiter pleinement ses dernières fonctionnalités en dehors de GNOME.

Le projet GTK+ est tout particulièrement actif puisque des fonctionnalités majeures lui ont été ajoutées, comme la prise en compte des gestes et autres écrans multi‐tactiles (multi‐touch), fonctionnalités, vous l’aurez compris, déjà exploitées par le Shell. Ça promet de belles traces sur les écrans, mais ouvre surtout des perspectives que certains ne manqueront pas d’exploiter.

Pour ne rien gâcher, les développeurs ont maintenant à leur disposition un outil de débogage interactif. Nommé GtkInspector, il se base en fait sur GtkParasite.

Paradoxalement, un des points rendant cette mouture 3.14 si importante passe quasiment inaperçu dans les notes de version : l’application Logiciels, apparue il y a deux cycles, ne concernait qu’assez peu de monde puisque seule la distribution Fedora était supportée. Le travail de Richard Hugues sur PackageKit et AppData — on appréciera l’effort sur les aspects juridiques — permettra aux utilisateurs de Debian, ArchLinux et autres Ubuntu de profiter de ce sublime gestionnaire de logiciels.

Il y a eu aussi beaucoup de progrès pour la prise en charge de Wayland. Le bureau ainsi que la plupart des applications de GNOME tournent nativement sous Wayland. Il manque cependant encore certaines choses pour remplacer complètement X.Org, notamment pour l’accessibilité.

Les distributions

Il devrait être plus aisé de trouver cette nouvelle version du bureau GNOME que la précédente

En effet, l’allongement exceptionnel du dernier cycle de développement de Fedora avait conduit à une situation où GNOME 3.12 n’était disponible qu’à travers des dépôts additionnels pour Fedora 20. Heureusement, 3.14 sera bien le bureau par défaut de Fedora 21, attendue pour début décembre.

Il sera aussi très probablement, le bureau par défaut de Debian 8 Jessie. Son intégration dans Debian est en tout cas bien avancée, et sa progression semble bien plus rapide que pour les précédentes versions. En revanche, pas de GNOME 3.14 pour Ubuntu GNOME 14.10, à moins, bien‐sûr, d’utiliser comme à l’accoutumée le PPA gnome3-staging.

Du côté des « rolling releases », Gentoo Linux, Sabayon, on devrait retrouver rapidement cette nouvelle version. Mais aussi du côté des utilisateurs de Funtoo qui ont de nouveau la possibilité d’utiliser une version récente de GNOME sans systemd. C’est déjà dispo chez ArchLinux.

Enfin, une image ISO destinée à être installée sur un support USB permet de tester GNOME 3.14.

Et après ?

Le cycle de développement de la version 3.14 a été l’occasion d’amorcer une refonte du système de notifications. Comme le présente Allan Day sur son blog, l’actuel système de notification pose quelques problèmes, aussi bien aux développeurs qu’aux utilisateurs. Il était donc nécessaire de le revoir. De multiples designs ont été tentés, notamment par Allan Day, mais au moins six mois supplémentaires ont été accordés pour travailler sur la question.

La rencontre des développeurs de GTK+ à Berlin a donné naissance à une feuille de route, avec notamment pour objectifs le remplacement de Clutter par GSK, ou encore le nettoyage du code pour préparer la sortie de GTK+ 4.

Enfin, le dernier GUADEC GUADEC de juillet dernier a donné naissance à un nouveau groupe de travail sur la confidentialité et la sûreté. Les sujets traités par ce groupe vont du confinement d’applications à l’effacement des métadonnées sur les fichiers partagés, en passant par le chiffrement des échanges entre les applications GNOME et les bases de données en ligne (les données échangées par les Météo et autres Cartes circulent en clair sur le réseau)… Bref, autant d’axes de réflexion sur lesquels chacun est invité à participer.

Télécharger ce contenu au format Epub

Lire les commentaires

Campagne de sociofinancement de la clé FACIL

2 octobre, 2014 - 07:54

Le 20 septembre dernier, à l'occasion de la Journée internationale du logiciel libre (JILL), FACIL, une association québécoise de défense et de promotion du libre, lançait la campagne de sociofinancement de la clé FACIL (FACIL pour l'Appropriation Collective de l'Informatique Libre, c'est simple, non ?). La clé FACIL est une clé USB de 16 Go capable de démarrer une sélection de systèmes d'exploitation libres sur un large éventail d'appareils numériques.

Nous avons déjà un prototype développé avec l'excellent logiciel libre MultiSystem. (Grâce au projet clé FACIL, MultiSystem a été mis à jour pour permettre le démarrage de systèmes libres sur les ordinateurs UEFI.) La prochaine étape dans notre projet est de produire 250 exemplaires. Voilà essentiellement pourquoi nous avons besoin de ramasser de l'argent.

Nous invitons tous les libristes de l'univers et leurs amis à participer au financement de la clé FACIL !

Télécharger ce contenu au format Epub

Lire les commentaires

Jeudi du libre du 2 octobre 2014 à Lyon

2 octobre, 2014 - 07:49

C'est la rentrée pour l'ALDIL, le GULL Lyonnais, et le premier jeudi du libre aura pour thème Infrastructure d’Internet : reprenons le pouvoir !

Les fournisseurs de contenus et vos fournisseurs d’accès à Internet se rapprochent de plus en plus les uns des autres pour élaborer de nouvelles alliances (complicités) pour optimiser leurs modèles économiques en essayant de différencier les contenus circulant via Internet pour élaborer des facturations à géométrie variable. Ainsi nous allons vers un un Internet à deux vitesses, où ce sont des impératifs commerciaux qui décident de la « priorité » d’une information sur une autre. Ainsi votre fournisseurs d'accès pourrait décréter que pour accéder à Wikipédia confortablement (entendez normalement par rapport à aujourd'hui, ou sans restriction demain), il faudrait rajouter mensuellement quelques euros ou acheter un forfait pour un bouquet "hors forfait Internet de base".

Nos usages d’Internet (partage, information, communication) sont en train devenir un luxe. Avons-nous envie de cela ? N’est-il pas temps de reprendre la main sur notre infrastructure ? C’est dans cet esprit qu’agissent les FAI associatifs.

Les intervenants

La conférence sera animée par les représentants d'Illyse, Fournisseur d'Accès Internet (FAI) indépendant et local, membre de la Fédération FDN. Elle sera aussi l'occasion de présenter son activité et les enjeux de cette dernière..

Regroupés au sein de la Fédération FDN, les FAI associatifs sont une alternative aux gros opérateurs classiques.

Le lieu

La conférence se déroulera à la Maison Pour Tous / Salle des Rancy, au 249 rue Vendôme - 69003 LYON (Métro Saxe Gambetta), et débutera à 19h30.

Télécharger ce contenu au format Epub

Lire les commentaires

Ruby dans le terminal le 7 octobre 2014 à Saint-Étienne

2 octobre, 2014 - 04:46

Alolise est un groupe d'utilisateurs de logiciels libres (GUL) de la Loire basé à St-Étienne.

Nous commençons à partir du 07 octobre en soirée, une série d'ateliers, hebdomadaires ou bi-mensuels selon l'affluence, consacrés à Ruby.

Parce que nous sommes en 2014, beaucoup voient le code comme le moyen d'avoir des jeux multijoueurs, des webapp consommant de multiples API, administrées sur des architectures distribuées de micro service… bla bla bla…

Oui… Oui… Mais et le plaisir d'écrire dans tout ça ? À travers les ateliers Terminal Ruby, nous vous proposons de nous attarder sur le plaisir d'écrire, la découverte d'un langage, ses subtilités ou ses multiples variations de tests de réponses autour d'un besoin donné.

Un coding dojo donc ! Avec pour seule ambition de faire tout de suite et sans objectif de but, des choses qui s'affichent dans le terminal, scripts, jeux en ascii… Un atelier fait pour ceux qui veulent coder tout de suite et surtout écrire, réécrire, débattre et comparer.

Ruby terminal ou le cercle des codeurs disparus : à l'écran en octobre 2014.

Bon ! Après le blabla, la technique: Ruby 2.0.0, Ncurses, Vim et … C'est tout !

Au programme:

  • Script
  • Fonction
  • Refactoring
  • Objet
  • Test
  • Refactoring
  • Design pattern
  • Refactoring
  • Architecture de programme (au fait vous ai-je déjà parlé de réfactoring…)
  • Ncurses
  • Programmation fonctionnelle
  • … Refactoring ! :)

Bien évidemment, ça dépendra des gens, du niveau et les thématiques seront selon les préférences du groupe.

La seule condition étant le 100% pratique où chacun est amené à parler, montrer et commenter ce qu'il écrit.

Les observateurs passifs ne sont donc pas les bienvenus :) et les personnes curieuses bien aimées !

Le but sera, avant tout de se faire plaisir en écrivant, de maîtriser le langage et la recherche du bôôôôôô code.
Le pourquoi du code après. Avis aux amateurs…

Au local d'alolise à Saint-Etienne, à partir du 07 octobre 2014. Plus d'infos sur notre site : alolise Télécharger ce contenu au format Epub

Lire les commentaires

Libday : journée de conférences sur le Libre pour les professionnels le 22 octobre 2014 à Marseille

2 octobre, 2014 - 00:23

Dans la dynamique des French Tech Weeks, la Commission Logiciel Libre Libertis organise le 22 octobre 2014 à Marseille, le Libday, une journée de conférences sur le Libre pour les professionnels.

Sont attendus à la fois les associations historiques du Libre (Aful, April), les entreprises du secteur (dont Smile, partenaire principal de l'évènement, mais aussi : Avencall, Atreal, Evolix, Linagora, Itika, Phidias, France Labs) et leurs clients publics et privés (Allopneus, Cybercartes, etc.).

Prenez connaissance du programme de la journée. Le Libday se tiendra à l'EMD Marseille Saint Charles, Rue Jules Ferry à Marseille. L'entrée est payante et soumise à une inscription. Un code promotionnel est cependant disponible pour les 50 premiers inscrits en provenance de LinuxFr.org : VY7H4W.

Télécharger ce contenu au format Epub

Lire les commentaires

systemd pour les administrateurs, parties 3, 4 et 5

1 octobre, 2014 - 09:39

On vous parle depuis longtemps de systemd. On vous dit que c’est très bien. De nombreuses distributions l’ont adopté (dont Fedora, openSUSE, Mageia, Frugalware et ArchLinux), vont l’adopter (Debian, Ubuntu) ou vous permettent de l’utiliser de manière optionnelle (Gentoo par exemple). Mais savez‐vous l’utiliser ?

Voici la suite d'une série d’articles didactiques pour apprendre à utiliser systemd et vous permettre de mieux l’appréhender et de comprendre les avantages qu’il apporte par rapport aux systèmes précédents.

Les informations ci‐dessous sont tirées, traduites et adaptées du blog de Lennart Poettering et sont accessibles dans la langue de Shakespeare aux adresses ci‐dessous :

Sommaire Partie 3: Convertir un script d'init SysV en fichier de service systemd ?

Traditionnellement, les services Unix et Linux (les démons) sont démarrés par des scripts d'init SysV. Il s'agit de scripts pour le shell Bourne qui résident généralement dans un répertoire tel que /etc/rc.d/init.d/ et qui, lorsqu'ils sont appelés avec un des quelques arguments standards (verbes) tels que start, stop ou restart, respectivement démarrent, arrêtent ou relancent le service en question. Pour le démarrage, cela implique généralement d'invoquer le binaire du démon qui forke un processus en tâche de fond (plus précisément, qui devient un démon). Les scripts shell ont tendance à être lents, assez lourds à lire, très verbeux et fragiles. Bien qu'ils soient immensément flexibles (après tout, ce n'est jamais que du code), certaines choses sont difficiles à réaliser avec des scripts shell, comme mettre en ordre une exécution en parallèle, superviser correctement des processus ou encore simplement configurer les contextes d'exécution dans leurs moindres détails.

Systemd fournit des éléments de compatibilité avec ces scripts shell mais, en raison des points négatifs invoqués précédemment, il est recommandé d'installer des fichiers de service systemd pour l'ensemble des démons installés.

De plus, en contraste avec les scripts d'init SysV qui ont besoin d'être adaptés à la distribution, les fichiers de service systemd sont compatibles avec n'importe quelle distribution exécutant systemd (ce qui arrive de plus en plus fréquemment ces derniers temps…).

Dans ce qui suit, vous trouverez un guide succinct sur comment convertir un script d'init SysV en un fichier de service natif systemd. Dans l'idéal, les projets en amont devraient distribuer et installer des fichiers de service dans leur archives tar. Si vous avez converti avec succès un script SysV en suivant les recommandations, il serait de bon ton de soumettre un patch au projet amont. La préparation d'un tel patch sera discutée lors d'une prochaine session et il suffit de vous informer que la page de manuel de daemon(7), distribuée avec systemd contient de nombreuses informations utiles sur ce sujet.

Plongeons-nous dedans

À titre d’exemple, nous allons convertir le script d'init du démon ABRT en fichier de service systemd. ABRT est un composant standard de toute installation de Fedora et il s'agit d'un acronyme pour Automatic Bug Reporting Tool, ce qui décrit bien mieux ce dont il s'agit, à savoir, un service pour collecter les dumps de crash. Le fichier de script SysV est disponible ici.

La première étape à suivre pour convertir un tel script consiste simplement à le lire (!) et à récupérer l'information essentielle distillée tout au long de ce script volumineux. Dans la majorité des cas, le script est formé d'un ensemble de code qui est assez similaire dans tous les scripts d'init et il est généralement copié-collé d'un script à l'autre. Extrayons maintenant l'information essentielle du script ci-dessus:

  • Une chaîne de caractère qui décrit le service: "Daemon to detect crashing apps". Les commentaires de l'en-tête du script présentent plusieurs chaînes de description, certaines décrivant davantage le script d'init réalisant le démarrage du service que le service en lui-même. Les services systemd ont également besoin d'une description et ils devraient décrire le service et non le fichier de service.
  • L'en-tête LSB1 contient les informations de dépendance. Grâce à son architecture basée sur l'activation par socket, systemd n'a généralement pas besoin (ou un tout petit peu) de définir manuellement les dépendances. (Pour plus d'informations sur l’activation par socket lisez l'article originel du blog.) Dans ce cas, la dépendance vis-à-vis de $syslog (qui indique que arbtd a besoin d'un démon syslog) est la seule information d'intérêt. Même si l'en-tête indique une autre dépendance ($local_fs), celle-ci est redondante dans systemd car les services normaux systemd sont toujours démarrés lorsque tous les systèmes de fichiers locaux sont disponibles.
  • L'en-tête LSB suggère que ce service doit être démarré dans les runlevels 3 (multi-utilisateur) et 5 (graphique).
  • Le binaire du démon est /usr/sbin/abrtd.

Et c'est déjà tout ! Le reste de ce script de 115 lignes est simplement du code générique ou redondant: du code qui gère la synchronisation et l'ordonnancement du démarrage (du code qui gère les fichiers de lock) ou qui génère des messages d'état (le code qui appelle echo), ou simplement qui analyse les arguments (le gros bloc du case).

À partir de l'information extraite ci-dessus, nous pouvons maintenant écrire notre fichier de service systemd:

[Unit] Description=Daemon to detect crashing apps After=syslog.target [Service] ExecStart=/usr/sbin/abrtd Type=forking [Install] WantedBy=multi-user.target Un peu d'explications du contenu de ce fichier La section [Unit]

Elle contient de l'information générique sur le service. Systemd gère des services systèmes mais également des périphériques, des points de montage, des timers, et d'autres composants du système. Le terme générique pour tous ces objets dans systemd est une unité (Unit). La section [Unit] stocke l'information qui s'applique non seulement aux services mais également à tous les autres types d'unité systemd. Dans notre cas, nous ajoutons les paramètres d'unité suivants: nous ajoutons une chaîne de caractère de description et nous configurons que le démon doit être lancé après Syslog2, de la même manière à ce qui est indiqué dans l'en-tête LSB du script d'init originel. Pour gérer cette dépendance à Syslog, nous créons une dépendance de type After= sur l'unité systemd nommée syslog.target. Cette dernière est une unité particulière et elle représente le nom standard pour l'implémentation de syslog dans systemd. Pour plus d'informations sur ces noms standardisés, consultez la page de manuel systemd.special(7). Notez qu'une dépendance du type After= représente seulement une suggestion d'ordre de démarrage; elle ne se traduit pas par le démarrage de syslog lorsque abrtd démarre. C'est exactement ce que nous voulons puisque abrtd fonctionne correctement, même lorsque syslog n'est pas disponible. Néanmoins, si les deux sont démarrés (c'est généralement le cas), alors l'ordre dans lequel ils sont lancés est contrôlé avec cette dépendance.

La section [Service]

Elle s'occupe de l'information sur le service en lui-même. Elle contient tous les paramètres qui s'appliquent uniquement à des services et non aux autres types d'unité systemd (points de montage, périphériques, timers, …). Deux paramètres sont utilisés ici: ExecStart= qui stocke le chemin vers le binaire pour l'exécuter lorsque le service doit être démarré. Avec Type=, on configure la manière dont le service notifie le système d'init qu'il a terminé son démarrage. Étant donné que les démons traditionnels Unix le font en émettant un code de retour au processus parent après avoir forké et initialisé un démon en tâche de fond, nous utilisons le type forking ici. Cela indique à systemd d'attendre jusqu'à ce que le binaire de démarrage envoie un code retour et de gérer les processus qui tournent toujours après ceux du démon.

La dernière section est [Install]

Elle stocke l'information sur comment devrait être l'installation suggérée, c’est-à-dire, dans quelles circonstances et par quels déclencheurs le service devrait être démarré. Dans notre cas, nous indiquons simplement que le service doit être démarré lorsque l'Unit multi-user.target est activée. Il s'agit également d'une Unit spéciale qui prend globalement le rôle du Runlevel 32 de SysV. Le paramètre WantedBy= a peu d'effet sur le fonctionnement courant du démon. Il est uniquement lu par la commande systemctl enable qui est le moyen recommandé d'installer un service dans systemd. Cette commande s'assure simplement que notre service est automatiquement activé dès que l'Unit multi-user.target est requise, ce qui est le cas lors des séquences de boot normales3.

Et c'est tout ! Nous avons maintenant un fichier de service systemd fonctionnel et simple. Pour le tester, il faut le copier dans /etc/systemd/system/abrtd.service et lancer systemctl daemon-reload. Cela permettra à systemd de prendre en compte notre fichier et dès cet instant, nous pouvons démarrer ce service en lançant: systemctl start abrtd.service. Nous pouvons en vérifier l'état grâce à systemctl status abrtd.service. Et nous pouvons arrêter le service via systemctl stop abrtd.service. Finalement, nous pouvons l'installer de manière à ce qu'il soit activé par défaut lors des prochains boots avec la commande systemctl enable abrtd.service.

Le fichier de service ci-dessus, bien que suffisant et représentant une traduction globale du script d'init SysV, peut encore être amélioré. En voici une petite mise à jour:

[Unit] Description=ABRT Automated Bug Reporting Tool After=syslog.target [Service] Type=dbus BusName=com.redhat.abrt ExecStart=/usr/sbin/abrtd -d -s [Install] WantedBy=multi-user.target

Voyons ce qui a changé. Deux choses: nous avons amélioré la description et, plus important, nous avons changé le type de service à dbus et configuré le nom D-Bus du service. Pourquoi avoir fait cela ? Comme déjà évoqué précédemment, les services classiques SysV deviennent des démons après le démarrage ce qui implique généralement un double fork et le fait de se détacher de tout terminal. Bien que cette approche soit utile et nécessaire lorsque les démons sont lancés par un script, elle est non nécessaire (et lente) ainsi que contre-productive lorsqu'un système efficace de gestion des processus tel que systemd est employé. La raison à cela est que le processus du démon qui a forké n'a généralement plus de lien avec le processus démarré par systemd (la procédure de transformation en démon consiste à supprimer ce lien), ce qui rend difficile pour systemd de distinguer, après le fork, dans les processus appartenant au service, lequel est le processus principal et quels sont les processus auxiliaires. Cette information est pourtant cruciale pour disposer d'une gestion de processus aux petits oignons, c’est-à-dire pour superviser un processus, le relancer automatiquement lors des arrêts anormaux, collecter l'information de crash et les codes de sortie. Pour que systemd puisse facilement repérer quel est le processus principal, nous avons changé le type de service à dbus. La syntaxe de ce type de service est faite pour tous les services qui prennent un nom sur le bus système D-Bus comme dernière étape de leur initialisation 4. ABRT est un de ces services. Avec ce paramètre, systemd lancera le processus ABRT qui ne forkera plus (configuré via les options -d -s du démon) et systemd considérera le service comme complètement démarré dès que com.redhat.abrt apparaîtra sur le bus. Ainsi, le processus lancé par systemd sera le processus principal du démon et systemd dispose d'un moyen fiable pour vérifier si le démon est complètement démarré; systemd pourra le superviser plus facilement.

Et c'est tout ce qu'il y a besoin de faire. Nous avons un simple fichier de service systemd qui fournit plus d'information dans 10 lignes que le script SysV originel en 115 lignes. Dès maintenant, il reste encore une grande marge d'amélioration en utilisant plus de fonctionnalités de systemd. Par exemple, nous pourrions configurer Restart=restart-always pour indiquer à systemd de relancer automatiquement le service lorsque celui-ci échoue. Ou encore, nous pourrions utiliser OOMScoreAdjust=-500 pour demander au noyau de laisser ce processus lorsque OOM killer est employé. Ou bien, nous pourrions utiliser CPUSchedulingPolicy=idle pour s'assurer que les processus abrtd crashent en tâche de fond uniquement, en autorisant le noyau à donner sa préférence à tout ce qui fonctionne et qui a besoin de temps CPU.

Pour plus d'informations sur les options de configuration mentionnées ci-dessus, consultez les pages de manuel respectives systemd.unit(5), systemd.service(5), systemd.exec(5). Ou bien, consultez toutes les pages de manuel systemd.

Bien sûr, tous les scripts SysV ne se convertissent pas aussi facilement que celui que nous avons étudié. Néanmoins une grande majorité devrait pouvoir l'être.

C'est tout pour aujourd'hui, à bientôt pour la prochaine session de cette série.

Partie 4: Tuer des services

Tuer un service, c'est simple non ? Ou pas ?

Bien entendu, tant que votre démon est constitué d'un seul processus, c'est généralement vrai. Vous tapez killall rsyslogd et le démon syslog n'est plus. Néanmoins, c'est un peu sale de faire ainsi étant donné que cela tuera tous les démons qui s'appellent ainsi, incluant ceux qu'un utilisateur malchanceux aurait nommé ainsi par accident. Une version plus correcte aurait été de lire le fichier .pid, c'est-à-dire kill $(cat /var/run/syslogd.pid). Cela nous avance un peu mais néanmoins est-ce vraiment ce que nous souhaitons ?

Dans la majorité des cas en fait, cela ne se passera pas ainsi. Considérons des services tels qu'Apache, crond ou atd qui, dans leur fonctionnement courant, engendrent des processus fils. Généralement, il s'agit de processus fils configurables par l'utilisateur tels que des tâches cron ou at ou encore des scripts CGI, y compris des serveurs d'application complets. Si vous tuez le processus principal Apache/crond/atd cela pourra ou non tuer l'ensemble des processus fils également et c'est à chacun de ces processus de savoir s'ils veulent continuer à tourner ou s'ils doivent s'arrêter. Dans la pratique, cela signifie que mettre fin à Apache pourrait très bien laisser ces scripts CGI fonctionner, réaffectés comme enfants du processus init, ce qui est difficile à tracer.

Systemd vient à la rescousse: avec systemctl kill, vous pouvez facilement envoyer un signal à tous les processus d'un service. Par exemple:

# systemctl kill crond.service

Cela assurera que SIGTERM est envoyé à tous les processus du service crond, pas uniquement au processus principal. Bien entendu, vous pouvez également envoyer un signal différent si vous le souhaitez. Par exemple, si vous êtes mal luné, vous aurez peut-être envie d'envoyer SIGKILL de cette manière:

# systemctl kill -s SIGKILL crond.service

Et voilà, le service sera complètement stoppé brutalement, peu importe combien de fois il a été forké ou qu'il essaye d'échapper à la supervision par un fork double ou par un bombardement de forks.

Parfois, vous avez juste besoin d'envoyer un signal spécifique au processus principal d'un service, par exemple parce que vous voulez déclencher un rechargement du service par le signal SIGHUP. A la place de retrouver le fichier de PID, voici un moyen plus simple d'y parvenir:

# systemctl kill -s HUP --kill-who=main crond.service

Encore une fois, qu'y-a-t-il de nouveau et de fantaisiste dans la manière de tuer des processus avec systemd ? Eh bien, pour la première fois sous Linux, nous pouvons le faire proprement. Les précédentes solutions dépendaient toutes de la bonne coopération des démons pour qu'ils arrêtent tous les processus qu'ils avaient engendrés lorsqu'ils devaient se terminer. Néanmoins si vous voulez employer SIGTERM ou SIGKILL, vous le faites parce qu'ils ne coopèrent pas correctement avec vous.

Qu'est-ce-que ça a à voir avec systemctl stop ? kill envoie directement un signal à chacun des processus situés dans le groupe; stop, pour sa part, utilise le moyen officiellement configuré pour arrêter le service, c'est-à-dire qu'il lance la commande configurée avec ExecStop= dans le fichier de service. En général, stop devrait être suffisant. kill reste la méthode forte à utiliser dans les cas ou vous ne voulez pas utiliser la commande shutdown d'un service ou bien lorsque le service est complètement en carafe.

(C'est à vous bien entendu d'indiquer ou non les noms de signaux avec le préfixe SIG avec ou sans l'option -s. Les deux fonctionnent.)

C'est assez surprenant d'être parvenu jusqu'ici sous Linux sans disposer d'un moyen efficace de tuer des services. Systemd permet pour la première fois de le faire proprement.

Partie 5: Trois niveaux de "Off"

Dans systemd, il y a trois niveaux pour arrêter un service (ou d'autres unités). Voyons voir quels sont-ils:

Arrêter un service

Cela termine simplement l'instance du service qui fonctionne et cela ne fait que ça. Si pour d'autres raisons d'activation (telles que le lancement manuel, l'activation par socket, par le bus, par le boot du système ou par un interrupteur machine) le service est demandé après cet arrêt, il sera à nouveau lancé. Arrêter un service est donc une opération simple, temporaire et superficielle. Voici un exemple avec le service NTP:

$ systemctl stop ntpd.service

C'est globalement équivalent à la commande traditionnelle disponible sur la plupart des systèmes basés sur SysV:

$ service ntpd stop

Dans les faits, sur Fedora 15, si vous exécutez cette dernière commande, elle sera convertie de manière transparente en la première.

Désactiver un service

Cela détache le service de ses déclencheurs. Cela signifie que, selon votre service, il ne sera plus activé au démarrage de la machine, par socket, par bus ou par un interrupteur machine (ou tout autre déclencheur qui s'y applique). Néanmoins, vous pouvez quand même le lancer manuellement si vous le désirez. S'il y a déjà une instance du service démarrée, désactiver un service ne l'arrêtera pas. Voici un exemple de comment désactiver un service:

$ systemctl disable ntpd.service

Sur les systèmes traditionnels Fedora, c'est globalement l'équivalent de la commande qui suit:

$ chkconfig ntpd off

Ici également, sur Fedora 15, la commande précédente sera convertie de manière transparente en la première, si nécessaire.

Bien souvent, vous souhaitez combiner arrêt et désactivation du service, de manière à supprimer l'instance courante et faire en sorte que le service ne soit pas relancé (sauf par action manuelle):

$ systemctl disable ntpd.service $ systemctl stop ntpd.service

Les commandes précédentes sont lancées par exemple lors de la désinstallation du paquet d'un service systemd sur Fedora.

Désactiver un service est un changement permanent; tant que vous ne le réactivez pas, ce changement sera conservé même après le redémarrage de la machine.

Masquer un service.

C'est comme le désactiver mais en plus fort. Cela fait en sorte d'être sûr que le service ne sera plus jamais démarré automatiquement mais assure également qu'un service ne puisse plus être démarré manuellement. C'est une fonctionnalité cachée dans systemd puisqu'elle n'est pas utilisé couramment et qu'elle peut être mal interprétée par un utilisateur. Néanmoins, voilà comment vous devriez procéder:

$ ln -s /dev/null /etc/systemd/system/ntpd.service $ systemctl daemon-reload

En créant un lien symbolique d'un fichier de service vers /dev/null, vous indiquez à systemd de ne jamais démarrer le service en question et vous bloquez complètement son exécution. Les fichiers d'unité stockés dans /etc/systemd.system remplacent ceux qui sont situés dans /lib/systemd/system qui portent le même nom. Le premier répertoire relève de l'administrateur système, le second relève du responsable de paquet. En installant un lien symbolique dans /etc/systemd/system/ntpd.service, vous pouvez être sûr que systemd ne lira jamais le fichier de service situé dans /lib/systemd/system/ntpd.service.

Systemd reconnaîtra les unités liées vers /dev/null et les indiquera comme étant masquées. Si vous essayez de lancer de tels services manuellement (via systemctl start par exemple), cela se terminera par une erreur.

Un mécanisme similaire n'existe pas (officiellement) pour les systèmes SysV. Néanmoins, il existe quelques trucs officieux comme éditer le script d'init et en indiquant un exit 0 au début ou bien encore en enlevant le bit exécutable. Néanmoins ces solutions présentent différents inconvénients comme le fait qu'elles interfèrent avec ce que le responsable de paquet a prévu.

Masquer un service est un changement permanent, un peu comme désactiver un service.

Maintenant que nous savons comment gérer l'arrêt de services sur ces trois niveaux, il reste encore une question: commet les réactiver. Eh bien, c'est assez similaire. Utilisez systemctl start pour revenir en arrière de la commande systemctl stop. Utilisez systemctl enable pour revenir en arrière de la commande systemctl disable et utilisez rm pour supprimer les liens symboliques.

C'est tout pour aujourd'hui, Merci de votre attention !

Notes de bas de page

Note du rédacteur: ce serait bien que l'ensemble des traductions relatives à systemd du blog de Lennart Poettering puissent être traduites sur LinuxFr.org (sauf peut-être celles sur journald qui est un composant optionnel de systemd). Cela permettrait de rendre plus accessible et démystifier un peu ce composant système devenu maintenant quasi-incontournable ainsi que d'apporter quelques articles techniques (pas forcément de haut niveau) sur LinuxFr.org.

  1. L'en-tête LSB des scripts d'init est une convention qui permet d'inclure des métadonnées sur le service dans des blocs de commentaires des scripts d'init SysV. Elle est définie dans la Linux Standard Base. L'objectif était de standardiser les scripts d'init parmi les différentes distributions. Bien que la majorité des distributions ont adopté ce schéma, la gestion des en-têtes varie beaucoup d'une distribution à l'autre et dans les faits, il est souvent nécessaire d'adapter chaque script d'init pour chacune des distributions. La spécification LSB sur ce point n'a jamais atteint la promesse qu'elle s'était fixée au départ. 

  2. Au moins de la manière utilisée pour sa définition dans Fedora. 

  3. Veuillez noter que dans systemd, le boot graphique (graphical.target qui prend le rôle du RunLevel 5 de SysV) est un sur-ensemble de la séquence de boot dédiée au mode console seule (multi-user.target, c’est-à-dire le RunLevel 3). Cela signifie que rattacher un service dans cette dernière le rattachera également à la première séquence de boot (`graphical.target). 

  4. En fait, la majorité des services de l'installation par défaut de Fedora utilisent maintenant un nom sur le bus après démarrage. 

Télécharger ce contenu au format Epub

Lire les commentaires

Atelier CLI du lundi 06 octobre 2014 à Bordeaux

1 octobre, 2014 - 09:39

Le lundi 06 octobre se tiendra le troisième atelier CLI dont le thème porte sur le framebuffer.

Les ateliers CLI ont lieu chaque lundi de 19h00 à 20h00 pour les utilisateurs débutants, et de 19h00 à 21h30 pour les utilisateurs avancés, dans les locaux du L@BX, à la Fabrique Pola (rue Marc Sangnier, 33130 Bègles).

Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

Les ateliers consacrés aux débutants reprendront le 13 octobre.

Télécharger ce contenu au format Epub

Lire les commentaires

WindowMaker 0.95.6 est sorti

1 octobre, 2014 - 08:33

WindowMaker est un gestionnaire de fenêtres, originellement pour le projet GNUstep, qui a connu son heure de gloire dans les années 2000, mais qui continue de vivre sa vie grâce au travail de Carlos R. Mafra et d'une petite équipe.
Le 30 août 2014 est sortie la version 0.95.6, qui apporte quelques nouveautés, les principales étant :

  • la possibilité d'avoir un aperçu des fenêtres iconifiées ;
  • le support des images au format WebP, ainsi que de la bibliothèque ImageMagick pour les formats exotiques (BMP, TGA, SVG, …).

Cette version a été suivie de la sortie de wmlive par Paul Seelig, une distribution qui permet de tester et utiliser WindowMaker à partir d'un DVD ou d'une clef USB.

C'est enfin l'occasion de découvrir quelques améliorations sur certaines dockapps hébergées par le projet.

Plus de détails dans la seconde partie de la dépêche…

WindowMaker

Cette version, sortie un an après la précédente, repose sur pas moins de 527 patches provenant de 15 contributeurs. Parmi les changements, on peut noter en plus des deux points ci-dessus:

  • la possibilité d'utiliser les boutons des souris qui en ont jusqu'à neuf ;
  • l'envoi des messages d'erreurs et warnings au travers du journal syslog ;
  • un certain nombre de petites améliorations diverses (sur la maximisation des fenêtres, la navigation avec alt-tab, …) ;
  • quelques petits détails supplémentaires maintenant paramétrables à travers WPrefs ;
  • beaucoup de petites corrections, notamment grâce à l'utilisation de Cppcheck, du Clang Static Analyzer et de Coverity.
wmlive

Basé sur la Debian stable (Wheezy), ces ISO de plus de 900MB sont disponibles pour les architectures Intel 32 et 64 bits.
Si la principale nouveauté concerne la version de WindowMaker, elle s'accompagne tout de même de quelques autres petites mises à jour diverses, et de l'inclusion de solutions de virtualisation.

Les Dockapps

De ces petites applications destinées à se loger dans le dock de WindowMaker, quelques-unes abandonnées par leur auteur ont été recueillies par l'équipe du projet. On peut noter comme principale évolution wmix 3.2, qui permet maintenant de contrôler le volume à l'aide des touches "multimédia" du clavier, et s'est enrichie d'une page de manuel complète.

Télécharger ce contenu au format Epub

Lire les commentaires

Venez découvrir la cartographie collaborative libre samedi 4 octobre 2014 à Forcalquier (04)

30 septembre, 2014 - 13:36

Venez découvrir la cartographie collaborative libre avec OpenStreetMap samedi 4 octobre 2014 à Forcalquier. Un atelier proposé par APITUX dans le cadre du Village des sciences à Forcalquier. C'est au Couvent des cordeliers, en continu de 14h à 18h. Accès libre, tout public.

OpenStreetMap est une base de données géographique construite de manière collaborative et publiée sous licence libre. Le projet reprend les principes qui ont fait le succès de Wikipédia. La contribution est ouverte à tous, chacun peut cartographier sa commune, son quartier, sa randonnée préférée. La carte du monde se dessine progressivement par l'assemblage de toutes les contributions.

APITUX animera également des ateliers en direction des scolaires vendredi 3 octobre de 14h à 18h.

Les enfants enrichissent une carte du monde librement accessible à tous à partir de différentes sources :

  • connaissance de l'environnement immédiat et observation accompagnée sur le terrain,
  • photos satellites,
  • relevés GPS.

Allers/retours entre le territoire et la technique, initiation à la géomatique, participation à un projet collaboratif à l'échelle planétaire, sensibilisation aux enjeux du partage sous licences libres.

À l'issue de l'atelier, les contributions sont accessibles en ligne.
Sur inscription par groupes de 8 élèves de cycle 3 ou collège.

Télécharger ce contenu au format Epub

Lire les commentaires

Retour d'expérience sur la cartographie collaborative libre avec OSM le 2 octobre 2014 à Digne (04)

30 septembre, 2014 - 11:24

Une rencontre départementale aura lieu dans les Alpes-de-Haute-Provence, sur la thématique « Réseaux sociaux et nouvelles formes d’engagement » jeudi 2 octobre 2014. Celle-ci s'inscrit dans le cadre des États généraux « Donner enfin leur place aux jeunes » organisés par la Région Provence-Alpes-Côte d’Azur. Rendez-vous à partir de 16h30, Salle Perchot, Avenue des Thermes à Digne.

Jean-Christophe Becquet, directeur d’APITUX proposera un retour d'expérience sur la cartographie collaborative libre avec OpenStreetMap dans le cadre de l'initiative « Dessine ta ville » à Digne-les-Bains.

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 39 de l'année 2014

29 septembre, 2014 - 22:31

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[Slate.fr] Shellshock, la nouvelle faille qui inquiète Internet, est-elle pire qu'Heartbleed? Difficile de le savoir

Par Andréa Fradin, le jeudi 25 septembre 2014. Extrait:

Le bug touche Bash, un programme que vous ne connaissez peut-être pas, mais qui permet à l'utilisateur d'accéder aux fonctions du système d'exploitation.

Lien vers l'article original: http://www.slate.fr/story/92601/bash-nouveau-bug-pire-heartbleed

Et aussi:

Voir aussi

[Next INpact] La ministre de l’Éducation veut que les enfants soient initiés au code

Par Xavier Berne, le mercredi 24 septembre 2014. Extrait:

Promue ministre de l’Éducation nationale suite au dernier remaniement ministériel, Najat Vallaud-Belkacem a assuré la semaine dernière qu’elle maintenait la position de son prédecesseur s’agissant de l’apprentissage de la programmation informatique à l’école. Devant l’Assemblée nationale, la benjamine du gouvernement s’est ainsi montrée déterminée à introduire une initiation obligatoire au code pour les élèves.

Lien vers l'article original: http://www.nextinpact.com/news/90064-la-ministre-l-education-veut-que-enfants-soient-inities-au-code.htm

Et aussi:

[Next INpact] Fleur Pellerin consacre la Hadopi en enterrant son transfert au CSA

Par Marc Rees, le mardi 23 septembre 2014. Extrait:

La fusion des compétences de la Hadopi entre les mains du CSA n’est vraiment plus la priorité du ministère de la Culture. Dans une interview au Monde, publiée cet après-midi, Fleur Pellerin confirme que désormais, la priorité est la lutte contre le streaming et le direct download.

Lien vers l'article original: http://www.nextinpact.com/news/90041-fleur-pellerin-consacre-hadopi-en-enterrant-son-transfert-au-csa.htm

[ZDNet] Pratique: le guide du logiciel libre pour les TPE-PME

Par Fabien Soyez, le lundi 22 septembre 2014. Extrait:

Sortis de leur carcan “geek”, les logiciels libres offrent aux entreprises une alternative aux produits propriétaires, couvrant la plupart de leurs tâches.

Lien vers l'article original: http://www.zdnet.fr/actualites/pratique-le-guide-du-logiciel-libre-pour-les-tpe-pme-39806659.htm

[Framablog] Enercoop: libérer les énergies

Par Pyg, le lundi 22 septembre 2014. Extrait:

Le logiciel libre donne à tous salariés d’Enercoop et aux informaticiens en particulier, les moyens de domestiquer, de comprendre et d’enrichir les systèmes qu’ils utilisent. Le logiciel libre signifie le partage de la connaissance, c’est la base de l’enseignement, du développement d’une culture libre et de l’épanouissement intellectuel de chacun.

Lien vers l'article original: http://www.framablog.org/index.php/post/2014/09/22/Enercoop-liberer-les-energies

[WSJ.com] Hard Times for Software Patents

Par Jacob Gershman, le lundi 22 septembre 2014. Extrait:

(Les cours fédérales ont rejeté plus de brevets logiciels depuis que le jugement de la Cour Suprême de juin) Federal courts have rejected more software patents since a U.S. Supreme Court ruling in June tackled the question of whether—and when—computer programs can qualify for intellectual-property protection.

Lien vers l'article original: http://blogs.wsj.com/law/2014/09/22/hard-times-for-software-patents/

Et aussi:

[France Culture] Nous et nos données

Par la rédaction, le vendredi 19 septembre 2014. Extrait:

Chaque jour, chacun d’entre nous produit de plus en plus de données. Même les plus fervents défenseurs de la déconnexion, ou les réseaux sociaux laissent des traces numériques. A chaque fois que nous nous connectons, utilisons notre abonnement pour un vélo en libre accès, prenons le métro ou le tram, envoyons des mails ou téléchargeons une application, nous laissons des informations sur nous. Elles deviennent un enjeu majeur qui mobilise de plus en plus, sauf peut-être les premiers concernés ! Enquête de Catherine Petillon.

Lien vers l'article original: http://www.franceculture.fr/emission-pixel-nous-et-nos-donnees-2014-09-19

Et aussi:

[Marianne] Traité transatlantique: le gouvernement demande enfin la transparence!

Par Bruno Rieth, le jeudi 18 septembre 2014. Extrait:

Jusqu’à présent, le gouvernement se foutait bien de l’opacité entourant le mandat de négociation des émissaires européens sur le traité transatlantique. Pis, il paraissait l'approuver. Mais Matthias Fekl, le remplaçant du phobique Thomas Thévenoud au secrétariat au Commerce extérieur, vient d’exiger que le secret soit levé. Ni plus ni moins que ce que réclament depuis des mois les opposants au traité…

Lien vers l'article original: http://www.marianne.net/Traite-transatlantique-le-gouvernement-demande-enfin-la-transparence-_a241454.html

Télécharger ce contenu au format Epub

Lire les commentaires

Cours Linux à Lille tous les mercredis par l'UFJ

29 septembre, 2014 - 22:29

L'UFJ (association d'éducation populaire) organise comme tous les ans à partir d'octobre des cours d'initiation aux logiciels libres niveau débutant tous les mercredis de 18h à 20h dans ses locaux rue du Mal Assis à Lille.

NdM: « Le pôle éducation populaire permet la formation pour tous et tout au long de la vie dans diverses disciplines. Une seule adhésion en début d’année donne accès à l’ensemble des [50] cours proposés. (…) Inscription tout au long de l'année et possibilité d'assister gratuitement au 1er cours. Tarif adhésion: 120 € / an, 60 € / an (étudiants, demandeurs d'emploi et personnes non imposables) »

Télécharger ce contenu au format Epub

Lire les commentaires

Red Hat Enterprise Linux 5.11

29 septembre, 2014 - 18:44

C'est discrètement, en plein milieu de ce mois de septembre, que Red Hat a rendu disponible la version 5.11 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises.

Alors bon, sachant que la 7 est toute neuve, pleine de nouveautés, et que la 6 est encore fringante, pourquoi sortir une mise à jour de la vieillissante 5 ? Parce que c'est l'engagement de Red Hat de maintenir sa distribution entreprise pendant 10 ans (13 si vous avez les moyens de payer pour du support étendu).

Comme pour la 5.10, les changements (abordés en seconde partie de dépêche) sont avant tout des corrections et quelques mises à jour de compatibilité matérielles ne demandant pas de développement conséquent.

Numérotage des versions de RHEL 5

Dans son annonce, Red Hat précise qu'il s'agit de la dernière version mineure. Cela ne veut pas dire qu'il n'y aura plus de mises à jour (RHEL 5 a 7 ans, donc il y a encore trois ans de maintenance), mais qu'il n'y aura plus d'incrémentation du numéro de version global. RHEL 5.11 est donc la dernière RHEL 5.

Matériel

L'outil dmidecode est assez pratique pour connaître à bas niveau le type de matériel du système. Il est donc mis à jour pour prendre en compte une plus grande variété de matériels, ainsi que la version 2.8 de SMBIOS.

Si votre machine comporte un contrôleur SAS LSI MegaRAID SAS 9360/9380 12Gb/s, vous êtes enfin sous support ! Le pilote a en effet quitté le statut d'avant-première technologique.

Enfin, le pilote cciss prend maintenant en charge les serveurs HP ProLiant avec les derniers contrôleurs SAS Smart Array.

Réseau

Si vous utilisez le paquet samba3x, attention ! La mise à jour disponible dans RHEL 5.11 provoque un changement dans le format des fichiers de TDB (Trivial Database), qui est incompatible avec les précédentes versions. Pensez donc à faire une copie de ces fichiers si vous voulez pouvoir revenir sur une version précédente.

Virtualisation

L'agent virt-who communique maintenant avec un hôte VMWare ESXi, ce qui permet de donner des informations à Subscription Manager dans le cas d'une machine virtuelle RHEL 5.11.

À noter aussi de nombreuses corrections de sécurité pour Xen : la liste complète des CVE corrigés se trouve dans la note technique.

Gestion des abonnements RHN

Red Hat Support Tool a été amélioré pour afficher des messages d'erreur plus facilement compréhensibles lorsqu'il n'arrive pas à télécharger les symboles de débogage, ce qui arrive par exemple s'il n'y a pas assez d'espace disque disponible.

Subscription Manager a aussi quelques améliorations, comme la génération du fichier redhat.repo tout de suite après l'enregistrement, sans attendre Yum. Autre amélioration notable, un champ "Subscription Type" a été ajouté, afin de connaître le type d'abonnement. Tout cela est accessible en ligne de commande et via l'interface graphique.

Certifications et standards de l'industrie

RHEL 5.11 contient OpenSCAP 1.0.8. Red Hat pousse depuis plusieurs versions de RHEL à l'utilisation du protocole SCAP, utilisé aussi par le NIST pour valider la sécurité des systèmes informatiques.

CentOS

À l'heure où vous lirez ces lignes, CentOS 5.11 sera sans doute déjà disponible, puisque Karanbir Singh (CentOS Project Leader) a annoncé ce 29 septembre son arrivée prochaine :

We are currently seeding CentOS-5.11 for release.
Karanbir Singh (@CentOS)
September 29, 2014

Télécharger ce contenu au format Epub

Lire les commentaires

Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement

29 septembre, 2014 - 17:51

appzer0 a écrit un journal pour évoquer l'état des lieux de la distribution 0Linux après 4 ans de développement :

0Linux est pour rappel une distribution indépendante (basée sur rien d'autre qu'elle-même) sous licence CeCiLL. Créée en 2010, elle s'adresse à un public francophone. Elle et a une vocation généraliste et est proche de Slackware (absence de PAM, pulseaudio ou systemd, scripts d'init à la BSD).

Cela fait maintenant 4 ans que je développe et maintiens 0Linux, une distribution GNU/Linux complète. Un projet à la charge de travail ahurissant que j'ai entrepris seul mais qui m'a ô combien appris sur les plus infimes rouages de ce super OS. Alors, où en est-on, domine-t-on le monde ? A-t-on derrière nous une armée de développeurs qui empaquettent à tout va, un forum qui déborde de discussions passionnés, des blogs de fans qui postent des captures de leur bureau et des e-mails de sponsors qui se bousculent dans notre file d'attente de courriel ? Que nenni.
Suis-je, a contrario, toujours là à coder seul devant mon écran poussiéreux, à maintenir un logiciel dont tout le monde se fout éperdument ? Non plus.

Pour reprendre le journal de 2011 :

Pour info, la liste de diffusion compte 5 membres, il n'y a pas de forum, juste un wiki (5 membres aussi), 0 est dans la liste d'attente de Distrowatch (tout en bas) et le canal IRC dépasse rarement les 5 personnes.

Elle n'a pas attiré les foules ni défrayé la chronique avec des fonctionnalités inédites ; elle a une documentation plutôt maigre et une base d'utilisateurs anecdotique mais elle a néanmoins bien grandi :

  • plus de 1400 paquets ;
  • 4 personnes contribuent régulièrement au projet (en code ou en hébergement/ressources) ;
  • une « infrastructure » qui compile automatiquement les paquets modifiés sur des serveurs dédiés, ce qui a permis de compiler sur 2 architectures depuis une seule arborescence de sources: x86_64 multilib et i686 ;
  • un site dédié ;
  • bien plus de membres et de visiteurs ;
  • un forum ;
  • un gestionnaire de paquets fiable (toujours Spack) et un outil de mise à jour et d'installation, 0g, qui gère maintenant les dépendances ;
  • un bureau KDE ultra-complet ;
  • un catalogue en ligne des paquets (en cours de construction) ;
  • 0Linux vient tout juste d'être intégrée à Distrowatch.

0Linux est aujourd'hui une distribution Linux sans prétention mais assez complète, intégrant pas mal de bureaux et d'environnements graphiques (flux/openbox, Enlightenment, KDE, MATE, Xfce, GNOME est en cours), des serveurs, des jeux, des applications pour le multimédia, etc. et a même ses propres fonds d'écran contribués. Les outils spécifiques à la distribution sont tous en shell, y compris la gestion des paquets et des mises à jour ainsi que l'installateur.

Elle a eu sa période systemd puis est revenue aux scripts à la BSD pour de multiples raisons qui ne sont pas le sujet de ce journal, a eu un outil pour faire du suivi de tâches qui a finalement été supprimé mais qui a tout de même servi.

Après tout ce temps (et cette énergie), je suis plutôt satisfait du résultat : 0Linux est une distribution agréable que j'utilise quotidiennement, y compris pour bosser ou faire tourner des serveurs et elle attire sporadiquement des curieux qui reviennent (parfois) ou qui ne font que passer (souvent). Un hébergeur veut même la proposer dans les systèmes installables sur leurs serveurs dédiés.

Alors, qu'est-ce qui est le plus difficile dans la maintenance d'une distribution ?

Être à jour peut être un vrai calvaire. Outre la difficulté à avoir un canal stable, régulier et léger d'informations sur les sorties (comprendre : pas noyé dans le torrent de messages d'une liste de discussion de développement ou bien sur un site qui ne change pas d'URL tous les mois), certains logiciels peuvent sortir plusieurs versions par semaine (voire par jour !), et de plus en plus cassent allègrement l'API/l'ABI (ou les deux) sans changer de manière adéquate leur numéro de version, quand ils ne réclament pas des bibliothèques sorties il y a 10 minutes pour compiler des logiciels qui n'ont pas bougé (oui GNOME, c'est de toi que je parle).

La visibilité du projet : il faut communiquer souvent, y compris sur les réseaux sociaux qu'on ne porte pas dans son coeur, et prier pour être intégré dans les sites populaires qui ont autorité de facto et qui peuvent vous ignorer pendant des années (là c'est de toi Distrowatch, que je parle).

La sécurité : il faut veiller à ce que ses paquets ne soient pas troués et consulter régulièrement les différentes ressources sur la sécurité.

Bref, tout ça mis bout à bout avec les autres tâches régulières, écrire des recettes, poster des articles, coder pour automatiser au maximum, tester, tester, tester, ça fait un sacré boulot.

Ce que je regrette :

  • la documentation, elle est bien trop maigre mais j'ai si peu de retours que je ne sais même pas si elle est consultée ;
  • la dynamique du projet : je m'attendais, peut-être naïvement, à voir des enthousiastes arriver par wagons et me proposer de contribuer ou bien d'avoir des propositions de fusion avec d'autres projets : niet ! Idem à propos de la constitution d'une communauté autour du projet, ça reste sporadique (mais on gagne en qualité ce qu'on rate en quantité et c'est finalement pas plus mal ainsi). Inutile de vouloir susciter un intérêt significatif du public, ça reste une simple distribution parmi tant d'autres.

Comment je vois le futur : un port ARM me plairait baucoup (j'ai déjà une chaîne de compilation) ainsi qu'un « Live » avec installateur graphique. J'aimerais également avoir une interface web pour administrer les serveurs de construction, consulter les logs, gérer les files d'attente de compilation, etc.

Cette activité m'a appris énormément mais m'a aussi montré les limites du shell et de Bash. Je pense donc me tourner vers Python3 à l'avenir, ce que j'en ai vu jusque là m'a beaucoup plu.

J'oublie certainement beaucoup d'autres aspects, mais c'est la raison pour laquelle ce post n'est qu'un journal (NdM: on a choisi néanmoins d'en faire une dépêche). Je développerai en commentaire ou dans un autre journal ce que j'ai pu avoir oublié.

Quelques liens pour finir :

Télécharger ce contenu au format Epub

Lire les commentaires

Vivre du logiciel libre - Ludovic Dubost nous parle de sa société : XWiki SAS

29 septembre, 2014 - 11:49

Le deuxième volet de la série sur l'économie du libre continue. Après l'entretien avec Jérôme Martinez début septembre, je vous propose de découvrir la société XWiki SAS, éditeur de logiciels libres créée il y a maintenant 10 ans par Ludovic Dubost.

XWiki SAS prouve si cela était nécessaire que l'édition de logiciels vraiment libres (sous licence LGPL) est une activité économique viable.

Sommaire Introduction Nom et prénom Ludovic Dubost Société XWiki SAS Activité de l'entreprise Editeur de logiciel collaboratif Open Source Démarrage de l'activité 15/11/2003 — Projet Open Source XWiki 19/07/2004 — XWiki SAS Localisation de la clientèle France, Europe, Monde Nombre de collaborateurs 42 Sites web http://www.xwiki.com, http://www.xwiki.org

Note : si vous êtes intéressé(e)s pour une interview, contactez-moi par courriel - damien point accorsi arobase free point fr.

Je vous laisse découvrir l'entretien et les réponses de Ludovic ; notez que Ludovic sera disponible ce mardi 30 septembre pour répondre aux questions que vous [vous|lui] posez. Alors n'hésitez pas à commenter/questionner !

La génèse du projet, la société

Bonjour Ludovic, pourrais-tu présenter en quelques lignes qui tu es, ce que tu fais et la démarche qui t'a mené à la création de la société XWiki ?

Bonjour Damien, très heureux de répondre à tes questions. Je suis un passionné d'informatique et d'Internet qui a la chance de pouvoir exercer sa passion dans un domaine très porteur. Depuis que j'ai eu accès à un ordinateur et ensuite à Internet en 1990 dans mon école d'ingénieur, j'ai eu envie de créer des choses qui exploitent la formidable puissance de ces technologies. J'ai commencé par un "shareware" (partagiciel) et un site internet de jeu quand j'étais étudiant puis je me suis retrouvé chez Netscape comme consultant en technologies Internet. Après cette expérience plus qu'enrichissante j'ai pu rejoindre un projet de startup de mesure des usages d'Internet "NetValue" qui fut une vraie aventure avec ses bons et mauvais côtés.

C'est chez NetValue que j'ai découvert les Wikis qu'on a mis en place avec succès, alors que chez Netscape nous avions travaillé sur des outils "plus traditionnels" de partage d'information qui n'avaient pas marché. C'est ce qui m'a donné envie de créer XWiki pour apporter aux entreprises une nouvelle approche du partage de l'information et de la connaissance.

Question : En 2004, l’édition de logiciel libre n’était pas le modèle économique le plus courant… Pourquoi avoir choisi ce modèle, et quelles difficultés cela a engendré ? Comment cela a-t-il évolué 10 ans plus tard ?

Initialement mon projet était de proposer des services sur les logiciels libres que j'avais utilisé, mais finalement j'ai vu les limites des outils que j'utilisais et j'ai décidé de faire mon propre logiciel. Ayant tout appris de ces logiciels Open Source, il m'a semblé naturel de le faire aussi en Open Source.

C'est à ce moment là que j'ai réfléchi à l'aspect business de l'Open Source. J'avais suivi en tant qu'utilisateur l'émergence des technologies Open Source Linux, MySQL, Apache, Tomcat et des entreprises comme Red Hat et JBoss. Surtout, quand j'ai quitté la société après cinq ans je me suis demandé ce qu'on ferait différemment technologiquement si on devait refaire le même projet, et là massivement la décision aurait été de construire sur des technologies libres alors qu'avant notre stack était Sun/Oracle. Je me suis dit que si en 5 ans des acteurs de plus de 15 ans ne sont plus les solutions d'avenir, alors il y a d'autres domaines où cela devait être possible, et c'est à mon sens le cas de la couche supérieure des "applications".

Finalement, mon parcours a fait que j'ai été dans des entreprises qui ont subi une très vive concurrence des leaders en place sur leur marché. Chez Netscape la "guerre" avec Microsoft était palpable tous les jours. Chez NetValue nous avions senti la concurrence des sociétés américaines largement mieux financées que nous alors que sur l'aspect technique nous étions tout à fait au niveau (ce que nous avons pu vérifier une fois racheté par le leader). Ceci a renforcé mon avis, qui est que concurrencer les entreprises de la Silicon Valley sur le même champ de bataille qu'eux est quasiment peine perdue. Cela a renforcé ma motivation à faire du libre.

Cependant ce choix initial m'a fait découvrir un monde complètement nouveau que je ne voyais avant qu'en tant qu'utilisateur. Ce que ce serait la vie du côté du "producteur" de logiciel libre tout en devant faire tourner une entreprise est quelque chose que je n'avais pas du tout imaginé tel que c'est réellement. Je pense d'ailleurs que beaucoup d'utilisateurs des logiciels libres ignorent comment les choses fonctionnent effectivement du côté des personnes qui "créent".

En fait pendant la phase de création je pense que faire du logiciel libre est plus "facile" que de faire du logiciel "propriétaire". On peut se faire aider par des contributeurs, les clients payent des améliorations au logiciel, on n'a pas à "donner" le logiciel pour se faire des références puisque celui-ci est déjà disponible gratuitement.

Mais globalement la difficulté est la même, il s'agit d'abord de faire un bon logiciel et de bien comprendre les besoins des utilisateurs et d'y répondre. Ensuite il faut être innovant face à des solutions venues d'entreprises bien plus capitalisées et dont les logiciels ont plus de fonctionnalités. Pour XWiki une chose qui n'a pas été facile à été de faire à la fois de l'Open Source et de l'innovation. Quelque part il est plus facile de "reproduire" un logiciel propriétaire et de le faire en Open Source que d'innover et de proposer en Open Source quelque chose de nouveau.

Aujourd'hui, dix ans plus tard, la situation est différente. On a une base installée et une certaine renommée. Le logiciel s'améliore en permanence (et la concurrence aussi). La difficulté est de pouvoir financer le fait de "donner" un logiciel, et ce qui est difficile est qu'il faut en même temps développer le logiciel lui-même pour avoir une base installée la plus grande possible et en parallèle développer une offre (qui peut prendre plusieurs formes) qui permet de réaliser du revenu, sans d'un côté dénaturer notre aspect "Libre" et sans nous auto-cannibaliser.

Question: Aujourd’hui, quel est le fil conducteur de XWiki ? Quels sont les sujets qui nécessitent toute la vigilance de l’équipe dirigeante pour pérenniser et développer son activité ?

Ce que j'expliquais précédemment. Continuer à améliorer le logiciel, tout en construisant les offres qui nous permettent de financer le développement de ce logiciel. Ces offres sont d'un côté nos offres de service : développement, formation et surtout le support et ensuite l'offre "cloud" ainsi que les extensions (Applications, Solutions). Nous devons trouver un bon équilibre entre l'investissement sur la technique et sur la partie marketing et la commercialisation. Le logiciel lui-même étant gratuit, nous devons travailler pour bien expliquer la valeur des services et les possibilités qui s'offrent aux clients en faisant appel à XWiki SAS et à ses solutions.

Ceci est aussi lié au fait que ce que propose XWiki reste quelque chose d'innovant et de complexe (ce qui le rend aussi passionnant). Il s'agit d'apporter aux entreprises des outils qui vont les rendre plus efficaces non seulement par l'usage du logiciel mais par le fait que ces entreprises vont changer leurs modes organisationnels et devenir "2.0".

Question : Sur ton profil Linkedin on voit que tu es « business angel » chez Alenty, ce qui m’amène à la question suivante. Aujourd’hui, les startups passent très souvent (systématiquement ?) par des levées de fonds, auprès de business angels, de capital-risqueurs ou d’investisseurs privés, ce qui a pour conséquence, en général, de diluer le capital et de transférer le pouvoir des fondateurs vers les investisseurs. Comment as-tu géré la croissance de XWiki du point de vue financier / perte de contrôle ?

Alors de ce point de vue nous sommes très atypiques. XWiki SAS n'a jamais fait appels à des investisseurs externes. Il y a plusieurs raisons à cela. J'ai d'ailleurs écrit un article sur notre blog sur ce sujet. Pourtant j'ai rencontré des investisseurs potentiels (business angels et VC) et finalement cela ne s'est jamais fait. Une des raisons est que je n'ai jamais été prêt à dire ce que ces investisseurs voulaient entendre i.e. "nous ferons tout ce qu'il faut y compris réduire le libre dans notre offre, pour faire plus d'argent". L'autre aspect est que mon profil "technique" n'a jamais parlé aux investisseurs que nous avons rencontré. Les VC français cherchent des "business men", et je pense que c'est moins le cas en Silicon Valley qui eux cherchent des "visionnaires". AU final ce dont je me suis rendu compte c'est que nous pouvions nous développer sans ces investisseurs, bien évidement plus lentement mais notre modèle Open Source nous a permis de nous développer beaucoup plus progressivement (ce n'est pas le cas je pense du modèle propriétaire qui demande beaucoup plus d'investissement pour amener l'offre à un niveau où les clients sont prêts à payer).

Un autre élément qui me rendait très prudent vis à vis d'investisseurs et qui faisait que je n'étais pas prêt à "brader" le capital de ma société, est que 99% des deals d'investisseurs comme tu le dis bien passent le contrôle de la société des fondateurs vers les investisseurs et finalement presque à la première levée de fonds la société est déjà "à vendre". Personnellement ma passion pour le projet XWiki excluait des deals qui nous mettraient sur un chemin sans retour.

Aujourd'hui nous ne sommes pas contre la notion d'investissements mais nous voulons que ce soient des investissements qui ne remettent pas en cause le contrôle que les employés ont sur la société (XWiki appartient à 100% aux employés et ex-employés, dont 92% à des employés actifs, et 62% contrôlés par moi personnellement). Les employés et actionnaires d'XWiki sont des personnes attachés aux valeurs de l'Open Source. Nous nous intéressons par exemple de près au crowd-funding car nous y voyons un moyen intéressant de nous rapprocher encore de notre communauté.

Question : À propos de la croissance… il me semble que XWiki a deux filiales à l’étranger, en Roumanie et en Algérie. Quelle a été la stratégie de croissance depuis le début, et pourquoi s’être implanté dans ces pays ? Est-ce parce qu’une part importante du chiffre d'affaires est faite dans ces pays ?

En fait ces filiales sont des filiales de production et pas de commercialisation. Je n'aurais pas imaginé quand j'ai crée XWiki d'avoir des employés en Roumanie et en Algérie. Ces filiales sont aussi issues de l'Open Source. Nous nous sommes retrouvé en Roumanie en 2007 après avoir convaincu un étudiant qui avait participé au Google Summer of Code avec XWiki de nous trouver des employés à l'université et de nous ouvrir un bureau. Aujourd'hui nous avons une équipe de 16 personnes la bas, tout aussi passionnée d'Open Source que notre équipe française. L'équipe algérienne, elle, est issue d'une entreprise qui faisait une solution propriétaire basée sur XWiki et qui a fait faillite après 8 ans d'existence. Nous avons embauché leurs meilleurs ingénieurs déjà formés au logiciel XWiki. Ces équipes nous ont permis de nous développer plus vite qu'à Paris et aussi de nous internationaliser. Notre niveau d'anglais est meilleur avec notre équipe roumaine et nous permet de nous adresser aux marchés internationaux.

Du logiciel libre…

Question : Si l’on revient un peu sur le thème du logiciel libre… Là où certains éditeurs font de l’open-core ou du freemium, XWiki a choisi de faire du “vrai” open source en distribuant sa plateforme en LGPL. N’y a-t-il pas des risques à “distribuer gratuitement” sa matière grise sans contrepartie financière, en particulier en phase de démarrage ? A quelles conditions ce modèle “full open source” fonctionne-t-il (ou ne fonctionne-t-il pas) ?

Oui, forcément c'est plus compliqué de tout distribuer en logiciel libre. En même temps il y a un vrai danger avec le modèle Open Core, surtout quand il est combiné avec des investisseurs qui ont le contrôle. Le danger est grand de voir un désengagement progressif du libre pour en final n'investir que dans la partie payante. Pour nous qui sommes indépendants c'est en fait une question d'objectif. Notre objectif, au final, c'est d'abord de faire quelque chose qui compte et ensuite d'en vivre bien. Quand on pose cet objectif on se rend compte de plusieurs choses :

  1. Si notre arrivons à rendre notre logiciel "leader" oui nous aurons des concurrents mais en même temps notre logiciel sera tellement demandé que ceux qui ont le leadership sur le développement du logiciel et aussi le contrôle de sa marque seront très demandés.
  2. Quelque soit ce que nous vendons, nous ne pouvons le vendre qu'à la base d'utilisateurs d'XWiki. Nous avons donc besoin d'un maximum d'utilisateurs et de contributeurs, et pour cela il nous faut distribuer nos logiciels y compris nos extensions le plus largement possible. Si nous fermons une partie des ces extensions, nous réduirons forcément la base installée.
  3. Nous avons la chance d'être dans un métier qui est demandé et où il faut des compétences bien particulières. Ceci fait que malgré le fait d'être en concurrence nous pouvons être concurrentiels d'autant plus que notre équipe dispose des contributeurs qui connaissent le mieux le logiciel.

Un autre point important est que je suis convaincu que l'économie collaborative va prendre une part de plus en plus importante dans notre économie. Même si dans le domaine informatique il est possible de faire des solutions "propriétaires" compétitives, il faut bien se rendre compte qu'il y aura de plus en plus de solutions Open Source de qualité et ce pour une raison assez simple. Chaque ligne de code libre s'ajoute aux lignes de code libre codés précédemment et la limite de ce qu'est capable de faire le libre ne cesse d'aller plus loin. Et ceci ne s'applique pas qu'au code. Pour mieux comprendre le phénomène je conseille à tes lecteurs le livre de Jeremy Rifkin Zéro marginal cost society. Ainsi être 100% open source c'est se positionner dans l'économie de demain et non celle d'hier.

Au final, nous donnons la priorité à la diffusion du logiciel, et nous sommes convaincus que notre position de contributeur principal à XWiki fera le reste, ainsi que l'accès à la marque. D'ailleurs sur ce sujet il est important de noter que la marque est sous mon contrôle personnel et j'autorise son usage double pour la communauté et pour la société.

Question : Comment les clients se positionnent par rapport à cet aspect “tout gratuit” ? N’achètent-ils que des prestations autour de la plateforme XWiki ?

Cela dépend des clients. Il arrive bien sûr que certains aient l'impression que tout doit être gratuit y compris les services. J'ai l'exemple d'un utilisateur qui voulait un single sign-on qui existait déjà mais qui demandait d'être configuré. Comme ce n'était pas assez bien documenté il n'arrivait pas à le faire lui-même, il nous a appelé et nous avons eu l'impression qu'il se sentait "volé" de devoir acheter une journée de service pour qu'on lui fasse l'installation. Ce qui est dommage finalement dans cette vision de l'Open Source tout gratuit est de ne pas se rendre compte que chaque service vendu nous permet de contribuer plus de code libre.

Cependant heureusement nous avons suffisamment de clients qui sont conscients de cela et depuis 10 ans que XWiki existe beaucoup de code, de documentation ont pu être réalisés grâce aux prestations vendues aux client, y compris des développements qui sont mis en Open Source avec l'accord du client, contribuant ainsi à l'enrichissement de la plateforme. Et au fur et à mesure, en particulier avec les contrats de support technique, nous finançons une équipe permanente qui améliore le logiciel et ce qu'il y a autour (documentation, extensions, etc..) suivant une feuille de route publique. Ceci contribue à un produit de plus en plus riche et toujours gratuit.

Ce n'est pas très compliqué à comprendre d'ailleurs, XWiki SAS re-dépense tout son revenu pour se développer et lorsqu'on compare l'investissement R&D de notre société en % du revenu celui-ci est supérieur à celui des sociétés de logiciels propriétaires qui dépensent beaucoup en vente et marketing. Un euro dépensé chez XWiki finira en bien plus grande proportion dans le logiciel qu'un euro chez Microsoft.

Oui bien sûr nous serons heureux en tant qu'investisseurs ou employés de pouvoir générer un dividende ou d'augmenter les salaires, mais nos objectifs sont clairs, il s'agit d'abord de faire la plus belle offre possible, la plus utilisée possible. C'est ce pour quoi nous nous levons le matin.

Question : Qui dit logiciel libre, dit communauté. Peux-tu nous en dire un peu plus sur la communauté XWiki et son mode de gouvernance ? Le projet libre et la société sont-ils distincts ? Qui sont les principaux contributeurs ?

Bien que le nom soit le même, en terme d'organisation la communauté et l'entreprise sont distinctes. La communauté est géré de façon indépendante. Les employés d'XWiki sont de simples participants. Dans tout ce qui est produit sur la communauté le nom "XWiki SAS" n'apparaît que comme contributeur, comme "sponsor" (car nous hébergeons), et sur la page des sociétés qui fournissent du support, où d'autres sociétés apparaissent aussi, en fonction de leur nombre de "committeurs". Le mode de gouvernance de la communauté fonctionne sur le modèle d'Apache avec des votes +1/0/-1 permettant à un unique committeur d'opposer son veto à une décision. Bien entendu XWiki SAS est le contributeur principal, ce qui est renforcé par le fait qu'il nous arrive de recruter des contributeurs, ce qui a été le cas plus d'une fois. Une autre chose qui rend les contributions difficiles est le rythme de développement des employés de XWiki SAS.

Mais malgré cela XWiki SAS n'est pas le seul contributeur et nous sommes heureux de voir beaucoup de pull requests, des traductions, des remontées de bugs et aussi des extensions publiées par des contributeurs. Il nous arrive de contribuer à une extension développée par un contributeur comme l'extension Mocca-Calendar, développée par des Allemands sur laquelle nous investissons du temps de nos équipes.

Notre objectif dans le futur est de toujours rendre plus facile la réalisation et la publication d'extension sur l'extension repository d'XWiki qui permet d'installer des extension en un clic.

Question : En tant qu’éditeur de logiciel libre, vous êtes probablement également utilisateur de logiciels libres. Il y en a-t-il sur lesquels vous contribuez activement ?

Nous l'encourageons en tout cas en interne. Nous faisons des remontées de bugs et des patches sur les bibliothèques java que nous utilisons, par exemple jodconverter, jdeb, kibana et aussi sur maven (notre directeur technique Vincent Massol est un ancien contributeur Maven), mais globalement pour notre usage les bibliothèques qu’on utilise fonctionnent plutôt bien.

Par ailleurs nous essayons aussi de contribuer des modules de façon indépendante à XWiki. Par exemple nous avons publié notre moteur de rendering de page Wiki de façon indépendante d'XWiki (XWiki rendering) et celui-ci est utilisé en dehors d'XWiki (par eXo Platform par exemple). Nous travaillons sur un éditeur Real Time qui peut être utilisé de façon indépendante à XWiki et aussi les WebViewers pour lesquels nous avons fait un module Wordpress.

Nous avons aussi une application "XWiki Glimpse" qui s'intègre avec Nagios et Cacti. Nous avons un module qui intègre Piwik avec XWiki. De manière générale nous essayons de favoriser l'intégration d’autres logiciels libres avec XWiki.

Nos employés sont aussi pour certains des contributeurs ou des créateurs de logiciel libre. Par exemple, Caleb James De Lisle est le créateur de cjdns (un réseau P2P encrypté), un projet qui connaît déjà un certain succès.

Question : Une dernière question : quel conseil donnerais-tu à quelqu’un qui veut se lancer dans l’édition de logiciel libre ? N’est-ce pas une aventure risquée ?

Tout dépend l'objectif qu'on se fixe. Si l'objectif est de faire la super startup qui va gagner beaucoup d'argent, alors le logiciel libre n'est pas la meilleure solution (même s'il y a quelques succès comme JBoss, Spring, etc..). Par contre s'il s'agit de faire une entreprise qui se développe correctement alors non ce n'est pas si risqué que cela. Un avantage du logiciel libre est de permettre de se développer progressivement, avec peu de financement initial.

Cependant il n'est pas facile de créer une entreprise et ce quelque soit le choix, libre ou non. L'entreprenariat est une aventure difficile mais c'est une aventure exaltante. On se retrouve régulièrement face à des difficultés, mais chaque année on peut mesurer le chemin parcouru et se rendre compte qu'on a pu contribuer un peu plus à la communauté du logiciel libre et que l'on peut faire de plus en plus de choses avec ce que nous avons produit.

Conclusion

Question : Le mot de la fin… Une nouveauté XWiki future ou présente à dévoiler ? Un projet de R&D particulièrement vivant à promouvoir ? Un évènement à annoncer ?

XWiki a passé les 10 ans d'existence cet été, et cette dixième année a été le temps d'un renouvellement technologique. Dans la version 6.2 de XWiki Enterprise qui est sorti il y a 10 jours, nous avons mis en place un nouvel habillage HTML5/Responsive basé sur Bootstrap et LESS. Par ailleurs nous avons fait notre première extension développée avec AngularJS et le résultat est assez bluffant (en 2 mois nous avons livré un gestionnaire web de fichiers complet).

Côté R&D, nous développons une technologie d'édition Realtime, qui s'applique non seulement au markup wiki mais surtout au texte riche. Ce que nous avons développé est plus complet et plus avancé qu'Etherpad. L'intérêt est que cette technologie peut être utilisée pour d'autres usages temps réel comme le dessin collaboratif en temps réel. Nous allons continuer dans cette direction et nous avons l'ambition d'aller plus loin dans les usages collaboratifs afin de permettre au logiciel libre de concurrencer les plateformes comme Google Apps et Office 365. Mais ça c'est pour un autre projet dont je ne peux pas encore parler.

Merci beaucoup, Ludovic, pour le temps que tu as pris pour répondre à cette interview. Bonne continuation à XWiki, et pour les lecteurs qui cherchent un job dans le domaine… http://www.xwiki.com/lang/fr/Company/Jobs

Merci à toi. Et même si vous ne voyez pas d'offre qui vous corresponde. Si vous êtes un fan d'Open Source et que vous pensez que XWiki SAS peut être un bon endroit pour vous n'hésitez pas à nous contacter. Même si nous n'avons pas de jobs tout de suite, cela peut changer dans le futur.

Télécharger ce contenu au format Epub

Lire les commentaires

Le logiciel libre dans l'éducation, regard depuis un lycée français

29 septembre, 2014 - 09:05

Je travaille dans un lycée français depuis quelques années maintenant. Étant libriste, j'ai accueilli la circulaire 5608 à bras ouverts. Je vous propose de voir son application dans mon académie, et cela notamment au travers d'un projet de déploiement de tablette tactiles.

Tout d'abord, comment s'organise le bousin informatique d'un lycée ? Et bien, l'académie, l'échelon local du ministère de l'éducation, gère les enseignants, leur formation et l'infrastructure informatique pour la partie administrative. Depuis la réforme du financement des lycées, il y a quelques années, c'est la région qui finance l'équipement en postes et en infrastructure pour les lycéens. Chacune de ces administrations possède ses propres escadres de techniciens mobiles. À noter au passage que la région n'est pas soumise à cette fameuse directive car elle ne dépend pas du ministère de l'Éducation.

L'application côté académie avance timidement : certains documents internes sont en odt, il y a quelques offres de formation interne pour LibreOffice (mais tout de même moins que pour MS Office), j'ai même vu certaines personnes utiliser LibreOffice ; il y a aussi le passage récent au groupware SOGo.
Côté région, les équipes se focalisent pour le moment sur la mise à jour de l'infrastructure, le nettoyage des écuries d'Augias. Mais pas de questionnement sur le libre.

Pour les serveurs, sans surprise c'est principalement du Linux, comme par exemple la distribution spécialisée Kwartz qui a l'avantage de pouvoir être opérée par un non-technicien.
Côté desktop, pas de projet à l'académie, ni à la région. S'il y a bien quelques lycées qui l'ont mis en place, c'est à l'entière charge du responsable informatique local.
Chez les enseignants, certains sont très bien sensibilisés aux tenants et aboutissants du libre, tandis que pour d'autres ce sont seulement « des produits inférieurs car ils sont gratuits… »

Voilà pour le tableau.

Et puis on tombe sur cette vidéo, postée sur le portail de l'environnement numérique de travail (portail mis en place pour tout le monde dans les lycées : élèves, parents d'élèves, enseignants, personnel administratif…), concernant le déploiement des tablettes numériques dans les lycées.
Bon, le projet en lui-même mériterait tout un article, mais dans sa forme, cette vidéo n'est ni plus ni moins qu'une publicité pour HP/Microsoft. Ce qui me fait tiquer c'est que les acteurs sont des responsables de l'éducation et que c'est publié sur un site pédagogique (humm, publicité gratuite). Mais ce n'est pas la première fois que l'on voit ce genre de chose. On notera au passage la sentence que « 99.5% des ordinateurs sont sous Windows dans la région » dans la bouche de la personne qui aurait pu faire en sorte que cela soit autrement.

On retrouve d'ailleurs l'argument l'amalgame classique entre compatibilité et interopérabilité : « comme tout le parc est sous Windows, on va utiliser un autre système de Microsoft », alors que des systèmes hétérogènes peuvent cohabiter s'ils reposent sur une même norme, comme avec les navigateurs web (il me semble que le même argument était déjà présent dans les documents d'Halloween il y a plus de 15 ans).

Un pas en avant, un pas en arrière ? En tout cas, Microsoft a peut-être trouvé là un moyen de rester encore un peu dans le monde de l'éducation. Après le ministère, reste maintenant à sensibiliser les structures régionales.

Télécharger ce contenu au format Epub

Lire les commentaires