Deblan blog

Informatique

Courier-imap vers Dovecot : "Renaming not supported across conflicting directory permissions"

Il y a des années de ça, je me suis lancé dans l'aventure de l'hébergement à la maison avec notamment la gestion de mes mails. Dès le départ, je suis parti sur de la Debian GNU/Linux et j'ai installé les outils Postfix et Courier pour gérer les couches SMTP et IMAP.

Cette semaine, j'ai remplacé Courier par Dovecot qui est plus complet, plus simple à configurer et au cœur de beaucoup de documentations. J'avais également besoin d'intégrer Sieve pour gérer des règles de tri coté serveur.

Je ne détaillerai pas la procédure de migration car j'ai pioché dans pas mal d'articles. Globalement, tout s'est très bien passé et ça été transparent pour les quelques utilisateurs du serveur. Cependant, je me suis confronté à une erreur lorsque qu'ai voulu supprimer un dossier via mon client Thunderbird :

[CANNOT] Renaming not supported across conflicting directory permissions

Après quelques recherches, il s'avère que les répertoires Maildir des utilsateurs, générés avec la commande maildirmake ~/Maildir, ont un chmod 700 et que par défaut, lors de la création d'un répertoire, son chmod est 755. Dans la version 2.2.*, Dovecot vérifie que les chmod des dossiers correspondent pour valider la suppression et comme ce n'est pas le cas, cette erreur apparait.

Ainsi, quand un répertoire est créé dans l'arborescence de la boite mail, il ne peut plus être supprimé sans faire un chmod 700 ~/Maildir/.LeRepertoire. Pour résoudre le souci et faire en sorte que le chmod soit le bon, j'ai simplement joué avec les ACL. Pour chaque utilisateur hébergé, j'ai lancé cette commande :

$ setfacl -d --set u::rwx,g::-,o::- ~/Maildir/

Ainsi, lorsqu'un répertoire est créé dans ~/Maildir, son chmod est par défaut en 700 et je peux le supprimer via Dovecot au travers de mon client Thunderbird !

J'en ai également profité pour faire un wrapper sur le serveur :

#!/bin/sh

maildirmake.dovecot "$1"
setfacl -d --set u::rwx,g::-,o::- "$1"

[tips] PHP FPM : récupérer la vraie adresse IP du visiteur

Mon serveur web fonctionne par couches. La première couche est gérée par Nginx et traite les requetes HTTP des internautes. Nginx gère les problématiques de cache sur les assets, c'est à dire les images, les fichiers javascripts et enfin les fichiers CSS. Ensuite, il transmet les requêtes au serveur web Apache qui va délivrer le site web concerné et faire appel au process manager de PHP (FPM) pour exécuter PHP.

En l'état, il n'est pas possible de connaître l'adresse IP de l'internaute via la variable globale $_SERVER en utilisant l'index REMOTE_ADDR. En effet, si j'affiche le contenu de $_SERVER['REMOTE_ADDR'], j'aurai comme résultat 127.0.0.1 qui est l'IP locale de Nginx.

Cependant, j'ai configuré Nginx de tel sorte qu'il ajoute les entêtes HTTP X-Forwarded-For et X-Real-IP. Apache les transmet ensuite via les index HTTP_X_FORWARDED_FOR et HTTP_X_REAL_IP.

proxy_set_header X-Real-IP  $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;

Ces index contiennent l'IP de l'internaute mais ne sont pas utilisés par les applications hébergées. Typiquement, Nextcloud détectait l'adresse IP 127.0.0.1. Lors d'un brute force, tous les comptes utilisateurs étaient impactés par la sécurité enclanchée par Nextcloud (soit 30s d'attente avant la validation des identifiants de connexion).

J'ai fouiné sur la toile et plusieurs solutions sont évoquées. J'ai un peu tout essayé et au delà des modules Apache Rpaf et RemoteIP, pas grand chose de probant. Rpaf est déjà installé et permet à Apache de logger la bonne IP dans les logs d'accès. RemoteIP n'a pas fonctionné dans mon environnement.

Pour résoudre le problème, j'ai appliqué ce qui a été rédigé dans ce post : inclure un script PHP de façon automatique pour l'ensemble des sites web du serveur.

j'ai créé un fichier PHP comme suit :

<?php

$trustedProxies = [
    '127.0.0.1',
];

$remote = $_SERVER['REMOTE_ADDR'];

$headers = [
    'HTTP_X_FORWARDED_FOR' => 'REMOTE_ADDR',
    'HTTP_X_REAL_IP' => 'REMOTE_HOST',
];

if (in_array($remote, $trustedProxies)) {
    foreach ($headers as $header => $value) {
        $_SERVER[$value] = $_SERVER[$header];
    }
}

Puis j'ai alimenté les php.ini de cette façon :

auto_prepend_file = /etc/php/fpm/real-ip.php

Après avoir relancé les services, j'ai pu constater que l'adresse IP de l'internaute est bien présente dans $_SERVER['REMOTE_ADDR'].


La vie d'un DSI

En début d'année, j'ai intégré le siège du groupe Zenitude. C'est une société qui gère aujourd'hui près de 25 résidences hôtelières partout en France. Mon rôle consiste à traiter l'informatique (au sens large) du groupe.

C'est un projet professionnel assez nouveau pour moi, car dès mon entrée dans la vie active, c'est dans une agence web où j'ai atterri avec l'étiquette de développeur. J'ai évolué vers de la gestion de projet technique pour devenir ensuite directeur technique dans une seconde agence. J'avais donc un profil très orienté développement web et j'ai développé l'administration système.

Je suis passé d'un environnement où les outils étaient assez bien maîtrisés (environnement de développement et d'hébergement) vers un environnement où l'informatique prend une échelle beaucoup plus importante. À ce stade, des outils et des processus m'échappaient parfois.

Voici quelques problématiques auxquelles je me suis confronté et quelques-unes des solutions mises en places.

Le contexte

Il faut savoir que Zenitude existe depuis 2009. On ne m'a pas attendu pour faire de l'informatique et je dois composer avec neuf ans d'histoire. Par ailleurs, comme nous récupérons la gestion d'établissements qui ont eux aussi leur passif, on n'a aucune uniformisation du parc.

Le parc informatique

Le groupe Zenitude, c'est une centaine d'ordinateurs sous Windows, 3 serveurs Debian GNU/Linux, 1 serveur avec Ubuntu, une tripoté de photocopieurs, des lignes téléphoniques SIP, des accès RTP sur 25 serveurs Microsoft Server, etc. Bref, il y a du monde et le premier truc que j'ai admis c'est qu'il est impossible d'avoir une maîtrise de tout ça.

Quand je parle de maîtrise, je pense déjà à l'inventaire du parc qui n'est absolument pas précis. Nous le verrons juste après mais l'objectif est de faire le plus de choses en ligne. Les machines tendent à devenir que de simples terminaux d'accès vers des outils déportés. Que ce soit bien ou pas, l'avenir nous le dira mais c'est un choix plutôt intéressant pour le moment. Quand une machine tombe, on ne se prend pas la tête et on la remplace. Les données sont en ligne donc il n'y a pas de perte.

Pour piloter le parc et assurer un minimum de sécurité et de support, nous avons déployé la solution Teamviewer permettant un accès avancé sur les machines via une console en ligne et un client manager. On peut harmoniser la politique de sécurité avec une solution anti-virus intégrée (IT Brain) et quelques règles définies en amont. Dès l'ajout d'une machine dans le parc, il suffit d'installer Teamviewer et je peux déployer ce que je veux dessus. Si quelque chose de bizarre est détecté, je suis averti par mail (Virus, problème de disque, etc.).

Teamview

Du côté des serveurs, les machines sous Windows ne sont pas infogérées par Zenitude. J'ai installé les serveurs sous Linux et c'est aussi moi qui les administre. Pour assurer l'accessibilité des services, j'ai déployé une instance Zabbix pour les monitorer. Dès qu'un service est inaccessible ou qu'un problème système est détecté, je suis averti par mail et par SMS suivant le niveau gravité.

Zabbix

Globalement, ça fonctionne bien. Je rencontre cependant deux problèmes récurrents. Le premier est l'installateur Windows 10 pour paramétrer la machine après l'achat. Le second émane des programmes préinstallés par les fabricants. L'un n'est pas toujours évident pour tout le monde et l'autre implique de faire du ménage qui prend du temps.

Le collaboratif

C'est un enjeu important pour les entreprises et c'est loin d'être simple à mettre en place. À Zenitude, on a donc des établissements hôteliers éparpillés partout en France, pilotés en partie par le siège où je travaille.

Chaque établissement a une équipe qui édite des documents communs. On retrouve une majorité de fichiers Excel et Word. La direction a choisi de s'orienter vers Office 365 pour traiter cette problématique. Il faut accompagner les équipes, expliquer le pourquoi du comment, les aider à configurer les logiciels et les former aux bons usages.

Dans les problématiques du tout collaboratif, on retrouve aussi les limitations techniques comme des accès à l'Internet pas toujours fiables et des machines pas toujours à la hauteur. Par ailleurs, quand on sort des sentiers battus, ça devient rapidement une vraie galère (cf Sharepoint sous Debian).

Cependant, j'ai l'opportunité de travailler sur des outils qui réduisent la quantité de problèmes. En effet, même si Office Online reste assez efficace, il est parfois beaucoup trop compliqué pour finalement saisir des données simples. On a lancé des développements en interne et particulièrement une plateforme nommées Tools, sous Symfony 3, qui tend à remplacer les tableurs par des formulaires en ligne. Ça permet de mieux contrôler les saisies et de pouvoir exploiter les données convenablement (graphiques dynamiques, tableaux, déploiement d'API, etc.). On a également remplacé des services externalisés et coûteux, ce qui permet de reprendre la main sur nos données. Aujourd'hui, cette application fait de l'analyse de budgets et de chiffres d'affaire, elle récupère et met en page des données de e-réputation pour les établissements, elle centralise les demandes pour les supports de communication, elle permet de mettre en ligne des offres de recrutement, elle intègre le processus d'achat du groupe, une messagerie instantanée est inclue, etc. C'est une véritable valeur ajoutée pour le groupe.

Zenitude Tools

Le changement par l'accompagnement

Comme je l'ai évoqué, quand on met en place de nouvelles solutions, il est primordial de penser à l'accompagnement. Cet accompagnement doit se faire autour de deux problématiques majeures : l'adoption de l'outil et son utilisation. En effet, quand on demande à des directeurs d'établissements, des responsables d'hébergement ou des réceptionnistes de changer leurs habitudes, ils doivent comprendre la nécessité de le faire.

Ce qui suit le « pourquoi », c'est le « comment » et voici une étape complexe à franchir. Même si j'ai acquis de l'expérience en pédagogie, je me suis rendu compte que des choses simples n'étaient pas acquises. Pour illustrer un peu, certains utilisateurs ne font pas la différence entre la version d'Outlook en ligne et le logiciel installé sur leur machine. Ça peut faire sourire mais c'est un fait. Je dois mesurer chaque mot que j'utilise pour expliquer des outils et je travaille beaucoup les interfaces que je produis. J'essaye aussi de réaliser de la documentation dans différents formats : des pages de contenus sous forme de Wiki, des tutoriels vidéos et des présentations.

Wiki

Intrinsèquement lié à l'accompagnement, le support informatique avec le suivi et l'historique des demandes est essentiel pour les utilisateurs et pour moi. J'ai mis en place une plateforme de suivi qui s'appuie sur Redmine, interconnecté à Tools via des API. Nous pouvons ainsi avoir une vision globale des problèmes rencontrés, que ce soit sur les outils internes mais également les services externes que nous utilisons. Nous pouvons suivre l'évolution d'une demande et alerter les différents acteurs. Enfin, le jour où l'IT grossie, mes futurs collaborateurs seront en mesure de prendre le relais en toute transparence.

Support

Conclusion

D'autres sujets auraient pu être traités ici mais j'avais envi de partager l'essentiel de mon travail. Il y a eu des ratés mais il faut essayer des choses, en adapter d'autres et remplacer ce qui ne me parait pas judicieux. En l'espace de quelques mois, beaucoup de choses ont avancé et pas mal d'autres projets sont à venir. Je pense avoir beaucoup appris depuis mon arrivée à Zenitude et je suis très fiers des résultats obtenus.

Par ailleurs, si on enlève la partie collaboration avec Office 365, Teamviewer et les machines sous Windows, le logiciel libre a une place importante dans les outils déployés à Zenitude. Des applications métiers sont en partie libres, je développe sur des outils libres (ou assimilés) et ça prouve que ça fonctionne en entreprise et particulièrement dans les moyennes entreprises (sans rentrer dans une optique de tout faire en libre).


Migration de Gogs vers Gitea

Gogs est une plateforme pour gérer des dépôts GIT à la manière de Github. C'est un projet sous licence MIT qui fonctionne bien mais son développeur ne propose par une collaboration des plus simple.

Il y a pas mal de temps déjà, la communauté a forké le projet pour créer Gitea. Au départ, nous avions une version très proche de Gogs mais Gitea évolue maintenant de façon indépendante. Gitea offre plus de fonctionnalités et j'ai décidé de migrer Gitnet vers cet outil.

La migration n'a pas été évidente mais voici une TODO list si vous souhaitez le faire de votre coté !

  1. Faire une sauvegarde de la base de données de Gogs
  2. Faire une sauvegarde des dépots de Gogs
  3. Suivre la procédure décrite dans la documentation

Après ça, mon répertoire gitea a cette forme :

/custom
/custom/conf/
/custom/conf/app.ini
/data
/data/avatars
/data/sessions
/log

Au départ, j'ai fait le bourrin et j'ai lancé la version 1.5 de gitea pour au final tout casser. Du coup, pour passer de Gogs à Gitea 1.5, j'ai décidé de récupérer les binaires des versions 1.0, 1.1, 1.2, 1.3 et 1.4 de Gitea et je les ai lancé successivement. Je me suis donc assuré de ne manquer aucne migrations de base de données.

Dans /path/to/gitea :

for v in 1.0.2 1.1.0 1.2.0 1.3.0 1.4.0 1.5.0; do
    wget https://github.com/go-gitea/gitea/releases/download/v${v}/gitea-${v}-linux-amd64
    chmod +x gitea-${v}-linux-amd64
done

…Et on migre la base de données en démarrant chacune de ces versions :

git@host: /path/to/gitea $ ./gitea-1.0.2-linux-amd64 web
git@host: /path/to/gitea $ ./gitea-1.1.0-linux-amd64 web
git@host: /path/to/gitea $ ./gitea-1.2.1-linux-amd64 web
git@host: /path/to/gitea $ ./gitea-1.3.0-linux-amd64 web
git@host: /path/to/gitea $ ./gitea-1.4.0-linux-amd64 web
git@host: /path/to/gitea $ ./gitea-1.5.0-linux-amd64 web

À l'heure où j'écris cet article, la version 1.5.1 est dispo mais elle ne fonctionne pas chez moi. Je vais donc attendre un peu pour upgrader Gitea.

J'ai fais le tour de Gitnet et je n'ai pas rencontré de bug. J'espère ne pas être passé à coté d'un gros soucis ! En tout cas, je suis très content d'avoir pu réaliser cette migration en même pas une heure !


Sharepoint Office365 sur Linux : automatiser l'authentification

Suite de l'aventure avec Sharepoint !

On a pu passer 2 étapes cruciales pour jouer avec Sharepoint Online :

Après quelques jours d'utilisation, il s'avère que les cookies d'authentification ne sont plus valables. C'est un gros problème car c'est pénible de les récupérer manuellement pour ensuite les injecter dans le fichier de configuration Davfs.

J'ai planché quelques heures sur une solution : réaliser le parcours de connexion d'un utilisateur qui passerait par un navigateur web.

Le projet est libre et voici comment l'installer et l'utiliser.

Note : il faut avoir NodeJS sur sa machine. J'ai développé le code en version 6.13.0.

Il faudra déclarer 3 variables d'environnement contenant le site Sharepoint, l'identifiant de connexion et le mot de passe :

Il ne reste plus qu'à lancer le script qui devrait vous retourner du JSON avec les 2 cookies dedans :

À vous de choisir la méthode pour alimenter la configuration de Davfs avec ces données !