เหตุผลสำหรับไดเรกทอรี `/ usr` คืออะไร?


107

เหตุผลสำหรับ "ทรัพยากรระบบ unix" หรือ/usrไดเรกทอรีดังอธิบายไว้ที่นี่ซึ่งซ้ำชื่อหลายชื่อไดเรกทอรีภายใต้ไดเรกทอรีราก/คืออะไร?

จุดประสงค์ของฉัน: ฉันกำลังติดตั้ง Oracle JDK เป็นครั้งที่เท่าที่จำเป็นและตัดสินใจในครั้งนี้ว่าจะต้องติดตั้ง/home/userและฉันก็แค่อ่านไปเรื่อย ๆ เพื่อดูว่ามันเป็นความคิดที่ไม่ดีในเครื่องผู้ใช้เครื่องเดียวหรือไม่


1
โฮมไดเรกทอรีของคุณเป็นสถานที่ที่เหมาะสำหรับการติดตั้งซอฟต์แวร์ของบุคคลที่สามในฐานะที่ไม่ใช่รูท
Lekensteyn

9
... การรับรู้ที่น่าเศร้าเพราะคุณคิดว่า/usrหมายถึงไดเรกทอรี "ผู้ใช้" ที่ซ่อนอยู่เป็นเวลาหลายปี ...
Govind Rai

6
ฉันคิดอย่างจริงจังว่าเป็น "ผู้ใช้" ตลอดเวลานี้ เช่นเดียวกับผู้ใช้ไบนารี
แทนเนอร์ Babcock

คำตอบ:


168

มีรุ่นสั้นและรุ่นยาวของคำตอบของคุณ ...

เวอร์ชั่นสั้น:

ในฐานะที่เป็นลิงค์ของคุณแล้วกล่าวว่า/usrเป็นสถานที่สำหรับทั้งระบบ , อ่านอย่างเดียวไฟล์ ดังนั้นซอฟต์แวร์ที่คุณติดตั้งทั้งหมดจึงไปที่นั่น มันไม่ได้ซ้ำกันชื่อใด ๆ/ยกเว้น/binและ/libแต่เดิมมีวัตถุประสงค์ที่แตกต่างกัน: /bin, /libมีไว้สำหรับไบนารีและไลบรารีที่จำเป็นสำหรับการบูตในขณะที่/usr/bin, /usr/libมีไว้สำหรับไฟล์ปฏิบัติการและไลบรารีอื่นทั้งหมด (ตอนนี้เป็นเด็กดีและไม่ต้องถาม/sbinนี่เป็นเวอร์ชั่นย่อหลังจากทั้งหมด)

ปัจจุบันความแตกต่างระหว่าง "จำเป็นสำหรับการบูต" และไม่ได้ลดลงเนื่องจาก distros ที่ทันสมัยมากที่สุดรวมทั้ง Ubuntu /usrไม่สามารถบูตได้อย่างถูกต้องโดยไม่ต้องหลายไฟล์จาก และนั่นเป็นเหตุผลที่มีการเคลื่อนไหวที่แข็งแกร่งต่อการควบรวมกิจการ/usr/binและ/binดังนั้นอาจจะเป็นในอนาคตอันใกล้ (Ubuntu 12.10 บางที?) /binจะ symlink /usr/binไป

แต่บางทีคุณอาจสับสน/usrและ/usr/local? เพราะใช่มี (และควรจะบริการ) จำนวนมากของชื่อไดเรกทอรีซ้ำ เพิ่มเติมในภายหลัง ...

รุ่นยาว:

ย้อนกลับไปในยุค 70 ใน Unix (ใช่, Unix, ทางก่อน Linux), floppies มีพื้นที่น้อย (ไม่มี HD, จำได้ไหม?) และ ณ จุดที่กำหนดไบนารีระบบจะขยายจำนวนและขนาดมากเกินไปจนถึงจุดที่พวกเขาจะไม่ พอดีกับดิสก์แผ่นเดียวและนักพัฒนาจะต้องแบ่งพวกเขาออกเป็นหลายสื่อและสร้างจุดเชื่อมต่อใหม่สำหรับพวกเขา /binระบบแฟ้มได้เต็มรูปแบบเพื่อให้พวกเขาติดตั้งไบนารีใหม่ที่ /usr/bin... และ/usrในเวลานั้น ... ไดเรกทอรีผู้ใช้ของพวกเขา!

หลังจากเกิดการแบ่งแยก (ที่น่าอายและมักจะบอกว่าเป็นเรื่องตลก / ตำนาน) พวกเขาเริ่มสร้างเหตุผล (และเกณฑ์) "ประดิษฐ์" เพื่อตัดสินว่าอะไรจะเกิดขึ้น/binและอะไรจะเกิด/usr/binขึ้น กฎทางการคือ: "จำเป็น" สิ่งที่ไป /bin"ส่วนที่เหลือ" /usr/binไป /libเช่นเดียวกันกับ ไม่นานก่อนที่จะ/usrมีผู้คนหนาแน่นไปด้วยผู้ที่เกี่ยวข้องกับระบบผสมกับผู้ใช้ ดังนั้นจึง/homeถือกำเนิดขึ้นเพื่อรักษา dirs ที่เกี่ยวข้องกับผู้ใช้ทั้งหมดและรักษาความ/usrสะอาดให้กับระบบ "เนื้อหา" เท่านั้น

นี่เป็นเวลานานก่อนที่จะมี FHS เมื่อมันถูกสร้างขึ้นมันกอด (และเป็นทางการ) ประเพณีปัจจุบันและเก็บชื่อ/usrแม้ว่าในเวลานั้นมันก็ไม่มีอะไรเกี่ยวข้องกับ "ผู้ใช้" อีกต่อไป ใช่ชื่อแฟนซี " U NIX s ource r epository" หรือ " U NIX s ystem r esources" เป็นชื่อที่สร้างขึ้นทั้งหมดและมันก็สายเกินไปที่จะเปลี่ยนชื่อใหม่ (แต่ไม่สายเกินไปที่จะรวมเข้าด้วยกัน/bin)

"ตกลงแล้ว/usr/sbinล่ะ" , คุณถาม. ประณามฉันหวังว่าคุณจะลืม ตกลง ... /usr/sbinสำหรับคำสั่งที่สามารถถูกดำเนินการโดยrootผู้ใช้เช่น ( mountและมีความหมายเฉพาะเมื่อ) fdiskเท่านั้น

"แต่นั่นไม่เหมือนกัน/binใช่มั้ย" . ใช่แน่นอน แต่ ...

"เดี๋ยวก่อนแล้วทำไมมันถึงมี/sbinเหมือนกันเหรอ? . นั่นเป็นเพราะ ... เอ่อ ..

ดูสิลิง 3 หัวที่อยู่ข้างหลังคุณ!

โอเคหวังว่าคุณจะฟุ้งซ่านพอ กำลังเดินทางไป...

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

เพิ่มเติมเกี่ยวกับกรณีสำหรับการ/usrผสานจากsystemdเอกสาร:

เหตุผลเชิงประวัติสำหรับ a / bin, / sbin และ / lib แยกจาก / usr ไม่ได้มีผลบังคับใช้อีกต่อไป พวกเขาแยกออกเพื่อเลือกเครื่องมือบนฮาร์ดดิสก์ที่เร็วกว่า (ซึ่งมีขนาดเล็กเนื่องจากมีราคาแพงกว่า) และมีเครื่องมือทั้งหมดที่จำเป็นในการเมาท์พาร์ติชันที่ช้าลง / usr วันนี้พาร์ติชั่น / usr ที่แยกต่างหากจะต้องถูกเมาท์โดย initramfs ในระหว่างการบู๊ตเครื่องก่อนดังนั้นจึงมีเหตุผลสำหรับการแยกส่วน นอกจากนี้เครื่องมือจำนวนมากใน / bin และ / sbin ในสถานะเดิมสูญเสียความสามารถในการทำงานโดยไม่ต้องติดตั้ง / usr ล่วงหน้า ไม่มีเหตุผลที่ถูกต้องอีกต่อไปที่จะให้ระบบปฏิบัติการแพร่กระจายไปตามลำดับชั้นหลาย ๆ ชุด แต่ก็ทำให้วัตถุประสงค์ของมันหายไป

และการอ่านเกี่ยวกับการ/usrแบ่งแยกและเหตุผลที่น่าทึ่งโดย Rob Landley:

ทำความเข้าใจกับการแยก bin, sbin, usr / bin, usr / sbin

ในปัจจุบันนี้

ขณะนี้เกี่ยวกับไดเรกทอรีการติดตั้งวิธีที่ดีที่สุดที่คุณจะเข้าใจคือคิดแบบนี้:

  • /usr - ไฟล์ทั้งหมดทั้งระบบอ่านอย่างเดียวที่ติดตั้งโดย (หรือให้บริการโดย) ระบบปฏิบัติการ

  • /usr/local- ไฟล์ทั้งระบบแบบอ่านอย่างเดียวที่ติดตั้งโดยผู้ดูแลระบบท้องถิ่น (โดยปกติคือคุณ) และนี่คือสาเหตุที่ชื่อไดเรกทอรีส่วนใหญ่/usrมีการทำซ้ำที่นี่

  • /opt- โหดร้ายหมายสำหรับทั้งระบบอ่านอย่างเดียวและตนเองมีซอฟแวร์ นั่นคือซอฟแวร์ที่ไม่ได้แยกไฟล์ของพวกเขามากกว่าbin, lib, share, includeเช่นซอฟต์แวร์มีความประพฤติดีควร

  • ~/.local- คู่ต่อผู้ใช้/usr/localคือ: ซอฟต์แวร์ที่ติดตั้งโดย (และสำหรับ) ผู้ใช้แต่ละคน

  • ~/.local/opt - คู่ต่อผู้ใช้ของ /opt

ดังนั้นจะติดตั้งซอฟต์แวร์ที่ไหน?

รายการด้านบนเป็นคำตอบสำหรับคุณคำถาม Oracle JDK ที่ครึ่งหนึ่งแล้วอย่างน้อยก็มีหลายประเด็น รายการตรวจสอบเพื่อ"ฉันควรติดตั้งซอฟต์แวร์ X ที่ไหน" ไปโดย:

  • มันเป็นซอฟต์แวร์ไดเรกทอรีที่มีอยู่ในตัวเองอย่างสมบูรณ์เช่น Eclipse IDE และแอป Java ที่ดาวน์โหลดอื่น ๆ และคุณต้องการให้ผู้ใช้ทุกคนสามารถใช้งานได้หรือไม่? จากนั้นติดตั้งใน/opt

  • เช่นเดียวกับข้างต้น แต่คุณไม่สนใจผู้ใช้คนอื่นและฉันต้องการติดตั้งสำหรับผู้ใช้ของคุณคนเดียว? จากนั้นติดตั้งใน~/.local/opt

  • ไฟล์มันแบ่งออกเป็น dirs หลาย ๆ อันเช่นbinและshareเหมือนซอฟต์แวร์ดั้งเดิมที่คอมไพล์และติดตั้งด้วย./configure && make && sudo make installและผู้ใช้ทุกคนควรพร้อมใช้งานหรือไม่ จากนั้นติดตั้งใน/usr/local

  • เหมือนด้านบน แต่สำหรับผู้ใช้ของคุณเท่านั้น จากนั้นติดตั้งใน~/.local

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

หมายเหตุ:

  • สิ่งนี้อธิบายว่าทำไมคำนำหน้าการติดตั้งเริ่มต้นสำหรับซอฟต์แวร์ที่คอมไพล์/usr/localแล้วและทำไมคุณควรเปลี่ยนเป็น./configure --prefix=$HOME/.localเมื่อติดตั้งซอฟต์แวร์สำหรับผู้ใช้ของคุณเองเท่านั้น

  • คุณอาจสังเกตเห็นว่าไดเรกทอรีข้างต้นทั้งหมดเป็นแบบอ่านอย่างเดียว (ยกเว้นแน่นอนเมื่อคุณติดตั้ง / ลบซอฟต์แวร์) ไฟล์ที่เขียนได้ (เช่นไฟล์กำหนดค่า) มักจะไปที่/etc(สำหรับซอฟต์แวร์ทั่วทั้งระบบ) และ~/.config(สำหรับการตั้งค่าต่อผู้ใช้) แม้ว่าจะมีซอฟต์แวร์รุ่นเก่าหลายตัว (และน่าเสียดายที่มีบางรุ่นที่ทันสมัย) ใช้งาน~/.<software-name>ทำให้รกโฟลเดอร์บ้านของคุณด้วยไฟล์และพันล้านไฟล์

  • ~/.localและ~/.configไม่ได้เป็นส่วนหนึ่งของข้อกำหนด FHS FHS ไม่ได้จัดการกับโฟลเดอร์บ้านของผู้ใช้ พวกเขาเป็นความพยายามของ XDG ซึ่งเป็นองค์กรมาตรฐานอีกแห่งหนึ่งที่มุ่งเน้นไปที่สภาพแวดล้อมเดสก์ท็อป (เช่น Gnome, KDE และ Unity) เพื่อพยายามกำหนดอนุสัญญาบางประการเกี่ยวกับโครงสร้างของบ้านของผู้ใช้ ไม่ใช่ว่าทุกคนจะปฏิบัติตามซอฟต์แวร์(ตัวอย่างเช่น~/.local/binไม่ได้อยู่ในค่าเริ่มต้นของผู้ใช้$PATHในขณะที่มันควรจะเป็นตรรกะ)และไม่มีผู้ใช้ถูกบังคับให้ทำตาม แต่ทั้งสองได้รับประโยชน์การทำงานร่วมกันมากมายถ้าพวกเขาทำ

ฉันหวังว่านี่จะช่วยชี้แจงสิ่งต่าง ๆ เล็กน้อย อย่าลังเลที่จะถามอะไรเพื่อที่ฉันจะได้ปรับปรุงคำตอบ!

(และฉันก็หวังว่าผู้สอนจะไม่ฆ่าฉันสำหรับภาษาและคำอธิบายที่ไม่เป็นทางการเช่นนี้มันเป็นความตั้งใจและแน่นอนว่ามีความไม่ถูกต้องหลายอย่าง แต่ฉันเชื่อว่ามันเป็นวิธีที่ดีในการทำให้ผู้มาใหม่ ไดเรกทอรีเหตุผล)


1
คุณสรุปได้อย่างกระชับและใช่มันเป็นความจริง - คำตอบที่สมบูรณ์คือเรื่องราวที่ยาวกว่าข้างบนมาก!
papashou

ทำไมจะไม่ล่ะ? ใช้ตรรกะเดียวกัน: ผู้โจมตีอาจสร้างปฏิบัติการภายใต้บ้านหรือไดเรกทอรีย่อยของมันตั้งชื่อตามคำสั่งของระบบ
Ignis

3
@ignis: หากผู้โจมตีมีสิทธิ์เข้าถึงในการสร้างและแก้ไขไฟล์ภายใต้หน้าแรกของผู้ใช้ผู้ใช้นั้นจะถูกโจมตีโดยสมบูรณ์แล้วและ$PATHไม่เกี่ยวข้อง ผู้โจมตียังสามารถเปลี่ยนที่ผ่าน~/.profileดังนั้นจุดของคุณเป็นที่สงสัย ~/.local/binมีความปลอดภัย (หรือไม่ปลอดภัยหากคุณต้องการ) ~/binซึ่งเป็นวิธีปฏิบัติทั่วไปใน distros ส่วนใหญ่ ความคิดที่ว่าผู้ใช้ไม่ควรมีผู้ใช้ใด ๆในการเก็บและรันสคริปต์ส่วนตัวใน$PATHนั้นเป็นเรื่องไร้สาระ
MestreLion

ดังนั้นจึง~/binปลอดภัยเหมือน~/.profileและ$PATHไม่ปกป้องฉันจากมัลแวร์ที่ดำเนินการโดยฉัน (ซึ่งได้รับอนุญาตให้เขียนในบ้านของฉันเอง) ฉันไม่รู้จักไฟล์นี้ฉันขอโทษ ขอบคุณสำหรับคำชี้แจงขออภัยในความคิดเห็นก่อนหน้าของฉัน
Ignis

ยิ่งมีประวัติศาสตร์ที่ยาวนานขึ้นเท่าไหร่
smwikipedia
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.