Jak „dobrze zarządzać” systemem operacyjnym, jak klikać, żeby się nie pogubić i wreszcie – jak to wszystko zrobić dobrze.
W ogóle, chwila usprawiedliwienia – piszę o tym, bo w ramach podsumowania własnej pracy wyszło mi, że co przejmowaliśmy adminkę po kimkolwiek – skala rozwiązań i chaosu powodowała problemy takiego sortu, że powinienem sobie dodać na Linkedinie skilla Linux archeo-ninja-terminator. Już nawet nie mówię o nieaktualizowanych zabytkach typu CentOS 5.2 albo Ubuntu 8.04.
Ogólny wniosek jest prosty – ilu administratorów, tyle najlepszych i w ogóle pomysłów. Przez chwilę zatęskniłem za Windowsem, w którym niektórych rzeczy nie da się sklikać inaczej, bo inne chore rozwiązanie na to nie pozwala. Ale za to wiadomo, gdzie szukać
Ale miało być o tym, jak robić, a nie jak nie robić.
Pierwsza sprawa, to porządek. Niby wszyscy to wiedzą, ale jeżeli się tego nie pilnuje od początku – po roku czy dwóch nawet dowolne distro linuxa nadaje się do przeinstalowania. Co tam jest, nie wie nikt, od czasu do czasu wybuchają różne biblioteki, nadpisane przy okazji instalacji różnego ciekawego lub w efekcie nieciekawego oprogramowania. I o ile Windowsy mają deinstalatory (gorsze lub często beznadziejne) o tyle Linuxy już nie do końca.
Jeżeli ktoś używa tylko oprogramowania w postaci binarnej (paczki czy porty) – jest prosto. Instalacja jak potrzeba, deinstalacja jak system „przytyje” i już. Ale czy aby w każdym przypadku tak jest?
Zatem zbierając kilka mądrości nabytych:
- korzystaj z programów w postaci binarnej – nie słuchaj tych, którzy chcą wszystko kompilować. W dzisiejszych czasach to sztuka dla sztuki, na dodatek przy większej ilości serwerów – szkodliwa sztuka (ale o tym za chwilę).
korzystaj z natywnych managerów oprogramowania dla danej dystrybucji (np. na Debianie jest alien – narzędzie do przetwarzania rpmów na deby, produkuje deby, i owszem, ale potrafi nadpisać kawał systemu swoimi skompilowanymi pod inne biblioteki softem, które potem trudno nawet wywalić z systemu). Binarki mają dodatkowo jeszcze jedną zaletę – nie śmiecą w systemie pozostałościami po kompilacji.
- jeżeli już musisz cokolwiek kompilować – poznaj FHS (filesystem hierarchy standard, czyli co się gdzie w danej dystrybucji/systemie znajduje) dla lokalnego systemu (dla Debiana mamy do dyspozycji całe drzewo /*/local, /usr/local, /var/local – jeżeli cokolwiek tam wrzucamy – system tego nie nadpisze, ani my nie nadpiszemy systemu. Jeżeli nie masz bladego pojęcia o czym mówię – nie kopuj bezmyślnie z sieci przykładów. W przypadku kompilacji główny katalog najczęściej określa opcja
--prefix. Nie /usr i nie /. Daj np. /opt, albo chociaż /moje. Wtedy będzie łatwiej zapanować nad różnicami pomiędzy kompilowanym narzędziem a systemem.
- poznaj dokładnie swój system – np. dowiedz się, gdzie trzyma konfigurację np. apache. W Debianie jest to /etc/apache, w starych wersjach RedHata czy innych CentOSów było to /etc/httpd. W Debianie demon nazywa się apache2, gdzie indziej najczęściej httpd, więc warto to wiedzieć zanim
make install narobi spustoszenia w podstawowym drzewie plików i katalogów)
- jeżeli cokolwiek chcesz dodać do systemu – poczytaj jak to zrobić zgodnie z zasadami adminki tymże. W Debianie (tak, jestem wyznawcą) jest coś, co nazywa się The Debian Way, czyli sposób zrobienia tego tak, żeby ktokolwiek nie siądzie do systemu rozezna się z nim w chwilę moment – o ile także podąża Debian Way’em.
- naucz się narzędzi administacyjnych dla właściwego systemu i używaj ich. To procentuje po jakimś czasie, szczególnie w przypadku konfiguracji, których nie dotyka się często.
Ok, ale jakie są korzyści przestrzegania takich niewygodnych czynności? W przypadku adminki jednym system – żadne. Serio. Nie ma potrzeby męczyć się i robić coś zgodnie z którymś wariantem standardu. Pomijając oczywiście przypadku, w których szukamy pomocy – wtedy może się okazać, że nikt nie jest nam w stanie pomóc, bo nie trzymamy standardu. Znacie to? Ile wpisów na forum kończy się mniej więcej tak: „a bo u mnie było to trochę inaczej, ale już znalazłem i podmieniłem ścieżki/biblioteki/konfigi”. Albo ile wpisów okazuje się gonieniem własnego ogona z powodu którejś drobnej zmiany dawno temu w przeszłości?
Czyli podsumowując: jeżeli jesteśmy adminem własnego systemu i ten system robi to co chcemy, to jak byśmy nie prowadzili hosta – będzie dobrze. Ale jeżeli zaczynamy przygodę z systemem – warto już robić to jak większość i standard, chociażby po to, żeby ktokolwiek mógł nam pomóc. Ludzie nie wiedzą, jak popsuliśmy własny system. Nawet nie podejrzewają zajebistości naszych rozwiązań 
.
Teraz o tym, dlaczego standardy są ważne w przypadku pracy z innymi ludźmi i większą ilością systemów niż jeden.
Weźmy najprostszą sytuację do wyjaśnienia – jest sobie dwóch adminów, którzy pilnują większej ilości systemów.
Idealnie, jeżeli są to te same dystrybucje. Jeżeli nie – nie jest źle, specjalizacja jest jak najbardziej wskazana, ale trzeba tutaj zapewnić jedną bardzo ważną rzecz. W przypadku nagłego zgonu lub innego przypadku losowego specjalisty – trzeba mieć pewność, że zanim tenże zmartwychwstanie, ktoś będzie w stanie podnieść usługę lub serwer. I że zrobi to szybko i nie popsuje bardziej niż pomógł.
Przykład prosto z życia. Ogólnie ja się zajmuję Linuxami w firmie, a kolega klika AD. Ale wszystko mamy zrobione zgodnie ze znanymi standardami w sieci. Przykład z AD: wiem gdzie leżą skrypty do dodawania usera do domeny od razu ze wszystkimi wpisami w GPO, wiem z grubsza jak się debuguje podstawowe problemy związane z brakiem możliwości zalogowania się do domeny. Od biedy potrafiłbym nawet dodać ręcznie usera, jak by mi skrypty wybuchły. Najwyżej bym go klikał kilka godzin, szukając po kolei, która grupa odpowiada za co.
Ale jestem w stanie to zrobić relatywnie szybko, bo grupy są tam, gdzie Internet mówi, że mają być. Nazywają się tak, że na podstawie samej nazwy kojarzę OCB – patrz SHARE_SKANY_RW (grupa mająca możliwość zapisu do share sieciowego SKANY).
Ok, może i nie umiem dodać drukarki tak, żeby się dystrybuowała przez GPO, ale to nie jest kluczowa usługa i wytrzyma do momentu, w którym pojawi się kolega i orypie mnie, że jeszcze nie dodałem drukarki . A jeżeli będzie taka potrzeba, dość szybko odnajdę pierwszy lepszy tutorial na sieci i sklikam to sam – bez szkody dla standardu.
W przypadkach Linuxowych jest jeszcze prościej – obaj wyznajemy Debian Way. Czyli np. nowe vhosty do apache dodajemy w /etc/apache2/sites-available i potem je włączamy przy pomocy a2ensite (albo chociaż ln -s).
Dovecot ma konfigurację w /etc/dovecot/conf.d i tam też dodajemy nowości, czy edytujemy opcje. Pewnie, można w konfigu zrobić include i dodać katalog w lokalizacji z dupy, ale szukanie tego komu innemu zajmie wieki. Jeżeli dodajemy coś do crona, to używamy katalogów /etc/cron.d, itp, itd.
A co do przestrzegania standardu, na przykład weźmy openvpna. Jeżeli się go klika komukolwiek, robi się to na początku. Trochę pracy jest, pewnie, ale potem cisza i spokój przez dłuższy czas. Ale potem przychodzi mroczny czas po np. roku, gdzie trzeba dodać nowego usera. I teraz seria bolesnych pytań: gdzie jest CA? Jak się dodawało certyfikat i klucz dla danego klienta. Jaki był standard dodawania userów na tym serwerze. Czy jest CCD? Czy jest hasło na klucz? Jaki jest podstawowy konfig? Ratunku? Pomocy?
Pytań może być jeszcze kilka i nie mówię, że problem nie jest nieogarnialny. W końcu odnajdziemy sposób, w jaki to konfigurował ktoś przed nami. Tylko zajmie to nieporównywalnie więcej czasu niż gdybyśmy wiedzieli jak to się robi i gdzie tego szukać. No i najważniejsza rzecz w tej całej zabawie – możemy spokojnie oddelegować zadanie koledze, jeżeli akurat składamy rozsypaną macierz czy szukamy pozostałości po włamie na serwer poczty.
A jeszcze bardziej na koniec, najlepsze do trzymania porządku są automaty. Do wyboru jest kilka rozwiązań, chef, cfengine czy inne płatne i niepłatne wynalazki. Nawet jeżeli komuś nie odpowiada żadne z rozwiązań – jeżeli się napisze swoje własne, tak czy inaczej porządek i standard zostanie wymuszony w obrębie własnego zbioru hostów do zarządzania. Automat nie zapomina, ale i nie wybacza – jeżeli zapomnimy dodać konfiga, system zrobi to za nas. Ale i nadpisze lokalne zmiany, więc trzeba się dobrze przymierzyć do takiego rozwiązania.
A obrazek z początku posta ma symbolizować sytuację, w której się znajdziemy, jeżeli na obcym systemie będziemy szukać właściwej drogi w rozwiązaniu autorskim umysłu, który przed nami coś połatał i działało aż do chwili temu. Najkrótsza droga do celu niekoniecznie jest najlepsza .
