Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Janvier 2019 -
Sommaire
Cher journal,
Toujours dans l'idée de parler des projets open-source qui m'ont porté de l'intérêt, j'ai décidé qu'il était temps de refaire un journal, comme en mars 2018.
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 coup 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 automatique 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 maintiens de cette extension, mais, entre temps, le développeur John Bieling de l'extension TbSync a ouvert une requête de collaboration entre nos deux projets !
En effet, TbSync était à l'époque capable de ne gérer que les synchronisations avec Exchange via les APIs 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).
A 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 le support 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 backend du protocole Exchange Web Service, mais toujours avec un minimum de frontend pour configurer les comptent et choisir les dossiers à synchroniser.
Finalement, 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, 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 a réussi à reprendre mes essais du printemps et à faire fonctionner 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 avec Thunderbird 60 l'extension (surtout la partie carnet d'adresse 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 claires 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é, 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 imaginer, 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, du coup, 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 reprend 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. Cet RFC permet de définir le processus de délivrement automatisé de certificats X.509, utilisé, entre autre, par les serveurs de Let's Encrypt. Le script Python acme-dns-tiny permet de faire des demandes de certificat 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éressant: 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:
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.
Par contre, comme j'ai décidé de changer de travail, j'ai voulu recommencer à pratiquer des langages tels que C et C++. J'ai profité donc 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… pour tout gérer correctement.
J'avais bien commencé 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 raid1 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 backups ont très bien fonctionné et je n'ai perdu qu'une journée (environ) de donnée personnelle (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 backup incrémentiel à coup de snapshots 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 backup.
#!/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 fichier, je peux avoir le bonheur d'utiliser directement rsync et ne plus passer des heures à attendre que mon processeur finisse de tout re-compresser avec tar quand je crée la nouvelle archive master (il n'y plus d'archive master, juste des snapshots 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 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.
J'espère pouvoir vous refaire un rapport aussi complet l'année prochaine :)
Commentaires :
voir le flux atom
ouvrir dans le navigateur
