Կարգավորման ֆայլը կարող է հաջողությամբ վերլուծվել և այնուամենայնիվ չկարգավորել պրոքսին։ APT-ն ընդունում է անվանված ընտրանքների ծառ. այն չի համարում յուրաքանչյուր հավանական ճյուղ իր HTTP տրանսպորտի հրահանգ։

HTTP ուղու համար APT-ի պրոքսի կարգավորումը հետևյալն է.

Acquire::http::Proxy "http://proxy.example.net:8080/";

Օգտագործեք ձեր ծառայության HTTP վերջնակետը կամ HTTP պրոքսիների ցանկը, երբ հանրային պահոցների հասանելիությունը կարող է օգտագործել հանրային պրոքսիներ։ Նույն կարգավորումը լրացուցիչ շրջանակում փաթաթելը փոխում է դրա անվանումը.

APT {
    Acquire {
        http {
            Proxy "http://proxy.example.net:8080/";
        };
    };
};

Դա արժեքը տեղադրում է APT::Acquire::http::Proxy հասցեում։ Սա Acquire::http::Proxy-ի այլ ուղղագրություն չէ։ HTTP ձեռքբերման մեթոդը փնտրում է վերջինը։

Խնդրեք ճշգրիտ արժեքը

apt-config shell HTTP_PROXY_VALUE Acquire::http::Proxy
apt-config shell NESTED_VALUE APT::Acquire::http::Proxy

Սրանք միայն ընթերցման կարգավորման ստուգումներ են։ Արդյունքը կարող է բացահայտել օգտատիրոջ տեղեկություններ, եթե URI-ն դրանք պարունակում է, ուստի հավատարմագրերը հեռու պահեք համօգտագործվող պատճեններից։ Համեմատեք նույն կարգավորման ֆայլերը, ընտրանքները և հաշվի համատեքստը, որոնք գործարկում են ձախողված փաթեթի գործողությունը։

Ճիշտ ուղու վրա բացակայող արժեքը բացատրում է, թե ինչու վավեր տեսք ունեցող ֆայլը չընտրեց վերջնակետը։ Այն դեռ չի ասում՝ արդյոք այդ վերջնակետը հասանելի է։

Ստուգեք կետադրությունը ճիշտ շերտում։ Անվանումները օգտագործում են կրկնակի երկու կետերի բաժանիչներ. սովորական արժեքների վերագրումները պահանջում են չակերտներ և վերջում՝ ստորակետ։ APT ընտրանքների անվանումներում մեծատառ-փոքրատառը նշանակություն չունի, ուստի proxy-ը Proxy-ով փոխարինելը լրացուցիչ շրջանակի ուղղում չէ։ URI տողի ներսում ստորակետը տվյալ է, ոչ թե հայտարարության ավարտ։

Ուղղեք հայտարարությունը, այլ ոչ թե դրա շուրջ ավելացրեք արտահանումներ։ Երբ APT-ը հաղորդի նախատեսված կարգավորումը, կապի մերժումը, 407-ը կամ վկայագրի սխալը պատկանում են ավելի ուշ փուլին։

Առնչվող հոդվածներ