Télédéploiment "Failed to download Metadata file"

Question

Bonjour,

Sur mon serveur OCS mon inventaire ce fait via une redirection de ports

monserver ← appareil ← monclient

Tout fonctionne très bien pour les inventaires avec mon certificat, mais lors d'une tentative de télédéploiment, j'ai cette erreur :

" ERROR *** DOWNLOAD => Failed to download Metadata file <https://IPmonserveur/download/1692195375/info> to <C:\ProgramData\OCS Inventory NG\Agent\download\1692195375\info>"

Et le client reste coincé en "NOTIFIED"

mon certificat a comme CN = FQDN apareil

Je suppose que mon problème vient du fait que quand le téléchargement en HTTPS ce fait, il pointe sur IPmonserveur alors que mon certificat utilise FQDN apareil.

Ce n'est qu'une supposition.

Contenu de access.log:

192.168.82.250 - - [21/Aug/2023:08:35:03 +0200] "POST /ocsinventory HTTP/1.1" 200 1916 "-" "OCS-NG_WINDOWS_AGENT_v2.9.2.0"

Si vous avez des idées ou des pistes de comment résoudre ce problème.

Merci d'avance pour toutes réponses.

Answer 1

J'ai trouvé la solution,

Il fallait modifier DOWNLOAD_URI_INFO dans "Configuration=>Configuration générale =>télédploiment" et mettre "https://FQDN apareil/download".

Comme ça en déploiement HTTPS mon certificat fonctionne, merci quand même jacquesh.

Answer 2

Plusieurs problèmes :

- Failed to download Metadata file <https://IPmonserveur/download/1692195375/info> : avez vous testé la même chose manuellement depuis un navigateur ? Et avez vous regardé les logs Apache ? Avez vous activé https pour Apache ?

- 'IPmonserveur' versus 'FQCN' : il FAUT configurer en utilisant TOUJOURS un nom FullyQualifiedDomainName, à la fois au niveau de l'Apache du serveur OCS et à la fois à l'installation de l'agent : cela s'appelle le bon sens !

- 'Sur mon serveur OCS mon inventaire ce fait via une redirection de ports', kesako ? Je ne comprends pas la signification ...

Je préconise d'avoir un peu de Knowledge en configuration d'Apache et en consultation de logs ...

(Perso : je n'utilise pas de certificat au niveau de l'agent (SSL=0 et HTTP=), et cela fonctionne pourtant très bien, mais il faut bien sûr avoir HTTP et HTTPS sur le serveur pour le Télédéploiement. J'utilise des 'VirtualHost' pour avoir des noms différents pour /ocsinventory et /ocsreports.)

Answer 3

1: "Failed to download Metadata file", Oui je l'ai tester dans le navigateur.

"<DOWNLOAD ID="1692195375" PRI="5" ACT="EXECUTE" DIGEST="8863437225b9f620fc726943448f9588" PROTO="HTTPS" FRAGS="4" DIGEST_ALGO="MD5" DIGEST_ENCODE="Hexa" COMMAND="msiexec /i application.msi " NOTIFY_USER="0" NOTIFY_TEXT="" NOTIFY_COUNTDOWN="" NOTIFY_CAN_ABORT="0" NOTIFY_CAN_DELAY="0" NEED_DONE_ACTION="0" NEED_DONE_ACTION_TEXT="" GARDEFOU="rien"/>"

Pour les logs, rien dans le fichier error.log ni dans acess.log. Quand je dit, rien, c'est aucune remontée d'erreur.

Quand, à l'activation de HTTPS pour Apache, le fait d'utiliser un certificat pour remonter l'inventaire devrait répondre à la question. À moins que je n'aie pas compris la question.

2: 'IPmonserveur' versus 'FQCN', je m'en suis rendu compte. Comment je peux modifier ça directement dans les fichiers ? Faut-il repartir de zéro en supprimant tout ?

3: 'Sur mon serveur OCS mon inventaire se fait via une redirection de ports', cela veut dire que l'inventaire est envoyé sur un appareil qui a une redirection de ports. Exemple: 

serveur OCS = 192.168.0.1

agent OCS = 192.168.0.2

Appareil = 192.168.0.3

192.168.0.2 envoie l'inventaire sur 192.168.0.3:200 qui avec une redirection de port l'envoie sur 192.168.0.1:443

Answer 4

1/ Failed to download : le test depuis un pc/navigateur est la base, en parallèle, on regarde 'access.log' : la requête doit générer un code '200' (et non '500' ou '400') qui signifie que le fichier est disponible. Si le PC/navigateur y arrive, l'agent doit y arriver ...

2/ Redirection : j'ai compris ce que vous écrivez mais je ne comprends pas bien l'idée ! Un reverse proxy est une bonne solution, si vous tenez à avoir une machine intermédiaire ... J'espère que vous avez testé 'à la place' d'un pc pour évaluer si l'agent est en cause ...

Perso : j'éviterais cette 'redirection'.

NB : j'utilise un reverse proxy et uniquement sur l'inventaire (/ocsinventory)

3/ fqdn : il est simple de traiter le problème de nom fqdn, avec un peu d'expérience en config certificat + Apache2. Mais il faudra revoir l'install des agents. Ca se scripte ...

Answer 5

1/ contenu de access.log:

192.168.82.250 - - [21/Aug/2023:08:35:03 +0200] "POST /ocsinventory HTTP/1.1" 200 1916 "-" "OCS-NG_WINDOWS_AGENT_v2.9.2.0"
j'ai bien un code 200. Cependant, mon inventaire remonte, mais pas de téléchargement de logiciel en télédéploiment.

2/ je comprend bien ce que tu dis, mais l'installation est comme ça et je ne cherche pas une remise en cause. Car elle DOIT être comme ça. Si j'en aie parlé, c'est parce que ça peut participer au problème. Mais je garde en tête ta solution

3/Ci ce que tu dit, c'est de changer ,Server= IP en Server= FQDN dans le fichier ocsinventory.ini c'est déjà fait.

Answer 6

Quand on initie le télé-déploiement, on DOIT (forcément) configurer DOWNLOAD_URI_FRAG et DOWNLOAD_URI_INFO aux valeurs souhaitées ... (et donc, de préférence, avec un fqdn qui peut être résolu par l'agent !). C'est tellement la base que je l'avais oublié !

(NB : l'agent qui télé-déploie ne vérifie pas le lien https avec le certificat qu'on lui a éventuellement fourni ! Entre autres, parce qu'il est possible d'avoir plusieurs serveurs de télédéploiement ... dans les très grandes configs)

Answer 7

J'ai vu à plusieurs reprises cette option mais sur des tutoriels très datés. Je ne l'avais pas trouvé sur l'interface graphique OCS alors j'ai supposé que cette option avais été retirée et toujours dispo dans les fichiers de conf du server. C'était le but initial de ma question, mais n'étant pas sûr de mon problème je l'ai exposé sans en parler.