Retour au Login à chaque clique (migration 13.0.2)

Ok mais je n’ai accès à rien !

C’est pas une VM ou j’installe ce que je veux. J’ai même essayé de redéfinir la variable session.save_path pour rediriger les fichiers vers un répertoire dont je pourrais contrôler les droits. Mais ça n’a pas fonctionné

J’ai peut-être une piste… OVH a déplacé mon hébergement et donc le numéro du filer à changé.

J’ai modifié le conf.php mais le problème persiste.

Cela peut avoir un impact ?

Bonsoir,

Oui, et surtout il y a par moment (souvent même) un cache côté OVH, lorsque je fais des modifications d’un fichier sur un mutualisé OVH par habitude je passe une dizaine de ligne, j’enregistre, je vérifie si la modification a bien été prise en compte et si oui alors je retourne dans mon fichier et je supprime la dizaine de ligne en trop :wink: et j’enregistre de nouveau, ça oblige le cache d’OVH à ce mettre à jour.

Cordialement,
Gaëtan.

Bonsoir,

Attention je pense qu’il y a une confusion, les logs d’OVH sont classées par date, le fichier error qui comporte 5 lignes est sans doute celui du jour ou des 5 dernières minutes.

Oui ça peut être une solution, mais avant il faut sauvegarder, sauvegarder et encore sauvegarder :wink: .

Et il est possible de suivre la procédure suivante pour faire des tests sans casser (encore plus !!) le Dolibarr :

Dupliquer une instance de production en instance de test

Amicalement,
Gaëtan.

bon j’ai encore un peu avancé…

J’ai testé l’installation de la 12.0.5 et ça refonctionne !!! Il y a des messages concernant des problèmes de base de données (ce qui me parait un poil normal) mais j’arrive à créer des clients et facturer.

Donc j’ai testé l’upgrade vers 13.0.0 et bim, même problème qu’avec la 13.0.2 !!

Donc je serai tenté de dire qu’OVH n’est pas en cause… non ? A moins que ce soit l’association V13 + OVH et là, je suis dans la merde… Donc j’ai commandé un hebergement chez o2switch pour dupliquer l’installation.

Bonsoir,

Il nous faudrait un maximum d’information pour comprendre pourquoi une mise à niveau de la version 12.0.5 vers la 13.0.0 pose problème.

Pouvez-vous détailler précisément les opérations effectuée pour la mise à niveau ?

J’ai dernièrement effectué une mise à niveau depuis une version 5.0.7 vers la version 13.0.2 et ça s’est passé sans problèmes, j’ai eu un soucis avec la base de donnée entre de mémoire la version 7 et la 8 ou la 9 et la 10 mais il était connu et répertorié sur ce forum.

Voici une page du wiki de Dolibarr qui explique comment faire une mise à jours :

Procédure de mise à jour avec Dolibarr (package standard .zip)

Cordialement,
Gaëtan.

Hello
J’ai fait comme d’habitude…

  1. téléchargement de la version
  2. décompression du zip
  3. transfert via Filezilla en ecrasant les fichiers sous le répertoire dolibarr
  4. exécution de la procédure d’install qui s’est passée sans problème

Bonjour @grandware

personne ne rencontre ce problème à part toi : il s’agit donc d’un cas particulier qui concerne ton instance.

Ton test d’une nouvelle install chez un autre hébergeur a donné quoi ? (tu citais o2switch )
Tu peut aussi essayer de monter une instance en local.
Ou de demander à ton hébergeur d’avoir une nouvelle instance et d’abandonner l’actuelle.

Dans le doute : tu ne te serais pas amuser avec des « .htaccess » ?

Tu as contacté ton hébergeur actuel pour avoir de l’assistance ?

Si tu n’as pas les compétences, adresse toi à un professionnel local ou l’un de cette liste.

Efface tous les cookies de ton navigateur et recommence pour voir.

Je ne m’amuse pas !!!

J’ai contacté OVH qui a évidemment balayé le problème d’un revers de main. Je vous rappelle que je ne loue pas une instance mais un hébergement. Je n’ai donc pas accès à grand chose…

Pour ce qui est du navigateur, j’ai essayé avec un autre que Firefox et même résultat

L’installation chez o2switch n’est pas encore effectuée car le retour en 12.0.5 me permet de bosser à nouveau même si la situation est bancale. Je m’y mets dès que possible.

Je referais également un test en partant de la 13.0.2 vierge et en y copiant que le repertoir document et le fichier conf.php

D’après le code source de Dolibarr, il y a eu un changement dans la gestion des sessions php.

Il faudrait voir où Dolibarr essaye de mettre la session : dans un fichier ou dans la base de données.
Il faudrait voir ce qui est indiqué dans le fichier .ovhconfig d’OVH, essayer une autre version de PHP.
Il faudrait regarder la table llx_session si elle est utilisée ou non.

Bonsoir,

Si justement sur OVH nous avons accès à pas mal de chose comparé à d’autres hébergeurs.

Le logs du serveur en temps réelle ou presque (5 minutes de décalage je trouve que ça va :wink: )

La possibilité de changer de version de PHP en quelques clics ou en modifiant le fichier .ovhconfig ou .htaccess

Et plein d’autres choses, mais ce n’est pas le sujet ici.

Mauvaise idée, car en prenant le fichier conf.php il va utiliser votre base de donnée de production.

Le mieux est encore de refaire une installation de la version 12.0.5 dans un sous-domaine dolitest.votrenomdedomaine.dom qui pointerai vers un dossier dolibarr/htdocs à la racine de votre hébergement OVH le dossier dolibarr au même niveau que le dossier www, la création d’une base de donnée dédié pour le test avec un utilisateur différent de l’utilisateur de la base de donnée de production pour éviter toute confusion, et la procédure :

Dupliquer une instance de production en instance de test

Sinon bien vérifier que vous n’avez pas plusieurs .ovhconfig et/ou .htaccess à la racine de votre hébergement, dans le dossier www et dans votre dossier dolibarr

Si vous n’y arrivez toujours pas, je pense comme @Arre il faut faire appel à un professionnel qui connaît Dolibarr et les hébergements mutualisés d’OVH, car il n’y a pas de raison que ça ne fonctionne pas chez vous alors que ça fonctionne parfaitement chez d’autres (et moi le premier qui suis sur de l’hébergement mutualisé d’OVH depuis plus de 16 ans et avec des Dolibarr depuis au moins 13-14 ans pour tests et utilisations)

Cordialement,
Gaëtan.

1 « J'aime »

Bonsoir,
Je rencontre également ce même pb de retour au login à chaque clic. Il est apparu depuis que OVH a changé les noms de ses bases de données (en gros cette semaine pour moi). Mon fichier conf.php a été automatiquement modifié par OVH (ligne $dolibarr_main_db_host=‹ xxxxxxxxx ›:wink: en remplaçant le nom de ma base de donnée et depuis ça plante.
Si je remet l’ancien nom de ma base dans le fichier conf.php tout refonctionne parfaitement. C’est une solution mais pas durable, OVH va arrêter de supporter les anciens noms.

Version Dolibarr 13.0.1
Version PHP 7.4.15

Je vais relire tranquillement vos réponses et conseils mais si quelqu’un a une idée géniale sur le truc, je prends.

Merci de votre aide
Patrick

Bonjour à tous,

J’ai exactement le même problème et je m’arrache les cheveux !
Problème sur webm32.cluster014.gra.hosting.ovh.net après mise à jour effectuée par OVH sur ma BD. (Pas de souci sur mon autre instance webm163.cluster014.gra.hosting.ovh.net non mise à jour)
Depuis, pas d’affichage d’image (dont captcha). Si je le désactive et me logue, chaque clic me renvoie sur la page de login.
Pas de cookie de session.

Merci aux bonnes idées.
Mab

Après avoir à peu près tout testé (changé les droits des fichiers, supprimé tous les fichiers non mis à jours à la dernière installation, fouillé la BD à la recherche de chemins en dur, recopié tous les fichiers …), ce qui m’a sauvé a été de chercher « SYSLOG_HANDLERS » dans la table llx_const qui pointait vers « mod_syslog_chromephp », ce syslog_chromephp pointant lui-même sur un chemin en dur (un vieux homez.xxx/) avec au bout un include Dolibarr du siècle passé.
En changeant la valeur à « mod_syslog_file », ça refonctionne :sweat:
(Dans la BD, c’est l’occasion de fouiller du côté des homez.xxx qui ne sont plus à jour)
… en espérant que ça serve à d’autres !

2 « J'aime »

Hello tous,

Après un peu de tâtonnement, le transfert de Dolibarr vers o2switch est terminé et opérationnel.

OVH ne sera bientôt plus qu’un lointain souvenir.

Merci à tous pour votre aide

Bonjour
j’ai été confronté au même problême chez OVH / mutualisé, résolu de la manière suivante aprés de loooooongues recherches:
1 - Désactiver le paramétrage forcé ovh /tmp du serveur mutualisé

  • dans .ovhconfig
  • ajouter la commande: app.engine.flags=noforcetmp
    2 - définir un nouveau répertoire « session » de sauvegarde des sessions
  • dans htdocs/conf/conf.php
  • ajouter: ini_set(‹ session.save_path ›, $_SERVER[‹ DOCUMENT_ROOT ›].’/session’)
    3 - créer le repertoire « www/session » avec le chmod 750
    4 - vérifier dans dolibarr Accueil/administration/session que les sessions sont bien visibles
    J’espére que cela pourra servir

Bonjour

Je ne connais pas bien les config OVH mais vous mettez le repertoire des sessions en zone web (www) et donc accessible ?
@+

j’ai déjà résolu le bug.
Je vais ensuite regarder les aspect sécurité et accessibilité et déplacer le répertoire
Merci du commentaire.