OCS Inventory - PB télédéploiement

Par rapport à php, c'est effectivement php5 qui est utilisé sous debian. On peut espérer que ce qui était codé en php4 continue à marcher en php5 donc pour moi ce n'est pas forcément un drame, surtout si tu as installé ocsinventory via le gestionnaire de paquets (les gens qui préparent les paquets debian ont dû prévoir le coup !).

(mando@aldur) (~) $ aptitude show ocsinventory-server
Paquet : ocsinventory-server                  
État: non installé
Version : 2.0.2-2
Priorité : supplémentaire
Section : web
Responsable : Pierre Chifflier <pollux@debian.org>
Taille décompressée : 404 k
Dépend: ucf (>= 0.28), libapache2-mod-perl2, libxml-simple-perl, libcompress-zlib-perl, libdbi-perl,
         libdbd-mysql-perl, libnet-ip-perl, libphp-pclzip, libapache-dbi-perl, libjs-jquery, apache2
...

On voit ici que normalement tu n'as pas à te poser de questions existentielles sur les modules apache à utiliser (pour perl j'entends). Pour avoir les bases sur apache, je t'invite à lire ce tutoriel :
http://www.mistra.fr/tutoriel-linux-serveur-web-apache2.html

Après lecture, tu as compris qu'il faudrait au moins activer le module perl2 et relancer apache :

aptitude update
aptitude safe-upgrade
aptitude install apache2 libapache2-mod-perl2 libapache2-mod-php5
a2enmod php5
a2enmod perl
service apache2 restart

Pour ton fichier manquant, il te manque le paquet qui le fournit. Pour trouver quel paquet le fourni, tu peux utiliser apt-file

aptitude install apt-file
apt-file update
apt-file search /usr/lib/libmysqlclient_r.so

Dans le cas présent cette commande donc :

(mando@aldur) (~) $ apt-file search /usr/lib/libmysqlclient_r.so
libmysqlclient-dev: /usr/lib/libmysqlclient_r.so
libmysqlclient16: /usr/lib/libmysqlclient_r.so.16
libmysqlclient16: /usr/lib/libmysqlclient_r.so.16.0.0

On installe le paquet correspondant :

aptitude install libmysqlclient16

Bonne chance

Bonjour,
En fait, j'ai bien fait l'installation par le paquet debian, mais pourtant, je te garantie bien que le module perl en question n'était pas installé.
En redémarrant tout ce qui concernait perl puis apache, j'ai pu de nouveau accéder au site, cependant, j'ai toujours un problème de télédéploiement.
J'ai créé en parallèle un fil de discussion sur le forum ocs...
Je pense qu'il s'agit d'un problème de certificat, mais je ne vois comment le régler.

J'ai même régénéré le certificat avec l'adresse IP du serveur dans le CN, mais ça n'a rien réglé.

L'inventaire fonctionne parfaitement, mais le télédéploiement ne se fait pas.
Je n'ai plus d'erreur dans le fichier error.log d'apache, donc je ne sais pas quoi modifier.

Je viens de regarder le fichier ss-access.log et les lignes correspondant à mes dernières tentatives sont celles-ci :

192.168.1.3 - - [20/Nov/2011:14:14:24 -1000] "GET /favicon.ico HTTP/1.1" 404 628 "-" "Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2"
192.168.1.3 - - [21/Nov/2011:06:41:19 -1000] "GET / HTTP/1.1" 200 1486 "-" "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.16) Gecko/20111108 Iceweasel/3.5.16 (like Firefox/3.5.16)"
192.168.1.3 - - [21/Nov/2011:06:41:19 -1000] "GET /favicon.ico HTTP/1.1" 404 628 "-" "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.16) Gecko/20111108 Iceweasel/3.5.16 (like Firefox/3.5.16)"
192.168.1.3 - - [21/Nov/2011:06:41:22 -1000] "GET /favicon.ico HTTP/1.1" 404 628 "-" "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.16) Gecko/20111108 Iceweasel/3.5.16 (like Firefox/3.5.16)"

A bientux.



Une idée reçue est souvent une idée morte.

En gros c'est simplement que les navigateurs téléchargent favicon.ico (pour mettre une petite icône dans la barre du navigateur ou dans les onglets).

Typiquement quand tu vas sur CCM, firefox fait une requête HTTP pour demander (bien que rien dans le code HTML de la page n'y fasse forcément référence) :
http://www.commentcamarche.net/favicon.ico

De deux choses l'une : soit ce fichier est bien disponible à la racine du vhost apache correspondant (ce qui est le cas dans l'exemple de CCM), soit il n'y ait pas. Dans ce cas, apache n'a pas de fichier à retourner (bien qu'un client l'ait explicitement demandé) donc il le loggue.

En d'autre termes, une façon de lever ce warning consiste simplement à mettre à disposition un fichier favicon.ico. En tout cas ça n'a rien à voir avec ton problème.

Avant de lire la suite, je n'ai jamais déployé d'OCS inventory donc je peux me craquer complètement, mais voici mon interprétation de ton cas, qui ressemble à un problème similaire que j'ai déjà rencontré.

La piste du certificat est tout à fait crédible : généralement le client doit, quand il reçoit un certificat qui n'est pas signé par une autorité valide dire s'il a confiance ou non en ce certificat. Ceci demande une démarche active de la part du client. Prenons un exemple : le site de la SNCF utilise un certificat signé par une autorité valide, donc tu n'as pas à valider leur certificat quand tu fais ta transaction.

Au contraire, si ce certificat n'était pas signé par une autorité de confiance, on te demanderait d'examiner le certificat, de vérifier que l'empreinte correspond bien à ce qu'il faut (en d'autres termes, que ce n'est pas quelqu'un d'autre qui usurpe le site en question) et dans ce cas de l'accepter. Dans ce cas, le client mémorise que ce certificat est correct.

Le problème c'est que dans un contexte automatisé, si le certificat n'est pas automatiquement "accepté", comme il n'y a personne pour le valider, généralement ça plante...

Prenons un exemple, un peu éloigné de ton problème initial mais qui met en évidence un soucis similaire. J'installe apache + webdav (ceci permet de faire du svn via http, peu importe ce qu'est svn).

1) Je veux interfacer un serveur redmine (peu importe ce que c'est) qui va se connecter en svn à mon apache + webdav. Tant que je suis en http, pas de soucis.

2) Supposons que je passe en https et que mon apache utilise un certificat SSL self-signed (donc pour lequel je dois de manière active valider le certificat).

3) Quand redmine va se connecter à apache vu que le certificat n'est pas validé. Or pas de pot redmine est un serveur donc contrairement à un navigateur internet (explicitement lancé par un utilisateur), il n'a pas moyen de demander à qui que ce soit de valider ce certificat. Conclusion : il plante.

4) Seule solution, se placer dans le contexte de redmine, valider le certificat pour lui, et mémoriser ce certificat. Ainsi lors des connexions ultérieures, pas de soucis.

=> Dans cet exemple, il faudrait reproduire une connexion svn cliente vers le serveur apache (en étant identifié avec l'utilisateur qui lance redmine), valider le certificat.

Dans ton cas c'est assez problématique, car ça veut dire que tu dois intervenir sur chaque poste client pour qu'il accepte systématiquement ton certificat. J'imagine que chacun des postes en question installe un agent ocs-inventory et que c'est donc au niveau de la configuration de cet agent que tu dois préciser que ton certificat est correct (ou reproduire sur chaque poste client une connexion ocs vers ton serveur et valider le certificat, ce qui est un tout petit peu gênant dans le cas d'un auto-déploiement). Bref, pour moi le soucis, c'est peut-être que ton certificat n'est pas signé par une autorité qui est automatiquement validé par tes postes clients.

Bonne chance

Bonjour,
En effet, les agents sont déployés avec un certificat.
Il y a deux méthodes de déploiement, mais la plus efficace demeure un utilitaire spécifique qui s'appelle Agent Deploy Tool et qui permet même de passer outre les UAC de Win7 et Vista.

Sur ma machine virtuelle je n'ai pas utilisé cet outil, par contre en production je l'ai fait.

Je vais essayé de le faire en test et voir si ça change quelque chose.
De toute façon, même en prod, j'ai un problème avec SSL, mais à première vue SSL était plantée à cause d'une petite erreur de configuration, mais on ne pouvait pas relancer apache dans la journée, donc nous verrons la semaine prochaine.

Bizarrement, à la maison, ça a marché, mais ça ne marche plus.

[Sun Nov 27 09:22:10 2011] [info] [client 192.168.1.3] (70007)The timeout specified has expired: SSL input filter read failed.
[Sun Nov 27 09:22:10 2011] [info] [client 192.168.1.3] Connection closed to child 3 with standard shutdown (server ocsweb:443) 

Comme je t'ai dit, je n'ai jamais utilisé OCS donc je peux me tromper.

Mais ce message tend à confirmer ce que je soupçonnais. Ton client est sensé faire une validation pour accepter le certificat. Or comme il ne la fait pas,, au bout d'un certain temps, apache croit que le client a "abandonné" et le dégage.

Pour moi le problème est clairement côté client (il doit accepter ce certificat au préalable) ou éventuellement au niveau du certificat lui même (si celui-ci est signé par une autorité de confiance reconnue par le client, alors il acceptera implicitement le certificat).

Et c'est ce qui est expliqué ici :
http://wiki.ocsinventory-ng.org/index.php/Documentation:WindowsAgent/fr#Installer_manuellement_l.27agent_OCS_Inventory_NG_sur_windows

(4e capture d'écran)

- soit tu désactives la validation du certificat, mais c'est un trou de sécurtié
- soit tu installes le certificat du serveur au niveau du client (donc de l'agent OCS).

Bonne chance

Bonjur,
En fait, j'ai bien laissé la case cochée, mais je pense que je vais refaire mes certificats en partant de zéro car j'ai pas mal fait de changements.
Donc je vais les effacer et les refaire.

Parfois en faisant table rase, on y voit plus clair.

Il suffit qu'accidentellement j'utilise un certificat avec une mauvaise clé, ou qu'en créant le certificat, j'ai oublié la durée de validité (et si on ne le met pas au frais, ça se périme très vite...) option "-days "

A bientôt.
Jonas.