Product SiteDocumentation Site

7.2. Powszechne procedury

Celem tej części jest przedstawienie ogólnych porad dotyczących pewnych operacji, które administrator będzie musiał często wykonywać. Procedury te oczywiście nie opiszą wszystkich możliwych przypadków w sposób wyczerpujący, ale mogą służyć za punkt początkowy dla przypadków trudniejszych.

7.2.1. Konfiguracja Programu

Jeśli chcesz skonfigurować nieznaną paczkę, musisz postępować etapami. Najpierw powinienes przeczytać dokumentacje konserwatora. Przeczytanie /usr/share/doc/paczka/README.Debian przybliży Ci konkretne schematy zastosowane do ułatwienia obsługi oprogramowania. Czasami jest to konieczne aby zrozumieć róznice pomiędzy pierwotnym zachowaniem programu, opisanym w głównej dokumentacji, takich jak howtos ( z jęz. ang. - jak to zrobić ). Czasami plik ten zawiera szczegółowy opis najczęściej występujących błędów aby unikąć utraty czasu.
Następnie powinienes przejrzeć oficjalną dokumentacje oprogramowania - sięgnij do poprzedniej sekcji aby wychwycić różne istniejące dokumentacje. Komenda dpkg -L paczka wyświetli Ci liste zawartych plików w paczce. W ten sposób będziesz w stanie szybko zidentyfikować dostępną dokumentacje ( tak jak i pliki konfiguracyjne, zlokalizowane w /etc/). dpkg -s paczka wyświetla meta-dane paczki i wszystkie zalecane bądź sugerowane paczki. Możesz tam znaleźć dokumentacje lub usługę ułatwiającą konfiguracje oprogramowania.
Ostatecznie, pliki konfiguracyjne są często same w sobie udokumentowane poprzez liczne wyjasniające komentarze, przedstawiające możliwe wartości dla każdej opcji ustawień. Do tego stopnia, że czasem wystarczy wybrać i aktywować jedną z dostępnych lini kodu. W niektórych wypadkach dostarczone są również przyklady konfiguracyjne w katalogu /usr/share/doc/paczka/examples/. Mogą one służyć jako podstawa pod Twój własny plik konfiguracyjny.

7.2.2. Monitorowanie co robią Deamony

Zrozumienie działania deamona jest trochę bardziej skomplikowane, ponieważ nie komunikuje się on bezpośrednio z działaniami administratora. Aby sprawdzić czy deamon faktycznie działa, musisz to przetestować. Dla przykładu : aby sprawdzić czy działa deamon Apache ( serwer WWW ) , sprawdź go zapytaniem HTTP.
Aby umożliwić takie testy, każdy deamon zapisuje to co robi, tak jak i każdy błąd który napotyka, w tak zwanych "log files" albo "system logs". Logi są przechowywane w /var/log/ albo jednym z ich podkatalogów. Aby poznać dokładną nazwę pliku logowego poszczególnego deamona sprawdź jego dokumentacje. Uwaga: pojedyńczy test nie zawsze będzie wystarczający jeśli nie będzie pokrywał wszystkich możliwych zastosowań. Niektóre problemy występują tylko w konkretnych okolicznościach.
Jako operacje zapobiegawczą, administrator powinien regularnie czytać najważniejsze logi serverowe. W ten sposób mogą zdiagnozować problem zanim zostanie on zgłoszony przez niezadowolonych użytkowników. Częstokroć użytkownicy czekają aż problem pojawi się kilkukrotnie w następujących dniach zanim go zgłoszą. W wielu przypadkach istnieją konkretne narzędzia do analizy zawartości dłuższych logów. W szczególności takie narzędzia istnieją dla serwerów www (takie jak analog, awstats, webalizer dla Apache), dla serwerów FTP, serwerów proxy/cache, firewallów, e-mailów i serwerów DNS a także serwerów drukujących. Niektóre z tych serwerów operują w sposób modularny i umożliwiają analize wielu typów plików logu. Tak jest w przypadku lirealbo też modlogan. Inne narzędzia , takie jak logcheck (oprogramowanie omówione na Rozdział 14, Security), skanują te pliki poszukując ostrzerzeń którymi trzeba się zająć.

7.2.3. Pytanie o pomoc poprzez listy mailingowe

Jeśli Twoje poszukiwania nie pomogły Ci dotrzeć do sedna problemu, możesz otwrzymać pomoc od innych, prawdopodobnie bardziej doświadczonych od Ciebie. Do tego właśnie służą listy meilingowe . Jak w każdej społeczności, istnieją tu reguły których należy przestrzegać. Zanim zadasz jakieś pytanie, należy sprawdzić czy Twój problem nie został juz omówiony we wcześniejszych dyskusjach lub nie jest gdzies opisany w oficjalnej dokumentacji.
Jeśli te dwa warunki zostaną spełnione, możesz pomyśleć o opisaniu swojego problemu do listy mailingowej. Zawrzyj jak najwięcej odpowiednich informacji jak to możliwe, różne przeprowadzone testy, zaczerpnięte dokumentacje, jak usiłowałeś zdiagnozować zaistniały problem, dotyczące paczki albo te które mogą być zamieszane, itd. Sprawdź System Śledzenia Błędów (BTS - Bug Tracking System, opisany w panelu bocznym TOOL Bug tracking system) dla podobnych problemów i wspomnij o wynikach wyszukania, załączając linki do znalezionych problemów. BTS znajduje się na:
Im będziesz bardziej uprzejmy i precyzyjny, tym większe są Twoje szanse na uzyskanie odpowiedzi, albo przynajmniej jej części. Jeśli uzyskasz pełną odpowiedz z właściwymi informacjami poprzez e-mail, pomyśł o upublicznieniu jej aby inni również mogli z niej skorzystać. To wspomoże także archiwum, przeszukiwane przez różne wyszukiwarki, znaleźć rozwiązanie innym posiadającym te same pytanie.

7.2.4. Raportowanie błędu jeśli jest zbyt trudny do rozwiązania

Jeśli wszystkie Twoje wysiłki związane z rozwiązaniem problemu zawiodą, istnieje możliwość, że odpowiedzialność za niego nie należy do Ciebie, a wynika z błędu w programie. W tym wypadku prawidłowym postępowaniem jest zgłoszenie błedu do Debiana bądź bezpośrednio do developerów. Aby to zrobić, wyodrebnij jak najmniejszą część programu tak, aby odtworzyć sytuacje w której on występuje. Jeśli wiesz który program jest jawnym powodzem występowania problemu, możesz odnaleźć jego paczke używając komendy , dpkg -S dany_plik. Sprawdź System Śledzenia Błędów (http://bugs.debian.org/paczka) aby się upewnić, że dany błąd nie został już zgłoszony. Możesz wtedy zgłosić swój błąd, używając komendy reportbug, załączając jak najwięcej informacji, w szczególnośći pełny opis wyodrębnionej części programu która umożliwi każdemu odtworzenie błędu.
Rozdział ten zawiera efektywne rozwiązania problemów które mogą się pojawić w następnych rozdziałach. Używaj ich zawsze kiedy to konieczne!