Projet

Général

Profil

Scripts archives » Historique » Version 3

Florent Torregrosa, 17/08/2014 22:28
Fix link not interpreted and that no more exists

1 2 Florent Torregrosa
2
3
4
{{>toc}}
5
6
h2. La mise à jour des projets
7
8
Voici les différentes étapes réalisées :
9
# 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é.
10
# Lancer le cron pour que les sites sachent s'il y a des mises à jour à faire
11
# Supprimer le cache des sites pour réduire drastiquement la taille des bases de données sauvegardées.
12
# Exécuter le [[Scripts_et_taches_planifiees#dump.sh_and_co|script de sauvegarde des bases de données]]
13
# Vérifier les versions des projets et au besoin, mettre à jour leur code
14
# Exécuter la [[Utilisation_de_Drupal_multi-site#Mise_à_jour_de_la_base_de_données|mise à jour des bases de données]]
15
# Exécuter une nouvelle fois le cron
16
# 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
17
# Dater les logs et les sauvegarder au bon endroit
18
# 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)
19
20
h2. La mise à jour des traductions
21
22
Sur les installations d6 et d7 : une fois par semaine le jeudi.
23
24
Voici les étapes effectuées :
25
# Activer partout le module _l10n_update_. C'est lui qui gère la mise à jour des traductions
26
# Vérifier s'il y a des nouvelles chaînes traduites disponibles
27
# Ajouter les nouvelles traductions disponibles
28
# Désactiver le module _l10n_update_
29
30 3 Florent Torregrosa
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.
31 2 Florent Torregrosa
32
h2. La réinitialisation des droits d'accès
33
34
Sur les installations d6 et d7 : toutes les semaines, après les D&D du club drupal
35
36
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 
37
* les dossiers des sites
38
* les settings.php des sites
39
40
h2. ch_mdp
41
42
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).
43
44
Pour effectuer cette action, il faut donner l'ancien et le nouveau mot de passe en argument puis lancer le script.
45
46
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.
47
48
h3. Comment le lancer ?
49
50
Il suffit de taper <code>ch_mdp</code> n'importe où dans le compte assos.
51
52
h3. À quoi ça ressemble ?
53
54
<pre>
55
<code class="bash">
56
cd [drupal directory]/sites
57
58
for x in $(ls -1 | grep -v 'all'); do
59
	cd $x;
60
	fichier="settings.php" 
61
	chmod 600 $fichier
62
	mv $fichier $fichier.old
63
        #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
64
	sed "s/$1/$2/g" < $fichier.old > $fichier
65
	chmod 400 $fichier
66
	echo "Verifier que le site fonctionne et appuyer sur la touche Entree pour continuer"
67
	read fake_variable
68
	rm $fichier.old
69
	cd ..
70
done
71
</code>
72
</pre>
73
74 1 Florent Torregrosa
h2. chk_perm
75
76
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.
77
78
Il ressemble à ça :
79
<pre>
80
<code class="bash">
81
cd [drupal directory]/sites
82
83
for dir in $(find . -type d -maxdepth 1 ! -name all)
84
do
85
    chmod 755 $dir
86
    cd $dir
87
    chmod 400 settings.php
88
    cd -
89
done
90
</code>
91
</pre>
92
93
h2. dis_tiers.sh et en_tiers.sh
94
95
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).
96
97
En effet, il s'agit de deux étapes indipensables pour la migration d'un site.
98
99
h3. Comment les lancer ?
100
101
Il suffit de taper "dis_tiers.sh" ou "en_tiers.sh" dans le dossier du site en question.
102
103
h3. À quoi ça ressemble ?
104
105
<pre>
106
<code class="bash">
107
##dis_tiers.sh
108
#écrire le nom des modules non core dans un fichier
109
drush pml |grep -v Core* | grep Module | grep Enabled > fichier.temp
110
sed -e 's/\(.*(\)\(.*\)\().*\)/\2/' fichier.temp > modules_tiers.txt
111
#désactiver ces modules
112
for line in $(cat modules_tiers.txt); do drush dis -y "$line" ; done  
113
#effacer les fichiers créés
114
rm fichier.temp
115
116
##en_tiers.sh
117
#activer ces modules du fichier texte
118
for line in $(cat modules_tiers.txt); do drush en -y "$line" ; done 
119
</code>
120
</pre>
121
122
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 :
123
* Avoir des droits d'écriture sur le dossier du site pour l'exécuter
124
* 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.
125
126
h2. drushall and co
127
128
Pour administrer tous les sites du multi-site en une seule fois, nous avons créé un script à partir de drush.
129
Il s'utilise comme drush, mais effectue la commande drush tapée sur tous les sites de l'installation un par un.
130
131
h3. Comment on le lance ?
132
133
Sur l'installation d6, on lance <code>drushall</code> n'importe où.
134
135
Sur l'installation d7, on lance <code>drushall_atest</code> n'importe où.
136
137
h3. À quoi ça ressemble ?
138
139
<pre>
140
<code class="bash">
141
#~/bin/sh
142
# si pas d'arguments :
143
if [ $# -lt 1 ]; then
144
  echo "usage: $0 <drush args>"
145
  exit 1
146
fi
147
148
cd [drupal directory]/sites
149
150
for x in $(ls -1 | grep -v 'all'); do
151
  if [ -d $x -a ! -L $x ]; then
152
    cd $x;
153
    echo $x
154
    drush $*
155
    cd -;
156
  fi
157
done
158
</code>
159
</pre>
160
161
h2. drushcronone
162
163
h3. Histoire
164
165
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_.
166
167
h3. Besoin
168
169
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.
170
171
h3. Usage
172
173
Donc pour exécuter le cron pour un seul site, il suffit de donner le nom du répertoire.
174
Exemple : <code>drushcronone assos.centrale-marseille.fr.cac13</code>
175
176
Q : Où est ce que ce script est le plus utilisé ?
177
178
R : Dans les tâches planifiés (crontab) bien sûr !
179
180
h2. dump.sh and co
181
182
Tous ces scripts se lancent n'importe où.
183
184
h3. Dump pour drupal 6
185
186
h4. Sauvegarder uniquement les tables d'un site
187
188
On a créé des scripts qui permettent de sauvegarder uniquement les tables associés à un site (et non toute la base).
189
190
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.
191
192
Ils **ressemblent** à :
193
<pre>
194
<code class="bash">
195
#récupération des tables du site dans le fichier liste_tables.temp
196
tables='_%'
197
liste="$1$tables"
198
199
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
200
201
#transformation de cette liste en une variable
202
var=$(cat liste_tables.temp)
203
204
#sauvegarde de toutes ces tables
205
suffixe="_dump.sql"
206
fichier="$1$suffixe"
207
208
mysqldump base_de_données -h serveur -u utilisateur --password=super_mot-de-passe $var > $fichier
209
210
#suppression du fichier temporaire utilisé
211
rm liste_tables.temp
212
</code>
213
</pre>
214
215
h4. Tout sauvegarder
216
217
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 :
218
<pre>
219
<code class="bash">
220
mysqldump nom_de_la_base -h serveur -u utilisateur --password=super_mot_de_passe_trop_bien > ~/chemin_vers_la/sauvegarde.dump.sql
221
</code>
222
</pre>
223
224
h3. Dump pour drupal 7
225
226
Pour drupal 7, on a un script plus complet : <code>dump_site_atest_all</code> qui repose sur @drush sql-dump@ :
227
228
<pre>
229
<code class="bash">
230
#!/bin/sh
231
PATH=/usr/local/bin:/usr/bin:/bin:/users/guest/assos/bin
232
233
sites_dir=~/htmltest/sites
234
backup_dir=~/Desktop/dump_d7
235
date=`date "+%Y-%m-%d-%Hh%Mm%Ss"`
236
237
cd $sites_dir
238
239
#Cherche dans le sous répertoire du répertoire courant sauf dans le sous répertoire
240
# all et dans les liens.
241
for dir in $(find . -maxdepth 1 -mindepth 1 -type d ! -name all )
242
do
243
    cd $dir
244
    drush sql-dump --result-file="$backup_dir/$dir.dump$date.sql"
245
    cd -
246
done
247
</code>
248
</pre>
249
250
Ce script s’exécute une fois par semaine.
251
252
h2. maj.sh
253
254
Ce script est principalement constitué d'une suite de commandes drush et d'appels à d'autres scripts du projet.
255
256
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]].
257
258
h3. Comment le lancer ?
259
260
<code>maj.sh</code> ou <code>maj_d7.sh</code>, n'importe où.
261
262
NB : il faut que le module _update_ soit activé sur tous les sites de l'installation pour que ce script fonctionne.
263
264
h2. usep
265
266
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é.
267
268
Pour le moment, il n'est fonctionnel que pour drupal 6, mais peut être adapté sans mal à drupal 7.
269
270
h3. Comment le lancer ?
271
272
Taper <code>usep projet</code> dans n'importe quel dossier de site de l'installation drupal 6.
273
274
h3. À quoi ça ressemble ?
275
276
(quelques  commentaires sont également dispo directement dans le script pour mieux comprendre son fonctionnement)
277
<pre>
278
<code class="bash">
279
#si pas d'argument donnés :
280
if [ $# -lt 1 ]; then
281
  echo "usage: $0 <drush args>"
282
  exit 1
283
fi
284
285
286
cd [drupal_directory]/sites
287
288
289
for x in $(ls -1 | grep -v 'all' | grep -v file-*); do
290
  if [ -d $x -a ! -L $x ]; then
291
    cd $x;
292
    if [ 1 = `drush pml --no-core --status=enabled | grep $1 | wc -l` ]; then
293
             echo $x; 
294
            fi
295
    cd -;
296
  fi
297
done
298
</code>
299
</pre>
300
301
h2. Taille.sh
302
303
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).
304
305
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.
306
307
h2. init_var.sh
308
309
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.
310
311
h3. Comment le lancer ?
312
313
Taper <code>init_var.sh</code> (ou <code>drush init</code>) dans le dossier du site.
314
315
h3. À quoi ça ressemble ?
316
317
<pre>
318
<code class="bash">
319
drush vset error_level 0 --yes
320
</code>
321
</pre>
322
323
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.
324
325
<pre>
326
<code class="php">
327
drush php-eval variable_set\(\'allow_authorize_operations\',FALSE\)\; 
328
</code>
329
</pre>
330
331
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é.
332
333
<pre>
334
<code class="bash">
335
drush vset --always-set reverse_proxy TRUE
336
drush vset --always-set --format=json reverse_proxy_addresses '["147.94.19.16","147.94.19.17"]'
337
</code>
338
</pre>
339
340
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.
341
<pre>
342
<code>
343
drush ev "variable_set('update_notify_emails', array('coucouuu@example.com'));"
344
</code>
345
</pre>
346
347
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)
348
Pour ne pas déranger les webmasters avec ceci, il faut mettre l'adresse du club drupal.
349
350
h2. reinit_var.sh
351
352
Ce script est utilisé pour réinitialiser des configurations et variables dangereuses sur tous les sites.
353
354
Des informations détaillées sont disponibles dans [[Scripts_et_taches_planifiees#la_réinitialisation_des_variables_dangeureuses|ce paragraphe]].
355
356
h3. Comment le lancer ?
357
358
Taper <code>reinit_var.sh</code> n'importe où.
359
360
h2. purge_des_sauvegardes.sh
361
362
Ce script permet de supprimer les vieilles sauvegardes de base de données, afin de libérer de l'espace disque.
363
364
Le script nettoie les sauvegardes de sites individuels et les sauvegardes des bases de données complètes d6 et d7.
365
366
h3. Comment le lancer ?
367
368
Il suffit de taper <code>purge_des_sauvegardes.sh</code> n'importe où dans le compte assos.
369
370
h3. À quoi ça ressemble ?
371
372
<pre>
373
<code class="bash">
374
cd [dump directory]
375
376
if [ $(ls -l | wc -l)  -gt YY ] ; then # s'il y a plus de YY fichiers alors
377
378
ls -tr | head -XX | xargs rm; #supprime les XX fichiers les plus vieux
379
380
else # sinon, alerte
381
382
echo "mon message d'erreur" | mail -s "[dump assos] mon message d'erreur" assos@centrale-marseille.fr ;
383
384
fi
385
</code>
386
</pre>
387
388
{{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 !))}}
389
390
h2. drushall_atest_logged
391
392
Pour faire des commandes drush et quelles soient logguées par site dans le dossier Desktop/log/d7/nom_du_site.log
393
394
h1. Anciennes entrées du crontab
395
396
Ces entrées ne sont plus nécessaires mais conservées pour archive :
397
398
* 03 03 * * *     /users/guest/assos/bin/drushall cron
399
* * */23 * * * echo "le crontab sas1 fonctionne, supprimer celui de scylla mnt !" | mail -s "sas1 is talking to you" assos