Lợi ích của /etc/apt/source.list.d so với /etc/apt/source.list

Tôi biết câu hỏi này đã được hỏi trước đây, nhưng tôi không chấp nhận câu trả lời, "bạn có thể thấy rõ các bổ sung tùy chỉnh". Khi tôi thêm ppa (mà tôi đã không thực hiện trong nhiều năm), tôi đã nhấn một phím trên bàn phím có nhãn "Enter" cho phép tôi thêm một dòng trống trước mục nhập mới (tôi thậm chí sẽ thêm một nhận xét giải thích, nhưng tôi là một nhà văn công nghệ, vì vậy ....). Tôi thích sự sources.confsạch sẽ và gọn gàng của tôi .

/etc/apt/sources.d

Có nghĩa là tôi có nửa tá tệp để phân tích thay vì chỉ một.

AFAIK, "hoàn toàn" không có lợi thế khi có một tệp cấu hình so với 6 (vì lý do tranh luận, có thể bạn có 3 hoặc thậm chí 2, không quan trọng ... 1 vẫn còn 2 nhịp).

Ai đó có thể vui lòng đưa ra một lợi thế hợp lý, "bạn có thể thấy rõ các bổ sung tùy chỉnh" là lý do của một người nghèo.

Tôi phải thêm, tôi thích thay đổi, tuy nhiên, CHỈ khi có những lợi ích được giới thiệu bởi sự thay đổi.

Chỉnh sửa sau phản hồi đầu tiên:

Nó cho phép cài đặt mới cần repos riêng của họ để không phải tìm kiếm một tệp phẳng để đảm bảo rằng nó không thêm các mục trùng lặp.

Bây giờ, họ phải tìm kiếm một thư mục cho dupe thay vì một tập tin phẳng. Trừ khi họ cho rằng quản trị viên không thay đổi mọi thứ ...

Nó cho phép người quản trị hệ thống dễ dàng vô hiệu hóa (bằng cách đổi tên) hoặc xóa (bằng cách xóa) bộ lưu trữ mà không phải chỉnh sửa tệp nguyên khối.

Quản trị viên phải tìm thư mục grep để tìm tệp thích hợp để đổi tên, trước đó, anh ta sẽ tìm kiếm MỘT tệp và nhận xét một dòng, một sed-liner cho "gần như" bất kỳ quản trị viên nào.

Nó cho phép một người bảo trì gói đưa ra một lệnh đơn giản để cập nhật vị trí kho lưu trữ mà không phải lo lắng về việc vô tình thay đổi cấu hình cho các kho lưu trữ không liên quan.

Tôi không hiểu điều này, tôi "giả sử" người bảo trì gói biết URL của kho lưu trữ của mình. Một lần nữa, có sedmột thư mục thay vì một tập tin.

Ở cấp độ kỹ thuật, như một người đã phải xử lý những thay đổi này trong một vài công cụ thông tin hệ thống lớn và phổ biến, về cơ bản, điều này dẫn đến điều này:

Đối với nguồn.list.d /

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

Lưu ý rằng trừ khi họ cũng đang thực hiện kiểm tra tương tự như dưới đây, nếu bạn đã nhận xét một dòng repo, các thử nghiệm này sẽ sai. Nếu họ đang thực hiện kiểm tra giống như bên dưới, thì đó là độ phức tạp chính xác như nhau, ngoại trừ được thực hiện trên nhiều tệp chứ không phải một tệp. Ngoài ra, trừ khi họ đang kiểm tra TẤT CẢ các tệp có thể, họ có thể và thường làm thêm một mục trùng lặp, sau đó sẽ khiến apt phàn nàn, cho đến khi bạn xóa một trong số chúng.

Đối với nguồn.list

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Các nhà phát triển Google Chrome đã không kiểm tra sự hiện diện của các nguồn Google Chrome, dựa vào tên tệp chính xác mà gói Chrome của họ sẽ tạo ra. Trong tất cả các trường hợp khác, họ sẽ tạo một tệp mới trong nguồn.list.d được đặt tên chính xác theo cách họ muốn.

Tất nhiên, để xem những nguồn nào bạn có, nó không đẹp lắm, vì bạn không thể dễ đọc và duy trì hơn:

cat /etc/sources.list

Vì vậy, điều này về cơ bản được thực hiện cho mục đích cập nhật tự động và để cung cấp các lệnh đơn dễ dàng mà bạn có thể cung cấp cho người dùng, theo như tôi có thể nói. Đối với người dùng, điều đó có nghĩa là họ phải đọc nhiều tệp thay vì 1 tệp để xem họ có thêm repo hay không, và đối với apt, điều đó có nghĩa là nó cũng phải đọc nhiều tệp thay vì một tệp.

Vì trong thế giới thực, nếu bạn định làm tốt điều này, bạn phải hỗ trợ kiểm tra tất cả các tệp, bất kể chúng được đặt tên là gì, và sau đó kiểm tra xem hành động được thực hiện có bắt buộc hay không bắt buộc.

Tuy nhiên, nếu bạn sẽ không làm tốt, bạn chỉ cần bỏ qua các kiểm tra để xem liệu mục đó có ở đâu đó trong nguồn không và chỉ kiểm tra tên tệp. Tôi tin rằng đó là những gì hầu hết các công cụ tự động làm, nhưng vì cuối cùng, tôi chỉ cần kiểm tra mọi thứ để tôi có thể liệt kê nó và hành động dựa trên nếu một trong những tệp đó khớp với nhau, kết quả thực sự duy nhất khiến nó phức tạp hơn rất nhiều.

Chỉnh sửa hàng loạt

Khi chạy nhiều máy chủ, tôi muốn thử kịch bản một công việc hàng đêm lặp lại /etc/apt/source.list.d/ và kiểm tra trước để đảm bảo mục đó không có trong nguồn.list, sau đó nếu nó là không, thêm mục đó vào nguồn.list, xóa tệp nguồn.list.d và nếu đã có trong nguồn.list, chỉ cần xóa tệp nguồn.list.d

Vì KHÔNG có tiêu cực khi chỉ sử dụng nguồn.list ngoài sự đơn giản và dễ bảo trì, nên thêm một cái gì đó như thế có thể không phải là ý tưởng tồi, đặc biệt được đưa ra bởi các quản trị viên ngẫu nhiên sáng tạo.

Như đã lưu ý trong nhận xét trên, inxi -r sẽ in ra gọn gàng trên mỗi tệp các repos đang hoạt động, nhưng tất nhiên sẽ không chỉnh sửa hoặc thay đổi chúng, do đó sẽ chỉ là một nửa giải pháp. Nếu đó là nhiều bản phân phối, thì thật khó để học cách mỗi người thực hiện nó, điều đó là chắc chắn, và sự ngẫu nhiên chắc chắn là quy tắc chứ không phải là ngoại lệ đáng buồn.

Có mỗi kho lưu trữ (hoặc bộ sưu tập các kho lưu trữ) trong tệp riêng giúp quản lý đơn giản hơn, cả bằng tay và lập trình:

• Nó cho phép cài đặt mới cần repos riêng của họ để không phải tìm kiếm một tệp phẳng để đảm bảo rằng nó không thêm các mục trùng lặp.
• Nó cho phép người quản trị hệ thống dễ dàng vô hiệu hóa (bằng cách đổi tên) hoặc xóa (bằng cách xóa) bộ lưu trữ mà không phải chỉnh sửa tệp nguyên khối.
• Nó cho phép một người bảo trì gói đưa ra một lệnh đơn giản để cập nhật vị trí kho lưu trữ mà không phải lo lắng về việc vô tình thay đổi cấu hình cho các kho lưu trữ không liên quan.

Nếu bạn tự quản lý máy chủ của mình, tôi sẽ đồng ý, điều đó sẽ khiến mọi thứ trở nên khó hiểu hơn. Tuy nhiên, nó mang lại lợi ích cho việc quản lý theo chương trình (tức là "cấu hình như mã"). Khi sử dụng phần mềm quản lý cấu hình như Puppet, Ansible, Chef, v.v., bạn chỉ cần thả hoặc xóa tệp trong thư mục và chạy apt update, thay vì phân tích tệp để thêm hoặc xóa một số dòng nhất định.

Đặc biệt là vì điều đó tránh việc phải quản lý nội dung của một tài nguyên 'tệp', ví dụ : /etc/apt/sources.list, từ nhiều mô-đun độc lập đã được viết bởi các bên thứ ba.

Tôi đánh giá cao việc sử dụng rộng rãi các thư mục ".d" của Ubuntu vì lý do cụ thể này, ví dụ như sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, v.v.

Như nemo đã chỉ ra trong một bình luận, một trong những lợi thế chính của một thư mục là nó cho phép khái niệm "quyền sở hữu".

Các bản phân phối và trình cài đặt Linux hiện đại đều dựa trên ý tưởng về các gói - các phần mềm độc lập có thể, càng nhiều càng tốt, được thêm vào và gỡ bỏ nguyên tử. Bất cứ khi nào bạn cài đặt một gói với dpkg(và do đó apt), nó sẽ theo dõi các tệp nào trên hệ thống được tạo bởi trình cài đặt đó. Gỡ cài đặt gói sau đó phần lớn có thể bao gồm xóa các tệp đó.

Các câu trả lời hiện đang chấp nhận mất nó như là một điều xấu mà một trình cài đặt Google Chrome cho rằng nó chỉ nên tạo hoặc xóa một mục trong vị trí nó mong đợi, nhưng tự động hoá bất cứ điều gì dẫn khác để tất cả các loại trường hợp cạnh khủng khiếp; ví dụ:

• Nếu dòng tồn tại trong sources.list khi cài đặt, nhưng được nhận xét, trình cài đặt sẽ bỏ ghi chú hoặc thêm một bản sao?
• Nếu trình gỡ cài đặt xóa dòng, nhưng người dùng đã thêm hoặc chỉnh sửa nhận xét bên cạnh, tệp sẽ bị bỏ lại với lời bình luận bị hỏng.
• Nếu người dùng thêm dòng thủ công, trình cài đặt có thể biết không thêm nó; nhưng làm thế nào để gỡ cài đặt biết không loại bỏ nó?

Các tập tin riêng biệt không cần thiết cho quyền sở hữu; chẳng hạn, trình cài đặt có thể bao gồm một khối các bình luận nói rằng nó "sở hữu" một tập hợp các dòng cụ thể. Trong trường hợp đó, nó sẽ luôn tìm kiếm tệp cho khối chính xác đó, không phải cho một số đề cập khác của cùng một kho lưu trữ.

Tất cả những thứ khác đều bằng nhau, tự động chỉnh sửa thành một tệp cấu hình duy nhất sẽ luôn phức tạp hơn so với tự động tạo và xóa một tệp riêng biệt. Ít nhất, việc loại bỏ các dòng yêu cầu sử dụng một số công cụ khớp mẫu nhưsed . Trong một tệp phức tạp hơn, cả việc thêm và xóa các dòng có thể yêu cầu một công cụ tạo tập lệnh có kiến ​​thức về định dạng tệp, để thêm vào một phần thích hợp hoặc xóa mà không làm hỏng định dạng xung quanh.

Vì trình cài đặt sẽ cần tránh làm rối với cấu hình được chỉnh sửa thủ công, nên đặt cấu hình tự động, sở hữu công cụ, theo định dạng dễ dàng cho các công cụ tự động quản lý.

Điều này cho phép các gói để thêm các nguồn bổ sung mà không cần dùng đến các tập lệnh.

Ví dụ: khi bạn cài đặt gói Skype của Microsoft, một nguồn cho skype.com sẽ tự động được định cấu hình để tải xuống các bản cập nhật; loại bỏ gói Skype khỏi hệ thống cũng vô hiệu hóa nguồn gói này một lần nữa.

Nếu bạn muốn có cùng hiệu ứng với một tệp phẳng, thì các tập lệnh cài đặt cho Skype sẽ cần phải sửa đổi nguồn của bạn. Danh sách mà có lẽ nhiều quản trị viên hệ thống sẽ thấy hơi khó coi.

Tôi không tin rằng có một lý do chính đáng - ngoài việc nó có vẻ thời trang. Đối với tôi, nó phá vỡ một quy tắc rằng một thư mục nên là một chiếc lá hoặc một nút - tức là nó chỉ nên chứa các tệp hoặc thư mục, không phải là một hỗn hợp của cả hai.

Tôi cho rằng nó làm cho các tệp nhỏ hơn, dễ đọc hơn - trong trường hợp quy tắc sudo, có thể khá dài, sẽ giúp dễ dàng có một bộ quy tắc chuẩn cho một loại người dùng (giả sử là nhà phát triển ) và thêm chúng vào thư mục cấu hình nếu các nhà phát triển nên được phép sudo trên máy này; do đó, bạn cần duy trì ít tệp hơn - chỉ là tệp cho nhà phát triển, cho quản trị viên, cho sysops, v.v., chứ không phải cho mọi kết hợp có thể có.

Ở đó, tôi đã mâu thuẫn với chính mình.