Dostałeś serwer w spadku?

Pewnego dnia, dowiadujesz się, że otrzymujesz "w spadku" serwer... Ktoś zmienia pracę, ktoś awansuje i przekazuje obowiązki, albo po prostu Ty ciężką pracą i nieprzespanymi nocami spędzonymi w serwerowni zapracowałeś na to, by przejąć opiekę nad nowym systemem. Taki powiew przyjemnej świeżej bryzy.

Pierwsze logowanie, żeby się troszkę rozejrzeć... i pierwsze zdziwienie... co robi proces "daemon.pl"?, po co ten interfejs vlan69? że, jaki routing? do 44.55.66.77 przez 127.0.0.1? o_O Nie poddawaj się... Spróbujmy to jakoś ogarnąć. ;-)

1. Backup

Sprawdź czy serwer posiada aktualne backupy... jeśli nie, to koniecznie je zacznij robić. Nawet jeśli serwer nie sygnalizuje, żadnych problemów, to po prostu je zrób, zaoszczędzisz sobie wiele stresu w przyszłości. Dmuchaj na zimne. Bardzo ciężko jest odtworzyć serwer z głowy, nawet jeśli wydaje nam się, że znamy go dobrze, a co dopiero jeśli jest dla nas nowy. Jak zrobić szybko kopię zapasową? Najprościej będzie gdy użyjesz rsync'a i po prostu skopiujesz dane jeden do jednego... jeśli chcesz trochę pokombinować to możesz zrobić obraz systemu używając dd. Sama metoda nie jest najważniejsza, najważniejsze jest, byś był w stanie odtworzyć tą maszynę po totalnym padzie.

2. Procesy

# ps axuwww - sprawdź jakie aplikacje działają w systemie, najlepiej zrób zrzut listy procesów, chociażby poprzez wydanie polecenia # ps axuwww > ps_axuwww.dmp. Nigdy nie wierz, że wszystkie usługi wstaną same po restarcie... Awaria zasilania, przypadowy reboot, kernel panic, oops... promieniowanie kosmiczne... Cokolwiek co spowoduje reboot sprzętu, może zmusić Cię do długich poszukiwań, czego w systemie brakuje, a nie zawsze każdy dba o to, by wszystkie usługi startowały poprawnie, a czasami wręcz celowo niektóre nie są uruchamiane automatycznie, bo administrator chce mieć pewność, że inne usługi powiązane wstały pierwsze i dopiero po upewnieniu się uruchamia ją z ręki.

Jeśli znajdziesz jakiś proces który jest dla Ciebie nowy, spróbuj jak najwięcej się o nim dowiedzieć, jeśli masz PID i jedynie nazwę, bez żadnej ścieżki to możesz spróbować znaleźć coś w /proc/$pid/ szczególnie linki cwd, oraz exe. Dodatkowo możesz pośledzić co robi, używając # strace, # lsof -n $pid. W ostateczności # find / -name nazwa_procesu.

3. RAID

Sprawdź czy serwer posiada jakąś macierz (RAID), sprzętową? programową? # cat /proc/mdstat, jeśli jest LVM to # lvdisplay, jeśli nic tam nie widać, to sprawdź czy w serwerze znajduje się jakiś kontroler # lspci, # dmesg, # fdisk. Upewnij się, że wszystkie dyski pracują prawidłowo, być może któryś z nich sygnalizuje jakiś problem i należy go wymienić.

4. Konfiguracja

Przejrzyj konfiguracje usług, byś wiedział mniej więcej, jak działają i dlaczego tak. Jeśli nie rozumiesz dokładnie konfiguracji spróbuj odtworzyć podobną usługę na środowisku testowym, wiem, że to ne zawsze jest takie proste do realizacji, ale po prostu postaraj się zrozumieć jak działa danych serwis i dlaczego konkretnie tak musi działać. Dokładniejsze poznanie, da Ci pewność podczas awarii, że wiesz co robisz, a nie klikasz na ślepo mając nadzieję, że tym razem zadziała.

5. Firewall

Przejrzyj reguły firewall'a # iptables-save , zwróć uwagę jaki dostęp jest zezwolony, a co jest blokowane. Być może serwer jest zbyt otwarty na świat, jeśli masz takie wrażenie to upewnij się 100 razy, zanim zmienisz politykę na DENY. Często wydaję nam się, że wiemy wszystko o czymś, a po zmianach okazuję się, że ktoś stracił dostęp do usługi... Najgorsze są przypadki, gdy usługa jest wykorzystywana cyklicznie ale bardzo rzadko.

6. Użytkownicy, dostęp

Przejrzyj konta w systemie, szczególnie te z powłoką bash/sh, szczegóły znajdziesz w pliku /etc/passwd. Zobacz kto loguje się na serwer i w jakich godzinach, # who, # pinky, # last.

7. Routing

Sprawdź tablicę routingu, # route -n, # netstat -rn, jeśli widzisz jakiś dziwny routing spróbuj się dowiedzieć dlaczego taki jest. Zapisz wynik do pliku # route > route_n.dmp. Po restarcie może Ci się przydać ;-) Jeśli znalazłeś routing do jakiegoś hosta przez 127.0.0.1, to prawdopodobnie ktoś chciał zablokować dostęp z/do tego serwera... ;-) tak, takie rzeczy też można spotkać ;-)

8. Połączenia sieciowe

Sprawdź co nasłuchuje i na jakich portach, # netstat -nplut, # netstat -na, jeśli nie wiesz jakie inne serwery lub kto korzysta z tych usług to uruchom # tcpdump, # tcpflow, podsłuchaj transmisję, przeanalzuj co się z czym łączy. Powinieneś wiedzieć od jakich innych systemów Twój serwer jest zależny, gdybyś potrzebował uzasadnienia, to wyobraź sobie sytuację, że na Twoim serwerze działa serwis udostępniający jakieś dane na zewnątrz, ale dane są umieszczone w bazie danych która znajduje się na serwerze obok i aktualnie ma awarię... Twój serwer będzie odbierał żądania od użytkowników i starał się odpytywać bazę danych. Jeśli usługa będzie napisana dobrze, lub dobrze skonfigurowana to serwer nie powinien tego odczuć, ale co w przypadku kiedy liczba połączeń do bazy danych będzie ciągle rosła? Skończą Ci się deskryptory... Masz pewność, że usługa poradzi sobie z tym dobrze?

9. Cron

Bardzo ważne jest, byś wiedział jakie cykliczne zadania są wykonywane na serwerze... po sumiennym przeanalizowaniu cron'a # cron -l, a najlepiej # cat /var/spool/cron/crontabs/*, oraz /etc/cron*, nie będą Cię dziwić żadne zamrożenia systemu. Czasami w cronie można znaleźć naprawdę niezłe perełki. Spróbuj sprawdzić co robią poszczególne skrypty, nie daj się złapać na głupi błąd z nieobsłużeniem długiego czasu wykonywania skryptu i brakiem lockowania ;-)

10. Interfejsy sieciowe

# ifconfig -a, # ip a l, wyniki poleceń oczywiście zapisujemy do plików > ifconfig_a.dmp oraz > ip_a_l.dmp. Nie ma to jak aliasy interfejsów dodawane z ręki... Może się zdarzyć tak, że ktoś potrzebował szybko uruchomić nową usługę i nie dopisał nowego adresu do skryptów startowych. Warto więc sprawdzić ile interfejsów jest w systemie, oraz co do nich się binduje.

11. Monitoring

Jeśli wykorzystujesz jakiś centralny system monitorowania serwerów, sprawdź czy Twój jest dodany do niego, oraz co jest monitorowane. Podstawowe parametry to zajętość dysków, wykorzystanie pamięci (swap również), obciążenie CPU, jeśli masz RAID to koniecznie monitoruj dyski... nie ma głupszej awarii jak brak miejsca na dysku albo pad drugiego dysku w mirrorze, bo nikt nie zauważył, że jeden wypadł pół roku temu.

12. sysctl

Zrób zrzut ustawień, # sysctl -a > systctl_a.dmp. Chociażby po to, by dowiedzieć się, czy Twój serwer nie działa jako router ;-) Jeśli masz włączony ip forwarding i nie masz żadnego firewall'a, to Twój serwer może okazać się całkiem fajną bramą pomiędzy różnymi podsieciami, ale mam nadzieję, że takie rzeczy wyłapałeś już wcześniej tcpdumpem.

13. /etc/hosts

Dzięki wpisom w /etc/hosts możesz podmienić IP dla konkretnego hosta... Zobacz czy nie masz tam wpisanych dziwnych rzeczy. Bardzo łatwo jest zapomnieć o różnych wpisach, a później stracić godzinę nad próbą połączenia się z hostem który w rzeczywistości wskazuje na coś innego.

14. Dokumentacja

Wszystko co udało Ci się znaleźć, odkryć zapisuj... Jeśli masz centralny system gdzie możesz to zrobić, to zrób to właśnie w nim, oszczędzisz pracy przyszłemu administratorowi, ale pomyśl, że robisz to dla siebie. Kto wie czy za kilka miesięcy nie będziesz potrzebował czegoś szybko sprawdzić, a z natury szybko zapominamy o szczegółach... Po co masz szukać coś dwa razy, lepiej zapisz i zapomnij, wystarczy, że będziesz wiedział gdzie szukać. ;-)

A jak Wy sobie radzicie z takimi sytuacjami? Dostajecie serwer po kimś, co robicie jako pierwsze? ;-)

  • Szacun panie redaktorze, fajnie się czyta varloga ;-) W przyszłości możesz opisać jeszcze jak monitorujemy zabawki, w czym prowadzisz dokumentację itp ;)

  • Paweł Torbus

    Ad 1. zwróć uwage z jakiego fs system korzysta jeśli nie ma dużego journalu albo wcale to bedzie problem na aktywnym filesystemie np z baza danych. mówie tutaj o obrazie za pomocą dd
    Ad7. warto zwrócić uwage też na inne tablice routingu np w przypadku wiecej niż jednej domyślnej trasy
    Ad8. we FreeBSD nie zaklika netstat -ntplu ale ale mamy sockstat :):)

    Aj, no to wszystkie moje uwagi na dziś :), Patryk widzę że się rozkręcasz i motywujesz
    Pozdro :)

  • Pingback: Dostałeś serwer w spadku? - develway.pl()

  • Pingback: Tweets that mention Dostałeś serwer w spadku? -- Topsy.com()

  • Bartosz Feński

    Brakuje punktu przeinstaluj to wszystko w pizdu, bo nie wiadomo ile backdorów tam jest.

  • Teks dobry, ale fEnIo najlepiej to podsumował. ;-)

  • Zig

    Blagam "ździwienie"? Slownik zaatakuj bo oczy wykreca juz na poczatku

  • @Zig: poprawione. Mam nadzieję, że oczy masz całe. BTW: http://www.youtube.com/watch?v=T2iISWltdzc

  • Dariusz Rozdenko

    Wszystko świetnie, tylko ten analfabetyzm...
    (piszemy "nigdy nie wiesz" zamiast "nigdy nie wierz").
    Tępmy analfabetyzm w Narodzie!

  • @Dariusz Rozdenko: "wierz" od "wiary" ;-)

  • Z Z

    no i jeszcze dobrze jest wykonać "uname -a" zeby wiedzieć na jakim jajku obecnie chodzi; może się okazać, że po restarcie maszyna wstaje domyślnie na innym kernelu

  • Grzegorz

    Dodatkowo warto sprawdzić obecność rozwiązań typu chroot-vps, dla linux vservers będzie to vserver-stat oraz vserver-info:

    ne0:~# vserver-info
    Versions:
    Kernel: 2.6.22.19-vs2.2.0.7-vs-nogrs-64
    VS-API: 0x00020200
    util-vserver: 0.30.216-pre2772; Dec 13 2008, 04:56:19

    Features:
    CC: gcc, gcc (Debian 4.3.2-1) 4.3.2
    CXX: g++, g++ (Debian 4.3.2-1) 4.3.2
    CPPFLAGS: ''
    CFLAGS: '-Wall -g -O2 -std=c99 -Wall -pedantic -W -funit-at-a-time'
    CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W -fmessage-length=0 -funit-at-a-time'
    build/host: x86_64-pc-linux-gnu/x86_64-pc-linux-gnu
    Use dietlibc: yes
    Build C++ programs: yes
    Build C99 programs: yes
    Available APIs: v13,net,v21,v22,v23,netv2
    ext2fs Source: e2fsprogs
    syscall(2) invocation: alternative
    vserver(2) syscall#: 236/glibc
    crypto api: beecrypt
    use library versioning: yes

    Paths:
    prefix: /usr
    sysconf-Directory: /etc
    cfg-Directory: /etc/vservers
    initrd-Directory: $(sysconfdir)/init.d
    pkgstate-Directory: /var/run/vservers
    vserver-Rootdir: /var/lib/vservers

    Assumed 'SYSINFO' as no other option given; try '--help' for more information.

    ne0:~# vserver-stat
    CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
    40029 19 1.1G 27.2M 3m16s00 1m34s36 19d09h02 database-server
    40030 10 490.6M 34M 0m12s50 0m02s98 1d01h28 http-server
    40036 23 853.5M 68.8M 1m44s26 6m57s96 19d09h01 mserver

  • sjd

    Nigdy nie wiesz co ktos ustawil w systemie i czy nie podmienil poszczegolnych aplikacji np. ls wcale nie musi byc ls - czas weryfikacji lacznie z porownaniem plikow z plikami dystrybucji minimum tydzien intensywnej pracy podatnej na bledy.

    Jezeli przejmujesz odpowiedzialnosc za serwer to:

    Zdecydowanie nalezy spisac uslugi i configi, zrobic dumpy baz danych i kopie katalogow domowych, zabezpieczyc wszystkie logi itp. itd. a nastepnie na NOWYM czystym dysku postawic nowy czysty system i dodac jedynie to co potrzebne.
    Przy skomplikowanym serwerze i wielu uslugach max 1 dzien pracy i 5 minut wylaczenia serwera na podmiane dysku i restart.

    Stary dysk odlozyc na rok na polke, nigdy nie wiesz czy sie jednak nie przyda.

    Jezeli serwer jest "zdalny" pozostaje spisanie uslug a nastepnie uruchomienie systemu rescue, zrobienie dumpa calego dysku, skopiowanie danych i logow i sciagniecie do backupu, wyzerowanie dysku (cos w stylu dd if=/dev/zero of=/dev/sda1 cel 1. przemagnesowanie dysku, cel2. skasowanie wszelkich smieci, po tej czynnosci sprawdzamy tablice SMART dysku - bywa roznie. ), nastepnie instalacja wszystkiego od zera.

    Bez dluzszej przerwy nie obedzie sie.

    Pozdrawiam
    sjd

  • Jeśli mamy ten komfort i przez jakiś czas współpracujemy ze 'starym' administratorem, pierwszą rzeczą o jaką powinniśmy poprosić, to restart maszyny. Wtedy można zobaczyć ile dodatkowych czynności wymaga postawienie tego na nogi.

  • Pingback: Nagios tips & tricks [1] « guzik()

  • Pingback: Nagios tips & tricks()

  • do zautomatyzowanego generowania reportow o konfiguracji/stanie serwera proponuje

    http://www.cfg2html.com/

    pzdr.
    witalis

  • Pingback: Chwila zastanowienia przed `init 0` « guzik()

  • Bubu

    Ja mam jeszcze lepiej niż sytuacja w artykule. Wyrzucili technika, który zarządzał serwerem budynku i wrzucili mnie na jego miejsce, bo znam się trochę na komputerach i znam angielski. Nigdy nie obsługiwałem nawet czegoś podobnego do sieci domowej, a teraz mam całą serwerownię z centralą telefoniczną na głowie. I co gorsza, wszystko stoi na Windows Server a ja od kilku lat tylko linuksy mam na kompach w domu. No i nie mam żadnej dokumentacji oprócz protokołów powykonawczych.

    Koledzy spece, jak to ugryźć i się nie zbłaźnić? Chętnie podłapię jakieś sugestie. O ile ktoś to przeczyta w ciągu miesiąca. ;p