שטעלט דעם SSM Agent ס פּראָקסי אויף זיין פּראַקטישן systemd סערוויס
ניצט דעם agent ס drop-in און דעם metadata אַריבערפֿיר, דערנאָך פֿונאַנדערשיידט זיין פֿאַרבינדונג פֿון דער Image Builder קאָמפּאָנענט ס אייגענער curl בקשה.
ערשט דערקענט דעם דורכגעפֿאַלענעם שיקער: די SSM Agent קאָמוניקאַציע אָדער אַ אַראָפּלאָדונג אין דער Image Builder קאָמפּאָנענט. אַן עקספּאָרט דורך אַן SSH שעל דערהײַנטיקט נישט דעם לויפֿנדיקן 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 פּראָקסי ליסטע קאַנדידאַטן פֿאַר די URLen; האַלט דעם metadata אַריבערפֿיר. לאָזט 169.254.169.254 גלייַך פֿאַר instance metadata; AWS דאָקומענטירט אויך [fd00:ec2::254] פֿאַר דעם IPv6 metadata ענדפּונקט.
לאָדט איבער systemd און סטאַרטעט אָן די פּראַקטישע agent אַנייט נאָך דער ענדערונג. די Ubuntu snap פּאַקאַזשירונג ניצט אַן אַנדער אָרט פֿאַר אַנייט/drop-in, דעריבער פּאַסט זיך צו צו דער אינסטאַלאַציע.
אויב דער agent אַרבעט אָבער דער curl פֿון דער קאָמפּאָנענט פֿאַלט, פֿאַרזאָרגט די סבֿיבה פֿון יענער קאָמאַנדע. קליינע אותיות http_proxy זענען וויכטיק פֿאַר curl; אַ דערפֿאָלגרייכע agent טראַנזאַקציע באַשטעטיקט נישט יענע אַרייַנגאַנגען פֿון דער קינד-בקשה.