Ansible SOCKS-prokuro: kiu maŝino posedas localhost?
Trovu la procezon, kiu faras peton al la Ansible-API, antaŭ ol direkti ĝin al SSH SOCKS-auskultanto sur loopback.
Tasko uzanta socks5h://127.0.0.1:65432 devas funkcii en la reta medio, kie tiu auskultanto ekzistas. Tunelo funkcianta de la regilo ne igas ĝin atingebla ĉe la loopback-adreso de administrata gastigo — aŭ ene de plenumuja ujo.
Por la malsukcesa tasko, konstatigu kvar faktojn:
- La gastigo aŭ ujo, kiu plenumas la retan peton.
- Ĝia efektiva uzanto kaj Python-interpretilo.
- La HTTP-biblioteko aŭ SDK de la modulo.
- La adreso, kie tiu procezo povas atingi la SOCKS-auskultanton.
La inventara celo de la teatraĵo sola ne respondas la unuan demandon. Moduloj uzas sian agordan konekton, delegado povas movi plenumadon, kaj loka konekto povas teni la laboron ĉe la regilo. Serĉoj ĉe la regila flanko okazas tute ekster la fora modulo.
Por OpenStack-bilda tasko, ekzamenu la postulojn de la instalita kolekto openstack.cloud kaj ĝian OpenStack SDK-medion. Sukceso de curl aliloke ne pruvas la SOCKS-kapablojn aŭ dependecojn de tiu SDK.
Se la API-operacio estas destinita funkcii loke, faru tiun plenum-elekton eksplicita kaj donu la agordon tie. Se ĝi funkcias fore, elektu prokurilon atingeblan el tiu kunteksto. La environment: de Ansible-tasko efikas al la taska procezo; ĝi ne reagordas ĉiun serĉon aŭ kromprogramon, kaj la SDK ankoraŭ devas subteni la skemon en tiu Python-medio.
Tenu du vojojn aparte: SSH aŭ ProxyJump portas Ansible al gastigo, dum la HTTP-kliento de la modulo iras de sia plenum-kunteksto al la API. Funkcianta unua vojo ne agordas la duan. Elmeti auskultanton ekzistantan nur ĉe la regilo por solvi atingeblon ankaŭ ŝanĝas, kiu povas aliri ĝin, do ĝi estas deploja elekto, ne adresa korekto.