कैसे: लाइव सीडी / ISO या वैकल्पिक Linux सिस्टम के माध्यम से एक टूट प्रणाली में Chroot

कभी-कभी, आपको एक टूटे हुए / अनबूट करने योग्य TurnKey सर्वर को बचाने की आवश्यकता हो सकती है। शायद आपके पास हार्डवेयर विफलता है, या शायद आपने अनजाने में कुछ टूटा है, या शायद आपने एक बगीचा अपडेट स्थापित किया है, जिसने कुछ चीजें टूटी है?

अक्सर इन मुद्दों को "क्रूटिंग" द्वारा एक कार्य प्रणाली (Linux) प्रणाली से टूट प्रणाली में तय किया जा सकता है, फिर मुद्दे को हल करने के लिए आवश्यक कदम उठाते हैं (ग्रब की स्थापना की जाती है, और फिर एक दूसरे को हल करने के लिए आवश्यक कदम उठाते हैं। एक कर्नेल को फिर से स्थापित करें, एक इनिट्राम्फ्स का पुनर्निर्माण करें, आदि)। जाहिर है एक टूट प्रणाली को ठीक करने के लिए कदम वास्तव में टूट गया है पर निर्भर करेगा। यदि आप निश्चित नहीं हैं, तो आप शायद एक नया धागा शुरू करने के लिए सबसे अच्छा कर रहे हैं मंच (नए धागे को शुरू करने के लिए मुफ्त वेबसाइट उपयोगकर्ता खाते की आवश्यकता होती है) ताकि हम इस मुद्दे का निदान करने में सहायता कर सकें।

इस डॉक में, मैं सिर्फ उस बिंदु तक सलाह दूंगा जहां आप चुटकुले में प्रवेश करते हैं, और किसी विशिष्ट मुद्दे को हल करने के बारे में विवरण में नहीं जाना चाहिए (हालांकि, अगर / जब मैं एक हो जाता हूं) शायद मैं कुछ सबसे आम मुद्दों के लिए डॉक पेज लिखूंगा?!

नोट: यह गाइड मानती है कि आप रूट यूज़र खाता के साथ लॉग इन हैं। यदि नहीं, तो अधिकांश (यदि सभी नहीं) तो आदेश को चुटकुले के बाहर चलाते हैं, उन्हें 'sudo' द्वारा पूर्वनिर्धारित करने की आवश्यकता हो सकती है। यदि आप एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक ही समय में एक बार फिर एक ही समय में एक बार फिर एक ही समय में एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार फिर एक बार

तो पहले; थोड़ा पृष्ठभूमि. अगर आप अभी तक सीधे में कूदना चाहते हैं chroot स्थापित करना, कृपया स्वतंत्र महसूस करें।

"chroot" क्या है?

विकिपीडिया के अनुसार, एक चुरबूत:

वर्तमान चल प्रक्रिया और उसके बच्चों के लिए स्पष्ट रूट निर्देशिका बदलता है। ऐसे प्रोग्राम जो ऐसे संशोधित वातावरण में चल रहा है, निर्दिष्ट निर्देशिका पेड़ के बाहर फ़ाइलों को नाम नहीं दे सकता (और इसलिए सामान्य रूप से एक्सेस नहीं कर सकता)।

Linux उपयोगकर्ता के रूप में, आप सामना कर सकते हैं, तो एक "मानक" chroot (क्या यह डॉक पेज कवर) कह सकते हैं, तो वहाँ भी एक "chroot जेल" है।

एक chroot जेल का उद्देश्य एक निर्देशिका पेड़ के एक निश्चित हिस्से के भीतर उपयोगकर्ता या प्रक्रिया को लॉक करना है। उदाहरण के लिए, E.g. इसके स्वयं की निर्देशिका में एक कार्यक्रम "chrooted" हो सकता है (उदाहरण के लिए पोस्टफिक्स इस तरह स्थापित किया गया है), जिसमें बाकी फ़ाइल सिस्टम तक कोई पहुंच नहीं है। या सीमित उपयोगकर्ता को अपनी होम डायरेक्टरी में "chrooted" किया जा सकता है, इसलिए वे SFTP का उपयोग कर सकते हैं, लेकिन पूरी फाइल सिस्टम ब्राउज़ नहीं कर सकते।

एक "मानक" chroot का उपयोग एक अनबूटेबल सिस्टम की जांच और संभवतः मरम्मत के लिए किया जा सकता है। यह आमतौर पर नए Linux सिस्टम बनाने के लिए भी प्रयोग किया जाता है। उदाहरण के लिए, TurnKey एक "मानक" chroot (on) का उपयोग करता है TKLDevTurnKey सर्वर बनाने के लिए। यह एक प्रकार का चतुराई है जिसे मैं यहां दस्तावेज दूँगा।

एक chroot स्थापित करना

तैयारी

यह सुनिश्चित करना कि टूटी हुई प्रणाली की फ़ाइल प्रणाली कार्य प्रणाली से सुलभ है। एक नंगे धातु स्थापित या एक VM के मामले में, ऐसा करने का सबसे आसान तरीका अक्सर लाइव सीडी / USB / ISO से बूट करना होता है। सामान्य नियम के रूप में, आमतौर पर उसी OS का उपयोग करना सबसे अच्छा होता है जैसा कि टूटी हुई प्रणाली क्या है। TurnKey के मामले में, आप उपयोग कर सकते हैं कोर (या किसी अन्य सर्वर; सिर्फ कोर सबसे छोटा है) एक ही प्रमुख संस्करण का। उदाहरण v15.0 कोर किसी भी v15.x सर्वर को ठीक करने के लिए उपयोग करने के लिए ठीक है। यदि ऐसा विकल्प नहीं है, तो Debian लाइव सिस्टम भी एक अच्छा विकल्प है। वर्स्ट केस परिदृश्य, आप किसी भी अपेक्षाकृत हाल के Linux डिस्ट्रो के साथ दूर हो सकते हैं, हालांकि एक मिलान संस्करण का TurnKey (या Debian) बेहतर है।

जो भी आप करते हैं NOT अपने टूटे हुए सिस्टम के शीर्ष पर स्थापित! यह इसे असुरक्षित बना देगा!

वैकल्पिक रूप से, आप डिस्क (भौतिक या आभासी) को दूसरे (काम) मशीन (TurnKey/Debian/etc के साथ ऊपर चल रहा है) में ले जा सकते हैं। AWS सर्वर के लिए जो अनिवार्य रूप से आपको क्या करना होगा (यानी टूटी हुई प्रणाली से प्राथमिक मात्रा को अलग करना और एक कार्य प्रणाली में फिर से संलग्न करना)।

माउंट करने के लिए सही मात्रा का पता लगाना

जब आप एक कार्य प्रणाली में टूटी हुई प्राथमिक मात्रा को जोड़ते हैं, तो अगला कदम इसे माउंट करना है। इसे माउंट करने के लिए आपको यह सुनिश्चित करने की आवश्यकता होगी कि आपके पास एक स्वच्छ माउंट स्थान है और आपको यह भी काम करने की आवश्यकता होगी कि आपको किस डिस्क/वोल्यूम/पार्टिशन(s) को माउंट करने की आवश्यकता है।

यह सुनिश्चित करने का एक आसान तरीका है कि आपके पास उपयोग करने के लिए एक स्वच्छ माउंट स्थान है, यह बनाना है! इस तरह कुछ:

mkdir /rescue

यह सुनिश्चित करने के लिए कि आपको सही ड्राइव/वोल्यूम/पार्टिशन(s) मिल सकता है, एक छोटा सा चालीसा हो सकता है, लेकिन एक ऐसा उपकरण जिसका आप उपयोग कर सकते हैं वह fdisk है। सभी संलग्न वॉल्यूम देखने के लिए, दौड़ें:

fdisk -l

यहां एक AWS सर्वर पर आउटपुट है जो मैं वर्तमान में काम कर रहा हूँ। इसमें एक माध्यमिक ड्राइव (अन्य सर्वर की जड़ मात्रा) है जो /dev/xvdf, डिफ़ॉल्ट रूट वॉल्यूम (i.e.) के रूप में जुड़ा हुआ है। कार्य सर्वर की मूल मात्रा /dev/xvda. है जो आपके लिए अलग हो सकती है (हालांकि यदि आप AWS पर हैं तो यह संभावना समान है)।

root@core ~# fdisk -l
Disk /dev/xvda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6183BC26-31B1-41F2-9AB9-319B7C4A85B0

Device     Start      End  Sectors Size Type
/dev/xvda1  2048     6143     4096   2M BIOS boot
/dev/xvda2  6144 20969471 20963328  10G Linux filesystem

Disk /dev/xvdf: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0029AB38-4BE5-4009-B163-9A7B4F597FE4

Device     Start      End  Sectors Size Type
/dev/xvdf1  2048     6143     4096   2M BIOS boot
/dev/xvdf2  6144 20969471 20963328  10G Linux filesystem

यदि आप अनिश्चित हैं कि कौन सी मात्रा एक है, तो जांचें कि कौन से वॉल्यूम पहले से ही माउंट किए गए हैं। ऐसा करें:

 mount | grep ^/dev

यह उन सभी लाइनों की जाँच करेगा जो /dev. के साथ शुरू होते हैं। मेरे मामले में, यह पुष्टि करता है कि मैं पहले से ही जानता हूँ, मैं पहले से ही माउंटेड हूँ, /dev/xvda: है।

root@core ~# mount | grep ^/dev
/dev/xvda2 on / type ext4 (rw,relatime,data=ordered)
/dev/xvda2 on /tmp type ext4 (rw,relatime,data=ordered)
/dev/xvda2 on /var/cache/tklbam type ext4 (rw,relatime,data=ordered)

टूटी हुई प्रणाली को घुमाने के लिए तैयार करना

इसलिए एक बार जब आप बाहर काम करते हैं तो आपको किस विभाजन की आवश्यकता होगी। यह बहुत सरल है। मेरे मामले में, मुझे जिस विभाजन को माउंट करना होगा वह /dev/xvdf2 है (यानी। /dev/xvf). पर दूसरा विभाजन यदि आप ऊपर देखते हैं, तो fdisk से मेरे आउटपुट पर, आपको देखेंगे कि /dev/xvdf1 टाइप "BIOS बूट" है और /dev/xvdf2 "Linux फाइल सिस्टम" है। इस तरह के रूप में आसान माउंट करने के लिए:

mount /dev/xvdf2 /rescue

यदि आप अब /rescue (i.e. ls /rescue),) में चेक करते हैं तो आपको इस तरह कुछ देखना चाहिए:

root@core ~# ls -l /rescue
total 92
drwxr-xr-x   2 root root  4096 Apr 16 02:49 bin
drwxr-xr-x   3 root root  4096 Apr 16 02:50 boot
drwxr-xr-x   5 root root  4096 Oct  3  2018 dev
drwxr-xr-x 100 root root  4096 Apr 16 02:50 etc
drwxr-xr-x   3 root root  4096 Oct  3  2018 home
lrwxrwxrwx   1 root root    29 Oct  3  2018 initrd.img -> boot/initrd.img-4.9.0-8-amd64
lrwxrwxrwx   1 root root    29 Oct  3  2018 initrd.img.old -> boot/initrd.img-4.9.0-8-amd64
drwxr-xr-x  18 root root  4096 Oct  3  2018 lib
drwxr-xr-x   2 root root  4096 Mar 11  2018 lib64
drwx------   2 root root 16384 Oct  3  2018 lost+found
drwxr-xr-x   2 root root  4096 Mar 11  2018 media
drwxr-xr-x   4 root root  4096 Apr 16 02:49 mnt
drwxr-xr-x   2 root root  4096 Mar 11  2018 opt
drwxr-xr-x   2 root root  4096 Feb 23  2018 proc
drwx------   5 root root  4096 Oct  3  2018 root
drwxr-xr-x  12 root root  4096 Oct  3  2018 run
drwxr-xr-x   2 root root  4096 Apr 16 02:49 sbin
drwxr-xr-x   2 root root  4096 Mar 11  2018 srv
drwxr-xr-x   2 root root  4096 Feb 12  2017 sys
drwxrwxrwt   7 root root  4096 Apr 16 02:51 tmp
drwxr-xr-x  10 root root  4096 Mar 11  2018 usr
drwxr-xr-x  13 root root  4096 Oct  3  2018 var
lrwxrwxrwx   1 root root    26 Oct  3  2018 vmlinuz -> boot/vmlinuz-4.9.0-8-amd64
lrwxrwxrwx   1 root root    26 Oct  3  2018 vmlinuz.old -> boot/vmlinuz-4.9.0-8-amd64

जाहिर है तारीख अलग हो जाएगी, लेकिन अन्यथा, यह दर्शाता है कि सिस्टम की उम्मीद के रूप में बढ़ रही है। TurnKey के सभी वर्तमान निर्माणों में /boot विभाजन शामिल है, हालांकि कुछ पुरानी रिलीज में, अगर स्थापित LVM का इस्तेमाल किया जाता है, तो /boot विभाजन को अलग से माउंट करने की आवश्यकता हो सकती है। उस मामले में, मुख्य ओएस के बाद घुड़सवार है, बूट निर्देशिका माउंट।

mount /dev/sdXN /rescue/boot

जहां /dev/sdXN विभाजन है जहां बूट जानकारी निवास करती है।

लेकिन इंतजार करना और भी है! एक बार मुख्य ओएस को शुरू होने के बाद आपको मेजबान से कुछ विशेष निर्देशिकाओं को माउंट करने की भी आवश्यकता है ताकि chroot ठीक से काम करे। पहले से ये /dev, /proc और /sys. /dev/pts भी बढ़ते लायक हैं। मेरे अनुभव में, आप उस पर बढ़ने के बिना दूर हो सकते हैं, लेकिन आपको अक्सर त्रुटियां होंगी, इसलिए यह बढ़ना लायक है कि शोर को कम करने के लिए।

mount -t proc proc /rescue/proc
mount -t sysfs sys /rescue/sys
mount -o bind /dev /rescue/dev
mount -t devpts pts /rescue/dev/pts

में Chrooting

अब आपको बस में chroot की आवश्यकता है। ऐसा करना:

chroot /rescue

जैसा कि ...! :)

अब क्या आपको अपने सिस्टम को ठीक करने के लिए क्या करना है? एक बार जब आप खुश हो (या सिर्फ टेस्ट करने के लिए तैयार) तो आप इस तरह के चुटकुले से बाहर निकल सकते हैं:

exit

बाद में सफाई करना

यदि आपको सर्वर को टूटी हुई ड्राइव को हटाने के लिए रोकने की आवश्यकता है, तो कोई साफ़-अप की आवश्यकता नहीं है। सभी घटकों को बंद करने की प्रक्रिया के हिस्से के रूप में ऑटो को अनमाउंट किया जाना चाहिए। यदि आपको सर्वर को रोकने की आवश्यकता नहीं है, तो पुनः आरंभ करना chroot को साफ करने का सबसे आसान तरीका है। हालांकि, यदि आप सर्वर का उपयोग नहीं कर रहे हैं, या किसी अन्य कारण से chroot config को रद्द करना चाहते हैं, तो उसके बाद आपने chroot से बाहर निकलने के बाद, आपको बस सिर्फ़ जरूरत है कि आपको सर्वर को रोकना है, या किसी अन्य कारण से chroot config को बाहर करना पसंद होगा, फिर इसके बाद आपको chroot से बाहर निकलने के लिए, आपको बस जरूरत है कि आपको सिर्फ़ chroot से बाहर निकलने की आवश्यकता है। उपरोक्त कमांडों पर बैकट्रैक करें। I.e. माउंट के बजाय umount का उपयोग करें और उन्हें रिवर्स ऑर्डर में उतार दें। I.e.:

umount /rescue/dev/pts
umount /rescue/dev
umount /rescue/sys
umount /rescue/proc

If you mounted a separate boot partition, unmount that next. I.e. 'umount /rescue/boot'. Then finally, the main volume:

umount /rescue