Assistance technique

Cette partie concerne SElinux.

Pour connaitre le statut de SElinux :

sestatus

Sur l'ancien serveur, j'avais paramétré SElinux en "permissive" (au lieu de "enforcing") :

sudo vi /etc/sysconfig/selinux

sudo setenforce permissive

Et vérifier avec :

sestatus
 

Cette année, pour plus de sécurité, j'ai voulu conserver SElinux en "Enforcing".

J'avais l'erreur "Forbidden
You don't have permission to access this resource.Server unable to read htaccess file, denying access to be safe", réglée en modifiant les droits :

sudo chmod -R 775 /var/www/html

J'avais ensuite un message d'erreur "Fatal error: $CFG->dataroot is not writable, admin has to fix directory permissions! Exiting." ou "cache/Unable to load the cache configuration file". Solution trouvée dans cette discussion.

J'ai du lancer :

sudo chcon -R -h -t httpd_sys_content_t /var/www/html

et

sudo chcon -R -t httpd_sys_rw_content_t /chemin/vers/moodledata

Ces opérations effectuées, cela fonctionne correctement.

Séverin

Cette partie concerne MariaDB.

Sur l'ancien serveur, c'était MariaDB 10.2, et sur le nouveau MariaDB 10.3.

Lorsque j'ai importé le fichier exporté (dump) représentant la sauvegarde de ma base de données, j'ai vu passer des messages d'erreur, tels que :

ERROR 1366 (22007) at line 22378 in file: '/tmp/export_moodle.2022-06-20.sql': Incorrect string value: 
'\xF0\x9F\x93\xA3 A...' for column `moodle`.`mdl_logstore_standard_log`.`other` at row 4355

ERROR 1366 (22007) at line 34385 in file: '/tmp/export_moodle.2022-06-20.sql': Incorrect string value: 
'\xF0\x9F\x93\xA2\xE2\x9A...' for column `moodle`.`mdl_notifications`.`subject` at row 180

ERROR 1366 (22007) at line 36202 in file: '/tmp/export_moodle.2022-06-20.sql': Incorrect string value: 
'\xF0\x9F\x93\x84T\xC3...' for column `moodle`.`mdl_page`.`content` at row 71

Quelques recherches m'ont permis de comprendre que c'était un problème de réglage de MariaDB, qui n'était pas prévu pour le support UTF8 complet, avec encodage utf8mb4. Vérifié en lançant :

SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';

Malheureusement, en relançant MariaDB (avec sudo systemctl start mariadb.service), cela bloquait, et j'obtenais cette erreur :

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

Et en lançant sudo systemctl status mariadb.service :

mariadb.service - MariaDB 10.3 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2022-06-21 19:49:19 CEST; 20s ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 112153 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
  Process: 112357 ExecStart=/usr/libexec/mysqld --basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER (code=exited, status=7)
  Process: 112318 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mariadb.service (code=exited, status=0/SUCCESS)
  Process: 112293 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
 Main PID: 112357 (code=exited, status=7)
   Status: "MariaDB server is down"

Jun 21 19:49:19 moodle-22 systemd[1]: Starting MariaDB 10.3 database server...
Jun 21 19:49:19 moodle-22 mysql-prepare-db-dir[112318]: Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
Jun 21 19:49:19 moodle-22 mysql-prepare-db-dir[112318]: If this is not the case, make sure the /var/lib/mysql is empty before running mysql-prepare-db-dir.
Jun 21 19:49:19 moodle-22 mysqld[112357]: 2022-06-21 19:49:19 0 [Note] /usr/libexec/mysqld (mysqld 10.3.32-MariaDB-log) starting as process 112357 ...
Jun 21 19:49:19 moodle-22 systemd[1]: mariadb.service: Main process exited, code=exited, status=7/NOTRUNNING
Jun 21 19:49:19 moodle-22 systemd[1]: mariadb.service: Failed with result 'exit-code'.
Jun 21 19:49:19 moodle-22 systemd[1]: Failed to start MariaDB 10.3 database server.

Après plusieurs recherches infructueuses, j'ai essayé d'enlever mon fichier de configuration personnalisé (/etc/my.cnf.d/moodle.my.cnf), et cela a redémarré correctement. Je l'ai remis et constaté à nouveau le problème...

Après de nombreux tatonnements, je me suis aperçu que c'est le fait d'avoir certaines lignes de paramètres dans le fichier de configuration qui mettait la pagaille et empechait le démarrage !

En résumé, pour corriger cela, j'ai du désactiver (commenter) les lignes liées à : innodb_file_io_threads, innodb_file_format et innodb_large_prefix.

MariaDB ayant redémarré correctement, j'ai pu vérifier l'encodage et l'interclassement avec la commande suivante :

SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';

Ce qui m'a donné :

+--------------------------+--------------------+
| Variable_name            | Value              |
+--------------------------+--------------------+
| character_set_client     | utf8mb4            |
| character_set_connection | utf8mb4            |
| character_set_database   | utf8mb4            |
| character_set_filesystem | binary             |
| character_set_results    | utf8mb4            |
| character_set_server     | utf8mb4            |
| character_set_system     | utf8               |
| collation_connection     | utf8mb4_unicode_ci |
| collation_database       | utf8mb4_unicode_ci |
| collation_server         | utf8mb4_unicode_ci |
+--------------------------+--------------------+

OK, on peut donc refaire l'importation de la base de données !

Séverin

Cette partie concerne PHP.

J'ai essayé de copier le fichier de configuration de mon ancien serveur vers le nouveau : /etc/php.d/50-moodle.php.ini

Dans ce fichier j'ai plusieurs lignes, notamment pour définir max_inputs_vars.

Hors, en redémarrant Apache (avec sudo service httpd restart), et en consultant l'environnement de Moodle, je vois toujours un avertissement à ce propos.

Je me demande du coup pourquoi mon fichier de configuration personnalisé n'est pas pris en compte. Si quelqu'un a une idée ?

Séverin

Bonjour,

Dupliquant notre instance vers un nouveau serveur, utilisant une adresse différente, il est nécessaire de procéder au changement d'URL.

Je détail tous les éléments dans cette discussion dédiée

Séverin

Cette partie concerne des vérifications et nettoyages, qui peuvent être lancés régulièrement sur toute instance Moodle :

• Vérification de l'encodage et l'interclassement de la base de données (ça ne devrait pas changer une fois configuré correctement, et on devrait être en utf8mb4) :
  

  SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';

• recherche des séquences de cours à problème (normalement vide) :
  

  php admin/cli/fix_course_sequence.php --courses=* | grep -v 'is OK'

• recherche des éléments de module sans instance (normalement vide) :
  

  SELECT id, course, section, module, instance, visible, FROM_UNIXTIME(added) FROM mdl_course_modules WHERE instance=0;

SELECT GROUP_CONCAT(DISTINCT(courseid)) FROM mdl_logstore_standard_log WHERE courseid > 1 AND courseid NOT IN (SELECT DISTINCT id FROM mdl_course) \G

Séverin

Cette partie concerne la mise à jour à Moodle 4.0.

Après avoir dupliqué mon instance Moodle sur un nouveau serveur, et avoir modifié tous les éléments pour adapter l'URL, j'ai lancé la mise à jour à Moodle 4.0.

Mais celle-ci s'est arrêtée avec un message d'erreur, lié à block_myoverview, manifestement liée à une durée d'exécution dépassée.

J'ai essayé de lancer la mise à jour en ligne de commande, mais cela avait échoué également. J'ai donc attendu le lendemain avant de relancer en ligne de commande.

Cela a fini par passer, mais cela a été très long (il faut patienter car rien ne bouge) sur le traitement de cet élément :

-->block_myoverview
++ Succès (12191,18 secondes) ++

La suite s'est ensuite bien passée, rapidement.

Séverin