URL: https://linuxfr.org/users/trim/journaux/mes-activites-open-sources-libres-recentes-8e6215ca-9cbc-4837-8b10-83660b378e69 Title: Mes activités open sources / libres récentes Authors: Adrien Dorsaz Date: 2019年01月10日T22:06:35+01:00 License: CC By-SA Tags: rapport, activité, open_source, debian et firefox Score: 47 Cher journal, Toujours dans l’idée de parler des projets _open source_ auxquels j’ai porté de l’intérêt, j’ai décidé qu’il était temps de refaire un journal, comme [en mars 2018](https://linuxfr.org/users/trim/journaux/mes-activites-open-sources-libres-recentes). # ExchangeCalendar Comme je le prévoyais au printemps, un gros travail de fond a été nécessaire pour pouvoir réussir à faire tourner l’extension avec Thunderbird 60. J’ai débuté quelques essais de migration automatique à gros coups de `grep` et `sed` pour mettre à jour tout le code JavaScript vieillissant. Seulement, il y avait vraiment beaucoup de code à mettre à jour et je n’étais pas hyper‐confiant sur ces mises à jour automatiques de syntaxe, car les changements d’écriture des boucles JavaScript font que les itérateurs risquent de changer de nature. J’allais donc abandonner le maintien de cette extension, mais, entre temps, [John Bieling](https://github.com/jobisoft), le développeur de l’extension [TbSync](https://addons.thunderbird.net/fr/thunderbird/addon/tbsync/) a ouvert une [requête](https://github.com/ExchangeCalendar/exchangecalendar/issues/182) de collaboration entre nos deux projets ! En effet, TbSync était à l’époque capable de ne gérer que les synchronisations avec Exchange via les API ActiveSync, mais comme il l’explique dans son rapport, le logiciel a toujours été prévu pour ajouter d’autres types de synchronisation avec un code commun pour l’interface avec Thunderbird et l’extension Lightning (les calendriers et événements dans Thunderbird). À ce moment là, il était justement en train de réussir à rendre sa propre extension compatible avec Thunderbird 60 et il était en train d’ajouter la prise en charge de nouveaux types de synchronisation (CalDav et CardDav) à son module. Suite à sa proposition, j’ai essayé de reprendre le code d’ExchangeCalendar et de l’adapter à TbSync. L’idée était très bonne, car ça permettait de réduire énormément la surface de code à implémenter dans ExchangeCalendar uniquement à la partie _back‐end_ du protocole Exchange Web Services, mais toujours avec un minimum en frontal pour configurer les comptes et choisir les dossiers à synchroniser. Par la suite, après avoir pris mes vacances en juillet, j’ai décidé de complètement arrêter mes contributions à ce projet bien trop conséquent pour ma personne seule et mes compétences. Comme j’essaie de l’expliquer dans [mon message](https://github.com/ExchangeCalendar/exchangecalendar/issues/182#issuecomment-407685445), je pense que la mutualisation des codes est vraiment la bonne voie à prendre, mais je suis clairement en dépression, je ne pourrai pas assumer cette tâche et il me faudra du temps pour peut‐être un jour revenir aider la communauté. 😕 Ce n’était pas une décision évidente à prendre et à exprimer, mais finalement, le choix était très bon, car la communauté d’Exchange Calendar s’est réveillée et, _[llange](https://github.com/llange)_ a réussi à reprendre mes essais du printemps et à faire [fonctionner](https://github.com/ExchangeCalendar/exchangecalendar/pull/188) l’extension avec Thunderbird 60 ! Merci beaucoup à lui. 👏 Finalement, j’ai réussi cet hiver à reprendre son travail et à proposer quelques petites corrections qui permettent de faire fonctionner au mieux l’extension avec Thunderbird 60 (surtout la partie carnet d’adresses que j’utilise tous les jours). # Home Bank Comme écrit plus haut, j’étais déprimé cet été et j’avais besoin de revoir l’organisation de ma vie personnelle et professionnelle. Comme pour tout le monde, l’organisation familiale se prend à base de budgets plus ou moins clairs et explicites. Pour avoir une bonne idée de ce que je pouvais prendre comme décision, j’ai eu la motivation de reprendre le code de Home Bank pour tenter de proposer une nouvelle interface de gestion des budgets avec un résumé annuelle et mensuel affiché en direct (comme proposé par un autre utilisateur). Comme je vous l’avais [raconté cet été](https://linuxfr.org/users/trim/journaux/forker-ou-ne-pas-forker), c’était la première fois que j’ai été confronté à un projet _open source_ dont le code en développement n’était pas accessible. Merci encore pour vos éclaircissements et, finalement, j’ai reçu une réponse du développeur du projet : il est intéressé par la fonctionnalité et il espère pouvoir l’intégrer dans une future version. Comme vous l’aviez imaginé, le projet est un hobby auquel il s’y consacre quand il a du temps (ce qui n’était pas le cas avec la rentrée scolaire) et, du coup, c’était simplement pour ça qu’il fallait que j’attende plus. Il m’a expliqué également que le code disponible sur le PPA était vraiment très proche du code actuellement en développement et que, par conséquent, il n’y avait pas trop besoin de s’en faire pour la prospérité du développement en cas d’accident. :) Le code en C m’avait bien plu finalement : bien que ce soit un peu plus lourd à écrire à la mode programmation orientée objet, le C a une syntaxe assez simple à appréhender et à utiliser. Home Bank m’a permis de bien comprendre que l’âge du langage n’est pas du tout un problème pour faire de superbes projets avec ! Actuellement, je reprends mon code pour ajouter quelques fonctionnalités indispensables pour être vraiment utile (ajouter, enlever et renommer des lignes de budgets). # acme-dns-tiny Depuis mars, j’ai publié la version 2.0, puis la version 2.1 pour suivre les derniers développements des brouillons de la future RFC ACME. Cette RFC permet de définir le processus de délivrance automatisée de certificats X.509, utilisée, entre autres, par les serveurs de Let’s Encrypt. Le script Python `acme-dns-tiny` permet de faire des demandes de certificats via des ressources DNS installées au bon moment avec la bonne valeur. Je reçois de temps en temps des retours d’utilisateur assez intéressants. Par exemple, cette semaine j’ai découvert que certains résolveurs DNS lient le nom `localhost` à `127.0.0.1`, et d’autres retournent juste une erreur `NXDOMAIN`. Je ne sais pas de qui, entre Quad9 et Google est le plus proche des spécifications du DNS, mais ça a permis de révéler une incohérence dans mon script (il essaie de faire des mises à jour alors qu’il sait qu’il ne pourra pas vérifier le résultat). Pour voir les différences, vous pouvez installer `dnsutils` sous Debian et faire : ```bash dig A localhost @9.9.9.9 dig A localhost @8.8.8.8 ``` # xmpp-pane et Ibex Finalement, j’ai décidé d’abandonner le développement de mon lecteur de flux pubsub XMPP que je nommais `xmpp-pane` (voir le journal précédent pour plus d’informations). Le problème principal pour moi était que le système de WebExtension est incapable de me proposer un stockage sûr des données utilisateurs. En effet, Firefox ne propose pas de stockage chiffré qui ne serait accessible que via l’extension elle‐même, et je ne pouvais donc stocker nulle part de manière sécurisée les mots de passe utilisateur. En revanche, comme j’ai décidé de changer de travail, j’ai voulu recommencer à pratiquer des langages tels que C et C++. J’ai donc profité de reprendre l’idée de ce projet, mais de faire cette fois‐ci une application de bureau avec les outillages de Glib, GTK+, libsecret, etc., pour tout gérer correctement. J’avais [bien commencé](https://projects.adorsaz.ch/adrien/ibex) le développement d’__Ibex__, jusqu’à cet hiver lorsque... # Hein ? Kadabra évolue ! Un changement de mémoire vive a tué mon serveur auto-hébergé kadabra.adorsaz.ch... Je n’avais pas compris tout de suite que la nouvelle mémoire vive était fautive et j’ai tenté de réparer mon RAID 1 Btrfs... Ce qui a été un désastre et a planté un clou définitif dans le cercueil de mon serveur. Heureusement, je venais d’acheter d’occasion un nouveau Lenovo Thinkpad L500 (série que je ne connaissais pas) pour une autre tâche. J’ai donc pu rapidement monter un nouveau serveur sous le doux nom d’_alakazam.adorsaz.ch_ (oui, mon enfance a été bercée par les Pokémon 😄). Mes sauvegardes ont très bien fonctionné et je n’ai perdu qu’une journée (environ) de données personnelles (c’est‐à‐dire pas grand’chose pour un jour de travail !). J’en ai profité pour réviser mes différentes configurations et pour utiliser un nouveau système de sauvegardes incrémentielles à coup d’instantanés Btrfs pour figer les données à une date donnée, et à coup de `rsync` pour synchroniser les dossiers du disque de production avec le disque de sauvegarde. ```bash #!/bin/bash set -e set -x bck_root='/srv/backup/alakazam' bck_rsync='rsync -a --xattrs --acls --delete --stats ' bckp_psql='sudo -u postgres pg_dump ' # Backup on 10 days at most once by hour # (So, for one day, we can backup twice for example) bck_suffix="$(expr $(date +'%d') % 10)_$(date +'%H')" bck_snapshot="/srv/backup/snapshot/alakazam.${bck_suffix}" mount -o remount,rw /srv/backup mkdir -p "${bck_root}/etc/" mkdir -p "${bck_root}/home/" mkdir -p "${bck_root}/ldap/" mkdir -p "${bck_root}/psql/" mkdir -p "/srv/backup/snapshot/" mkdir -p "${bck_root}/srv/" mkdir -p "${bck_root}/var/lib/" date>${bck_root}/last_sync_start slapcat -b 'cn=config'>"${bck_root}/ldap/config.ldiff" slapcat -b 'dc=adorsaz,dc=org'>"${bck_root}/ldap/adorsaz.org.ldiff" ${bckp_psql} ejabberd>"${bck_root}/psql/ejabberd.sql" ${bckp_psql} freshrss>"${bck_root}/psql/freshrss.sql" ${bckp_psql} gitlab>"${bck_root}/psql/gitlab.sql" ${bckp_psql} owncloud>"${bck_root}/psql/owncloud.sql" ${bckp_psql} roundcube>"${bck_root}/psql/roundcube.sql" ${bck_rsync} \ /etc/ "${bck_root}/etc/" ${bck_rsync} \ /home/ "${bck_root}/home/" ${bck_rsync} \ /var/lib/ "${bck_root}/var/lib/" ${bck_rsync} \ --exclude backup \ --exclude kadabra \ --exclude movim/cache \ --exclude nextcloud/cache \ --exclude www/movim/cache \ /srv/ "${bck_root}/srv/" date>${bck_root}/last_sync_end if [ -d "${bck_snapshot}" ] ; then btrfs subvolume delete --commit-after "${bck_snapshot}" fi btrfs subvolume snapshot -r "${bck_root}" "${bck_snapshot}" mount -o remount,ro /srv/backup ``` Vous remarquerez que je ne passe pas par une étape de compression, car la destination de ma commande `rsync` est un système Btrfs monté avec l’option `compression`. Celle‐ci permet pour chaque nouveau fichier enregistré de le compresser à la volée si c’est utile (selon un test de compression sur un échantillon des données). Comme la compression et la décompression sont réalisées à la volée par le système de fichiers, je peux avoir le bonheur d’utiliser directement `rsync` et ne plus passer des heures à attendre que mon processeur finisse de tout recompresser avec `tar` quand je crée la nouvelle archive `master` (il n’y plus d’archive _master_, juste des instantanés qui se suivent). Pour moi, ce script est bien plus lisible et je sais exactement ce qu’il va faire, alors qu’avant j’utilisais [`backup-manager`](https://packages.debian.org/stretch/backup-manager) qui faisait bien son travail, mais qui était impossible à relire et adapter facilement pour moi. Et voilà, c’est ainsi que 2019 est déjà arrivé et que je n’ai malheureusement pas contribué au code source de _LinuxFr.org_. J’espère pouvoir vous refaire un rapport aussi complet l’année prochaine. :)

AltStyle によって変換されたページ (->オリジナル) /