systemd சேவைக்கு உங்கள் ஷெல்லின் புராக்ஸி அமைப்புகள் கிடைக்காதது ஏன்
புராக்ஸி அமைப்பை systemd சேவையின் உண்மையான சூழலில் வையுங்கள்; முனையத்தில் export செய்வது இயங்கிக்கொண்டிருக்கும் செயல்முறையை மறுகட்டமைக்காது.
முனையத்தில் இன்னொரு மாறியை export செய்வதற்குப் பதிலாகத் தோல்வியடையும் சேவையை ஆராயுங்கள். systemctl cat example.service அதன் யூனிட்டையும் கூடுதல் அமைப்புகளையும் காட்டும்; EnvironmentFile, வேறு மேலெழுதும் அமைப்பு அல்லது பயன்பாட்டின் சொந்த புராக்ஸி அமைப்புகள் உள்ளனவா என்று பாருங்கள். உள்நுழைவு விவரங்கள் உள்ள வெளியீட்டை உள்ளூரிலேயே படியுங்கள்.
பயன்பாடு HTTP புராக்ஸி சூழல் மாறிகளைப் பயன்படுத்தினால், சேவையின் கூடுதல் அமைப்பில் இவற்றை வழங்கலாம்:
[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"ஆவண உதாரணத்தின் முகவரியை மாற்றிப் பயன்பாடு ஆதரிக்கும் மாறிப் பெயர்களைப் பயன்படுத்துங்கள். பொது HTTP புராக்ஸிகளைப் பயன்படுத்த அனுமதிக்கப்பட்ட சேவைக்கான முகவரிகளை HTTP புராக்ஸி பட்டியலில் காணலாம். சொந்த அமைப்பைக் கொண்ட கிளையன்ட் இந்த உள்ளீடுகளைப் புறக்கணிக்கலாம். இதுவே வேண்டிய கணினிச் சேவையா என்றும் உறுதிப்படுத்துங்கள்: பயனர் சேவைக்கு வேறு மேலாளரும் சூழலும் இருக்கும்; ஒரேபோன்ற பெயருள்ள கணினி யூனிட்டை மாற்றுவது அதைச் சரிசெய்யாது.
சரியான யூனிட் அல்லது கூடுதல் அமைப்பைத் திருத்திய பிறகு வரையறைகளை மீண்டும் ஏற்றி, அதன் பணியை இடைநிறுத்தக்கூடிய நேரத்தில் அந்தச் சேவையை மறுதொடக்கம் செய்யுங்கள்:
sudo systemctl daemon-reload
sudo systemctl restart example.servicedaemon-reload மட்டும் இயங்கும் செயல்முறையின் சூழலை மாற்றாது. மறுதொடக்கமே புதிய செயல்முறையைத் தொடங்குகிறது; ஷெல்லில் export செய்வது அந்த ஷெல்லையும் அது பின்னர் தொடங்கும் சேய் செயல்முறைகளையும் மட்டுமே பாதிக்கும்.
சேவைக்கு எதிர்பார்த்த URL கிடைத்ததும் அதன் உண்மையான பிழையைத் தொடருங்கள். அதன் கணக்கிற்கு CA கோப்பை அணுகும் உரிமை இல்லாமல் இருக்கலாம், அதன் வலைப்பின்னல் பெயர்வெளியால் லிசனரை அடைய முடியாமல் இருக்கலாம் அல்லது புராக்ஸி கோரிக்கையை மறுக்கலாம். இவை அடுத்தகட்டச் சோதனைகள்; தொடர்பில்லாத ஷெல் சுயவிவரங்களைத் தொடர்ந்து திருத்துவதற்கான காரணங்கள் அல்ல.