OCS Inventory - PB télédéploiement
Fermé
jivef
Messages postés
927
Date d'inscription
mercredi 11 août 2004
Statut
Membre
Dernière intervention
12 novembre 2020
-
Modifié par jivef le 20/11/2011 à 22:19
jivef Messages postés 927 Date d'inscription mercredi 11 août 2004 Statut Membre Dernière intervention 12 novembre 2020 - 29 nov. 2011 à 17:48
jivef Messages postés 927 Date d'inscription mercredi 11 août 2004 Statut Membre Dernière intervention 12 novembre 2020 - 29 nov. 2011 à 17:48
A voir également:
- OCS Inventory - PB télédéploiement
- Ocs inventory ng - Télécharger - Outils professionnels
- Inflow inventory - Télécharger - Comptabilité & Facturation
- Total network inventory - Télécharger - Divers Réseau & Wi-Fi
- Network inventory advisor - Télécharger - Divers Réseau & Wi-Fi
- Ciné+ ocs - Accueil - Streaming
6 réponses
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
21 nov. 2011 à 20:43
21 nov. 2011 à 20:43
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 !).
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 :
Pour ton fichier manquant, il te manque le paquet qui le fournit. Pour trouver quel paquet le fourni, tu peux utiliser apt-file
Dans le cas présent cette commande donc :
On installe le paquet correspondant :
Bonne chance
(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
jivef
Messages postés
927
Date d'inscription
mercredi 11 août 2004
Statut
Membre
Dernière intervention
12 novembre 2020
306
Modifié par jivef le 22/11/2011 à 18:58
Modifié par jivef le 22/11/2011 à 18:58
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 :
A bientux.
Une idée reçue est souvent une idée morte.
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.
jivef
Messages postés
927
Date d'inscription
mercredi 11 août 2004
Statut
Membre
Dernière intervention
12 novembre 2020
306
22 nov. 2011 à 19:06
22 nov. 2011 à 19:06
Par contre, le nom favicon.ico m'a rappelé un souvenir vaguement vu dans /var/log/apache2/error mais auquel je n'avais pas pr?té attention :
[Mon Nov 21 06:41:22 2011] [error] [client 192.168.1.3] File does not exist: /var/www/favicon.ico
[Mon Nov 21 06:41:22 2011] [error] [client 192.168.1.3] File does not exist: /var/www/favicon.ico
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
22 nov. 2011 à 22:11
22 nov. 2011 à 22:11
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
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
jivef
Messages postés
927
Date d'inscription
mercredi 11 août 2004
Statut
Membre
Dernière intervention
12 novembre 2020
306
27 nov. 2011 à 20:17
27 nov. 2011 à 20:17
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.
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.
jivef
Messages postés
927
Date d'inscription
mercredi 11 août 2004
Statut
Membre
Dernière intervention
12 novembre 2020
306
27 nov. 2011 à 20:40
27 nov. 2011 à 20:40
Re Bonjour,
Je ne peux plus modifier mon message précédent, donc j'en rajoute une couche autrement...
Pour info, voici mon fichier apache correspondant au site concerné.
(j'ai fait un fichier de config à part par site, ce qui me parait plus propre)
J'ai paramétré le niveau d'errorlog à info, pour en voir un peu plus, et j'ai cette trace dans mon fichier :
[Sun Nov 27 09:21:55 2011] [info] Subsequent (No.18) HTTPS request received for child 3 (server ocsweb:443)
[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)
Est-ce que ces messages te font penser à quelque chose.
Je n'ai rien trouvé de vraiment probant.
Ce sont des infos, pas des erreurs, en tout cas coté serveur.
Mais cela implique probablement une erreur coté client.
Je vais refaire mon installation avec "Agent deploy tool" pour voir.
Cela dit, je teste l'accès à l'agent depuis un navigateur qui a accepté le certificat et qui accède au site et j'ai ce message parfois qui m'inquiète un peu :
l'expression "abortive shutdown" suivie du nom de mon serveur m'inquiète.
En fait, je suis bien connecté mais j'ai ce message bizarre.
A bientux.
Jonas.
Une idée reçue est souvent une idée morte.
Je ne peux plus modifier mon message précédent, donc j'en rajoute une couche autrement...
Pour info, voici mon fichier apache correspondant au site concerné.
(j'ai fait un fichier de config à part par site, ce qui me parait plus propre)
<VirtualHost *:80>
ServerName ocsweb
Redirect / https://ocsweb
</VirtualHost>
<VirtualHost *:443>
ServerName ocsweb
DocumentRoot /usr/share/ocsinventory-server
LogLevel info
ErrorLog ${APACHE_LOG_DIR}/ocs_error.log
TransferLog ${APACHE_LOG_DIR}/ocs_transfer.log
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
SSLCertificateFile /etc/apache2/server.crt
SSLCertificateKeyFile /etc/apache2/server.key
</VirtualHost>
J'ai paramétré le niveau d'errorlog à info, pour en voir un peu plus, et j'ai cette trace dans mon fichier :
[Sun Nov 27 09:21:55 2011] [info] Subsequent (No.18) HTTPS request received for child 3 (server ocsweb:443)
[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)
Est-ce que ces messages te font penser à quelque chose.
Je n'ai rien trouvé de vraiment probant.
Ce sont des infos, pas des erreurs, en tout cas coté serveur.
Mais cela implique probablement une erreur coté client.
Je vais refaire mon installation avec "Agent deploy tool" pour voir.
Cela dit, je teste l'accès à l'agent depuis un navigateur qui a accepté le certificat et qui accède au site et j'ai ce message parfois qui m'inquiète un peu :
[Sun Nov 27 09:32:39 2011] [info] [client ::1] Connection closed to child 7 with abortive shutdown (server ocsweb:443) [Sun Nov 27 09:32:40 2011] [info] [client ::1] Connection to child 8 established (server ocsweb:443) [Sun Nov 27 09:32:40 2011] [info] Seeding PRNG with 648 bytes of entropy [Sun Nov 27 09:32:40 2011] [info] [client ::1] SSL library error 1 in handshake (server ocsweb:443) [Sun Nov 27 09:32:40 2011] [info] SSL Library Error: 336027900 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol speaking not SSL to HTTPS port!? [Sun Nov 27 09:32:40 2011] [info] [client ::1] Connection closed to child 8 with abortive shutdown (server ocsweb:443)
l'expression "abortive shutdown" suivie du nom de mon serveur m'inquiète.
En fait, je suis bien connecté mais j'ai ce message bizarre.
A bientux.
Jonas.
Une idée reçue est souvent une idée morte.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
27 nov. 2011 à 22:52
27 nov. 2011 à 22:52
[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
jivef
Messages postés
927
Date d'inscription
mercredi 11 août 2004
Statut
Membre
Dernière intervention
12 novembre 2020
306
29 nov. 2011 à 17:48
29 nov. 2011 à 17:48
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.
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.