Bonjour

J'essaye de mettre en place une solution de Gestion Libre de Parc Informatique.

Cette solution se compose de 2 applications:
     GLPI:                            http://glpi-project.org/
     OCS Inventory NG:     http://ocsinventory.sourceforge.net/index.php?page=French

Pour GLPI pas de problèmes, l'installation est aussi simple qu'un CMS de type Mambo ou Spip.
Pour OCS Inventory c'est différent!

   Les serveurs ont besoin de modules PERL

   Requirements.
       Apache version 1.3.33 or higher / Apache version 2.0.46 or higher.
       Mod_perl version 1.29 or higher.
       Mod_php version 4.3.2 or higher.
       PHP 4.1.0 or higher, with ZIP and GD support enabled.
       PERL 5.6 or higher.
       Perl module XML::Simple version 2.13-1 or higher.
       Perl module Compress::Zlib version 1.34-1 or higher.
       Perl module DBI version 1.46-5 or higher.
       Perl module DBD::Mysql version 2.9003-3 or higher.
       Perl module Apache:: DBI version 0.94-2 or higher.
       MySQL version 4.1.0 or higher with InnoDB engine active.
       Make utility like GNU make.

--------------------------------------------------------------------------------
-
Voici la liste des modules PERL qui sont installés sur le système

Apache:: DBI --1.05
Apache:: Ocsinventory --0.80
Authen:: PAM --0.16
BSD:: Resource --1.28
Compress:: Zlib --1.42
DBD:: mysql --3.0008
DBI -- 1.53
Digest:: SHA1 --2.11
Locale:: gettext --1.05
Math-BigInt  -- ???
Net:: IP -- 1.25
Net:: SSLeay --1.30
Perl -- 5.8.8
Storable -- 2.15
XML:: Parser --2.34
XML:: Simple --2.16
mod_perl2 -- 2.000002
--------------------------------------------------------------------------------
---------------------------------------------
Le systeme est Freebsd6.1p10

Les serveurs:

Appache22, PHP5.2.0 , Mysql  Ver 14.12 Distrib 5.0.27, for portbld-freebsd6.1 (i386) using  5.0
--------------------------------------------------------------------------------
----------------------------------------------

APACHE2HANDLER
Apache Version	Apache/2.2.3  (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 PHP/5.2.0 with Suhosin-Patch mod_perl /2.0.2 Perl/v5.8.8
Apache API	Apache API
Server Administrator	webmaster@domaine
Hostname: Port	machine.domaine:0
User/Group	www(80)/80
Max Requests	Per Child: 10000 - Keep Alive: on - Max Per Connection: 100
Timeouts Connection:	300 - Keep-Alive: 5
Virtual Server	Yes
Server Root	/usr/local
Loaded Modules	core prefork http_core mod_so mod_authn_file mod_authn_dbm od_authn_anon mod_authn_default mod_authn_alias mod_authz_host mod_authz_groupfile       od_authz_user mod_authz_dbm mod_authz_owner mod_authz_default mod_auth_basic mod_auth_digest od_file_cache mod_cache mod_disk_cache mod_include mod_filter mod_charset_lite mod_deflate od_log_config mod_logio mod_env mod_mime_magic mod_cern_meta mod_expires mod_headers od_usertrack mod_unique_id mod_setenvif mod_version mod_ssl mod_mime mod_status mod_autoindex od_asis mod_info mod_cgi mod_vhost_alias mod_negotiation mod_dir mod_imagemap mod_actions od_speling mod_userdir mod_alias mod_rewrite mod_php5 mod_perl

--------------------------------------------------------------------------------
-----------------------------------------------------------
Mon problème est le suivant:
Quand je lance l'application OCS  (apres avoir réussi l'installation) .
                  c.a.d : http://Serveur/ocsreports
j'obtiens le code source de la page!   (cela fait comme si apache22 ne prenait pas en charge les scripts *.php )!!!
--------------------------------------------------------------------------------
-----------------------------------------------------------
Est ce que vous auriez une idée à soumettre pour essayer de debugger ce problème?

Merci d'avance.

ros wrote on 26. Nov 2006 at 11:59:


C'est Ok pour mon fichier de config.
Voici l'erreur que je constate dans mon fichier de httpd-error.log:

[Sun Nov 26 17:58:41 2006] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.7e-p1
PHP Warning:  PHP Startup: PDO: Unable to initialize module\nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP    compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0
[Sun Nov 26 17:58:41 2006] [notice] Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 PHP/5.2.0 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations

En effet, le problème est que apache ne semble pas reconnaitre les extentions .php comme etant des cgi à pré processer. Le premièr log d'erreurs montait bien que apache ne reussisait pas à charger son module php.

Essayes une sois apache arreté :
# apachectl stop

efface les fichiers httpd_error.log et httpd-acces.log

puis relance apache :
# apachectl start

verifie qu'il n'y a plus d'erreur dans le fichier de log ni en ligne de commande lors du lancement.
Apres ça essayes  d'executer l'application et envoie les resultats.
PS : As tu jeté un coup d'oeuil sur ton  /var/log/messages?

Bonne chance

J'ai passé ces valeurs à 8M, plus histoire de faire taire le warning qu'autre chose, n'utilisant pas (encore ?) la fonctionnalité en question. Mais en regardant install.php, on voit qu'il n'y a aucun test (pas de valeur "plancher" ou "recommandée"): si tu venais à faire usage de ce truc, fais-nous un retour sur ta "bonne valeur", merci

Pense aussi à changer le password de la BDD. Attention: on le trouve à différents endroits. Ici, sur Buzuntu: /var/www/ocsreports/dbconfig.inc.php, /var/www/ocsreports/ipdiscover-util.pl et /etc/apache-perl/conf.d/ocsinventory.conf. Ca m'a pris un moment pour comprendre pourquoi mon OCS était en l'air après avoir changé le password et mis à jour seulement le dbconfig.inc.php...

C'est globalement pas très propre (voir la gueule du setup.sh de l'agent Linux, notamment) mais enfin, pas de souci jusqu'à présent, et les fonctionnalités valent bien le petit effort à installer le truc (qui a déjà fait un tour de parc pour noter divers numéros de série, de modèles, etc. sur son bloc-notes comprendra bien...)

kermitt wrote on 29. Nov 2006 at 04:54:

Normal, c'était une question un peu bête en soi. Après avoir lu sur le sujet ("OCSng package deployment"), j'ai regardé un peu notre mirroir pour voir jusqu'à quelle taille de paquet on pouvait avoir à distribuer.
S'agissant d'Ubuntu (toutes releases, dépôts main, restricted et universe), ça donnerait (notez le conditionnel*):
Code:

(...)/ubuntu# nice find pool -type f -exec ls -l {} \;| awk '{printf "%s\t\t%s\n", $5, $9}'|sort -n|tail
144382484		pool/universe/o/openclipart/openclipart-png_0.18+dfsg-4_all.deb
146628071		pool/main/i/ia32-libs-openoffice.org/ia32-libs-openoffice.org_11.tar.gz
148486719		pool/main/i/ia32-libs-openoffice.org/ia32-libs-openoffice.org_11.0.1.tar.gz
150252658		pool/main/i/ia32-libs/ia32-libs_0.5ubuntu3.tar.gz
150314670		pool/main/i/ia32-libs/ia32-libs_0.5ubuntu3.1.tar.gz
152189029		pool/main/i/ia32-libs-openoffice.org/ia32-libs-openoffice.org_11.1.tar.gz
155776930		pool/universe/v/vegastrike-data/vegastrike-data_0.4.3-2_all.deb
161313230		pool/universe/f/fgfs-base/fgfs-base_0.9.10-1_all.deb
172933827		pool/main/i/ia32-libs/ia32-libs_1.4ubuntu4.tar.gz
237971679		pool/main/i/ia32-libs/ia32-libs_1.5ubuntu5.tar.gz 

Quand même, hein ?..
kermitt wrote on 29. Nov 2006 at 04:54:

Donc, ces réglages qui me paraissaient un peu 'fantaisistes' sont en fait justifiés

* MAIS OCSng fait peut-être un bon boulot en matière d'inventaire du parc, ne lui demandons pas non plus: pour distribuer des fichiers, exécuter des commandes sur les clients, etc. il y a déjà de très bons outils comme CFEngine. Pas la peine de vouloir réinventer la roue, des fonctionalités en moins et des bugs en plus.
Juste my 2 centimes, comme on dit.