Jarri SSM Agent-en proxy-a bere benetako systemd zerbitzuan
Erabili agentaren drop-in-a eta metadata saihesteko bidea, eta gero bere konektibitatea bereizi Image Builder osagaiaren curl eskaeratik.
Lehenik, identifikatu huts egiten duen bidaltzailea: SSM Agent-en komunikazioa edo Image Builder osagaiaren barneko deskarga bat. SSH shell bidezko esportazioak ez du martxan dagoen agenta eguneratzen.
amazon-ssm-agent systemd unitate arruntarentzat, batu /etc/systemd/system/amazon-ssm-agent.service.d/override.conf-n dokumentatutako drop-in-a:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"HTTP amaierako puntuak HTTPS helmugak eraman ditzake. Agenteak AWS zerbitzu publikoen amaierako puntuetarako bitartekari publiko bat erabil dezakeenean, HTTP proxy zerrendak hautagaiak ematen ditu URL horietarako; mantendu metadata saihesteko bidea. Eutsi 169.254.169.254 zuzenean instantziaren metadatuetarako; AWSek [fd00:ec2::254] ere dokumentatzen du IPv6 metadatuen amaierako punturako.
Birkargatu systemd eta berrabiarazi agentaren benetako unitatea aldaketaren ondoren. Ubuntu snap paketatzeak beste unitate/drop-in kokapen bat erabiltzen du, beraz egokitu instalazioari.
Agenteak funtzionatzen badu baina osagaiaren curl-ek huts egiten badu, eman komando horren ingurunea. http_proxy letra xeheak garrantzitsuak dira curl-entzat; agentearen transakzio arrakastatsuak ez ditu haur-eskaeraren sarrera horiek frogatzen.