Bao lâu tôi nên cập nhật máy chủ Linux của chúng tôi?


56

Tôi chịu trách nhiệm quản lý cả máy chủ sản xuất của chúng tôi (thư, web, cơ sở dữ liệu đều nằm trên một máy chủ) và máy chủ thử nghiệm của chúng tôi. Cả hai đều được xây dựng trên Debian. Tuy nhiên, vì tôi rất mới với quản trị hệ thống, tôi chỉ cài đặt các bản cập nhật khi tôi gặp những thứ phải cập nhật để tôi có thể có các tính năng mới hơn và sửa lỗi. Đó là một quá trình ad hoc khá ngay bây giờ, và tôi muốn làm cho nó ít hơn như vậy.

Vì vậy, tôi tự hỏi làm thế nào những người biết những gì họ đang làm xử lý này? Bạn có thường xuyên thực hiện nâng cấp trên máy chủ của mình không? Là quá trình nâng cấp khác nhau giữa thử nghiệm và sản xuất? Bạn luôn luôn nâng cấp bất kỳ máy chủ thử nghiệm đầu tiên? Và bạn có cập nhật đầy đủ tất cả các phần mềm không, hay bạn chỉ cài đặt các bản cập nhật đã chọn?

Câu trả lời:


34

Tôi chạy apt-get update -qq; apt-get nâng cấp -duyq hàng ngày. Điều này sẽ kiểm tra các bản cập nhật, nhưng không tự động thực hiện chúng.

Sau đó, tôi có thể chạy các bản nâng cấp bằng tay trong khi tôi đang xem và có thể sửa bất cứ điều gì có thể sai.

Bên cạnh những lo ngại về bảo mật của việc duy trì một hệ thống được vá, tôi thấy rằng nếu tôi để nó quá lâu giữa các bản vá, tôi kết thúc với một loạt các gói muốn được nâng cấp, và điều đó làm tôi sợ hơn rất nhiều so với việc chỉ nâng cấp một hoặc hai mỗi tuần hoặc lâu hơn. Do đó, tôi có xu hướng chạy các bản nâng cấp hàng tuần hoặc nếu chúng có mức độ ưu tiên cao hàng ngày. Điều này có thêm lợi thế là biết gói nào đã phá vỡ hệ thống của bạn (nghĩa là nếu bạn chỉ nâng cấp một vài lần)

Tôi luôn nâng cấp các hệ thống ít quan trọng hơn trước. Tôi cũng có một "kế hoạch rollback" trong trường hợp tôi không thể sửa chữa hệ thống. (vì hầu hết các máy chủ của chúng tôi là ảo, kế hoạch khôi phục này thường bao gồm chụp ảnh trước khi nâng cấp mà tôi có thể hoàn nguyên nếu cần)

Điều đó đang được nói, tôi nghĩ rằng một bản nâng cấp đã phá vỡ thứ gì đó chỉ một hoặc hai lần trong 4 năm qua và đó là trên một hệ thống tùy biến cao - vì vậy bạn không cần phải quá hoang tưởng :)


4
Tôi làm việc rất chăm chỉ để chạm vào mỗi máy chủ cứ sau 30 ngày. Tôi có hơn 80 máy chủ tại thời điểm này. Tôi làm chúng theo lô theo nhóm chức năng hoặc theo hệ điều hành.
Thomas Denton

2
Chúng tôi có một tập lệnh cron chạy tương đương với các hộp SLES / OpenSuSE của chúng tôi hàng đêm; khi nhận thấy cần gói, nó sẽ gửi một vé đến hàng đợi quản trị hệ thống trong hệ thống vé rắc rối của chúng tôi. (Nó theo dõi những cái mà nó đã gửi trước đó trong một tệp trong / tmp để nó không spam hàng đợi.)
Karl Katzke

4
Debian có hai gói, apticron và cron-apt, hoạt động tương tự và gửi email cho bạn nếu có bất kỳ bản cập nhật nào. IME, apticron có lợi thế bằng cách gửi email cho bạn thay đổi để bạn có thể thấy những gì đã thay đổi.
David Pashley


6

Giả sử bạn đang chạy bản phát hành ổn định của Debian, hầu hết các bản vá sẽ liên quan đến bảo mật hoặc lỗi, điều đó có nghĩa là sẽ không có quá nhiều thay đổi lớn giữa các phiên bản của bất kỳ gói nào. Theo các bản vá chính sách bản vá debian cũng nên được thử nghiệm một thời gian trước khi được người bảo trì chuyển đến nhánh ổn định. Rõ ràng Điều này sẽ không ngừng vỡ khi vá nhưng nên ngăn chặn chúng trong hầu hết các trường hợp.

Sẽ là khôn ngoan để đảm bảo rằng máy chủ thử nghiệm của bạn được cập nhật và mọi gói có lỗi ảnh hưởng đến bạn và máy chủ của bạn phải được cập nhật. Tất cả các gói có tư vấn bảo mật chống lại chúng nên được cập nhật ngay khi bạn biết bản vá ổn định.

Debian thường là một hệ điều hành rất ổn định và không phải là một hệ điều hành mà bạn nên quá quan tâm đến các sự cố, tuy nhiên hãy luôn đọc những gì sẽ được cập nhật trước khi nó được cập nhật và để mắt đến bất cứ điều gì có vẻ lạ. Tôi cũng sử dụng VCS trên / etc / dir của mình để đảm bảo rằng mọi thay đổi tệp cấu hình đều có thể được nhìn thấy bằng lệnh 'git diff'.


3

Tôi chạy khô (đầu tiên) để xem những gì sẽ được cập nhật. Đôi khi, các thư viện (cho phép gọi nó là libfoo cho ví dụ này) thay đổi API của họ, điều này phá vỡ các chương trình mà chúng tôi tự viết / cài đặt. Nếu một số thư viện quan trọng được cập nhật, tôi lấy nguồn và thử xây dựng lại công cụ của chúng tôi trước khi cập nhật.

Tôi cũng kiểm tra xem chúng tôi sẽ không chuyển sang phiên bản trung gian của một số dịch vụ công cộng, ví dụ như apache, v.v. Tôi thà ở lại một năm và không gặp phải sự cố ngẫu nhiên, trừ khi cập nhật là quan trọng.

Nếu bạn là quản trị viên hệ thống, bạn nên lấy nguồn cấp RSS từ các trang web như Secunia , điều này sẽ cho bạn biết trước nếu bản phân phối của bạn sẽ được đẩy một số bản vá.

Đừng bao giờ, chỉ cần nâng cấp / cập nhật một cách mù quáng. Thật không may, nhiệm vụ để biết những gì bị hỏng thuộc về bạn, không phải người quản lý gói distro của bạn, đặc biệt nếu hệ thống của bạn hỗ trợ các lập trình viên.


2

Ở nơi tôi làm việc, chúng tôi có một quy trình khá rộng bao gồm sử dụng phần mềm có tên PatchLink để thông báo cho chúng tôi về các cập nhật liên quan đến bảo mật quan trọng nhất và chúng tôi áp dụng chúng sau khi thử nghiệm, trên cơ sở gói. Chúng tôi có hàng ngàn máy chủ mặc dù.

Nếu bạn chỉ có hai máy chủ thì quá trình sẽ đơn giản hơn nhiều. Mặc dù tôi không nghĩ thực hiện "cập nhật / nâng cấp apt-get" là cách tốt nhất của bạn.

Tôi sẽ theo dõi các bản vá cho phần mềm bạn đang chạy và đưa ra quyết định dựa trên các bản sửa lỗi trong các bản phát hành đó khi nào cần nâng cấp.

Vì bạn có một máy chủ thử nghiệm, rõ ràng, luôn luôn kiểm tra bản cập nhật trước khi áp dụng chúng.


2

Cập nhật thủ công là tốt nhất như được đề cập ở đây theo nghĩa bạn có thể thấy những gì đang xảy ra. Tuy nhiên, đối với số lượng lớn máy chủ có thể trở nên không thực tế. Chạy khô là một thông lệ tiêu chuẩn, trên thực tế, hầu hết các nhà quản lý gói sẽ hỏi bạn trước khi tiếp tục.

Cập nhật thường xuyên có xu hướng là tốt nhất mặc dù nó có thể là một chút của một hành động cân bằng. Cập nhật thường xuyên có nghĩa là ít hơn trong một lần và ít sai sót cùng một lúc. Nếu mọi thứ đi sai, có ít ứng cử viên để kiểm tra. Các gói cũng tốt hơn một chút khi cập nhật theo các bước nhỏ hơn, vì thông thường khi lập trình viên cập nhật họ đang tìm kiếm từ phiên bản cuối cùng sang phiên bản tiếp theo, liệu họ có chú ý gì ngoài phiên bản trước có thể thay đổi hay không, mặc dù điều này có xu hướng quan trọng chủ yếu là cho phần mềm đang phát triển nhanh chóng.

Không phải tất cả các cập nhật là không phá vỡ. Bạn sẽ muốn coi chừng này. Một số sẽ khởi động lại dịch vụ dẫn đến thời gian xuống.

Trong một thiết lập lý tưởng, bạn có thể có những điều sau đây:

  • Một phương tiện của các máy chủ chuyển đổi dường như (A / B hoặc tick tock). Điều này có nghĩa là bạn cập nhật một cái trong khi trên băng ghế dự bị, sau đó chỉ cần trao đổi lưu lượng truy cập từ cái hiện tại sang cái mới. Điều này có thể phức tạp hơn đối với các dịch vụ như cơ sở dữ liệu.
  • Khả năng kiểm tra cập nhật. Bạn nên có các máy chủ thử nghiệm thực tế là nhân bản sản xuất (nhưng không kết nối với bất kỳ dịch vụ sản xuất nào). Những thứ này sẽ cho phép bạn kiểm tra cập nhật trước.
  • Một chiến lược sao lưu tốt, gia tăng là lý tưởng. Bạn không bao giờ biết. Luôn luôn tốt hơn để được an toàn hơn xin lỗi.
  • Hãy nhận biết thời điểm nào có nhiều hoạt động nhất và mức độ thời gian chết nào có thể chấp nhận được.
  • Biết cách khôi phục một bản cập nhật hoặc một gói cụ thể.
  • Có gương gói riêng của bạn để cập nhật phù hợp và có thể dự đoán trên các máy chủ. Đây là bước đầu tiên hướng tới một hệ thống không giám sát tốt mà bạn có thể tin tưởng. Điều đó có nghĩa là bạn có thể cập nhật máy nhân bản, chạy cập nhật trên một hoặc nhiều máy kiểm tra sau đó nếu điều đó tốt hãy để nó tự động tắt. Tôi đã có một thời gian tuyệt vời với việc quản lý khéo léo khoảng 800 máy EPOS.
  • Một mức độ nhất quán tốt để bạn có thể biết rằng nếu một cái gì đó sẽ hoạt động ở đây, nó sẽ hoạt động ở đó.

Một số trong số này có thể là quá mức cần thiết ở các mức độ khác nhau cho các thiết lập nhỏ nhưng nên được ghi nhớ.

Nói chung, các bản cập nhật thường tương đối không gây đau đớn cho các bản phân phối máy chủ. Điều này là do họ gần như luôn luôn chỉ sửa lỗi và cập nhật bảo mật. Tuy nhiên, bạn có thể gặp sự cố nếu mọi người đã làm những điều kỳ lạ cho hệ thống hoặc bạn thêm các nguồn gói bổ sung.

Mặc dù nó hiếm ở mức độ vừa phải, đôi khi chúng vẫn mắc lỗi và phá vỡ tính tương thích giữa các phiên bản gói nhỏ.


1

Tôi thích cron-apt để tự động hóa quá trình này, nhưng như @dinomite đã chỉ ra một câu hỏi khác liên quan đến các bản cập nhật, cấu hình nó cụ thể để tự động hóa các cập nhật liên quan đến bảo mật là một ý tưởng rất thông minh - sau đó bạn có thể cập nhật thủ công những gì bạn cần. Tôi đã sử dụng cron-apt cho tất cả các bản cập nhật nhưng thực sự đã thay đổi điều này dựa trên câu trả lời của anh ấy. Nếu bạn thích nó, có lẽ bạn nên bỏ phiếu cho câu trả lời của anh ấy hơn là câu trả lời này.


1

Trên debian tôi cài đặt cron-apt và chỉnh sửa tập tin cấu hình của nó để gửi thư cho tôi nếu có bất kỳ thay đổi nào. Bằng cách này, tôi nhận được thông báo nếu có bản cập nhật cho hệ thống của mình và thực hiện cập nhật bằng tay


1

Dọc theo các dòng giống như cron-apt, bạn nên xem gói nâng cấp không giám sát http://packages.debian.org/lenny/unattends-upgrades .

Nó rất dễ dàng để cấu hình và sẽ cho phép bạn tải xuống và áp dụng các bản cập nhật bảo mật tự động nhưng để lại các bản cập nhật khác để nâng cấp thủ công (hoặc theo ý của bạn nâng cấp mọi thứ!).

Hướng dẫn máy chủ Ubuntu chính thức, có phần chi tiết hợp lý bao gồm việc sử dụng gói nâng cấp không giám sát https://help.ubfox.com/9.04/serverguide/C/automatic-updates.html

Lưu ý: tùy thuộc vào mức độ thận trọng / hoang tưởng của bạn, trước tiên bạn có thể nâng cấp trên một nhóm máy chủ thử nghiệm, sau đó nếu không có vấn đề gì, hãy cho phép các hộp sản xuất của bạn cập nhật, mặc dù cá nhân tôi không gặp phải rắc rối nào với các cập nhật bảo mật tàn phá cho đến nay (gõ vào gỗ) ...

Ngoài ra còn có một tùy chọn cấu hình để gửi cho bạn kết quả của mỗi bản cập nhật bảo mật, sau khi được áp dụng. Ngoài ra, nếu có bất kỳ hộp thoại hoặc lời nhắc tương tác nào được trình bày trong quá trình cập nhật, những lời nhắc sẽ cần điều chỉnh thủ công bởi một sysadmin, nó cũng sẽ đề cập đến những điều này.


1

Cá nhân tôi tắt cập nhật tự động và không thường xuyên thực hiện bất kỳ loại cập nhật gói nào trên máy chủ trong môi trường của mình, trừ khi: (a) có một lời khuyên CERT quan trọng cho một trong các gói trên hệ thống của tôi; (b) Tôi cần nâng cấp các gói riêng lẻ vì những lý do cụ thể; (c) Hệ điều hành hoặc gói đang đến cuối chu kỳ, chúng sẽ không được hỗ trợ nữa và chúng tôi cần tiếp tục có hỗ trợ. Lý do của tôi là nâng cấp mà không biết những gì đang thay đổi hoặc tại sao để lại quá nhiều chỗ cho một cái gì đó bị phá vỡ. Tôi đã làm những việc như thế này trong 14 năm và nó hoạt động tốt.


0

Bên cạnh những thứ được đề cập, bạn nên sử dụng một số loại công cụ giám sát (Nagios hoặc bất cứ thứ gì nổi lên thuyền của bạn) để cảnh báo bạn về các cập nhật.

Theo như mức độ thường xuyên: Ngay khi có bản cập nhật!

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.