Jak pilne jest *** wymagane ponowne uruchomienie systemu *** dla bezpieczeństwa?

Aby nauczyć się trochę administracji serwerem, skonfigurowałem prosty serwer Ubuntu 14.04, na którym prowadzę osobistą stronę internetową. Ustawiłem go tak, aby automatycznie instalował aktualizacje zabezpieczeń, ale pomijam inne aktualizacje. To wydaje się działać całkiem dobrze. Czasami pojawia się komunikat podczas logowania do serwera (za pomocą ssh) z informacją:

*** System restart required ***

Kiedy tak się stało, po prostu ponownie uruchomiłem Ubuntu i wszystko było w porządku. Jest to w porządku, ponieważ jest to prosta osobista strona internetowa. Zastanawiam się jednak, jak to działa w przypadku serwerów sieciowych, które powinny być o 99,9999etc% czasu? Czy po prostu nie uruchamiają się ponownie i ryzykują naruszenie bezpieczeństwa, ponieważ aktualizacje zabezpieczeń nie są zainstalowane (czego nie mogę sobie wyobrazić)? Czy może uważają przestoje za coś oczywistego (czego też nie wyobrażam)?

Jak sobie z tym poradzić, jeśli byłby to bardzo ważny serwer produkcyjny, który chcę utrzymać i działać? Wszystkie wskazówki są mile widziane!

[EDYCJA] Wiem, że mogę zrobić, cat /var/run/reboot-required.pkgsaby wyświetlić listę pakietów, które powodują ponowne uruchomienie. Polecenie daje obecnie następujące wyniki:

linux-image-3.13.0-36-generic
linux-base
dbus
linux-image-extra-3.13.0-36-generic
linux-base

ale skąd mam wiedzieć, czy aktualizacje są drobiazgami tego, czy mam poważną lukę w zabezpieczeniach, jeśli nie wykonam ponownego uruchomienia?

[EDIT2] OK, teraz połączyłem polecenia, które okazały się przydatne, w jeden:

xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high

Jeśli to nic nie da, problemy z bezpieczeństwem nie wydają się być pilne.

Ostatnie pytanie jednak: to low, mediumi highjedyne możliwości pilnych czy są jakieś bardziej jak na przykład criticalczy extremelyimportant?

Nie jest to prosta odpowiedź, ponieważ zależy od dokonanych aktualizacji. Jeśli jądro miało poważny problem z bezpieczeństwem, dobrze jest zrestartować tak szybko, jak to możliwe. Jeśli jądro ma tylko drobne poprawki, restart może zostać odroczony.

Jeśli zagwarantujesz dostępność> 99,9%, prawie zawsze będziesz mieć system klastrowy, w którym możesz ponownie uruchamiać węzły jeden po drugim bez przerywania usługi.

Ponownie uruchom pierwszy system i podłącz go ponownie do klastra. Potem drugi i tak dalej. Usługa nigdy nie będzie niedostępna.

dodatek do rozwiązania tematu

Przeprowadzam podobne sprawdzenie „wymagania ponownego uruchomienia” dla systemu monitorowania zabbix

Widzę 2 problem w rozwiązaniu „Temat”:

1. aptitude zwykle źle działa w skryptach. Zabijam kilka godzin, ale nadal nie działa z zabbix
2. jeśli tylko 1 dziennik zmian zawiera pilną aktualizację - sprawdzenie zawsze będzie miało pozytywne wyniki

Moja logika to:

1. Sprawdź ostatnią zmianę tylko w dzienniku zmian dla każdego pakietu, który wymaga ponownego uruchomienia systemu
2. Jako wynik pokaż tylko aktualizację o najwyższym priorytecie

Korzystając z dokumentacji Debiana znalazłem 5 możliwych wartości dla „pilności”, a także fakt, że po niej mogą występować znaki równości („=”) lub średnika („:”). Mogą być także wielkie i małe litery

Więc skończyłem z następującymi:

#!/bin/bash
##################################
# Zabbix monitoring script
#
# Checking urgency in changelog 
# for updates which require system restart
#
##################################
# Contact:
#  [email protected]
##################################
# ChangeLog:
#  20151205    initial creation
#  20151208    check uniq packages only 
##################################

case "$1" in

status)
    if [ -f /var/run/reboot-required ]; then
      echo 1
    else
      echo 0
    fi 
    ;;

urgency)
    if [ -f /var/run/reboot-required.pkgs ]; then
      while read pkg; do
        tmp=`/usr/bin/apt-get changelog $pkg | \
             /bin/grep -m1 -ioP '(?<=[Uu]rgency[=:])(low|medium|high|emergency|critical)' | \
             tr '[:upper:]' '[:lower:]'`
        if [ -n $tmp ]; then
          if   [ "$tmp" == "low" ] && \
               [ "$urgency" != "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=low
          elif [ "$tmp" == "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=medium
          elif [ "$tmp" == "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=high
          elif [ "$tmp" == "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=emergency
          elif [ "$tmp" == "critical" ]; then 
            urgency=critical
            break
          fi
        fi 
      done < <(sort -u /run/reboot-required.pkgs)
    else
      urgency=none
    fi

    case "$urgency" in
        none)      urgency=0 ;;
        low)       urgency=1 ;;
        medium)    urgency=2 ;;
        high)      urgency=3 ;;
        emergency) urgency=4 ;;
        critical)  urgency=5 ;;
        *)         urgency=42 ;;
    esac

    echo $urgency
    ;;
esac
exit 0

W rezultacie:

• reboot_required_check.sh status zwraca 1, jeśli wymagane jest ponowne uruchomienie, 0 jeśli nie jest
• reboot_required_check.sh urgency zwraca najwyższy poziom „pilności” lub „0”, jeśli ponowne uruchomienie nie jest wymagane

Mam nadzieję, że pomoże to komuś zaoszczędzić czas;)

Zastanawiam się jednak, jak to działa w przypadku serwerów sieciowych, które powinny być o 99,9999etc% czasu? Czy po prostu nie uruchamiają się ponownie i ryzykują naruszenie bezpieczeństwa, ponieważ aktualizacje zabezpieczeń nie są zainstalowane (czego nie mogę sobie wyobrazić)? Czy może uważają przestoje za coś oczywistego (czego też nie wyobrażam)?

Duże serwery WWW są restartowane, gdy ze względów bezpieczeństwa pojawi się * Wymagane ponowne uruchomienie systemu * .

Jest to jednak przezroczyste dla użytkownika, a witryna nigdy nie działa, ponieważ duże serwery często obsługują dwa lub trzy serwery, które przechowują dokładnie te same pliki i wyświetlają tę samą witrynę. Pierwszy jest serwerem głównym, a pozostałe dwa są drugorzędne i są używane tylko wtedy, gdy główny serwer jest wyłączony.