Historique

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)

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 source:bin/d7-all-update-localisation.sh dans le crontab.

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

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.

Comment le lancer ?¶

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

À quoi ça ressemble ?¶

<code class="bash">
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
</code>

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 :

<code class="bash">
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
</code>

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.

Comment les lancer ?¶

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

À quoi ça ressemble ?¶

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

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.

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.

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

À quoi ça ressemble ?¶

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

drushcronone¶

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.

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.

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 !

dump.sh and co¶

Tous ces scripts se lancent n'importe où.

Dump pour drupal 6¶

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 à :

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

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 :

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

Dump pour drupal 7¶

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

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

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

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.

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.

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.

Comment le lancer ?¶

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

À quoi ça ressemble ?¶

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

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

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.

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.

Comment le lancer ?¶

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

À quoi ça ressemble ?¶

<code class="bash">
drush vset error_level 0 --yes
</code>

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.

<code class="php">
drush php-eval variable_set\(\'allow_authorize_operations\',FALSE\)\; 
</code>

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

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

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.

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

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.

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.

Comment le lancer ?¶

Taper reinit_var.sh n'importe où.

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.

Comment le lancer ?¶

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

À quoi ça ressemble ?¶

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

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 !)

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

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

Fichiers (0)

Projet

Général

Profil

Club Drupal

Wiki

La mise à jour des projets¶

La mise à jour des traductions¶

La réinitialisation des droits d'accès¶

ch_mdp¶

Comment le lancer ?¶

À quoi ça ressemble ?¶

chk_perm¶

dis_tiers.sh et en_tiers.sh¶

Comment les lancer ?¶

À quoi ça ressemble ?¶

drushall and co¶

Comment on le lance ?¶

À quoi ça ressemble ?¶

drushcronone¶

Histoire¶

Besoin¶

Usage¶

dump.sh and co¶

Dump pour drupal 6¶

Sauvegarder uniquement les tables d'un site¶

Tout sauvegarder¶

Dump pour drupal 7¶

maj.sh¶

Comment le lancer ?¶

usep¶

Comment le lancer ?¶

À quoi ça ressemble ?¶

Taille.sh¶

init_var.sh¶

Comment le lancer ?¶

À quoi ça ressemble ?¶

reinit_var.sh¶

Comment le lancer ?¶

purge_des_sauvegardes.sh¶

Comment le lancer ?¶

À quoi ça ressemble ?¶

drushall_atest_logged¶

Anciennes entrées du crontab¶