د SSM Agent پراکسي د هغې په ریښتیني systemd خدمت کېږدئ
د agent drop-in او د metadata تېرېدل وکاروئ، بیا د هغې اړیکه د Image Builder برخې له خپل curl غوښتنې څخه جلا کړئ.
لومړی هغه لېږونکی وپېژنئ چې ناکامېږي: د SSM Agent اړیکه یا د Image Builder برخې دننه ډاونلوډ. د SSH shell له لارې صادرول روان agent نه تازه کوي.
د عادي amazon-ssm-agent systemd واحد لپاره، مستند شوی drop-in په /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"د HTTP پای ټکی کولای شي HTTPS منزلونه ولېږدوي. کله چې agent ته اجازه وي چې د خپلو عامه AWS خدمت پای ټکو لپاره عامه منځګړی وکاروي، د HTTP پراکسي لړلیک د دې URL لپاره نوماندان وړاندې کوي؛ د metadata تېرېدل وساتئ. 169.254.169.254 د instance metadata لپاره مستقیم وساتئ؛ AWS د IPv6 metadata پای ټکي لپاره [fd00:ec2::254] هم مستند کوي.
د بدلون وروسته systemd بیا بار کړئ او د agent ریښتینی واحد بیا پیل کړئ. د Ubuntu snap بسته بندي بله واحد/drop-in ځای کاروي، نو له نصب سره سمون ورکړئ.
که agent کار کوي خو د برخې curl ناکامېږي، د هغه کمانډ چاپېریال برابروئ. کوچني توري http_proxy د curl لپاره مهم دي؛ بریالۍ agent معامله د هغه ماشوم غوښتنې ننوتنې نه ثابتوي.