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? ;-)