debootstrap की प्रॉक्सी सेटिंग्स होस्ट डाउनलोडर की हैं
debootstrap जिस होस्ट-साइड डाउनलोडर का उपयोग करता है, उसे उसके द्वारा बनाए गए रूट फ़ाइलसिस्टम के भीतर APT से अलग कॉन्फ़िगर करें।
debootstrap के Wget-आधारित डाउनलोड पथ के लिए, प्रॉक्सी को होस्ट-साइड wgetprogress परिवेश में दें:
sudo env \
http_proxy=http://proxy.example.net:8080 \
https_proxy=http://proxy.example.net:8080 \
debootstrap stable /srv/chroot/debian https://deb.debian.org/debian
परिनियोजन के लिए सूट, लक्ष्य निर्देशिका और मिरर चुनें। असाइनमेंट sudo के बाद होते हैं, इसलिए विशेषाधिकार प्राप्त कमांड उन्हें कॉलर के निर्यात किए गए वेरिएबल के sudo नीति से बचने पर भरोसा किए बिना प्राप्त करता है। दोनों गंतव्य योजनाएँ इस सामान्य HTTP प्रॉक्सी का उपयोग कर सकती हैं। प्रॉक्सी प्रमाणीकरण के बिना अनुमत सार्वजनिक-मिरर डाउनलोड के लिए, HTTP प्रॉक्सी सूची उन परिवेश मानों के लिए संभावित HTTP एंडपॉइंट प्रदान करती है।
पहले डाउनलोड नई Debian प्रणाली के उपयोग योग्य होने से पहले मेटाडेटा और पैकेज प्राप्त करते हैं। उस भावी रूट के भीतर APT प्रॉक्सी फ़ाइल पहले के होस्ट डाउनलोडर को कॉन्फ़िगर नहीं कर सकती।
प्रमाणीकरण के लिए, Wget द्वारा समर्थित प्रॉक्सी क्रेडेंशियल का उपयोग करें। URI उपयोगकर्ता जानकारी को आरक्षित वर्णों के एन्कोडिंग की आवश्यकता होती है; स्टार्टअप कॉन्फ़िगरेशन proxy_user और proxy_password भी प्रदान करता है। विशेषाधिकार प्राप्त खाते के इनपुट इंटरैक्टिव उपयोगकर्ता के .wgetrc से भिन्न हो सकते हैं, इसलिए पहचानें कि वास्तव में कौन-सी फ़ाइल पढ़ी जाती है और उसका दायरा जानबूझकर रखें।
अगले चरणों की अलग से योजना बनाएँ। दूसरे चरण का bootstrap, विशेषकर विदेशी आर्किटेक्चर के लिए, किसी अन्य परिवेश में चल सकता है। बाद में पूर्ण प्रणाली के भीतर APT उस प्रणाली का कॉन्फ़िगरेशन पढ़ता है। होस्ट कमांड दोनों में से किसी को भी स्थायी रूप से कॉन्फ़िगर नहीं करता।