Projet

Général

Profil

Actions
Historique

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.

Les tâches planifiées

Crontab

Pour exécuter ces tâches régulièrement, on utilise le crontab. Il s'agit d'un programme installé sur notre serveur et qui exécute des actions à intervalles réguliers.

Pour voir et modifier la liste des actions :

  1. se connecter au serveur : ssh
  2. taper la commande pour voir le crontab crontab -l
  3. taper la commande pour modifier le crontab crontab -e.

{{important(Ne pas effectuer cette opération avant de s'être renseigné sur vi (l'éditeur de texte utilisé qui n'est pas vraiment intuitif :p) et sur la syntaxe du crontab ! Les scripts doivent si possible s’exécuter avant le club Drupal pour que les problèmes éventuels y soient réglés)}}

{{tip(Pour utiliser un autre éditeur que vi taper : export EDITOR=editor_name exemple : vim, nano.)}}

{{important(d7-all-update-contrib.sh fait des sauvegardes automatiques individuelles pour les sites Drupal 7 en faisant appel à d7-all-dump-indiviual.sh auto. C'est pour cela que d7-all-dump-individual.sh auto n'est pas appelé dans le crontab.)}}

<code class="php">
######## How to use
# mm hh jj MMM JJJ task
# minutes hour day_month month day_week
# for more informations : https://fr.wikipedia.org/wiki/Crontab#Notation
######## End how to
# Update content type site on default when making changes here

### Cleaning
00 5 * * * /home/assos/bin/all-reset-permissions.sh > /dev/null
00 6 * * * /home/assos/bin/delete-temporary-files.sh > /dev/null


### Git report
00 12 * * * /home/assos/bin/git-report.sh


### Drupal 7 cron
00 * * * * /home/assos/bin/d7-all-drush.sh -q cron 2>&1 | /home/assos/bin/log.sh "Drush cron"

### Databases
# Create backup
00 8 1,15 * * /home/assos/bin/d7-all-dump-full.sh > /dev/null || mail -s "d7-all-dump-full.sh did not run correctly" assos

# flush backup
00 8 2,16 * * /home/assos/bin/flush-full-databases-backups.sh d7 > /dev/null
00 23 * * 2   /home/assos/bin/flush-individual-databases-backups.sh auto d7 > /dev/null
00 1 * * 3    /home/assos/bin/flush-individual-databases-backups.sh manual d7 > /dev/null


### Drupal 7
00 3 * * 4  /home/assos/bin/d7-all-reset-variables.sh 2>&1 | /home/assos/bin/log.sh "d7-all-reset-variables.sh"
00 22 * * 3 /home/assos/bin/d7-all-update-contrib.sh 2>&1 | /home/assos/bin/log.sh "d7-all-update-contrib.sh"
00 1 * * 4  /home/assos/bin/d7-all-update-localisation.sh 2>&1 | /home/assos/bin/log.sh "d7-all-update-localisation.sh"
00 2 * * 4  /home/assos/bin/d7-all-security-review.sh 2>&1 | /home/assos/bin/log.sh "d7-all-security-review.sh"
00 4 * * 4  /home/assos/bin/sauron.sh settings.load_settings:project=assos update.check_update:send_mail=True > /dev/null

00 22 * * 6 /home/assos/bin/d7-all-usage.sh
00 22 * * 7 /home/assos/bin/disk-usage.sh


### Log report
55 23 * * * /home/assos/bin/log-report.sh
0 0 * * 0 /home/assos/bin/purge-logs.sh
</code>

La liste des tâches effectuées régulièrement est ci-dessous.

{{important(Lors de l’import d’un script de configuration comme scripts-config.sh sont chemin doit être donné de façon absolue. Sinon le crontab ne trouvera pas le script !)}}

La réinitialisation des variables

Cette tâche consiste à réinitialiser certaines variables qui donnent des droits considérés comme trop permissifs donc dangereux aux administrateurs des sites ou nécessaire pour d'autres scripts tels que piwik ou security_review.

En voici quelques exemples :

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

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

<code class="php">
drush -y vset --always-set reverse_proxy TRUE
drush -y 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 serveurs sus-cités.

La sauvegarde des bases de données

Sur les installations D7 : une fois par semaine

On utilise les scripts de sauvegardes :

La purge des sauvegardes de bases de données

Sur les installations D7 : toutes les semaines

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

Liste des scripts à disposition

Les scripts utilisés sont hébergés dans le répertoire bin du compte assos. Ce dossier est dans le PATH de l'utilisateur assos ce qui permet d'utiliser les scripts comme les commandes usuelles du shell. Les script doiventb être exécutables pour fonctionner ainsi. Le script all-reset-permissions.sh remet les bonnes permissions sur ce dossier.

Le PATH est par sécurité entièrement récrit dans scripts-config.sh (on est certain que les commandes seront trouvées même si on ne les appelle pas avec leur chemin absolu). Le PATH contient alors les chemins vers les dossiers contenant les exécutables du système ainsi que les dossiers bin de assos.

La plupart des scripts ont besoin d’importer un des scripts de configuration. L’import se fait grâce à la commande . SCRIPT. Ces scripts doivent être importés explicitement. On réalise un test en début de script. Ce test permet de savoir si le script importé a besoin de l’import d’un autre script. Si ce n’est pas le cas, on affiche un message d’avertissement et on arrête l’exécution.

Les scripts nécessitant un argument contiennent une ligne commençant par ARGS détaillant la liste des arguments nécessaires à l’exécution du script. Les arguments entre crochets sont facultatifs. Si vous lancez un tel script sans argument, il affichera un message d’aide donnant la liste des arguments.

La liste complète et à jour est disponible ici : https://forge.centrale-marseille.fr/projects/clubdrupal/repository

Recréer le venv pour unlog

Si Python est mis à jour (par exemple de 3.4 vers 3.5) il faut recréer le venv pour unlog. Pour cela :

# Supprimer l'ancien venv :

cd unlog
rm -rf bin include lib lib64 pyvenv.cfg

# Recréer le venv (toujours dans /home/assos/unlog) :

python3 -m venv --without-pip .

# Activer le venv :

source bin/activate

# Installer pip le gestionnaire de paquets python :

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py

# Installer unlog :

cd /home/assos/unlog/unlog
python3 setup.py install

# Vérifier que tout fonctionne :

# Désactiver le venv
deactivate
# Retourner dans le home de assos
cd 
# lancer unlog
my-unlog --help

Mis à jour par Julien Enselme il y a plus de 7 ans · 118 révisions