Jak często powinienem aktualizować nasz serwer Linux?

Jestem odpowiedzialny za zarządzanie zarówno naszym serwerem produkcyjnym (poczta, sieć, baza danych są na jednym serwerze), jak i naszym serwerem testowym. Oba są oparte na Debianie. Ponieważ jednak jestem nowy w administrowaniu systemem, instaluję aktualizacje tylko wtedy, gdy natrafiam na rzeczy, które należy zaktualizować, aby móc korzystać z nowszych funkcji i otrzymywać poprawki błędów. W tej chwili jest to dość ad hoc proces, a chciałbym, aby było mniej.

Zastanawiam się więc, jak ludzie, którzy wiedzą, co robią, radzą sobie z tym? Jak często przeprowadzasz aktualizacje na swoich serwerach? Czy proces aktualizacji różni się między testem a produkcją? Czy zawsze najpierw aktualizujesz jakieś serwery testowe? Czy wykonujesz pełną aktualizację całego oprogramowania, czy tylko instalujesz wybrane aktualizacje?

Uruchomić apt-get update -qq; apt-get upgrade -duyq codziennie. Spowoduje to sprawdzenie aktualizacji, ale nie zrobi ich automatycznie.

Następnie mogę uruchomić aktualizacje ręcznie podczas oglądania i mogę naprawić wszystko, co może pójść nie tak.

Oprócz obaw związanych z utrzymywaniem łatanego systemu, stwierdzam, że jeśli pozostawię go zbyt długo między łatami, otrzymam całą masę pakietów, które chcą zostać zaktualizowane, a to przeraża mnie o wiele bardziej niż tylko aktualizacja jednego lub mniej więcej dwa razy w tygodniu. Dlatego staram się uruchamiać moje aktualizacje co tydzień lub, jeśli mają one wysoki priorytet, codziennie. Ma to tę dodatkową zaletę, że wiesz, który pakiet zepsuł system (tj. Jeśli aktualizujesz tylko kilka naraz)

Zawsze najpierw aktualizuję mniej krytyczne systemy. Mam też „plan wycofania” na wypadek, gdy nie mogę naprawić systemu. (ponieważ większość naszych serwerów jest wirtualnych, ten plan wycofania zwykle polega na zrobieniu migawki przed aktualizacją, do której mogę przywrócić w razie potrzeby)

Biorąc to pod uwagę, myślę, że aktualizacja w ciągu ostatnich 4 lat zepsuła coś tylko raz lub dwa razy, i to było na wysoce spersonalizowanym systemie - więc nie musisz być zbyt paranoikiem :)

Oprócz poprzednich odpowiedzi - kilka bardziej szczegółowych kwestii związanych z Debianem: powinieneś zasubskrybować debian-security-announce i debian-announce i / lub zajrzeć na stronę Debian Security .

Zakładając, że używasz stabilnej wersji Debiana, większość łatek będzie związana z bezpieczeństwem lub błędami, co powinno oznaczać, że nie będzie zbyt wielu poważnych zmian między wersjami danego pakietu. Zgodnie z łatką debian łatki powinny również być w fazie testowania przez pewien czas, zanim opiekun przeniesie je do gałęzi stabilnej. Oczywiście nie zatrzyma to pęknięć podczas łatania, ale w większości przypadków powinno im zapobiec.

Rozsądnie byłoby upewnić się, że serwer testowy jest aktualizowany, a wszelkie pakiety, które zawierają błędy wpływające na Ciebie i Twoje serwery, powinny być aktualizowane. Wszystkie pakiety zawierające zalecenia bezpieczeństwa powinny zostać zaktualizowane, gdy tylko dowiesz się, że łatka jest stabilna.

Debian jest zwykle bardzo stabilnym systemem operacyjnym i nie należy go zbytnio przejmować awariami, jednak zawsze czytaj to, co zostanie zaktualizowane, zanim zostanie zaktualizowane i miej oko na wszystko, co wydaje się dziwne. Używam VCS również na moim / etc / dir, aby upewnić się, że wszelkie zmiany w pliku konfiguracyjnym można zobaczyć za pomocą polecenia „git diff”.

Robię próbę (najpierw), aby zobaczyć, co będzie aktualizowane. Czasami biblioteki (w tym przykładzie nazywamy to libfoo) zmieniają API, co psuje programy, które sami napisaliśmy / zainstalowaliśmy. Jeśli jakaś krytyczna biblioteka zostanie zaktualizowana, chwytam źródło i próbuję odbudować nasze rzeczy przed aktualizacją.

Sprawdzam również, czy nie przeskakujemy do pośredniej wersji jakiejś usługi publicznej, tj. Apache itp. Wolę pozostać o rok z tyłu i nie spotkać przypadkowego zepsucia, chyba że aktualizacja jest krytyczna.

Jeśli jesteś administratorem systemu, powinieneś pobierać kanały RSS z witryn takich jak Secunia , co powinno dać ci znać z wyprzedzeniem, jeśli twoja dystrybucja będzie publikować niektóre łatki.

Nigdy, nigdy, tylko ślepo aktualizuj / aktualizuj. Niestety zadanie polegające na tym, aby dowiedzieć się, co jest zepsute, spoczywa na tobie, a nie na menedżerze pakietów dystrybucyjnych, szczególnie jeśli twoje systemy obsługują programistów.

Tam, gdzie pracuję, mamy dość obszerny proces, który polega na użyciu oprogramowania o nazwie PatchLink do powiadamiania nas o najważniejszych aktualizacjach związanych z bezpieczeństwem i stosujemy je po testach, w zależności od pakietu. Mamy jednak tysiące serwerów.

Jeśli masz tylko dwa serwery, proces ten powinien być znacznie prostszy. Chociaż nie sądzę, aby wykonanie „apt-get update / upgrade” było najlepszym wyborem.

Chciałbym monitorować łatki dla uruchomionego oprogramowania i podejmować decyzje na podstawie poprawek w tych wydaniach, kiedy należy dokonać aktualizacji.

Ponieważ masz serwer testowy, oczywiście zawsze testuj aktualizację przed jej zastosowaniem.

Ręczne aktualizacje są najlepsze, jak wspomniano tutaj, w tym sensie, że można zobaczyć, co się dzieje. Jednak w przypadku bardzo dużej liczby serwerów, które mogą stać się niepraktyczne. Dry run jest standardową praktyką, w rzeczywistości większość menedżerów paczek zapyta cię przed kontynuowaniem.

Regularna aktualizacja jest zwykle najlepsza, choć może być trochę równoważąca. Częste aktualizacje oznaczają mniej za jednym razem, a mniej popełniają błędy na raz. Jeśli coś pójdzie nie tak, jest mniej kandydatów do sprawdzenia. Pakiety są również nieco lepsze w aktualizowaniu w mniejszych krokach, ponieważ ogólnie, gdy aktualizacje programisty patrzą na przejście od ostatniej wersji do następnej, to czy będą zwracać uwagę poza ostatnią wersją, mogą się różnić, chociaż ma to zwykle znaczenie głównie dla szybko ewoluującego oprogramowania.

Nie wszystkie aktualizacje nie powodują zakłóceń. Musisz na to uważać. Niektóre zrestartują usługi prowadzące do przestojów.

W idealnej konfiguracji możesz mieć następujące elementy:

• Sposób pozornie zmieniającego serwery (A / B lub tik tak). Oznacza to, że aktualizujesz jeden, gdy jest on na ławce, a następnie po prostu zamieniasz ruch z obecnego na nowy. Może to być bardziej skomplikowane w przypadku usług takich jak bazy danych.
• Możliwość testowania aktualizacji. Powinieneś mieć serwery testowe, które są praktycznie klonami produkcji (ale bez łączenia się z żadnymi usługami produkcyjnymi). Umożliwi to najpierw przetestowanie aktualizacji.
• Dobra strategia tworzenia kopii zapasowych, przyrostowa jest idealna. Nigdy nie wiesz. Zawsze lepiej być bezpiecznym niż żałować.
• Pamiętaj, które czasy mają największą aktywność i jaki poziom przestojów jest dopuszczalny.
• Dowiedz się, jak wycofać aktualizację lub określony pakiet.
• Posiadaj własne kopie lustrzane, aby aktualizacje były spójne i przewidywalne na różnych serwerach. To pierwszy krok w kierunku przyzwoitego nienadzorowanego systemu, któremu można zaufać. Oznacza to, że możesz zaktualizować kopię lustrzaną, uruchomić aktualizację na co najmniej jednej maszynie testowej, a jeśli to dobrze, pozwól jej automatycznie wyjść. Świetnie się bawiłem z trafnym zarządzaniem około 800 maszynami EPOS.
• Dobry poziom spójności, abyś mógł wiedzieć, że jeśli coś tu zadziała, będzie działać.

Niektóre z nich mogą być przesadzone w różnym stopniu w przypadku małych konfiguracji, ale należy o tym pamiętać.

Ogólnie rzecz biorąc, aktualizacje są zwykle stosunkowo bezbolesne dla dystrybucji serwerów. Wynika to z tego, że prawie zawsze trzymają się tylko poprawek błędów i aktualizacji bezpieczeństwa. Możesz jednak mieć problemy, jeśli ludzie zrobili dziwne rzeczy w systemie lub dodasz dodatkowe źródła pakietów.

Chociaż jest to dość rzadkie, czasami popełniają błędy i psują zgodność między mniejszymi wersjami pakietów.

Lubię cron-apt do automatyzacji tego procesu, ale jak zauważył @dinomite w innym pytaniu dotyczącym aktualizacji, skonfigurowanie go specjalnie do automatyzacji aktualizacji związanych z bezpieczeństwem jest bardzo sprytnym pomysłem - możesz następnie ręcznie zaktualizować to, czego potrzebujesz. Używałem cron-apt do wszystkich aktualizacji, ale tak naprawdę zmieniłem to na podstawie jego odpowiedzi. Jeśli ci się podoba, powinieneś raczej głosować na jego odpowiedź, a nie na tę.

Na Debianie instaluję cron-apt i edytuję jego plik konfiguracyjny, aby wysłać mi wiadomość e-mail, jeśli są jakieś zmiany. w ten sposób otrzymuję powiadomienie, jeśli są aktualizacje dla moich systemów i wykonuję je ręcznie

W tym samym wierszu co cron-apt powinieneś spojrzeć na pakiet nienadzorowanych aktualizacji http://packages.debian.org/lenny/unattended-upgrades .

Jest bardzo łatwy w konfiguracji i umożliwia automatyczne pobieranie i stosowanie aktualizacji zabezpieczeń, ale pozostawianie innych aktualizacji do ręcznej aktualizacji (lub według własnego uznania uaktualnij wszystko!).

Oficjalny przewodnik po serwerze Ubuntu zawiera dość szczegółową sekcję dotyczącą korzystania z pakietu nienadzorowanych aktualizacji https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Uwaga: w zależności od poziomu ostrożności / paranoi możesz najpierw wykonać aktualizację stopniową na grupie serwerów testowych, a następnie, jeśli nie ma żadnych problemów, pozwól aktualizować swoje skrzynki produkcyjne, chociaż osobiście nie napotkałem żadnych problemów z aktualizacjami zabezpieczeń spustoszenie jak dotąd spustoszenie (pukanie w drewno) ...

Dostępna jest również opcja konfiguracji wysyłająca pocztą e-mail wyniki każdej aktualizacji zabezpieczeń po jej zastosowaniu. Ponadto, jeśli podczas aktualizacji pojawiły się jakieś okna dialogowe lub interaktywne monity, które będą wymagały ręcznego dostosowywania przez sysadmin, również o nich wspomni.

Osobiście wyłączam automatyczne aktualizacje i nie wykonuję regularnie żadnych aktualizacji pakietów na serwerach w moich środowiskach, chyba że: (a) istnieje ważny poradnik CERT dla jednego z pakietów w moim systemie; (b) Muszę zaktualizować poszczególne pakiety z określonych powodów; (c) System operacyjny lub pakiety zbliżają się do końca cyklu, nie będą już obsługiwane i musimy nadal mieć wsparcie. Moje rozumowanie jest takie: uaktualnianie bez wiedzy o tym, co się zmienia lub dlaczego pozostawia zbyt wiele miejsca na coś zepsucia. Robiłem takie rzeczy przez 14 lat i to działa dobrze.

Poza wymienionymi rzeczami powinieneś użyć jakiegoś narzędzia do monitorowania (Nagios lub cokolwiek płynie łodzią), aby powiadomić Cię o aktualizacjach.

Jeśli chodzi o częstotliwość: tak szybko, jak dostępna będzie aktualizacja!