Envoyer/recevoir les e-mails, accéder à l’agenda et aux contacts Microsoft Exchange sur Fedora

Contexte : Mon unique PC portable principal tourne avec Fedora depuis maintenant plusieurs années (j’ai quand même un dual-boot avec Windows 10 au cas où mais honnêtement, je ne l’utilise quasi jamais de la sorte). L’entreprise où je travaille, comme beaucoup d’autres boîtes, utilise Microsoft Exchange pour les e-mails, l’agenda et les contacts. Bien évidemment, à l’heure où j’écris ceci, même si Microsoft a fait plusieurs pas en avant ces dernières années vers l’univers « Linux » et que Microsoft Outlook est disponible sous Android, pour GNU/Linux et dans le cas qui m’intéresse plus précisément Fedora, aucun Microsoft Outlook à disposition (certains diront que via Wine c’est possible mais, sincèrement, je n’avais pas envie de « bricoler » de la sorte – cf. principe KISS).

Depuis des années voire même presque le début, j’utilise Mozilla Firefox. Il était donc +/- logique que je bascule vers Thunderbird pour mes e-mails. Par contre, et c’est là que ça coince, nativement, Microsoft Exchange n’est pas supporté. J’ai donc testé plusieurs modules complémentaires comme TbSync et Owl/Chouette. Hélas, aucun n’a répondu totalement à mes attentes. Le 1er, je n’ai jamais réussi à le faire fonctionner correctement et le second, pour lequel j’avais quand même payé une licence d’un an, m’imposait très très souvent de me reconnecter et était limité au niveau des agendas (partagés).

J’étais ensuite tombé sur le site web suivant : https://www.monperrus.net/martin/microsoft-exchange-calendar-from-thunderbird au gré de mes recherches. Et là, bingo ! Avec la passerelle Davmail, ça marchait du tonnerre ! C’était un peu du bricolage pour la partie « agenda » mais, sans utiliser le moindre module complémentaire dans Thunderbird, ça faisait parfaitement le job ! Et ça pourrait d’ailleurs parfaitement vous convenir en fonction de votre infra Exchange. Je dis bien « ça faisait parfaitement le job » car, du jour au lendemain, au niveau agenda, ça a commencé à déconner. J’ai bien évidemment essayé d’utiliser la dernière version en date de Davmail mais, dans ce cas précis, c’était encore pire et plus rien ne fonctionnait ! J’ai même désespérément tenté de contacter le développeur principal de Davmail. Hélas en vain (je ne lui jette pas du tout la pierre hein, il a sans doute mieux à faire) !

Bref, il fallait donc que je trouve une alternative. Je n’avais guère envie de revenir sous Windows 10 ou 11. J’avais alors envisagé un peu par dépit de tenter l’aventure avec macOS sur un MacBook Pro d’occasion (je n’ai toutefois pas [encore ?] franchi le pas).

Je suis donc tombé sur Evolution. Il faut dire qu’il n’y a pas 36 alternatives à Thunderbird (si ce ne sont quelques clients e-mails en ligne de commande). Je l’ai installé et je l’ai essayé. Résultat : échec. Je m’y suis sans doute mal pris. J’avais fait la configuration de mon compte e-mail manuellement. Et c’est sans doute là que ça a coincé (ça plus le fait qu’il me manquait un paquet pour la prise en charge complète d’Exchange). Je l’ai désinstallé et je me suis entêté à faire fonctionner quasi coûte que coûte Thunderbird et Davmail. Spoiler : en vain !

Puis, j’ai fait une nouvelle recherche sur le Net et là, bingo, je suis tombé sur le site web suivant : https://www.linuxtricks.fr/wiki/gnome-integrer-son-compte-microsoft-exchange-sous-linux Hourra ! Merci d’ailleurs à l’auteur de cet article ! Si j’étais tombé dessus un peu plus tôt, il m’aurait fait économiser de nombreuses heures de prise de tête.

Concrètement : il suffit d’installer les paquets evolution et evolution-ews (ce dernier permet la prise en charge de l’API Exchange Web Services (EWS)). Et après avoir configuré son compte, c’est à peu près tout ! Accessoirement, je recommande l’installation de gnome-calendar & gnome-contacts.

Dès que c’est installé, allez dans « Comptes en ligne » (via Paramètres système / Centre de contrôle ou directement en tapant « Comptes en ligne » dans le menu des applications) et ajoutez-y votre compte Microsoft Exchange (si pas présent sur votre système, installez le paquet gnome-online-accounts).

Vous pouvez choisir ce que vous souhaitez synchroniser : Courriel, Agenda et/ou Contacts.

Patientez quelques secondes et ça devrait être bon. C’est tout ! Rien de plus !

Toujours dans mon cas, j’ai importé toutes mes archives Thunderbird sans le moindre souci. J’ai également refait 2 ou 3 règles pour appliquer des étiquettes automatiquement aux e-mails de la boîte de réception. Après quelques réglages ci et là (le dossier local d’archivage, la signature, la manière dont sont affichés les e-mails [grouper ou non par fils de discussion]) et je me retrouvais à quelques menus détails près avec ce que j’avais avec Thunderbird, prise de tête en moins.

Petite subtilité pour ajouter un agenda partagé d’un-e collègue ou d’une équipe : il suffit de faire un clic droit sur l’intitulé de votre compte dans la partie « Courriel » d’Evolution est cliquer sur « Subscribe to folder of other user… ». Vous renseignez le nom du calendrier et dès qu’il apparaît dans les résultats, vous choisissez bien entendu « Calendar ».

Dans l’immédiat, j’ai retrouvé presque toutes mes habitudes de Thunderbird dans Evolution (comme par exemple convertir le contenu d’un e-mail en évènement dans l’agenda pour ne rien oublier – par contre, le fait de simplement appuyer sur la touche « A » du clavier pour archiver les messages me manque [ou alors, je n’ai pas bien cherché]). A voir bien entendu dans les semaines/mois qui viennent si des choses vont me titiller.

Bonus : via le terminal, il est possible de faire démarrer Evolution dans un mode bien précis (Courriel, Agenda, Contacts, …). Tapez evolution –help pour en savoir plus. Et, chose intéressante pour les sauvegardes, il suffit d’aller dans Fichier puis Archiver les données d’Evolution …. pour générer automatiquement une archive compressée tar.gz (malheureusement, pas faisable via la commande evolution [j’ai vérifié] et donc pas scriptable automatiquement en l’état).

pip vs npm

Petit aide-mémoire si besoin

npm vs pip : Quelles sont les différences ?

Les développeurs décrivent npm comme « Le gestionnaire de paquets pour JavaScript » (Node.js). npm est l’interface en ligne de commande de l’écosystème npm. Il est éprouvé, étonnamment flexible et utilisé par des centaines de milliers de développeurs JavaScript chaque jour.

npm se compose de deux parties principales :

*/ un outil CLI (interface de ligne de commande) pour publier et télécharger des paquets, et
*/ un référentiel en ligne qui héberge les paquets JavaScript

D’autre part, pip est décrit comme « un gestionnaire de paquets utilisé pour installer et gérer des paquets écrits en Python. ». Vous pouvez utiliser pip pour installer des paquets à partir de l’index des paquets Python et d’autres index.

npm et pip peuvent être classés dans la catégorie des outils « Front End Package Manager »

Bref, npm et pip sont très proches en terme de philosophie. On peut les résumer en gestionnaires de paquets. Le premier pour JavaScript (Node.js) et le second pour Python.

Les nouveaux outils Tech/DevOps/IT « à la mode » ne m’emballent pas

Je deviens vieux. Ou alors c’était mieux avant. À peu de choses près c’est la même chose. Telle sera certainement la conclusion de ce billet.

Je vais peut-être me tirer une balle dans le pied en écrivant ce qui va suivre. À voir. Ce billet sera plus intimiste. Donc plus personnel. Ce n’est pas du tout, mais alors pas du tout dans mes habitudes de faire cela. Mais un peu à la manière de ce qu’à pu écrire Genma sur son blog ces derniers mois / ces dernières années (cf. ici et là par exemple), je me suis dit pourquoi pas.

Topo : professionnellement parlant, je suis dans l’IT depuis plus de 15 ans. Après une formation en tant que « Conseiller Technique PC/Réseau », me voilà technicien PC/Réseau (technico-commercial officiellement) dans une petite PME. Après avoir énormément appris sur un laps de temps très court, je sens à l’époque que j’en ai fait le tour et que je commence à stagner (à force de formater et réinstaller des Windows XP et Vista, cérébralement parlant, c’était bon pour moi). Le contexte est ce qu’il est à l’époque, je suis célibataire, sans enfants et sans grandes responsabilités/obligations en fin de compte. J’aurais aimé lancer ma propre activité (en tant qu’étudiant quelques années plus tôt, j’avais beaucoup aimé travailler dans un petit magasin d’alimentation générale – comme j’aimais le contact avec la clientèle et l’informatique [évidemment !], je souhaitais ouvrir ma propre petite structure du même acabit). Pour X et Y raisons, cela ne s’est pas fait. J’y reviendrai peut-être à l’occasion… J’ai donc ensuite travaillé pendant un an en tant qu’employé administratif. Je n’ai pas beaucoup aimé, je suis passé à autre chose juste après. J’ai finalement lancé mon activité en tant qu’indépendant (auto-entrepreneur pour les lecteurs français). J’étais donc aux commandes de mon propre « business » mais en tant que consultant, sans surface commerciale donc. Au début, j’ai fait ce que je savais faire : technicien PC/Réseau (pour tous). Ensuite j’ai souhaité évoluer moi-même en me focalisant uniquement sur les professionnels. J’ai fait de la consultance/sous-traitance pour quelques boîtes. Puis je me suis décidé à laisser tomber l’univers Windows pour me focaliser sur Linux (j’ai toujours eu des idées/concepts avec des Raspberry Pi même si pas grand chose de palpable n’en est sorti…). Me voilà donc administrateur système Linux en tant que consultant/freelance puis désormais en tant qu’employé (ayant mis un terme à mon activité d’indépendant il y a peu de temps).

Comme je le note en titre, les nouveaux outils Tech/DevOps/IT « à la mode » (je précise un peu plus loin pourquoi les guillemets) ne m’emballent pas. D’ailleurs, je ne me considère toujours pas comme un DevOps mais encore et toujours comme un administrateur système. Je suis peut-être de la vieille école (les mauvaises langues diront que je ne sais plus évoluer et me remettre en question vis-à-vis du métier – et vous n’avez peut-être pas tort finalement). Quels sont justement les outils du DevOps et quels sont les rôles de ce dernier ? Une rapide recherche et je prends les 2 premiers liens qui arrivent : https://kinsta.com/fr/blog/outils-devops/ & https://www.padok.fr/blog/outils-devops .

Bref, Docker, Kubernetes, Docker-Swarm, Terraform, Vagrant, … (liste non-exhaustive), ça ne me fait pas vibrer. Ce n’est pas mon « délire ». Je ne jette pas la pierre bien entendu aux personnes qui apprécient et maîtrisent ces outils. Tant mieux pour elles. Peut-être qu’il y a 10 ans j’aurais aimé moi aussi m’y mettre. Mais ce n’est pas le cas pour le moment. Le Cloud, ce mot magique de l’informatique dans les nuages alors que, comme il l’a déjà été répété à maintes et maintes reprises, il ne s’agit que de l’ordinateur (ou plutôt le serveur) de quelqu’un d’autre. Les GAFAM ont pris le dessus. Désormais, déployer une instance chez AWS ou Google Cloud Computing est presque la norme. Les notions de cloud souverains sont bien belles sur papier mais pour l’instant uniquement au rayon fiction (alors que ce ne sont pas les acteurs majeurs du domaine qui manquent : Scaleway, OVH, …). Tiens, pour la Belgique, je suis incapable de donner un nom !

Pourquoi ces outils Tech/DevOps/IT ne m’intéressent guère ? Car, comme je l’écris en sujet, je les trouve souvent « à la mode ». J’entends par là que telle ou telle techno sera mise en avant pendant un moment et, qu’après quelques temps, l’outil ne sera plus celui qui est en vogue mais sera remplacé par autre chose. Avec plus de fonctionnalités, plus de flexibilité, plus de ceci et plus de cela. Tant mieux, c’est sans doute bien, ça génère de la concurrence entres les acteurs et chacun est toujours obligé de se remettre en question. Mais, je n’aime pas effleurer un outil ou une technologie que du bout des doigts parce qu’elle est à la mode sans la maîtriser un minimum. Sans compter de toute façon qu’en entreprise, on ne peut pas se permettre de faire la girouette tous les 6 mois et changer pour s’aligner sur le produit du moment. C’est techniquement et commercialement impossible tant la latence pour déclencher le processus de réflexion et enclencher le changement mettra du temps (sans doute justifié pour éviter de choisir un produit à la hâte – sans oublier que les enjeux commerciaux feront de toute façon sans doute basculer le choix vers telle techno plutôt qu’une autre). Mais ça peut être frustrant justement. Car l’outil qui aura été validé comme « standard », devra être utilisé pendant des années. Alors qu’à côté, on sait qu’il y a tel ou tel autre qui fait sans doute ça plus rapidement, plus simplement et bien entendu plus efficacement (selon les échos et autres bruits de couloirs bien évidemment). Je n’aime donc pas la guerre des chapelles technologiques ou chaque personne prône pour sa propre paroisse. Il n’y a qu’à chercher sur le Web où une multitude de solutions existent. C’est bien, c’est diversifié. Mais hélas, le choix en devient alors cornélien et lourd à assumer (car, selon les dires, telle ou telle techno est la meilleure). Exemple simple : besoin d’un serveur web ? Apache HTTP (bien connu et réputé) fera le job ! Non, Nginx est mieux, plus léger, moins consommateur de ressources. Et lighttpd là-dedans ? Sur quel OS serveur tournera ce serveur web ? Debian, Ubuntu, Rocky Linux, … ?

Je pense être assez lucide pour comprendre qu’il me faut de l’informatique qui a du sens. Si c’est pour déployer des serveurs à foison sans avoir un réel retour sur à quoi tout ça pourra bien servir et si finalement les utilisateurs finaux seront contents du service rendu, ça n’est pas réellement pour moi. Mais bon, là, je digresse, ce n’est pas l’objet de ce texte.

En fin de compte, pour ne pas faire trop long avec ce billet, force est de constater que je me suis finalement sans doute trompé en intro. Ma conclusion ne sera pas « Je deviens vieux. Ou alors c’était mieux avant. » (même si la 1ère partie est bien un fait). Ce n’était sans doute pas mieux avant mais, personnellement, j’ai peut-être envie (une nouvelle fois) d’autre chose. J’aime pouvoir compter sur des technologies qui ont fait leurs preuves et qui sont stables. En effet, j’ai une relation un peu « particulière » avec l’informatique : un peu aigre-douce. Le fait que la moindre mise à jour, la moindre installation, le moindre caractère peut mettre un système par terre m’horripile.

Il parait que ce n’est pas au vieux singe qu’on apprend à faire la grimace. Il paraît aussi qu’il n’y a que les imbéciles qui ne changent pas d’avis. Déployer un backend à haute disponibilité et redondance, résiliant avec scalabilité chez tel ou tel prestataire cloud avec un frontend chez tel autre CDN n’est pas mon kif. Je n’ai pas dit que je le faisais, mais je sais déjà que je ne veux pas le faire. Et de mon point de vue, c’est déjà bien. Il me faut des choses plus simples (j’ai pas dit simplistes), plus authentiques. Utiles pour telles structures, telles écoles, tels services aux citoyens. Éthiques, solidaires et proches de l’humain (sans vouloir utiliser des bullshit buzzwords).

On va peut-être me dire que je suis un vieux briscard et qu’il est temps de passer à autre chose. Toutefois, cet autre chose, je ne sais pas c’est quoi. Je ne sais pas faire grand chose d’autre. Dois-je aller élever des chèvres dans le Larzac ou devenir boulanger ? J’ose encore espérer pouvoir trouver tip top ce qui me conviendra.

Réduire la taille d’un disque virtuel Windows au format VDI (VirtualBox)

De nos jours, nous avons beau avoir accès à du stockage de données à foison, pour autant, je n’aime pas l’espace disque gaspillé pour rien (peut-être une conséquence du fait que mon 1er PC avec Windows 98 SE n’avait qu’un disque de 4 Go…).

Le contexte : j’utilise VirtualBox pour mes machines virtuelles (VM) depuis des années (après un passage il y a 15 ans par Virtual PC de Microsoft ainsi que VMware Workstation Player). J’y teste à l’occasion divers systèmes d’exploitation : Microsoft Windows, CentOS, Fedora, Ubuntu, …

Avec Windows 10 et ses mises à jour semestrielles, l’espace disque du fichier .vdi (VirtualBox Disk Image) avait pris de l’embonpoint alors que dans le système, sur le disque C: , le disque n’était pas pour autant à saturation. Je ne vais pas rentrer dans les détails de comment la mise à jour fonctionne mais, en gros, lorsque cette dernière s’exécute, Windows crée une « sauvegarde » pour pouvoir revenir en arrière en cas de pépin. Même avec un bon nettoyage de disque avec l’utilitaire intégré en allant dans les options « Nettoyer les fichiers système », même si le disque C: avait repris des couleurs, ce n’était pas le cas du fichier .vdi.

Voici la solution : il suffit de télécharger et exécuter dans la VM Windows l’utilitaire SDelete de Sysinternals (https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete). A-t-on encore besoin de présenter ces derniers ? Si oui, rendez-vous par ici : https://en.wikipedia.org/wiki/Sysinternals. Via l’invite de commandes, on exécute :

sdelete -z c:

-z correspond à zero free space (good for virtual disk optimization)

Ensuite, il suffit d’exécuter la commande vboxmanage sur le système hôte de la manière suivante :

vboxmanage modifymedium --compact nom_du_fichier.vdi

Simple et efficace. Cette procédure permet de récupérer facilement quelques Go de stockage.

A l’origine, lorsque j’avais été confronté la toute première fois à cette « problématique », j’avais créé une p’tite note/un aide-mémoire dans Evernote avec les infos trouvées sur superuser.com (comme souvent – si ce n’est pas là, ça sera sur Stack Overflow de toute façon). C’était aux alentours d’octobre 2019, la date de la note Evernote faisant foi (je sais, Evernote c’est le mal, j’y ai déjà fait un énorme ménage, j’utilise en fonction des besoins soit Carnet dans Nextcloud soit tout simplement Notes dans ce dernier également). Quelques semaines après, la procédure a été publiée sur le blog de Seboss666 : https://blog.seboss666.info/2019/11/reduire-la-taille-dun-disque-vdi/ J’avais donc laissé ça de côté jusqu’à récemment suite à la mise à jour de 2 VM Windows 10 en 21H1.

Réduire la taille de la table mdl_logstore_standard_log de la DB Moodle

Hello,

Au printemps 2020, suite à l’apparition du fameux et désormais bien connu virus SARS-CoV-2 responsable de la Covid-19 et face aux bouleversements en terme d’organisation un peu partout, j’ai installé rapidement (à l’arrache pourrait-on presque dire) et temporairement le LMS Moodle sur un VPS hébergé chez OVH.

N’ayant pas spécialement beaucoup de temps à disposition, l’installation a été réalisée le plus simplement possible (création de la DB, récupération de l’archive sur le site officiel de Moodle, création du Virtual Host Apache HTTPD et génération des certificats TLS avec Let’s Encrypt). L’objectif était de rapidement disposer d’une plateforme fonctionnelle où y déposer les ressources pédagogiques pour les formations en cours de cette année scolaire.

Comme je le précisais, je n’avais pas le temps de potasser dans les moindres détails les bonnes pratiques d’une installation de Moodle en bonne et due forme, et encore moins concernant son administration ainsi que sa maintenance.

La plateforme a rapidement fait le job et c’était le principal.

Je m’apprête à décommissionner prochainement ce Moodle après ses bons et loyaux services rendus aux personnes concernées.

Récemment toutefois, sur le VPS qui l’héberge, j’ai constaté à plusieurs reprises que l’espace de stockage arrivait à saturation à cause d’une table de la DB de Moodle. J’ai un script « custom » qui sauvegarde toutes les nuits les DB, les fichiers de configuration, les contenus des dossiers Apache (j’en parlerai peut-être un de ces quatre ici…) avec une rétention locale pendant une petite poignée de jours (pour rapidement revenir en arrière d’un, deux ou trois jours) et un export chez Swiss Backup d’Infomaniak car on n’est jamais trop prudent.

Après analyse rapide de l’espace disque utilisé (avec ncdu), je constate que la table mdl_logstore_standard_log est tout simplement énorme ! Plus d’1 Go ! Une recherche rapide sur le Net et je comprends que c’est à cause du réglage par défaut de conservation des logs (pour faire simple, tout est conservé dans les logs depuis le début).

Pour changer ça : on se connecte à Moodle en tant qu’administrateur, on suit le chemin Administration du site > Plugins > Journaux > Journaux standards et il suffit de changer la valeur de « Conserver les journaux durant » (il n’est pas recommandé de choisir une valeur inférieure à 30 jours de rétention). Dans mon cas, j’ai donc choisi 35 jours.

Normalement, à ce que j’ai vu, un cron est censé faire le job après et supprimer les anciens logs devenus obsolètes.

Toutefois, pour « corriger » le souci manuellement, voici ce qu’il faut faire : on se connecte à son gestionnaire de base de données, on choisit la DB liée à Moodle puis on exécute les commandes suivantes (en ayant au préalable réalisé une sauvegarde de la DB bien entendu) :

DELETE FROM mdl_logstore_standard_log WHERE timecreated < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 30 DAY));

OPTIMIZE TABLE mdl_logstore_standard_log;

La 1ère ligne va supprimer les entrées supérieures à 30 jours de rétention et la seconde va optimiser l’espace utilisé en « récupérant » l’espace libre ainsi créé.

Le résultat est sans appel. Dans mon cas, la table fait désormais moins de 125 Mo.

Bonne année 2021 ! 🍾😷

Bon, vu qu’il reste encore quelques jours avant de clôturer le mois de janvier, en toute logique, il est encore temps de vous souhaiter une belle et heureuse année 2021 masquée !

Pas de fausse promesse pour cette nouvelle année :
je ne promets pas du tout, mais pas du tout, de mettre en ligne sur ce magnifique blog (sans doute le meilleur du monde des Zinternets) de superbes articles intéressants. J’ai de nombreuses idées mais sans doute pas assez de motivation et/ou de temps pour faire ça à un rythme régulier.

Bref, l’avenir nous dira de quoi il en sera (ou pas) !

Ciao ! 😁