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 का लागि महत्त्वपूर्ण छन्; सफल एजेन्ट लेनदेनले ती चाइल्ड-अनुरोध इनपुटहरू प्रमाणित गर्दैन।