SSM Agent-ന്റെ proxy അതിന്റെ യഥാർത്ഥ systemd സേവനത്തിൽ വയ്ക്കുക
ഏജന്റിന്റെ drop-in-ഉം metadata ബൈപാസും ഉപയോഗിക്കുക, തുടർന്ന് അതിന്റെ കണക്റ്റിവിറ്റി Image Builder ഘടകത്തിന്റെ സ്വന്തം curl അഭ്യർത്ഥനയിൽ നിന്ന് വേർതിരിക്കുക.
ആദ്യം പരാജയപ്പെടുന്ന അയച്ചയാളെ കണ്ടെത്തുക: SSM Agent ആശയവിനിമയമോ Image Builder ഘടകത്തിനുള്ളിലെ ഡൗൺലോഡോ. SSH ഷെൽ വഴിയുള്ള എക്സ്പോർട്ട് പ്രവർത്തിക്കുന്ന ഏജന്റിനെ അപ്ഡേറ്റ് ചെയ്യുന്നില്ല.
സാധാരണ 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 ലക്ഷ്യങ്ങൾ വഹിക്കാം. ഏജന്റിന് അതിന്റെ പൊതു AWS സേവന എൻഡ്പോയിന്റുകൾക്കായി ഒരു പൊതു മധ്യസ്ഥൻ ഉപയോഗിക്കാൻ അനുവാദമുള്ളപ്പോൾ, HTTP proxy പട്ടിക ഈ URL-കൾക്ക് സ്ഥാനാർത്ഥികൾ നൽകുന്നു; metadata ബൈപാസ് നിലനിർത്തുക. instance metadata-യ്ക്ക് 169.254.169.254 നേരിട്ട് സൂക്ഷിക്കുക; IPv6 metadata എൻഡ്പോയിന്റിന് AWS [fd00:ec2::254]-ഉം രേഖപ്പെടുത്തുന്നു.
മാറ്റത്തിന് ശേഷം systemd വീണ്ടും ലോഡ് ചെയ്ത് യഥാർത്ഥ ഏജന്റ് യൂണിറ്റ് പുനരാരംഭിക്കുക. Ubuntu snap പാക്കേജിംഗ് മറ്റൊരു യൂണിറ്റ്/drop-in സ്ഥാനം ഉപയോഗിക്കുന്നു, അതിനാൽ ഇൻസ്റ്റാളേഷനുമായി പൊരുത്തപ്പെടുക.
ഏജന്റ് പ്രവർത്തിക്കുന്നു എന്നാൽ ഘടകത്തിന്റെ curl പരാജയപ്പെടുന്നു എങ്കിൽ, ആ കമാൻഡിന്റെ പരിതസ്ഥിതി നൽകുക. ചെറിയ അക്ഷരങ്ങൾ http_proxy curl-ന് പ്രധാനമാണ്; വിജയകരമായ ഏജന്റ് ഇടപാട് ആ ചൈൽഡ്-അഭ്യർത്ഥന ഇൻപുട്ടുകൾ തെളിയിക്കുന്നില്ല.