Club Drupal

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.

{{toc}}

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 : <code>ssh assos@sas1.centrale-marseille</code>

# taper la commande pour voir le crontab <code>crontab -l</code>

# taper la commande pour modifier le crontab <code>crontab -e</code>. /!\ 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

{{note(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 mises à jour à faire

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

# Exécuter le [[Scripts_et_taches_planifiees#dump.sh_and_co|script de sauvegarde des bases de données]]

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

# Exécuter la [[Utilisation_de_Drupal_multi-site#Mise_à_jour_de_la_base_de_données|mise à jour des bases de données]]

# Exécuter une nouvelle fois le cron

# Exécuter le [[Scripts_et_taches_planifiees#taille.sh|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 [[Scripts_et_taches_planifiees#maj.sh| 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 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 [[Scripts_et_taches_planifiees#drush_maj_trad|l'alias drush perso <code>drush maj_trad</code>]] 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 [[Scripts_et_taches_planifiees#ch_mdp|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 :

<pre>

<code class="bash">

drushall_atest vset error_level 0 --yes

</code>

</pre>

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.

<pre>

<code class="php">

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

</code>

</pre>

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

<pre>

<code class="php">

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"]'

</code>

</pre>

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 <code>reinit_var.sh</code>.

h2. La sauvegarde des bases de données

Sur les installations d6 et d7 : une fois par semaine

On utilise les [[Scripts_et_taches_planifiees#Tout-sauvegarder|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 [[Scripts_et_taches_planifiees#purge_des_sauvegardes.sh|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 <code>sed 's/ancien_mdp/nvo_mdp/g' < $fichier.old > $fichier </code> 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 <code>ch_mdp</code> n'importe où dans le compte assos.

h3. À quoi ça ressemble ?

<pre>

<code class="bash">

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

</code>

</pre>

h2. dis_tiers.sh et en_tiers.sh

Créé en juillet 2011 dans le cadre de [[De_Drupal6_vers_Drupal7|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 ?

<pre>

<code class="bash">

##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 

</code>

</pre>

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 [[Scripts_et_taches_planifiees#ch_mdp|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 <code>drushall</code> n'importe où.

Sur l'installation d7, on lance <code>drushall_atest</code> n'importe où.

h3. À quoi ça ressemble ?

<pre>

<code class="bash">

#~/bin/sh

# si pas d'arguments :

if [ $# -lt 1 ]; then

  echo "usage: $0 <drush args>"

  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

</code>

</pre>

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 : <code>drushcronone assos.centrale-marseille.fr.cac13</code>

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 <code>dump_site nom_de_site</code> (d6) ou <code>dump_site_atest nom_du_site</code> (d7). Le nom du site à fournir est le préfixe utilisé dans la base de données.

Ils **ressemblent** à :

<pre>

<code class="bash">

#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

</code>

</pre>

h4. Tout sauvegarder

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

<pre>

<code class="bash">

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

</code>

</pre>

h3. Dump pour drupal 7

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

<pre>

<code class="bash">

#!/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

</code>

</pre>

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 [[Scripts_et_taches_planifiees#la_mise_à_jour_des_projets|paragraphe suivant]].

h3. Comment le lancer ?

<code>maj.sh</code> ou <code>maj_d7.sh</code>, 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 [[De_Drupal6_vers_Drupal7|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 <code>usep projet</code> 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)

<pre>

<code class="bash">

#si pas d'argument donnés :

if [ $# -lt 1 ]; then

  echo "usage: $0 <drush args>"

  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

</code>

</pre>

h2. Taille.sh

Ce script utilise la commande <code>du -hcs</code> 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 <code>init_var.sh</code> (ou <code>drush init</code>) dans le dossier du site.

h3. À quoi ça ressemble ?

<pre>

<code class="bash">

drush vset error_level 0 --yes

</code>

</pre>

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.

<pre>

<code class="php">

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

</code>

</pre>

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

<pre>

<code class="bash">

drush vset --always-set reverse_proxy TRUE

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

</code>

</pre>

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.

<pre>

<code>

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

</code>

</pre>

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 [[Scripts_et_taches_planifiees#la_réinitialisation_des_variables_dangeureuses|ce paragraphe]].

h3. Comment le lancer ?

Taper <code>reinit_var.sh</code> 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 <code>purge_des_sauvegardes.sh</code> n'importe où dans le compte assos.

h3. À quoi ça ressemble ?

<pre>

<code class="bash">

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

</code>

</pre>

{{important(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 [[Scripts_et_taches_planifiees#init_var.sh|init_var.sh]]. Les deux peuvent s'utiliser indifféremment.

h3. Comment l'utiliser ?

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

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

h2. drush maj_trad

h3. À quoi ça sert ?

Ce script met à jour les traductions, en suivant [[Scripts_et_taches_planifiees#la_mise_à_jour_des_traductions|la procédure décrite ici]].

h3. Comment l'utiliser ?

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

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