Category

Web/Tech

Category

Tous les tutoriels et articles de barbus orientés technique.

Serveur dédié : installation de MariaDB 10.3 photo

Sur le serveur chinois que j’ai monté pour un de mes clients sur Codeable, le site a commencé à afficher des erreurs étranges : erreur 502 pour nginx sur certaines pages et des nombres étranges en lieu et place des données de la base de données.

Après un redémarrage des services PHP, nginx et mysql, je constate que MariaDB veut bien s’arrêter mais ne veut plus de lancer.

Voici ce que donne:

systemctl status mariadb.service

Résultat:

● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-04-22 18:14:22 CST; 59s ago
  Process: 721 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 718 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 12274 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
  Process: 12179 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
  Process: 12176 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12173 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 12274 (code=exited, status=1/FAILURE)
   Status: "MariaDB server is down"
systemd[1]: Starting MariaDB database server…
mysqld[12274]: 2019-04-22 18:14:19 140194687476288 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12274 …
systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start MariaDB database server.
systemd[1]: mariadb.service: Unit entered failed state.
systemd[1]: mariadb.service: Failed with result 'exit-code'.

Bon, chou blanc. Cela ne nous donne aucune information exploitable quand à l’erreur qui empêche le démarrage du service de base de données.

On regarde ensuite ce que nous donnent les logs de MariaDB:

tail -f /var/log/mysql/error.log

Résultat:

2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Completed initialization of buffer pool
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Highest supported file format is Barracuda.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: 128 rollback segment(s) are active.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Waiting for purge to start
2019-04-22 18:14:19 140194687476288 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 11397472969
2019-04-22 18:14:19 140194687476288 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-22 18:14:19 140194687476288 [ERROR] mysqld: Can't change size of file (Errcode: 28 "No space left on device")
2019-04-22 18:14:19 140194687476288 [ERROR] Can't init tc log
2019-04-22 18:14:19 140194687476288 [ERROR] Aborting

Là, c’est beaucoup plus intéressant. Visiblement, deux erreurs majeures sont à l’origine du non-démarrage du service:

  • il n’y a plus d’espace disponible sur le disque dur du serveur,
  • le fichier /var/lib/mysql/tc.log ne peut pas être initialisé.

Après un petit df, il s’avère que le client a installé un plugin de sauvegarde qui a littéralement saturé tout l’espace disponible.

Après un petit ménage, il ne reste plus qu’à gérer la seconde erreur, Can’t init tc log.

Le fichier /var/lib/mysql/tc.log peut parfois souffrir d’un problème de permission. Dans le cas du client, on l’archive par précaution:

mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bakup.log

Puis on relance le serveur MariaDB:

service mysql start

On vérifie le statut du service:

service mysql status

qui nous retourne:

service mysql status
● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-04-22 18:17:22 CST; 1h 37min ago
  Process: 12467 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12464 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 12340 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
  Process: 12337 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12334 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 12437 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 29 (limit: 4915)
   CGroup: /system.slice/mariadb.service
           └─12437 /usr/sbin/mysqld

Apr 22 18:17:20 iZuf6aj6jz83uxa0jgbgcrZ systemd[1]: Starting MariaDB database server...
Apr 22 18:17:21 iZuf6aj6jz83uxa0jgbgcrZ mysqld[12437]: 2019-04-22 18:17:21 139940495544896 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12437 ...
Apr 22 18:17:22 iZuf6aj6jz83uxa0jgbgcrZ systemd[1]: Started MariaDB database server.

A noter que l’erreur 502 de nginx n’était pas due à une mauvaise configuration du server block mais bien d’un manque d’espace disque. C’est important à vérifier, avant de se lancer dans la dissection du fichier de configuration d’nginx (qui n’aurait pas réglé le problème dans ce cas précis).

Réforme de la directive sur le droit d’auteur sur Internet

Le Parlement européen a donné son aval à la directive sur le droit d’auteur, un ensemble de lois controversé destiné à mettre à jour le droit d’auteur en Europe à l’ère de l’internet.

Les députés ont voté à 348 en faveur de la loi et 274 contre. Une proposition de dernière minute visant à supprimer la clause la plus controversée de la loi – connue sous le nom d’article 13 ou «filtre de téléchargement» – a été rejetée de près par cinq voix seulement.

La directive va maintenant être transmise aux États membres de l’UE, qui disposeront de 24 mois pour la traduire en droit national. La directive sur le droit d’auteur est en préparation depuis plus de deux ans et a fait l’objet d’un lobbying acharné de la part des géants de la technologie, des détenteurs de droits et des activistes des droits numériques.

Julia Reda, eurodéputée du parti pirate allemand qui a beaucoup dirigé l’opposition à la directive, a déclaré que c’était “un jour sombre pour la liberté de l’internet”. Andrus Ansip, vice-président de la Commission européenne et grand défenseur de la loi, a déclaré qu’il était un «grand pas en avant» qui unifierait le marché numérique européen tout en protégeant la «créativité en ligne».

Les détails de la législation devront être décidés par les différents États membres de l’UE, mais la loi aura probablement un impact considérable sur le fonctionnement d’Internet en Europe et au-delà. Comme nous l’avons vu avec le GRPD, la législation de l’UE sur la protection des données, la législation européenne peut influencer la politique américaine.

Les partisans de la directive ont déclaré qu’elle équilibrerait le terrain de jeu entre les géants américains de la technologie et les créateurs de contenu européens, en donnant aux détenteurs de droits d’auteur le pouvoir sur la manière dont les plates-formes Internet distribuent leur contenu.

Les critiques disent toutefois que la loi est vague et mal conçue, et finira par restreindre la façon dont le contenu est partagé en ligne, ce qui freine l’innovation et la liberté d’expression.

La nouvelle police d’Internet: la “taxe sur les liens” et le “filtre de téléchargement”

Les clauses les plus controversées de la directive sur le droit d’auteur – l’article 11 ou la “taxe sur les liens” et l’article 13 ou le “filtre de téléchargement” – sont restées en grande partie intactes.

L’article 11 permet aux éditeurs de facturer des plateformes telles que Google Actualités lorsqu’ils affichent des extraits d’articles d’actualité, tandis que l’article 13 (renommé Article 17 dans la version la plus récente de la législation) donne à des sites tels que YouTube de nouvelles obligations pour empêcher les utilisateurs de télécharger du contenu protégé par le droit d’auteur.

Dans les deux cas, les critiques disent que ces lois bien intentionnées créeront des problèmes. L’article 13, par exemple, pourrait conduire à l’introduction de «filtres de téléchargement» qui analyseront tout le contenu de l’utilisateur avant son téléchargement sur des sites afin de supprimer les éléments protégés par le droit d’auteur. La loi n’appelle pas explicitement de tels filtres, mais les critiques disent que ce sera inévitable, car les sites cherchent à éviter les pénalités.

Les défenseurs de la directive disent que les allégations selon lesquelles l’article 13 «tue les mèmes» sont des exagérations et que la législation prévoit des protections pour la parodie. Mais les experts affirment que tous les filtres introduits seront probablement source d’erreurs et inefficaces. Ils notent également que, compte tenu du coût de déploiement de cette technologie, la loi pourrait avoir l’effet inverse de son objectif: consolider accidentellement la domination des géants américains de la technologie sur les espaces en ligne.

Les effets possibles de la taxe sur les liens sont également difficiles à prévoir. La loi est principalement axée sur des services tels que Google Search et Google News, qui diffusent des extraits d’articles de presse. Google a déclaré que si les journaux choisissaient de facturer des licences pour ce matériel, ils seraient forcés de supprimer le contenu affiché dans Google News.

Les groupes du monde de la musique, de l’édition et du cinéma ont célébré l’adoption de la loi. “C’est un vote contre le vol de contenu”, a déclaré Xavier Bouckaert, président de l’European Magazine Media Association, dans un communiqué de presse. «Les éditeurs de toutes tailles et les autres créateurs auront désormais le droit de définir des termes et des conditions pour que les autres utilisateurs réutilisent leur contenu à des fins commerciales, ce qui n’est que juste et approprié.»

La plupart des gens craignent au contraire que leur expérience du Web ne soit affectée, car la législation aura également un impact considérable sur les hommes d’affaires. «Quiconque développe une plate-forme avec des utilisateurs de l’UE impliquant le partage de liens ou de contenu est confronté à une grande incertitude», a déclaré Tal Niv, vice-président du droit et de la politique du dépositaire de codes GitHub, dans un communiqué. “Les conséquences sont notamment l’impossibilité de développer les fonctionnalités attendues par les internautes et l’obligation de mettre en oeuvre un filtrage automatisé très coûteux et inexact.”

Message de George Orwell

Cela va conduire à encore plus de chiffrement des réseaux… et c’est George Orwell (ou bientôt George TORwell!) qui adresse un important message à tous les utilisateurs des Internets !

Mettre à jour WC avec wp-cli

Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.

Cet échec de la mise à jour de la base de données est généralement causé par le délai d’attente de PHP, en particulier sur l’environnement d’hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s’exécuter via une requête Web.

La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l’origine de problèmes.

Mise à jour de la base WooCommerce en ligne de commande

Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.

1. Connectez-vous au serveur en SSH.

2. Naviguez jusqu’à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:

wp wc update

Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :

wp wc update
Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0

3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.

La nébuleuse d’Orion, prise par Hubble.

Vous lisez actuellement cet article depuis le nouveau serveur de SkyMinds, baptisé ORION.

De mail à ORION

Le serveur précédent a été le théâtre d’une multitude de tutoriels consacrés à la série Monter un serveur dédié de A à Z, tournait sous Debian (6, 7, 8, et 9) mais était un peu limité en termes de ressources (Intel Core2 Quad Q8300 @ 2.50GHz, 4 Go de RAM, 750 Go de disque). Tant qu’il n’y avait qu’un seul site à gérer, cela convenait mais avec près d’une dizaine de sites, on touchait les limites.

ORION est bien plus confortable : Intel Xeon W3530 @ 2.80GHz, 32 Go de RAM, 2 To de disque en RAID). De quoi pouvoir monter en charge tranquillement :)

Du changement dans notre stack

Qui dit nouveau serveur, dit refonte de la stack. Vu que nous partons d’un environnement vierge, autant partir du bon pied et utiliser toutes les dernières innovations. Le serveur précédent datait de 2012 et, même s’il tournait parfaitement, il a connu pas mal de mises à jour (parfois pas très stables).

J’ai donc décidé de changer d’OS pour ORION : même si j’adore travailler sous Debian, je me suis dit que j’allais tenter Ubuntu Server 18.04 LTS. Certains tutoriels ne sont pas exactement équivalents entre Debian et Ubuntu Server donc cela promet quelques nouveaux tutoriels !

Objectif performance

Le but du nouveau serveur est d’être un peu plus à l’aise au niveau des ressources, surtout si les sites lancés récemment prennent de l’ampleur. Cela donne également un peu plus d’oxygène au serveur de bases de données.

L’autre objectif est un objectif de performance : monter un serveur dédié de manière simple et efficace, en privilégiant la sécurité et la rapidité des sites hébergés.

Voilà, c’est tout pour la note de service. Les tutoriels sont en cours d’écriture, donc bientôt disponibles sur le site !

J’ai récemment monté un nouveau serveur qui utilise MySQL 8 et après quelques jours d’utilisation, je me suis rendu compte que l’espace disque avait considérablement augmenté.

La cause ? Une multitude de fichiers logs binaires dans le répertoire d’exécution de MySQL 8 : il y en avait pour plus de 260 Go !

Les fichiers logs binaires enregistrent toutes les requêtes qui ont été effectuées par le serveur de bases de données. Inutile de dire qu’il est assez improbable que vous cherchiez à savoir quelles requêtes ont été lancées le mois dernier!

Désactivation des logs binaires

Sous MySQL 8, voici comment désactiver les logs binaires : éditez le fichier de configuration de MySQL:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

et ajoutez cette ligne sous [mysqld] :

skip-log-bin

Vous pouvez également vous connecter au serveur MySQL en ligne de commande:

mysql -u root -p

et lancer la commande suivante dans l’invite de commande MySQL:

SET sql_log_bin = 0;
PURGE BINARY LOGS BEFORE '2019-03-31';

Relancez ensuite le serveur MySQL:

service mysql restart

Il ne vous reste plus qu’à vous rendre dans le dossier d’exécution de MySQL – /etc/mysql par défaut, sauf si vous l’avez modifié – et supprimer les fichiers binlog*.

Voici un tutoriel qui vous permet de supprimer les kernels linux installés sur votre serveur/machine qui ne sont pas actuellement utilisés.

Cela est utile pour faire un peu de ménage sur la partition /boot, idéalement avant qu’elle ne soit complètement saturée. Sinon, je vous donne aussi l’astuce pour faire le ménage manuellement et retrouver APT complètement opérationnel.

Ce tutoriel a été testé sous Ubuntu Server 18.04 LTS, il est complètement transférable sous Ubuntu et Debian.

Cas de figure 1: /boot n’est pas plein à 100% et apt est opérationnel

1. On vérifie la version actuelle du kernel

uname -r

Cela nous donne la version du noyau sous laquelle tourne notre machine:

4.15.0-46-generic

2. On supprime les vieux kernels

2.a. On liste les vieux kernels

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

You will get the list of images something like below:

linux-image-4.15.0-45-generic

2.b. On supprime les vieux kernels (un par un)

sudo apt purge linux-image-4.15.0-45-generic

Une fois que les vieux kernels sont supprimés, on supprime également les paquets qui seront maintenant obsolètes:

sudo apt autoremove

Et on finit par la mise à jour de la liste des noyaux de GRUB:

sudo update-grub

Voilà, il ne vous reste plus qu’à rebooter votre machine ou votre serveur. Il ne reste que le dernier kernel.

Cas de figure 2 : apt est indisponible car /boot est plein à 100%

NOTE: cette partie du tutoriel n’est valable que si et seulement si vous ne pouvez utiliser APT parce que la partition /boot est pleine à 100%.

1. Listez les images de kernel

Obtenez la liste des images de kernels et faites la liste des kernels que vous pouvez supprimer car ils ne sont plus utilisés. Cette commande vous montre les kernels installés à l’exception de celui qui est en cours d’utilisation:

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

Voici le résultat de la commande, la liste des kernels installés mais inutilisés:

linux-image-3.19.0-59-generic
linux-image-3.19.0-61-generic
linux-image-3.19.0-65-generic
linux-image-extra-3.19.0-59-generic
linux-image-extra-3.19.0-61-generic
linux-image-extra-3.19.0-65-generic

2. Préparez la suppression

Vous devez préparer la commande qui va supprimer tous les kernels inutilisés en utilisant la brace expansion pour vous simplifier la vie. Je vous conseille d’écrire la commande dans un éditeur de texte et de bien la vérifier avant de la lancer dans le terminal.

N’oubliez pas d’exclure le kernel actuel ainsi que les deux kernels les plus récents pour pallier tout problème:

sudo rm -rf /boot/*-3.19.0-{59,61,65}-*

3. Nettoyez APT et ses messages d’avertissement à propos d’une installation partielle

sudo apt-get -f install

4. Autoremove

Enfin, on lance la commande autoremove pour supprimer les paquets relatifs aux vieilles images de kernel qui ont été rendues orphelines par le nettoyage manuel de /boot :

sudo apt autoremove

5. Mise à jour de GRUB

sudo update-grub

6. APT est opérationnel

Vous pouvez de nouveau utiliser APT et mettre à jour, installer et supprimer les paquets de votre distribution:

sudo apt update

Si vous avez suivi le tutoriel sur Flexget pour télécharger vos torrents automatiquement avec Transmission, voici un petit complément qui vous permettra de récupérer les sous-titres automatiquement, de manière périodique.

Je considère ici que l’installation de Flexget est déjà opérationnelle.

Installation de subliminal

S’il n’est déjà présent sur votre serveur/poste de travail, installez subliminal:

pip install subliminal

Configuration des sous-titres

Editez le fichier de configuration de FlexGet, config.yml et ajoutez-y cette nouvelle tâche:

tasks:
  get-subtitles:
    filesystem:
      path: 
        - d:\media\incoming         # on Windows
        - /home/incoming          # unix
      regexp: '.*\.(avi|mkv|mp4)$'  # only include filenames with these extensions
      recursive: yes
    accept_all: yes
    seen: local                     # seen shouldn't interfer with anything outside this subtitles task
    subliminal:
      languages:
        - eng
      alternatives:
        - fra
      exact_match: yes
      #only use the following providers
      providers: [addic7ed, opensubtitles, tvsubtitles]
      single: no
      hearing_impaired: yes
      authentication:               #consider using the variables plugin
        addic7ed:
          username: my_user
          password: my_password
        opensubtitles:
          username: other_user
          password: other_passsword

Pensez à éditer le chemin du répertoire qui contient vos fichiers vidéo (lignes 5-6), suivant que vous êtes sous Windows ou Unix. N’oubliez pas de mettre les identifiants de compte addic7ed et opensubtitles.

Il ne vous reste plus qu’à lancer FlexGet et celui-ci se chargera de récupérer les sous-titres de tous les fichiers vidéos contenus dans le répertoire que vous avez défini dans la configuration:

flexget execute

Enjoy!

Suite à une mauvaise manipulation, j’ai malencontreusement écrasé ma version de pip installée par APT en faisant un pip install pip. Après cela, toute commande lancée par pip donne cette erreur:

Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Pas glop! Si cela vous arrive un jour, voici comment retrouver la version pip initiale, installée par votre gestionnaire de paquet APT.

On marque python2.7 comme binaire Python par défault en le sélectionnant dans cette liste (si besoin):

update-alternatives --config python

On désinstalle pip, dans APT et dans PIP :

python -m pip uninstall pip
apt purge --autoremove python-pip

On réinstalle pip avec APT:

apt install python-pip

Et on vérifie la version de pip :

pip --version

qui nous donne:

pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

Et voilà, nous venons de retrouver une version de pip utilisable sur notre système.

Note : ne pas tenter de mettre à jour pip manuellement, il vaut mieux laisser le gestionnaire de paquet gérer les mises à jour de ce paquet lorsque cela est nécessaire, au fil des mises à jour.

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas et donnait une erreur 502 avec ce message dans les logs:

upstream sent too big header while reading response header from upstream

Si votre serveur utilise NginX, il suffit d’ajouter ces deux lignes à votre server block pour que tout rentre dans l’ordre:

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

L’augmentation de la taille des buffers permet d’envoyer toutes les données d’un coup d’un seul, ce qui résout l’erreur.

Il ne reste plus ensuite qu’à relancer le serveur NginX:

service nginx restart

Hop, problème réglé.

J’ai récemment écrit un petit script bash qui me permet de sauvegarder rapidement toutes les bases de données d’un serveur. Le script est lancé par une tâche cron automatiquement, tous les jours.

Si l’on passe l’utilisateur et le mot de passe SQL dans la requête, avec mysql ou mysqldump, vous obtiendrez très certainement le message d’avertissement suivant:

Warning: Using a password on the command line interface can be insecure.

Et pour cause : cela veut dire que n’importe qui ayant accès au serveur pourra voir, dans les logs ou avec un simple ps, vos informations de connexion à vos bases de données. Ce n’est pas ce qui se fait de mieux en matière de sécurité !

Une solution est de passer en argument un fichier qui contiendra vos données de connexion à la base de données.

Donc, au lieu d’écrire :

mysqldump -u $USER -p$PASSWORD --databases $db > $BACKUP_PATH/$date-$db.sql

Il vaut mieux écrire:

mysqldump --defaults-extra-file=/etc/mysql/mysql-backup-script.cnf --databases $db > $BACKUP_PATH/$date-$db.sql

Note: L’argument --defaults-extra-file doit venir en premier, sinon il ne sera pas interprété.

Le fichier /etc/mysql/mysql-backup-script.cnf contient les identifiants de votre utilisateur SQL qui aura les droits sur chacune des bases de données à sauvegarder. Voici à quoi il ressemble:

[client]
user = 'backup'
password = 'GIGANTIC_SECURE_PASSWORD'

Par sécurité, on restreint les droits d’accès au fichier pour qu’il ne soit pas lisible par tout le monde:

chmod 400 /etc/mysql/mysql-backup-script.cnf

Il ne vous reste qu’à créer votre cron avec votre nouvelle commande, sans montrer les identifiants SQL en clair.

Si vous possédez votre propre serveur email, géré avec Postfix, vous pouvez parfois obtenir l’avertissement suivant, lorsque vous utilisez un certificat SSL/TLS :

postfix/smtp[13461]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.166.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

La solution est très simple, il suffit d’éditer le fichier main.cf de Postfix :

nano /etc/postfix/main.cf

Et on y ajoute:

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

Sauvegardez le fichier puis relancez Postfix :

service postfix restart

Envoyez un mail depuis le serveur, vous devriez maintenant obtenir le graal :

postfix/smtp[7243]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1a]:25: TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

Et voilà, authentifié en TLS pour l’envoi de mail avec Postfix.

Les directives “HttpOnly” et “Secure”

A l’heure où la grande majorité des sites internet sont passés à HTTPS, il n’est pas rare de constater que PHP ne sert toujours pas les cookies de session avec les directives “HttpOnly” et “Secure”.

Pourtant, les directives sont bien disponibles dans le fichier php.ini, il suffit donc de les activer.

Edition de php.ini

On édite donc notre fichier php.ini:

nano /etc/php/7.2/fpm/php.ini

Et on modifie ces valeurs :

session.cookie_httponly 1
session.cookie_secure 1
session.use_only_cookies 1

Enregistrez le fichier et relancez PHP:

service php7.2-fpm restart

Testez votre site de nouveau : les cookies de session contiennent maintenant les deux nouvelles directives :

set-cookie: PHPSESSID=7d5h81tfiuna3p2p00o1v7b13q; path=/; secure; HttpOnly

Cela ne s’applique pas à tous les cookies créés par les plugins ou applications du site. Il faudrait pour cela que le serveur, nginx, possède nativement le module nginx_cookie_flag_module.