Tự động cập nhật yum nâng cấp để giữ an toàn cho máy chủ - ưu và nhược điểm?


8

Tôi đang xem xét việc thêm một cronjob chạy yum -qy updatethường xuyên trên một số máy không được bảo trì thường xuyên. Mục tiêu sẽ là giữ cho các máy được cập nhật liên quan đến các bản vá bảo mật nếu không sẽ được áp dụng quá muộn. Tôi chỉ sử dụng kho cơ sở của CentOS.

Câu hỏi:

  • Theo kinh nghiệm của bạn - cách tiếp cận này "an toàn" sẽ như thế nào? Thỉnh thoảng tôi có nên cập nhật thất bại không? Khoảng cách thường xuyên phương pháp này sẽ yêu cầu khởi động lại?
  • Ưu / nhược điểm hoặc các vấn đề khác với phương pháp này?
  • Làm thế nào để bạn giữ cho máy của bạn cập nhật bằng cách sử dụng tự động hóa?

2
thay thế yum -qy bằng: / usr / bin / yum -R 120 -e 0 -d 0 -y cập nhật yum VÀ / usr / bin / yum -R 10 -e 0 -d 0 -y cập nhật
Adam Benayoun

Adam: Cảm ơn lời đề nghị của bạn. Bạn có thể giải thích tại sao điều đó là tốt hơn?
knorv

1
Đầu tiên bạn cập nhật yum sau đó bạn cập nhật các gói, -R có nghĩa là nó cho thời gian chờ lệnh tối đa, nghĩa là nó sẽ không hết thời gian nếu tôi đúng. -e và -d chỉ là mức độ lỗi / gỡ lỗi
Adam Benayoun

Tôi không chắc chắn về "-R [thời gian tính bằng phút]" - "đặt lượng thời gian tối đa yum sẽ đợi trước khi thực hiện lệnh - nó ngẫu nhiên theo thời gian". Có vẻ như yum sẽ đợi rand () * phút trước khi ra lệnh? Như vậy có tốt không :-)
knorv

Câu trả lời:


6

Nó phụ thuộc

Theo kinh nghiệm của tôi với CentOS, nó khá an toàn vì bạn chỉ sử dụng kho cơ sở của CentOS.

Bạn có nên mong đợi các bản cập nhật thất bại thỉnh thoảng ... có ... ở cùng một mức độ mà bạn sẽ mong đợi một ổ cứng bị lỗi hoặc CPU bị lỗi một lần trong một thời gian. Bạn không bao giờ có thể có quá nhiều bản sao lưu. :-)

Điều hay ho về cập nhật tự động là bạn được vá (và do đó an toàn hơn) nhanh hơn so với thực hiện thủ công.

Các bản vá thủ công dường như luôn bị đẩy ra hoặc bị coi là "mức độ ưu tiên thấp" đối với rất nhiều thứ khác vì vậy nếu bạn sẽ chuyển sang chế độ thủ công LỊCH THỜI GIAN TRÊN LỊCH CỦA BẠN để làm điều đó.

Tôi đã cấu hình nhiều máy để thực hiện tự động udpates (thông qua công việc định kỳ) và hiếm khi gặp sự cố. Trên thực tế, tôi không nhớ là đã từng có vấn đề với kho BASE. Mọi vấn đề tôi có thể nghĩ ra (ngoài đỉnh đầu, theo kinh nghiệm của tôi) luôn là tình huống của bên thứ 3.

Điều đó đang được nói ... Tôi có một số máy mà tôi THỰC SỰ làm các bản cập nhật cho. Những thứ như máy chủ cơ sở dữ liệu và các hệ thống quan trọng TUYỆT VỜI khác mà tôi muốn có cách tiếp cận "thực hành".

Cách mà cá nhân tôi đã tìm ra nó là như thế này ... Tôi nghĩ về kịch bản "chuyện gì xảy ra" và sau đó cố gắng nghĩ xem sẽ mất bao lâu để xây dựng lại hoặc khôi phục từ bản sao lưu và điều gì (nếu có) sẽ bị mất .

Trong trường hợp có nhiều máy chủ web ... hoặc máy chủ có nội dung không thay đổi nhiều ... Tôi tiếp tục và tự động cập nhật vì lượng thời gian để xây dựng lại / khôi phục là tối thiểu.

Trong trường hợp các máy chủ cơ sở dữ liệu quan trọng, v.v ... Tôi lên lịch thời gian mỗi tuần một lần để xem chúng và vá chúng theo cách thủ công ... vì thời gian để xây dựng lại / khôi phục tốn nhiều thời gian hơn.

Tùy thuộc vào những máy chủ BẠN có trong mạng của bạn và cách thực hiện kế hoạch sao lưu / phục hồi của bạn, các quyết định của bạn có thể khác nhau.

Hi vọng điêu nay co ich.


6

Pro : Máy chủ của bạn luôn ở mức vá lỗi mới nhất, thường là thậm chí chống lại các khai thác 0 ngày.

Con : Bất kỳ mã nào chạy trên máy chủ của bạn sử dụng các tính năng bị xóa trong các phiên bản mới hơn, mọi tệp cấu hình thay đổi cú pháp và bất kỳ "tính năng" bảo mật mới nào ngăn chặn việc thực thi mã có thể bị khai thác đều có thể khiến mọi thứ chạy trên máy chủ đó bị hỏng mà không có bạn biết về nó cho đến khi ai đó gọi bạn với một vấn đề.

Thực hành tốt nhất: Yêu cầu máy chủ gửi email cho bạn khi cần cập nhật. Sao lưu hoặc biết làm thế nào để cập nhật lại.


+1 - Tôi thực sự khuyên bạn nên đăng ký vào danh sách gửi thư của centos, họ làm rất tốt trong việc đưa ra các thông báo về các bản vá và ưu tiên trước khi được đẩy vào kho lưu trữ.
Adam Benayoun

3
Theo định nghĩa, không có bản vá nào chống lại việc khai thác 0 ngày. Khai thác 0 ngày là một khai thác mà chưa có bản vá nào.
MarkR

Tôi coi 0 ngày là ngày nó được phát hiện / khai thác / công bố và Redhat thường vá các lỗ hổng nghiêm trọng trong vài giờ - điều trùng hợp là vẫn còn trong ngày nó được phát hiện.
Karl Katzke

2

Trên hết những gì mọi người nói ở đây, tôi khuyên bạn nên đăng ký vào danh sách gửi thư của centos, họ luôn đăng email về các bản vá và các ưu tiên của họ ngay trước khi họ đẩy chúng vào kho lưu trữ. Thật hữu ích khi biết trước những gói cần được nâng cấp.

Thiết lập của tôi là cho phép yum tự động cập nhật hệ thống mỗi ngày một lần, tôi làm cho yum gửi cho tôi một thư với các gói được cài đặt hoặc nâng cấp ngay sau đó. Tôi cũng nhận được thư khi yum có xung đột và cần can thiệp thủ công (cứ sau 4 giờ).

Cho đến bây giờ, mọi thứ đều hoạt động trơn tru (trong hơn 4 năm nay), lần duy nhất tôi bị bắt phạm tội là khi yum nâng cấp kernel thông thường (tôi đã ảo hóa máy chủ của mình) và thay đổi grub và đẩy kernel thông thường làm mặc định, 2 tuần sau đó trong quá trình bảo trì, hệ thống của tôi đã được khởi động lại và tất cả các máy chủ ảo của tôi đã biến mất trong vài phút cho đến khi tôi phải can thiệp bằng tay.

Ngoài ra, tôi không thực sự có vấn đề gì.


1

miễn là bạn không có bất kỳ gói tùy chỉnh nào và chỉ sử dụng kho cơ sở từ CentOS, thì nó khá an toàn.

Ngoài ra, một cách tốt hơn để đạt được điều này sẽ là sử dụng yum-Updatesd với do_update = yesbộ.


1
Dịch vụ yum-Updatesd chưa đủ trưởng thành cho môi trường doanh nghiệp và dịch vụ có thể giới thiệu chi phí không cần thiết. Tôi sẽ sử dụng: / usr / bin / yum -R 120 -e 0 -d 0 -y update yum AND / usr / bin / yum -R 10 -e 0 -d 0 -y update
Adam Benayoun

0

Tôi cho rằng miễn là bạn có bản sao lưu tự động thì sẽ không quá lo lắng, miễn là bạn có thể sống với thời gian chết của máy chủ.

Tôi đã không thử điều này; Tôi sẽ không muốn cá nhân bởi vì có một rủi ro đáng kể trong việc phá vỡ một cái gì đó hoặc có một vấn đề mơ hồ bất thường được đưa ra vì một sửa chữa ngược dòng. Thậm chí còn tệ hơn nếu đây là một máy chủ hiếm khi được chú ý vì vậy nếu có sự cố xảy ra, bạn có thể không biết về nó.

Nếu bạn có thể sống với máy chủ bị nghi ngờ trong một khoảng thời gian nếu / khi có sự cố xảy ra và bạn có kế hoạch phản hồi để khôi phục hệ thống về trạng thái trước đó cũng như hệ thống gửi cho bạn các cập nhật qua nhật ký hoặc email báo cáo khi nào và những gì đã được cập nhật (để bạn biết nó không ở trạng thái bị kẹt hoặc chờ trả lời cho nội dung cần can thiệp) thì bạn có thể dùng thử. Nếu đó là một máy chủ quan trọng hoặc một cái gì đó quan trọng ... Tôi không muốn mạo hiểm.

Máy chủ của tôi không phải của bạn mặc dù :-)

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.