You are not logged in.
Pages: 1
Topic closed
Bonjour,
Après qlq heure de recherche, je me décide à poster.
Qd je cherche à interfacer GLPI (0.71.6) et OCS NG (1.02) j'ai un message d'erreur :
(http://glpi-project.org/wiki/doku.php?i … nfig:ocsng)
Configuration / Mode OCSNG
Nom : Nom de mon serveur OCS
Hote OCSweb : @IP de mon serveur OCS (il n'est pas dans le même VLAN mais il répond bien)
Nom de la base de données OCS : ocsweb
Utilisateur de la base de données OCSweb : ocs (Connexion OK avec PhpMyAdmin)
Mot de passe de la base de données OCSweb : ocs
"Échec de connexion à la base de données OCS NG"
Une idée ?
Offline
En mode debug pour avoir l'erreur complète ?
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Alors en mode debug ça donne :
PHP ERROR: mysql_connect() [function.mysql-connect]: Lost connection to MySQL server at 'reading initial communication packet', system error: 0 in /var/www/glpi/inc/dbmysql.class.php at line 74
Échec de connexion à la base de données OCS NG
GLPI 0.71.6 Copyright (C) 2003-2009 by the INDEPNET Development Team.
GLPI MODE DEBUG
GLPI MODE DEBUG
SQL REQUEST : 2 Queries took 0.001s
N° Queries Time Errors
1 SELECT *
FROM `glpi_ocs_config`
WHERE (`ID` = '2') 0.001
2 SELECT *
FROM glpi_ocs_config
WHERE ID='2' 0.000
POST VARIABLE
GET VARIABLE
KEY => VALUE
ID => 2
SESSION VARIABLE
KEY => VALUE
glpi_currenttime => 2009-06-10 11:22:08
glpiID => 146
glpiname => boutet
glpirealname => Boutet
glpifirstname => S
glpilanguage => fr_FR
glpidefault_entity => 0
glpitracking_order => 0
glpiauthorisation => 1
glpiextauth => 0
glpiauth_method => 1
glpisearchcount =>
KEY => VALUE
15 => 1
32 => 1
glpisearchcount2 =>
KEY => VALUE
15 => 0
32 => 0
glpiroot => /glpi
glpilist_limit => 10000
glpicrontimer => 1244625706
glpiprofiles =>
KEY => VALUE
4 =>
KEY => VALUE
ID => 4
name => super-admin
interface => central
is_default => 0
computer => w
monitor => w
software => w
networking => w
printer => w
peripheral => w
cartridge => w
consumable => w
phone => w
notes => w
contact_enterprise => w
document => w
contract_infocom => w
knowbase => w
faq => w
reservation_helpdesk => 1
reservation_central => w
reports => r
ocsng => w
view_ocsng => r
sync_ocsng => w
dropdown => w
entity_dropdown => w
device => w
typedoc => w
link => w
config => w
rule_tracking => w
rule_ocs => w
rule_ldap => w
rule_softwarecategories => w
search_config => w
search_config_global => w
check_update => r
profile => w
user => w
user_auth_method => w
group => w
entity => w
transfer => w
logs => r
reminder_public => w
bookmark_public => w
backup => w
create_ticket => 1
delete_ticket => 1
comment_ticket => 1
comment_all_ticket => 1
update_ticket => 1
own_ticket => 1
steal_ticket => 1
assign_ticket => 1
show_all_ticket => 1
show_assign_ticket => 1
show_full_ticket => 1
observe_ticket => 1
update_followups => 1
show_planning => 1
show_group_planning => 1
show_all_planning => 1
statistic => 1
password_update => 1
helpdesk_hardware => 2
helpdesk_hardware_type => 2
show_group_ticket => 0
show_group_hardware => 0
rule_dictionnary_software => w
rule_dictionnary_dropdown => w
entities =>
KEY => VALUE
142 =>
KEY => VALUE
ID => 0
name =>
completename =>
recursive => 1
glpiactiveprofile =>
KEY => VALUE
ID => 4
name => super-admin
interface => central
is_default => 0
computer => w
monitor => w
software => w
networking => w
printer => w
peripheral => w
cartridge => w
consumable => w
phone => w
notes => w
contact_enterprise => w
document => w
contract_infocom => w
knowbase => w
faq => w
reservation_helpdesk => 1
reservation_central => w
reports => r
ocsng => w
view_ocsng => r
sync_ocsng => w
dropdown => w
entity_dropdown => w
device => w
typedoc => w
link => w
config => w
rule_tracking => w
rule_ocs => w
rule_ldap => w
rule_softwarecategories => w
search_config => w
search_config_global => w
check_update => r
profile => w
user => w
user_auth_method => w
group => w
entity => w
transfer => w
logs => r
reminder_public => w
bookmark_public => w
backup => w
create_ticket => 1
delete_ticket => 1
comment_ticket => 1
comment_all_ticket => 1
update_ticket => 1
own_ticket => 1
steal_ticket => 1
assign_ticket => 1
show_all_ticket => 1
show_assign_ticket => 1
show_full_ticket => 1
observe_ticket => 1
update_followups => 1
show_planning => 1
show_group_planning => 1
show_all_planning => 1
statistic => 1
password_update => 1
helpdesk_hardware => 2
helpdesk_hardware_type => 2
show_group_ticket => 0
show_group_hardware => 0
rule_dictionnary_software => w
rule_dictionnary_dropdown => w
entities =>
KEY => VALUE
142 =>
KEY => VALUE
ID => 0
name =>
completename =>
recursive => 1
glpi_entities_tree =>
KEY => VALUE
0 =>
KEY => VALUE
0 =>
KEY => VALUE
name => Entité Racine
tree =>
glpiactiveentities =>
KEY => VALUE
0 => 0
glpi_entities_ancestors =>
KEY => VALUE
0 =>
glpiactive_entity => 0
glpiactive_entity_name => Entité Racine (arborescence)
glpiactive_entity_shortname => Entité Racine (arborescence)
glpishowallentities => 1
glpigroups =>
glpi_plugins =>
MESSAGE_AFTER_REDIRECT =>
glpi_multientitiesmode => 0
glpi_viewcentral => my
glpisearch =>
KEY => VALUE
15 =>
KEY => VALUE
start => 0
order => ASC
deleted => 0
distinct => N
link =>
field =>
KEY => VALUE
0 => view
contains =>
KEY => VALUE
0 =>
link2 =>
field2 =>
KEY => VALUE
0 => view
contains2 =>
KEY => VALUE
0 =>
type2 =>
sort => 1
32 =>
KEY => VALUE
start => 0
order => ASC
deleted => 0
distinct => N
link =>
field =>
KEY => VALUE
0 => view
contains =>
KEY => VALUE
0 =>
link2 =>
field2 =>
KEY => VALUE
0 => view
contains2 =>
KEY => VALUE
0 =>
type2 =>
sort => 1
glpimassiveactionselected =>
glpi_configgen => 1
PHP ERROR: mysql_close(): supplied argument is not a valid MySQL-Link resource in /var/www/glpi/inc/dbmysql.class.php at line 296
Offline
Une idée ?
Merci
Last edited by sboutet (2009-06-15 12:16:25)
Offline
- votre user a le droit de se connecter à la base mysql ?
- vous n'auriez pas dans le my.cnf de mysql une ligne qui n'autorise la connexion qu'à localhost seulement ?
- votre base de données est sur windows ? linux ?
Offline
- votre user a le droit de se connecter à la base mysql ?
>>> L'utilisateur 'ocs' peut se connecter sur la base ocsweb (je m'y connecte avec phpmyadmin)
- vous n'auriez pas dans le my.cnf de mysql une ligne qui n'autorise la connexion qu'à localhost seulement ?
>>> Je ne pense pas, car d'autre serveur GLPI s'y connect (avec des classes d'adresse différente)
- votre base de données est sur windows ? linux ?
Linux
Petite précision, mon serveur GLPI est une copie de l'environnement de production
Voila comment j'ai procèder pour le copier :
- Installation de GLPI 0.68.3 sur mon serveur de test
- Restauration de la base de prod + recopie des fichier de \files
- Mise à jours en 0.71.6 (Mise à jours effectué avec succès et sans erreur) tjours sur
Offline
...
car d'autre serveur GLPI s'y connect
.....
Petite précision, mon serveur GLPI est une copie de l'environnement de production
...
C'est une mauvaise idée de faire pointer plusieurs GLPI vers le même serveur OCS.
En effet la synchro "modifie" la base OCS.
Avec cette configuration, le risque de perdre des données (des inventaires avec changement) est important.
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Il y 3 service qui utilise le serveur OCS,
Par contre, chaque machine référencé dans la base ocs sont tagger du nom du service.
Normalement pas de Pb de syncro car on ne remonte que celle qui nous intéresse.
Enfin de tt façon le pb ne se pose pas comme je ne peux m'y connecter ;-)
Offline
Normalement pas de Pb de syncro car on ne remonte que celle qui nous intéresse
Sauf que les changements d'ID (traitement de la table deleted_equiv) ne sera faite qu'une fois (elle est vidée après la synchro).
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
et changement de valeur du tag après la synchro aussi
Offline
En clair,
Je dois utilisé un autre serveur OCS pour que mon GLPI ne soit le seul à l'utiliser.
Ça ne m'arrange pas vraiment. (Config des postes clients, Récup des donnée du serveur OCS actuel...)
De plus, cette méthode fonctionne pour les 2 autres services.
Enfin ds tt les cas, ça ne résous pas mon pb de cnx de GLPI sur la base d'OCS
Merci
Offline
Tjours pas d'idée ? (autre que refaire un serveur OCS)
Merci
Offline
Je pense que mon Pb doit venir du serveur OCS que j'utilise.
En effet, j'ai monté un autre serveur OCS sur la même machine que j'utilise pour GLPI et ça marche.
Merci à tous
Last edited by sboutet (2009-06-30 10:44:41)
Offline
Parfait. Je ferme
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
Topic closed