มาทำความรู้จักกับ bin และโฟลเดอร์ sbin ทั้งหมด (จากมาตรฐานลำดับชั้นของระบบไฟล์):

• /bin มีไว้สำหรับไบนารีระดับระบบ
• /sbin สำหรับไบนารีระดับระบบอื่น ๆ ส่วนใหญ่สำหรับบูตโหลดเดอร์และผู้ดูแลระบบ
• /usr/bin มีไว้สำหรับไบนารีไม่จำเป็น
• /usr/sbin- นี่เป็นจุดเริ่มต้นของระเบียบ - ไม่ใช่เครื่องมือที่จำเป็นสำหรับผู้ดูแลระบบ? มันหมายความว่าอะไร? สำหรับการทดลอง?
• /usr/local/bin - ไม่มีคำพูดใด ๆ เกี่ยวกับโฟลเดอร์นี้
• /usr/local/sbin- โปรแกรมการดูแลระบบที่ติดตั้งในเครื่อง อีกครั้งหรือไม่ แล้วไง/usr/sbinล่ะ

ดังนั้นคำถามคือทำไมมีไดเรกทอรีจำนวนมากและสิ่งที่เป็นความหมายของ/usr/sbin, /usr/local/sbinและ/usr/local/bin?

มีหลายโปรแกรมที่เผยแพร่ผ่านไฟล์เก็บถาวรและเราต้องสร้างจากซอร์สโค้ด โดยปกติแล้วพวกเขามี makefile ดังนั้นมันค่อนข้างง่าย กระบวนการนี้เกี่ยวข้องกับการสร้างไฟล์ใน usr / local / lib, usr / local / bin ... usr / local / อะไรก็ตามโดยไม่ต้องสร้างโฟลเดอร์เฉพาะสำหรับโปรแกรมที่กำหนด

ทำไมถึงเป็นเช่นนั้น

ฉันคิดว่ามันไม่ถูกต้องเพราะถ้าเราจำเป็นต้องลบโปรแกรมที่เราต้องลบทุกไฟล์ด้วยตนเองถ้าผู้สร้างโปรแกรมไม่ได้ดูแลมัน

1. โครงสร้างไดเรกทอรี

สิ่งนี้ควรครอบคลุมในลำดับชั้นของระบบแฟ้ม ( 2.3 PDF )

/ bin / Essential ไบนารีคำสั่งที่จำเป็นต้องมีในโหมดผู้ใช้คนเดียว
            สำหรับผู้ใช้ทั้งหมดเช่น cat, ls, cp

/ sbin / ไบนารีระบบที่สำคัญเช่น init, ip, mount

/ usr / bin / ไบนารีคำสั่งที่ไม่จำเป็น (ไม่จำเป็นในโหมดผู้ใช้คนเดียว); 
            สำหรับผู้ใช้ทั้งหมด

/ usr / sbin / ไบนารีระบบที่ไม่จำเป็นเช่น daemons สำหรับบริการเครือข่ายที่หลากหลาย

/ usr / local / ลำดับชั้นสำหรับข้อมูลท้องถิ่นเฉพาะโฮสต์นี้ 
            โดยทั่วไปจะมีไดเรกทอรีย่อยเพิ่มเติมเช่น bin /, lib /, share /

2. การติดตั้ง

ฉันใช้ตัวจัดการแพคเกจทุกที่ที่เป็นไปได้ (เช่น yum หรือ apt-get) นี่เป็นไปได้สำหรับแอปพลิเคชันจำนวนมากในบางกรณีคุณอาจต้องเพิ่มที่เก็บ ตัวเลือกที่สองของฉันจะเป็นแพ็คเกจระดับล่างเช่น RPM และการรวบรวมจากแหล่งที่มาจะเป็นทางเลือกสุดท้ายของฉัน (แต่บางคนชอบสิ่งนี้)

ผู้จัดการแพ็คเกจบางคนสามารถติดตั้งได้จาก RPM (เช่นyum install oddity.rpm)

หากคุณรวบรวมจากแหล่งที่มาอาจไม่ใช่ขั้นตอนใหญ่ในการสร้างแพ็คเกจของคุณเองเพื่อให้ผู้ติดตั้งระบบรู้ว่าคุณทำอะไรไปแล้ว

จากนั้นปัญหาของคุณจะลดลงเช่น yum remove packagename

ทางเลือกคือเก็บเอกสารที่ดีเกี่ยวกับกิจกรรมดูแลระบบทั้งหมด (ฉันเก็บบันทึกประจำวันในแฟ้มข้อความอยู่แล้ว)

เนื้อหาในไดเรกทอรี * / sbin ทั้งหมดมีแนวโน้มที่จะเป็นประโยชน์สำหรับผู้ดูแลระบบเท่านั้น คุณสามารถแยกพวกเขาออกจากเส้นทางของคุณหากคุณเป็นผู้ใช้ปกติ

ไดเรกทอรีที่แตกต่างกันไม่สมเหตุสมผลถ้าคุณมีเครื่องยูนิกซ์เดี่ยวบนดิสก์แผ่นเดียว แต่จะเข้าใจได้ดีกว่าถ้าคุณมีระบบขนาดใหญ่และพาร์ติชันที่แตกต่างกัน โปรดจำไว้ว่านิสัยเหล่านี้มีมากมายในยุค 80 และ 90 เมื่อระบบต่างกันเล็กน้อย

/sbinมีแนวโน้มที่จะเล็กมาก สิ่งเหล่านี้คือสาธารณูปโภคที่คุณต้องการเมื่อคุณถูก hosed จริงๆ คุณใส่มันลงในพาร์ติชั่นรูทขั้นต่ำสุดด้วย / root และ / lib สิ่งที่ / sbin เคยถูกเชื่อมโยงแบบสแตติกทั้งหมดเนื่องจากถ้าพาร์ทิชัน / usr ของคุณถูกซ่อนแอปที่เชื่อมโยงแบบไดนามิกใด ๆ จะไร้ประโยชน์ fsck อยู่ที่นี่และเชื่อมโยงแบบคงที่ หากคุณมีการพึ่งพา / usr แน่นอนคุณไม่สามารถ fsck / usr / แน่นอนถ้าพาร์ทิชันรูทถูก hosed คุณเมามาก นี่คือเหตุผลที่เป็นพาร์ติชันเล็ก ๆ - ลดราคาของบล็อกดิสก์ที่ไม่ดีโดยใช้บล็อกน้อยมากที่นี่

/usr/sbinไบนารีเป็นเครื่องมือดูแลระบบทั่วไปที่คุณสามารถเข้าสู่โหมดผู้ใช้อย่างน้อยหนึ่งครั้งและติดวอลลุ่มทั้งหมดของคุณ พวกเขาได้รับอนุญาตให้เชื่อมโยงแบบไดนามิก

พาร์ติชันที่แยกต่างหากสำหรับ / sbin (well, / sbin บน / partition) และ / usr ยังมีเหตุผลเพิ่มเติมเมื่อคุณจำได้ว่าการสำรองข้อมูลมีราคาแพงมากทั้งในเวลาและเทป หากพาร์ติชั่นแยกพาร์ติชั่นคุณสามารถกำหนดตารางเวลาให้แตกต่างกัน

/usr/localสามารถเป็นระบบไฟล์เครือข่าย ดังนั้นเครื่องมือดูแลระบบที่เขียนในเครื่องซึ่งสามารถใช้ร่วมกันในหลาย ๆ เครื่องได้ในบางครั้งก็เข้าไปใน / usr / local / sbin เห็นได้ชัดว่าไม่มีการแก้ไขเครือข่ายที่สามารถไปที่นั่นได้

อีกครั้งหลายสิ่งหลายอย่างที่เหมาะสมกับเครื่องจักรขนาดใหญ่ในสภาพแวดล้อมเครือข่ายบนเครื่องที่มีการจัดการที่มีหลายวอลุ่มน้อยกว่าด้วยเครื่อง Linux เพียงเครื่องเดียวในพาร์ติชันรากเดียว

คุณควรให้คำถามที่สองเป็นคำถามแยกต่างหากที่นี่ใน Superuser มันไม่เกี่ยวข้องกับครั้งแรก

ใช่มีไฟล์ทั่วสถานที่ครับ นั่นเป็นเหตุผลที่มีโซลูชั่นบรรจุภัณฑ์มากมาย RedHat สร้าง RPM ซึ่งใช้ทุกที่ Solaris มีรูปแบบแพ็คเกจ HP / UX มีสิ่งเหล่านี้และมีรูปแบบที่เหมาะสมและรูปแบบอื่น ๆ อีกมากมาย เก็บสิ่งต่าง ๆ ไว้ในที่ที่ถูกต้อง (/ usr / bin, / usr / lib) ตามความเหมาะสม แต่ให้เพิ่มและนำออกได้ง่าย

สำหรับแหล่งข้อมูลเคยมีเครื่องมือที่จะช่วยให้คุณกำหนดค่าและติดตั้งในส่วนย่อยของ / usr / local และมันจะจัดการ symlink ไปยัง / usr / local / bin สำหรับคุณ เนื่องจากมีการแพร่กระจายอย่างกว้างขวางของเครื่องมือแพ็กเกจสิ่งนี้มีความจำเป็นน้อยกว่าและฉันลืมชื่อของพวกเขา

บางคนชอบติดตั้งใน / opt / packagenameและเก็บทุกอย่างไว้ด้วยกัน ดี: rm -rf /opt/packagenameทุกอย่างอยู่ในไดเรกทอรีหนึ่งและถอนการติดตั้ง ข้อเสียของสิ่งนี้คือการเพิ่ม / opt / packagename / bin ให้กับ PATH ของทุกคนและความจริงที่ว่าคนมักจะไม่ใส่ / opt บนพาร์ติชั่นแยกต่างหากและคุณเติมพาร์ติชั่นรูท

การใช้ความหมายของไดเรกทอรีของฉัน (จากประสบการณ์กับ Debian GNU Linux) ของฉันคือ:

ความแตกต่างแรก: sสำหรับ superuser

sก่อนbinไดเรกทอรีระบุว่ามันมีเครื่องมือที่โดยปกติจะมีประโยชน์สำหรับผู้ดูแลระบบ โปรดทราบว่าเช่นifconfigเป็นของประเภทนี้และฉันต้องการเรียกใช้ifconfigในฐานะผู้ใช้ปกติ (เพื่อตรวจสอบว่าฉันได้รับการเชื่อมต่อที่อยู่ IP / เครือข่าย) ซึ่งทำให้ความแตกต่างนี้ไม่ยากอย่างที่คิด

ความแตกต่างที่สอง: localสำหรับ "ข้อมูลท้องถิ่น"

ในทางปฏิบัติความแตกต่างที่สำคัญที่สุดที่นี่คือผู้จัดการแพ็คเกจระบบปฏิบัติการ (เช่น APT) ติดตั้งแพ็กเกจกับ/usrโครงสร้างปกติและ/usr/localไม่ได้รับผลกระทบ สิ่งนี้ช่วยให้แพคเกจที่คอมไพล์ในเครื่องหรือสคริปต์ภายใน บริษัท ที่จัดทำโดยผู้ดูแลระบบวางไว้ใต้/usr/localตำแหน่งที่พวกเขาจะไม่รบกวนไฟล์ที่บรรจุอย่างเหมาะสม

เป็นที่ถกเถียงกันว่า/usr/localควรจะแทนที่ไฟล์ที่มีอยู่จาก/usrโครงสร้างปกติหรือไม่ดูเป็นอันตรายหรือไม่ที่จะมี / usr / local / bin ข้างหน้า / usr / bin ใน PATH สำหรับรายละเอียดบางอย่างเกี่ยวกับเรื่องนี้

ความแตกต่างที่สาม: ระดับสูงสุด/binและ/sbinไดเรกทอรี

บนเดเบียนมีUsrMergeชื่อจริง มีการใช้เป็นความแตกต่างที่/binและ/sbinพร้อมอยู่ในขั้นตอนการบู๊ตก่อนหน้านี้ (คิด/usrเป็นบนอุปกรณ์เครือข่ายหรือพาร์ทิชันที่แตกต่างกัน, RAID ฯลฯ ) แต่ Nowdays ระบบ Linux ไม่กี่บูตโดยไม่ต้องมี/usrซึ่งเป็นเหตุผลที่ผมจะพิจารณาความแตกต่างระหว่างบนสุด ระดับและ/usrไดเรกทอรีเป็นส่วนใหญ่ที่น่าสนใจทางประวัติศาสตร์สำหรับ Linux

สุดท้าย: ข้อดีและปัญหาของไฟล์ "กระจาย"

ไม่มีคำตอบที่ "จริง" ในเรื่องนี้ ข้อดีของระบบไฟล์ที่กระจัดกระจายของ Linux คือ:

• ไบนารีทั้งหมดอยู่ในไดเรกทอรีน้อย ซึ่งหมายความว่าคุณสามารถเรียกทุกโปรแกรมจากเชลล์ เปรียบเทียบ Windows ที่หนึ่งต้องแก้ไข%PATH%ตัวแปรสภาพแวดล้อมเพื่อเพิ่มโปรแกรมที่น่าสนใจ ฉันเห็นสภาพแวดล้อมเส้นทางยาวมากบน Windows

• ห้องสมุดทั้งหมดอยู่ในส่วนกลาง ซึ่งหมายความว่าไม่จำเป็นต้องติดตั้งสองครั้งเมื่อใช้งานหลายแอปพลิเคชัน

• เนื่องจาก Linux ได้รับการออกแบบไฟล์ระบบส่วนใหญ่จะถูกติดตามโดยตัวจัดการแพ็กเกจอย่างไรก็ตามไม่จำเป็นต้องเก็บภาพรวมของไฟล์จากมุมมองของผู้ใช้

• เนื่องจาก FHS มาตรฐานเอกสารยังอยู่ในตำแหน่งกลางที่ช่วยให้ระบบเช่นman, infoและไฟล์ README สนับสนุนการทำงานตามที่คาดไว้

• ง่ายต่อการพึ่งพาโปรแกรมที่ติดตั้งในสถานที่คงที่ ทุกคนเขียน#!/bin/sh -eหรือคล้ายกันที่จุดเริ่มต้นของสคริปต์และใช้งานได้ พิจารณาระบบที่เชลล์จะไปยังไดเร็กตอรี่ต่าง ๆ : จะรู้ได้อย่างไรว่ามันใช้ชื่ออะไร? หากสนใจตรวจสอบวิธีการต่าง ๆ ในการติดตั้ง Perl หรือ LaTeX บน Windows เพื่อดูว่ามันซับซ้อนเพียงใด ...

ข้อเสียที่ฉันได้พบคือ:

• โดยทั่วไปการเรียกใช้แอปพลิเคชั่น "พกพา" ในแง่ของ "แอพพลิเคชั่นแบบพกพาสำหรับ Windows" ได้ยาก บน Linux ไม่ง่ายเพียงคัดลอกโปรแกรมไปยังคอมพิวเตอร์เครื่องอื่น ... ต้องมีแพ็คเกจ (ซึ่งต้องมีการอนุญาตรูท) หรือจัดการกับLD_LIBRARY_PATHแอพพลิเคชั่นชี้ไปที่พา ธ การค้นหาที่แตกต่างกันสำหรับไลบรารีที่ต้องตรวจสอบ

• การติดตั้งโปรแกรมเดียวกันหลายรุ่นจะต้องได้รับการสนับสนุนอย่างชัดเจนในขณะที่ระบบที่มี "หนึ่งไดเรกทอรีต่อโปรแกรม" มักจะมีปัญหาน้อยกว่านี้

• การจัดการไฟล์ที่ไม่มีตัวจัดการแพ็กเกจนั้นเกิดข้อผิดพลาดได้ง่าย (ดังที่ได้กล่าวไว้แล้ว)

ที่จะตอบคำถามที่สองของคุณ:
โดยปกติโปรแกรมจะกระจายกับสิ่งที่เรียกว่าผู้จัดการแพคเกจ ผู้จัดการแพคเกจมักจะดึงแพคเกจไบนารี (ซอฟต์แวร์ที่รวบรวมสำหรับแพลตฟอร์มที่แน่นอน) และโยนไปรอบ ๆ ไดเรกทอรี (มีบางคนที่ดาวน์โหลดซอร์สโค้ดรวบรวมไว้ในเครื่องของคุณและติดตั้ง) ดังนั้นตัวจัดการแพ็กเกจจะรู้ว่าไฟล์ที่เป็นของ "โปรแกรม" (แพคเกจ) บางอย่างกำลังอยู่และเมื่อคุณต้องการลบแพคเกจตัวจัดการแพ็กเกจจะดูแลการทำความสะอาดทุกอย่าง
แม้ว่าคุณจะรวบรวมซอร์สโค้ดด้วยตัวเองด้วย

make

และติดตั้งด้วย

make install

คุณสามารถทำได้

make uninstall

ซึ่งจะลบไฟล์ออกจากระบบไฟล์