J'exécute Moodle 2.4.8 (Build: 20140113) sur une boîte Debian Squeeze, avec Apache 2.2. Chaque fois qu'un utilisateur (même l'administrateur) modifie certains paramètres (c'est-à-dire en ajoutant un utilisateur ) ou en accédant simplement à certains cours (dans ce cas, Math 9), la page s’affiche avec une erreur 503, Erreur fatale: $ CFG-> dataroot n’est pas accessible en écriture, l’administrateur doit réparer les autorisations de répertoire! Exiting.
En vérifiant mon fichier /config.php
, je vois que le chemin est défini sur /var/moodledata2
, qui appartient à www-data www-data
, et les autorisations sont alignées sur la documentation de Moodle.
C'était intermittent au début de la semaine, mais maintenant ça devient constant. Il y a beaucoup d'espace libre disponible (comme indiqué ci-dessous):
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md2 83G 37G 42G 48% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 2.0G 224K 2.0G 1% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/md1 939M 35M 857M 4% /boot
/dev/md3 822G 355G 426G 46% /var
/dev/md4 917G 72G 799G 9% /var/moodledata2
# cat config.php
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = 'localhost';
$CFG->dbname = 'moodle2';
$CFG->dbuser = 'root';
$CFG->dbpass = '<removed>';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbsocket' => 0,
);
$CFG->wwwroot = 'http://example.com/moodle2'; // <removed>
$CFG->dataroot = '/var/moodledata2';
$CFG->admin = 'admin';
$CFG->directorypermissions = 0777;
$CFG->passwordsaltmain = '<removed>';
require_once(dirname(__FILE__) . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!
#
Je ne sais plus quoi faire. Les autorisations semblent logiques dans leur forme (www-data possédant tout et ayant un accès complet au dossier /var/moodledata2
). Quelle est ma prochaine étape?
Edit: J'ai oublié de mentionner l'une des techniques évidentes. Lisez les journaux des erreurs de serveur et de programme pour plus d'informations sur des problèmes spécifiques. Les erreurs affichées à l'utilisateur par le biais de l'interface sont souvent intentionnellement génériques.
Pour résoudre le problème, recherchez les fichiers utilisés dans les processus défaillants en déboguant le programme (ou demandez directement aux développeurs, ce qui pourrait être la voie la plus simple). Un moyen efficace de déboguer un programme php consiste à le charger dans un programme tel que phpeclipse. Une fois que vous connaissez les fichiers à l'origine du problème, recherchez-les individuellement. Vous pourriez être confronté à un problème de corruption ou à un problème où les fichiers ne sont pas créés par le programme avec la propriété ou les autorisations appropriées.
Ce lien peut vous aider à démarrer le débogage: http://www.ibm.com/developerworks/library/os-debug/
Assurez-vous également que les nouveaux fichiers créés dans le répertoire de données disposent des autorisations et de la propriété appropriées. Parfois, un script est incapable de créer de nouvelles données sur le serveur car le script en cours d'exécution ne dispose pas des autorisations appropriées pour créer de nouvelles données car le répertoire de données est trop restrictif.
Ce serait mon étape 1: Si rien de ce qui précède ne fonctionne ou ne semble trop intimidant, essayez de déplacer le site de production sur un serveur de test et voyez si vous le pouvez. reproduire le problème. Mieux encore, vous pouvez le déplacer vers une structure de système d'exploitation différente pour isoler la configuration du serveur par rapport aux problèmes liés au programme.
J'ai eu la même erreur dans Centos 7, après ceci commande linux, ça fonctionne bien!
setenforce 0