Project

General

Profile

Scripts et taches planifiees » History » Version 1

Version 1/118 - Next » - Current version
Julien Enselme, 04/04/2013 05:31 PM


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 [http://fr.wikipedia.org/wiki/Crontab 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 crontab -l (pour voir le crontab)

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

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

h2. la mise à jour des projets

sur l'installation d6 uniquement pour le moment ; devra être fait pour l'installation d7 (date du jour : 25 avril 12)
=> une fois par semaine

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 majs à 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)

Les étapes 2 à 9 sont gérés par le script maj.sh, le reste est directement écrit dans le crontab.

h2. la mise à jour des traductions

=> sur les installations d6 et d7
=> une fois par jour

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. Pour plus d'info, voir le mail de dgeo du 15 mai 2012.

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

S'il est exécuté tel quel, sans être modifié, il se contente de rétablir les bons droits sur les dossiers des sites et sur les settings.php de nos deux installations.

Il a cependant été initialement é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 effectuer cette action, il faut rentrer l'ancien et le nouveau mot de passe à la ligne sed 's/ancien_mdp/nvo_mdp/g' < $fichier.old > $fichier 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
chmod +w $x
cd $x;
echo $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/ancien_mdp/nvo_mdp/g' < $fichier.old > $fichier
chmod 400 $fichier
rm $fichier.old
cd ..
chmod -w $x
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

h3. 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

h3. 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

Pour drupal 7, on a un script plus complet : dump_site_atest_all.

On utilise d'abord le script de sauvegarde individuelle des sites ( dump_site_atest) appliqué sur tous les sites un par un. Puis on effectue également une sauvegarde complète au cas où ^

Ils se lancent n'importe où.

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

NB : 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 !).

h1. Liste des alias drush à disposition

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)

[[Catégorie: Club Drupal]][[Catégorie: Projet Multi-assos]]