Protocole de test

• Une base de données de dump brute de 7Go avec innodb a été utilisée
• Cela tourne sous MySQL 5.7, c’est une veille app comme il en reste beaucoup. Il faudra tester également avec MySQL 8.0.
• VM sous ESXi avec 12 vCPU intel Xeon qui ont 5ans.

Compressions utilisées

La compression de texte se passant mal pour bzip2, je l’ai d’office exclus. J’envisage donc Gzip et XZ. Il y a le monde un seul thread avec :

• Gzip
• XZ

Et multi-thread avec :

• pigz
• pixz

Quand il n’y a plus de gain selon le niveau de compression (pouvant aller de 1 à 9), j’arrête les tests inutiles.

Tableau benchmark compression Mysqldump

Pour Gzip, il n’y a plus de gain de taille après une compression de 7.

Pour XZ, il n’y a plus de gain de taille après un niveau de 5.

Résultats de compression Mysqldump

Le meilleur temps qui ne consomme pas trop de ressources, c’est pigz avec 4 threads et une compression de niveau 3. La compression est très bonne un niveau 7, mais 3% de taille en moins pour 28% de temps en plus, est-ce utile ? Vous savez quoi utilise pour gagner 5,5x l’espace disque en impactant très peu la charge CPU.

Comme vous pouvez le voir, il y a deux options si vous avez besoin d’archiver à long terme beaucoup de données :

• soit vous cherchez la rapidité et avoir un gain important de place par rapport à gzip et vous utiliserez pixz avec un niveau 1 de compression et 2 processus.
• soit vous cherchez une compression importante et vous utiliserez pixz avec un niveau 3 de compression et 5 processus. Un niveau plus haut que 3 ne sert à rien, trop de temps perdu pour un gain minime de compression, comme on peut le voir avec un niveau 5

Si vous avez une architecture master/slave MySQL, je vous conseille de le faire sur votre slave pour éviter les lock tables sur votre master.

J’ai effectué un comparatif également pour les backups compressés d’XtraBackup.

L’article Mysqldump benchmark compression est apparu en premier sur Mon linux.

• L’identification du serveur et la sécurisation du flux
• L’identification du client
• L’authentification du client

Vous devez faire le bon compromis entre sécurité et flexibilité. Il ne faut pas forcément pousser le bouton à fond pour tous les cas de figures.

Génération des clés et certificats

Pour MQTTS, 2 options s’offre à vous comme pour un serveur HTTPS :

• générer vos certificats auto-signé
• via une autorité de certification

Dans mon cas ce n’est que du local, ce sera donc de l’auto-signé.

Je génère toujours les clés et certificats sur ma machine perso et ensuite je copie les certificats/clés sur le serveur et les clients, afin de les archiver. C’est donc à faire dans un dossier à garder sous Linux ou en WSL sous Windows.

Veillez bien à remplacer les DNS suivants par votre domaine externe pointant sur votre serveur ainsi que votre DNS interne ou IP interne pour joindre votre serveur MQTT (dans mon cas installé sur mon serveur Jeedom) : DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home

mkdir ca broker clients

#CA
openssl genrsa -out ca/ca.key 2048
openssl req -new -x509 -days 9999 -subj "/C=BE/CN=MQTT-CA/O=home" -key ca/ca.key -out ca/ca.crt

#broker
openssl genrsa -out broker/mosquitto.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-mosquitto" -key broker/mosquitto.key -out broker/mosquitto.csr
openssl x509 -req -extfile <(printf "subjectAltName = DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home,DNS:localhost,IP:127.0.0.1,IP:::1") -in broker/mosquitto.csr
 -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out broker/mosquitto.crt -days 9999 -sha256
 
#client (facultatif) si on souhaite une authentification par certificat du client au lieu de password
openssl genrsa -out clients/local-tasmotas.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-client-tasmotas" -key clients/local-tasmotas.key -out clients/local-tasmotas.csr
openssl x509 -req -in clients/local-tasmotas.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out clients/local-tasmotas.crt -days 9999 -sha256

MQTTS côté broker Mosquitto

Les certificats et clés privées doivent être archivés, ils ne le sont pas dans le backup Jeedom.

La configuration de base du fichier Debian est : /etc/mosquitto/mosquitto.conf

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

C’est conseillé d’utiliser un fichier dans conf.d : dans mon cas sous Jeedom avec l’installation du plugin jMQTT, le fichier suivant est créé et sera utilisé : /etc/mosquitto/conf.d/jMQTT.conf

Copie des fichiers nécessaires du broker sur le serveur Jeedom :

scp ca/ca.crt broker/mosquitto.crt broker/mosquitto.key jeedom:
ssh jeedom
sudo mv ca.crt mosquitto.crt mosquitto.key /etc/mosquitto/certs/
ls -l /etc/mosquitto/certs

Editer via l’interface web la configuration du fichier jMQTT.conf ou via vim /etc/mosquitto/conf.d/jMQTT.conf

• on laisse les connexions en clair du port 1883 provenant de localhost uniquement (127.0.0.1), plus d’accès en clair depuis l’extérieur (sert pour jeedom se connecter au broker Mosquitto)
• on active le port TLS 8883 sur toutes les interfaces

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key

# Only allow clients with a valid certificat (false to only trus the broker and not the clients)
require_certificate true

Rédémarrez le service et vérifier que le port 8883 est ouvert pour tous et 1883 n’est plus accessible que par 127.0.0.1 :

sudo systemctl restart mosquitto.service
sudo ss -tlpn | egrep '(1883|8883)'
LISTEN    0         100                0.0.0.0:8883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=6))
LISTEN    0         100              127.0.0.1:1883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=5))

A ce moment là, le trafic entre nos clients et notre serveur est sécurisé. Mais n’importe quel client peut se connecter à notre serveur sans mot de passe!

Basé sur la documentation jMQTT officielle, d’autres informations et erreurs courantes sont disponibles sur ce blog.

Authentification

Mes clients étant des ESP32 qui disposent de Wifi ou mon pc avec MQTT explorer pour le debug, tout en local, une authentification par mot de passe est suffisante. Je distingue les clients IoT avec un seul mot de passe et mes 2 pc avec chacun un mot de passe différent.

Pour un serveur MQTTS publique, l’authentification des clients par certificat est recommandé

1. Créer les fichiers de mot de passe : mosquitto_passwd -c <password file> <username>
   sudo mosquitto_passwd -c /etc/mosquitto/distant.passwd tasmota
2. Configurer le broker avec la ligne : password_file <path to the configuration file>
3. Ajout d’un second utilisateur sudo mosquitto_passwd /etc/mosquitto/distant.passwd hp
4. Redémarrer : sudo systemctl restart mosquitto.service

Le fichier /etc/mosquitto/conf.d/jMQTT.conf

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

Si vous préférez utiliser un mot de passe pour Jeedom en local, selon si le plugin vous l’impose, vous pouvez le faire :

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous false
persistence false
password_file /etc/mosquitto/local.passwd

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

source

L’article MQTTS sécuriser Mosquitto MQTT est apparu en premier sur Mon linux.

Voici quelques bases d’explications, que vous pouvez compléter avec la documentation officielle du protocole.

architecture de communication de MQTT

Nous avons un broker, celui qui passe les messages.
Des clients Publisher vont envoyer des messages avec un nom appelé Topic
Des clients Subscriber vont recevoir des messages s’ils sont abonnés à ce Topic

architecture du protocole MQTT

C’est organisé en Topic / sujets

On peut faire un topic racine : toto
Et des sous topic :

• toto/test1/o1
• toto/test1/o2
• toto/test2/o1
• toto/test2/o2
• toto/test3

On peut souscrire à plusieurs Topic via toto/* ou toto/#
Il n’est pas possible de mettre # pour la racine

On peut s’inscrire à plusieurs sous Topic via le + : toto/+/o1

MQTT Broker

Le plus utilisé : Mosquitto. Il est open-source et simple de configuration.

Organisation des Topic Jeedom

Il faut vous organiser à l’avance pour l’arborescence des topic qui seront utilisé chez vous. Voici ce que j’ai organisé chez moi pour les niveaux :

1. mettre le protocole passerelle
2. mettre la pièce ou une référence à la pièce
3. mettre le device
4. mettre les topics du device

Cela permet par exemple de matcher tous les objets du bureau quelque soit son protocole!

• MQTT direct : ip/piece/device/xxx
  • si plusieurs composant pour un seul objet, mettre cet objet devant le device : ip/display-rdc/matrixled-temp/xxx et ip/display-rdc/matrixled-spotify/xxx par exemple
• modbus2mqtt : modbus/rdc/device/xxx
• zigbee2mqtt : zigbee/bureau/device/xxx
• zwaveJS : zwave/bureau/device/xxx

clients

• Windows : MQTT Explorer permet le MQTT en clair, en MQTTS avec certificat serveur uniquement ou avec la pair de certificat/clé client
• Android j’en cherche encore un bon pour le debug

L’article MQTT broker est apparu en premier sur Mon linux.

Il existe une version mineure LTS 3.28.66 supportée jusque juin 2023. Plus de version LTS après cela!

L’OS utilisé passant à Ubuntu 22.04, il faut déjà trouver un intermédiaire pour faire fonctionner la version actuelle et la mettre à jour. La version installée ne supporte uniquement que PHP 7.0.

Le but à atteindre étant d’utiliser la dernière version de l’application 6.1.8 et sa version PHP supportée 8.0.

Phases de migration LimeSurvey

1. Migrer en dernière version LTS 3.28.66 (support PHP 7.4 max)
2. Mise à jour de PHP 7.0 vers 7.4
3. Migrer vers 5.6.31 (supports PHP 7.2.5 to 8.0.x)
4. Migrer vers 6.1.8 (requires PHP 7.4.x or newer)
5. Mise à jour de PHP 7.4 vers 8.0

Pré-requis

1. On va devoir utiliser une sandbox docker ayant différentes versions de PHP pour faire la migration de l’application du à l’incompatibilité entre les version PHP de l’app et la nouvelle machine
2. On va ajouter un dépôt pour gérer les versions de PHP qui ne sont pas dans le dépôt ubuntu https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main

Pour utiliser docker sous Windows, je vous réfère à mon article sur Docker Desktop.

Export/Import base de donnée LimeSurvey actuel

Export :

cd /var/www
sudo tar -czf /home/b/lime-prod.tgz limesurvey
sudo mysqldump --defaults-file=/etc/mysql/debian.cnf limesurveydb | gzip --to-stdout > /home/b/lime-prod.sql.gz

import :

scp new-srv:lime-prod.* ./
zcat lime-prod.sql.gz | sudo mysql lime
cd /data/www
sudo tar -xf /home/b/lime-prod.tgz
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

Migrer LimeSurvey en dernière version LTS

Sur la sandbox docker, ajouter le support de PHP 7.0 et 7.4 via un dépôt supplémentaire.

La version Version 3.15 ne supportant pas php 7.4, il faut passer par le 7.0 pour mettre à jour vers la 3.28.66 et puis essayer de passer php en 7.4

Situation fonctionnelle

• Ajout du dépôt

sudo add-apt-repository ppa:ondrej/php

• ajout des paquets

sudo apt update
sudo apt install php7.0 php7.0-curl php7.0-mysql php7.0-mbstring php7.0-zip php7.0-gd php7.0-ldap php7.0-simplexml
sudo apt install php7.4 php7.4-curl  php7.4-mysql  php7.4-mbstring  php7.4-zip  php7.4-gd  php7.4-ldap  php7.4-simplexml

• Switch du PHP par défaut :

sudo update-alternatives --config php
There are 3 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
* 0            /usr/bin/php8.1   81        auto mode
  1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/bin/php7.0 to provide /usr/bin/php (php) in manual mode

• Vérifier : php -v
• Activer dans apache la version à utiliser, ici 7.0 d’abord:

sudo a2dismod php8.1
sudo a2enmod php7.0
sudo systemctl restart apache2

• Importer les fichiers tgz + db

zcat limesurvey.sql.gz | mysql lime
cd /data/www
tar -xf lime-prod.tgz

• changer les accès db dans application/config/config.php

Pour le debug limesurvey :
application/config/config.php
‘debug’=>2,

Migration de LimeSurvey 3.15.3 vers 3.28.66

Notes de migration anciennes version

cd
wget https://download.limesurvey.org/latest-3.x-LTS/limesurvey3.28.66+230719.zip
cur_version=3.15.3
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey3.28.66+230719.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

Upgrade DB en console :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime_stag; with prefix :lime_ from 355 to 366
Database has been successfully upgraded to version 366

Après connexion à l’interface admin, pas de message pour upgrade la DB. Et vérifier si erreur template.

==> Etat OK, customisation logo, templates formulaire également.

Switch de PHP 7.0 vers PHP 7.4

Pour les versions suivantes, la version minimum est PHP 7.2.5 et il faut donc abandonné PHP7.0. Allons directement en 7.4 qui est censé être supporté par la version 3.28.66….

sudo update-alternatives --config php
There are 3 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.1   81        auto mode
* 1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/php7.4 to provide /usr/bin/php (php) in manual mode
Time: 0h:00m:03s
php -v
sudo a2dismod php7.0
sudo a2enmod php7.4
sudo systemctl restart apache2

==> Etat OK également!

Migrer LimeSurvey vers 5.6.31

Cette version 5.6.31 supporte PHP 7.2.5 à 8.0.x.

cd
wget https://download.limesurvey.org/latest-5.x/limesurvey5.6.31+230718.zip
cur_version=3.28.66
sudo mysqldump lime | gzip --to-stdout > lime-${cur_version}.sql.gz
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey5.6.31+230718.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

On est à la version 366 de la base de données pour rappel.

Update en console possible :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime; with prefix :lime_ from 366 to 497
Database has been successfully upgraded to version 497
Time: 0h:00m:18s

Si erreur pour faire l’update entre 418 et 497, voir si bien en php 7.4 et recommencer depuis la 3.28.66. Un oubli arrive vite…

Migrer LimeSurvey vers 6.1.8

Cette version 6.1.8 de Limesurvey nécessite PHP 7.4.x ou plus.

Upgrade 5.6.31 vers 6.1.8

Attention l’interface est très différente, à voir l’impacte sur les utilisateurs de l’application !

cd
wget https://download.limesurvey.org/latest-master/limesurvey6.1.8+230717.zip
cur_version=5.6.31
sudo mysqldump lime | gzip --to-stdout > lime-${cur_version}.sql.gz
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey6.1.8+230717.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey-$cur_version/application/config/security.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

On est à la version 497 de la base de données

Update en console possible :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime; with prefix :lime_ from 497 to 607
Database has been successfully upgraded to version 607
Time: 0h:00m:04s

Switch de PHP 7.4 vers PHP 8.0

Pour les versions suivantes de LimeSurvey, la version minimum est PHP 7.4.x. Pas d’infos officielles sur la version maximal, mais un information sur le forum :

8.1 and 8.2 are not supported, yet.
The maximum PHP version currently supported by LimeSurvey 5 is 8.0.x.

Il faut donc tester… Résultat des tests :

• PHP 7.4 est OK
• PHP 8.0 est OK
• PHP 8.1 ne semble pas supporté!!!
• PHP 8.2 non testé

Il faut donc utiliser PHP 8.0.

Installer :

sudo apt install php8.0 php8.0-curl  php8.0-mysql  php8.0-mbstring  php8.0-zip  php8.0-gd  php8.0-ldap  php8.0-simplexml
sudo a2dismod php7.4
sudo a2enmod php8.0
sudo systemctl restart apache2

sudo update-alternatives --config php
There are 4 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.1   81        auto mode
  1            /usr/bin/php7.0   70        manual mode
* 2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.0   80        manual mode
  4            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/php8.0 to provide /usr/bin/php (php) in manual mode
php -v

Conclusion

La tâche n’était pas simple sans avoir une manipulation officielle d’un changement de version application + PHP. Il faut donc faire quelques raté pour en arriver à cette manipulation. Espérant aider le plus grand nombre!

L’article LimeSurvey migration 3.15 vers 6.1.8 est apparu en premier sur Mon linux.

Si vous essayé d’utiliser les variables d’environnement https_proxy=socks5://votreserver:port vous aurez l’erreur suivante :

InvalidSchema: Missing dependencies for SOCKS support.

La solution est de télécharger les dépendances nécessaires sur une machine ayant l’accès à Internet!

Dépendances pip sur la machine ayant le net :

mkdir pipdep && cd pipdep
echo pysocks > requirements.txt
echo pyvmomi >> requirements.txt
pip download -r requirements.txt

Vous copier le dossier sur la machine cible

Installation des dépendances python pip sur la machine cible

C’est à exécuter en temps d’utilisateur pour rappel :

pip install -r requirements.txt --no-index --find-links .

Le gist est disponible sur Github

L’article Python pip installation offline de librairies est apparu en premier sur Mon linux.

Pour utiliser Nmap pour identifier l’OS Windows, vous pouvez utiliser la commande suivante :

nmap -O [IP_ADDRESS]

Pour l’identification plus poussée via le protocole SMB :

export NMAPDIR=.
mkdir scripts

wget http://nmap.org/svn/scripts/smb-os-discovery.nse

nmap --script smb-os-discovery.nse -p445 127.0.0.1

nmap -sU -sS --script smb-os-discovery.nse -p U:137,T:139 127.0.0.1

Nmap scan report for 10.xx.xx.xx
Host is up (0.00020s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: F8:BC:xx:xx:xx:xx (Unknown)
Host script results:
| smb-os-discovery:
|   OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
|   NetBIOS computer name: IHATEWINDOWS
|   Workgroup: WORKGROUP
|_  System time: 2015-03-20 22:55:05 UTC+1

Nmap done: 1 IP address (1 host up) scanned in 0.49 seconds

La librairie se trouve ici : smb-os-discovery NSE Script.

Ce ne sera que les windows répondant à SMB.

Et la version qui essaye d’authentifier l’OS comme précédemment + les hotes en samba (plus fouillis mais au moins on prouve que c’est du matos switch, linux, vmware, etc)

nmap --script smb-os-discovery.nse -O -p445 10.102.69.0/22 --exclude 10.102.69.107 > scan-$(date '+%d-%m-%Y-%H-%M.txt')

Disponible en version graphique avec zenmap.

L’article NMAP – identification exacte de l’OS d’un Windows est apparu en premier sur Mon linux.

L’utilisation est presque la même, hormis l’utilisation préférable d’un fichier my.cnf pour ne plus avoir les identifiants MySQL dans la ligne de commande… Le mot de passe est stocké dans un fichier à devoir remplir dans la variable CONFIG_mysql_mycnf_file .

D’autres bugfix ont été réglés pour des arguments actuellement dépréciés –ssl, ainsi que des problèmes lié à un accès refusé pour les tablespaces.

Pour ceux qui ne connaissent pas, AutoMySQLBackup permet un fonctionnement en mode whitelist ou blacklist des bases de données à sauvegarder. Souvent, on va lui dire que tout sauvegarder sauf information_schema, performance_schema, sys. C’est donc une sauvegarde MySQL automatique ! Et toute nouvelle base de données ajoutée sur le serveur mutualisé sera automatiquement sauvegardée ! Il permet de gérer une rétention différente pour les backups journaliers, hebdomadaires ou mensuels.

Installation d’AutoMySQLBackup

Voici les étapes d’installation :

• Pré-requis de bonne pratique, créer un utilisateur dédié au dump MySQL pour AutoMySQLBackup

CREATE USER 'automysqlbackup'@'localhost' IDENTIFIED BY  '<MOT_DE_PASSE>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'localhost' ;

• Copier le répertoire git OU directement le dernière version de l’archive

git clone https://github.com/belgotux/automysqlbackup.git
wget https://github.com/belgotux/automysqlbackup/archive/refs/heads/main.zip && unzip main.zip

• Installer le script et les fichiers de configuration

sudo bash install.sh

• Créer le fichier contenant les identifiants de connexion /etc/automysqlbackup/votre-server.cnf

[mysqldump]
user=automysqlbackup
password=""
[mysql]
user=automysqlbackup
password=""
[mysqlshow]
user=automysqlbackup
password=""

• Créer le fichier de configuration /etc/automysqlbackup/votre-server.conf en vous basant sur le template. Les points importants sont :

CONFIG_mysql_mycnf_file='/etc/automysqlbackup/votre-server.cnf'
CONFIG_mysql_dump_host='localhost'
CONFIG_backup_dir='/backup/db'
CONFIG_db_names=()  # laisser vide pour sauvegarder toutes les bases de données
CONFIG_db_month_names=() # idem
CONFIG_db_exclude=( 'information_schema' 'performance_schema' 'sys' ) # exclus ces bases
CONFIG_table_exclude=('mysql.event') # exclus cette table
CONFIG_do_monthly="01"
CONFIG_do_weekly="6"
CONFIG_rotation_daily=7
CONFIG_rotation_weekly=4
CONFIG_rotation_monthly=180
CONFIG_mysql_no_tablespaces='yes'
CONFIG_mysql_dump_use_separate_dirs='yes'
CONFIG_mysql_dump_compression='gzip'
CONFIG_mysql_dump_latest='yes'
CONFIG_mysql_dump_latest_clean_filenames='no'
CONFIG_mailcontent='quiet'
CONFIG_mail_address='root'

• Créer le cron /etc/cron.d/automysqlbackup

0 21 * * *       root    /usr/local/bin/automysqlbackup /etc/automysqlbackup/votre-server.conf > /dev/null

• Tester manuellement une première fois pour vérifier la création des dossiers daily/weekly/monthly

/usr/local/bin/automysqlbackup /etc/automysqlbackup/votre-server.conf

Voilà, vos sauvegardes MySQL sont maintenant automatisées, vous recevez un mail en cas de problème du script!

Si vous utilisez une architecture MySQL master-slave, je vous conseille de le faire sur le slave, afin de ne pas faire durer un lock table sur le master. Une désynchronisation du slave est préférable, voir un slave dédié si vous ne pouvez vous permettre une désynchro de quelques secondes

L’article AutoMySQLBackup – sauvegarde MySQL est apparu en premier sur Mon linux.

Installation du rôle basic

Pour installer ce rôle de configuration sous Debian ou Ubuntu rien de plus simple :

ansible-galaxy install belgotux.basic

Pré-requis sur un host Debian

Un playbook d’initialisation playbook-init-server.yml est à exécuter seulement sur un host Debian. Pour Ubuntu si vous avez installé en y ajoutant votre clé SSH dès l’installation, vous n’aviez rien à faire. Exemple :

ansible-playbook -i inventories/prod roles/basic/playbook-init-server.yml -e 'myhost=node9 user=devops become_meth=sudo' -kK

Pré-requis pour Debian ou Ubuntu

Vous devez copier basic.aliases.example vers basic.aliases pour pouvoir ajouter vos propres alias, il y en a déjà certains utiles dans le fichier d’exemple.

Configuration des variables Ansible

• bm prend la valeur yes pour installer des outils pour serveur physique
• ssh_key_filename clé SSH généré pour root, utile pour les accès serveur à serveur (default id_rsa)
• basic_list_users liste d’utilisateur et clé SSH :
  • name utilisateur
  • primarygroup groupe par défaut de l’utilisateur
  • groups groupes de l’utilisateur
  • pubkeys liste de clés publiques de l’utilisateur, les fichiers dans le dossier files
  • home home utilisateur (default /home/username)
  • shell prompt utilisateur (default /bin/bash)
  • create_home créer le répertoire utilisateur (default true)
  • append ajouter ou remplacer les groupes (default true to append)
  • passwd hash du mot de passe de l’utilisateur
    • mkpasswd --method=sha-512 résultat du genre $6$
    • docker run --rm -it ulikoehler/mkpasswd résultat en yescript $y$ pour ubuntu >22.04
  • generate_ssh_key générer une paire de clé SSH (default false)
• root_public_keys liste de clés publiques à copier depuis le dossier files pour root
• bash_alias_shared activer le partage d’alias (installé dans /usr/share uniquement avec l’utilisateur root via remote_user ou become dans le playbook) (default installe seulement les alias dans le répertoire home de l’utilisateur via remote_user)
• bash_alias_dir_share (default /usr/share)

optional

• auto_upgrade Configurer inattended-upgrades (default false)
• basic_packages_default Liste des paquets commun à installer
• basic_packages_extra Liste d’autres paquets supplémentaire pour un groupe ou une machine spécifiques
• staff_directories liste des répertoires qui peuvent être modifiés par le groupe staff
• basic_custom_scripts_common liste des scripts locaux commun à copier dans /usr/local/bin
• basic_custom_scripts_local liste des scripts locaux supplémentaires à copier dans /usr/local/bin (à utiliser dans hosts)

Exemple de playbook

- hosts: [homeservers,vps]
  remote_user: root
  roles:
    - name: basic
      vars: 
        basic_list_users:
          - name: belgotux
            primarygroup: belgotux
            groups: sudo,users,staff,adm
            shell: "/bin/zsh"
            passwd: $6$xxxx
            pubkeys:
              - xxx.pub
              - yyy.pub
        bash_alias_shared: yes
        staff_directories:
          - /usr/local/bin
          - /usr/local/etc
        auto_upgrade: true

L’article Ansible rôle de configuration Debian – Ubuntu est apparu en premier sur Mon linux.

L’utilisation d’un relais tel que Microsoft 365 facilite la sécurisation de nos échanges mails, car une intégration de DKIM et DMARC est déjà gérée nativement! Si vous avez déjà vos mails ou l’ensemble de votre active directory, c’est dans cette direction qu’il faut se diriger pour une mise en place efficace.

Je suppose qu’il est possible de faire cela également avec Infomaniak pour ceux disposant de comptes pro chez eux. Avec mon compte perso je n’ai pas vu cette option. Avec OVH, oubliez directement! Du temps où j’étais encore client chez eux, j’avais parlé DKIM DMARC au support, et on m’a posés des questions pour savoir pourquoi je veux ces fonctions etc. Vraiment comme si j’étais un extraterrestre! On était tout de même en 2020… Rien n’était fait pour le mail mutualisé donc… Longtemps client perso et pro je suis passé chez Infomaniak pour la partie mutualisée en partie pour cela. J’arrête le OFF là

Configuration dans l’Exchange 365

Il faut créer un connector dans mail flow > connectors > Add a connector :

L’authentification est faite par adresse IP ou certificat valide. Il faut savoir que votre serveur relais interne postfix va lui-même se connecter sur VOTRE_DNS.mail.protection.outlook.com et celui-ci présente un certificat valide. Votre « client » va donc authentifier le serveur de Microsoft comme valide (notre serveur relais est client par rapport au relais M365).

L’authentification par IP est déjà suffisante en soit. Mais vous pouvez décider que les serveurs relais de Microsoft n’acceptent QUE les mails si le serveur client (votre relais SMTP) présente le bon certificat client. Ce qui fait qu’il y a une identification et authentification de part et d’autre!

• Configurer une restriction par votre IP publique de sortie :

• Configurer une restriction par un certificat valide : dans ce cas cela ne doit pas forcément être le certificat *.votredomain.tld, cela peut très bien être monrelais.mondomainetechnique.tld. La seule règle étant que ce certificat soit émis par une autorité de certification reconnue.

Mettre un certbot avec let’s encrypt sur votre serveur est envisageable si vous utilisez une vérification let’s encrypt par dns.

Si vous souhaitez plus d’infos, la documentation Microsoft est bien faite.

Remarque : Les limites d’envoie pour M365 sont larges et dépendent de votre licence.

Un mot sur le serveur Postfix

Il faut tout de suite savoir que Postfix est à la fois un serveur et un client. Il faut donc bien distinguer les directives. Veillez donc bien au début qui peut être :

• smtp_tls_xxx en tant que client
• smtpd_tls_xxx en tant que serveur

Notre serveur relais est serveur par rapport à nos serveurs internes. Il est client par rapport à Microsoft 365.

Configuration de notre relais mail Postfix

J’ai distingué les directives serveurs et clients pour que la configuration soit lisible.

Pour le comportement serveur du relais SMTP :

• smtpd_tls_security_level=may permet de spécifier que notre serveur accepte une liaison client en TLS mais également en clair. Il faut penser aux copieurs ou autre matériel ne gérant pas le TLS interne à notre réseau
• smtpd_tls_loglevel permet d’avoir une trace des connexions TLS dans les logs avec les ciphers pris en compte, pratique pour voir quel client envoie encore en clair et s’il peut être modifié
• smtpd_tls_cert_file et smtpd_tls_key_file renseignent le certificat et la clé utilisé en interne
• smtpd_tls_chain_files est le nouveau format pour pouvoir contenir plusieurs clés et certificats pour différents noms de domaine. Il faut toujours la clé et puis la chaîne de certificat et le certificat final
• smtpd_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés

### SERVER ###
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1

smtpd_tls_cert_file=/etc/xxx.crt
smtpd_tls_key_file=/etc/xxx.key
#alternative
#smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all

#optionel
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache



### CLIENT ###
relayhost = your-domain.mail.protection.outlook.com
smtp_tls_security_level = encrypt # optionnel : secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
#optionnel
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_chain_files = /etc/xxx.all

Pour le comportement client du relais SMTP :

• relayhost on vient mettre le DNS de notre tenant M365
• smtp_tls_security_level le niveau de securité minimal accepté en TLS. Je vous conseille secure
• smtp_tls_mandatory_ciphers high contient un « bundle » de ciphers satisfaisant
• smtp_tls_loglevel permet d’avoir une trace des connexions TLS
• smtp_tls_CAfile permet de spécifié le fichier des CA faisant autorité. Un fichier du système contient déjà les CA connus du monde
• smtp_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés
• smtp_tls_chain_files spécifiez la chaine de certificats client qui est utiliser si vous aviez choisi une restriction par un certificat client pour votre connector M365. L’ordre dans la chaine est importante : votre clé privée, suivie de votre certificat, ensuite le certificat intermédiaire et pour finir le certificat du CA

host xxx.mail.protection.outlook.com[104.47.2.7] said: 550 5.4.1 Recipient address rejected: Access denied. AS(201776281) [AB4EUR01RT057.eop-EUR01.prod.protection.outlook.com] (in reply to RCPT TO command)

postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: matched peername: *.mail.protection.outlook.com
postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: subject_CN=mail.protection.outlook.com, issuer_CN=DigiCert Cloud Services CA-1, fingerprint=6A:DD:32:6D:2A:0C:C5:3A:9E:D7:E7:91:3D:6F:5C:F4, pkey_fingerprint=20:78:41:CD:EC:4F:19:7A:E0:B2:01:4F:3C:3D:1C:EE
postfix/smtp[71318]: Verified TLS connection established to your-domain.mail.protection.outlook.com[104.47.0.36]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Fichier main.cf d’un relais SMTP Postfix complet :

myorigin = /etc/hostname
mydomain = your-local-domain
mydestination = $myhostname, $myorigin, localhost.localdomain, localhost, localhost.your-local-domain

# Backward compatibility off
compatibility_level = 3.6
relay_domains = $mydestination
append_dot_mydomain = yes
smtputf8_enable=yes
smtpd_banner = $myhostname ESMTP
biff = no
readme_directory = no

# TLS parameters server
smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all
#alternative
#smtpd_tls_cert_file=/etc/xxx.cer
#smtpd_tls_key_file=/etc/xxx.key
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# TLS parameters client
relayhost = xxx.mail.protection.outlook.com
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Client certificat to be identified by M365
#smtp_tls_chain_files = /etc/xxx.all

smtpd_client_restrictions = permit_mynetworks reject
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

mynetworks = 10.0.0.0/22,xxx
mailbox_size_limit = 0
message_size_limit = 29480000
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

header_checks = regexp:/etc/postfix/header_checks_regexp
smtp_header_checks = regexp:/etc/postfix/replace_header_checks_regexp

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

Configuration d’un serveur client interne linux

Voici la partie TLS d’un fichier main.cf d’un postfix « satellite » qui se connecte à notre relais interne. Il dois évidement avoir le certificat serveur de notre relais ou notre CA interne de configuré dans les certificats du système ou via la directive smtp_tls_CAfile.

smtp_tls_security_level = may
smtp_tls_loglevel = 1
#optionnel
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

L’article Relais mail Postfix – envoyer ses mails sécurisés vers M365 est apparu en premier sur Mon linux.

J’explique ici le cas où le suffixe DNS interne est yourdomain.lan et le domaine externe est your-domain.tld

D’abord il faut distinguer 2 types de mails :

• Ceux envoyés directement à partir de la machine ou une de ses applications locales
• Ceux envoyés depuis la machine qui fait office de relais.

Ce sont bien 2 choses différentes pour postfix et donc 2 types de filtre différents.

Filtre de sortie pour les mails générés sur la machine

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

/^(.*)@(.*)\.your-local-domain\.lan$/ ${2}-${1}@your-domain.tld
/^(.*)\ <(.*)@(.*)\.your-local-domain\.lan>$/ ${1} <${3}-${2}@your-domain.tld>

postmap /etc/postfix/sender_canonical_regexp

Vous pouvez toujours ajouter un « catch all » à la fin comme décrit dans l’article précédent de réécriture de mail simple avec postfix.

Filtre de sortie pour les mails transitant sur notre relais interne

Typiquement vous avez un relais mail interne utilisé par vos autres serveurs. Il faut dans un premier temps ajouter votre adresse IP publique de sortie dans le champ SPF de votre nom de domaine. Le DKIM et DMARC permettent de sécurisé encore mieux l’authenticité de vos messages, mais une chose à la fois

Vous pouvez utilisez la directive header_checks ou smtp_header_checks. Dans mon cas j’ai besoin de faire 2 opérations pour le même filtre mail, ce qui n’est pas possible de base. Mais en jouant avec ces 2 directives, je peux arriver à mes fins : marquer les mails à problème et faire une réécriture de mail :
ATTENTION à l’ordre : c’est d’abord header_checks qui est interprété et ensuite smtp_header_checks. Il faut d’abords mettre le WARN et ensuite le REPLACE

header_checks = regexp:/etc/postfix/warn_checks_regexp
smtp_header_checks = regexp:/etc/postfix/header_checks_regexp

/^From:\ (.*)@(.*)\.yourdomain\.lan$/ WARN bad sender
/^From:\ (.*)\ <(.*)@(.*)\.yourdomain\.lan>$/ WARN bad sender

/^From:\ (.*)@(.*)\.your-local-domain\.lan$/ REPLACE From: ${2}-${1}@your-domain.tld
/^From:\ (.*)\ <(.*)@(.*)\.your-local-domain\.lan>$/ REPLACE From: ${1} <${3}-${2}@your-domain.tld>

postmap /etc/postfix/warn_checks_regexp
postmap /etc/postfix/header_checks_regexp

Le reste de votre configuration postfix dépendra :

• Si vous envoyez directement les mails vers Internet, auquel cas je vous conseille de configurer les signatures DKIM et d’utiliser le record DNS DMARC
• Si vous utilisez un serveur relais tel que M365 si vous y géré déjà vos services mails

L’article Réécriture de mail – serveur relais postfix est apparu en premier sur Mon linux.