Deblan blog

Simon Vieille

IT director at Zenitude Groupe, symfony expert and debian addict

Glyn Moody sur l’article 13 – Une aberration judiciaire

Glyn Moody sur l’article 13 – Une aberration judiciaire

https://framablog.org/2019/02/13/glyn-moody-sur-larticle-13-une-aberration-judiciaire/

L'émancipation des grosses plateformes centralisatrices est une des réponses à ces débiles qui pondent des lois proportionnellement toutes aussi débiles.

Héberger des contenus à la maison fonctionne très bien et c'est le moment d'y songer ! Et si vous préférez les chatons alors visitez Chatons.org.

Lien permanent


Le communautaire fonctionne mieux que le propriétaire

Au moment où j'écris cet article, ça fait un an que j'ai rejoint le groupe Zenitude avec comme nouveau métier pour moi, la responsabilité du parc informatique au sens large (support logiciel, support matériel, développement, administration système).

Aujourd'hui, ma conclusion est très radicale : les solutions logicielles open-source/libres fonctionnent mieux que les solutions propriétaires et le support communautaire est largement plus efficace que le support fournit par les sociétés commerciales. La majorité des problèmes que je rencontre est liée aux solutions propriétaires.

Le simple fait de pouvoir regarder le code source d'une application pour en comprendre son fonctionnement, voire même de le modifier est un gain considérable de temps et d'argent. Ne pas avoir la faculté d'appliquer un patch correctif temporaire avant une correction en upstream est un vrai problème qui coûte beaucoup de temps (et donc d'argent).

Je pense que beaucoup d'entreprises perdent du temps, de l'argent et beaucoup d'énergie en s'entêtant à éviter les solutions open-sources ou libres.

Meme open-source


Bande annonce du film "La bataille du libre" (version 3min VF) / Sortie officielle début 2019

https://vimeo.com/309626671

« La bataille du Libre » film documentaire (version 87mn du film "Internet ou la révolution du partage" bientôt diffusé…

Lien permanent


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'].