Upgrading Moodle 2.1 → Moodle 2.3 avec GIT

Je suis resté toute l'année scolaire précédente sur la version 2.1 : je n'ai pas voulu tenter le diable avec la 2.2, déjà que le passage de la 1.9 en 2.1 a perturbé quelques utilisateurs...
Par contre, les nouveautés de la 2.3 soint TRÈS alléchantes... Alors, je profite de cette fin de vacances (ou début d'année scolaire ?) pour faire la mise à jour...

NB : D'après la lecture de la doc, il est nécessaire de passer par une version 2.2 avant de passer en 2.3.
J'en profite pour tester les tâches administratives en ligne de commande !

Vérifications

  1. Vérifiez que votre serveur puisse accueillir la version 2.3 : Administration du site / Serveur / Environnement. S'il ne vous propose pas la vérification pour la version voulue, il le fera après une première mise à jour, il faudra alors retenter le coup plus tard...
  2. Vérifiez que les plugins que vous utilisez soient disponibles ou compatibles avec la version 2.3.

Sécurité avant tout

Effectuez une sauvegarde de votre Moodle.
Il est conseillé de vérifier que votre base est en bon état avant de faire un upgrade.
Passage du site en mode maintenance

cd /var/www/html/moodle
/usr/bin/php admin/cli/maintenance.php --enable

Mise à jour antérieure à l'upgrade

Pour démarrer avec quelque chose de sain...

git pull
/usr/bin/php admin/cli/upgrade.php

Passage de 2.1 en 2.2

Changement de version, puis upgrade.
git branch -a
git checkout -b local_22_STABLE origin/MOODLE_22_STABLE
/usr/bin/php admin/cli/upgrade.php

Le première ligne permet simplement de voir ce qui est disponible, elle est donc facultative.

Passage de 2.2 en 2.3

Même démarche...
git checkout -b local_23_STABLE origin/MOODLE_23_STABLE
/usr/bin/php admin/cli/upgrade.php

Update des plugins

Update des plugins avec une version compatible (dépend de la façon dont vous avez installé les plugins...).

  • soit par GIT, puis visite de la page de notification,
  • soit par upload FTP, puis visite de la page de notification.

Restauration du site

Un petit test du site, du thème... puis retour au mode production.

/usr/bin/php admin/cli/maintenance.php --disable

Au cas où...

Une petite sauvegarde avec un Moodle updaté fonctionnel ?

Sources :
http://docs.moodle.org/23/en/CLI

Réparer la base de donnée Moodle

Au fur et à mesure des updates / upgrades, la base de donnée Moodle a tendance à se perturber...
Deux choses sont à faire après une upgrade importante (changement de version).

Sous Moodle

Des outils de vérification de base sont déjà présents dans Moodle. Allez dans Administration du site / Développement / Expérimental / Éditeur XMLDB
En haut de page vous avez :
  • Vérifier les index
  • Vérifier les valeurs par défaut
  • Vérifier les longs entiers (bigints)
  • Vérifier les clefs extérieures

Ces outils permettent de vérifier des éléments essentiels de la base.

Ils ne font qu'un check et proposent des solutions si nécessaire.

Sous MySQL

Vous pouvez vérifier / réparer les bases, et les optimiser pour gagner en performance avec les commandes :
CHECK TABLE
REPAIR TABLE
OPTIMIZE TABLE
Sur votre serveur; connectez vous à Mysql et sélectionnez la base Moodle :
mysqld
USE moodle
Puis lancer la vérification (et la réparation si nécessaire), puis l'optimisation des tables importantes et sensibles :
CHECK TABLE mdl_course_sections;
CHECK TABLE mdl_forum_posts;
CHECK TABLE mdl_log;
CHECK TABLE mdl_sessions;
CHECK TABLE mdl_backup_controllers;
CHECK TABLE mdl_grade_grades_history;
CHECK TABLE mdl_backup_log;
OPTIMIZE TABLE mdl_course_sections;
OPTIMIZE TABLE mdl_forum_posts;
OPTIMIZE TABLE mdl_log;
OPTIMIZE TABLE mdl_sessions;
OPTIMIZE TABLE mdl_backup_controllers;
OPTIMIZE TABLE mdl_grade_grades_history;
OPTIMIZE TABLE mdl_backup_log;

Il existe une méthode un peu plus brutasse : vérifier et optimiser toutes les tables de la base Moodle...

Dans l'invite de commande, tapez :

mysqlcheck --auto-repair --database moodle
mysqlcheck --optimize --database moodle

Ou alors carrément et monstrueusement brutasse : toues les tables de toutes les bases...

mysqlcheck --auto-repair --all-databases
mysqlcheck --optimize --all-databases

 

Installation de SPIP par Git

Illustration sur un Ubuntu, avec LAMP et Git déjà installés.

Récupération des sources, puis choix de la version.

cd /var/www/
sudo git clone http://git.spip.org/spip.git/
sudo chown -R www-data:www-data spip/
cd spip
sudo git checkout spip-2.1
sudo git pull

Installation du site

  1. Avec un navigateur, se rendre sur la page http://localhost/spip/ecrire
  2. Choix de la langue.
  3. Configuration de la BDD.
  4. Configuration de l'utilisateur de base.

Sources :
http://core.spip.org/projects/spip/wiki/#SPIP-sous-Git-comment-ça-marche-

Canon MP 510 – Erreur 5100

L'erreur 5100 est une erreur relative au chariot, mais pas plus de précisions...
Ça peut être de éléments qui gênent le coulissement, ou des cartouches en mauvais état...
Mais dans les imprimantes Canon, j'ai déjà plusieurs fois été confronté aux réservoirs d'encre trop pleins.

Il faut savoir que, quand elles se rangent, les cartouches vont se poser sur des tampons pour éviter le dessèchement.
Ces tampons servent aussi lorsque les cartouches se nettoyent... De l'encre est craché dessus.
Et au bout d'un moment ces réservoirs débordent, et l'imprimante se met en erreur.

Nettoyer le surplus d'encre

Avec un coton tige ou sopalain, nettoyer les tampons où les cartouches se rangent, et profitez pour faire l'abord. vous pouvez aussi utiliser un dissolvant ou de l'alcool. Évidement, comme vous avez les mains dans la machine, il vaut mieux la débrancher !

Le problème, c'est que si cette première manip permet de vider le surplus, l'électronique a conservé l'état d'erreur... il faut alors lui dire d'oublier.

Remise à zéro

Il faut faire appel au menu constructeur :

  1. Imprimante éteinte
  2. Appuyez et maintenez la touche RESUME (triangle rouge)
  3. Appuyez et maintenez la touche POWER
  4. Relachez la touche RESUME
  5. Appuyez 2 fois sur la touche RESUME (le voyant passe en orange, puis à nouveau en vert)
  6. Relachez la touche POWER
Vous êtes maintenant dans le menu constructeur.
Pour réinitialiser le réservoir :
  1. Appuyez 4 fois sur la touche RESUME
  2. Appuyez sur la touche POWER (pour valider l'action)
That's all, normalement, l'état d'erreur étant réinitialisé et l'imprimante nettoyée, ça devrait aller mieux !

Lancer Google Chrome avec le bon profil utilisateur

Depuis quelques temps, Chrome est capable de gérer plusieurs profils dans une seule session de votre ordinateur. Vous pouvez donc lancer sur même bureau Chrome pour toute la famille, mais avec des paramètres personnalisés et synchronisés pour chacun...

Mise en place (au cas où)

Dans les Préférences de Chrome / Données personnelles / Utilisateurs.
Créez vos utilisateurs, et personnalisez les.

Création des raccourcis

Pour lancer Chrome avec un profil spécifié dès le démarrage, il faut ajouter un argument au raccourcis :

--profile-directory=

Par défaut, Chrome lance :

--profile-directory=Default
Pour lancer les autres profiles, quelques soient leurs noms, il faut utiliser les termes « "Profile 1" » et suivants...
Sous Ubuntu, j'ai donc créé un raccourcis supplémentaire avec un logo compréhensible :
google-chrome --profile-directory="Profile 1"

Je vous laisse adapter pour Windows©® et Mac©®...
Vous trouverez la liste des profiles dans le répertoire 

~/.config/google-chrome/

Mise en place d’un accélérateur php

Moodle étant consommateur en requêtes HTML, il est utile d'ajouter à votre Apache un accélérateur php.
Puisque je suis sous Centos, j'ai opté pour APC.

Installation

Installation des pré-requis :

yum install php-pear
yum install php-devel
yum install httpd-devel

Installation d'APC :

pecl install apc

Ajout d'APC à Apache et redémarrage :

echo "extension=apc.so" > /etc/php.d/apc.ini
service httpd restart

Pour savoir s'il est activé, rendez vous sur votre Moodle / Administration du site / Serveur / Info php, vous devriez trouver un cadre APC.
Bien sûr, pour évaluer l'impact de cette installation, l'idéal est d'avoir une courbe de charge de votre serveur avant / après... en passant par un FAN par exemple.

Sources :
http://docs.moodle.org/23/en/Performance_recommendations#PHP_performance
http://2bits.com/articles/installing-php-apc-gnulinux-centos-5.html

Sauvegarder Moodle

Dans Moodle, il existe 3 objets à sauvegarder régulièrement :

  • le répertoire qui contient Moodle (et ses éventuelles modifications)
  • le répertoire qui contient les données utilisateurs / fichiers des cours...
  • la base de donnée
Perso, je compresse ce données dans un répertoire et je copie le répertoire résultant sur un disque extérieur par sécurité. En cas de soucis, j'ai toutes les infos nécessaires pour rétablir mon Moodle tel qu'il était à une date donnée.

Étapes

Moodle : copie du répertoire
tar -czf /home/moodle/save/rep_moodle.tar.gz /var/www/html/moodle
Moodledata : copie du répertoire
tar -czf /home/moodle/save/rep_moodle_data.tar.gz /home/moodle/upload
MySql : dump de la base SQL
mysqldump -uUSERNAME -pPASSWORD -e -q -Q --add-drop-table moodle | gzip > /home/moodle/save/bdd_moodle.sql.gz

Optimisation

N'hésitez pas à scripter ces commandes et à les lancer par cron régulièrement... avec la date du jour en plus dans le nom du répertoire par exemple.

Synchronisation des utilisateurs LDAP sur Moodle

Dans Moodle, il existe un fichier qui permet de synchroniser les utilisateurs avec le LDAP.

Cette synchro ne se passe que dans un sens, à savoir créer les nouveaux utilisateurs dans Moodle et modifier les utilisateurs existants si la source LDAP a été modifiée.
Ça ne modifie en rien le LDAP.
Pour lancer cette action :
http://mymoodle.org/auth/ldap/cli/sync_users.php

Il existe le même dans /auth/cas pour ceux que ça intéresse...

Pour simplifier l'opération, je lance ce script automatiquement chaque nuit (à 3h15) par l'intermédiaire d'un cron.
15 03 * * * php /var/www/html/moodle/auth/ldap/cli/sync_users.php

Du coup, tout nouvel utilisateur dans mon LDAP se verra créé dans Moodle la nuit suivante.

Pour Moodle, il me reste à synchroniser les groupes LDAP avec les cohortes, mais ça n'existe pas encore en natif...  Patrick Pollet à bossé dessus, mais pas pour la version 2.3.


Je vous tiendrais au jus de mes essais après l'upgrade !

Gestion des flux utilisateurs dans un établissement scolaire

Le milieu scolaire est assez particulier dans la gestion informatique des utilisateurs. Il faut distinguer 3 types d'utilisateurs avec leur besoins particuliers.

La gestion du personnel administratif est assez semblable à une gestion en entreprise... RAS de ce coté. Création manuelle de compte, et on n'en parle plus...

Les élèves/étudiants arrivent tous en même temps, doivent tous avoir un compte le premier jour sur toutes les plateformes, avec des mots de passes simples à retenir.
Certains étaient déjà dans l'établissement l'année précédente mais ont oublié leur mot de passe durant les vacances, d'autres viennent d'arriver. Notre politique consiste à créer un nouveau mot de passe principal chaque début d'année scolaire, mais de conserver les documents utilisateurs dans la mesure du possible.
Autre particularité, ils font partie de classes et doivent avoir accès à des répertoires partagés (protégés en écriture ou non), et retrouver ces groupes dans l'ENT.
Et, contrairement à ce qu'on pourrait penser, ils ne sont pas si à l'aise que ça avec l'informatique... Poser un message sur Facebook, pas de soucis, mais accéder à un répertoire réseau, peu d'entre eux savent le faire. Il faut donc essayer de simplifier cette partie.

Les enseignants sont de niveaux très hétérogènes : certains sont hermétiques, d'autre addictes... Il faut donc aussi simplifier les opérations d'accès disques, car évidement, ils doivent pouvoir partager des documents avec les étudiants par des accès aux répertoires réseaux.
La génération des comptes et des partages peut être aussi complexe...

Derrière tout ça se cache aussi l'aspect sécurité : la protection des données personnelles demande d'interdire d'accès aux documents étudiants et professeurs à d'autres personnes, évidement ! D'où le besoin de répertoires privés.


Enfin, le fait d'avoir des mineurs dans un établissement n'est pas anodin, mais j'y reviendrais surement...

Pour la partie Windows / Ldap, nous utilisons KoXo Administrateur (j'ai pas d'action dans la boite, je précise : j'apprécie juste). Il me semble, corrigez si je me trompe, que l'auteur travaillait avant à développer GUNT, que l'on utilisait aussi. Il a maintenant créé sa boite pour vivre de son travail...
Ce logiciel permet entre autre à partir d'un CSV de créer les comptes (login, mot de passe...), les groupes et les dossiers avec les droits de partages adaptés.
Si vous n'avez pas de scripts dans vos mallettes, jetez un œuil dessus...

Mise à jour de Moodle 1.9.3 maintenue par CVS → 2.1 maintenue par GIT

Mise à jour du serveur Centos

Upgrade php et installation des modules php nécessaires (Serveur / Environnement / Version 2.1 et plus)

yum install php
yum install php-xmlrpc
yum install php-intl
yum install php-soap
service httpd restart

Sauvegarde

Moodledata : copie du répertoire

tar -czf /home/moodle/save_rep_moodle_data.tar.gz /home/moodle/upload

Moodle : copie du répertoire

tar -czf /home/moodle/save_rep_moodle.tar.gz /var/www/html/moodle

MySql : dump de la base SQL

mysqldump -uUSERNAME -pPASSWORD -e -q -Q --add-drop-table moodle | gzip > /home/moodle/save_bdd_moodle.sql.gz

Nettoyage

Suppression des plugins pas importants (sous utilisés, voir déjà masqués car seulement testés, ou inutiles car remplacés en natif dans la version 2) : suppression sous moodle, puis dans l’arborescence.
Vérification de la présence des plugins importants pour la version 2.1 (en ce qui me concerne : feedback → OK)
Retour au thème standard (Présentation / Thèmes / Sélecteur de thème / Standard)
Mise en pause du site (Serveur / Mode de maintenance / Écrire votre message puis Activer)

Upgrade

Suppression de l’ancien répertoire Moodle

cd /var/www/html/
cp -R moodle moodle_save
rm -rf moodle

Aller dans le répertoire parent

cd /var/www/html/

Giter moodle (port du git à ouvrir WAN <-> DMZ : 9418 TCP & UDP)

git clone git://git.moodle.org/moodle.git
cd moodle
git branch -a
git checkout -b local_21_STABLE origin/MOODLE_21_STABLE
cp config-dist.php config.php

Configurer le config.php en prenant exemple sur l’ancien config.php

Lancer le site -> procédure de mise à jour

Tester la connexion CAS
Choisir le langage
Choisir le thème
Ouvrir le site & aller sur notification pour rentrer tous les nouveaux paramètres
Activer / Désactiver les plugins
Dépot à ajouter :

  • Dropbox
  • GoogleDocs
  • Picasa
  • Youtube

Enregistrer le site sur MOOCH
Tester un cours
Configurer la barre de lien (menu)
Faire une annonce pour la mise à jour (activités conditionnelles, achèvement d’activités, dépôts de fichiers, multiplication d’items)
Google analytics (HTML additionnel)

Sauvegarde post upgrade

Moodledata : copie du répertoire

tar -czf /home/moodle/save_rep_moodle_21_data.tar.gz /home/moodle/upload

Moodle : copie du répertoire

tar -czf /home/moodle/save_rep_moodle_21.tar.gz /var/www/html/moodle

MySql : dump de la base SQL

mysqldump -uUSERNAME -pPASSWORD -e -q -Q --add-drop-table moodle | gzip > /home/moodle/save_bdd_moodle_21.sql.gz

Pour la suite...

Mise à jour de moodle par GIT : 

cd /var/www/html/moodle/
git pull

Visiter la page de notification.

NB :
Cette expérience m'a ensuite permis de créer une doc sur MoodleDocs :