Deblan blog

Informatique

Générer un rapport d'un serveur en HTML/Texte dans fichier et/ou un mail

Générer un rapport d'un serveur en HTML/Texte dans fichier et/ou un mail

https://gitnet.fr/deblan/deblan-report

Ce projet génère un rapport générique sur une distribution Debian GNU/Linux (+ Ubuntu).

  • Nom du système
  • État des paquets et uptime
  • Points de montage
  • Espaces disques
  • Rapport Smartmontools

Ce rapport pourra être enregistré dans un fichier et/ou envoyé par mail.

Sa configuration est très simple et tout est documenté dans le README du projet.

Lien permanent


DOSSIER. Reprendre la main sur ses données avec l’auto-hébergement

DOSSIER. Reprendre la main sur ses données avec l’auto-hébergement

https://www.tinternet.net/article/2019/05/dossier-reprendre-la-main-sur-ses-donnees-avec-lauto-hebergement

Dans un dossier complet, Tinternet & cie vous explique comment nous pouvons reprendre la main sur nos données personnelles sur internet.

Un premier article d'une longue série j'espère 🙂

Lien permanent


Vérifier la date d'expiration de noms de domaine

Que ce soit à titre personnel ou dans le cadre de mon travail, je dois gérer une liste relativement importante de noms de domaine et m'assurer qu'ils sont renouvelés à temps.

Les prestataires vers qui sont achetés les noms sont divers et il n'y a pas d'homogénéité des alertes qui notifient d'une expiration prochaine.

Par conséquent, j'ai écris un projet qui a pour seul et unique objectif de me donner la date d'expiration d'un ou plusieurs noms de domaine. Cette date prendra une couleur selon de l'échéance : rouge si on est dans les 2 dernières semaines, jaune si c'est dans les 30 prochains jours ou ou vert si c'est au délà.

$ domain-expiration check google.com amazon.com facebook.com apple.com microsoft.com
+---------------+---------------------+
| Domain        | Date                |
+---------------+---------------------+
| google.com    | 2020-09-14 04:00:00 |
| apple.com     | 2021-02-20 05:00:00 |
| microsoft.com | 2021-03-05 04:00:00 |
| amazon.com    | 2022-10-31 04:00:00 |
| facebook.com  | 2028-03-30 04:00:00 |
+---------------+---------------------+

Grâce à ansi2html, on peut réaliser une conversion du rendu en HTML afin générer un mail coloré.

$ domain-expiration --ansi check [...] | ansi2html | mail \
  -a "Content-type: text/html" \
  -s "Dates d'expirations des domaines" \
  admin@example.com

Le projet est écrit avec PHP 7.3. Les dépendances sont traitées avec composer et il faut le programme whois.

$ git clone https://gitnet.fr/deblan/domain-expiration.git
$ cd domain-expiration
$ composer install
$ php7.3 ./domain-expiration check mon-site.fr

Le code n'est pas parfait mais ça fonctionne 😊


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