Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et FAmSCo. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mardi 13 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le FAmSCo. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour l'une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

• Les nouvelles fonctionnalités de la distribution ;
• Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
• La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
• La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

FAmSCo

Le FAmSCo (Fedora Ambassadors Steering Committee) est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur.

Voici un exemple des thèmes dont il a compétence :

• Gérer l'accroissement des ambassadeurs à travers le mentoring ;
• Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
• Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
• Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
• S'occuper des conflits entre ambassadeurs.

Les 7 membres de cette équipe sont également entièrement élus avec une durée de mandat d'un an. Chaque élection renouvelle le collège par moitié.

Original post of Renault.Votez pour ce billet sur Planet Libre.

Mon PC portable commençait à me faire des misères moins d'un an après son achat. J'ai commencé à avoir quelques problèmes il y a quelques semaines et ça commençait à être de plus en plus gênant. Visiblement les quelques problèmes que j'ai eu auparavant avec un blocage au démarrage n'étaient que les premiers signes (obligé d'éteindre et redémarrer de nombreuses fois la machine).
Le constat est assez simple, le SSD commençait à me lâcher.

Pas le choix, il fallait remplacer ce SSD pour éviter de perdre les quelques données qui étaient présentes et avoir un PC fonctionnel sous la main. Je ressors donc la boîte et la facture du placard pour me rendre au SAV LDLC puisque la machine est encore sous garantie.

J'ai donc acheté un PC portable en décembre 2016, un LDLC Aurore PC5-2-S1 qui remplit parfaitement son rôle et marche très bien sous Debian. En fait, c'est un Clevo N240JU pour les curieux.

Acheter il y presque un an, je passe un coup de téléphone en expliquant le problème (je ne sais pas combien de temps le PC est garanti et si ça s'applique au SSD). On me dit de passer directement au SAV. Une fois arrivé sur place, il y a quelques personnes mais l'attente se fait un peu longue. Enfin mon tour, j'explique donc mon problème et je démarre le PC.
Les messages d'erreurs permettent d'annoncer la couleur. Arrive le moment où je dois entrer ma passphrase. Pas surpris plus que ça, mon interlocuteur me demande si le disque est chiffré. Cela ne présume pas de ses compétences mais ça me rassure. Le temps d'aller faire un tour derrière et demander un avis, il revient pour me dire qu'il y a bien un problème et qu'il remplace le SSD (en même temps les messages d'erreurs continuaient toujours).

Habitué aux SAV et hotline pourris de certaines entreprises, je suis agréablement surpris. Plutôt que de laisser le PC et le récupérer quelques jours plus tard, il a été changé sur place (c'est encore mieux). Quelques minutes plus tard, on revient avec la machine. Du coup, on peut juste constater que le nouveau SSD est reconnu dans le bios mais faudra ré-installer le système pour en savoir plus. Au total, 45min entre le temps d'attente et le remplacement du SSD. On peut faire plus rapide mais je repars avec une machine qui marche et c'est le plus important. J'aurais préféré ne pas avoir de problème mais ça n'a pas été un calvaire pour le faire remplacer.

Pour le coup, c'était le LDLC SSD F7 PLUS 120 GB qui était en cause. Plutôt rapide mais visiblement, c'est pas très fiable.

LDLC vend des PC qui fonctionnent bien sous GNU/Linux et le SAV est plutôt bon. Pour le moment, je vous recommande LDLC pour l'achat de matériel informatique. J'espère qu'ils continueront à tenir cette promesse.

J'en profiterai pour détailler l'installation plus tard.

---

nIQnutn CC-BY

Original post of nIQnutn.Votez pour ce billet sur Planet Libre.

Intégrer des formules LaTeX directement dans Inkscape est quasi indispensable pour les scientifiques utilisateurs de ce logiciel de dessin vectoriel. Il est possible de le faire directement via la menu Extensions → Rendu → LaTeX…. Si cette entrée n’est pas disponible, c’est qu’il manque une dépendance, mais tant qu’à installer celle-ci, profitez-en pour installer Textext, l’extension LaTeX plus complète qui permet de ré-éditer les équations.

La seule chose qui manque à Textext à mon sens, c’est le manque d’aide à la saisie… Une interface telle que celle que l’on trouve sur https://www.codecogs.com/latex/eqneditor.php est très pratique pour les trous de mémoire, bref.

Depuis 2015, bien des choses ont changées pour l’installation de Textext, en particulier, l’auteur original ne maintient plus le projet, on passe donc à Textext de pitgarbe. En particulier, sur les distributions Linux avec un Ghostscript trop récent…

Debian

Ghostscript 9.22 désactive une fonction dépréciée utilisée par pstoedit, on force donc 9.20.

sudo aptitude install -t stable ghostscript{,-x} libgs9{,-common}
sudo aptitude hold ghostscript{,-x} libgs9{,-common}

Installation des autres dépendances :

sudo aptitude install texlive pstoedit pdf2svg python-gtksourceview2 python-gtk2 imagemagick

L’auteur original de Textext ne maintient plus le projet, on passe donc à Textext de pitgarbe :

wget https://bitbucket.org/pitgarbe/textext/downloads/TexText-Linux-0.6.1.tgz -O /tmp/textext.tgz
tar -xvzf /tmp/textext.tgz --strip=2 textext-0.6.1-linux/extension/ -C ~/.config/inkscape/extensions/

Windows

Suivre les instructions du site officiel : https://bitbucket.org/pitgarbe/textext/overview#markdown-header-installation-for-windows

Mac OS X

Suivre les instructions du site officiel : https://tex.stackexchange.com/questions/257147/how-to-use-latex-with-inkscape-mac-os-x/380585#380585

Original post of yeKcim.Votez pour ce billet sur Planet Libre.

Pour la 48ème semaine de 2017, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Windows, pourquoi ne pas lui faire confiance
• Adieu TeamViewer
• Un an après, faisons le point sur wallabag.it
• Un YouTube "libre" à la française
• Facebook poursuit son ambition de remplacer l'État
• Faut-il démanteler Google ?
• Et si on se débarrassait de Google (pour commencer) ?
• PeerTube : les réponses à vos questions techniques !
• Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière
• L’accessibilité n’est plus un luxe !

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Petite présentation

Galera est une surcouche de MariaDB permettant de mettre en œuvre un cluster au dessus du moteur de stockage InnoDB pour permettre un environnement hautement disponible :

• Réplication multi master
• Réplication synchrone
• Chaque nœud du cluster est utilisable pour un accès lecture/écriture
• La réplication est supportée au travers d’un lien WAN et de la latence que ce type de lien peut comporter
• Contrôle d’admission au cluster intégré

Dans une architecture Galera, les clients SQL vont donc attaquer le cluster via un Load Balancer comme HAProxy qui sera lui-même hautement disponible :

Bien évidemment, cela implique quelques limitations :

• Seul le moteur InnoDB est supporté (MyISAM en alpha)
• La DB mysql qui gère notamment les droits n’est pas comprise dans la réplication
• Toutes les tables doivent avoir une clé primaire, il faudra donc vérifier (ou faire évoluer avec les développeurs le schéma de la base)
• Le verrouillage des tables n’est pas supporté
• Cela ne fonctionne que sous GNU/Linux

Enfin, c’est nettement mieux documenté ici.

Préparation du cluster

Pour exposer le principe de mise en oeuvre, je vais partir sur un cluster à trois noeuds, ce qui correspond au nombre minimal de noeuds nécessaire pour éviter un split brain en cas de panne d’un des deux noeuds. Les trois serveurs db1, db2 et db3 sont tous sous Ubuntu 16.04 pour la démonstration.

On commence donc pas installer les paquets sur les trois serveurs :

sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.2/ubuntu xenial main'
sudo apt update
sudo apt -y install mariadb-server

Ensuite, il faut que les instances MariaDB écoutent sur le réseau ce qui n’est pas le cas par défaut et pousser les options nécessaires pour que MariaDB soit compatible avec le mode de réplication on va donc ajouter au fichier /etc/mysql/my.cnf :

[mysqld]
bind-address=0.0.0.0
binlog_format=ROW
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0

Dans ce même fichier, il faut également configurer le cluster. Chaque node doit partager le même nom et la même définition des noeuds du cluster.
Cependant, il faut adapter le nom du node local et son adresse en modifiant chaque wsrep_node_name et wsrep_node_address.

wsrep_cluster_name=MariaDBCluster
wsrep_cluster_address="gcomm://192.168.69.71,192.168.69.72,192.168.69.73"
wsrep_node_name=db1
wsrep_node_address="192.168.69.71"
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_sst_method=rsync

Une fois cette étape passée, il faut initialiser un nouveau cluster via le démarrage du premier noeud, c’est l’étape de boostrap. Cela peut se faire depuis n’importe lequel des nœuds du cluster. Par commodité, ce sera mon noeud db1. La commande suivante va ainsi généré un nouvel UUID de cluster (cela se fait avec le service MariaDB préalablement coupé sur l’ensemble du cluster). La commande galera_new_cluster est revient à exécuter /usr/sbin/mysqld –wsrep-new-cluster.

systemctl stop mysqld.service
galera_new_cluster

Toujours sur db1, vérifions que le cluster est opérationnel et comporte un noeud :

root@db1:~# mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
Enter password:
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Ajout des autres noeuds

Il ne reste plus qu’à démarrer normalement MariaDB sur les autres noeuds db2 et db3 :

systemctl start mysqld.service

Et le cluster doit bien être porté à trois noeuds :

root@db1:~# mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
Enter password:
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Vérifions un peu plus finement l’état de notre cluster en ne gardant que les valeurs qui nous intéressent :

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_%';"
+------------------------------+----------------------------------------------------------+
| Variable_name                | Value                                                    |
+------------------------------+----------------------------------------------------------+
| wsrep_cluster_size           | 3                                                        |
| wsrep_cluster_status         | Primary                                                  |
| wsrep_connected              | ON                                                       |
| wsrep_evs_state              | OPERATIONAL                                              |
| wsrep_incoming_addresses     | 192.168.69.72:3306,192.168.69.73:3306,192.168.69.71:3306 |
| wsrep_local_state_comment    | Synced                                                   |
| wsrep_provider_version       | 25.3.22(r3764)                                           |
| wsrep_ready                  | ON                                                       |
+------------------------------+----------------------------------------------------------+

A ce propos, la page de monitoring galera est particulièrement bien documentée à ce sujet.

Tests

Sur l’un des serveurs, créons une base avec une table et injectons quelques données :

CREATE DATABASE mydb;
USE mydb;
CREATE TABLE clients (
        id INT PRIMARY KEY AUTO_INCREMENT,
        nom VARCHAR(60),
        prenom VARCHAR(60)
);
INSERT INTO clients (nom, prenom) VALUES ('Simpson', 'Homer');
INSERT INTO clients (nom, prenom) VALUES ('Marsh', 'Stan');
INSERT INTO clients (nom, prenom) VALUES ('Smith', 'Stan');

Le contenu doit pouvoir être requêté depuis les deux autres serveurs :

root@db2:~# mysql -u root -p mydb -e "select * from clients;"
Enter password:
+----+---------+--------+
| id | nom     | prenom |
+----+---------+--------+
|  6 | Simpson | Homer  |
|  9 | Marsh   | Stan   |
| 12 | Smith   | Stan   |
+----+---------+--------+

Original post of Morot.Votez pour ce billet sur Planet Libre.