You are not logged in.
Pages: 1
Bonjour,
J’ai un pb avec la base glpi
Actuellement je n’arrive pas a me reconnecter sur ma base => message d’erreur « L'action que vous avez demandée n'est pas autorisée. Recharger la page précédente avant de faire une action à nouveau « .
Apres avoir tâtonner j’ai décidé de remonter une base neuve en dernière version et de réimporter une de mes sauvegardes.
Je créer dans une nouvelle base , et j’installe glpi , à vide tout fonctionne bien , je fais une sauvegarde de la base via le module de maintenance.
Puis je restaure mon ancienne base et la de nouveau et gros problème, je n’arrive plus a me connecter « L'action que vous avez demandée n'est pas autorisée. Recharger la page précédente avant de faire une action à nouveau »
Est-ce que qqu a une idée, ou plusieurs, pour « réinjecter les data « dans ma base vide ?
Merci d'avance
Offline
Version de GLPI ?
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonsoir
La version de GLPI =>0.84.4
La base était sous GLPI version 0.83
Merci
Offline
Et vous avez eu des problèmes lors de la migration ?
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour
Merci de votre intérêt
effectivement lorsque j'ai fait la maj. j'ai un messager d'erreur qui m'indiquait que j'avais un problème de GLPI par rapport a ma base
C'est pourquoi j'ai refait une Install avec un version plus ancien de GLPI sur une nouvelle base propre et vide
afin de valider la config
lorsque je restore mon ancienne base la le pb survient
Offline
Bonjour,
avez vous essayer le purger la table "glpi_logs" de la base glpi ?
Offline
Bonjour et merci
non je n'avais pas pensé a ça , quel est la commande a faire ?
Merci
Offline
Bonjour et merci
non je n'avais pas pensé a ça , quel est la commande a faire ?
Merci
Bonjour,
Quel est la taille de la table sql ?
d'abort la verifier :
CHECK TABLE `glpi_logs`
si elle est trop grosse ou ingerable par votre serveur > la solution de purge :
TRUNCATE TABLE `glpi_logs`
vous pouvez executer ces commandes directement depuis phpmyadmin si vous l'avez sur votre serveur.
Offline
Bonjour
j'ai bien effectué les commande sans proble
par contre après j'ai tjrs le meme message aprs le login
"L'action que vous avez demandée n'est pas autorisée. Recharger la page précédente avant de faire une action à nouveau"
Offline
Bonjour,
Je crois avoir eu le même problème sur ma base.
J'ai du désactiver le SELINUX en faisaint : setenforce 0
Offline
Salut à tous,
déjà en guise de premier post par ici, un grand merci pour ce chouette logiciel et tous ces plugins ! Je l'utilise dans le cadre d'une petite asso marseillaise d'entraide informatique.
Je rencontre le même souci énoncé plus haut mais disons partiellement.
J'ai le souci quand je me connecte en ipv6, que ce soit sur le port 80 ou 443. En ipv4, aucun problème.
(à confirmer : l'accès depuis le même préfixe que le serveur)
TRUNCATE TABLE `glpi_logs` -> pas d'amélioration
D'autres services installés sur la même racine répondent parfaitement en ipv6.
debian 7.8 / PHP 5.4.39 / Apache/2.2.22 / GLPI 0.85.1
Offline
Maxw : vous ne pouvez pas restaurer une base 0.83 dans une structure vide en 0.84. Les 2 structures sont trop différentes.
Dans votre version 0.84, il faut créer une base 0.83, importer votre base de prod et laisser GLPI faire sa migration.
Votre base sera donc transformer, avec vos données en base 0.84 et là, vous pourrez l'utiliser.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Pages: 1