Metu la prokurilon de SSM Agent sur ĝian realan systemd-servon
Uzu la drop-in de la agento kaj la metadata-preteriron, poste distingi ĝian konektecon de la propra curl-peto de Image Builder-komponento.
Unue identigu la malsukcesantan sendanton: la komunikado de SSM Agent aŭ elŝuto ene de la Image Builder-komponento. Eksporto per SSH-ŝelo ne ĝisdatigas la kurantan agenton.
Por la ordinara amazon-ssm-agent systemd-unuo, kunfandu la dokumentitan drop-in ĉe /etc/systemd/system/amazon-ssm-agent.service.d/override.conf:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"La HTTP-finpunkto povas porti HTTPS-celojn. Kiam la agento rajtas uzi publikan peranton por siaj publikaj AWS-servaj finpunktoj, la HTTP-prokurila listo provizas kandidatojn por tiuj URL-oj; konservu la metadata-preteriron. Tenu 169.254.169.254 rekte por la metadata de la instanco; AWS ankaŭ dokumentas [fd00:ec2::254] por la IPv6-metadata finpunkto.
Reŝargu systemd kaj restartigu la realan agent-unuon post la ŝanĝo. La Ubuntu snap-pakaĵo uzas alian lokon por unuo/drop-in, do agordu laŭ la instalado.
Se la agento funkcias sed la curl de la komponento malsukcesas, provizu la medion de tiu komando. Minusklaj http_proxy gravas por curl; sukcesa agent-transakcio ne pruvas tiujn enigojn de la infana peto.