Najlepsze praktyki utrzymywania aktualności pakietów UNIX?

• Jak aktualizujesz swoje serwery?
• Korzystając z menedżera pakietów, takiego jak Aptitude , przechowujesz historię aktualizacji / instalacji, a jeśli tak, to jak to zrobić?
• Czy podczas instalowania lub aktualizowania pakietów na wielu serwerach istnieją sposoby na jak najszybsze przyspieszenie procesu?

W systemach Linux / Debian cron-apt jest bardzo przydatnym narzędziem, które może zarządzać automatyzacją apt za pomocą crona.

Używam go do apt-get updatekażdego dnia i wysyłam mi e-mail, jeśli trzeba zainstalować nowe aktualizacje.

Oto krótkie i dobrze wykonane wprowadzenie do tego narzędzia .

Jeśli chodzi o twoje trzecie pytanie: zawsze prowadzę lokalne repozytorium. Nawet jeśli dotyczy tylko jednej maszyny, oszczędza czas na wypadek konieczności ponownej instalacji (zazwyczaj używam czegoś takiego jak aptitude autoclean), a dla dwóch maszyn prawie zawsze się to opłaca.

W przypadku klastrów, którymi administruję, zazwyczaj nie prowadzę jawnych dzienników: pozwalam menedżerowi pakietów zrobić to za mnie. Jednak w przypadku tych komputerów (w przeciwieństwie do komputerów stacjonarnych) nie korzystam z automatycznych instalacji, więc mam swoje uwagi na temat tego, co zamierzałem zainstalować na wszystkich komputerach.

Podobnie jak cron-apt, używam apticronu .

Używam apt-history do historii. Nie mam pojęcia, dlaczego to przydatne narzędzie nie jest domyślnie dołączone, jest to pierwszy pakiet, który wdrażam wraz z marionetką .

Każdej nocy uruchamiam / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq jako zadanie crona. Rano mam powiadomienie o tym, które pakiety wymagają aktualizacji, a pliki zostały już pobrane na maszynę.

Następnie zazwyczaj robię migawkę maszyny (większość naszych serwerów jest wirtualna), przeprowadzam apt-get dist-upgrade , sprawdzam nagio i upewniam się, że wszystko nadal działa, i usuwam migawkę.

Na koniec przechowuję listę wszystkich zmian wprowadzonych na każdym serwerze na wiki , aby śledzić wszelkie problemy, które pojawią się później.

Jeśli chodzi o ograniczenie zbędnych pobrań, rozumiem, że możesz skonfigurować buforowanie serwera proxy (squid?) Między serwerami a Internetem, które będą buforować pliki .deb przy pierwszym dostępie . Być może jest to prostsze niż konfigurowanie lokalnego repozytorium pakietów - i ma tę dodatkową zaletę, że przyspiesza ogólne przeglądanie stron internetowych.

apt-cacher przydaje się do buforowania pakietów, buforuje je za pierwszym razem, gdy są potrzebne, zamiast wypełniać pełne lustro całego repozytorium, oszczędzając w ten sposób dysk i przepustowość. Jest to również przydatne, ponieważ przesyła strumieniowo pierwsze żądanie pakietu bezpośrednio do requestera, jednocześnie buforując go, więc nie ma dodatkowego opóźnienia.

Prowadzenie lokalnego repozytorium to najlepszy sposób na zarządzanie dokładnie tym, co znajduje się na lokalnych serwerach. Umożliwia także łatwe wdrażanie niestandardowych backportów lub niestandardowych pakietów lokalnych. Wiem, że tworzę lokalne „meta-pakiety”, które są tylko ogromną liczbą zależności, które ułatwiają instalację lokalną. (np. „apt-get install local-mailserver”). Ma to również efekt uboczny polegający na umożliwieniu „wersji” zmian konfiguracji. (Do bardziej skomplikowanego zarządzania konfiguracją potrzebujesz czegoś takiego jak Puppet)

W przypadku naszych pudeł z systemem Windows mamy lokalny serwer WSUS i standardowe okno do stosowania miesięcznych poprawek. W przypadku systemów Linux (RHEL) w kampusie mamy serwer satelitarny RHN, do którego wszyscy są przyłączeni. Zapewnia to przyjemny pulpit nawigacyjny każdego połączonego systemu, którym administrujesz, a także niezastosowane aktualizacje dla każdego systemu. Dla tych, którzy są w marionetce, wypychamy skrypt, który automatycznie stosuje poprawki podczas zwykłego okna i wysyła powiadomienie e-mail z wynikami.

Możesz mieć lokalne repozytorium i skonfigurować wszystkie serwery, aby wskazywały na niego aktualizacje. Nie tylko zyskujesz prędkość pobierania lokalnego, ale także kontrolujesz, które oficjalne aktualizacje chcesz zainstalować w swojej infrastrukturze, aby zapobiec problemom ze zgodnością.

Po stronie systemu Windows korzystałem z usług Windows Server Update Services z bardzo satysfakcjonującymi wynikami.

Korzystając z menedżera pakietów, takiego jak Aptitude, przechowujesz historię aktualizacji / instalacji, a jeśli tak, to jak to zrobić?

apt zachowuje dziennik / var / log / apt /, a dpkg używa /var/log/dpkg.log. W szczególności dpkg jest dość parsowalny.

W OpenSuSE Linux, SLES i Novell OES (wszystkie produkty oparte na SuSE) mamy skrypt, który uruchamia zypper i szuka pakietów, które należy zaktualizować. Kiedy go znajdzie, przesyła bilet do JIRA i przypisuje go sysadmins. Po zainstalowaniu aktualizacji zamykamy bilet, co pozostawia ślad audytu, który informuje nas, kiedy został zainstalowany i przez kogo. Można to pogodzić / potwierdzić z logami zypper i sudo, które są scentralizowane na serwerze syslogging.