Restauration : pas d'utilisateurs !

ldauphin · 2005-11-07 12:14:20

Bonjour,

Ayant installé et testé avec grand succès et satisfactions Glpi 0.6 sur un poste de travail, j'ai décidé de le déployer sur notre serveur web intranet : Windows2000 / Apache 2.0.55 / MySQL 5.0 / Php5.0.5

Au passage, un grand Merci à Jonathan Wilson pour sa procédure bien détaillée.
Idéalement j'aurais préféré que la procédure soit dispo sous un format permettant d'ajouter facilement des personnalisations/commentaires...

Revenons à nos moutons...
Tout semble se passer correctement: ayant sauvegardé mes données au format SQL sur le premier poste, j'utilise ce fichier pour restaurer les données sur le serveur : aucun message d'erreur.
Un rapide vérification me confirme qu'à priori toutes les données sont bien présente SAUF LES UTILISATEURS !?

Problème N°1:
==> Seuls les utilisateurs helpdesk(1) et glpi(2) existent dans la base,
En vérifiant le fichier SQL, je trouve bien le bloc avec les "INSERT INTO glpi_users VALUES ..."

J'arrive à recréer mes utilisateurs en copiant les lignes correspondante et en les exécutant dans Phpadmin.

Par contre j'obtient un message d'erreur sur les utilisateurs 3 et 5 :
INSERT INTO glpi_users VALUES ('3','post-only','*5683D7F638D6598D057638B1957F194E4CA974FB','3177926a7314de24680a9938aaa97703','','','post-only','','no','0','','english');
INSERT INTO glpi_users VALUES ('5','normal','*F3F91B23FC1DB728B49B1F22DEE3D7A839E10F0E','fea087517c26fadd409bd4b9dc642555','','','normal','','no','0','','english');

#1265 - Data truncated for column 'tracking_order' at row 1

Problème N°2:
Il est impossible à tout utilisateur de poster une demande d'intervention. Nous obtenons systématiquement le message : "Votre problème ne peut pas être ajouté dans notre base de données.Veuillez prendre contact avec un technicien. SVP".
Toute autre opération semble possible (je peux ajouter/modifier/supprimer du matériel, ajouter une entreprise...)

J'ai le sentiment que le second problème est fortement lié à l'absence de l'utilisateur post-only.... quelqu'un aurait-il une piste à m'indiquer pour corriger ce problème ? Ai-je fait une fausse manip ? Est-ce lié à un bug ?

Merci de toute vos réponses et commentaires !

Laurent

Last edited by ldauphin (2005-11-07 12:39:34)

aurel · 2005-11-07 13:18:06

Tu peux toujours mettre tes modifs sur le wiki du projet mais pense à bien commenté histoire que tout le monde puisse en profiter. http://glpi.indepnet.org/wiki/wakka.php … Principale

@+

ldauphin · 2005-11-07 13:37:00

Non, je n'ai pas de modifs pertinentes à apporter au document, il s'agit juste de personnalisations des répertoires d'installation.

ldauphin · 2005-11-09 09:57:46

Problème N°1 :
J'avance doucement.... j'ai modifié l'instruction SQL en mettant 'yes' au niveau de la colonne 'tracking_order', cela m'a permis d'importer les deux utilisateurs.
Mais cela ne résoud pas mon problème N°2: il est toujours impossible d'enregistrer une demande saisie dans le helpdesk.
J'ai essayé en mettant 'no' dans cette meme colonne, sans amélioration....

Rappel Problème N°2:
Il est impossible à tout utilisateur de poster une demande d'intervention. Nous obtenons systématiquement le message : "Votre problème ne peut pas être ajouté dans notre base de données.Veuillez prendre contact avec un technicien. SVP".
Toute autre opération semble possible (je peux ajouter/modifier/supprimer du matériel, ajouter une entreprise...)

Quelqu'un aurait-il une piste à m'indiquer pour corriger ce problème ? Ai-je fait une fausse manip ? Est-ce lié à un bug ?

Merci d'avance pour toute suggestion.

Laurent.

Last edited by ldauphin (2005-11-09 11:28:20)

MoYo · 2005-11-09 11:39:41

Comme ca non je n'ai pas d'idée il faudrait voir ce que donne la base de données. Il y a du y avoir un problème dans la mise à jour.

ldauphin · 2005-11-09 12:25:01

Quelles informations concernant la base de données vous semblerait pertinente à regarder de plus près ?

J'ai vérifié les droits de l'utilisateur 'glpi' utilisé pour se connecter à la base, il a tout les droits sur la base ça devrait donc être ok

J'ai lancé une vérification des tables de la base de données avec phpmyadmin, toutes les tables sont OK, j'ai cependant les messages d'avertissement suivant :
Il y a des problèmes avec les index de la table `glpi_cartridges_assoc`
La colonne `FK_glpi_type_printer` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_computer_device`
Plus d'un index de type INDEX existe pour la colonne `device_type`
Il y a des problèmes avec les index de la table `glpi_connect_wire`
La colonne `end1` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_contact_enterprise`
La colonne `FK_enterprise` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_contract_device`
La colonne `FK_contract` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_contract_enterprise`
La colonne `FK_enterprise` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_doc_device`
La colonne `FK_doc` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_dropdown_kbcategories`
La colonne `parentID` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_links_device`
La colonne `device_type` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_monitors`
La colonne `ID` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index
Il y a des problèmes avec les index de la table `glpi_networking_vlan`
La colonne `FK_port` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_networking_wire`
La colonne `end1` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index
Il y a des problèmes avec les index de la table `glpi_printers`
La colonne `ID` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index
Il y a des problèmes avec les index de la table `glpi_repair_item`
Plus d'un index de type INDEX existe pour la colonne `device_type`
Il y a des problèmes avec les index de la table `glpi_state_item`
Plus d'un index de type INDEX existe pour la colonne `device_type`
Il y a des problèmes avec les index de la table `glpi_users`
La colonne `name` ne devrait pas faire partie à la fois d'une clé unique et d'une clé index

MoYo · 2005-11-09 12:40:51

Les problemes que vous rencontrez ne sont pas des problèmes. phpMyAdmin n'est pas très intelligent je dirais.
Car les unique que vous avez c'est des clés multiples donc il n'y a aucun problème.

ldauphin · 2005-11-09 12:50:58

J'ai supprimé les fichiers glpi, "droppé" la base de données correspondant et recommencé à 0 l'install de glpi.

je déploie glpi 0.6 + le patch
je lance l'install de glpi, créé une base de donnée avec un nom différent, a priori toujours pas de souci lors de l'install

Après l'installation j'ai 3 utilisateurs dans la base :
Helpdesk(1)
glpi(2)
tech(4)

Je me demande ce qu'il est advenu de post-only(3) et normal(5)

Il est toujours impossible d'enregistrer un helpdeskitem
J'utilise mon backupsql pour n'ajouter que les users 3 et 5
en modifiant la colonne 'tracking_order' à 'yes' ==> Il est toujours impossible d'enregistrer un helpdeskitem
en modifiant la colonne 'tracking_order' à 'no' ==> Il est toujours impossible d'enregistrer un helpdeskitem

Je n'arrive vraiment pas à m'expliquer pourquoi "ca ne marche qu'a moitié" ? Any suggestions ?

Merci d'avance,

Laurent.

Last edited by ldauphin (2005-11-09 18:40:20)

ldauphin · 2005-11-09 19:07:47

Bon, je crois avoir trouvé d'où viennent tous mes déboires : MySQL 5.0

J'ai simplement remplacé MySQL 5.0 par MySQL 4.1.15 et réinstallé glpi 0.6 plus ma sauvegarde et là ça marche nickel !

Si quelqu'un a déjà réussi à installer glpi avec MySQL 5.0 je veux bien qu'il me dise comment....

Bon, j'espère que c'est là mon dernier post concernant un problème sur mon install en attendant d'avoir suffisament d'expérience avec glpi pour contribuer à mon tour à aider les nouveaux !

Merci à tous, pour tout,

Laurent.

JMD · 2005-11-09 19:48:07

Content que votre pb soit résolu (en partie)

Erjo · 2005-11-14 18:04:35

J'ai trouvé le problème de ldauphin intéressant.
Donc j'ai testé.
Après 2 ou 3 conneries avec l'installation de PHP5/ Apache j'ai pu démarrer l'installation de GLPI.
Il y a déjà un petit 'bug' sur la détection de la version de Php. Glpi m'affiche que j'utilise du 4.x alors que je suis en 5. Mais bon passons.
Tout le reste se passe bien, sauf que comme notre ami ldauphin il me manque les utilisateurs post-only et normal.
En essayant de créer les comptes directement dans la base, méthode bestiale, j'en convient, le serveur MySQL me renvoie l'erreur suivante:

ERROR 1265 (01000): Data truncated for column 'tracking_order' at row 1
ERROR 1265 (01000): Data truncated for column 'tracking_order' at row 1

Dans le script SQL d'origine (glpi-0.6-empty.sql) le tracking_order vaut '', j'ai rajouter la valeur 'no', pour corriger le problème, et là ça fonctionne.

Par contre je ne sais pas si il vaut mieux mettre 'yes' ou 'no'.

ldauphin · 2005-11-14 18:30:34

Ca me rassure de ne pas être le seul confronté à ce problème (résolu voir plus haut)...

Erjo, as tu testé la création d'une demande de support ? Parce que j'aivais aussi créé "bestialement" les utilisateurs (un coup avec 'yes', l'autre avec 'no') et si je me souviens bien à chaque fois je me heurtais à l'impossibilité de valider ma demande de support...

Erjo · 2005-11-14 18:44:30

ldauphin wrote:

Ca me rassure de ne pas être le seul confronté à ce problème (résolu voir plus haut)...
Erjo, as tu testé la création d'une demande de support ? Parce que j'aivais aussi créé "bestialement" les utilisateurs (un coup avec 'yes', l'autre avec 'no') et si je me souviens bien à chaque fois je me heurtais à l'impossibilité de valider ma demande de support...

Oui j'ai le même problème.
Je suis gentillement renvoyé vers un technicien.

ldauphin · 2005-11-14 18:52:13

C'est bizzare non ?

Ma conclusion de béotien :
Avec MySQL 5.0, le champ tracking_order doit renseigné pour pourvoir créer un utilisateur.
Dans GLPI 0.6 les utilisateurs post-only et normal doivent être créés pour saisir un helpdesk item.
Dans GLPI 0.6 si les utilisateurs post-only et normal ont le champ tracking_order renseigné il est impossible de saisir un helpdesk item.
==> c'est le serpent qui se mord la queue !

Avec la version MySQL 4.1.15 tout baigne !

Erjo · 2005-11-14 19:09:28

Mouais.
M'enfin même en étant connecté avec le user glpi, ca ne fonctionne pas mieux.
Il faudrait qu'un des développeurs nous donne une piste à suivre.
Bon pour l'instant j'utilise toujours la version 0.6 avec MySQL 4.x. donc y a pas le feu...
Mais si ils avaient une idée...

MoYo · 2005-11-14 19:41:03

Ca ressemble à un problème dans le dump de MySQL.
Mais bon en voyant ce que vous me dites et en analysant ce qui se passe je pense que MySQL est un gros boulet.
le champ est :
tracking_order enum('yes','no') DEFAULT 'no' NOT NULL,
donc par defaut c'est 'no'
Ensuite on insère un user avec tracking_order = '' bref pas de quoi hurler. S'il ne comprend pas qu'il faut mettre 'no' c'est a dire la valeur par defaut c'est qu'il a un soucis quand meme.

J'ai corrigé le dump dans sur le CVS.

Pour le problème de helpdesk j'ai pas encore regardé. Mais je pense que c'est la meme chose MySQL hurle parce qu'un champ enum est définit a vide alors qu'il devrait etre rempli.
Si vous pouviez nous donner plus d'info a ce niveau là ca serait pas mal (requete qui foire etc etc)

ldauphin ton analyse n'est pas bonne je pense :

ldauphin wrote:

Dans GLPI 0.6 les utilisateurs post-only et normal doivent être créés pour saisir un helpdesk item.
Dans GLPI 0.6 si les utilisateurs post-only et normal ont le champ tracking_order renseigné il est impossible de saisir un helpdesk item.

Point 1 : il n'y a aucune raison pour que ce soit vrai.
Point 2 : impossible avec quel utilisateur ?

Pour info, GLPI n'est developpé que sous PHP4 et mysql 4 nous n'avons jamais testé sous d'autres archi.
Normalement la compatibilité ascendante devrait faire que cela fonctionne sans problème mais bon...

Erjo · 2005-11-14 20:16:19

Ben voilà vous venez de trouver deux beta testeurs
Cela dit j'ai regardé la doc sur le site de MySQL et normalement le dump devrait fonctionner en l'état.
MySQL gros boulet ? auriez-vous un portage sous PostgreSQL en vue

MoYo · 2005-11-14 20:27:58

Non pas de portage postgresql en vue. Mais c'est juste que je trouve ca moyen comme comportement.

pour les beta testeurs il me faudrait les requetes d'inclusion d'interventions avec les retours SQL pour voir ou cela peut poser problème

Erjo · 2005-11-14 20:44:53

Pas de prob.
Je fais ça comment ? Un flag 'debug' à activer dans les scripts ?

Erjo · 2005-11-14 20:50:35

Pour en finir avec MySQL et le type ENUM, j'ai trouvé un commentaire sur leur doc qui remonte à peu pr^t le mêmpe problème:

Posted by Andy Macdonald on April 6 2005 1:38pm [Delete] [Edit]

A small point that may save someone some time.
When defining an ENUM field, MySQL apparently requires an explicit 'NOT NULL' statement.
For example a table definition including a column definition like:

`BasicType` ENUM( 'organisation', 'individual' ) DEFAULT 'individual',

will fail, but succeeds when changed to:

`BasicType` ENUM( 'organisation', 'individual' ) NOT NULL DEFAULT 'individual',

Mais je suis d'accord avec toi ce n'est pas un comportement normal.

MoYo · 2005-11-14 22:55:40

nos enum sont tous NOT NULL sauf 1.
c'est celui là qui peut poser problème.
Vous pouvez tester en modifiant le champ status de la table glpi_tracking en le mettant en NOT NULL.

MoYo · 2005-11-14 22:59:01

Si c'est ca c'est corrigé dans le CVS

Erjo · 2005-11-15 00:14:13

Non, ca ne change rien.
Par contre j'ai rajouté un echo mysql_error() et j'obtient ça:

Incorrect datetime value: '' for column 'closedate' at row 1

Erjo · 2005-11-15 00:58:02

Ouf...
J'ai enfin réussit à dérouler l'écheveau de votre code...
C'est joliment fait d'ailleurs.
Afin de vérifier ma théorie j'ai bidouuillé la fonction putinJob de la classe Job pour lui faire mettre un format de date acceptable par ce - bip - de MySQL5.

if ($this->status=="old") {
$this->closedate = date("Y-m-d H:i:s");
} else {
$this->closedate = '0000-00-00 00:00:00';
}

C'est crado mais ça fonctionne.

Par contre j'ai vu dans la doc MySQL que l'on pouvait jouer sur le Mode SQL du serveur.
C'est peut être une meilleur solution.
Je commence à comprendre à quoi correspond l'option 'strict mode' qui est proposé au moment de l'installationde MySQL...

Last edited by Erjo (2005-11-15 01:16:30)

Erjo · 2005-11-15 01:15:58

Haaaaaa (soupir d'aise...).
Je l'ai eu.

J'ai enlevé mabidouille dans la classe job.

Pour que cela fonctionne il faut soit:

- Eviter de cocher la case "Enable strict Mode" lors de la configuration de l'instance MySQL

- Utiliser l'option --sql-mode="MYSQL40" au démarrage du serveur (Si l'instance est déjà installé)

- Ou alors, je pense que l'on doit pouvoir mettre cette option dans le my.ini dans la section [mysqld]

Moi j'ai fait les test 'en live' avec la fonction 'SET GLOBAL sql_mode="MYSQL40" et ça fonctionne.
Pour ce qui est du mode SQL à choisir il y 'en a une palanqué, il y a peut être moyen d'affiner un peu.
Voir la page [url]http://dev.mysql.com/doc/refman/5.0/fr/ … -mode.html {/url] pour ceux que ça intéresse.

Bon c'est tout pour ce soir.

Last edited by Erjo (2005-11-15 12:22:01)

Forum GLPI-Project

Announcement

#1 2005-11-07 12:14:20

Restauration : pas d'utilisateurs !

#2 2005-11-07 13:18:06

Re: Restauration : pas d'utilisateurs !

#3 2005-11-07 13:37:00

Re: Restauration : pas d'utilisateurs !

#4 2005-11-09 09:57:46

Re: Restauration : pas d'utilisateurs !

#5 2005-11-09 11:39:41

Re: Restauration : pas d'utilisateurs !

#6 2005-11-09 12:25:01

Re: Restauration : pas d'utilisateurs !

#7 2005-11-09 12:40:51

Re: Restauration : pas d'utilisateurs !

#8 2005-11-09 12:50:58

Re: Restauration : pas d'utilisateurs !

#9 2005-11-09 19:07:47

Re: Restauration : pas d'utilisateurs !

#10 2005-11-09 19:48:07

Re: Restauration : pas d'utilisateurs !

#11 2005-11-14 18:04:35

Re: Restauration : pas d'utilisateurs !

#12 2005-11-14 18:30:34

Re: Restauration : pas d'utilisateurs !

#13 2005-11-14 18:44:30

Re: Restauration : pas d'utilisateurs !

#14 2005-11-14 18:52:13

Re: Restauration : pas d'utilisateurs !

#15 2005-11-14 19:09:28

Re: Restauration : pas d'utilisateurs !

#16 2005-11-14 19:41:03

Re: Restauration : pas d'utilisateurs !

#17 2005-11-14 20:16:19

Re: Restauration : pas d'utilisateurs !

#18 2005-11-14 20:27:58

Re: Restauration : pas d'utilisateurs !

#19 2005-11-14 20:44:53

Re: Restauration : pas d'utilisateurs !

#20 2005-11-14 20:50:35

Re: Restauration : pas d'utilisateurs !

#21 2005-11-14 22:55:40

Re: Restauration : pas d'utilisateurs !

#22 2005-11-14 22:59:01

Re: Restauration : pas d'utilisateurs !

#23 2005-11-15 00:14:13

Re: Restauration : pas d'utilisateurs !

#24 2005-11-15 00:58:02

Re: Restauration : pas d'utilisateurs !

#25 2005-11-15 01:15:58

Re: Restauration : pas d'utilisateurs !

Board footer