SSM Agent के proxy को उसकी वास्तविक systemd सेवा पर रखें
एजेंट के drop-in और metadata बाईपास का उपयोग करें, फिर उसकी कनेक्टिविटी को Image Builder घटक के अपने curl अनुरोध से अलग पहचानें।
पहले विफल प्रेषक की पहचान करें: SSM Agent संचार या Image Builder घटक के भीतर डाउनलोड। SSH-shell निर्यात चल रहे एजेंट को अपडेट नहीं करता।
सामान्य 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 को सीधा रखें; AWS IPv6 metadata एंडपॉइंट के लिए [fd00:ec2::254] का भी दस्तावेज़न करता है।
परिवर्तन के बाद systemd पुनः लोड करें और वास्तविक एजेंट यूनिट पुनः आरंभ करें। Ubuntu snap पैकेजिंग दूसरा यूनिट/drop-in स्थान उपयोग करती है, इसलिए इंस्टॉलेशन से मेल खाएँ।
यदि एजेंट काम करता है पर घटक का curl विफल होता है, तो उस कमांड का वातावरण दें। छोटे अक्षर http_proxy curl के लिए मायने रखते हैं; सफल एजेंट लेन-देन उन चाइल्ड-अनुरोध इनपुट को सिद्ध नहीं करता।