Project

General

Profile

Scripts et taches planifiees » History » Version 18

« Previous - Version 18/118 (diff) - Next » - Current version
Julien Enselme, 08/04/2013 11:59 AM
Tout est dans le script


Afin de gagner du temps et d'éviter les erreurs humaines, des scripts ont été écrits tout au long du projet. Certains sont même exécutés automatiquement toutes les semaines.

h1. Les tâches planifiées

Pour exécuter ces tâches régulièrement, on utilise le "crontab":http://fr.wikipedia.org/wiki/Crontab. Il s'agit d'un programme installé sur notre serveur.

Pour voir et modifier la liste des actions :

se connecter au serveur : ssh assos@sas1.centrale-marseille

taper la commande pour voir le crontab crontab -l

taper la commande pour modifier le crontab crontab -e. /!\ Ne pas effectuer cette opération avant de s'être renseigné sur "vi":http://fr.wikipedia.org/wiki/Vi (l'éditeur de texte utilisé qui n'est pas vraiment intuitif :p) et sur "la syntaxe du crontab":http://fr.wikipedia.org/wiki/Crontab#Modification !

Voici la liste des tâches effectuées régulièrement.

h2. La mise à jour des projets

Voici les différentes étapes réalisées :

Activer partout le module update. C'est lui qui gère la vérification des versions, l'envoi de notifications par mail ainsi que les mises à jour via drush, il est donc indispensable qu'il soit activé.

Lancer le cron pour que les sites sachent s'il y a des mises à jour à faire

Supprimer le cache des sites pour réduire drastiquement la taille des bases de données sauvegardées.

Exécuter le script de sauvegarde des bases de données

Vérifier les versions des projets et au besoin, mettre à jour leur code

Exécuter la mise à jour des bases de données

Exécuter une nouvelle fois le cron

Exécuter le script de rapport sur la taille utilisée du disque et l'envoyer par mail au club Drupal

Dater les logs et les sauvegarder au bon endroit

Désactiver le module update (vu qu'il est réactivé avant la mise à jour et que celle-ci a lieu toutes les semaines, il y a peu d'intérêt à le garder activé le reste du temps)

h2. La mise à jour des traductions

Sur les installations d6 et d7 : une fois par semaine le jeudi.

Voici les étapes effectuées :

Activer partout le module l10n_update. C'est lui qui gère la mise à jour des traductions

Vérifier s'il y a des nouvelles chaînes traduites disponibles

Ajouter les nouvelles traductions disponibles

Désactiver le module l10n_update

Pour drupal 6, les différentes instructions sont écrites directement dans le crontab. Pour drupal 7, on utilise l'alias drush perso drush maj_trad dans le crontab.

h2. La réinitialisation des droits d'accès

Sur les installations d6 et d7 : toutes les semaines, après les D&D du club drupal

Cette tâche utilise le script ch_mdp afin de rétablir les droits d'accès recommandés par drupal sur

  • les dossiers des sites
  • les settings.php des sites

h2. La réinitialisation des variables dangeureuses

Sur l'installation d7 principalement : une fois par semaine

Cette tâche consiste à réinitialiser certaines variables qui donnent des droits considérés comme trop permissifs donc dangereux aux administrateurs des sites. En voici la liste :


drushall_atest vset error_level 0 --yes

Cette commande permet de ne pas afficher les messages d'erreurs aux utilisateurs autre que les administrateurs. En effet, ils contiennent parfois des informations sensibles sur l'installation et ne doivent donc pas être divulgués à n'importe qui.


drushall_atest php-eval variable_set(\'allow_authorize_operations\',FALSE)\;

Cette commande permet de ne pas autoriser les utilisateurs à installer et mettre à jour des modules via l'interface du site (fonctionnalité introduite dans drupal7). En effet, seul le club Drupal maintient les codes des projet, afin d'en garantir la pérennité.

drushall_atest vset --always-set reverse_proxy TRUE
drushall_atest vset --always-set --format=json reverse_proxy_addresses '["147.94.19.16","147.94.19.17"]'


Ces commandes permettent de déclarer à drupal les serveurs proxy du CRI afin d'éviter qu'il ne répertorie tous les visiteurs comme ayant l'adresse des sus-cités serveurs. Pas fini : voir http://assos.centrale-marseille.fr/content/t%C3%A2che/d%C3%A9clarer-les-proxy-du-cri-%C3%A0-drupal

h3. Comment le lancer ?

N'importe où, taper reinit_var.sh.

h2. La sauvegarde des bases de données

Sur les installations d6 et d7 : une fois par semaine

On utilise les scripts de sauvegarde créés par le club Drupal.

h2. La purge des sauvegardes de bdd

Sur les installations d6 et d7 : toutes les semaines

Cette tâche utilise le script de purge des sauvegardes afin de libérer de l'espace disque en supprimant les sauvegardes de bdd les plus vieilles.

h1. Liste des scripts à disposition

Les scripts utilisés sont hébergés dans le répertoire bin du compte assos.

h2. ch_mdp

Il a été écrit pour permettre de prendre acte de la modification du mot de passe de la base de données rapidement dans tous les settings.php (pour l’installation de drupal 6 uniquement, les sites drupal 7 étant chacun dans leur base de données).

Pour effectuer cette action, il faut donner l'ancien et le nouveau mot de passe en argument puis lancer le script.

Plus d'info sur comment ça marche en lisant http://fr.wikipedia.org/wiki/Stream_Editor#Utilisation_la_documentation_de_la_commande_sed et les commentaires laissés dans le code du script.

h3. Comment le lancer ?

Il suffit de taper ch_mdp n'importe où dans le compte assos.

h3. À quoi ça ressemble ?

cd [drupal directory]/sites

for x in $(ls -1 | grep -v 'all'); do
cd $x;
fichier="settings.php"
chmod 600 $fichier
mv $fichier $fichier.old
#remplacer la première chaine après le / par l'ancien mot de passe, et la seconde chaine (après le deuxième /) par le nouveau mot de passe
sed "s/$1/$2/g" < $fichier.old > $fichier
chmod 400 $fichier
echo "Verifier que le site fonctionne et appuyer sur la touche Entree pour continuer"
read fake_variable
rm $fichier.old
cd ..
done

h2. chk_perm

Ce script rétablit les permissions des dossiers des sites, des scripts et des settings.php. Il se lance tous les jours grâce au cron.

Il ressemble à ça :


cd [drupal directory]/sites

for dir in $(find . -type d -maxdepth 1 ! -name all)
do
chmod 755 $dir
cd $dir
chmod 400 settings.php
cd -
done

h2. dis_tiers.sh et en_tiers.sh

Créé en juillet 2011 dans le cadre de la migration de d6 à d7, ces scripts permettent respectivement de désactiver et réactiver tous les modules tiers (c'est-à-dire les modules qui ne font pas partie du noyau / core de drupal, ceux qui sont installé dans sites/all/modules).

En effet, il s'agit de deux étapes indipensables pour la migration d'un site.

h3. Comment les lancer ?

Il suffit de taper "dis_tiers.sh" ou "en_tiers.sh" dans le dossier du site en question.

h3. À quoi ça ressemble ?

##dis_tiers.sh
#écrire le nom des modules non core dans un fichier
drush pml |grep -v Core* | grep Module | grep Enabled > fichier.temp
sed -e 's/(.()(.)().*)/\2/' fichier.temp > modules_tiers.txt
#désactiver ces modules
for line in $(cat modules_tiers.txt); do drush dis -y "$line" ; done

#effacer les fichiers créés
rm fichier.temp

##en_tiers.sh
#activer ces modules du fichier texte
for line in $(cat modules_tiers.txt); do drush en -y "$line" ; done

NB : dis_tiers.sh crée un fichier texte contenant la liste des modules tiers qui étaient activés sur le site. Il faut donc :

  • Avoir des droits d'écriture sur le dossier du site pour l'exécuter
  • Penser à supprimer ce fichier et à remettre les droits correctement (par exemple en lançant le script ch_mdp ) après.

h2. drushall and co

Pour administrer tous les sites du multi-site en une seule fois, nous avons créé un script à partir de drush.
Il s'utilise comme drush, mais effectue la commande drush tapée sur tous les sites de l'installation un par un.

h3. Comment on le lance ?

Sur l'installation d6, on lance drushall n'importe où.

Sur l'installation d7, on lance drushall_atest n'importe où.

h3. À quoi ça ressemble ?

#~/bin/sh

si pas d'arguments :

if [ $# -lt 1 ]; then
echo "usage: $0 "
exit 1
fi

cd [drupal directory]/sites

for x in $(ls -1 | grep -v 'all'); do
if [ -d $x -a ! -L $x ]; then
cd $x;
echo $x
drush $*
cd -;
fi
done

h2. drushcronone

h3. Histoire

Ce script a été introduit pour la version 6 du projet essentiellement pour améliorer les performances : au lieu de faire un wget sur le cron.php d'un site, valait mieux exécuter le script en interne.

h3. Besoin

La version 7 du projet en a besoin plus que jamais ! puisque le cron.php n'est plus 'wget'able sans une chaîne de codes à ajouter à l'url publique, sinon il faut avoir les droits nécessaires.

h3. Usage

Donc pour exécuter le cron pour un seul site, il suffit de donner le nom du répertoire.
Exemple : drushcronone assos.centrale-marseille.fr.cac13

Q : Où est ce que ce script est le plus utilisé ?

R : Dans les tâches planifiés (crontab) bien sûr !

h2. dump.sh and co

Tous ces scripts se lancent n'importe où.

h3. Dump pour drupal 6

h4. Sauvegarder uniquement les tables d'un site

On a créé des scripts qui permettent de sauvegarder uniquement les tables associés à un site (et non toute la base).

Ils se lancent n'importe où (mais attention, la sauvegarde est effectuée là où il est lancé, donc à ne pas lancer dans dossier accessible par n'importe qui !) en tapant dump_site nom_de_site (d6) ou dump_site_atest nom_du_site (d7). Le nom du site à fournir est le préfixe utilisé dans la base de données.

Ils ressemblent à :


#récupération des tables du site dans le fichier liste_tables.temp
tables='_%'
liste="$1$tables"

mysql -h serveur -u utilisateur --password=super_mot-de-passe -BNe "show tables like '"$liste"'" base_de_données | tr '\r\n' ' ' > liste_tables.temp

#transformation de cette liste en une variable
var=$(cat liste_tables.temp)

#sauvegarde de toutes ces tables
suffixe="_dump.sql"
fichier="$1$suffixe"

mysqldump base_de_données -h serveur -u utilisateur --password=super_mot-de-passe $var > $fichier

#suppression du fichier temporaire utilisé
rm liste_tables.temp

h4. Tout sauvegarder

Pour drupal 6, on a un script qui réalise la sauvegarde de toute la base en une seule fois : dump.sh. Il ressemble à ça :


mysqldump nom_de_la_base -h serveur -u utilisateur --password=super_mot_de_passe_trop_bien > ~/chemin_vers_la/sauvegarde.dump.sql

h3. Dump pour drupal 7

Pour drupal 7, on a un script plus complet : dump_site_atest_all qui repose sur @drush sql-dump@ :

#!/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin:/users/guest/assos/bin

sites_dir=~/htmltest/sites
backup_dir=~/Desktop/dump_d7
date=date "+%Y-%m-%d-%Hh%Mm%Ss"

cd $sites_dir

#Cherche dans le sous répertoire du répertoire courant sauf dans le sous répertoire

all et dans les liens.

for dir in $(find . -maxdepth 1 -mindepth 1 -type d ! -name all )
do
cd $dir
drush sql-dump --result-file="$backup_dir/$dir.dump$date.sql"
cd -
done

Ce script s’exécute une fois par semaine.

h2. maj.sh

Ce script est principalement constitué d'une suite de commandes drush et d'appels à d'autres scripts du projet.

Plus d'info sur les étapes précises dans les commentaires du script lui-même et dans le paragraphe suivant.

h3. Comment le lancer ?

maj.sh ou maj_d7.sh, n'importe où.

NB : il faut que le module update soit activé sur tous les sites de l'installation pour que ce script fonctionne.

h2. usep

Ce script a été créé dans le cadre de la migration de drupal 6 à drupal 7 mais peut être utilisé pour des tas de choses : il permet de savoir quels sont les sites qui utilisent (c'est-à-dire qui ont activé) un projet donné.

Pour le moment, il n'est fonctionnel que pour drupal 6, mais peut être adapté sans mal à drupal 7.

h3. Comment le lancer ?

Taper usep projet dans n'importe quel dossier de site de l'installation drupal 6.

h3. À quoi ça ressemble ?

(quelques commentaires sont également dispo directement dans le script pour mieux comprendre son fonctionnement)


#si pas d'argument donnés :
if [ $# -lt 1 ]; then
echo "usage: $0 "
exit 1
fi

cd [drupal_directory]/sites

for x in $(ls -1 | grep -v 'all' | grep -v file-*); do
if [ -d $x -a ! -L $x ]; then
cd $x;
if [ 1 = drush pml --no-core --status=enabled | grep $1 | wc -l ]; then
echo $x;
fi
cd -;
fi
done

h2. Taille.sh

Ce script utilise la commande du -hcs pour retourner l'espace disque utilisé sur le compte assos, ainsi que sa répartition dans les différents répertoires des sites).

Ce script est notamment utilisé à la fin du script de mise à jour de projet ; son résultat est envoyé par mail au club drupal pour vérification.

h2. init_var.sh

Ce script permet d'initialiser des configurations et variables dangereuses, pour l'installation drupal 7. Il faut le lancer après chaque installation de sous-site.

h3. Comment le lancer ?

Taper init_var.sh (ou drush init) dans le dossier du site.

h3. À quoi ça ressemble ?

drush vset error_level 0 --yes

Cette commande permet de ne pas afficher les messages d'erreurs aux utilisateurs autre que les administrateurs. En effet, ils contiennent parfois des informations sensibles sur l'installation et ne doivent donc pas être divulguées à n'importe qui.

drush php-eval variable_set(\'allow_authorize_operations\',FALSE)\;

Cette commande permet de ne pas autoriser les utilisateurs à installer et mettre à jour des modules via l'interface du site (fonctionnalité introduite dans drupal7). En effet, seul le club Drupal maintient les codes des projet, afin d'en garantir la pérennité.

drush vset --always-set reverse_proxy TRUE
drush vset --always-set --format=json reverse_proxy_addresses '["147.94.19.16","147.94.19.17"]'

Ces commandes permettent de déclarer à drupal les serveurs proxy du CRI afin d'éviter qu'il ne répertorie tous les visiteurs comme ayant l'adresse des sus-cités serveurs. Pour plus d'info, voir le mail de dgeo du 15 mai 2012.


drush ev "variable_set('update_notify_emails', array('coucouuu@example.com'));"

Cette commande permet de modifier l'adresse de la personne qui recevra des notifications lorsqu'une nouvelle mise à jour (projet ou noyau drupal) est disponible (NB : c'est le module (du noyau) update qui gère ces envois, s'il est désactivé, aucune vérification des versions n'est effectuée)
Pour ne pas déranger les webmasters avec ceci, il faut mettre l'adresse du club drupal.

h2. reinit_var.sh

Ce script est utilisé pour réinitialiser des configurations et variables dangereuses sur tous les sites.

Des informations détaillées sont disponibles dans ce paragraphe.

h3. Comment le lancer ?

Taper reinit_var.sh n'importe où.

h2. purge_des_sauvegardes.sh

Ce script permet de supprimer les vieilles sauvegardes de base de données, afin de libérer de l'espace disque.

Le script nettoie les sauvegardes de sites individuels et les sauvegardes des bases de données complètes d6 et d7.

h3. Comment le lancer ?

Il suffit de taper purge_des_sauvegardes.sh n'importe où dans le compte assos.

h3. À quoi ça ressemble ?

cd [dump directory]

if [ $(ls -l | wc -l) -gt YY ] ; then # s'il y a plus de YY fichiers alors

ls -tr | head -XX | xargs rm; #supprime les XX fichiers les plus vieux

else # sinon, alerte

echo "mon message d'erreur" | mail -s "[dump assos] mon message d'erreur" assos@centrale-marseille.fr ;

fi

Ce script supprime les x sauvegardes les plus vieilles de chaque catégorie (sites d7, tout d6, tout d7), sans aucune notion de temps. Cela implique que si des sauvegardes ont été faites manuellement, des sauvegardes automatiques plus vieilles seront supprimées (alors qu'elles ne sont pas nécessairement périmées !)

h2. drushall_atest_logged

Pour faire des commandes drush et quelles soient logguées par site dans le dossier Desktop/log/d7/nom_du_site.log

h1. Liste des alias drush à disposition

à ne plus utiliser : passer par les scripts

Les alias drush sont hébergés dans le fichier drushrc.php du .drush du compte assos.

h2. drush init

h3. À quoi ça sert ?

Ce script initialise les variables dangereuses, en faisant appel au scrit init_var.sh. Les deux peuvent s'utiliser indifféremment.

h3. Comment l'utiliser ?

Dans le dossier d'un site (drupal 7 uniquement), taper drush init (ou init_var.sh).

Pour initialiser les variables de tous les sites (drupal 7 uniquement), dans le dossier sites, taper drushall_atest init

h2. drush maj_trad

h3. À quoi ça sert ?

Ce script met à jour les traductions, en suivant la procédure décrite ici.

h3. Comment l'utiliser ?

Dans le dossier d'un site (drupal 6 ou 7), taper drush maj_trad.

Pour mettre à jour les traductions de tous les sites (drupal 7 ou 6), dans le dossier sites, taper drushall maj_trad (ou drushall_atest maj_trad selon le cas).

h1. Anciennes entrées du crontab

Ces entrées ne sont plus nécessaires mais conservées pour archive :

  • 03 03 * * * /users/guest/assos/bin/drushall cron
  • * */23 * * * echo "le crontab sas1 fonctionne, supprimer celui de scylla mnt !" | mail -s "sas1 is talking to you" assos