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

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

Pantheon, Cinnamon, MATE, Budgie, Endless Mobile, Tizen Shell...: un bureau pour les gouverner tous!

29 septembre, 2014 - 06:57

david.g a publié un journal sur divers bureaux tirés de GNOME :

Connaissez-vous le point commun entre Pantheon Desktop, Cinnamon, MATE, Budgie Desktop, Tizen Shell et Endless Mobile ?

La réponse: « ils sont tous issus des technologies du bureau GNOME. »

Pour certains, nés de la discorde provoquée par l'arrivée de GNOME 3, il y a maintenant 3 ans et demi, le changement de paradigme et les manques (supposés?) de cette nouvelle version ont enflammés les débats. Sont alors apparus une petite flopée de nouveaux projets.

Depuis GNOME 3 et GNOME Shell ont bien évolué, il existe même une déclinaison « Classic » du Shell et des dizaines d'extensions pour le modeler à souhait. Mais les dérivés sont toujours là. Il était donc temps d'en faire une rapide cartographie.

Pantheon Desktop

Pantheon est le bureau de la distribution elementary OS, il inclut sa propre suite d'applications (gestionnaire de fichiers, émulateur de terminal, calculatrice, …).

L'objectif de Pantheon est d'être simple et beau, tout un programme!

Cinnamon

Cinnamon est le bureau de Linux Mint, lui aussi inclut sa suite d'applications, comme par exemple Nemo son gestionnaire de fichiers et ses propres outils de configuration.

L'objectif de Cinnamon est de proposer une expérience utilisateur dite "classique" en utilisant les nouvelles technologies introduites par GNOME 3.

MATE

L'autre bureau conçu pour Linux Mint. MATE démarre là où GNOME 2 s'est arrêté.

Son objectif est donc de fournir une expérience utilisateur similaire à celle de GNOME 2 tout en modernisant les bibliothèques logiciels utilisées. Le projet maintient aussi bon nombre d'applications issues de son aîné (gestionnaire de fichiers, émulateur de terminal, visualiseur d'images, …).

Budgie Desktop

Autre distribution, autre bureau : Budgie est le bureau de la distribution Evolve OS avec comme originalité de proposer à l'utilisateur le choix entre deux paradigmes.

C'est encore assez expérimental, mais on peut donc avoir deux expériences utilisateur différentes. Une première qui n'est pas sans rappeler l'expérience utilisateur de Chrome/Chromium OS.

La seconde, plus classique, proche de Cinnamon.

Hormis son lecteur multimédia personnel (Budgie Media Player) il repose sur les applications GNOME 3 et sur les applications Chrome.

Tizen Shell

Présenté par Intel il y a plus d'un an, Tizen Shell devrait proposer une version étendue de GNOME Shell avec des extensions spécifiques. Il y a pour le moment très peu d'infos sur le sujet. Est-il encore développé ? Sortira-t-il avec Tizen OS 3.0 ? Nous verrons.

Endless Mobile

Autre projet lui aussi un peu secret et encore en gestation, il s'agit d'un futur système d'exploitation créé par Endless Mobile.

Un système d'exploitation orienté mobilité et systèmes à faible coût. Il sera basé sur Debian et embarquera une version modifié du bureau GNOME.

Endless semble se donner les moyens de ses ambitions, en ayant, par exemple recruté parmi les meilleurs contributeurs au projet GNOME (Emmanuele Bassi, Cosimo Cecchi, Jasper St. Pierre).

Sans parler du défunt Consort Desktop, mort avec la distribution SolusOS ou d'Unity qui est en passe de s'affranchir des dernières briques qui le reliait à GNOME.

Mais au final, maudite fragmentation ? ou choix bénéfique pour l'utilisateur ?

Télécharger ce contenu au format Epub

Lire les commentaires

Une faille nommée « shellshock »

28 septembre, 2014 - 23:22

« ShellShock », une faille dans l'usage du shell Bash, est sous les projecteurs depuis quelques jours. Le terme est un jeu de mot entre la stupeur propre à l'obusite des combattants de la première guerre mondiale et l'interface système shell. Nous vous proposons des explications sur cet évènement particulier, son périmètre, les conditions de son exploitation, les surfaces d'attaques, et les solutions proposées, déjà mises en œuvre ou à venir. Enfin, une revue de presse sera dressée, cette faille s'étant transformée en évènement.

Sommaire Contexte et histoire

Bash est l'interpréteur par défaut du projet GNU, c'est une amélioration du Shell Bourne, reprenant des idées du Korn Shell (ksh). Il est développé depuis 1988 et n'a cessé de s'améliorer.

Bash est le shell par défaut d'un grand nombre de distributions GNU/Linux, mais pas toutes. Par exemple Ubuntu ne lance pas Bash avec son /bin/sh, mais dash, Bash n'étant disponible que pour l'utilisateur en session interactive. Bash se retrouve également dans Apple Mac OS X et dans Microsoft Windows via Cygwin (SFU, Services for Unix, utilise csh ou ksh).

Quelques explications

Il s'agit d'exploiter un bash-isme, une spécificité du shell Bash, permettant d'exporter une fonction et non seulement une variable. Les autres shells (ksh, zsh, dash, …) ne sont pas concernés par cette faille. Par ailleurs, Bash ne permet pas cet export de fonctions s'il est utilisé avec l'option -p ).

Il est tout à fait normal de vouloir passer des variables d'environnement à un processus enfant.

Mais Bash permet en outre de passer des fonctions vers le processus enfant. Aucun autre shell ne permet cela. Dans ce cadre relativement strict, la sécurité ne pose pas de problème : les droits et contextes d'exécution sont identiques et l'utilisateur, système ou non, est le même. Ceci est documenté, il s'agit de l'option -f de la commande export dans le shell Bash. « It is not a bug, it is a feature », le vieil adage prend ici tout son sens. Nous laissons le lecteur seul juge du bien-fondé de ce bashisme.

Alors s'il n'y a pas de problème, où est le problème ? Le problème se situe dans l'usage de Bash par les autres programmes. Bash est devenu le shell par défaut de certaines distributions, et de nombreux programmes utilisent le shell par défaut pour passer des variables d'environnement entre leurs processus. Le contexte change donc : ce n'est plus un utilisateur local et de confiance qui utilise cela, mais une multitude de programmes, parfois distants.

Ces programmes ne valident pas eux mêmes les données qu'ils donnent à Bash, et ne font souvent que passe-plat. Dans ce contexte, ce qui était auparavant une fonctionnalité se transforme alors en faille. Ceci explique l'ancienneté du problème.

Explications techniques

Une fonction dans le shell bash

#!/bin/bash # déclaration de la fonction d'affichage du message "bonjour vous", nommée mafonction : mafonction() { echo "bonjour vous"; } # exécution de la fonction : mafonction

La même chose, pour passer la fonction à un sous-shell

env mafonction='() { echo "bonjour vous"; }' bash -c 'mafonction;'

On prefixe avec la commande env pour faire tourner un programme dans un environnement modifié. Et à la fin on fait exécuter la fonction par un autre bash. OK ?

La même chose, en détournant l'usage

env mafonction='() { echo "bonjour vous"; }; echo "voici shellshock"' bash -c "mafonction;"

Ici, l'exécution de la fonction mafonction ne se limite pas à un écho "bonjour vous", mais exécute aussi le code echo "voici shellshock" On notera la place du délimiteur '
OK ?

Et en fait il n'est même pas nécessaire d'exécuter la fonction définie :

env mafonction='() { echo "bonjour vous"; }; echo "voici shellshock"' bash -c "true" voici shellshock

Donc, le simple () { :;} suffit à résumer la situation.
OK !

Surfaces d'attaques et exploitabilité

Les conditions de l'exploitation à distance de la faille sont relativement simples :

  • /bin/sh pointe sur /bin/bash ;
  • avoir SELinux désactivé ou non configuré ;
  • avoir un service qui écoute le réseau et qui va exécuter bash.

L'exploitation de cette faille est très simple, et de nombreux preuves de concepts et exploits circulent actuellement sur Internet. Voici une liste non-exhaustive des logiciels qui peuvent être utilisés en passe-plat :

  • dhclient ;
  • apache, via mod_cgi (et sans mod_security correctement configuré) ;
  • exim ; postfix ; qmail ; procmail ;
  • OpenVPN ;
  • stunnel ;
  • probablement de très nombreux logiciels privateurs …
  • SIP, FTP, probablement d'autres …

Preuves de Concept
Un projet hébergé sur github rassemble une série de POC à cette adresse

À noter que SELinux ne va pas bloquer un usage de « shellshock », il va cependant en réduire fortement les possibilités d'exploitation. Par exemple le contexte httpd_sys_script_t est attribué à tout CGI, contexte qui ne permet l'écriture que dans … /tmp! Le lecteur trouvera des explications complètes sur le blog de Dan Walsh à ce sujet.

Ne sont donc pas concernées : toutes les distributions ayant un autre shell que Bash. Toutes les distributions ayant SELinux activé bénéficient d'une protection contre des exploitations de ce type. Mais également : tous les matériels embarqués et objets connectés, contrairement à ce que des articles de presse affirment, car ces matériels utilisent la plupart du temps busybox et son implémentation inline de Bash n'est pas vulnérable. Ne sont pas concernés non plus les téléphones portables (pas plus les Android que les iPhones). Les "box" internet ne le sont pas davantage, ni les télévisions, ni les lecteurs de salon, les autoradios, ni les avions, drones, missiles, sous-marins… Bref, nous avons eu le plaisir de lire un peu n'importe quoi sur le sujet et la revue de presse contient quelques jolies perles.

NdM : le fabriquant de NAS QNAP vient d'alerter ses utilisateurs (cf article Next INpact)

Chronologie des évènements
  • Stéphane Chazelas rapporte le problème à Redhat (bug déclaré le 14 septembre) ;
  • Le CVE-2014-6271 lui est attribué ;
  • Le 24 septembre, ce CVE est rendu public et un premier correctif est mis à disposition ;
  • Le jour même la communauté pointe l'insuffisance de ce correctif ;
  • Le CVE-2014-7169 est alors ouvert et attribué à Tavis Ormandy ;
  • Le 27 septembre le second correctif est publié
Solutions mises en œuvre Correctifs disponibles et annonces des distributions La faille, CVE-2014-6271
  • Le test :
    env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test" Ne doit pas retourner le terme "vulnérable", quelque soit le formattage retour.

  • Les annonces :

Le second problème, CVE-2014-7169
  • Le test :
    cd /tmp; rm -f echo; env 'x=() { (a)=>\' bash -c "echo date"; cat echo doit retourner que le fichier "/tmp/echo" n'existe pas.

  • Les annonces :

Les CVE-2014-6277, CVE-2014-7186 et CVE-2014-7187 ne sont pas publics à ce jour (infos chez Redhat 0, 1 et 2).
  • D'autres correctifs sont à venir.
mod_security, le filtrage

Mod_security est un pare-feu applicatif pour le serveur Apache. Il peut être configuré pour filtrer certains caractères et expressions régulières. C'est donc un moyen efficace pour se prémunir contre le principal vecteur d'attaque : les scripts CGI. Si vous utilisez Redhat, vous pouvez l'installer ou le mettre à jour : il contient les règles tout prêtes pour filtrer « shellshock ». Ces règles sont de types : SecRule REQUEST_HEADERS "^\(\) {" & request_line.

Le cas FreeBSD

Le projet FreeBSD a décidé de désactiver la possibilité d'importation de fonction de Bash. Le système FreeBSD n'utilise pas Bash comme shell par défaut, mais tcsh, Bash n'étant même pas inclus dans une installation de base. Mais pour prémunir de tout problème lié à un changement de shell par défaut, le projet a décidé de supprimer la fonctionnalité incriminée, avec ce message laconique : « cela retire le risque de nouveaux problèmes conduisant à l’exécution de code, et le risque pour les scripts suid, aussi pour les applications mal écrites qui ne nettoient pas leurs environnements » Radical.

Revue de presse

Après les annonces sécurité et la réaction des projets (Bash, FSF - traduite en français par l'April), la presse spécialisée puis la presse généraliste ont multiplié les articles : pire que la faille Heartbleed ? (Slate.fr, LMI, Silicon.fr, L'Express, 20minutes, HuffingtonPost, New Zealand Herald), « panique » (Courrier International), « mégafaille » (01Net), « horrible » (ZdNet), « premières attaques » (01net), « plus grande menace de l'histoire du web » (ParisMatch, si si), « 500 millions de serveurs web vulnérables » (La Tribune, Washington Post), « Google et Amazon ont patchés » - super on est sauvés alors - (WallStreetJournal), d'autres failles Bash à prévoir (ArsTechnica), « ver fou ShellShock » (Wired ou le blog de R. Graham), « internet bâti sur de la glace fine » (Financial Times), etc.

Conclusion

D'une rencontre entre une fonctionnalité et des usages nait une faille qui fait grand bruit. Bruit généré par l'importance du problème, certes, mais également par le manque de discernement et le FUD autour. Ce qui met en valeur la place qu'ont pris les Logiciels Libres dans nos vies quotidiennes, sans que cela se voie. Il aura fallu moins de 4 jours entre la publication du problème (à ne pas confondre avec le signalement initial aux équipes sécurité) et sa résolution. Peu d'éditeurs peuvent se targuer d'être aussi rapides sur la résolution d'un problème de ce type et sur la transparence pour l'accès à l'information.

Dans le même temps, l'inquiétude de savoir que cette possibilité existe depuis de nombreuses années est légitime. Et elle renforce la nécessité de participation. Combien d'éditeurs de solutions s'appuient sur des briques libres sans jamais rien verser aux projets ?

Mettez et maintenez vos systèmes à jour! Et ne pensez pas qu'un programme qui n'a pas connu beaucoup de failles est forcément très sûr, peut-être que personne ne l'avait vraiment regardé jusque là.

Télécharger ce contenu au format Epub

Lire les commentaires

Atelier « Découverte des Logiciels Libres : Scribus » le 11 octobre 2014 à Marseille

28 septembre, 2014 - 14:18

L'association CercLL en collaboration avec Yves Specht vous invite à l' Atelier du Samedi Libre qui se déroule le samedi 11 octobre 2014 de 14h30 à 17h30, à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille.

Atelier « Découverte des Logiciels Libres : Scribus » Deuxième séance

Scribus est un logiciel libre de Publication Assistée par Ordinateur, distribué sous licence GNU GPL. Il convient pour la réalisation de plaquettes, de livres et de magazines. Scribus est multiplate-formes.

Nos ateliers se déroulent, en général, sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé. Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.
Nous avons décidé de nous adresser à un public débutant qui cherche à mieux connaître son ordinateur et les applications les plus courantes que tout un chacun utilise.

Prérequis

Les personnes qui veulent participer à nos ateliers devront s’inscrire à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille Fabulerie ou sur notre site CercLL au http://cercll.wordpress.com/contact/ L'atelier n'aura lieu que si 4 personnes au moins sont inscrites. L’inscription équivaut à un engagement moral de participation. Une participation de 2 euros est demandée. L'adhésion à l'association est de 20 euros annuelle

Entrée Libre. Tout Public. Plan d'accès

Télécharger ce contenu au format Epub

Lire les commentaires

Réunion mensuelle Chtinux le 30 septembre 2014 à Lille

28 septembre, 2014 - 00:00

L'association Chtinux propose sa réunion mensuelle autour du logiciel Libre (évidemment), le mardi 30 Septembre à partir de 20H au Café Citoyen de Lille.

Aussi, ce sera l'occasion de discuter de venir rencontrer les membres de l'association, en discuter et/ou adhérer à celle-ci en cette rentrée 2014, autour d'une consommation 100% bio!

N'hésitez pas à faire passer le mot, et venez nombreux!

NdM : on imagine que les discussions porteront aussi sur les gaufres et Cafougnette et sur le débriefing de la braderie de Lille.

Télécharger ce contenu au format Epub

Lire les commentaires

Hackathon Nao à la Cité des sciences de Paris - 24 au 26 octobre 2014

27 septembre, 2014 - 23:40

vincent14 a écrit un journal sur le Hackathon Nao à venir à la Cité des Sciences de Paris - 24 au 26 octobre 2014 :

Il s'appelle Nao, ce petit robot humanoïde mesure une cinquantaine de centimètres, il tourne sous Linux et se programme en C++, Python, Java, MATLAB, Urbi, C, .Net ou avec des boites d'actions dans un logiciel de programmation graphique.

Il sera à la Cité des sciences et de l'industrie de Paris les 24, 25 et 26 octobre 2014 pour vous ! Un concours de création d'application s'y tiendra pendant trois jours, pour vous donner l'occasion de l'utiliser en équipes de 5 et de créer une première application.

Les inscriptions vont jusqu'au 1er octobre, soit mercredi prochain.

Je n'ai vu aucune limite d'âge, l'idée étant de rassembler le plus de corps de métiers différents autour d'une première approche de la robotique grand public.

Point de vue licence, le robot n'est pas Open Hardware mais son OS et son framework sont Libres. Certains outils de dev sont proprio (par exemple le logiciel de dev graphique). Je suppose que la Cité des Sciences publiera tout le contenu produit au cours des 36h sous licence Creative Commons (NdM: By Sa 3.0 pour le projet de vincent14), comme l'an dernier, car ce sont eux qui organisent le hackathon.

Ayant déjà participé à la première édition, je vous propose de lire mon billet de feedback, j'en étais très content.

L'esprit est de rendre accessibles des machines à 12k€ l'unité, chose que tout étudiant est loin de pouvoir imaginer chez lui avant un certain temps. Les alternatives Open Hardware ne sont d'ailleurs pas beaucoup moins chères, car la motorisation se compose de puissants servo-moteurs de précision très coûteux (200€ pièce pour un Darwin-OP de mémoire, et il en a un paquet).

Je vous invite à venir partager vos idées, apprendre des autres et donner de votre personne pour faire émerger des trucs sympa :)

Télécharger ce contenu au format Epub

Lire les commentaires