Bonjour,
J’ai mis à jour mon Dolibarr v20 vers la v21.0.1.
Aucun problème pendant la mise à jour.
Depuis, je n’ai plus accès aux modules custom (timesheet et dolibackup par exemple). Lorsqu’on souhaite accéder aux paramètres de ces modules, on a une erreur 500 classique.
Rien dans les logs PHP et Dolibarr que j’ai passé en mode debug…
Là je sèche. Si vous avez une idée.
Dolibarr v20 vers v21.0.1
PHP 8.1.31
Chez O2SWITCH
Merci,
Patrice
Bonjour,
Rien dans les log d’apache c’est impossible un erreur 500 écrit forcement un log d’erreur.
regarde dans /var/www/apache2/tonsite.com.error.log
ou /var/www/apache2/error.log
Oui je sais mais non, rien.
J’ai ouvert un ticket chez O2SWITCH car c’est vraiment bizarre. Voir si il y a des logs quelque part.
J’ai fait un rollback de Dolibarr de la v21.0.1 à la v20.0.4.
Et le pb persiste sur les custom modules : Toujours erreur 500.
Alors que hier, zéro problème tout fonctionnait normalement en v20 avant la mise à jour en v21.
je pense que tu utilise un cpanel, au pire tu doit pouvoir faire du ssh chez eux
Oui oui, ça j’ai un accès SSH. Mais impossible de trouver l’équivalent d’un error_log Apache ou autre. Le log PHP (en E_ALL) reste vide, le log Dolibarr en DEBUG pas mieux. Là je sèche.
J’ai essayé de désactiver / réactiver les 3 modules custom. Aucun changement.
J’ai supprimé les fichiers de session, pas mieux.
J’ai 3 modules custom et les 3 sont concernés. Et sur les 3, il y a au moins un que j’ai utilisé le 30/04 pour ma facture et aucun problème. Je pensais que c’était la mise à jour vers la v21. Mais rollback complet (base, appli et data) en v20 et rien n’y fait.
regarde sur Corriger un problème de page blanche ou d'erreur 500 sur un site web | Documentation o2switch il y a une explication
Bonjour,
Chez O2Switch vous avez un menu « Sélectionner une version de PHP ».
Vous allez ensuite dans l’onglet « options » et dans le champs « error_log » vous mettez un truc du genre: /home/votre_serveur/public_html/php_errors.log
C’est beaucoup plus simple ensuite de consulter le fichier.
Évidemment il faut s’assurer que vous soyez le seul à pouvoir consulter le fichier.
Du même menu, vous avez l’option pour afficher les erreurs, si cela ne présente pas de risques particuliers dans votre cas.
C’est bien ce que j’ai fait. J’ai passé le niveau de log à E_ALL et mis un chemin vers un fichier de log. Ca a bien créé le fichier mais il reste vide.
Je pense que vous n’avez pas d’autres choix, essayez d’afficher les erreurs directement.
Au pire, essayez de mettre ça dans le code d’une des pages en erreur, sous le bloc qui charge le fichier main.inc.php de Dolibarr. Ça évite d’exposer tout le site.
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL & ~E_DEPRECATED);
J’ai refait une installation from scratch chez O2SWITCH via Softaculous de cPanel, Dolibarr v21.
Et la blaque c’est qu’il y a des dossiers qui sont exposés et accessibles même sans être connecté :
/custom/
/admin/system/
Je ne sais pas si il y en a d’autres, mais c’est grave je trouve.
En attendant, j’ai collé des index.php vide dans les dossiers concernés…
Le problème est la configuration de l’hébergement. Les index.php sont juste un bonus, mais si le serveur est configuré correctement, ces fichiers sont inutiles.
Perso, je mets un fichier .htaccess dans le dossier /public_html avec ceci:
Options All -Indexes
<RequireAny>
Require all denied
</RequireAny>
Un dans le dossier htdocs de Dolibarr, et plus généralement, dans tous les dossiers de l’hébergement uniquement accessible par moi seul.
<RequireAny>
Require all denied
Require ip xxx.xxx.xxx.xxx #votre IP
Require ip 127.0.0.1
Require host localhost
</RequireAny>
Un dernier dans /htdocs/public, et dans tous les dossiers publiques de l’hébergement
Require all granted
Options All -Indexes est la ligne qui empêche les visiteurs de parcourir les dossiers
Ca sent la mauvaise conf des Vhost :
Voilà un exemple que j’utilise :
<VirtualHost *:80>
ServerName xxx.xxx.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/xxx.xxx.com/htdocs
ErrorLog ${APACHE_LOG_DIR}/xxx.xxx.com.error.log
CustomLog ${APACHE_LOG_DIR}/xxx.xxx.com.access.log combined
php_admin_value session.save_path /var/www/xxx.xxx.com/sessions/
php_admin_value upload_tmp_dir /var/www/xxx.xxx.com/tmp/
php_admin_value session.safe_path /var/www/xxx.xxx.com/sessions/
<Directory "/var/www/xxx.xxx.com/htdocs">
Options -Indexes
AllowOverride all
Require all granted
</Directory>
</VirtualHost>
pour moi c’est bien *:80 j’utilise un proxy en amont
Merci à tous pour vos réponses.
Je confirme que l’installation de Dolibarr (la v21) est foireuse chez O2SWITCH. Des dossiers exposés !..
J’ai ouvert un ticket chez O2SWITCH pour leur signaler et indiqué ce qu’ils doivent corrigé.
Je viens de refaire une installation complète from scratch puis j’ai rechargé ma dernière sauvegarde en v21 (SQL, Data et Htdocs).
J’ai remis d’équerre les droits sur custom avec un bon .htaccess à la racine :
Options All -Indexes
Bizarrement, seul 1 des 3 modules custom visibles (alors que présent dans custom) après la restauration. J’ai juste réinstallé les 2 custom modules manquants (dolitemplate et dolibackup). Project Timesheet 5.0.4 fonctionne bien en v21.
Heureusement que j’ai mes sauvegardes que je fais avant chaque upgrade ou installation de module… J’ai un peu transpiré !
A tous les utilisateurs O2SWITCH avec une installation de Dolibarr, vérifiez votre sécurité !
Autre blague : Depuis le passage en v21, hormis les 2 modules custom que je ne vois plus et qui refuse de s’installer, je m’aperçois qu’il me manque des modules natifs. Je n’ai plus les modules Systèmes (debug) et il manque des modules « Interfaces avec des systèmes externes »…
Là je craque, je reste en v20, tant pis.
J’ai trouvé, j’ai passé de PHP 8.1 à 8.2 via le fichier .htaccess à la racine.
Et bien, pour une raison que j’ignore, ça ne liste pas tous les modules.
Je suis revenu à PHP8.1 et tous les modules (natifs et custom) sont là !
Encore une blague de O2SWITCH… Je pense que je vais tout basculer chez OVH et avoir l main sur tout…
Merci 
Je ne pense pas que cela vienne de o2switch.
Selon vos tests, je pencherais plutôt pour un problème de compatibilité d’un des modules customs, ou d’ailleurs dans votre Dolibarr, avec PHP8.2 et supérieur.
C’était bien un pb avec la version PHP 8.2 embarquée via le .htaccess.
O2SWITCH est intervenu et a modifié le php.ini (liste des extensions complétée, les extensions zend ont le chemin absolu en dure vers les modules) aussi embarqué via le .htaccess.
Problème résolu.
