kalilinux/build-scripts/kali-vmकाली लिनक्स वीएम इमेज बिल्ड स्क्रिप्ट
यह कली लिनक्स वर्चुअल मशीन (VM) इमेज बनाने के लिए बिल्ड स्क्रिप्ट है।
वर्तमान में दो बिल्ड विधियाँ संभव हैं:
build.sh - सीधे अपनी मशीन से बिल्ड करेंbuild-in-container.sh - कंटेनर के भीतर से बिल्ड करें (डॉकर या पॉडमैन)किसी भी तरह से, बिल्ड वास्तव में एक वर्चुअल मशीन के भीतर होता है जिसे बिल्ड टूल debos द्वारा तुरंत बनाया जाता है। Debos अंदरूनी रूप से fakemachine का उपयोग करता है, जो बदले में QEMU/KVM पर निर्भर करता है।
सुनिश्चित करें कि git रिपॉज़िटरी स्थानीय रूप से क्लोन की गई है:
$ sudo apt install -y git
$ git clone https://gitlab.com/kalilinux/build-scripts/kali-vm.git
$ cd kali-vm/
QEMU/KVM की आवश्यकताओं के कारण, आपको kvm समूह का सदस्य होना चाहिए।
आप इस प्रकार जाँच सकते हैं:
$ # Not apart of the group
$ grep kvm /etc/group
kvm:x:104:
$
$ # In the group
$ grep kvm /etc/group
kvm:x:104:kali
यदि आपका उपयोगकर्ता नाम लौटाई गई पंक्ति में दिखाई नहीं देता है, तो इसका मतलब है कि आप समूह में नहीं हैं, और आपको स्वयं को kvm समूह में जोड़ना होगा:
$ sudo adduser $USER kvm
फिर परिवर्तन प्रभावी होने के लिए लॉग आउट करें और वापस लॉग इन करें।
यदि build.sh का उपयोग करके सीधे अपनी मशीन से बिल्ड कर रहे हैं, तो आपको debos स्थापित करना होगा:
$ sudo apt install -y 7zip debos dosfstools qemu-utils zerofree
फिर अपनी मशीन पर सीधे एक वीएम इमेज बनाने के लिए स्क्रिप्ट build.sh का उपयोग करें।
यदि आप कंटेनर के भीतर से बिल्ड करना पसंद करते हैं, तो आपको अपनी मशीन पर docker या podman में से किसी एक को स्थापित और कॉन्फ़िगर करना होगा।
फिर एक इमेज बनाने के लिए स्क्रिप्ट build-in-container.sh का उपयोग करें।
build-in-container.sh केवल build.sh के ऊपर एक रैपर है।
यह पता लगाएगा कि कौन सा OCI-अनुरूप कंटेनर इंजन उपयोग करना है, यदि कंटेनर इमेज मौजूद नहीं है तो उसे बनाने का ध्यान रखता है, और अंत में यह भीतर से बिल्ड करने के लिए कंटेनर प्रारंभ करता है।
docker के लिए आवश्यक है कि उपयोगकर्ता को डॉकर समूह में जोड़ा जाए, ठीक ऊपर KVM के साथ की तरह, या रूट खाते का उपयोग करें (जैसे $ sudo ./build-in-container.sh)।
podman का परीक्षण रूटफुल (जैसे $ sudo ./build-in-container.sh) और रूटलेस (जैसे $ ./build-in-container.sh) दोनों रूपों में किया गया है।
अपनी पसंद के अनुसार build.sh या build-in-container.sh में से किसी एक का उपयोग करें।
इस बिंदु से हम संक्षिप्तता के लिए build.sh का उपयोग करेंगे।
हमेशा की तरह, सबसे अच्छा प्रारंभिक बिंदु उपयोग संदेश है:
$ ./build.sh -h
Usage: build.sh <options> [-- <debos options>]
Build a Kali Linux VM image
Build options:
-a ARCH Build an image for this architecture, default: amd64
Supported values: amd64
-b BRANCH Kali branch used to build the image, default: kali-rolling
Supported values: kali-dev kali-last-snapshot kali-rolling
-f FORMAT Format to export the image to, default depends on the VARIANT
Supported values: hyperv ova ovf qemu raw vagrant virtualbox vmware
-k Keep raw disk image and other intermediary build artifacts
-m MIRROR Mirror used to build the image, default: http://http.kali.org/kali
-r ROOTFS rootfs to use to build the image, default: none
-s SIZE Size of the disk image in GB, default: 86
-v VARIANT Variant of image to build (see below for details), default: generic
Supported values: generic hyperv qemu rootfs virtualbox vmware
-x VERSION What to name the image release as, default: rolling
-z Zip images and metadata files after the build
Customization options:
-D DESKTOP Desktop environment installed in the image, default: xfce
Supported values: e17 gnome i3 kde lxde mate xfce none
-H HOSTNAME Set system host name, default: kali
-K KEYBOARD Set keyboard layout, default: us
Refer to the README.md for more details
-L LOCALE Set locale, default: en_US.UTF-8
-P PACKAGES Install extra packages (comma/space separated list)
-T TOOLSET The selection of tools to include in the image, default: default
Supported values: default everything headless large none
-U USERPASS Username and password, separated by a colon, default: kali:kali
-Z TIMEZONE Set timezone, default: America/New_York
The different variants of images are:
generic Image with all virtualization support pre-installed, default format: raw
hyperv Image pre-configured for Hyper-V "Enhanced Session Mode", default format: hyperv
qemu Image with QEMU and SPICE guest agents pre-installed, default format: qemu
rootfs Not an image, a root filesystem (no bootloader/kernel), packed in a .tar.gz
virtualbox Image with VirtualBox guest utilities pre-installed, default format: virtualbox
vmware Image with Open VM Tools pre-installed, default format: vmware
The different formats are:
hyperv VHDX disk image, powershell install scripts
ova streamOptimized VMDK disk image, OVF metadata file, packed in a OVA archive
ovf monolithicSparse VMDK disk image, OVF metadata file
qemu QCOW2 disk image, no metadata
raw sparse disk image, no metadata
virtualbox VDI disk image, .vbox metadata file
vmware 2GbMaxExtentSparse VMDK disk image, VMX metadata file
Supported environment variables:
http_proxy HTTP proxy URL, refer to the README.md for more details
Most useful debos options:
--artifactdir DIR Set artifact directory, default: images
--memory, -m SIZE Limit amount of memory to build VM in GB, default: 4G
--scratchsize SIZE Limit amount of HDD to build VM in GB, default: 45G
--debug-shell Get a shell on the VM
--help, -h See the complete list of options for debos
Refer to the README.md for examples
डिफ़ॉल्ट विकल्प AMD64 आर्किटेक्चर के लिए Kali rolling इमेज, डिफ़ॉल्ट डेस्कटॉप और डिफ़ॉल्ट टूलसेट बनाएंगे।
यह एक रॉ डिस्क इमेज है, अर्थात डिस्क की एक सादा बाइनरी इमेज (जिसे QEMU के साथ प्रारंभ किया जा सकता है)।
उदाहरण:
$ ./build.sh
VMware के लिए अनुकूलित कली लिनक्स इमेज बनाने के लिए। इसका मतलब है कि इसमें Open VM Tools पहले से स्थापित आता है, और उत्पादित इमेज VMware में "जैसी है" आयात करने के लिए तैयार है।
इसके अलावा, हम इसे कली के अंतिम स्थिर रिलीज़ से बनाने जा रहे हैं, और हम सामान्य डिफ़ॉल्ट Xfce के बजाय GNOME को डेस्कटॉप वातावरण के रूप में उपयोग करेंगे:
./build.sh -v vmware -b kali-last-snapshot -D gnome
VirtualBox के लिए डिज़ाइन की गई कली लिनक्स इमेज बनाने के लिए। इसमें VirtualBox गेस्ट उपयोगिताएँ पहले से स्थापित आती हैं, और इमेज को VirtualBox में "जैसी है" आयात किया जा सकता है।
इसके अलावा, हमें 150 GB की वर्चुअल डिस्क चाहिए, और हम "everything" टूल चयन स्थापित करेंगे:
./build.sh -v virtualbox -s 150 -S everything
एक हल्की कली इमेज बनाने के लिए, जिसमें कोई डेस्कटॉप वातावरण और कोई डिफ़ॉल्ट टूलसेट नहीं है। यह एक जेनेरिक इमेज है, इसमें बाज़ार में उपलब्ध अधिकांश वीएम इंजनों के लिए समर्थन आता है। हम इसे OVA प्रारूप में निर्यात करेंगे, जो VMware और VirtualBox दोनों के लिए उपयुक्त है।
आप -P विकल्प के साथ अतिरिक्त पैकेज स्थापित कर सकते हैं।
या तो विकल्प का कई बार उपयोग करें (जैसे -P pkg1 -P pkg2 ...), या अल्पविराम/स्थान से अलग किया गया मान दें (जैसे -P "pkg1,pkg2, pkg3 pkg4"), या दोनों का मिश्रण करें।
आइए पैकेज metasploit-framework भी स्थापित करें:
./build.sh -v generic -f ova -D headless -P metasploit-framework
कई इमेज की श्रृंखला बनाते समय, बिल्ड को दो भागों में विभाजित करना अधिक सुविधाजनक (और तेज़) हो सकता है: पहले, एक rootfs बनाएं, और फिर इस rootfs को प्रारंभिक बिंदु के रूप में पुनः उपयोग करके इमेज बनाएं।
नीचे दिए गए उदाहरण में, हमने पहले एक kali-rolling rootfs बनाया, और फिर हम Vagrant इमेज की एक श्रृंखला बनाते हैं:
./build.sh -b kali-rolling -v rootfs
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v hyperv
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v qemu
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v virtualbox
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v vmware
keyboard settings सेट करने के लिए, -K विकल्प का उपयोग करें।
सेटिंग का रूप <layouts>/<models>/<variants>/<options> है। प्रत्येक सेटिंग को छोड़ा जा सकता है (उस स्थिति में डिफ़ॉल्ट उपयोग किया जाता है), या अल्पविराम से अलग किए गए कई मान हो सकते हैं। सबसे सरल मामले में, आप केवल कीबोर्ड लेआउट बदलना चाह सकते हैं, इसलिए आप US कीबोर्ड लेआउट के लिए us सेट करेंगे, जर्मन कीबोर्ड लेआउट के लिए de, और इसी तरह। लंबी व्याख्याएँ और उदाहरण keyboard(5) मैन पेज में पाए जा सकते हैं।
समर्थित मूल्यों की सूची के लिए, आप फ़ाइल /usr/share/X11/xkb/rules/xorg.lst देख सकते हैं (जो Debian और Debian-जैसे सिस्टम पर पैकेज xkb-data द्वारा प्रदान की जाती है)। इस फ़ाइल में विभिन्न अनुभाग हैं (! layout, ! model, !variant और !option) जो प्रत्येक सेटिंग के लिए संभावित मान सूचीबद्ध करते हैं।
आप cat /etc/default/keyboard के साथ अपने सिस्टम पर क्या कॉन्फ़िगर किया गया है, यह भी जाँच सकते हैं।
होस्ट सिस्टम से मेल खाने के लिए -K same का शॉर्टकट भी है (अर्थात /etc/default/keyboard फ़ाइल में क्या सेट है)।
locale सेट करने के लिए, -L विकल्प का उपयोग करें।
/usr/share/i18n/SUPPORTED के पहले कॉलम में एक मान चुनें, या grep -v ^# /etc/locale.gen के साथ जाँचें कि आपके सिस्टम पर क्या कॉन्फ़िगर किया गया है, या बस echo $LANG करें।
होस्ट सिस्टम से मेल खाने के लिए -L same का शॉर्टकट भी है।
timezone सेट करने के लिए, -Z विकल्प का उपयोग करें।
/usr/share/zoneinfo में देखें और एक निर्देशिका और एक उप-निर्देशिका चुनें।
संदेह होने पर, मार्गदर्शन के लिए tzselect चलाएँ, या realpath /etc/localtime के साथ अपने सिस्टम पर क्या कॉन्फ़िगर किया गया है, देखें।
होस्ट सिस्टम से मेल खाने के लिए -Z same का शॉर्टकट भी है।
अविशेषाधिकार प्राप्त उपयोगकर्ता के लिए नाम और पासवर्ड सेट करने के लिए, -U विकल्प का उपयोग करें।
मान एक एकल स्ट्रिंग है और उपयोगकर्ता नाम को पासवर्ड से अलग करने के लिए : का उपयोग किया जाता है।
यहाँ हम एक कली इमेज बनाएंगे, और इसे होस्ट सिस्टम की नकल करने के लिए कॉन्फ़िगर करेंगे: समान locale और समान timezone और समान उपयोगकर्ता नाम (password पासवर्ड के साथ):
./build.sh -K same -L same -Z same -U $USER:password
इस पर निर्भर करते हुए कि आप कली इमेज को किस वीएम इंजन में चलाना चाहते हैं, इमेज के विभिन्न वेरिएंट बनाए जा सकते हैं। VARIANT मुख्य रूप से परिभाषित करता है कि किसी विशेष वीएम इंजन के लिए समर्थन जोड़ने हेतु इमेज में कौन सा अतिरिक्त पैकेज स्थापित किया जाता है। फिर FORMAT परिभाषित करता है कि वर्चुअल डिस्क के लिए क्या प्रारूप है, और कौन सी अतिरिक्त मेटाडेटा फ़ाइलें बनानी हैं।
यदि सेट नहीं है, तो प्रारूप (विकल्प -f) वेरिएंट (विकल्प -v) के अनुसार स्वचालित रूप से सेट हो जाता है।
वेरिएंट और प्रारूप का हर संयोजन उचित नहीं होता, इसलिए नीचे दी गई तालिका सबसे सामान्य संयोजनों को सारांशित करने का प्रयास करती है।
| variant | format | disk format | metadata | pack |
|---|---|---|---|---|
| generic | raw | raw (sparse file) | none | |
| generic | ova | streamOptimized VMDK | OVF | OVA |
| generic | ovf | monolithicSparse VMDK | OVF | |
| qemu | qemu | QCOW2 | none | |
| virtualbox | virtualbox | VDI | VBOX | |
| vmware | vmware | 2GbMaxExtentSparse VMDK | VMX |
generic इमेज QEMU, VirtualBox और VMware के लिए वर्चुअलाइज़ेशन समर्थन पैकेज के साथ पहले से स्थापित आती हैं, इसलिए नाम "generic" है।
जबकि अन्य इमेज, जो किसी विशिष्ट वीएम इंजन को लक्षित करती हैं, केवल उस विशेष वर्चुअलाइज़ेशन इंजन के लिए समर्थन के साथ आती हैं।
केवल ova प्रारूप एक कंटेनर परिभाषित करता है: बिल्ड का परिणाम एक .ova फ़ाइल है, जो केवल एक tar संग्रह है।
अन्य प्रारूपों के लिए, बिल्ड अलग-अलग फ़ाइलें उत्पन्न करता है।
उन्हें -z विकल्प के साथ एक 7z संग्रह में एक साथ बंडल किया जा सकता है।
एक rootfs प्रकार भी है: यह एक इमेज नहीं है।
यह केवल एक कली लिनक्स रूट फाइलसिस्टम ट्री है, जिसमें कर्नेल और बूटलोडर नहीं होते, और .tar.gz संग्रह में पैक किया जाता है।
मुख्य उपयोग-मामला इसे OS इमेज बनाने के लिए इनपुट के रूप में पुनः उपयोग करना है, और यह बिल्ड सिस्टम के बाहर उपयोग के लिए अभिप्रेत नहीं है।
OS इमेज बनाते समय, सभी पैकेजों को बार-बार इंटरनेट से डाउनलोड करने से बचने के लिए एक कैशिंग तंत्र होना उपयोगी है।
इस प्रयोजन हेतु, बिल्ड स्क्रिप्ट स्थानीय होस्ट पर चल रहे ज्ञात कैशिंग प्रॉक्सी का पता लगाने का प्रयास करती है। यह पहले स्थानीय APT कॉन्फ़िगरेशन Acquire::http::Proxy का संदर्भ लेती है। यदि सेट नहीं है, तो यह जाँच करके कि क्या कोई सेवा उनके डिफ़ॉल्ट पोर्ट पर सुन रही है, apt-cacher-ng और squid-deb-proxy का पता लगाने का प्रयास करती है। यह तंत्र approx (एक प्रसिद्ध APT कैशिंग प्रॉक्सी) के लिए काम नहीं करता, क्योंकि यह मांग पर स्वचालित रूप से प्रारंभ होता है।
इस पहचान को ओवरराइड करने के लिए, आप स्वयं पर्यावरण चर http_proxy निर्यात कर सकते हैं।
हालाँकि, आपको याद रखना चाहिए कि बिल्ड एक QEMU वर्चुअल मशीन के भीतर होता है, इसलिए बिल्ड वातावरण में localhost वीएम को संदर्भित करता है, होस्ट को नहीं।
यदि आप वीएम से होस्ट तक पहुँचना चाहते हैं, तो आप शायद http://10.0.2.2 का उपयोग करना चाहेंगे।
उदाहरण के लिए, यदि आप अपनी मशीन पर पोर्ट 9876 पर चल रहे प्रॉक्सी का उपयोग करना चाहते हैं, तो export http_proxy=http://10.0.2.2:9876 का उपयोग करें।
यदि आप सुनिश्चित करना चाहते हैं कि कोई प्रॉक्सी उपयोग न हो, तो export http_proxy= का उपयोग करें।
अधिक विवरण के लिए https://github.com/go-debos/debos#environment-variables भी देखें।
वैकल्पिक रूप से, आप एक स्थानीय मिरर स्थापित कर सकते हैं।
बिल्ड को दो चरणों में विभाजित करना संभव है।
आप पहले ./build.sh -v rootfs के साथ एक rootfs बना सकते हैं, और फिर इस rootfs के आधार पर ./build.sh -r ROOTFS_NAME.tar.gz के साथ एक इमेज बना सकते हैं।
यह उचित है यदि आप उदाहरण के लिए कई इमेज प्रकार बनाने की योजना बनाते हैं।
जब स्क्रैच क्षेत्र भर जाता है (अर्थात --scratchsize मान बहुत कम है), तो बिल्ड इस प्रकार के त्रुटि संदेशों के साथ विफल हो सकता है:
[...]: failed to write (No space left on device)
[...]: Cannot write: No space left on device
समाधान: --scratchsize का मान बढ़ाएँ।
आप विशेष वर्ण -- के बाद debos को तर्क पास कर सकते हैं, इसलिए यदि आपको उदाहरण के लिए 50G चाहिए, तो आप ./build.sh [...] -- --scratchsize=50G कर सकते हैं।
बिल्ड विफलताओं को डीबग करते समय, उस वीएम के भीतर शेल में पहुँचाया जाना सुविधाजनक होता है जहाँ बिल्ड होता है।
यह debos को --debug-shell विकल्प देकर संभव है: ./build.sh [...] -- --debug-shell।
यह एक ज्ञात समस्या है, समाधान के लिए https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132 देखें।