Un petit script pour la mise à jour d'un site "DRUPAL".

Ce script est destiné à repérer et effectuer les mises à jour du logiciel du site, il utilise "composer" et "drush" qui simplifient cette tâche.
Le script est fourni en téléchargement ICI.

1.  Ce script doit être stocké dans un répertoire du PATH pour simplifier son lancement.
2.  Il faut se positionner dans le répertoire "haut" du site :  cd /var/www/mon_site
3.  Lancer le script.
4.  Il affiche le répertoire courant pour vérification, si OK frapper "Y"
5.  Une vérification des mises à jour possibles est effectuée, si des modules sont signalés "upgrade possible" répondre "Y", sinon frapper la touche "entrée"
6.  La mise à jour commence par une mise à niveau de "drush" qui est utilisé dans ce script.
7.  La mise à jour proprement dite est lancée
8.  La mise à jour éventuelle de la base de données est effectuée
9.  Les caches sont reconstruits

Et c'est tout, cela suffit et m'a permis de passer plusieurs mises à niveau sans aucun problème.

J'utilise souvent un système de tables à deux niveaux :

1. Table "courante" dans laquelle les événements sont enregistrés
2. Table "historique" dans laquelle sont reportés les événements traités.

Ce système permet de conserver un historique tout en ayant des tables "vivantes" peu volumineuses, donc rapides à traiter. 
Ce système  implique une conservation de la valeur de l'autoincrément pour la table "courante" afin de ne pas avoir de doublons dans la table "historique". C'est encore plus important si la table d'événements est découpée en plusieurs tables physiques qui doivent conserver un identifiant commun. 
Ce phénomène était le suivant : 
Lorsque la table est vidée et qu'il ne reste plus aucun rang et que vous redémarrez Mysql/MariaDB alors l'incrément repart à 1 et fiche la panique dans ce beau système ! 
Ce phénomène est heureusement réglé dans MariaDB à partir de la version 10.3.x.

La seule solution que j'ai trouvée est d'utiliser la possibilité d'exécuter une procédure lors du démarrage de Mysql/MariaDB. J'ai donc réalisé :

1. Une procédure SQL cataloguée téléchargeable ici. 
   Cette procédure concerne une "paire" de tables : "RUN_MODSEC" pour la table événements et "HIS_MODSEC" pour la partie historique.

2. Un petit fichier SQL (ini_file) de lancement lancé par Mysql/MariaDB lors de son démarrage, ce fichier ne comporte que deux lignes :

   use ma_base;  call REINCRT();

3. Mes systèmes utilisent "systemd" j'ai donc du modifier le script "mysql.service" de la façon suivante :

Avant :   ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

Après : ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid --init-file=/etc/mysql/ini_file

C'est tout !

Cette procédure cataloguée vérifie que l'incrément de la table "vive" n'est pas à 1 et le force à la valeur de l'incrément de la table historique + 1. 
J'attends quand même avec impatience de pouvoir passer cette base sous MariaDB 10.3 qui résout, enfin, ce vieux bug. Cela devrait être effectif lors du passage de Stretch à Buster.

Ces cinq "plugins" fonctionnent avec Shinken (ils doivent d'ailleurs aussi fonctionner avec Nagios ou Centreon) et remplissent les fonctions suivantes :

check_apache.txt :  à renommer en check_apache.sh pour faire plus professionnel ...

Ce script partiellement en Python permet de suivre quelques indicateurs d'activité d'un service Apache tels que :

• le nombre d'accès,
• le nombre de KB transmis,
• Les paramétrages coté Shinken et coté serveur Apache sont précisés avec le script.
• la charge CPU "Apache,
• le nombre moyen de requêtes par seconde,
• le volume moyen par seconde,
• la taille moyenne d'une page
• le nombre de "Busy workers" et de "Idle Workers".

Ces données de performance sont utilisables par des applications externes, Omeganoc par exemple. Des alarmes (Warning et Critical) sont possibles sur le nombre de requêtes par seconde et sur un nombre minimum de "Idle workers" devant être présents.

Les trois suivants (bash pur) utilisent SNMP pour obtenir leurs données et sont construits sur le même modèle. Il ne nécessitent que peu de dépendances, à part SNMP et ses MIB bien sûr.

check_snmp_memory.txt : 
Ce script utilise "SNMP" pour obtenir les données, il est donc nécessaire de configurer "snmpd" afin de permettre l'accès à vos machines depuis la machine "Shinken". Les données récupérées sont les suivantes :

• la mémoire globale
• la mémoire "cache"
• la mémoire "buffer"
• La mémoire utilisée (hors cache et buffers)

Là aussi les données de performance sont utilisables par des applications externes. Une alarme (Warning et Critical) est possible.

check_snmp_network.txt : 
Même remarque que le précédent pour SNMP. Les données récupérées sont les suivantes :

• la vitesse en réception
• la vitesse en émission

Ces deux valeurs sont des moyennes de l'activité entre deux tests. 
Ce script utilise des fichiers dans le répertoire /tmp pour stocker les résultats du test qui servent de base au passage suivant car les valeurs lues par SNMP sont des valeurs depuis le démarrage des interfaces reseau.

check_snmp_disk.txt : 
Encore SNMP, les données récupérées sont les suivantes :

• la taille utilisée
• le pourcentage utilisé

Des alarmes (en pourcentage) pour Warning et Critical sont disponibles.

CHECK_SLAVE , mesure du "lag" des esclaves par rapport aux maîtres dispose ici d'un article à part entière.

On a souvent besoin d'afficher la durée d'une opération réalisée en shell (bash), ce script réponds à cette problématique. 
Il permet de déclencher un chronomètre puis de le stopper et d'afficher la durée entre les deux actions.

Son utilisation est très simple, intégrer dans votre script perso les lignes suivante :

1. source CHRONO.sh
2. Au début de script : CHRONO DEBUT
3. A la fin du script : CHRONO FIN

That's all folks!

Télécharger ce script (à renommer en .sh, là encore).

L'ensemble de scripts présentés ci dessous permet de sauvegarder une base Mysql/MariaDB sans pratiquement interrompre son fonctionnement. 
Pour que ces scripts soient utilisables il faut pouvoir effectuer un "snapshot" LVM du disque contenant la base, votre répertoire /var/lib/mysql est bien sur une partition LVM ? 
Ici la base est installée confortablement dans un volume LVM "posé" sur un Raid 10 de SSD ce qui permet entre autres vitesse et sécurité. 

Le principe général est le suivant :

1. Effectuer un "flush" sur la base principale, dans le style "WITH WRITE LOCK"
2. Prendre un "snaphot" de la partition LVM de la base principale
3. Noter la position du binlog ou le GTID, ça peut servir à resynchroniser un esclave restauré/créé à partir de ce dump
4. Monter ce snapshot dans le système de fichiers
5. Libérer la base principale (UNLOCK TABLES)
6. Lancer une instance Mysql/MariaDB "bis" sur le snapshot
7. Effectuer tranquillement votre dump sur une base cohérente et qui ne bouge pas !
8. Stopper la base "bis"
9. Démonter le snapshot
10. Détruire le snapshot.

Les scripts présentés effectuent l'ensemble de ces opérations : 
  
La procédure LC_DUMP réalise les opérations suivantes : 
1    : FLUSH tables sur base principale 
2    : Création et montage d'un snapshot dans le système de fichiers 
3    : Lancement nouvelle instance spécifique de Mysql/MariaDB 
4    : Lancement des dumps en parallèle de toutes les bases 
5    : Arret de l'instance spécifique 
6    : démontage et suppression du snapshot

La procédure LC_DUMP enchaîne l'ensemble des phases. 
Cet ensemble lance en parallèle les différents dumps, il faut donc, de préférence, une machine largement multiprocesseurs. Deux ou quatre processeurs par base seront les bienvenus ... et permettrons une performance maximale par utilisation du maximum de processeurs disponibles. 
Compter deux processeurs par base + N pour lbzip2. Il est aussi possible d'utiliser plusieurs fichiers paramètres avec une seule base et d'enchaîner les traitements.

Inventaire : 
1) Procédures 
LC_DUMP         
Cette procédure gère l'enchaînement des opérations 
DUMPBASES     
Réalise le dump des bases en parallèle 
GERE_SNAP     
Réalise la gestion du snapshot : 
    1 : nom du fichier paramètres (DUMP_PARAM.param) 
    2 : action à réaliser 
        - "CRE"    création et montage du snapshot 
        - "DEL" démontage et destruction du snapshot 
GERE_MYSQL     
Lance et stoppe l'instance Mysql/MariaDB spéciale dump 
    1 : nom du fichier paramètres (DUMP_PARAM.param) 
    2 : action à réaliser 
        - "start" lance l'instance 
        - "stop"  stoppe l'instance 
LC_DUMP.fct     
Fonctions communes aux différents modules.        

MYSPECIAL     
script connexion à la base "spéciale dump", en cas d'ennuis ...

2) Paramètres. 
DUMP_PARAM.param   
Contient les paramètres principaux 
    La liste des bases à dumper 
    Nom des objets répertoires, VG et sockets ... 
    Nom des fichiers de paramètres pour mysql et mysqldump 
    Quelques valeurs utilisées à des fins de contrôle de la 
    taille du snapshot : Taille mini, % devant rester à la 
    fin des opérations pour détecter une saturation de l'espace.

admin_default.cnf 
Contient les paramètres de connexion de mysql à l'instance "dump"

mysqld_default_file.cnf     
Contient le paramétrage de l'instance spécifique "dump" (type fichier "my.cnf")

mysqldump_default_file.cnf   
Contient le paramétrage de l'utilitaire "mysqldump"

serveur_local_root 
Contient le paramétrage de connexion de "root" à l'instance principale

Ces fichiers (.cnf) de configuration contiennent des couples utilisateur/mot de passe et doivent donc être tenus à l'écart des yeux indiscrets ...

Remarques : 
----------- 
Le montage de disque nécessite les droits "root" --> exécuter les procédures avec "sudo". 
Les procédures "GERE_SNAP" et "GERE_MYSQL" peuvent être exécutées "en solo" en utilisant "sudo".

Télécharger les scripts (tar.xz).

Note 2022 : cela fonctionne depuis des années et cela a déjà permis plusieurs restaurations, création d'esclaves pour des bases qui n'étaient pas ainsi sécurisées. 
Le "cluster" maître/maître avec "fail over" c'est le pied ultime de la sécurité.