Để cập nhật yum? Hay không?


13

xin vui lòng tha thứ cho câu hỏi khá đơn giản này.

Trước hết, tôi không phải là một sysadmin và kinh nghiệm của tôi với Linux có phần hạn chế.

Khoảng 3-4 tháng trước, tôi đã thiết lập một máy chủ CentOS đang hoạt động, vì nhiều lý do. Chúng tôi đang sử dụng nó như một máy chủ phát triển cho các trang web (mà khách hàng của chúng tôi có quyền truy cập), máy chủ lật đổ và chúng tôi cũng đang lưu trữ một wiki trên đó để liên lạc nội bộ, vì vậy nó đã trở thành một công cụ quan trọng đối với chúng tôi. (Có lẽ quan trọng hơn chúng ta nghĩ khi tôi thiết lập nó!)

Tôi đã nhận thấy rằng Yum muốn cập nhật khoảng 250 gói lên các phiên bản mới nhất trong repo.

Vì máy chủ đang hoạt động tốt cho chúng tôi, tôi có nên mạo hiểm cập nhật các gói này không? Các rủi ro bảo mật có cao hơn rủi ro máy chủ bị phá vỡ khi tôi cập nhật mọi thứ không?

Tôi nên chỉ ra rằng trong khi tôi có bản sao lưu mọi thứ, sẽ mất thời gian để thiết lập mọi thứ theo cách hiện tại và tôi không có nhiều thời gian rảnh trong công việc vào lúc này!

Nếu lời khuyên là cập nhật, có bất kỳ thực hành tốt nhất nào có thể được truyền lại để làm cho quá trình này an toàn nhất có thể?

Cảm ơn trước cho tất cả lời khuyên.

CẬP NHẬT - Cảm ơn phản hồi của bạn tất cả mọi người. Nếu tôi có đủ đại diện để nâng cao tất cả mọi người, tôi sẽ làm thế. ;) Tôi đã quyết định ghost ổ cứng và cập nhật. Thật không may, việc nắm giữ một sysadmin toàn thời gian hoặc bán thời gian không phải là một lựa chọn vào lúc này, vì vậy tôi sẽ phải giải quyết vấn đề tốt nhất có thể!

Câu trả lời:


12

Giải pháp nhanh và bẩn (ví dụ: Quản trị viên chiến trường):

  1. Đưa hệ thống của bạn ngoại tuyến (tôi hy vọng bạn có thể) và thực hiện sao lưu NortonGhost (hoặc một cái gì đó tương tự) với ổ cứng thứ 2.

  2. Khởi động ổ đĩa cứng thứ 2 (để đảm bảo sao lưu của bạn thực sự hoạt động) và thực hiện cập nhật yum trên ổ đĩa THAT.

  3. Nếu tất cả đều hoạt động ... xin chúc mừng!

  4. Nếu nó làm hỏng thứ gì đó ... hãy tiếp tục và đặt vào ổ ORIGINAL của bạn và đưa ra "Kế hoạch B".

CẬP NHẬT:

Chỉ cần nghĩ rằng tôi đã đề cập rằng vấn đề thực sự ở đây là "Tôi có cập nhật waaaay của mình ra khỏi hệ thống ngày và có nguy cơ làm hỏng nó không?" hoặc "Tôi có để hệ thống làm việc hoàn toàn tốt của mình không bị lỗi và có nguy cơ bị hack / xâm nhập không?"

Câu trả lời là ... một khi bạn có được hệ thống của mình được vá thông qua các bước ở trên ... hãy thử và luôn đứng đầu nó bằng cách sao lưu thường xuyên VÀ vá nó thường xuyên.

Sau đó, bạn sẽ có tốt nhất của cả hai thế giới. ;-)


Niềm vui của tôi ... chúc may mắn với bản sao lưu / cập nhật của bạn. Một ghi chú bên lề, cá nhân tôi đã thực hiện các cập nhật yum trong CentOS khi có 200-300 cập nhật và nó vẫn ổn. NHƯNG ... Tôi cũng đã thực hiện các cập nhật trong đó nó hoàn toàn bị hỏng và tôi phải thực hiện các nghi thức voodoo / gà ngớ ngẩn (và rất nhiều câu lệnh tào lao) chỉ để mọi thứ hoạt động trở lại. Chúc các bạn cập nhật nhanh chóng và thành công. ;-)
KPWINC

10

Vâng, cập nhật.

RHEL (và do đó là CentOS) cẩn thận không cập nhật các phiên bản lên bất kỳ thứ gì không tương thích, thay vào đó chúng có lỗi sửa lỗi và sửa lỗi bảo mật, do đó, các thay đổi thực tế đối với các gói là tối thiểu và không có khả năng gây ra sự cố tương thích.

Nếu bất kỳ tệp cấu hình nào thay đổi, các gói sẽ cho bạn biết về tệp .rpmorig hoặc .rpmnew được tạo. Nó phụ thuộc vào cấu hình của chính RPM. Bạn có thể tìm kiếm các cảnh báo về bất kỳ thứ nào được tạo và đặt lại cấu hình cũ của bạn (" cp foo foo.bak; cp foo.rpmorig foo") hoặc xem các tệp .rpmnew và kết hợp mọi thay đổi vào cấu hình của bạn.

Vấn đề ít được chú ý hơn nếu bạn cập nhật thường xuyên.

Chúng tôi có rất nhiều hệ thống được cập nhật hàng quý (cứ sau 3 tháng); và rất hiếm khi thấy bất kỳ vấn đề từ các bản cập nhật gói. (ngoại trừ các hệ thống thực hiện những điều kỳ lạ để truy cập LUN từ SAN)


Tôi thích câu trả lời KPWINC hơn. Sao lưu trước. Ví dụ: httpd 2.2 đã được nâng cấp lên 2.4 và đột nhiên các tệp cấu hình không hoạt động nữa. Hoảng loạn và đội dev nhàn rỗi trong nhiều giờ cho đến khi vấn đề được chẩn đoán và khắc phục.
Jose Manuel Gomez Alvarez

Không nói về việc nâng cấp gói kernel, có khả năng phá vỡ khả năng khởi động của máy truy cập.redhat.com / document / en
Jose Manuel Gomez Alvarez

@Jose Manuel Gomez Alvarez - sao lưu đầu tiên luôn luôn tốt, nhưng nếu hệ thống của bạn chuyển từ http 2.2 sang 2.4, điều đó không phù hợp với câu hỏi này, CentOS không làm điều đó bao giờ.
freiheit

6

Mặc dù có, sẽ mất thời gian để nâng cấp, và trong cùng một trang viên, sẽ mất thời gian để khôi phục nếu có sự cố, sẽ đau đớn / đau khổ đến mức nào nếu dữ liệu trên hệ thống đó bị xóa thông qua khai thác / hack?

Đối với hầu hết các nâng cấp từ kho lưu trữ cơ sở của CentOS đều an toàn để cài đặt, Lần duy nhất tôi gặp sự cố cập nhật với CentOS là khi tôi bắt đầu / hoặc cần sử dụng kho lưu trữ bên ngoài (DAG, RPMForge, Ect ect ..)

Các tốt nhất cài đặt cho các loại hình điều là phải có một máy chủ hot-swappable sẵn sàng, vì vậy bạn có thể kiểm tra các bản cập nhật trên đó trước khi triển khai chúng đến máy chủ trực tiếp.


3

Âm thanh như bạn cần một quản trị viên hệ thống thực sự mất vài giờ để xem qua hệ thống của bạn, cập nhật nó và đảm bảo mọi thứ sẽ chạy lại. Lý tưởng nhất là bạn sẽ có người này đến và làm điều này cho bạn vài lần một tháng. Một máy chủ không phải là thứ cài đặt một lần và quên về nó; nó cần dịch vụ thường xuyên.


3

Nếu hệ thống này rất quan trọng, thì các bản cập nhật bảo mật sẽ trở nên quan trọng hơn. Hãy xem xét các hàm ý nếu hệ thống đó phải được gỡ xuống để xây dựng lại nếu (khi nào?) Một gói lỗi thời cho phép thỏa hiệp hệ thống. Lý tưởng nhất là bạn sẽ có một máy chủ thử nghiệm được cấu hình theo kiểu tương tự mà bạn có thể cập nhật trước và kiểm tra xem có gì bị hỏng không.

Khi bạn áp dụng các bản cập nhật, bạn cần đảm bảo một số điều:

  1. Thời gian cập nhật được công khai cho mọi người sử dụng hệ thống
  2. Bạn có kế hoạch về cách cập nhật và kiểm tra từng ứng dụng
  3. Bạn có kế hoạch làm thế nào để hoàn tác các bản cập nhật nếu (khi nào?) Bản cập nhật phá vỡ ứng dụng
  4. Và sao lưu hiện tại tồn tại trong trường hợp có gì đó thực sự sai

Một sysadmin tốt sẽ có kinh nghiệm trong loại công việc này, và dù sao cũng nên làm tất cả những việc đó. Nếu tổ chức của bạn có bất kỳ, thì đây có thể là thời gian để quản trị hệ thống trên chúng. Hoặc nếu bạn lo lắng khi tự làm việc này, thì hãy xem xét việc thuê ai đó theo hợp đồng để thực hiện loại bảo trì thường xuyên này. Dù bằng cách nào, các cập nhật cần phải xảy ra, vì bạn đang mở ra cho mình một tình huống tồi tệ hơn nhiều.


3

Đây là lý do tại sao ngày nay, tôi gần như không bao giờ chạy bất kỳ hệ thống sản xuất nào trên phần cứng thực sự. Tôi chạy chúng trong các máy ảo. Sau đó, trong thời gian ngừng hoạt động nhanh (5 phút), tôi chạy một ảnh chụp nhanh từ bên trong ESX hoặc nếu tôi đang sử dụng cài đặt Xen / Solaris / OpenVZ tùy chỉnh, tôi thực hiện một ảnh chụp nhanh LVM của hình ảnh máy chủ. Sau đó tôi khởi động lại bản gốc, và bây giờ tôi có một bản sao tôi có thể làm theo ý muốn.

Điều đó nói rằng, bắt đầu với việc cập nhật kernel và apache, và sau đó làm việc ngược từ đó. Bạn không cần phải lấy danh sách gói đầy đủ mà yum báo cáo, nhưng các vectơ tấn công hàng đầu sẽ là những vectơ bạn vá sớm nhất.

Bất cứ khi nào tôi có một hệ thống Linux bị hack, đó là vì tôi đã để lại apache, openssh hoặc hạt nhân chưa được vá.



2

Tôi đã có một thứ chính xác xuất hiện cách đây một năm hoặc lâu hơn ... Tôi đã thực hiện cập nhật yum trên hộp CentOS, chạy trên phần cứng của Dell và nó đã cài đặt một kernel không khởi động được. Chiếc hộp chưa có bất cứ thứ gì được tải trên đó (nếu không tôi sẽ thận trọng hơn). Đã dành rất nhiều thời gian để loay hoay với nó và dường như có một số sự không tương thích giữa các hạt nhân mới hơn của CentOS / Linux và hộp Dell đó. Hãy rất thận trọng với các cập nhật của bạn. Tôi vẫn khuyên bạn nên cập nhật vì đó là điều nên làm, nhưng hãy chuẩn bị để phục hồi từ hệ thống bị hỏng!


Tuyệt vời, nó là một hộp Dell!
John McCollum
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.