Najlepsze praktyki dotyczące aktualizowania wcześniej nieobsługiwanego serwera RHEL5.7

Nowy serwer RedHat EL5.6 został niedawno objęty moją opieką. Od razu widać, że przez ostatnie 12 miesięcy niewiele uwagi poświęcano jakimkolwiek aktualizacjom pakietów.

Zazwyczaj uważam, że jeśli nie jest zepsuty - nie naprawiaj go. Jednak po zarejestrowaniu serwera w RHN, a także użyciu wtyczki yum-security do sprawdzenia aktualizacji zabezpieczeń, dostępnych jest nieco ponad 1100 aktualizacji „zabezpieczeń”.

Czy ktoś miał podobną sytuację? Niechętnie aktualizuję wszystko, ponieważ lubię wiedzieć, co jest aktualizowane i czy może potencjalnie wpłynąć na wszystko, co działa na urządzeniu (jest to serwer produkcyjny). Wygląda jednak na to, że przestrzeganie tej praktyki wymagałoby ode mnie przejścia przez pakiet 1100 errata linia po linii. Czy istnieje bardziej wydajne rozwiązanie?

Mówiąc ogólnie, aktualizacje bezpieczeństwa są uważane za nieco bezpieczne, szczególnie w przypadku dystrybucji z celami takimi jak RedHat. Ich głównym celem jest stworzenie spójnego środowiska operacyjnego. W związku z tym opiekunowie wybierają wersje pakietów i trzymają się ich na dłuższą metę. Aby zobaczyć, co mam na myśli wygląd w wersji takich pakietów, takich jak kernel, python, perl, i httpd. To, co robią, to łatki bezpieczeństwa backport od wcześniejszych programistów. Jeśli więc zostanie wykryta luka w zabezpieczeniach dla wszystkich wersji Apache httpd 2.2.x, wówczas Apache Foundation może wydać wersję 2.2.40 z poprawką, ale RedHat rzuci łatkę lokalnie i wyda httpd-2.2.3-80z poprawką.

Pamiętaj również, że obecnie mówisz o systemie RHEL5.7, obecna wersja to 5.9. Niektórzy dostawcy oprogramowania obsługują tylko niektóre podwydania. Ostatnio natknąłem się na jedno oprogramowanie, na przykład, które według dostawcy działa tylko na wersji 5.4. To nie znaczy, że nie będzie działało na 5.9, ale może oznaczać, że nie zapewnią żadnego wsparcia, jeśli nie będzie działać.

Istnieją również obawy związane z dokonywaniem masowych aktualizacji systemu, który nie był łatany przez tak długi czas. Największy, z jakim się zetknąłem, to problem zarządzania konfiguracją, który może zostać zaostrzony przez duże aktualizacje. Czasami plik konfiguracyjny jest zmieniany, ale administrator nigdy nie uruchamia ponownie usługi. Oznacza to, że konfiguracja na dysku nigdy nie została przetestowana, a uruchomiona konfiguracja może już nie istnieć. Jeśli więc usługa zostanie zrestartowana, co nastąpi po zastosowaniu aktualizacji jądra, może ona nie zostać zrestartowana. Lub może działać inaczej po ponownym uruchomieniu.

Radzę, aby zrobić aktualizacje, ale bądź mądry.

• Zaplanuj to podczas okna konserwacji. Jeśli nic więcej nie będzie wymagać ponownego uruchomienia serwera, pojawiło się wiele aktualizacji jądra i będziesz musiał ponownie uruchomić komputer, aby je zastosować.
• Przed zrobieniem czegokolwiek wykonaj pełną kopię zapasową. Może to być migawka, jeśli jest to maszyna wirtualna, uruchamianie pełnej kopii zapasowej na dowolnym narzędziu, tarowanie /(do innego systemu), robienie ddzdjęcia dysków, cokolwiek. Tak długo, jak można coś przywrócić.
• Zaplanuj sposób stosowania aktualizacji. Nie chcesz po prostu rzucić yum update -yna to i odejść. Dla wszystkich dobrych rzeczy, które robi yum, nie porządkuje, gdy stosuje aktualizacje zgodnie z zależnościami. W przeszłości powodowało to problemy. Zawsze biegam yum clean all && yum update -y yum && yum update -y glibc && yum update. To zazwyczaj rozwiązuje większość potencjalnych problemów z zamówieniem.

Może to być również świetny czas na ponowne uruchomienie platformy. Mamy już RHEL6 od dłuższego czasu. W zależności od tego, co robi ten serwer, sensowne może być pozostawienie go tak, jak działa, podczas jednoczesnego uruchamiania nowej instancji. Następnie po zainstalowaniu możesz skopiować wszystkie dane, przetestować usługi i wykonać cięcie. Daje to również szansę, aby wiedzieć od podstaw, że system jest ustandaryzowany, czysty, dobrze udokumentowany i cały ten jazz.

Bez względu na to, co robisz, wydaje mi się, że bardzo ważne jest, aby przejść do obecnego systemu. Musisz tylko zrobić to w sposób, który pozwoli ci zaufać swojej pracy i gotowemu produktowi.

Z mojego doświadczenia wynika, że ​​RHEL nie narusza wstecznej kompatybilności w aktualizacjach tej samej wersji.

nie obejmie to jednak niczego, co zostało zainstalowane zewnętrznie na rpm.

Możesz użyć rpm -qfdo znalezienia plików, które podejrzewasz, że są kompilowane zewnętrznie, jeśli zwróci „nie należy do żadnego pakietu”, możesz mieć problemy z aktualizacją.

Zrobiłbym zdjęcie serwera i przeprowadziłbym aktualizację, jestem jednak trochę bardziej zainteresowany diabłem niż większość.