Zarządzanie aktualizacjami na setkach serwerów Debiana

Jak myślisz, jakie są najlepsze praktyki utrzymywania aktualności dziesiątek (jeśli nie setek) serwerów Debiana? Pamiętając, że:

• Istnieją grupy serwerów (tj. Identyczne serwery WWW, serwery DB, ...)
• Może być kilka problemów z Debianem (lenny, etch)
• Uruchomienie pętli na wszystkich serwerach i wykonanie aktualizacji i aktualizacji apt-get jest niedopuszczalne (ponieważ właśnie to robię w tej chwili :)) Powinno być lepsze niż to!

Obecnie, kiedy w końcu skończę wszystkie aktualizacje, publikowana jest nowa aktualizacja zabezpieczeń i muszę to zrobić od nowa.

Z góry dziękujemy społeczności serverfault!

Używam apt-dater do zarządzania aktualizacją wszystkich moich pudeł Debiana. Wydaje się, że wystarcza dobrze. Nie próbowałem jednak skalować go do setek hostów.

Google rozwiązało to za pomocą debmarshal:

http://code.google.com/p/debmarshal/

Umożliwia to zatwierdzanie pakietów z repozytorium nadrzędnego w celu instalacji na hostach produkcyjnych.

Następnie możesz po prostu uruchomić cron-apt w trybie w pełni automatycznym.

Oto wideo wprowadzające:

http://www.youtube.com/watch?v=L3hRToC23mQ

Próbowaliśmy używać marionetki do aktualizacji poprawek bezpieczeństwa w nieistotnych pakietach. Uruchomilibyśmy apticron, aby wysłać pocztą e-mail listę aktualizacji dla każdego serwera, a następnie codziennie uruchamiamy skrypt, który połączył te aktualizacje w plik manifestu marionetkowego, który dał pakiet i wersję dla każdej dystrybucji. Spowoduje to zaktualizowanie wiązki plików na poszczególnych serwerach i uruchomienie skryptu aktualizacji, gdy pakiet będzie wymagał aktualizacji. Działa to dość dobrze, ale nie przetestowaliśmy go tak bardzo, jak bym chciał. W tym schemacie ominęło się ograniczenie Puppet polegające na tym, że ten sam zasób nie został zdefiniowany w wielu miejscach.

Nie czułem się też komfortowo z automatycznymi aktualizacjami takich rzeczy jak MySQL lub PostgreSQL, gdzie przypadkowa aktualizacja wyłączyła usługę, być może w środku dnia. Nadal będą wymagały ręcznych aktualizacji.

Spacewalk i Debmarshall wyglądają jak odpowiednia alternatywa dla naszego programu lalek.

Najwyraźniej Spacewalk ma teraz wstępne wsparcie dla Debiana. Być może to razem z Puppet będzie moim punktem wyjścia. Jestem prawie pewien, że facet rozwijający obsługę Debiana dla Spacewalk pokocha cię za współpracę z nim przy przenoszeniu wsparcia Debiana na wyższy poziom.

W sposób oparty na systemie ściągającym, takim jak Puppet, istnieją również bcfg2 i cfengine. Jeden lub drugi z nich może dobrze pasować do twoich potrzeb. W tej chwili wdrażam bcfg2 w moim laboratorium.

Rozwiązanie może dać func

Nie jestem pewien, jakiego rodzaju rozwiązania oczekujesz. Prawdopodobnie wiesz o zadaniach crona, ale nie aktualizowałbym systemów w ciemno, ponieważ potrzebne są ludzkie interwencje (i dlatego płacą ci za to, prawda?)

Jeśli masz całkowicie identyczne systemy, możesz rozważyć użycie czegoś takiego jak rsync, aby wprowadzić różnice, ale ustalenie, które pliki nie powinny być rsync, może być trudne i nie zrobiłbym tego, gdy usługi są uruchomione. Przynajmniej skrypty aktualizacji są skonfigurowane do zarządzania restartowaniem usług i łączeniem różnic w plikach konfiguracyjnych.

Być może jeśli wyjaśnisz, na czym polega problem z wykonywaniem poleceń apt-get, możemy zobaczyć, czego chcesz uniknąć.

Jeśli problemem jest przepustowość i czas pobierania, być może powinieneś skonfigurować jedno pole, które będzie działać jako lokalne repozytorium Debiana. Istnieją przewodniki Debiana, jak to zrobić.

Oto kilka wskazówek, jak zminimalizować liczbę rzeczy, które należy zaktualizować.

Podczas instalacji Debiana nie instaluj Desktopa, chyba że naprawdę potrzebujesz X na tej konsoli. Większość serwerów nie wymaga zainstalowanego X-a. Może to znacznie zmniejszyć liczbę pakietów w systemie, a następnie nie trzeba aktualizować tylu pakietów.

Sprawdź, czy plik sources.list zawiera tylko te repozytoria, których naprawdę potrzebujesz. Jeśli eksperymentowałeś z jakimś repozytorium i zapomniałeś o tym, być może dostarczasz aktualizacje, których nie potrzebujesz lub nie chcesz.

Jeśli masz problemy ze ślepym robieniem aktualizacji na serwerze produkcyjnym, uważaj, aby zapoznać się z przewodnikami aktualizacji Debiana, gdy jest ważna aktualizacja (4.0 do 5.0). Przejdą one bardzo dobrze, jeśli postępujesz zgodnie z instrukcjami aktualizacji. Nie jest to tak łatwe, jak uruchomienie apt-get dist-upgrade i odejście. Czasami w instrukcjach znajdują się nawet wskazówki, kiedy uruchomić aptitude zamiast apt-get - są w nich niewielkie różnice.

Czy to narzędzie to „skorupa tancerza”? Lubię to i używam. Ale nie wiem, czy możesz go użyć dla tak wielu hostów. Może mógłbyś spróbować ...

http://www.netfort.gr.jp/~dancer/software/dsh.html.en

I on jest w repozytorium.

ClusterSSH. Logujesz się do wszystkich serwerów i podajesz im dokładnie te same polecenia, dzięki czemu możesz także reagować na okna dialogowe. Jeśli jeden serwer otrzyma dodatkowe pytanie, po prostu kliknij ten, a on będzie jedynym, który odpowie.

Użyłem go do uaktualnienia 25 serwerów z etch do Lenny. Działa jak urok.

http://sourceforge.net/projects/clusterssh/

Cluster ssh jest dobrą sugestią.

debmarshal nie jest jeszcze częścią Debiana - nie jestem nawet pewien, czy będzie to pakiet - wydaje się być zupełnie innym systemem ze specjalnym repozytorium. Jak powiedział mówca, jest to obecnie wrogie dla użytkownika, a nie przyjazne dla użytkownika.

Spacewalk wydaje się być klonem sieci Redhat, przynajmniej w interfejsie internetowym. Miałem złe wyniki z wykorzystaniem sieci Redhat do aktualizacji systemów. Pewnego razu zawiesił się bez wyraźnego powodu i spowodował awarię usługi. Zrobiłem mniam aktualizację natychmiast po tym i poradziłem sobie z tym dobrze, więc mogę tylko założyć, że problem był z czegoś, co obezwładniło po stronie RHN. Inną rzeczą, która mi się nie podoba w aktualizacjach RHN jest to, że nie wiesz, kiedy nastąpi aktualizacja, aby uważać na problemy.