Chúng ta hãy làm rõ với tất cả các thư mục bin và sbin (từ tiêu chuẩn phân cấp hệ thống tệp):

• /bin dành cho nhị phân cấp hệ thống
• /sbin dành cho các nhị phân cấp hệ thống khác, chủ yếu dành cho trình tải khởi động và quản trị viên hệ thống
• /usr/bin không phải là nhị phân thiết yếu
• /usr/sbin- đây là nơi lộn xộn bắt đầu - không phải là công cụ cần thiết cho quản trị viên hệ thống? Nó có nghĩa là gì? Cho thí nghiệm?
• /usr/local/bin - không có thông tin gì về thư mục này
• /usr/local/sbin- cài đặt chương trình quản trị hệ thống cục bộ. Lần nữa? Thế còn /usr/sbin?

Vì vậy, câu hỏi là: Tại sao có rất nhiều thư mục và ý nghĩa của /usr/sbin, /usr/local/sbinvà là /usr/local/bingì?

Nhiều chương trình được phân phối thông qua tài liệu lưu trữ và chúng tôi phải xây dựng chúng từ mã nguồn. Thông thường họ có makefile nên khá dễ dàng. Quá trình này bao gồm việc tạo các tệp trong usr / local / lib, usr / local / bin ... usr / local / bất cứ thứ gì mà không tạo các thư mục cụ thể cho một chương trình nhất định.

Tại sao nó như vậy?

Tôi nghĩ rằng điều đó không đúng bởi vì nếu chúng ta cần xóa chương trình, chúng ta phải xóa thủ công mọi tệp của nó nếu người tạo chương trình không quan tâm đến nó.

1. Cấu trúc thư mục

Điều này cần được đề cập trong Tiêu chuẩn phân cấp hệ thống tập tin ( 2.3 PDF )

/ bin / Các nhị phân lệnh cần thiết phải có sẵn trong chế độ người dùng;
            cho tất cả người dùng, ví dụ: cat, ls, cp

/ sbin / Các nhị phân hệ thống thiết yếu, ví dụ: init, ip, mount.

/ usr / bin / Các nhị phân lệnh không cần thiết (không cần trong chế độ người dùng đơn); 
            Cho tất cả người dùng

/ usr / sbin / Các nhị phân hệ thống không thiết yếu, ví dụ trình nền cho các dịch vụ mạng khác nhau.

/ usr / local / Phân cấp thứ ba cho dữ liệu cục bộ, cụ thể cho máy chủ này. 
            Thông thường có các thư mục con khác, ví dụ: bin /, lib /, share /

2. Cài đặt

Tôi sử dụng trình quản lý gói bất cứ khi nào có thể (ví dụ: yum hoặc apt-get). Điều này có thể cho một số lượng lớn các ứng dụng, trong một vài trường hợp bạn có thể phải thêm một kho lưu trữ. Lựa chọn thứ hai của tôi sẽ là các gói cấp thấp hơn như RPM và biên dịch từ nguồn sẽ là phương án cuối cùng của tôi (nhưng một số người thích điều này)

Một số người quản lý gói có thể cài đặt từ RPM (ví dụ yum install oddity.rpm)

Nếu bạn đang biên dịch từ nguồn, có lẽ không phải là một bước lớn để tạo gói của riêng bạn để trình cài đặt hệ thống biết bạn đã làm gì.

Sau đó, vấn đề của bạn giảm xuống yum remove packagename

Cách khác là giữ tài liệu tốt về tất cả các hoạt động của sysadmin được thực hiện (dù sao tôi vẫn giữ một tạp chí trong một tệp văn bản)

Nội dung trong tất cả các thư mục * / sbin có xu hướng chỉ hữu ích cho quản trị viên hệ thống. Bạn có thể tránh xa PATH nếu bạn là người dùng bình thường.

Các thư mục khác nhau không có ý nghĩa gì nếu bạn có một máy unix duy nhất trên một đĩa, nhưng sẽ có ý nghĩa hơn nếu bạn có một hệ thống lớn và các phân vùng khác nhau. Hãy nhớ rằng rất nhiều những thói quen này đã được thực hiện vào những năm 80 và 90 khi các hệ thống hơi khác một chút.

/sbincó xu hướng rất nhỏ Đây là những tiện ích mà bạn cần khi bạn thực sự hos. Bạn sẽ đặt cái này trên một phân vùng gốc tối thiểu với / root và / lib. Mọi thứ trong / sbin từng được liên kết tĩnh, vì nếu phân vùng / usr của bạn bị hos, mọi ứng dụng được liên kết động đều vô dụng. fsck ở đây và liên kết tĩnh. Nếu bạn có một phụ thuộc vào / usr, rõ ràng bạn không thể fsck / usr /. Tất nhiên, nếu phân vùng gốc bị hos, bạn sẽ rất khó chịu. Đây là lý do tại sao đây là một phân vùng nhỏ như vậy - giảm tỷ lệ cược của một khối đĩa xấu bằng cách sử dụng rất ít khối ở đây.

/usr/sbinnhị phân là các công cụ sysadmin chung nơi bạn ít nhất có thể vào chế độ người dùng duy nhất và gắn kết tất cả các khối lượng của bạn. Họ được phép liên kết động.

Các phân vùng riêng cho / sbin (tốt, / sbin trên / phân vùng) và / usr cũng có ý nghĩa hơn khi bạn nhớ rằng sao lưu rất tốn kém cả về thời gian và băng từ. Nếu chúng nằm trên các phân vùng riêng biệt, bạn có thể lên lịch cho chúng khác nhau.

/usr/localcó thể là một hệ thống tập tin mạng. Vì vậy, các công cụ sysadmin được viết cục bộ có thể được chia sẻ trên nhiều máy đôi khi đi vào / usr / local / sbin. Rõ ràng không có dụng cụ sửa chữa mạng có thể đi đến đó.

Một lần nữa, rất nhiều điều có ý nghĩa hơn đối với các máy lớn trong môi trường được nối mạng trên các máy được quản lý có nhiều khối lượng, ít hơn với một máy Linux trên một phân vùng gốc.

Bạn thực sự nên có câu hỏi thứ hai của bạn là một câu hỏi riêng biệt ở đây trên Superuser. Nó không liên quan đến cái đầu tiên.

Có, có tập tin ở khắp mọi nơi hút. Đó là lý do tại sao có nhiều giải pháp đóng gói. RedHat đã tạo RPM được sử dụng ở mọi nơi. Solaris có định dạng gói của họ. HP / UX có của họ, và có apt và nhiều định dạng gói khác. Giữ mọi thứ ở đúng nơi (/ usr / bin, / usr / lib) khi thích hợp, nhưng cho phép dễ dàng thêm và xóa.

Đối với nguồn, đã từng có các công cụ cho phép bạn định cấu hình và cài đặt trong một thư mục con của / usr / local và nó sẽ xử lý các liên kết tượng trưng đến / usr / local / bin cho bạn. Vì sự phổ biến rộng rãi của các công cụ gói, điều này ít cần thiết hơn và tôi đã quên tên của chúng.

Một số người thích cài đặt trong / opt / packagename và giữ mọi thứ cùng nhau ở đó. Điều tốt: mọi thứ đều nằm trong một thư mục và gỡ cài đặt rm -rf /opt/packagename. Nhược điểm của việc này là phải thêm / opt / packagename / bin vào PATH của mọi người và thực tế là mọi người thường không đặt / opt vào một phân vùng riêng và bạn điền vào phân vùng gốc.

Tôi hiểu ý nghĩa của các thư mục (từ kinh nghiệm với Debian GNU Linux) là:

Phân biệt đầu tiên: sdành cho siêu người dùng

strước một binthư mục chỉ ra rằng nó chứa các công cụ thường chỉ hữu ích cho quản trị viên. Lưu ý rằng ví dụ ifconfigcũng thuộc danh mục này và tôi muốn gọi ifconfignhư một người dùng thông thường (để kiểm tra xem tôi có địa chỉ IP / kết nối mạng không), điều này làm cho sự khác biệt này không khó như vẻ ngoài của nó.

Phân biệt thứ hai: localdành cho "Dữ liệu cục bộ"

Trong thực tế, điểm khác biệt quan trọng nhất ở đây là các trình quản lý gói hệ điều hành (như APT) cài đặt các gói theo /usrcấu trúc bình thường và /usr/localkhông bị ảnh hưởng. Điều này cho phép các gói được biên dịch cục bộ hoặc tập lệnh nội bộ công ty do quản trị viên hệ thống cung cấp được đặt /usr/localở nơi chúng sẽ không bao giờ can thiệp vào các tệp được đóng gói đúng cách.

Người ta tranh cãi liệu có /usr/localnên ghi đè các tệp hiện có từ /usrcấu trúc bình thường hay không , xem Có nguy hiểm khi có / usr / local / bin trước / usr / bin trong PATH của một người không? cho một số chi tiết về điều này.

Phân biệt thứ ba: Cấp cao nhất /binvà /sbinthư mục.

Trên Debian, thực sự có cái gọi là UsrMerge . Trước đây thường có sự khác biệt /binvà /sbincó sẵn trong quy trình khởi động (nghĩ về /usrviệc sử dụng thiết bị mạng hoặc phân vùng khác, RAID, v.v.), nhưng ngày nay, rất ít hệ thống Linux khởi động tốt mà không phải /usrlà lý do tại sao tôi sẽ xem xét sự khác biệt giữa top- cấp độ và /usrthư mục phần lớn là mối quan tâm lịch sử đối với Linux.

Cuối cùng: Ưu điểm và vấn đề của các tệp "tán xạ".

Thực sự không có câu trả lời "đúng" nào cho vấn đề này. Ưu điểm của hệ thống tệp phân tán của Linux là:

• Tất cả các nhị phân nằm trong một vài thư mục. Điều này có nghĩa là bạn có thể gọi mọi chương trình từ shell. So sánh Windows, nơi người ta luôn cần chỉnh sửa %PATH%biến môi trường để thêm bất kỳ chương trình quan tâm nào. Tôi đã thấy môi trường đường dẫn rất dài trên Windows.

• Tất cả các thư viện nằm ở một nơi trung tâm. Điều này có nghĩa là chúng không cần phải được cài đặt hai lần khi được sử dụng bởi nhiều ứng dụng.

• Vì Linux được thiết kế nên hầu hết các tệp hệ thống đều được theo dõi bởi người quản lý gói , nên không cần phải xem tổng quan về các tệp theo quan điểm của người dùng.

• Do đảm bảo VSATTP tiêu chuẩn, tài liệu cũng cư trú ở những nơi trung tâm hệ thống cho phép thích man, infovà các tập tin README hỗ trợ cho công việc như mong đợi.

• Nó dễ dàng hơn để dựa vào một chương trình được cài đặt ở một nơi cố định. Mọi người đều viết #!/bin/sh -ehoặc tương tự khi bắt đầu các kịch bản và nó chỉ hoạt động . Hãy xem xét một hệ thống trong đó shell sẽ chuyển đến một thư mục khác: Làm thế nào để người ta biết nó sẽ lấy tên gì? Nếu quan tâm, hãy kiểm tra các cách khác nhau để cài đặt Perl hoặc LaTeX trên Windows để xem mức độ phức tạp này có thể ...

Những nhược điểm tôi đã tìm thấy cho đến nay là:

• Thông thường, khó hơn để chạy các ứng dụng "có thể di chuyển" theo nghĩa "ứng dụng di động cho Windows". Trên Linux, không dễ dàng chỉ cần sao chép chương trình sang máy tính khác ... người ta cần phải có gói (yêu cầu quyền root) hoặc xử lý LD_LIBRARY_PATHđể trỏ ứng dụng vào các đường dẫn tìm kiếm khác nhau cho các thư viện được yêu cầu.

• Cài đặt nhiều phiên bản của cùng một chương trình cần phải được hỗ trợ rõ ràng trong khi trên các hệ thống có "một thư mục cho mỗi chương trình" thì điều này thường ít xảy ra sự cố.

• Quản lý các tệp mà không có trình quản lý gói dễ bị lỗi (như đã đề cập).

Để trả lời câu hỏi thứ hai của bạn:
Thông thường các chương trình được phân phối với cái gọi là trình quản lý gói . Trình quản lý gói thường tìm nạp các gói nhị phân (phần mềm được biên dịch cho một nền tảng nhất định) và ném nó xung quanh các thư mục (có một số người tải mã nguồn, biên dịch nó trên máy của bạn và cài đặt nó). Do đó, người quản lý gói biết nơi các tệp thuộc "chương trình" (gói) nhất định đang ở và khi bạn muốn xóa gói, trình quản lý gói sẽ đảm nhiệm việc dọn dẹp mọi thứ.
Ngay cả khi bạn tự biên dịch mã nguồn với

make

và cài đặt nó với

make install

bạn thường có thể làm

make uninstall

trong đó xóa các tập tin từ hệ thống tập tin.