Linuxfr.org

Ces derniers jours, ont été annoncées plusieurs bonnes nouvelles concernant l'utilisation des logiciels libres de bureautique au Royaume-Uni, en France et en Espagne. En France, c'est Toulouse Métropole qui est passé à LibreOffice sur environ 9000 postes. La migration a pris un an et demi et l'économie réalisée (par rapport au coût de la suite bureautique propriétaire) est estimé à un million d'euros sur trois ans.

Au Royaume-Uni, le UK cabinet office a adopté le format ODF (Open Document Format for Office Applications) pour le partage des documents au sein du gouvernement et des institutions publiques. D'autres formats ouverts comme le PDF et le HTML sont également approuvés. En cassant la dépendance avec les formats propriétaires et les logiciels du même acabit, le Bureau du cabinet estime que les économies réalisées seront de l'ordre de 1,2 milliards de livres sterling.

En Espagne, la communauté autonome de Valence confirme ses choix technologiques en publiant une distribution Linux (dérivée d'Edubuntu) qui a été déployée sur plus de 100 000 ordinateurs dans les écoles. Et dans le secteur administratif, LibreOffice est utilisé sur 120 000 postes depuis l'année dernière.

• lien n°1 : Numérama : LibreOffice fait économiser un million d'euros à Toulouse
• lien n°2 : Developpez.com : Le gouvernement britannique adopte le format ODF
• lien n°3 : Silicon : La région de Valence a économisé 36 millions d’euros, grâce à Linux
• lien n°4 : LibreOffice

Vous pouvez éditer cette partie en cliquant sur le crayon !

Télécharger ce contenu au format Epub

Lire les commentaires

Un précédent article a signalé la possibilité jusqu'au 15 septembre 2014 de proposer des idées pour simplifier les démarches administratives en France. Le nombre de propositions grandit et il est important maintenant de voter pour donner de l'importance aux sujets qui concernent la communauté du Libre.

• lien n°1 : Faire une proposition, la commenter, voter
• lien n°2 : L'article précédent et ses commentaires
• lien n°3 : Le Pad de la FSFE
• lien n°4 : Débat public à Bure, le fiasco

Plusieurs propositions favorables (notamment) au Libre ont été retenues, avec difficulté, le système de modération étant difficile à comprendre et ne justifiant pas ses refus (robot ?). Mais face à votre mobilisation, certaines sont passées, par exemple :

• utiliser des formats de fichiers lisibles par tous ;
• faire en sorte que les documents administratifs soient dans des formats ne nécessitant pas de logiciels propriétaires ;
• communications chiffrées et signées par courriel avec l'administration.

Il y en a certainement d'autres à trouver, ce serait intéressant de les signaler ici ou sur le pad de la FSFE afin de savoir pour lesquelles voter et/ou apporter des propositions constructives en commentaires.

Dans les propositions faites et à faire, il y a beaucoup de sujets d'actualité : sécurité, respect de la vie privée (fichier médical centralisé, carte d'identité fusionnée avec d'autres papiers etc.), formation des utilisateurs à l'informatique, informatisation de toutes les démarches, etc…

Centraliser toutes les données privées, faciliter les recoupements, augmenter les dégâts en cas de piratage des serveurs (ça arrive souvent, si, si) vont poser beaucoup de problèmes techniques, politiques, juridiques. Quelles seront les suites données à ces propositions, votes et commentaires ? Est-ce que les associations libristes, la CNIL, les juristes seront aussi consultés ? En général, un tel débat public sert ensuite politiquement à justifier les changements et quelques passages en force. Aussi, vous êtes invités dès à présent à vous exprimer, à voter, à continuer à faire des propositions, à commenter les propositions existantes. Difficile de savoir si c'est la bonne stratégie (le robot qui refuse les propositions n'est déjà pas un bon signe d'ouverture du dialogue) mais dans le doute, il vaut mieux s'exprimer. Quoique parfois, le refus du débat public est aussi une bonne stratégie, comme cela s'est passé à Bure (ville française ayant un laboratoire de recherches sur le stockage des déchets radioactifs en couche géologique profonde).

Télécharger ce contenu au format Epub

Lire les commentaires

La distribution Tails (The Amnesic Incognito Live System) est un live-CD/live-USB visant à protéger votre anonymat et votre vie privée quand vous vous connectez à Internet.
La sortie de la version 1.1 a été annoncée le 22 juillet dernier par l'équipe de développement.

• lien n°1 : Site officiel
• lien n°2 : Télécharger Tails
• lien n°3 : Documentation en français

Sommaire

• Changement majeurs
• Autres changements
  • Correctifs de sécurité
  • Améliations et modifications mineures
• Attendre une version corrective
• Et pour la suite ?

Depuis la dernière dépêche LinuxFR annonçant la sortie de la version 0.20 il y a un peu moins d'un an, la distribution Tails a continué son évolution. La version 1.0 était auparavant sortie le 29 avril dernier. C'était une version de stabilisation et de corrections de bogues/failles de sécurité sans nouveautés majeures.

Tout comme Tor qui a vu son nombre de téléchargements exploser depuis les révélations d'Edward Snowden, le projecteur s'est braqué sur Tails lorsque Bruce Schneier, journaliste travaillant pour The Guardian, a indiqué qu'il utilisait Tails pour travailler sur les documents de Snowden.
Pour rappel, si vous avez cliqué sur un lien ci-dessus, vous êtes probablement maintenant considéré comme un « extrémiste » potentiel par la National Security Agency.

La version 1.1 apporte davantage de nouveautés. Tout d'abord, Tails 1.1 est maintenant basé sur Debian 7 « Wheezy » ce qui a conduit à la régénération de milliers de paquets, la migration vers le mode « fallback » de GNOME 3 ainsi que le remplacement d'OpenOffice par LibreOffice.

Changement majeurs

Cette nouvelle version prend maintenant en charge l'UEFI (Unified Extensible Firmware Interface) ce qui devrait permettre à Tails de se lancer sur les ordinateurs récents ainsi que sur Mac.
Le « camouflage » Windows XP a été remplacé par un « camouflage » Windows 8.

Les modules « guest » de VirtualBox ont été importés depuis les rétroportages (« backports ») de Wheezy. L'ensemble des fonctionnalités ne sont disponibles qu'avec le noyau 32 bits.

Autres changements Correctifs de sécurité

Les logiciels embarqués dans Tails ont été mis à jour ce qui leur permet de profiter des derniers correctifs de sécurité. Le noyau Linux est ainsi présent en version 3.14.13-1, le navigateur web maison s'appuie sur la version 24.7.0 ESR de firefox, les paquets libav sont présents en version 0.8.13 (corrigeant CVE-2014-4609), libxml2 en version 2.8.0 (corrigeant CVE-2014-0191) et dbus en version 1.6.8 (corrigeant CVE-2014-3477, CVE-2014-3532 et CVE-2014-3533), …
Par ailleurs, il n'est maintenant plus possible à l'utilisateur du bureau de passer des arguments à tails-upgrade-frontend, les permissions persistantes sur les fichiers ont été rendues plus sûres, le « handler » du protocole proxy:// de FoxyProxy a été désactivé.

Améliations et modifications mineures

systemd fait son apparition dans Tails. Cependant il n'est pas activé par défaut ; sa présence actuelle facilitera la travail d'intégration pour les futures versions. Python 2.6 n'est plus présent en parallèle de la version 2.7 ; seahorse-nautilus remplace seahorse-plugins, la version stable de scribus remplace scribus-ng ; la version 0.4 de Gobby a laissée la place à la version 0.5 ; le nouveau logo de Tails a été intégré à l'installateur.

Le message « Not enough memory available to check for upgrades » qui pouvait apparaitre lors d'une mise à jour devrait moins apparaitre du fait qu'un peu moins de mémoire est maintenant nécessaire pour lancer ce processus.

La résolution de la fenêtre d'aide du Tails Greeter prend maintenant en compte la résolution de l'écran ce qui devrait arranger les petites résolutions (précédemment la résolution était fixée 800x600).

Whisperback est un logiciel permettant de rapporter des bogues de manière anonyme depuis Tails. La nouvelle version supprime plus proprement les fichiers de log attachés au niveau des données DMI, des adresses IPv6 et des numéros de série.

L'installateur reçoit aussi diverses améliorations (marges cohérentes dans l'interface graphique, installation du chargeur d'amorçage (bootloader) à partir du binaire syslinux présent sur le support cible, …)

Attendre une version corrective

Cette version présenterait plusieurs failles critiques de type 0-day si l'on en croit Exodus Intelligence, une société chargée de détecter les failles logicielles pour ensuite revendre ce genre d'information. La société a posté un message sur Twitter le jour de la sortie de Tails 1.1 pour indiquer que toutes les failles qu'ils avaient repérées étaient toujours présentes.

La société a cependant indiqué qu'elle ne comptait pas divulguer ces informations et qu'elle transmettrait un rapport sur ces failles aux développeurs de Tails afin qu'elles soient corrigées. L'équipe de Tails a confirmé avoir été contactée par Exodus Intelligence en ce sens.

Une version corrective de la distribution devrait donc rapidement faire son apparition dans les semaines qui arrivent.

Et pour la suite ?

D'après l'annonce qui a été faite au moment de la sortie de Tails 1.0, voici ce que l'on peut attendre pour les futures version majeures de la distribution.

Tails 2.0 se focalisera sur la soutenabilité et la maintenabilité. Une grande part du travail consiste à réduire la charge de travail demandée par la création de nouvelles versions de Tails grâce à l'amélioration de l'infrastructure et à l'automatisation des tests. L'objectif est d'être capable de sortir des mises à jour de sécurité le jour même.

Tails 3.0 se focalisera sur les changements internes de Tails pour le rendre plus sécurisé. Cela comprendra un sandboxing (compartimentage) des applications critiques et un durcissement des logiciels.

Télécharger ce contenu au format Epub

Lire les commentaires

LemonLDAP::NG est un logiciel libre de SSO, de gestion des accès et de fédération des identités. Il est publié sous licence GPL. Il est développé par la Gendarmerie Nationale et la société Linagora.

Il implémente de nombreux protocoles standards, tels que Central Authentication Service, OpenID et SAML.

La version 1.4 est sortie fin juin. Cette dépêche présente les principales nouveautés de cette version.

• lien n°1 : Site du projet
• lien n°2 : Captures d'écran
• lien n°3 : Téléchargement
• lien n°4 : Dépêche sur la sortie de la version 1.3
• lien n°5 : Conférence aux RMLL 2014
• lien n°6 : Webinaire OW2
• lien n°7 : Annonce de la sortie sur la forge OW2

Thème graphique

Un nouveau thème graphique basé sur Bootstrap est disponible. Ce thème est adaptatif (responsive), il permet donc d'utiliser le SSO depuis tout type de périphérique (téléphone, tablette, poste de travail).

De nombreux thèmes sont disponibles sur Internet permettant de changer l’apparence d'un site utilisant Bootstrap, facilitant ainsi la personnalisation de l'interface Web de LemonLDAP::NG.

Création de compte

LemonLDAP::NG propose plusieurs libre-services (self service), en particulier la possibilité de réinitialiser son mot de passe lorsqu'il a été perdu. La nouvelle version propose désormais dans le même esprit de pouvoir créer un compte si l'on n'en possède pas.

La démarche est simple, calquée sur la plupart des services similaires proposés par des sites en ligne :
1. L'utilisateur remplit un formulaire avec nom, prénom et adresse mail
2. Il reçoit un message avec un lien sur lequel cliquer
3. Après avoir cliqué, il reçoit un message lui confirmant la création de son compte, avec ses informations de connexion

Bien entendu cette fonctionnalité a peu d'intérêt en entreprise, où les utilisateurs sont déclarés dans un annuaire central et ne peuvent choisir de s'inscrire ou non au service. Toutefois cela offre désormais la possibilité de proposer plusieurs services en ligne protégés par LemonLDAP::NG, permettant à un nouvel utilisateur de s'inscrire s'il ne possède pas de compte.

Utilisation de Mouse

Mouse est un module Perl permettant une manipulation haut niveau des objets. Ce module est utilisé dans la nouvelle version de LemonLDAP::NG, ce qui a entraîné beaucoup de réécriture de code, avec un objectif de meilleure maintenabilité.

Ces changements sont visibles essentiellement des développeurs, mais ils ont tout de même permis quelques améliorations :
- gestion unifiée du cache des sessions, pour tous les types de session (SSO, CAS, SAML, etc.) ;
- centralisation des valeurs par défaut des attributs de configuration ;
- simplification des appels au Handler dans la configuration Apache ;
- support des captcha en cluster ;

Génération des identifiants

C'est le principe du SSO : l'accès aux différentes applications est possible à l'aide d'un jeton, en l'occurrence pour LemonLDAP::NG une clé de session stockée dans un cookie.

Par défaut, les identifiants de session sont générés en MD5 avec une taille de 32 caractères. Cela peut poser des problèmes de sécurité, en particulier si un attaquant tente de découvrir un identifiant de session par force brute. Ce n'est pas spécifique au SSO, ce type d'attaque est possible sur toute application utilisant un cookie de session. Toutefois dans le cas du SSO, la découverte de la session permet l'accès à toutes les applications protégées.

La nouvelle version de LemonLDAP::NG permet de choisir son propre module de génération d'identifiant de session, et propose un module basé sur SHA, créant des clés sur 64 caractères.

SAML

Le mode SSO initié par le fournisseur d'identité (SSO IDP initiated) est désormais disponible. Il permet de générer des URLs sur le portail LemonLDAP::NG (agissant comme IDP SAML) qui transmettent directement une réponse SAML à un fournisseur de service (SP).

Cela permet une authentification en deux étapes (authentification sur l'IDP puis accès au SP) au lieu des trois étapes du processus standard (accès au SP, authentification sur l'IDP puis retour sur le SP).

La nouvelle version de LemonLDAP::NG permet également une configuration plus fine des dates utilisées dans les messages SAML (durée de validité des assertions et des sessions).

Nginx

Depuis ses origines (il y a plus de 10 ans), LemonLDAP::NG a été conçu pour fonctionner avec Apache. Le support de Nginx étant une demande de plus en plus forte, l'équipe de développement a planché sur le sujet.

Une première implémentation du Handler en LUA a été publiée. Cette implémentation ne permet pas de couvrir 100% des fonctionnalités offertes par le Handler standard (gestion des expressions régulières, de l'interception des déconnexion, etc.), c'est toutefois une bonne base de départ pour protéger l'accès à une application derrière Nginx.

Des travaux sont encore en cours sur un Handler Perl pour Nginx, pour l'instant freinés par les manques de l'API Perl de Nginx. Les discussions entre les communautés sont en cours (et toute aide est la bienvenue sur le sujet).

Télécharger ce contenu au format Epub

Lire les commentaires

Crux est disponible dans sa version 3.1 depuis le 16 juillet dernier. Cette distribution, qui a été la principale source d'inspiration à la création d'Arch Linux, suit le principe KISS (keep it simple), dispose d'un système d'init à la BSD ainsi que d'un système de [ports]. C'est une distribution légère ciblant l'architecture x86-64 et des utilisateurs Linux avancés.

Crux, dont la première version date de décembre 2002, n'est basée sur aucune autre distribution et possède ses propres outils pour, par exemple, la gestion des paquets et ports.

Plus d'informations se trouvent dans la suite de la dépêche.

• lien n°1 : Homepage
• lien n°2 : Handbook de la version 3.1
• lien n°3 : Notes de version

Sommaire

• Scripts d'initialisation
• Ports et paquets
• Description: Compression utility using the lzma algorithm, successor of lzma-utils
• URL: http://tukaani.org/xz/
• Maintainer: CRUX System Team, core-ports at crux dot nu
• Installation
• Changements dans la version 3.1

Scripts d'initialisation

Les utilisateurs de systèmes *BSD ne devraient pas être trop dépaysés par Crux. En effet, point de systemd ici mais un système d'init à la BSD.

Le système comporte plusieurs runlevels, tels que définis dans /etc/inittab:

• 0: halt
• 1: mode utilisateur unique
• 2: mode multi-utilisateur
• 3-5: non utilisés
• 6: reboot

Le script de démarrage système est défini dans /etc/rc alors que celui pour l'extinction se trouve dans /etc/rc.shutdown et l'initialisation des modules passe par /etc/rc.modules. Le script pour le mode utilisateur unique dans /etc/rc.single, pour le mode multi-utilisateur dans /etc/rc.multi.

La configuration de base du système se fait via /etc/rc.conf et les scripts des services, par exemple sshd, se trouve dans /etc/rc.d.

Ports et paquets

Le système de paquets utilise des simples tarballs tar.gz, sans métadonnées. Cependant, l'extension .pkg.tar.gz est utilisée afin de permettre de différencier un paquet d'un simple tarball. Les paquets peuvent également être compressés avec bzip2 ou encore xz et dans ce cas là, l'extension est changée en accord (.pkg.tar.bz2 et .pkg.tar.xz).

Les paquets s'installent et se mettent à jour via pkgadd(8), se désinstallent via pkgrm(8) et peuvent se créer via pkgmk(8) tandis que pkginfo(8) permet l'obtention d'informations sur les paquets.

Ce système de paquets simple ne supporte pas, par exemple, la résolution des dépendances. En revanche, un front-end, prt-get(8), est fourni avec le système et permet notamment la résolution des dépendances.

Crux comprend également un système de ports que l'on peut trouver dans /usr/ports. Un port comprend les fichiers Pkgfile, .md5sum et .footprint. Le Pkgfile est en réalité un script shell spécial qui permet la création d'un paquet, un peu à la manière d'un PKGBUILD chez Arch Linux. Un exemple valant mieux que mille mots:
```

Description: Compression utility using the lzma algorithm, successor of lzma-utils URL: http://tukaani.org/xz/ Maintainer: CRUX System Team, core-ports at crux dot nu

name=xz
version=5.0.5
release=1
source=(http://tukaani.org/xz/$name-$version.tar.bz2)

build() {
cd $name-$version
./configure --prefix=/usr \
--mandir=/usr/man \
--disable-nls
make
make DESTDIR=$PKG install

ln -s liblzma.so.$version $PKG/usr/lib/liblzma.so.0 rm -r $PKG/usr/share

}
``Le fichier.md5sumsert donc à stocker la somme md5 du (des) tarball(s) nécessaire(s) à la création du paquet tandis que le fichier.footprint` contient la liste des fichiers et dossiers créés par le port. Évidemment, si des patches ou fichiers de configuration sont nécessaires, ils prendront également leur place dans le dossier du port en question.

Il faut noter que les paquets sont réduits au strict minimum. Ainsi, les fichiers de traduction ne sont pas installés, de même que les fichiers de documentation tels des README, fichiers *.info ou *.html, etc. Seules les pages de manuels sont conservées comme documentation.

L'arbre des ports se synchronise via l'utilitaire ports(8). Ainsi, une mise à jour de son système peut être réalisée simplement via un ports -u && prt-get sysup.

Le noyau Linux est une exception. En effet, il n'existe pas de port pour le noyau Linux. Les sources du noyau se trouvent par défaut dans /usr/src. Par exemple, la version 3.1 de Crux fournit les sources du noyau Linux 3.12 dans /usr/src/linux-3.12.24. L'installation du noyau passe donc par un procédé standard:

$ cd /usr/src/linux-3.12.24
$ make menuconfig
$ make all
$ make modules_install
$ cp arch/x86/boot/bzImage /boot/vmlinuz
$ cp System.map /boot

Pour une mise à jour du noyau, il suffit donc de télécharger les sources depuis kernel.org, de copier le fichier de configuration du noyau et de lancer un make oldconfig suivi d'un make all && make modules_install && make install.

Étant donné que le noyau n'est pas géré par pkgadd(8), il est tout à fait possible de télécharger et installer le noyau de son choix sans rendre la base de données des paquets inconsistante. Par ailleurs, cela n'affecte pas non plus les headers kernel qui se trouvent dans /usr/include/linux et /usr/include/asm étant donné que ceux-ci ne sont pas des liens symboliques vers les sources du kernel mais contiennent une copie des headers.

Installation

Concernant l'installation, point de GUI ou de superflu. Le média d'installation est une image ISO hybride pouvant autant être gravée sur un CD-ROM qu'utilisée pour créer une clé USB amorçable. Une fois démarré sur le média d'installation, l'utilisateur se trouve connecté en tant que root et peut donc procéder à l'installation du système.

Le partitionnement se fait généralement via fdisk(8) suivit d'un mkfs(8). Une fois cela fait, il faut monter la (ou les) partition(s) nouvellement créée(s), par exemple dans /mnt et lancer la commande setup. Cette dernière permet d'installer les paquets nécessaires au système, notamment les paquets de core. Une fois cela effectué, il faut créer un chroot pour finir la configuration de son système. Cela peut se faire de manière traditionnelle mais la commande setup-chroot permet d'automatiser le processus. Une fois dans le chroot, l'utilisateur doit donc définir un mot de passe pour le super-utilisateur, éditer /etc/fstab afin de configurer les systèmes de fichiers, éditer /etc/rc.conf pour configurer le système de base tel que la timezone, le layout du clavier ou encore le hostname et les services à lancer au démarrage. La configuration du réseau passe par l'édition des fichiers /etc/rc.d/net, /etc/hosts et /etc/resolv.conf.
Une fois ceci fait, il est nécessaire de configurer et installer son kernel, tels que décrit dans la section précédente. À noter qu'un fichier .config générique est fourni de base pour simplifier le processus.
Le gestionnaire de démarrage de base par défaut est lilo. Pour autant que l'utilisateur le choisisse, il doit passer par l'édition de /etc/lilo.conf afin de rendre son système démarrable.

Changements dans la version 3.1

La toolchain utilise glibc 2.19.0, gcc 4.8.3 et binutils 2.24.

Le kernel par défaut est le kernel à support à long terme 3.12.24. À noter que depuis la disponibilité de Crux 3.1, la version 3.12.25 est disponible et une mise-à-jour du noyau est donc conseillée.

À noter également que udev a disparu au profit de eudev.

Les détails peuvent se trouver dans les notes de mise à jour ainsi que dans le changelog.

Télécharger ce contenu au format Epub

Lire les commentaires

Le 17 juin dernier est sorti en librairie et sur le Web le livre « Solutions informatiques pour les TPE… avec des logiciels libres » aux éditions D-BookeR (qui d'ailleurs travaille avec des logiciels libres comme DocBook et GNU/Linux comme système). Ce manuel propose des solutions à base de logiciels libres pour tous les problèmes que se posent un gérant de petite entreprise afin de mener à bien son activité.

Sous la direction de Philippe Scoffoni aidé de Sébastien Mirate et moi-même, ainsi que Sandrine Monllor pour ses précieuses relectures, il aborde les thèmes suivants :

• quels logiciels choisir ? introduction sur le logiciel libre et l'importance des formats ouverts ;
• communiquer avec les autres ;
• s'organiser ;
• travailler en équipe ;
• créer son image de marque ;
• administrer sa société ;
• gérer ses données.

Le livre existe donc en version papier, mais aussi électronique. Il ne s'agit pas d'un simple PDF identique à l'imprimé, mais d'un véritable livre électronique enrichi par des vidéos. À noter que les possesseurs de la version papier peuvent visionner facilement chaque vidéo grâce à des QR-codes insérés dans le livre.

Les vidéos sont visibles sur la chaîne Youtube de D-BookeR. Enfin, un site compagnon. accompagne le livre.

• lien n°1 : Solutions informatiques libres (site du livre)
• lien n°2 : Le livre sur le site de l'éditeur
• lien n°3 : D-BookeR
• lien n°4 : Les vidéos du livre

Télécharger ce contenu au format Epub

Lire les commentaires

Ce billet fait suite à la demande de soutien de Timothée Jaussoin sur sa page personnelle: http://edhelas.movim.eu/blog/?post/2014/07/16/Movim-%C3%A0-besoin-d-aide

D'autres billets devraient suivre pour décrire ce qu'il se passe autour de Movim avec notamment les fonctionnalités, une levée de fond sur Kickstarter et bien sûr les dernières nouveautés.

Présentation du projet

Movim pour ceux qui ne connaissent pas, est une application web de réseau social décentralisé, sous licence AGPL, qui se base sur le protocole XMPP, standard de communication déjà largement utilisé.
Le projet est en grande partie développé en PHP, l'interface reposant sur les technologies HTML5.

Movim est compatible avec les bases de données MySQL et PostgreSQL. L'architecture du projet repose sur un système de modules (appelés widgets) lui permettant d'être facilement extensible et modifiable.

Plusieurs dépêches à propos de Movim étaient déjà sorties sur LinuxFr.org. Dont une en particulier qui décrit un peu plus le projet et montre comment installer son propre réseau social avec le couple Movim/Metronome.

• lien n°1 : Page du projet
• lien n°2 : Wiki du projet
• lien n°3 : Launchpad
• lien n°4 : Appel à soutien

XMPP est surtout connu pour ses fonctions de messagerie instantanée, mais sa nature extensible lui permet aujourd'hui d'offrir bien plus que ça. L'extension [Pubsub] permet, par exemple, de mettre en place un puissant système de flux de publication avec la gestion des droits, des abonnements et de la configuration.
L'utilisation de tels services permet dans le cas de Movim de mettre en place un réel réseau social sur lequel vous pouvez poster vos messages, liens et images tout en voyant ceux postés par les personnes que vous suivez.
Movim implémente également le protocole [Jingle] permettant d'établir une connexion multimédia (de type VoIp) entre deux clients web (à l'aide de la technologie [WebRTC]).

Plus généralement Movim possède toutes les fonctionnalités d'un réseau social :

• personnalisation de son profil ;
• gestion des contacts ;
• ajouts d'images dans une galerie personnelle ;
• rédaction de billets avec possibilité d'ajout de liens et d'images ;
• lecture des billets des contacts ;
• chat avec un contact ou un groupe de contacts ;
• audio et vidéo-conférence ;
• respect de la norme Atom pour le format de publication des billets ;
• …

Un autre point fort de l'application est la possibilité donnée à chacun d'installer sa propre instance Movim sur son serveur, conjointement à un serveur Jabber, ou non. Réunir les deux serveurs sur la même machine offre alors l'opportunité de conserver l'ensemble des informations de l'utilisateur sur le même hôte.

Aujourd'hui, Movim est sur le point de sortir la version 0.8. Celle-ci étant une grande étape pour l'application puisque c'est la première version que l'on peut considérer comme pleinement utilisable par le grand public. Le cœur du projet a été entièrement réécrit permettant l'ajout de nombreuses nouvelles fonctionnalités. Pour plus de détails, je vous invite à visiter le site officiel du projet ou d'attendre le prochain billet.

Besoin de soutien

Depuis 2008, Movim est développé par son créateur, Timothée Jaussoin, pseudo edhelas, avec l'aide de sa petite amie. Il est aidé par de nombreux traducteurs à travers le monde qui ont abattu un travail déjà conséquent. Sur la partie développement, Timothée est relativement seul malgré les contributions ponctuelles qui ont pu l'aider jusqu'ici.

Movim cherche donc des développeurs motivés par un logiciel libre, passionnant et avec un but simple : construire et rendre universel les méthodes de communications sociales actuelles. Tous les niveaux et compétences sont les bienvenues et plus il y aura de personnes investies, d'échanges et d'idées, et plus le projet Movim pourra grandir.

Movim est un projet libre, qui se base sur un protocole ouvert et qui a pour seul but de fournir au monde un outil de communication efficace qui se détache des solutions fermées, propriétaires et intrusives, de Facebook ou Google.
Si vous êtes donc motivé et prêt à vous investir dans un projet innovant et unique en son genre, n'hésitez pas à vous manifester. Les contributeurs seront ravis de vous expliquer les différents rouages de l'application et d'écouter vos idées et suggestions.

Pour contacter Timothée et les quelques autres contributeurs, rendez-vous la page du projet :D

Télécharger ce contenu au format Epub

Lire les commentaires

Votre aventure d'hébergeur amateur prend de l'ampleur. Depuis quelques mois, vous avez réussi à gérer plusieurs services de façon transparente, mais maintenant que vous avez de plus en plus d'utilisateurs de vos services, vous vous rendez compte que votre unique serveur web est surchargé et que chaque maintenance provoque des coupures de service que ne comprennent pas vos visiteurs.

Afin de répondre à cette problématique, le plus simple est de multiplier les serveurs : la charge sera répartie entre les différents serveurs et vous pourrez couper un serveur pour une maintenance, sans couper le service associé.

Sommaire

• Étape 1 : digérer quelques concepts
  • Répartition de charge
  • Adresse IP virtuelle
  • Test de vie
  • Ordonnanceur de répartition
  • Un peu de routage
    • Méthode 1 : tout passe par le répartiteur de charge
    • Méthode 2 : faisons travailler le serveur
• Étape 2 : multiplier les serveurs
  • Mon service est-il multipliable ?
  • Mes ressources sont-elles accessibles de partout ?
  • Comment gérer mon routage ?
    • Définition d'un routage statique
    • Gérer le routage direct
• Étape 3 : mon premier répartiteur de charge
  • installation
    • Machines
    • Paquets
    • Paramètres système
    • Configuration de base
    • Configuration de l'instance
  • Ma première adresse IP virtuelle
    • Rappel des pré-requis pour le routage direct
    • Déclaration dans keepalived.conf
  • On s'en fait une deuxième ?
    • Choix de l'adresse IP
    • Ajout de quelques options
    • Choix du test de vie
      • GET d'une URL
      • test personnalisé
• Étape 4 : Exploitons tout ça
  • Extraire des statistiques
  • Manipuler vos adresses virtuelles dynamiquement

Étape 1 : digérer quelques concepts

Afin de simplifier les explications et de coller à ce qui est probablement votre cas d'usage, nous considérerons dans ce tutoriel que nous travaillons dans une infrastructure totalement IPv4.

Répartition de charge

La répartition de charge « est un ensemble de techniques permettant de distribuer une charge de travail entre différents ordinateurs d'un groupe. Ces techniques permettent à la fois de répondre à une charge trop importante d'un service en la répartissant sur plusieurs serveurs, et de réduire l'indisponibilité potentielle de ce service que pourrait provoquer la panne logicielle ou matérielle d'un unique serveur »1 . On distingue deux grands types de répartition de charge :

• la répartition parallèle (« actif / actif ») : plusieurs serveurs offrent de façon simultanée le service, le répartiteur de charge peut envoyer une requête indifféremment à chaque serveur ;

• la répartition séquentielle (« actif / passif ») : plusieurs serveurs sont capables de rendre le service, mais le répartiteur de charge n'envoie des requêtes qu'à un seul d'entre eux ; l'envoi de requête à un autre serveur ne sera fait que si le serveur nominal n'est plus en mesure de prendre en compte les requêtes.

Le mode séquentiel ne permet pas de répartir la charge de travail à proprement parler puisque seul un serveur rend le service à la fois, en revanche cela répond bien au besoin de ne pas interrompre le service en cas de coupure d'un serveur.

Adresse IP virtuelle

Une adresse IP virtuelle (parfois appelée « vIP » ou « serveur virtuel », même si l'usage de ce dernier terme est tombé en désuétude suite à l'arrivée des « machines virtuelles » et le risque de confusion associé) est l'adresse IP d'un service faisant l'objet d'une répartition de charge : l'adresse est dite virtuelle parce qu'elle n'est portée par aucun serveur à proprement parler, mais par un groupe de serveurs, défini dans la configuration du répartiteur de charge. L'adresse IP virtuelle peut être utilisée comme n'importe quelle adresse IP, on doit notamment en autoriser l'accès depuis le pare-feu comme on le ferait pour l'adresse IP d'un serveur.

Test de vie

Puisqu'on demande au répartiteur de charge de n'envoyer les requêtes qu'aux serveurs en état de les traiter, il faut lui donner les moyens de définir quels serveurs sont hors-service. Pour cela, on va configurer un ou plusieurs tests de vie par service, par exemple :

• un ping du serveur cible (test rarement pertinent, mais dans le cadre d'un réseau local non filtré et non routé, on peut considérer que si un serveur ne répond pas au ping c'est qu'il n'est plus en état de rendre le service)

• une connexion TCP sur un port (si le serveur ne permet pas d'ouvrir une connexion sur le port 443, il ne rend à priori pas le service HTTPS)

• un test applicatif (pour un serveur HTTP on peut vérifier qu'un « GET / » ne renvoie pas une erreur 500)

• un test de service (pour un serveur HTTP hébergeant un wiki on peut aller jusqu'à tester qu'une modification de page réussit).

Les tests de vie sont associés à une fréquence d'exécution, qui définira la durée maximale pendant laquelle on accepte qu'un serveur HS continue de recevoir des requêtes (par exemple, si on veut que le serveur ne reçoive plus de requêtes moins de 2 secondes après être tombé, il faut mettre en place un test de vie toutes les secondes), il faut donc veiller :

• à avoir un test de vie plus rapide que votre fréquence d'exécution (si vous lancez un test qui prend 5 secondes chaque seconde, ceux-ci vont s'empiler sur les serveurs) ;

• à ne pas avoir des tests de vie qui deviennent une cause de surcharge des serveurs rendant le service (pour reprendre l'exemple du wiki, si vous avez 30 éditions par jour habituellement en faisant une édition par test de vie vous allez subitement en avoir des milliers).

Ordonnanceur de répartition

Dans le cadre d'une répartition parallèle, chaque requête vers une adresse IP virtuelle est envoyée à un ordonnanceur qui se charge de définir par quel serveur la requête doit être traitée, parmi tous les serveurs détectés comme vivants. Il y a 3 grandes familles d'ordonnanceurs :

• les ordonnanceurs impartiaux : si on a 1000 requêtes réparties entre 4 serveurs, chaque serveur en traitera 250 ; pour cela l'algorithme généralement utilisé est le round-robin (les serveurs reçoivent une requête chacun leur tour), mais certains répartiteurs de charge proposent également des ordonnanceurs basés sur un algorithme aléatoire

• les ordonnanceurs compensateurs : la requête est envoyée au serveur qui la traitera le plus vite (l'algorithme généralement utilisé est d'envoyer au serveur qui a le moins de connexions actives), l'ordonnanceur se charge donc de compenser l'éventuelle lenteur d'un serveur en lui envoyant moins de requêtes ; attention : même si cela n'est pas intuitif, un serveur défaillant traite souvent les requêtes plus rapidement qu'un serveur fonctionnel (un accès refusé à une base de données peut prendre quelques millisecondes quand le traitement d'une requête peut prendre plusieurs secondes), donc ce type d'ordonnanceur favorisera les serveurs défaillants si votre test de vie n'est pas suffisamment bien conçu pour que ceux-ci ne soient plus considérés comme vivants

• les ordonnanceurs déterministes : une fonction de hachage appliquée à la requête reçue permet de définir le serveur qui traitera la requête ; il y a deux principaux types de déterminisme :

  • déterminisme réseau : une même adresse IP source (ou un même couple adresse/port) enverra toujours au même serveur ; à noter que si vous avez de nombreux utilisateurs derrière un même proxy la répartition ne sera pas optimale ;
  • déterminisme applicatif : la même demande (par exemple "GET /login.php") enverra toujours au même serveur (en général la requête est analysée au niveau de la couche application, l'analyse du paquet TCP n'étant pas suffisante pour calculer un hash pertinent).

Les ordonnanceurs acceptent parfois des options :

• gestion des poids : on peut donner des poids différents aux serveurs pointés par une adresse virtuelle afin que ceux-ci soient privilégiés par l'algorithme de répartition (par exemple un ordonnanceur impartial enverra deux fois plus de connexions à un serveur de poids 10 qu'à un serveur de poids 5).

• persistance de session : l'ordonnanceur n'est appelé que pour la première connexion d'un client, puis le répartiteur de charge conserve dans une table de sessions le serveur cible associé à ce client : tant que ce serveur sera vu vivant, toutes les requêtes du client lui seront envoyées.

Un peu de routage

Vous allez donc avoir des connexions qui vont arriver depuis vos répartiteurs de charge vers vos serveurs ; maintenant, il faut se poser une question : comment répondre au client qui a fait la requête ? Il y a deux écoles, chacune ayant ses avantages et inconvénients.

Méthode 1 : tout passe par le répartiteur de charge

Les connexions arrivent au répartiteur de charge ? Qu'elles y retournent ! Cette méthode qui est la plus utilisée consiste à répondre aux requêtes envoyées par le répartiteur de charge au répartiteur de charge lui-même, celui-ci s'occupant de les renvoyer sur Internet. Il y a deux façons de procéder :

• le NAT source : le repartiteur de charge se présente au serveur avec sa propre adresse IP, la réponse est faite naturellement à cette adresse

  • avantages : cela fonctionne avec à peu près tous les services imaginables sans avoir à modifier le serveur cible, si on n'a pas que du logiciel libre côté serveur cela simplifiera grandement les choses ;
  • inconvénients : comme dans le cas d'un proxy, le serveur ne verra pas l'adresse IP d'origine, cela complique la gestion des traces que l'on doit conserver dans le cadre de la loi pour la confiance dans l'économie numérique, le diagnostic des problématiques rencontrées par certains utilisateurs et la mise en place de contrôles d'accès.

• le routage statique : le répartiteur de charge envoie les connexions telles quelles au serveur, mais celui-ci dispose d'un routage statique pour renvoyer toutes les requêtes provenant d'Internet au répartiteur de charge

  • avantages : on n'a pas les inconvénients du NAT ;
  • inconvénients : il faut maintenir une table de routage pour chaque serveur en y listant l'ensemble des réseaux et services auxquels on est susceptible de devoir accéder sans passer par le répartiteur de charge.

Méthode 2 : faisons travailler le serveur

Cette méthode consiste à déléguer au serveur la réponse aux clients, sans repasser par le répartiteur de charge :

• avantage : le répartiteur de charge se comporte comme un simple routeur, il consomme donc peu de ressources système, une machine virtuelle minuscule est suffisante pour rendre ce service ;

• inconvénient : cela nécessite de bidouiller les serveurs pour que ceux-ci acceptent de gérer des communications réseau peu orthodoxes et, en général, et dans ce cas hors système Linux cela s'avère complexe à mettre en œuvre.

Il y a deux façons de gérer ces connexions :

• le routage direct : on fait croire à chaque serveur qu'il est porteur de l'adresse IP virtuelle afin qu'il traite les connexions concernant cette adresse IP comme une connexion à une adresse IP locale ;

• le tunnel IP-IP : le répartiteur de charge envoie la connexion dans un tunnel et le serveur traite les connexions venant de son interface tunnel comme une connexion à une adresse IP locale (on préfère cette méthode au routage direct uniquement quand le répartiteur de charge n'est pas dans le même réseau que le serveur).

Étape 2 : multiplier les serveurs

Maintenant que vous savez que vous pouvez repartir la charge entre plusieurs serveurs, vous allez pouvoir commencer à multiplier ceux-ci : attention cependant à vous poser les bonnes questions.

Mon service est-il multipliable ?

Certains services nécessitant une ressource locale ne peuvent pas faire l'objet d'une répartition de charge. Par exemple, une base SQLite ne garantit sa cohérence que si elle est capable de poser un verrou sur un fichier : un verrou de fichier étant local à un serveur, il n'est pas possible de partager une telle base de données entre différents serveurs. Dans ce type de cas, un répartiteur de charge séquentiel peut devenir intéressant : on peut installer plusieurs serveurs mais demander au répartiteur de charge de n'en adresser qu'un seul à la fois, ainsi toutes les requêtes accéderont à la même ressource locale.

Mes ressources sont-elles accessibles de partout ?

Votre service utilise probablement des fichiers locaux et/ou des informations en mémoire pour fonctionner, il convient donc de s'assurer que celles-ci sont accessibles par tous les serveurs rendant le service. Il faut surtout se poser la question des informations de session que peut porter le service : celles-ci doivent être dans un espace partagé (il est commun de stocker des sessions php dans un montage NFS par exemple) ou dans un outil qui sait gérer la replication (une base de données en réseau par exemple). Si vous ne pouvez pas partager ou répliquer les informations de session entre vos différents serveurs, il conviendra de veiller à ce qu'un client ne change jamais de serveur pendant sa session, soit en utilisant la fonctionnalité de persistance de session de votre répartiteur de charge, soit en utilisant un ordonnanceur déterministe.

Comment gérer mon routage ?

On peut se contenter de faire du NAT et ne pas se poser la question. C'est même la solution préconisée par de nombreux outils de répartition de charge. Cependant, si le NAT ne répond pas à votre besoin pour une des raisons indiquées précédemment (obligation légale, contrôle d'accès, besoin d'investigation) ou tout simplement parce que votre applicatif ou votre protocole ne le gère pas, la mise en place d'une infrastructure répartie peut affecter la configuration de votre serveur.

Définition d'un routage statique

Le plus simple lorsqu'on fait le choix d'un routage statique est de configurer le répartiteur de charge comme passerelle par défaut de votre serveur. Cependant, si votre serveur ne fait pas que répondre à des requêtes en utilisant des ressources locales (par exemple s'il s'agit d'un serveur mail, il doit aussi communiquer avec le reste du monde pour envoyer des mails), il va falloir gérer un routage différent pour ces autres besoins : si votre applicatif le permet vous pouvez envoyer ces connexions à une interface réseau spécifique qui ne passera pas par la passerelle par défaut, sinon il faudra envisager l'usage d'un système de routage intelligent.

Gérer le routage direct

Si vous avez une plate-forme 100% Linux, n'hésitez pas à faire ce choix, il faudra juste autoriser le trafic d'ARP en ajoutant cela dans votre sysctl.conf :

net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.all.arp_announce=2 net.ipv4.conf.eth0.arp_ignore=1 net.ipv4.conf.eth0.arp_announce=2

(il faut le faire pour all et pour l'interface avec laquelle vous communiquez avec le répartiteur de charge) ; si vous n'avez pas prévu de redémarrer votre serveur, vous pouvez forcer la prise en compte de vos modifications :

# sysctl -p

Ensuite, il convient de faire comprendre au serveur qu'il gère l'adresse IP virtuelle. Le plus propre pour faire cela est de déclarer celle-ci comme un alias de l'interface de loopback :

# ifconfig lo:9 lo:4 Link encap:Boucle locale inet adr:192.168.10.9 Masque:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1 Étape 3 : mon premier répartiteur de charge

Linux Virtual Server, abrégé en LVS, est un logiciel répartiteur de charge pour GNU/Linux. Il peut se configurer simplement en ligne de commande, mais afin de gérer simplement la configuration on utilise en général un logiciel spécialisé, dans ce tutoriel ce sera keepalived.

installation Machines

Pour installer ce service, une simple machine virtuelle avec quelques centaines de Mo d'espace disque et quelques dizaines de Mo de mémoire suffira. Et puis comme on veut gérer la redondance en cas de panne, on va même en installer deux !

Paquets

Sur une Debian fraîchement installée avec le système de base, installer le paquet keepalived avec toutes ses dépendances mais sans les paquets recommandés :

# apt-get install keepalived Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets supplémentaires suivants seront installés : ipvsadm libnl1 Paquets suggérés : heartbeat ldirectord Les NOUVEAUX paquets suivants seront installés : ipvsadm keepalived libnl1 0 mis à jour, 3 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 331 ko dans les archives. Après cette opération, 995 ko d'espace disque supplémentaires seront utilisés.

Bien entendu ça fonctionne aussi bien avec d'autres distributions…

Paramètres système

Ajouter le paramètre suivants dans /etc/sysctl.conf* :

# Parametres pour le LVS net.ipv4.ip_forward=1

Charger la configuration :

# sysctl -p net.ipv4.ip_forward = 1 Configuration de base

Source : http://www.keepalived.org/documentation.html

Debian ne génère aucune configuration à l'installation, il faut donc créer le fichier /etc/keepalived/keepalived.conf après l'installation. Pour commencer, il faut y mettre la section globaldefs qui permet de définir la configuration de base :

global_defs { notification_email { georgette@example.com } notification_email_from lvs@example.com smtp_server relayhost.example.com smtp_connect_timeout 30 router_id LVS } vrrp_sync_group VG1 { group { linuxfr } }

Voici l'explication des paramètres :

• notification_email : liste des adresses (séparées par des sauts de ligne) notifiées en cas de changement d'état d'une adresse IP virtuelle (enverra par exemple un e-mail lorsqu'un serveur ne répond plus) ; ne pas mettre cette ligne si on ne désire pas être notifié

• notification_email_from, smtp_server, smtp_connect_timeout : paramètres d'expédition des mails

• router_id : le petit nom donné au service LVS, comme on n'en a qu'un sur la plateforme, on va faire simple en mettant LVS, mais on peut faire plus intelligent

• group : liste des instances déclarées (voir ci-dessous)

Configuration de l'instance

Toujours sans keepalived.conf, on peut créer plusieurs instances ayant chacune leur configuration (par exemple "prod" et "dev"), pour commencer on ne va en créer qu'une, nommée linuxfr :

vrrp_instance linuxfr { state MASTER interface eth0 smtp_alert virtual_router_id 51 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.2.9 } }

Explication des paramètres :

• vrrp_instance : début du bloc de paramètres de l'instance, doit être suivi du nom de l'instance (ici linuxfr)

• state : il s'agit de la seule différence entre la configuration du LVS primaire et du LVS secondaire : l'un d'entre eux doit être "MASTER", l'autre "SLAVE" (c'est pour cela qu'on peut se permettre de metre en place deux serveurs dès le début, la mise en place du second tient à un copier/coller suivi de cette seule modification)

• interface : nom de l'interface surveillée par le service

• smtp_alert : à positionner ou non selon que l'on souhaite avoir des notification par courriel des défaillances

• virtual_router_id : on peut mettre n'importe quel nombre entre 0 et 255, il faut juste qu'il soit différent entre les différentes instances

• authentication, auth_type, auth_pass : identifiants utilisés par les serveurs LVS pour communiquer entre eux, notez cependant que ces informations circulent en clair dans le réseau

• virtual_ipaddress : liste des adresses virtuelles portées par le LVS (une par ligne, 20 maximum) ; c'est la partie que vous oublierez systématiquement de remplir en ajoutant de nouvelles adresses IP virtuelles, et vous perdrez 5 minutes à chercher pourquoi ça ne marche pas

Ma première adresse IP virtuelle

Dans cet exemple, nous déclarons une adresse virtuelle suivante 192.168.10.9 qui renvoie le port 80 vers le port 80 des serveurs 192.168.10.98 et 192.168.10.85.

Rappel des pré-requis pour le routage direct

• vos répartiteurs de charge doivent être dans le même réseau que vos serveurs (sinon configurez votre LVS pour utiliser des tunnels)

• vos serveurs doivent accepter le trafic ARP entre leurs interfaces (cf. paramètres systcl plus haut, si vous n'avez pas la main sur vos serveurs, configurez votre LVS pour faire du NAT source)

• chaque serveur doit croire qu'il porte l'adresse IP du service (ici on déclarera un alias de l'interface de loopback avec l'adresse IP 192.168.10.9)

• l'adresse doit être connue du bloc virtual_ipaddress de votre instance LVS (certes on vous l'a déjà précisé dans le paragraphe précédent, mais on sait que vous allez l'oublier)

Déclaration dans keepalived.conf virtual_server 192.168.10.9 80 { delay_loop 6 lb_algo rr lb_kind DR protocol TCP real_server 192.168.10.98 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } real_server 192.168.10.85 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } } }

• virtual_server : doit être suivi de l'adresse IP virtuelle puis du port

• delay_loop : délai entre deux tests de vie (n'oubliez pas que vous avez deux serveurs LVS, donc vos serveurs se prendront deux fois la charge correspondante)

• lb_algo : l'algorithme utilisé par l'ordonnanceur ; les plus utilisés sont rr (round-robin) et lc (moins de connexions actives) avec leurs équivalents wrr et wlc prenant en compte les poids ; la liste complète des algorithmes est disponible dans http://www.linuxvirtualserver.org/docs/scheduling.html

• lb_kind : méthode d'accès aux serveurs, pour du routage direct on indique '''DR'''

• real_server : doit être suivi de l'adresse IP d'un serveur et du port du service. Il faut autant de blocs real_server qu'il y a de serveurs derrière l'adresse virtuelle

• weight : poids, notamment utilisé pour les algorithmes wlc et wrr ; par défaut, le poids est 1

• TCP_CHECK : test de vie de type ouverture de connexion TCP ; dans cette exemple si une connexion au port 80 prend plus de 3 secondes, le serveur n'est plus considéré comme vivant

On s'en fait une deuxième ?

Vous avez probablement plus d'un service à répartir, donc il faudra créer une adresse IP virtuelle par service.

Choix de l'adresse IP

Pour votre deuxième service vous pouvez soit attribuer une nouvelle adresse IP, soit réutiliser celle d'une adresse de service existante, à condition évidemment que ce soit sur un port différent (et en plus comme ça elle est déjà dans le bloc virtual_servers, vous ne l'oublierez pas pour une fois).

Ajout de quelques options persistence_timeout 60 virtualhost supervision.fr.local quorum 30 hysteresis 2 quorum_up "/usr/local/bin/notify.pl qourum up" quorum_down "/usr/local/bin/start_spare_vm.pl" sorry_server 192.168.10.55 80

• persistence_timeout : mettre un nombre de secondes si on veut activer la persistance de session ; pendant ce nombre de secondes, une même adresse IP source sera systématiquement envoyée au même serveur sans que l'ordonnanceur ne soit sollicité

• quorum : poids total des serveurs actifs nécessaire pour considérer l'adresse virtuelle comme pleinement opérationnelle

• quorum_down : commande à lancer quand le quorum n'est plus atteint, en général on met une commande qui envoie une alarme par sms ou dans l'outil de supervision, mais selon votre architecture vous pouvez aussi envisager de démarrer automatiquement des serveurs supplémentaires, d'activer une version allégée de vos services, etc.

• quorum_up : commande à lancer une fois que le quorum est de nouveau atteint

• hystérésis : différence de poids minimum entre deux appels de commande quorum_up/quorum_down ; par exemple dans notre cas si un quorum_down a été détecté à 29, le quorum_up ne sera pas appelé lors du passage à 30 mais seulement lors du passage à 31 ; cette fonctionnalité permet d'éviter d'appeler les commandes trop souvent lorsqu'on est proche des limites, c'est surtout utile si la commande appelée est particulièrement lourde

• sorry_server : serveur auquel seront envoyées les requêtes si aucun des serveurs pointés par l'adresse virtuelle ne répond ; pour un service web ça pourrait être un mini serveut hébergeant une simple page html d'excuses

• virtualhost : pour un service web, nom de domaine vers lequel seront envoyés les tests de vie HTTP ou HTTPS (cf. paragraphe suivant)

Choix du test de vie

Pour notre première adresse IP virtuelle nous avons choisi un test de vie TCP, mais keepalived permet d'autres tests de vie.

GET d'une URL HTTP_GET { url { path /test_vie.php digest 5f1a4b7e269b7f5ddf6bbce06856c1e8 status_code 200 } connect_port 80 connect_timeout 3 }

Si la page test_vie.php n'est pas dans le virtual host par défaut de votre serveur web, il faudra préciser le paramètre virtualhost dans la configuration de l'adresse IP virtuelle. Le paramètre digest correspond au hash MD5 de la réponse du serveur, on peut le récupérer avec la commande suivante :

# genhash -s 192.168.10.85 -p 80 -u /test_vie.php MD5SUM = 5f1a4b7e269b7f5ddf6bbce06856c1e8

Veuillez noter que :

• on peut ne mettre qu'une seule information entre digest et status_code (code retour HTTP, a priori ce sera 200)

• on peut déclarer autant de blocs url{} que l'on veut dans un test, le serveur ne sera plus vu vivant si un seul d'entre eux échoue

• si on veut faire un test en HTTPS, il faut nommer le bloc SSL_GET au lieu de HTTP_GET (et pour récupérer le digest ajouter l'option « -S » à la commande genhash)

• le digest dépend du contenu de la page, n'ayez pas de contenu dynamique dedans ! Afficher l'heure ou la durée d'affichage par exemple ferait tomber systématiquement le test en erreur ; par contre c'est utile pour valider que tout va bien, par exemple on peut faire une page qui affiche « OK » quand elle arrive à accéder à la base de données, et « KO » sinon : le digest n'étant retrouvé que lorsque la page affiche OK, le répartiteur de charge n'enverra pas de trafic aux serveurs incapables d'accéder à la base de données

test personnalisé

Il est possible d'écrire un script qui sera utilisé pour les checks, par exemple pour tester qu'un serveur LDAP est opérationnel, on fera un script qui fait une requête LDAP :

MISC_CHECK { misc_path "/usr/local/bin/test_ldap.pl 192.168.10.72" misc_timeout 15 # misc_dynamic }

Le script doit simplement renvoyer 0 si le serveur est vivant, et une autre valeur si ce n'est pas le cas. Ici on n'a pas opté pour l'option misc_dynamic (elle est commentée), mais on peut l'activer si on utilise les algorithmes wrr ou wlc, dans ce cas le code retour du script sera interprété ainsi :

• 0: le serveur est vivant, son poids doit rester celui configuré dans keepalived.conf

• 1 : le serveur n'est pas vivant, plus aucune requête ne doit lui être envoyé

• de 2 à 255 : le serveur est vivant, mais son poids doit être changé par la valeur renvoyée moins deux (par exemple si le script a un code retour de 10 le nouveau poids du serveur sera 8)

Étape 4 : Exploitons tout ça

Votre service est configuré, il n'y a plus qu'à le lancer !

# service keepalived start

Keepalived permet seulement de gérer une configuration pour LVS, sans donner d'outils d'exploitation supplémentaires. Pour ensuite suivre la vie de votre service LVS, il faut utiliser la commande ipvsadm.

Extraire des statistiques

L'option --list (abréviations : -l ou -L) permet de lister toutes les adresses virtuelles portées par votre répartiteur de charge avec le nombre de connexions en cours pour chacun des serveurs qu'elles contiennent. En y ajoutant l'option --stats, vous aurez en plus des statistiques réseau :

# ipvsadm -ln -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.10.9:443 rr persistent 1 -> 192.168.10.70:443 Route 1 0 0 -> 192.168.10.85:443 Route 1 0 0 TCP 192.168.10.9:80 rr persistent 50 -> 192.168.10.70:80 Route 1 416 136 -> 192.168.10.85:80 Route 1 48 91

La plupart des outils de monitoring savent interpréter ces chiffres pour sortir des graphes qui peuvent vous être utiles, par exemple voici ce que donne un suivi de nombre de connexions en cours avec munin :

Manipuler vos adresses virtuelles dynamiquement

Si vous avez décidé d'utiliser le paramètre quorum_down pour adapter votre architecture dynamiquement, vous pouvez vouloir ajouter des serveurs dans la liste de ceux portés par une adresse virtuelle dynamiquement. Pour cela, il faut utiliser l'option --add-server (abrégeable en -a), il y a bien évidemment une option --delete-server pour faire l'inverse :

# ajout du serveur 192.168.10.44 # à l'adresse virtuelle 192.168.10.9:80 ipvsadm -a -t 192.168.10.9:80 -r 192.168.10.75 # retrait du serveur 192.168.10.44 # de l'adresse virtuelle 192.168.10.9:80 ipvsadm -d -t 192.168.10.9:80 -r 192.168.10.75

1. Source : Article Répartition de charge de Wikipédia en français - Liste des auteurs ↩

Télécharger ce contenu au format Epub

Lire les commentaires

Si cette nouvelle version met l'accent sur les outils de développement, il faut aussi souligner la prise en charge tant attendue de WebVTT qui autorise le placement à la volée de sous-titres sur les vidéos HTML5, le tout nativement par le navigateur.

À noter que cette version sert de base à la prochaine version ESR (Extended Support Release) qui sera maintenue d'un point de vue sécurité pendant une année. La version ESR est utilisée par les entreprises ne voulant pas requalifier une version toutes les six semaines, le projet Tor Browser ou par certaines distributions GNU/Linux comme Debian ou Tails.

• lien n°1 : Firefox
• lien n°2 : Firefox 31.0 desktop
• lien n°3 : Firefox 31.0 mobile
• lien n°4 : Dépêche de la version précédente

Commun (Desktop & Mobile) Blocage des malwares lors du téléchargement

Lorsque Firefox va télécharger un fichier il va extraire un certain nombre de données :

• l’URL depuis laquelle le fichier est téléchargé, l’URL qui nous a mené à ce lien, ainsi que toutes les URL dans la chaîne de redirection ;
• le hachage SHA-256 du contenu du fichier ;
• n’importe quelle information de vérification obtenue via les API Windows Authenticate ;
• la taille du fichier en octets ;
• le nom de fichier suggéré pour le téléchargement.

Firefox va ensuite vérifier en cherchant si les caractéristiques correspondent aux listes de blocage et d’autorisation. Si le binaire ne correspond ni à un téléchargement de confiance, ni à un téléchargement suspect, Firefox va vérifier la réputation du site via l'API Google Safe Browsing.

Vérification des certificats

La vérification des certificats se fait maintenant via mozilla::pkix. Cette nouvelle bibliothèque est plus robuste (la vérification des certificats n'étant plus fiable) et maintenable (on passe de presque 82 000 lignes de code à seulement un peu de 4 000).

Gestion de Prefer:Safe

Lorsque le contrôle parental est activé sous OS X ou Windows, lors de l’initialisation de la connexion, Firefox va envoyer au serveur une directive Prefer:Safe indiquant, si besoin, que le contenu et les fonctionnalités du site doivent être réduites.

Techniquement, c’est un entête HTTP, c’est donc un système analogue au mécanisme « Ne me pistez pas » (ou Do not track).

Dévelopeurs

Comme souligné en première partie de dépêche, Firefox prend maintenant en charge WebVTT, le format standard du web pour les sous-titres de vidéos HTML5. Par rapport à SRT, il a comme avantage d’avoir des options de formatage plus poussées.

On notera aussi la prise en charge des variables CSS, fonctionnalité qui existe depuis longtemps dans les pré-processeurs CSS comme LESS, Sass ou Stylus.

Firefox Desktop Nouveautés

Un champ de recherche est apparu sur la page d’accueil.
 

Les fichiers Ogg et PDF sont maintenant gérés par Firefox si aucune application n'est spécifiée sous Windows.

Outils développeurs

Les canvas sont fortement utilisés dans les jeux et les animations en général. Un débugueur de canvas fait son apparition, permettant de comprendre, corriger et d'améliorer les contextes WebGL ou 2D.

Un autre débugueur arrive, cette fois-ci pour les extensions. Cet outil permet de débuguer le Javascript utilisé dans les extensions. Il est disponible uniquement pour les extensions sans redémarrage et basées sur le SDK.

Qui n'a jamais eu besoin de sélectionner une couleur dans son navigateur ? Avec l'outil pipette, c'est maintenant possible ! On peut soit sélectionner l’outil depuis le menu développeur pour copier une couleur dans le presse-papier, soit cliquer sur le rond à côté du nom de la couleur d’une propriété CSS dans l’onglet Règles de l’inspecteur pour la modifier.

Modèle de boite modifiable : vous pouvez désormais cliquer sur les valeurs dans l’onglet concernant le modèle de boite pour les modifier et voir le résultat immédiatement.

L'éditeur de code a lui aussi droit à quelques améliorations.

Il est maintenant possible d'afficher la pile d'exécution dans la console, dont le rendu est d'ailleurs personnalisable.

L'option Copier comme cURL a été ajoutée. Concrètement, cela permet de copier une requête réseau sous forme de ligne de commande cURL afin de la rejouer depuis la ligne de commande.

Firefox Mobile Nouveautés

Outre la possibilité de rafraîchir les onglets synchronisés, on notera l'arrivée de nombreuses nouvelles langues : Assamese [as], Bengali [bn-IN], Gujarati [gu-IN], Hindi [hi-IN], Kannada [kn], Malayalam [ml], Marathi [mr], Oriya [or], Panjabi [pa-IN], Tamil [ta] et Telugu [te].

Développeurs

Introduction de l'API Firefox Hub : elle offre aux extensions la possibilité de personnaliser la page d’accueil de Firefox Mobile. Quelques exemples sont déjà disponibles sur le site addons.mozilla.org.

Quelques statistiques

• 484 développeurs ont contribué à cette version, 62 d'entre eux sont de nouveaux contributeurs ;
• 5441 modifications ont été acceptées pour cette version, 726962 lignes ont été ajoutées et 460522 supprimées (soit un delta de 266440).

Prochaines versions

Avec la version 33, l'écran de veille ne se déclenchera plus lorsque vous regarderez une vidéo en plein écran sous GNU/Linux.

Toujours à partir de la version 33 et même si le port vers GTK+3 ne sera pas terminé, il sera désormais possible de créer des paquets expérimentaux pour tester Firefox en GTK+3 (d'autant qu'il sera possible de faire tourner les greffons GTK+2 — comme Adobe Flash, au hasard). Peut-être bientôt dans Debian (vu que c'est notre Mike Hommey national, aka glandium, de la Debian Mozilla team, qui s'y est collé) ? En tout cas des exécutables peuvent d'ores et déjà être téléchargés. Accessoirement, le port vers GTK+3 est un des prérequis pour faire tourner Firefox nativement sous Wayland (mais on n'en est pas encore là).

Télécharger ce contenu au format Epub

Lire les commentaires

L’équipe de développement de SFLphone, client de téléphonie sur internet (User Agent SIP/IAX2), pour GNU/Linux vient d'annoncer la sortie de la nouvelle version 1.4.0. En 2005, Savoir-faire Linux lance le projet de développement d'un softphone : SFLphone. SFLphone est une application libre de téléphonie par Internet, sous licence publique générale GNU version 3, conçue pour fonctionner sur les systèmes d'exploitation GNU/Linux. Elle a été pensée pour les entreprises mais peut être utilisée par tous.

Ce logiciel dispose de fonctionnalités très performantes en téléphonie IP, comme le support des conférences, plusieurs codecs haute définition, et la prise en charge des principaux protocoles de chiffrement des communications (TLS, SRTP/ZRTP). Il permet aussi de diffuser en temps réel plusieurs types de flux vidéo ou de fichiers image et d’activer le partage d’écran en cours d’appel. Il représente aujourd'hui une alternative de plus en plus crédible à Skype.

• lien n°1 : Site web sflphone
• lien n°2 : Article de blog de l'annonce
• lien n°3 : Wiki du projet
• lien n°4 : Bug tracker
• lien n°5 : Liste d'envoi

Deux axes ont été au centre des efforts sur cette nouvelle version :

• Maturité de la visioconférence : parmi les nombreux changements et améliorations, notons que l’implémentation de la vidéo a été retravaillée en profondeur afin d’assurer une meilleure robustesse dans des conditions très diverses et de rendre la configuration plus flexible.
• Améliorations audio : autre fonctionnalité remarquable, la prise en charge du système audio JACK largement utilisé dans l’industrie de l’audio professionnelle. Grâce à l’amélioration de la mise en cache temporaire (buffering), de la latence et du rééchantillonnage audio, la qualité sonore est également sensiblement meilleure.

L'équipe est ouverte à vos retours et vos contributions !

Journal des changements Démon

• support JACK Audio ;
• support vidéo par défaut ;
• fonction de partage d’écran ;
• possibilité de diffuser des fichiers vidéo, images et texte ;
• support de GnuTLS comme alternative à OpenSSL ;
• configuration caméra persistante (par caméra) ;
• changement de source vidéo en cours d’appel ;
• activation ou désactivation de la vidéo pour chaque compte ;
• masquage des pertes de trame ;
• support RTCP ;
• compilations réalisées avec clang.

Client KDE

• gestionnaire de contacts aux fonctionnalités complètes :
  • ajout, modification et gestion des sources de contacts ;
  • suppression de contacts depuis l’interface ;
  • sources de contacts disponibles pour la saisie automatique (auto-completion) ou l’indicateur de présence.
• effets vidéo de base tels que rotation et rapport hauteur/largeur défini ;
• mode vidéo plein écran.

Client Gnome

• vidéo à fenêtre unique ;
• nouvelles icônes ;
• validation partielle des certificats SSL.

Télécharger ce contenu au format Epub

Lire les commentaires

Plasma, l’espace de travail (aussi appelé shell) de KDE, est sorti en version 5.0 le 15 juillet 2014.

Breeze, le nouveau thème graphique offre un visuel plus propre et une meilleure lisibilité. Les flux de travail ont été rationalisés, tandis que les motifs d’interaction globaux sont laissés intacts. Plasma 5.0 améliore la prise en charge des écrans à haut DPI, fournit un espace de travail (shell) complet, et s'adapte à différents appareils.

Sous le capot, on notera la migration vers une nouvelle pile graphique totalement accélérée par le matériel, centrée autour d’un graphe de scène OpenGL(ES). Plasma est construit avec Qt5 et KDE Frameworks 5.

Note : cette dépêche est une traduction d’une partie de l’annonce officielle.

• lien n°1 : Annonce de la sortie de Plasma 5.0 sur le site de KDE
• lien n°2 : Description des changements sur dot.kde.org

Parmi les changements importants Une interface utilisateur mise à jour, modernisée, plus propre et interactive.

Breeze est un nouveau thème pour un espace de travail plat à haut contraste. Il est disponible en deux variantes : clair ou sombre. Des éléments graphiques plus simples et monochromes, et des dispositions centrées sur la typographie offrent une expérience utilisateur propre et claire.

Plasma 5.0 avec le menu Kickoff ouvert et l’application Configuration du Système.

Performance graphique plus fluide grâce à une pile graphique mise à jour

Les interfaces utilisateur de Plasma sont rendues avec un graphe de scène OpenGL ou OpenGL ES, transférant de nombreuses tâches de rendu, couteuses en temps de calcul, vers la carte graphique. Cela permet d’atteindre des taux d’images par seconde plus élevés, et un affichage plus fluide, tout en libérant des ressources pour le processeur principal.

L’écran de verrouillage de Plasma profite lui aussi des nouveautés de la pile graphique.

Autres changements visibles par l’utilisateur Espace de travail convergent

L’espace de travail « Plasma convergent », qui gère le bureau dans Plasma 5.0, peut être étendu à d’autres besoins utilisateur pour d'autres types de plateformes ou d'affichage. Cela pose les bases pour une expérience utilisateur convergeant vers une interface utilisateur adaptée pour chaque appareil.

Cet environnement utilisateur peut être dynamiquement modifié en cours d'exécution, en tenant compte d’évènements matériels tels que le branchement d’un clavier et d’une souris.

Une fois porté sur Plasma 5, Plasma Active sera une interface utilisateur de Plasma, et non plus un binaire séparé.

Lanceurs modernisés

Les interfaces des lanceurs d’applications ont été retravaillées. Parmi les changements, on compte une nouvelle apparence pour le lanceur d’applications Kickoff, un nouveau lanceur plus rétro nommé Kicker, et une nouvelle interface pour KRunner.

KRunner affiche désormais les résultats par groupe.

Amélioration du flux de travail dans la zone de notification

La zone de notification a été nettoyée et arbore désormais une apparence plus unifiée. Moins de fenêtres surgissantes et des transitions plus rapides entre, par exemple, la gestion d’énergie et les paramètres réseau. Ce qui donne un motif d’interaction, sans distraction, dans une plus grande cohérence visuelle.

L’OSD lors du changement de luminosité et la nouvelle zone de notification.

Meilleure prise en charge des écrans à haute densité de pixels

La gestion des écrans à haut DPI a été améliorée. De nombreuses parties de l’UI prennent maintenant en compte la taille physique de l’écran. En conséquence, on obtient une meilleure utilisabilité et un meilleur affichage sur les écrans avec des pixels très petits comme les écrans Retina.

Allez voir la vidéo !

Conclusion

Le résultat est vraiment impressionnant. La transition côté interface et fonctionnalités se fait réellement en douceur, et la nouvelle apparence donne clairement un coup de jeune à l’ensemble. Les technologies utilisées ont fortement évolué, présageant des évolutions très intéressantes pour la suite.

Plasma 5.0 est stable, mais il y aura probablement quelques bugs pour sa première version stable. Ils seront réglées au fur et à mesure, lors des mises à jour mensuelles. De plus, quelques fonctionnalités secondaires sont manquantes. Vous pouvez tester Plasma 5.0 pour vous faire une idée (il peut être testé via l’ISO de Kubuntu générée par le projet Neon ou d'autres).

Concernant la branche 4.x de KDE SC : on peut continuer à l'utiliser. Ses cycles de stabilisation, avec la sortie la semaine dernière des versions 4.13.3 et 4.11.11, ne changent pas. Enfin, la seconde bêta pour KDE SC 4.14, dont la version finale est prévue fin aout, annoncera la dernière version de KDE SC 4.x.

Télécharger ce contenu au format Epub

Lire les commentaires

Lors du deuxième rendez-vous de Pythonistas nantais, nous avons décidé de tenter un rendez-vous régulier, tous les derniers mardi du mois.

Une fois sur deux ce sera avec un format BarCamp en alternance avec un format présentation.

Mardi 29 juillet à 19h nous vous proposons donc un rendez-vous autour de Python, au format Barcamp, à la cantine du numérique de Nantes.

En mode BarCamp, les principes sont simples :

• Nous sommes toutes participantes et nous laissons place à la spontanéité ;
• Chacune amène ses idées et nous nous répartissons en petits groupes ;
• Au programme, pas de programme.

Que vous soyez experte Python, amateure ou juste curieuse, vous êtes les bienvenues !

PS : le féminin est utilisé pour changer un peu mais c’est bien sûr ouvert à toutes et tous

PPS : pour participer ou vous tenir au courant, inscrivez-vous à la liste de diffusion

• lien n°1 : Évènement sur le site de la cantine
• lien n°2 : La liste python nantes

Télécharger ce contenu au format Epub

Lire les commentaires

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

• [Le Courrier picard] Beauvais, capitale mondiale du logiciel libre, l’été prochain
• [Developpez.com] Le choix des logiciels Libres & Open source entraine t-il des gains importants
• [ZDNet] Code à l’ecole: les associations dans le flou
• [Le Monde Informatique] Systematic: bilan et perspectives du soutien au logiciel libre
• [Numerama] L'April cherche des dons pour distribuer son Guide Libre Association
• [Next INpact] Un rapport parlementaire encourage au développement des logiciels libres
• [Le Monde.fr] TiSA: un accord géant de libre-échange en discrètes négociations

• lien n°1 : April
• lien n°2 : Revue de presse de l'April
• lien n°3 : Revue de presse de la semaine précédente
• lien n°4 : Podcast

[Le Courrier picard] Beauvais, capitale mondiale du logiciel libre, l’été prochain

Par Mélanie Carnot, le vendredi 18 juillet 2014. Extrait:

Les geeks de la planète ont rendez-vous à Beauvais l’année prochaine. L’association Oisux et la CCI de l’Oise organiseront les Rencontres mondiales du logiciel libre, en juillet.

Lien vers l'article original: http://www.courrier-picard.fr/region/beauvais-capitale-mondiale-du-logiciel-libre-l-ete-prochain-ia186b0n407085

[Developpez.com] Le choix des logiciels Libres & Open source entraine t-il des gains importants

Par la rédaction, le vendredi 18 juillet 2014. Extrait:

Sur Internet, vous trouverez beaucoup d'études qui démontrent que les logiciels Libres & Open source entrainent des gains financiers importants, qui peuvent aller jusqu'à un facteur de 3. Des institutions ont déjà franchi le pas: la Gendarmerie, la ville de Munich, etc.

Lien vers l'article original: http://open-source.developpez.com/actu/73401/Le-choix-des-logiciels-Libres-Open-source-entraine-t-il-des-gains-importants-Quand-est-il-reellement

[ZDNet] Code à l’ecole: les associations dans le flou

Par Louis Adam, le jeudi 17 juillet 2014. Extrait:

Benoit Hamon annonçait dans le JDD sa volonté d’intégrer l’apprentissage du code à l’école primaire dès septembre. Cette première étape, prévue pour la rentrée 2014, devrait être dévolues aux associations qui proposeront leurs activités sur les temps périscolaires. Mais ces dernières cherchent encore l'appel à projets évoqué…

Lien vers l'article original: http://www.zdnet.fr/actualites/code-a-l-ecole-les-associations-dans-le-flou-39803961.htm

Et aussi:

• [Next INpact] Apprentissage du code: des initiations dès la rentrée prochaine en primaire
• [Next INpact] Initiation des enfants au code: l'appel à projets du gouvernement

[Le Monde Informatique] Systematic: bilan et perspectives du soutien au logiciel libre

Par Dominique Filippone, le jeudi 17 juillet 2014. Extrait:

Après 7 ans d'existence, le Groupe Thématique Logiciel Libre (GTLL) du pôle Systematic Paris Région a permis à 80 projets d'être labellisés et à près de la moitié d'entre eux d'obtenir des financements pour assurer leur développement. Big data, qualité logicielle et technologies de l'après PC constituent les principales priorités de soutien aux projets R&D en logiciels libres de GTLL pour les années à venir.

Lien vers l'article original: http://www.lemondeinformatique.fr/actualites/lire-systematic-bilan-et-perspectives-du-soutien-au-logiciel-libre-58108.html

[Numerama] L'April cherche des dons pour distribuer son Guide Libre Association

Par Guillaume Champeau, le mardi 15 juillet 2014. Extrait:

Alors que le gouvernement a fait de l'engagement associatif la grande cause nationale 2014, l'Association promouvoir et défendre le logiciel libre (April) aimerait faire distribuer auprès du maximum d'entre-elles le guide à destination des associations qu'elle a mis au point pour leur apprendre à connaître les logiciels libres qui peuvent leur être utile.

Lien vers l'article original: http://www.numerama.com/magazine/30004-l-april-cherche-des-dons-pour-distribuer-son-guide-libre-association.html

Et aussi:

• [Association mode d'emploi] Appel à dons pour la diffusion du Guide Libre Association

Voir aussi:

• Donnez pour diffuser le Guide Libre Association

[Next INpact] Un rapport parlementaire encourage au développement des logiciels libres

Par Xavier Berne, le mardi 15 juillet 2014. Extrait:

Un récent rapport sénatorial vient d’apporter un soutien de poids au développement des logiciels libres en France. Il y est en effet préconisé d’encourager le déploiement de ces programmes dont l'étude, la reproduction et la modification est autorisée, et ce à la fois «par leur intégration dans les marchés publics et par l’imposition de standards ouverts». Ce coup d’accélérateur pourrait avoir lieu à condition toutefois «de développer les compétences pour l’utilisation de ces logiciels et standards».

Lien vers l'article original: http://www.nextinpact.com/news/88675-un-rapport-parlementaire-encourage-au-developpement-logiciels-libres.htm

[Le Monde.fr] TiSA: un accord géant de libre-échange en discrètes négociations

Par Maxime Vaudano, le mercredi 9 juillet 2014. Extrait:

Réunis à Paris mardi 8 juillet pour préparer le prochain volet de la régulation financière européenne, les représentants du monde financier ne semblent pas être particulièrement au fait des négociations secrètes qui pourraient demain bloquer toute volonté régulatoire de 50 des plus grandes économies mondiales. Une perspective nommée TiSA, pour Trade in Services Agreement, ou Accord sur le commerce des services en français.

Lien vers l'article original: http://www.lemonde.fr/les-decodeurs/article/2014/07/09/tisa-quand-le-liberalisme-revient-par-la-porte-de-derriere_4452691_4355770.html

Et aussi:

• [Le Figaro] Le poulet au chlore va-t-il débarquer dans nos assiettes?

Télécharger ce contenu au format Epub

Lire les commentaires

CHOUETTE est le nom d’un logiciel libre dont le but est de faciliter les échanges de données transports entre différents systèmes d’information.
Ce logiciel est développé à l'initiative de l'Agence Française pour l’Information Multimodale et la Billettique, rattachée au Ministère en charge des Transports.

• lien n°1 : Site officiel

Contexte : un langage commun pour échanger les données transports

Les systèmes informatiques figurent parmi les outils permettant la planification, l’organisation, la régulation du transport collectif et l’information des usagers. Pour fonctionner et communiquer entre eux, ils utilisent un langage informatique.

La normalisation et les standards précisent des règles d’écriture des données composant ce langage afin de faciliter les échanges d’information entre les différents systèmes informatiques.

Le logiciel Chouette, permet de contrôler la bonne organisation des données selon les règles d’écriture définies par la normalisation et/ou par les standards.

Fonctionnalités de Chouette

Le logiciel Chouette permet de :

• contrôler la conformité des données d’offre de transport avec la norme dite Neptune (Référence : NF P 99506)
• importer / exporter / convertir les données d’offre de transport
• gérer et mettre à jour les données d'offre de transport
• visualiser les données transport sur fond cartographique (exemple : positionnement d’un arrêt de bus)

Un logiciel destiné à plusieurs types d’acteurs

• les collectivités locales, Autorités Organisatrices de Transport (AOT),
• les exploitants des réseaux de transport collectif, et leurs prestataires (bureaux d'étude ou société de services et éditeurs de logiciels),
• les opérateurs/développeurs de services d'information,
• les services de l'Etat,
• etc.

Des apports concrets Pour les collectivités

Le logiciel Chouette contribue à :

• Améliorer la qualité des services d’information multimodale aux usagers
• Favoriser l’innovation de services à partir des données du transport (par exemple, permettre à des acteurs du tourisme de disposer de données transport de qualité pour réaliser une application mobile)
• Améliorer la connaissance de la desserte des transports collectifs sur les territoires

Pour les développeurs de services d’information

Le logiciel Chouette contribue à :

• Faciliter la construction de services basés sur des données multimodales
• Étendre géographiquement les services proposés
• Améliorer la qualité des données de mobilité de leurs services

Utiliser le logiciel Chouette

L'ensemble des informations fonctionnelles et techniques (documentations, code, données…) sur le logiciel Chouette est accessible depuis le site

Usages :

Le logiciel Chouette sous licence CeCILL-B est utilisable gratuitement de plusieurs façons :

• directement en ligne sur le web en créant un compte utilisateur
• sur votre poste : en tant que machine virtuelle à installer
• sur votre serveur (Linux ou Windows) : en tant qu'application web à installer et pour les développeurs :
• en ligne de commande (shell)
• en Ruby
• en tant que bibliothèque Java réutilisable

Les sources sont hébergés sur Github, pour la partie Ruby on Rails et la partie Java.

Extension IRYS (données en temps réel)

D'autres logiciels libres peuvent s'intégrer à Chouette, parmi lesquels IRYS.

IRYS est une extension, développée dans le but de faciliter les échanges de données « temps réel ». En s’adossant à la norme SIRI, IRYS permet de visualiser sur une carte des données transports en temps réel. Une version de démonstration est disponible en ligne et les codes sources sont téléchargeables à partir du site.

Pour en savoir plus…

L'ensemble des informations fonctionnelles et techniques (documentations, code, données…) sur chouette est accessible depuis le site.
Les informations relatives aux normes pour les données du transport collectif sont disponibles à partir d'un site dédié

N'hésitez pas à poser vos questions via le forum ou la rubrique « contact » du site

Télécharger ce contenu au format Epub

Lire les commentaires

Après avoir participé au Café vie privée1 du 5 juillet dernier, FAImaison, fournisseur d'accès à internet Nantais, vous propose un ApéroMaison le 31 juillet à 19h au bar l'Absence (rue La Noué Bras de Fer à Nantes), pour échanger de façon informelle et conviviale à propos d'Internet et ses usages, pour découvrir FAImaison en dehors des réunions hebdomadaires, etc.

L'évènement est ouvert à tous, entrée libre et gratuite.

1. NdM : Nous somme désolé d'utiliser un raccourcisseur d'URL mais un problème avec les URL contenant des accents ne permet pas de mettre un lien direct ↩

• lien n°1 : Annonce dans l'agenda du Libre
• lien n°2 : Article "Lancement des ApéroMaison"
• lien n°3 : Situation du bar l'Absence sur OSM

Télécharger ce contenu au format Epub

Lire les commentaires

ProtonMail est un service de messagerie web sécurisé créé en 2013 par Jason Stockman, Andy Yen et Wei Sun au CERN, situé à côté de Genève en Suisse. À l'opposé de nombreuses messageries web existantes (gmail.com, outlook.com…), ProtonMail chiffre les courriels avant qu'ils ne soient envoyés au serveur. ProtonMail est actuellement en version bêta.

Depuis le 17 juin, une campagne de financement participative a été lancée par l'équipe de développeur dans le but d'atteindre 100 000$. Deux semaines plus tard, le projet avait déjà reçu 200 000$. La prochaine étape est d'atteindre 500 000$ afin que des applications pour iOS et Android soient développées. La campagne se termine le 31 juillet. ProtonMail accepte les paiements par carte bleue, paypal (voir plus bas) et bitcoin.

• lien n°1 : Campagne de financement sur indiegogo
• lien n°2 : Site officiel de ProtonMail

Détail de la sécurité

Les développeurs mettent en avant plusieurs points pour justifier de la sécurité de ce nouveau projet.

Tout d'abord, les serveurs de ProtonMail sont localisés en Suisse et dépendent donc de la législation suisse qui est l'une des plus protectrices au monde concernant les données personnelles (d'après les développeurs). Seul le tribunal cantonal de Genève ou le tribunal fédéral peuvent obliger ProtonMail à fournir les données extrêmement limitées qu'ils ont de leurs utilisateurs.

De plus, les données ne sont pas accessibles. Le système repose sur deux mots de passe. Le premier permet de se connecter à la messagerie. Celui-ci est connu par les administrateurs. Une fois connecté, les données sont envoyées chiffrées à l'utilisateur. Il utilise alors le deuxième mot de passe, connu de lui seul, pour déchiffrer les données au sein du navigateur. Ce deuxième mot de passe n'est pas envoyé au serveur, ni les données déchiffrées. Les données sont donc chiffrées de bout en bout et les serveurs de ProtonMail ne contiennent que des données chiffrées.

ProtonMail n'enregistre aucun log. Il ne sauvegarde aucune métadonnée, que ce soit les adresses IP à partir desquelles l'utilisateur se connecte, ou bien le temps durant lequel un compte est consulté. À noter que Google Analytics est utilisé mais uniquement sur la page d'accueil du site. Il n'est pas possible de faire correspondre les données avec un compte utilisateur spécifique.

Il est possible d'échanger des mails avec d'autres services de messagerie. Dans ce cas, votre correspondant recevra un lien vers le message chiffré qu'il pourra déchiffrer grâce à la phrase de passe que vous lui aurez auparavant communiqué par un moyen de communication sécurisé ;)

Enfin, il existe une option pour activer l'autodestruction des courriels au bout d'un certain délai.

Techniquement, sur quoi ça repose ?

Techniquement, le chiffrement des données est réalisé avec AES et RSA implémenté dans OpenPGP. Par ailleurs, des scripts vérifient régulièrement l'intégrité du code en exécution de sorte à détecter toute modification de celui-ci. Enfin, bien que les données transitant depuis le serveur vers votre navigateur web soient déjà chiffrées, la communication s'effectue via SSL pour ajouter une protection supplémentaire (attaque de l'homme du milieu).
Leur certificat SSL est fournit par SwissSign. Les développeurs publieront prochainement le hash SHA3 de leur clé publique SSL.

Enfin, l'équipe a choisi avec attention l'emplacement physique des serveurs. Ils sont situés dans des centres de traitement de données (datacenters) sécurisés et gardés aux côtés des serveurs de banques suisses. Du côté humain, aucune personne ne possède l'ensemble des mots de passe d'accès ; ils sont conservés par différents personnes de nationalités différentes.

Équivalent

À noter que tutanota, basé en Allemagne, propose le même genre de fonctionnalités.

Paypal pense que c'est illégal

En plein milieu de la campagne de financement, le 30 juin dernier, paypal décide unilatéralement de bloquer les dons pour ProtonMail. Paypal se demandait si ProtonMail était légal et s'ils avaient l'autorisation du gouvernement (lequel ?) pour chiffrer les courriels. Le blocage a été levé le lendemain dans l'après-midi.

Télécharger ce contenu au format Epub

Lire les commentaires

En 2013, l'April a repris l'hébergement de l'Agenda du Libre. Afin de faire évoluer le projet, une nouvelle version a été écrite en Ruby on Rails. Celle-ci utilise actuellement rigoureusement la base de données et l'ergonomie de l'ancienne version.

Vous pouvez retrouver le code source dans son intégralité sur son dépôt Gitorious.

La période étant plutôt creuse et le code prêt, nous avons modifié la configuration Apache httpd pour que le site www.agendadulibre.org pointe vers la nouvelle version.

• lien n°1 : Site de l'Agenda du Libre
• lien n°2 : Code source sur Gitorious
• lien n°3 : Site de l'April

Cette nouvelle version comporte probablement encore beaucoup de bugs et oublis, mais apporte aussi :

• une meilleure accessibilité ;
• la validation W3C ;
• des formulaires html5 ;
• l'internationalisation ;
• un outil d'administration ;
• des dépendances vers des bibliothèques tierces ;
• un système de migration de la base de données ;
• des textes modifiables depuis la base de données ;
• et enfin, des tests unitaires, fonctionnels et de sécurité.

Des tests ont été réalisés ; de plus les flux type RSS et iCal répondent avec les mêmes URL qu'avant, donc idéalement la plupart des sites référençant l'Agenda du Libre français ne devraient subir aucun désagrément.

Le script de soumission automatisée d'événements, en python, a été mis à jour, mais il faudra tout de même que les utilisateurs le téléchargent.

En fonction des remontées reçues, nous verrons pour les versions suisses et belges, qui utiliseront le même code mais une base de données séparée.

Nous sommes joignables par IRC sur #agendadulibre (sur freenode) ou par courriel à devel chez agendadulibre point org si vous avez le moindre souci ou si vous souhaitez des évolutions !

Télécharger ce contenu au format Epub

Lire les commentaires