Tôi có nên cài đặt các ứng dụng Linux trong / var hoặc / opt không?


83

Tôi chạy rất nhiều ứng dụng nguồn mở bao gồm java và tomcat. Có vẻ như hầu hết các hướng dẫn có ứng dụng của tôi chạy từ /varthư mục. Nhưng thỉnh thoảng, tôi cũng thấy /optthư mục. Trong khi tôi đang ở đó, tôi cũng thấy /usr/local/và thậm chí /etclà tốt.

Khi nào tôi nên cài đặt ứng dụng trong một thư mục này hay thư mục khác? Có những ưu và nhược điểm của từng người? Nó có liên quan đến lịch sử hương vị (Solaris vs Linux hay Red Hat vs Ubuntu) không?


8
/ etc là một nơi kỳ lạ và không phù hợp để rời khỏi ứng dụng ...
user5336

Tôi đã thấy mọi người đặt công cụ vào / etc, như các mô-đun Perl. Thật kỳ lạ, nhưng nó xảy ra ...
ℝaphink

6
Đối với mỗi sự ngớ ngẩn, có một nhà vô địch để bảo vệ nó.
womble

Câu trả lời:


133

Tiêu chuẩn cho những vấn đề này là Tiêu chuẩn phân cấp tệp . Đó là một tài liệu khá lớn. Về cơ bản (và rất đại khái), các đường dẫn tiêu chuẩn trên Linux là:

  • /bin& /sbindành cho các chương trình quan trọng cho HĐH, sbin chỉ dành cho quản trị viên;
  • /usr/bin& /usr/sbinkhông dành cho các chương trình quan trọng, sbin chỉ dành cho quản trị viên;
  • /varlà cho dữ liệu sống cho các chương trình. Nó có thể là dữ liệu bộ đệm, dữ liệu đệm, dữ liệu tạm thời (trừ khi nó /tmpđược xóa, mỗi lần khởi động lại), v.v .;
  • /usr/localdành cho các chương trình cài đặt cục bộ. Thông thường, nó lưu trữ các chương trình tuân theo các tiêu chuẩn nhưng không được đóng gói cho HĐH, mà được cài đặt thủ công bởi quản trị viên (ví dụ sử dụng ./configure && make && make install) cũng như các tập lệnh quản trị viên;
  • /optdành cho các chương trình không được đóng gói và không tuân theo các tiêu chuẩn. Bạn chỉ cần đặt tất cả các thư viện ở đó cùng với chương trình. Đây thường là một giải pháp nhanh & bẩn, nhưng nó cũng có thể được sử dụng cho các chương trình do chính bạn tạo ra và bạn muốn có một con đường cụ thể. Bạn có thể tạo đường dẫn của riêng mình (ví dụ /opt/yourcompany) trong đó và trong trường hợp này, bạn được khuyến khích đăng ký nó như một phần của đường dẫn chuẩn;
  • /etc không nên chứa các chương trình, mà là cấu hình.

Nếu các chương trình của bạn dành riêng cho các dịch vụ được cung cấp bởi dịch vụ, /srvcũng có thể là một vị trí tốt cho chúng. Ví dụ: tôi thích sử dụng /srv/wwwcho các trang web hơn là /var/wwwđể đảm bảo thư mục sẽ chỉ chứa dữ liệu tôi tự thêm và không có gì đến từ các gói phần mềm.

Có một số khác biệt giữa các bản phân phối. Ví dụ: hệ thống RedHat sử dụng các libexecthư mục khi hệ thống Debian / Ubuntu không có.

FHS chủ yếu được sử dụng bởi các bản phân phối Linux (tôi thực sự không biết bất kỳ HĐH nào khác thực sự tuân thủ nó). Các hệ thống Unix khác không tuân theo nó. Ví dụ, các hệ thống BSD có xu hướng sử dụng /usr/localcho các chương trình đóng gói, đây không phải là trường hợp của Linux. Solaris có những con đường tiêu chuẩn rất khác nhau.

Tôi đặc biệt khuyến khích bạn đọc tài liệu FHS mà tôi đã liên kết ở trên nếu bạn muốn biết thêm về điều này.


1
Một trong số ít danh sách đạn mà tôi có thể muốn in ra dưới dạng một mánh gian lận ...
thích77

6
+1 cho /srv. Tôi đang tìm một nơi cho kho git của tôi và không thích nội dung Apache của tôi ở trong đó /var/www. /srvcó vẻ như là nơi hoàn hảo
Ông Hedgekey

@ Aphink, vậy tại sao nó được gọi varthay vì data?
Pacerier

@ Mr.Hedgehog, ý của bạn là "không thích" là gì? Quan tâm để giải thích?
Pacerier

@Pacerier Trở lại những năm 90, bạn sẽ được thông báo /varvì đó là "dữ liệu khác nhau". Trong những ngày đầu Unix được lưu trữ trên một ổ đĩa duy nhất. Khi chưa đủ, họ có một cái mới, gắn nó vào /usrvà di chuyển tất cả dữ liệu người dùng ở đó. Nhưng nó không đủ và ổ đĩa cũ đã đầy trở lại sớm. Vì vậy, họ đã di chuyển tất cả các nhị phân mà hệ thống có thể khởi động mà không cần từ /binđến /usr/bin. Họ chỉ đơn giản là hết không gian. Sau đó, họ cần chia sẻ dữ liệu giữa những người dùng để họ thực hiện /varvà sử dụng nó như một hộp thả. FHS có đầy đủ các quyết định kế thừa như thế và nên được thực hiện bằng một nhúm muối.
cprn

4

optlà viết tắt của phần mềm tùy chọn. varlà viết tắt của các tập tin hệ thống biến. Do đó, các ứng dụng của bạn nên đi đến /opt.


8
/vardành cho các tệp hệ thống khác nhau , không phải "khác nhau".
womble

4
/ var dành cho "tệp dữ liệu biến". Nói rằng nó cho "các tệp hệ thống khác nhau" là mơ hồ và có khả năng gây hiểu lầm. o_O Bạn nói đúng về "opt".
phoenix8

@Eduard, còn / opt / var thì sao? Và </ usr / var>, </ usr / local / var> ...
Pacerier

@womble Đó là từ nguyên sai. Đó là những gì FHS nói nhưng nó không đúng. Quay trở lại những năm 90, bạn sẽ được thông báo /varvì đó là "dữ liệu khác nhau". Tôi vẫn còn ghi chú từ một cuốn sách trước khi tôi đọc lại.
cprn

2

Nó phụ thuộc vào tiêu chuẩn địa phương của bạn là gì.

Cá nhân, tôi không cài đặt bất cứ thứ gì vào / var mà không có lý do chính đáng. My / usr / local hầu như luôn luôn là một nfs gắn kết với mạng, vì vậy mọi thứ không được đóng gói đều được cài đặt vào / opt.


1
Bạn sẽ đặt cái gì vào / var, ngoại trừ dữ liệu?
ℝaphink

1
thông thường các chương trình sẽ dính nội dung của riêng họ vào / var. Chủ yếu là do nhà cung cấp cung cấp - nhật ký, một số thư viện, tệp kiểm soát, tệp .pid, loại đó.
David Mackffy

2
Tôi không hoàn toàn đồng ý. Thư viện, nếu chúng là tĩnh, nên đi vào /usr. Libs được tạo tự động có thể kết thúc trong /var/libthỉnh thoảng, nhưng tôi không nhìn thấy những gì bạn thực sự sẽ cài đặt trong /var, từ quan điểm quản trị xem. Chương trình có thể sử dụng nó rộng rãi, nhưng nó sẽ khá trống trước khi bạn khởi chạy chương trình.
ℝaphink

1
Ngay bây giờ, thứ duy nhất tôi cố tình cài đặt vào / var là nfsen / nfdump, và đó là vì dấu chân của ứng dụng là tất cả các tệp nfdump mà nó tích lũy. (Và bởi vì đây là bản cài đặt thử nghiệm bằng cách nào đó đã đưa nó vào sản xuất. Vì vậy - "đối với người sử dụng không có lý do chính đáng".) Nhưng đó là khá nhiều. Tất nhiên vì tôi không phân vùng đĩa cứng của mình, / var, / opt và / usr đều nằm trên cùng một hệ thống tệp.
David Mackffy

1
Qmail cài đặt trong / var. Đây là một trong vô số những lời chỉ trích chống lại nó.
staticsan
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.