Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00363 008445 11062962 na godz. na dobę w sumie
Apache. Receptury - książka
Apache. Receptury - książka
Autor: , Liczba stron: 280
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-416-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> serwery internetowe >> apache
Porównaj ceny (książka, ebook, audiobook).

Gotowe rozwiązania dla administratorów
najpopularniejszego serwera WWW

Apache jest najpopularniejszym obecnie serwerem WWW na świecie, co potwierdzają badania i statystyki. Większość witryn WWW działa właśnie na bazie tego serwera. Apache jest kolejnym, po Linuksie, potwierdzeniem fenomenu ruchu open source.

Dokumentacja Apache dostępna w sieci opisuje proces instalacji i konfiguracji serwera, co nie zawsze jest wystarczające, ponieważ administrowanie serwerem WWW działającym pod kontrolą Apache wymaga często rozwiązywania problemów pojawiających się w trakcie pracy. Dzięki ogromnej społeczności użytkowników, żadne wołanie o pomoc w sieci nie zostanie zignorowane, często jednak odpowiedź jest potrzebna natychmiast.

Książka 'Apache. Receptury' jest zbiorem gotowych rozwiązań najczęściej pojawiających się problemów i wątpliwości, przeznaczonym dla administratorów, programistów i innych użytkowników Apache. Opisane w książce problemy są rzeczywiste -- przydarzyły się autorom lub osobom zwracających się do nich o pomoc. Każde zagadnienie omówione jest w ten sam sposób -- problem, analiza i rozwiązanie. Zaletą takiego przedstawienia informacji jest to, że Czytelnik dowiaduje się nie tylko, co powinien zrobić, ale również dlaczego powinien postąpić tak a nie inaczej. Wyjaśnienia zamieszczonych w książce kodów pomogą również dostosować je do innych przypadków.

Książka zawiera rozwiązania problemów występujących przy różnych czynnościach -- od instalacji serwera, aż do obsługi szyfrowania SSL. Znajdujące się w niej informacje pomogą Czytelnikowi przy następujących przedsięwzięciach:

Każdy administrator serwera WWW powinien mieć tę książkę na swoim biurku.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI Apache. Receptury KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG Autorzy: Ken Coar, Rich Bowen T³umaczenie: Witold Zio³o ISBN: 83-7361-416-8 Tytu³ orygina³u: Apache Cookbook Format: B5, stron: 280 TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Apache jest najpopularniejszym obecnie serwerem WWW na ġwiecie, co potwierdzaj¹ badania i statystyki. Wiêkszoġæ witryn WWW dzia³a w³aġnie na bazie tego serwera. Apache jest kolejnym, po Linuksie, potwierdzeniem fenomenu ruchu open source. Dokumentacja Apache dostêpna w sieci opisuje proces instalacji i konfiguracji serwera, co nie zawsze jest wystarczaj¹ce, poniewa¿ administrowanie serwerem WWW dzia³aj¹cym pod kontrol¹ Apache wymaga czêsto rozwi¹zywania problemów pojawiaj¹cych siê w trakcie pracy. Dziêki ogromnej spo³ecznoġci u¿ytkowników, ¿adne wo³anie o pomoc w sieci nie zostanie zignorowane, czêsto jednak odpowiedĥ jest potrzebna natychmiast. Ksi¹¿ka „Apache. Receptury” jest zbiorem gotowych rozwi¹zañ najczêġciej pojawiaj¹cych siê problemów i w¹tpliwoġci, przeznaczonym dla administratorów, programistów i innych u¿ytkowników Apache. Opisane w ksi¹¿ce problemy s¹ rzeczywiste -- przydarzy³y siê autorom lub osobom zwracaj¹cych siê do nich o pomoc. Ka¿de zagadnienie omówione jest w ten sam sposób -- problem, analiza i rozwi¹zanie. Zalet¹ takiego przedstawienia informacji jest to, ¿e Czytelnik dowiaduje siê nie tylko, co powinien zrobiæ, ale równie¿ dlaczego powinien post¹piæ tak a nie inaczej. Wyjaġnienia zamieszczonych w ksi¹¿ce kodów pomog¹ równie¿ dostosowaæ je do innych przypadków. Ksi¹¿ka zawiera rozwi¹zania problemów wystêpuj¹cych przy ró¿nych czynnoġciach — od instalacji serwera, a¿ do obs³ugi szyfrowania SSL. Znajduj¹ce siê w niej informacje pomog¹ Czytelnikowi przy nastêpuj¹cych przedsiêwziêciach: • Instalacja Apache w systemach Linux i Windows • Instalowanie dodatkowych modu³ów • Rejestracja zdarzeñ i analizowanie dziennika zdarzeñ serwera • Konfigurowanie i obs³uga serwerów wirtualnych • Tworzenie aliasów, przekierowañ i przypisañ • Zwiêkszenie poziomu bezpieczeñstwa serwera • Praca z szyfrowaniem SSL • Konfigurowanie obs³ugi skryptów CGI i PHP • Obs³uga b³êdów • Praca z serwerem proxy • Optymalizacja i poprawa wydajnoġci dzia³ania serwera 5RKUVTGħEK Przedmowa .......................................................................................................................11 Rozdział 1. Instalacja serwera.....................................................................................17 1.1. Instalacja serwera z pakietów dystrybucji Red Hat Linux ..................................................18 1.2. Instalacja serwera Apache w systemie Windows ...................................................j..............19 1.3. Pobieranie plików źródłowych serwera Apache ...................................................j...............25 1.4. Budowa serwera Apache z kodu źródłowego...................................................j....................27 1.5. Instalacja serwera Apache za pomocą programu ApacheToolbox ....................................29 1.6. Uruchamianie, zatrzymywanie oraz ponowne uruchamianie serwera Apache..............31 1.7. Usunięcie serwera Apache...................................................j.....................................................33 Rozdział 2. Instalacja modułów..................................................................................35 2.1. Instalacja typowego modułu ...................................................j.................................................36 2.2. Instalacja modułu mod_dav w systemie uniksowym ...................................................j.......37 2.3. Instalacja modułu mod_dav w systemie Windows...................................................j...........39 2.4. Instalacja modułu mod_perl w systemie uniksowym...................................................j.......42 2.5. Instalacja modułu mod_php w systemie uniksowym...................................................j.......44 2.6. Instalacja modułu mod_php w systemie Windows...................................................j...........45 2.7. Instalacja modułu mod_snake Python...................................................j.................................46 2.8. Instalacja modułu mod_ssl ...................................................j....................................................47 Rozdział 3. Rejestracja zdarzeń...................................................................................49 3.1. Zwiększenie szczegółowości zapisów dziennika zdarzeń ..................................................53 3.2. Zwiększenie liczby komunikatów o błędach...................................................j......................53 3.3. Rejestracja zawartości POST...................................................j..................................................56 4 Spis treści 3.4. Rejestracja adresu IP klienta łączącego się poprzez serwer proxy.....................................57 3.5. Rejestracja adresu MAC klienta ...................................................j............................................57 3.6. Rejestracja Cookies...................................................j...................................................j...............58 3.7. Zaniechanie rejestracji żądań pobierania obrazów pochodzących ze stron lokalnych...60 3.8. Zmiana pliku dziennika zdarzeń o określonej porze dnia..................................................61 3.9. Zmiana pliku dziennika zdarzeń pierwszego dnia miesiąca..............................................62 3.10. Rejestracja nazw komputerów zamiast ich adresów IP ...................................................j....63 3.11. Oddzielne pliki dzienników zdarzeń serwerów wirtualnych ............................................65 3.12. Rejestracja żądań proxy...................................................j..........................................................66 3.13. Rejestracja komunikatów o błędach różnych serwerów wirtualnych w różnych plikach ...................................................j...................................................j.............67 3.14. Rejestracja adresu IP serwera ...................................................j................................................68 3.15. Rejestracja stron, z których nadchodzą żądania...................................................j.................69 3.16. Rejestracja nazw używanych przeglądarek ...................................................j........................70 3.17. Rejestracja dowolnych pól nagłówka żądania...................................................j....................71 3.18. Rejestracja dowolnych pól nagłówka odpowiedzi ...................................................j............72 3.19. Rejestracja aktywności serwera w bazie danych MySQL...................................................j.73 3.20. Rejestracja zdarzeń w dzienniku systemowym...................................................j..................74 3.21. Rejestracja katalogów użytkowników...................................................j..................................76 Rozdział 4. Serwery wirtualne .....................................................................................79 4.1. Konfiguracja serwerów wirtualnych opartych na nazwach................................................80 4.2. Konfiguracja jednego z serwerów wirtualnych opartych na nazwach jako serwera domyślnego ...................................................j...................................................j.82 4.3. Konfiguracja serwerów wirtualnych opartych na adresach................................................83 4.4. Konfiguracja jednego z serwerów wirtualnych opartych na adresach jako serwera domyślnego ...................................................j...................................................j.84 4.5. Jednoczesne użycie serwerów wirtualnych opartych na adresach oraz na nazwach.....85 4.6. Liczne serwery wirtualne obsługiwane za pomocą modułu mod_vhost_alias ...............86 4.7. Liczne serwery wirtualne obsługiwane za pomocą reguł przepisania .............................88 4.8. SSL i serwery wirtualne oparte na nazwach...................................................j.......................89 4.9. Rejestracja zdarzeń wszystkich serwerów wirtualnych...................................................j....90 4.10. Podział pliku dziennika zdarzeń ...................................................j..........................................91 4.11. Serwery wirtualne oparte na portach ...................................................j..................................92 4.12. Ta sama zawartość dostępna pod kilkoma adresami IP...................................................j...93 Spis treści 5 Rozdział 5. Aliasy, przekierowania oraz przepisania............................................95 5.1. Wyróżnianie składni kodu źródłowego PHP bez użycia dowiązań symbolicznych......95 5.2. Przyporządkowanie adresu URL do katalogu ...................................................j...................97 5.3. Tworzenie dodatkowego adresu URL dla istniejącej zawartości.......................................98 5.4. Przydzielenie użytkownikom ich własnych adresów URL.................................................99 5.5. Utożsamienie kilku adresów URL za pomocą pojedynczej dyrektywy..........................102 5.6. Przyporządkowanie kilku adresów URL do tego samego katalogu CGI.......................103 5.7. Tworzenie katalogów CGI dla każdego użytkownika...................................................j....104 5.8. Przekierowanie do innego miejsca ...................................................j.....................................105 5.9. Przekierowanie kilku adresów URL w to samo miejsce...................................................j.107 5.10. Nierozróżnianie wielkości liter w adresach URL...................................................j.............107 5.11. Wymiana ciągów znaków w żądanych adresach URL...................................................j...108 5.12. Zamiana informacji o ścieżce na argumenty CGI ...................................................j............109 5.13. Odmowa dostępu żądaniom pochodzącym z obcych stron .............................................110 5.14. Przepisanie na podstawie łańcucha zapytania ...................................................j.................111 5.15. Przekierowanie całego lub części serwera do SSL...................................................j...........112 5.16. Zamiana nazw katalogów na nazwy serwerów...................................................j...............113 5.17. Przekierowanie wszystkich żądań do jednego serwera...................................................j..114 5.18. Zamiana nazw dokumentów na argumenty programu ...................................................j.115 Rozdział 6. Bezpieczeństwo........................................................................................117 6.1. Wykorzystanie kont użytkowników do uwierzytelnienia dostępu do zasobów WWW ...................................................j...................................................j..........118 6.2. Konfiguracja haseł jednorazowych...................................................j.....................................121 6.3. Wygasające hasła...................................................j...................................................j................122 6.4. Ograniczanie wielkości umieszczanych na serwerze plików ...........................................124 6.5. Ograniczenie pobierania obrazków ze stron znajdujących się na innych serwerach ...126 6.6. Żądanie zarówno słabego, jak i silnego uwierzytelnienia.................................................127 6.7. Zarządzanie plikami .htpasswd...................................................j..........................................128 6.8. Przygotowanie plików haseł uwierzytelniania typu Digest .............................................130 6.9. Rozluźnienie ochrony w podkatalogu...................................................j...............................131 6.10. Wybiórcze zniesienie ochrony...................................................j.............................................134 6.11. Autoryzacja za pomocą informacji o właścicielu pliku...................................................j...135 6.12. Przechowywanie poświadczeń użytkownika w bazie danych MySQL..........................136 6.13. Dostęp do nazwy użytkownika uwierzytelnionego...................................................j........138 6.14. Uzyskanie hasła użytego do uwierzytelnienia...................................................j.................139 6.15. Ochrona przed atakami na hasła, typu brute-force ...................................................j.........140 6.16. Uwierzytelnianie typu Digest i uwierzytelnianie typu Basic ...........................................141 6 Spis treści 6.17. Dostęp do poświadczeń osadzonych w adresach URL ...................................................j..142 6.18. Zabezpieczenie usługi WebDAV ...................................................j........................................143 6.19. Uruchomienie usługi WebDAV bez udzielenia zezwolenia na zapisywanie do plików użytkownikowi, z uprawnieniami którego działa serwer...............................144 6.20. Ograniczanie dostępu poprzez proxy do określonych adresów URL.............................145 6.21. Ochrona plików za pomocą osłony...................................................j....................................147 6.22. Zniesienie ochrony pewnej grupy plików...................................................j.........................149 6.23. Ochrona plików serwera przed złośliwymi skryptami ...................................................j..150 6.24. Nadanie prawidłowych uprawnień do plików...................................................j................151 6.25. Uruchomienie serwera z minimalną liczbą modułów ...................................................j....154 6.26. Ograniczenie dostępu do plików znajdujących się poza katalogiem głównym WWW...................................................j...................................156 6.27. Ograniczenie metod dostępnych dla użytkowników ...................................................j.....157 6.28. Ograniczanie żądań zakresów ...................................................j............................................158 Rozdział 7. SSL ..............................................................................................................161 7.1. Instalacja SSL...................................................j...................................................j.......................161 7.2. Tworzenie certyfikatów SSL...................................................j................................................163 7.3. Tworzenie zaufanego ośrodka certyfikacyjnego...................................................j..............166 7.4. Udostępnianie części witryny WWW poprzez SSL...................................................j.........168 7.5. Uwierzytelnianie za pomocą certyfikatów klientów...................................................j.......170 Rozdział 8. Treść dynamiczna....................................................................................171 8.1. Uaktywnienie katalogu CGI ...................................................j................................................171 8.2. Uaktywnienie skryptów CGI w katalogach niewyznaczonych za pomocą dyrektywy ScriptAlias ...................................................j...................................172 8.3. Wykorzystanie rozszerzeń plików systemu Windows do uruchamiana skryptów CGI...................................................j........................................173 8.4. Identyfikacja skryptów CGI na podstawie ich rozszerzeń................................................175 8.5. Sprawdzenie, czy obsługa programów CGI jest skonfigurowana poprawnie...............176 8.6. Odczyt wartości z formularza...................................................j.............................................179 8.7. Uruchamianie programu CGI dla pewnych rodzajów treści............................................181 8.8. Użycie SSI ...................................................j...................................................j............................183 8.9. Przedstawienie daty ostatniej modyfikacji...................................................j........................185 8.10. Dołączenie standardowego nagłówka ...................................................j...............................185 8.11. Dołączanie wyniku działania programu CGI...................................................j...................187 8.12. Uruchamianie za pomocą programu suexec skryptów CGI z uprawnieniami innego użytkownika ...................................................j...........................187 Spis treści 7 8.13. Instalacja programu obsługi modułu mod_perl z serwisu CPAN...................................190 8.14. Pisanie programów obsługi modułu mod_perl ...................................................j...............191 8.15. Uruchomienie obsługi skryptów PHP ...................................................j...............................193 8.16. Weryfikacja instalacji PHP...................................................j...................................................193 Rozdział 9. Obsługa błędów .......................................................................................195 9.1. Obsługa przypadku brakującego pola Host ...................................................j.....................195 9.2. Zmiana kodu stanu odpowiedzi za pomocą skryptu CGI ................................................196 9.3. Własne komunikaty o błędach...................................................j............................................197 9.4. Komunikaty o błędach w różnych językach...................................................j.....................198 9.5. Przekierowanie odwołań do niepoprawnych adresów URL do innych stron...............200 9.6. Prawidłowa strona komunikatu o błędzie w programie Internet Explorer ...................201 9.7. Powiadamianie o błędach ...................................................j....................................................202 Rozdział 10. Proxy.........................................................................................................205 10.1. Zabezpieczenie serwera proxy...................................................j............................................205 10.2. Zabezpieczenie serwera proxy przed użyciem go jako otwartego przekaźnika poczty ...................................................j.................................207 10.3. Przekazywanie żądań do innego serwera...................................................j.........................208 10.4. Blokowanie żądań proxy do określonych miejsc ...................................................j.............209 10.5. Przeniesienie żądań obsługiwanych przez mod_perl na inny serwer ............................210 10.6. Konfiguracja buforującego serwera proxy ...................................................j........................211 10.7. Filtrowanie treści przekazywanych przez serwer proxy...................................................j212 10.8. Wymaganie uwierzytelnienia się na serwerze dostępnym poprzez proxy....................213 Rozdział 11. Wydajność ..............................................................................................215 11.1. Określenie ilości potrzebnej pamięci RAM ...................................................j.......................216 11.2. Testowanie wydajności serwera Apache za pomocą programu ab .................................217 11.3. Dobór ustawień dostępu keepalive...................................................j....................................218 11.4. Określenie stanu aktywności witryny WWW ...................................................j..................220 11.5. Unikanie wyszukiwania w DNS...................................................j.........................................221 11.6. Optymalizacja dowiązań symbolicznych ...................................................j..........................223 11.7. Ograniczanie wpływu użycia plików .htaccess na wydajność serwera..........................224 11.8. Wyłączenie negocjacji treści...................................................j.................................................226 11.9. Optymalizacja tworzenia procesów ...................................................j...................................228 11.10. Dobór parametrów tworzenia wątków ...................................................j.............................229 11.11. Buforowanie najczęściej przeglądanych plików ...................................................j..............231 11.12. Przeniesienie części obciążenia na drugi serwer za pomocą modułu mod_proxy .......233 8 Spis treści 11.13. Równomierne rozłożenia obciążenia między kilka serwerów .........................................234 11.14. Buforowanie list zawartości katalogu...................................................j................................235 11.15. Przyśpieszenie pracy programów Perl CGI za pomocą modułu mod_perl...................236 Rozdział 12. Pozostałe zagadnienia .........................................................................239 12.1. Poprawne umieszczanie dyrektyw ...................................................j....................................239 12.2. Zmiana nazw plików .htaccess ...................................................j...........................................241 12.3. Tworzenie listy zawartości katalogu...................................................j..................................242 12.4. Rozwiązanie „problemu końcowego ukośnika”...................................................j..............244 12.5. Ustalenie zawartości pola Content-Type w zależności od możliwości przeglądarki ...245 12.6. Obsługa brakującego pola Host: nagłówka..................................................j........................246 12.7. Inny domyślny dokument ...................................................j...................................................247 12.8. Konfiguracja domyślnej „ulubionej ikony”...................................................j.......................248 Dodatek A Użycie wyrażeń regularnych ..................................................................249 Dodatek B Rozwiązywanie problemów ...................................................................255 Skorowidz ......................................................................................................................265 Rejestracja zdarzeń Serwer WWW Apache może rejestrować i zwykle rejestruje wszystkie przetwarzane żą- dania. Kontrolowanie sposobu rejestracji oraz wydobywanie z dzienników zdarzeń przydatnych informacji jest równie ważne jak samo icch gromadzenie. Dzienniki zdarzeń gromadzą dwa rodzaje danych — informacje o samym żądaniu oraz jeden lub więcej komunikatów informujących o nieprawidłowościach stwierdzonych w czasie przetwarzania żądań (na przykład spowodowanych brakiem odpowiednich uprawnień do pliku). Administrator nie ma zbyt wielu możliwości kontrolowania spo- sobu rejestracji informacji o błędach, ale może w znaczącym stopniu kontrolować format oraz ilość rejestrowanych informacji dotyczących przetwarzania żądań (rejestracji aktyw- ności). Serwer może rejestrować informacje o żądaniach w kilku formatach i w kilku dziennikach zdarzeń, ale komunikaty o błędach może rejestrować tylko w jednym dzienniku. Należy zdawać sobie sprawę z tego, że zapis w dzienniku zdarzeń pojawia się dopiero po tym, gdy żądanie zostanie całkowicie obsłużone. Czas, jaki upływa pomiędzy zgło- szeniem żądania a zakończeniem jego obsługi, może w pewnych przypadkach mieć znacznie. Gdy, na przykład, w czasie pobierania szczególnie dużego pliku nastąpiła zmiana pliku dziennika zdarzeń, zapis w dzienniku odnotowujący żądanie pobrania pliku znajdzie się w nowym dzienniku w momencie, gdy zakończy się obsługa żądania, a nie w starym dzienniku, który obowiązywał, gdy żądanie nadeszło. W przeciwieństwie do tego, ko- munikaty o błędach rejestrowane są w dziennikach od crazu po ich wystąpieniu. Serwer WWW rejestruje zdarzenia przez cały czas pracy. Z tego powodu pliki dzien- ników zdarzeń mogą w przypadku bardzo obciążonych witryn WWW rozrastać się do niebotycznych rozmiarów, a w przypadku mniej obciążonych witryn ich rozmiar wciąż może być kłopotliwy. Żeby pliki dzienników zdarzeń nie rozrastały się zanadto, w większości witryn WWW zmienia się je co jakiś czas. Polega to na tym, że serwer zaprzestaje rejestracji zdarzeń w aktualnym pliku dziennika i rozpoczyna ją w no- wym. Ponieważ serwer Apache stara się ze wszystkich sił nie zgubić żadnego wpisu, 50 Rozdział 3. Rejestracja zdarzeń zmuszenie go, by zmieniał plik dziennika na podstawie określonego harmonogramu, wymaga pewnego wysiłku. W kilku recepturach (na przykład 3.8 i 3.9) pokazano, jak zrobić to skutecznie i pewnie. Dyrektywy rejestracji CustomLog oraz ErrorLog mogą pojawiać się wewnątrz kontene- rów VirtualHost , poza nimi (w czymś co jest nazywane serwerem głównym lub global- nym lub czasem zasięgiem globalnym) lub w obu tych miejscach jednocześnie. Informacje są jednak rejestrowane tylko w jednym z zestawów plików — jeżeli żądanie lub błąd dotyczą kontenera VirtualHost , w którym znajduje się odpowiednia dyrektywa reje- stracji, komunikat zostanie zapisany tylko w zestawie tego kontenera i nie pojawi się w żadnym z plików zadeklarowanych globalnie. Z drugiej strony, gdy w kontenerze VirtualHost nie ma żadnych dyrektyw rejestracji, serwer prowadzi rejestrację na podstawie dyrektyw globalnych. Jednak, niezależnie od tego, który zasięg zostanie wykorzystany do określania używa- nych dyrektyw rejestracji, wszystkie dyrektywy CustomLog tego zasięgu będą przetwa- rzane i traktowane niezależnie. W takim przypadku, gdy dyrektywa CustomLog znajduje się w zasięgu globalnym i równocześnie dwie takie dyrektywy znajdują się wewnątrz kontenera VirtualHost — zastosowane zostaną obydwie. Podobnie, jeżeli dyrektywa CustomLog wykorzystuje opcję env=, nie ma wpływu na to, jakiego rodzaju żądania bę- dą rejestrowane przez inne dyrektywy CustomLog w tym samym zasięgu. Aktywność serwerów WWW rejestruje się od początku ich istnienia. Bardzo szybko pierwsi administratorzy serwerów WWW ustalili, jakiego rodzaju informacje mają być rejestrowane. Tak powstał powszechny format rejestracji CLF (ang. Common Log Format). W zapisie używanym przez serwer Apache ma on postać: h l u t r s b W zapisie tego typu rejestrowane są: nazwa komputera klienta lub jego adres IP, nazwa użytkownika klienta (w sposób zdefiniowany w RFC 1413, jeżeli serwerowi Apache na- kazano jej śledzenie za pomocą dyrektywy IdentityCheck On), nazwa użytkownika, za pomocą której klient się uwierzytelnił (jeżeli serwer stosuje kontrolę dostępu), czas otrzymania żądania, treść żądania HTTP, końcowy stan przetwarzania żądania przez serwer oraz liczba bajtów zawartości wysłanej w odpowciedzi na żądanie. Niedługo po tym, gdy protokół HTTP już dojrzał, zaistniała potrzeba stworzenia po- wszechnego formatu rejestrowania informacji, w wyniku czego powstał wzbogacony format o nazwie złożony format rejestracji: h l u t r s b {Referer}i {User -agent}i Pojawiły się w nim dwa nowe człony — Referer (napisany w specyfikacji z błędem) oraz User-agent. Są to odpowiednio: adres URL strony zawierającej łącze do żądanego doku- mentu oraz nazwa i wersja przeglądarki lub innego klcienta występującego z żądaniem. Oba te formaty są obecnie szeroko stosowane, a wiele narzędzi do analizy dzienników zdarzeń zakłada, że zapisy dzienników mają jeden z dwócch powyższych formatów. Wprowadzenie 51 Standardowy moduł rejestracji aktywności serwera Apache nazywający się (niespo- dzianka!) mod_log_config, daje się bardzo dobrze konfigurować i umożliwia stosowanie własnych formatów dzienników zdarzeń. Serwer Apache 2.0 wyposażono w dodatkowy moduł mod_logio, który rozszerza funkcje modułu mod_log_config o możliwość rejestro- wania liczby wysłanych i odebranych siecią bajtów. Jeżeli jednak oba te moduły nie spełniają oczekiwań, można użyć jednego z wielu dostępnych modułów innych produ- centów wymienionych w rejestrze modułów na stronie http://modules.apache.org/. Kod stanu przetwarzania żądania występujący w obu formatach wymaga szerszego omówienia, gdyż jego znaczenie nie jest od razu oczywiste. Kody stanu zdefiniowane zostały w specyfikacji protokołu HTTP (aktualny dokument RFC 2616 znajduje się po adresem ftp://ftp.isi.edu/in-notes/rfc2616.txt). W tabeli 3.1 zebrano kody zdefiniowane do czasu powstania książki. Tabela 3.1. Kody stanu protokołu HTTP Kod Znaczenie 1xx — kody informacyjne 100 101 Kontynuacja Przełączenie protokołów 2xx — kody powodzenia 200 201 202 203 204 205 206 3xx — kody przekierowania 300 301 302 303 304 305 306 307 OK Utworzony Zaakceptowany Informacja nieautorytatywna Brak zawartości Zerowanie zawartości Zawartość częściowa Wiele możliwości Przeniesiony na stałe Znaleziony Spróbuj inny Niezmodyfikowany Użyj proxy (Nieużywany) Przekierowanie tymczasowe Wprowadzenie 52 Rozdział 3. Rejestracja zdarzeń Tabela 3.1. Kody stanu protokołu HTTP — ciąg dalszy Kod Znaczenie 4xx — kody błędów klienta 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 Złe żądanie Dostęp nieautoryzowany Wymagana opłata Dostęp zabroniony Nieznaleziony Metoda niedozwolona Nie do zaakceptowania Wymagane uwierzytelnienie proxy Upłynął limit czasu żądania Konflikt Nieobecny Potrzebna długość Niespełnione warunki wstępne Żądanie zbyt długie Żądanie URI zbyt długie Nieobsługiwany rodzaj medium Zakres żądania niezadowalający Oczekiwanie niespełnione 5xx — kody błędów serwera 500 501 502 503 504 505 Wewnętrzny błąd serwera Niezaimplementowany Zła brama Usługa niedostępna Upłyną limit czasu bramy Nieobsługiwana wersja protokołu HTTP Takie jednowierszowe opisy kodów stanu, jak te przedstawione w tabeli 3.1, mogą być mylące, ale przynajmniej dają pewne pojęcie o tym, co według serwera miało miejsce. Pierwsza cyfra kodu służy do wyróżnienia klas lub inaczej — kategorii kodów. Na przy- kład wszystkie kody zaczynające się cyfrą 5 oznaczają, że wystąpił problem obsługi żą- dania i że serwer „sądzi”, że przyczyna tego leży po jego stronie, a nie po stronie klienta. Pełny opis wszystkich kodów stanu można znaleźć w dokumentach poświęconych pro- tokołowi HTTP lub w samym RFC. 3.2. Zwiększenie liczby komunikatów o błędach 53 3.1. Zwiększenie szczegółowości zapisów dziennika zdarzeń Problem Zapisy dziennika zdarzeń dostępu powinny zawierać trocchę więcej szczegółów. Rozwiązanie Zamiast powszechnego (common) formatu rejestracji należy użyć złożonego formatu reje- stracji (combined): CustomLog logs/access_log combined Analiza Domyślnie informacje rejestrowane przez serwer Apache zapisywane są w formacie powszechnym (common), jednak za pomocą dyrektywy LogFormat można zmienić go na format złożony (combined). Złożony format rejestracji zawiera dwie dodatkowe informacje niedostępne w forma- cie powszechnym. Są to Referer — strona, z której nadeszło żądanie, oraz User- agent — używana przez klienta przeglądarka. Każdy poważny program analizujący dzienniki zdarzeń potrafi analizować dzienniki utworzone w obu formatach, a wiele z tych programów tworzy na podstawie dodatko- wych pól dodatkowe statystyki. Używając formatu złożonego, nie traci się nic, a można zyskać dodatkowe informacje. Zobacz również • http://httpd.apache.org/docs/mod/mod_log_config.html. • http://httpd.apache.org/docs-2.0/mod/mod_log_config.html. 3.2. Zwiększenie liczby komunikatów o błędach Problem Aby można było łatwiej znaleźć przyczynę problemu, w dzienniku błędów powinno znajdować się więcej informacji. 54 Rozwiązanie Rozdział 3. Rejestracja zdarzeń W tym celu w pliku httpd.conf należy zmienić lub dodać do niego wiersz LogLevel. Dy- rektywa ta ma kilka argumentów omówionych dalej. Na przykład: LogLevel Debug Analiza Istnieje kilka zhierarchizowanych poziomów rejestracji błędów, każdy oznaczony innym słowem kluczowym. Domyślnym argumentem dyrektywy LogLevel jest warn. Innymi możliwymi argumentami są w kolejności od najważniejsczej: emerg Zdarzenia krytyczne, gdy serwer WWW nie nadaje się do cużycia. alert Zdarzenia wymagające natychmiastowego podjęcia działancia. crit Zdarzenia krytyczne. error Błędy. warn Ostrzeżenia. notice Zdarzenia normalne, ale istotne. info Informacje. debug Komunikaty poziomu rozwiązywania problemów. Najmniej informacji będzie rejestrowanych w przypadku użycia argumentu emerg, a w przypadku użycia argumentu debug — najwięcej. W tej drugiej sytuacji reje- strowanych będzie prawdopodobnie wiele informacji niezwiązanych z rozwiązywa- nym problemem, więc po rozwiązaniu problemu należy powrócić do poprzedniego poziomu rejestracji. Mimo że poziomy rejestracji są z natury zhierarchizowane, komunikaty poziomu notice są rejestrowane zawsze, bez względu na ustawienia dyrektywy LogLevel. 3.2. Zwiększenie liczby komunikatów o błędach 55 Poziomy rejestracji są dość luźno zdefiniowane i jeszcze luźniej używane. Mówiąc ina- czej — poziom, przy którym zostanie odnotowany dany błąd, zależy wyłącznie od po- glądu osoby, która napisała kod programu. Opinia administratora na ten temat może być inna. Oto kilka przykładów komunikatów o różnych poziomach: [Thu Apr 18 01:37:40 2002] [alert] [client 64.152.75.26] /home/smith/public_html/test/.htaccess: Invalid comman d Test , perhaps mis-spelled or defined by a module not included in t he server configuration [Thu Apr 25 22:21:58 2002] [error] PHP Fatal error: Call to undefined function: decode_url( ) in /usr/apache/htdocs/foo.php on line 8 [Mon Apr 15 09:31:37 2002] [warn] pid file /usr/apache/logs/httpd.pid overwritten --Unclean shutdown of previous Apache run? [Mon Apr 15 09:31:38 2002] [info] Server built: Apr 12 2002 09:14:06 [Mon Apr 15 09:31:38 2002] [notice] Accept mutex: sysvsem (Default: sysvs em) Są to typowe komunikaty, z którymi można zetknąć się w przypadku czynnego serwera WWW. Po zmianie poziomu na debug może pojawić się dużo więcej tajemniczych ko- munikatów, takich jak: [Thu Mar 28 10:29:50 2002] [debug] proxy_cache.c(992): No CacheRoot, so n o caching. Declining. [Thu Mar 28 10:29:50 2002] [debug] proxy_http.c(540): Content-Type: text/ht ml Do tego właśnie służą te komunikaty — dzięki nim programista serwera Apache może dowiedzieć się, co dokładnie dzieje się w module proxyc. Zobacz również W czasie, gdy powstawała ta książka, prowadzone były wysiłki mające na celu stwo- rzenie słownika komunikatów o błędach serwera Apache, dzięki któremu będzie wia- domo, co one dokładnie oznaczają i co w przypadku ich wystąpienia należy zrobić. Jednak na razie nie można jeszcze zaprezentować żadnych wyników tych prac. Gdy prace się zakończą, na pewno pojawi się odpowiednia informacja na stronie twórców serwera Apache: http://httpd.apache.org/dev/ W takim przypadku informacja ta znajdzie się również cna stronie WWW książki: http://Apache-Cookbook.Com/ Szczegółowy opis działania dyrektywy LogLevel można znaleźć na stronie serwera Apache: http://httpd.apache.org/docs/mod/core.html#loglevel 56 Rozdział 3. Rejestracja zdarzeń 3.3. Rejestracja zawartości POST Problem Należy rejestrować dane dostarczone za pomocą metody POST, na przykład w postaci formularzy WWW. Rozwiązanie W przypadku serwera Apache 1.3 nie jest to w zasadzie możliwe, chyba że robi to moduł obsługujący metodę POST. W serwerze Apache 2.0 można to zrobić za po- mocą filtrów, ale w czasie, gdy powstawała ta książka nie było jeszcze filtrów tego rodzaju. Analiza W wersji 1.3 serwera Apache możliwość przetwarzania treści komunikatu żądania za- wierającego zmienną POST ma tylko jeden moduł i jedynie on może je rejestrować. In- formacja o żądaniu jest czytana z sieci tylko raz — przez moduł wybrany przez serwer do utworzenia odpowiedzi. Z tego powodu informacja ta nie jest dostępna w czasie fazy rejestracji, która następuje po fazie obsługi zawartościc. Gdy używany jest, na przykład, moduł mod_perl, informacje tego rodzaju można reje- strować, jeżeli kod obsługujący zawartość i tworzący odpowiedzi jest skryptem języka Perl obsługiwanym przez moduł mod_perl. Zobacz również • Jeżeli pojawi się odpowiedni filtr wejściowy, informacjca o nim znajdzie się na stronie WWW książki: http://Apache-Cookbook.Com/ • Więcej informacji na ten temat można znaleźć w różnychc artykułach omawiających filtry serwera Apache 2.0, na przykład znajdujących sicę na stronach: http://OnLAMP.Com/apache/ http://ApacheToday.Com/ 3.5. Rejestracja adresu MAC klienta 57 3.4. Rejestracja adresu IP klienta łączącego się poprzez serwer proxy Problem Należy rejestrować adres IP klienta otwierającego strony WWW, nawet gdy jego żądania przychodzą za pośrednictwem serwera proxy. Rozwiązanie Brak. Analiza Niestety, uniemożliwia to sam protokół HTTP. Patrząc od strony klienta — serwery proxy są zupełnie przeźroczyste, a patrząc od strony serwera WWW, w którym znajduje się żądana zawartość — są one całkowicie nieprzeźroczyste, co powoduje, że tożsamość klienta zgłaszającego żądanie jest ukrywana. Pozostaje tylko rejestrowanie adresów IP, z których nadchodzą żądania. Jeżeli przycho- dzą one bezpośrednio z przeglądarki — adresem tym będzie adres klienta, a jeżeli przy- chodzą one z jednego lub więcej serwerów proxy, będzie to adres tego serwera proxy, który bezpośrednio łączy się z serwerem WWW. Oba formaty rejestracji — złożony oraz powszechny — zawierają dyrektywę h repre- zentującą tożsamość (zdalnego) klienta. W zależności od ustawień dyrektywy Host- NameLookups może być nią nazwa komputera lub jego adres IP. Jeżeli w dzienniku zda- rzeń mają pojawiać się wyłącznie adresy IP, należy użyćc dyrektywy a. Zobacz również • Specyfikacja protokołu HTTP dostępna pod adresem ftp://ftp.isi.edu /in-notes/rfc2616.txt. 3.5. Rejestracja adresu MAC klienta Problem Należy rejestrować adres MAC (adres sprzętowy) klienta cłączącego się z serwerem WWW. 58 Rozwiązanie Rozdział 3. Rejestracja zdarzeń W większości przypadków nie można tego zrobić wcale i nie może tego zrobić również serwer Apache. Analiza Adres MAC nie ma żadnego znaczenia, za wyjątkiem przypadków, gdy żądanie nad- chodzi z sieci lokalnej (LAN). Na dodatek adres MAC nie występuje w transakcjach przeprowadzanych poprzez sieci rozległe (WAN). Gdy pakiet sieciowy przechodzi przez router, na przykład, gdy opuszcza sieć LAN, w polu adresu MAC pakietu, router zazwyczaj umieszcza swój adres sprzętowy. Zobacz również • Specyfikacja protokołu TCP/IP (należy przejść na stronę http://www.rfc-editor.org/ cgi-bin/rfcsearch.pl i w polu wyszukiwania wpisać „TCP”). 3.6. Rejestracja Cookies Problem Należy rejestrować wszystkie cookies wysyłane do serwera przez klienty oraz wszystkie cookies, o które serwer prosi, by klienci umieścili je w swych bazach. Może się to przy- dać do rozwiązywania problemów z aplikacjami WWW pocsługującymi się cookies. Rozwiązanie Aby rejestrować cookies otrzymywane od klientów, nalceży użyć: CustomLog logs/cookies_in.log {UNIQUE_ID}e {Cookie}i CustomLog logs/cookies2_in.log {UNIQUE_ID}e {Cookie2}i natomiast, aby rejestrować wartości cookies, które usctala i wysyła do klienta serwer: CustomLog logs/cookies_out.log {UNIQUE_ID}e {Set-Cookie }o CustomLog logs/cookies2_out.log {UNIQUE_ID}e {Set-Cookie 2}o Użycie dyrektywy formatu {Set-Cookie}o do rozwiązywania problemu nie jest za- lecane w sytuacji, gdy dotyczy on (lub może dotyczyć) wielu cookies — w dzienniku zdarzeń zostanie zarejestrowane tylko pierwsze. W punkcie zawierającym analizę tej receptury zostanie podany odpowiedni przykład. 3.6. Rejestracja Cookies 59 W czasie, gdy powstawała ta książka, serwer Apache nie potrafił rejestrować wartości wszystkich cookies, ale jeden z autorów książki pracuje nad rozwiąza- niem tego problemu. Gdy problem zostanie już rozwiązany, odpowiednia informa- cja pojawi się na stronie WWW książki (http://Apache-Cookbook.Com/). Analiza Pola cookies bywają bardzo długie i złożone, zatem podane instrukcje rejestrują je w od- dzielnych plikach. Zapisy dziennika cookies można wiązać z dziennikiem żądań dostępu odbieranych od klientów za pomocą zmiennej środowiskowej server-set UNIQUE_ID (zakładając, że moduł mod_unique_id jest aktywny, i że w formacie rejestracji zdarzeń tę zmienną środowiska uwzględniono za pomocą dyrektywy fcormatu {UNIQUE_ID}e). W czasie, gdy powstawała ta książka, najczęściej stosowane były pola nagłówka Cookie oraz Set-Cookie. Pola Cookie2 oraz Set-Cookie2 są nowsze i zostały stworzone w celu poprawienia niektórych niedoskonałości pierwotnej specyfikacji, ale nie zyskały sobie jeszcze większej popularności. Z powodu sposobu, w jaki zmieniała się z czasem składnia pól nagłówka cookie, in- strukcje rejestracji mogą, ale nie muszą, rejestrowaćc wszystkich szczegółów cookies. Należy pamiętać, że podane dyrektywy rejestracji będą rejestrować wszystkie cookies, a nie tylko te, które z jakichś powodów są interesujące. Na przykład, niżej pokazano za- pis dziennika przedstawiający żądanie klienta zawierające dwa cookies — jedno nazy- wające się RFC2109-1, a drugie — RFC2109-2: PNCSUsCoF2UAACI3CZs RFC2109-1= This is an old-style cookie, with spa ce characters embedded ; RFC2109-2=This_is_a_normal_old-style _cookie Mimo że jest to jeden zapis, zawiera on informacje o cdwóch cookies. Po stronie ustalającej zawartość cookie, pole nagłówka Set-Cookie wysyłane przez ser- wer w nagłówku swojej odpowiedzi wygląda tak: Set-Cookie: RFC2109-1= This is an old-style cookie, with space characters embedded ; Version=1; Path=/; Max-Age=60; Comment= RFC2109 demonst ration cookie Set-Cookie: RFC2109-2=This_is_a_normal_old-style_cookie; Vers ion=1; Path=/; Max-Age=60; Comment= RFC2109 demonstration cookie W dzienniku pojawia się zapis odpowiadający tej odpcowiedzi: PNCSUsCoF2UAACI3CZs RFC2109-1= This is an old-style cookie, with spa ce characters embedded ; Version=1; Path=/; Max-Age=60; Comment= RFC2109 demonstration cookie Jak widać, rejestracja pola Cookie w nagłówku żądania została wykonana poprawnie, ale zarejestrowano tylko jedno z pól nagłówka Set-Cookie odpowiedzi. 60 Rozdział 3. Rejestracja zdarzeń Zobacz również • RFC 2109 — „HTTP State Management Mechanizm” — definicje IETF pól nagłówka Cookie oraz Set-Cookie dostępne pod adresem ftp://ftp.isi.edu/in-notes/rfc2109.txt. • RFC 2965 — „HTTP State Management Mechanism” — definicje IETF pól nagłówka Cookie2 oraz Set-Cookie2 dostępne pod adresem ftp://ftp.isi.edu /in-notes/rfc2965.txt. • Oryginalna propozycja specyfikacji cookies firmy Netscape znajdująca się pod adresem http://home.netscape.com/newsref/std/cookie_spec.html. 3.7. Zaniechanie rejestracji żądań pobierania obrazów pochodzących ze stron lokalnych Problem Należy rejestrować żądania pobierania obrazów znajdujących się w witrynie WWW za wyjątkiem żądań pochodzących z własnych stron witryny. Przydaje się w przypadku konieczności ograniczenia rozmiaru pliku dziennika zdarzeń lub po to, by wyśledzić strony WWW, które traktują te obrazy jako własne. Rozwiązanie Aby ograniczyć rejestrację żądań tylko do pochodzących spoza danego ośrodka WWW, można wykorzystać dyrektywę SetEnvIfNoCase: FilesMatch .(jpg|gif|png)$ SetEnvIfNoCase Referer ^http://www.przykladowa.pl/ local_re ferrer=1 /FilesMatch CustomLog logs/access_log combined env=!local_referre r Analiza W wielu przypadkach strony umieszczone na serwerze WWW zawierają odwołania do obrazów przechowywanych również na tym samym serwerze. Z punktu widzenia ana- lizy dzienników zdarzeń jedynymi interesującymi zapisami są tylko te, które informują o stronach, z których nastąpiło odwołanie. Jak zapobiec rejestrowaniu żądań pobierania obrazów pochodzących ze strony lokalnej serwera? W przypadku, gdy strona, na której znajdują się łącza do obrazu, umieszczona jest w ser- werze www.przykladowa.pl (oczywiście nazwę tę należy zamienić na rzeczywistą nazwę serwera) i żądane są obrazy umieszczone w plikach GIF, PNG lub JPEG, za pomocą dy- rektywy SetEnvIfNoCase nadana zostanie wartość odpowiedniej zmiennej środocwiska. 3.8. Zmiana pliku dziennika zdarzeń o określonej porze dnia 61 Dyrektywa SetEnvIfNoCase jest podobna do dyrektywy SetEnvIf, różni się od niej tylko tym, że porównuje zmienne bez zwracania cuwagi na wielkość liter. Dyrektywa CustomLog zarejestruje wszystkie żądania, którym nie towarzyszy określona wartość zmiennej środowiska, czyli wszystkie żądania pobrania obrazów pochodzące spoza przykładowej strony. Przedstawione tu rozwiązanie działa tylko w przypadku klientów WWW, które infor- mują o stronie, z której pochodzi żądanie. Niektórzy uważają, że adresy URL stron, z których następuje odwołanie, nie powinny nikogo interesować. W przypadku niektó- rych klientów można wybrać, czy informacja ta ma być przekazywana czy też nie. W internecie działają też serwery zapewniające anonimowość, które działają jako serwe- ry proxy i skutecznie ukrywają tego typu informacje. Zobacz również • Receptura 6.5. 3.8. Zmiana pliku dziennika zdarzeń o określonej porze dnia Problem O określonej godzinie należy zmienić plik dziennika zdarzeń serwera Apache w sposób niewymagający zatrzymania i ponownego uruchamiania scerwera. Rozwiązanie Należy posłużyć się dyrektywą CustomLog oraz programem rotatelogs: CustomLog | /ścieżka/do/rotatelogs /ścieżka/do/logs/acc ess_log. Y- m- d 86400 combined Analiza Skrypt rotatelogs wykorzystuje funkcję serwera Apache o nazwie rejestrowanie potokowe (ang. piped logging), której działanie polega na kierowaniu komunikatów zdarzeń nie do pliku, a na wejście innego programu. Umieszczając skrypt rotatelogs pomiędzy serwerem WWW, a plikiem na dysku, można uniknąć konieczności zatrzymywania i ponownego uruchamiania serwera WWW w celu utworzenia nowego pliku dziennika zdarzeń. Skrypt automatycznie otworzy nowy plik i o określonej godzicnie rozpocznie zapisywanie do niego. 62 Rozdział 3. Rejestracja zdarzeń Pierwszym argumentem skryptu rotatelogs jest stały człon nazwy pliku dziennika zda- rzeń. Jeżeli argument ten będzie zawierać jeden lub więcej znaków , zostanie uznany za ciąg w formacie strftime(3). W przeciwnym razie do stałego członu nazwy dodany zostanie czas zmiany pliku (wyrażony w liczbie sekund, które upłynęły od 1 stycznia 1970) w postaci dziesięciocyfrowej liczby. Na przykład, gdy stałym członem nazwy bę- dzie wyraz foo, nazwy plików dzienników będą miały postać foo.1020297600, natomiast w przypadku stałego członu nazwy w postaci foo. Y- m- d, nazwy plików dzienników będą miały postać foo.2002-04-29. Drugim argumentem jest wyrażony w sekundach interwał pomiędzy zmianami plików. Zmiana pliku nastąpi wówczas, gdy wartość czasu systemowego będzie wielokrotnością interwału. Doba składa się z 86400 sekund, zatem użycie interwału wynoszącego 86400 sekund spowoduje, że nowy plik dziennika będzie tworzony o północy każdego dnia — gdy czas systemowy oparty na dacie 1 stycznia 1970 będzcie wielokrotnością 24 godzin. Ponieważ interwał jest liczbą sekund, która upływa pomiędzy zmianą pliku, zmia- na czasu z zimowego na letni nie ma wpływu na czas pomiędzy kolejnymi zmia- nami plików. Zobacz również • Strona podręcznika man programu rotatelogs: man -M /ścieżka/do/ServerRoot/man/rotatelogs.8 gdzie w miejsce /ścieżka/do/ServerRoot należy wpisać ścieżkę użytą w dyrektywie ServerRoot umieszczonej w pliku httpd.conf. 3.9. Zmiana pliku dziennika zdarzeń pierwszego dnia miesiąca Problem W pierwszym dniu nowego miesiąca powinno zakończyć się rejestrowanie zdarzeń w dotychczasowym pliku i rozpocząć w nowym. Rozwiązanie W dystrybucji serwera Apache nie ma żadnego skryptu, który realizowałby tę funkcję, ale skrypt taki można znaleźć na stronie WWW książki pod adresem http://Apache- Cookbook.Com/sources/Chapter04/rotate-log-monthly.pl1. 1 W grudniu 2003 roku skrypt ten nie był dostępny pod wskazanym adresem, gdyż, jak twierdzą autorzy książki, „są z nim pewne problemy” — przyp. tłum. 3.10. Rejestracja nazw komputerów zamiast ich adresów IP 63 Skryptu używa się, kierując przez niego potok komunikcatów o zdarzeniach, na przykład: CustomLog | rotate-log-monthly.pl logs/access_log- Y- M CLF Argumentem skryptu jest nazwa pliku dziennika zdarzeń. Ciąg znaków rozpoczynający się od znaku przesyłany jest funkcji strftime(3) w celu utworzenia członu nazwy nowego pliku dziennika uzależnionego od daty utworzecnia tego pliku. Analiza Podobnie jak w przypadku innych przedstawionych w tym rozdziale rozwiązań reje- stracji zdarzeń skrypt ten pełni tylko jedną funkcję. Jeżeli trzeba wykonać kilka funkcji — na przykład rozdzielić dzienniki zdarzeń pomiędzy serwery wirtualne i zmieniać pli- ki dzienników każdego pierwszego dnia miesiąca — należcy użyć innych skryptów. Rozwiązanie zastosowane w skrypcie rotate-log-monthly.pl należy raczej do rozwiązań typu „ślepej siły” i może nie działać zbyt dobrze w przypadku bardzo obciążonych ser- werów. Przyczyną tego jest odczytywanie czasu systemowego podczas zapisu każdej pozycji dziennika zdarzeń. Mimo to skrypt stanowi ilcustrację przyjętej w nim metody. Zobacz również • http://httpd.apache.org/docs/logs.html#piped. 3.10. Rejestracja nazw komputerów zamiast ich adresów IP Problem W dziennikach zdarzeń powinny być umieszczane nazwyc komputerów, a nie ich adresy IP. Rozwiązanie Serwer WWW może w czasie przetwarzania żądania klienta odwzorowywać adres IP klienta na odpowiadającą mu nazwę komputera. W tym ccelu należy wydać polecenie: HostnameLookups On Można też pozostać w czasie przetwarzania żądania przy adresie IP, a odwzorowanie adresu IP przeprowadzić w fazie zapisywania pozycji dziennika, wykorzystując do tego celu potok: 64 Rozdział 3. Rejestracja zdarzeń HostnameLookups Off CustomLog | /ścieżka/do/logresolve -c /ścieżka/do/logs/access_log.resolved combined Można również zapisywać w dzienniku adresy IP klientów i odwzorować je na nazwy komputerów później — podczas analizowania dziennika zdarzeń. W tym celu do pliku httpd.conf należy dodać wiersz: CustomLog /ścieżka/do/logs/access_log.raw combined I w razie potrzeby przetworzyć plik dziennika za pocmocą polecenia: /ścieżka/do/logresolve -c access_log.raw access_log.resolved Analiza Mechanizm rejestracji aktywności serwera Apache może rejestrować adresy IP klientów lub nazwy ich komputerów (albo jedno i drugie). Rejestrowanie nazwy komputera w czasie przetwarzania żądania powoduje, że serwer musi poświęcić trochę czasu na wykonanie operacji wyszukiwania w DNS mającej na celu zamianę (już posiadanego) adresu IP na odpowiadającą mu nazwę komputera. Tego rodzaju działanie może mieć poważny wpływ na wydajność serwera, gdyż aby zamienić adres komputera na jego nazwę, proces potomny serwera (lub jego wątek) musi za każdym razem zwracać się do odpowiedniej usługi odwzorowującej, a w czasie, gdy oczekuje on odpowiedzi — nie może obsługiwać innych żądań klienta. Alternatywą dla takiego postępowania jest reje- strowanie adresów IP klientów i odwzorowanie ich przez serwer na nazwy komputerów w czasie przetwarzania pliku dziennika. Ostatnią możliwością jest przeprowadzenie tej czynności za pomocą oddzielnego procesu, który nie ancgażuje serwera WWW. Teoretycznie do dyspozycji jest zatem szeroki wybór środków, jednak nie są one wolne od pułapek. Winny jest temu sam, dołączony do serwera Apache, program logresolve (zwykle instalowany w podkatalogu bin/ katalogu ServerRoot), który odwzorowuje tyl- ko adresy IP występujące na samym początku zapisów dziennika zdarzeń, a zatem nie nadaje się do użycia w przypadku, gdy stosowane są niestandardowe formaty dzienni- ków. Wadą ostatniego rozwiązania jest również to, że pomiędzy zarejestrowaniem adre- sów IP, a ich odwzorowaniem na nazwy komputerów może minąć zbyt dużo czasu, w którym informacje DNS mogą się istotnie zmienić, co może doprowadzić do mylących lub nawet niepoprawnych wyników. Dotyczy to szczególnie adresów IP nadawanych dynamicznie, co ma miejsce na przykład w przypadku adresów IP nadawanych przez dostawców usług internetowych (ISP). Inna wada tych rozwiązań ujawnia się wówczas, gdy komunikaty o zdarzeniach kiero- wane są do programu logresolve za pośrednictwem potoku — do wersji 1.3.24 serwera Apache program logresolve nie opróżnia buforów wyjściowych natychmiast, istnieje więc niebezpieczeństwo utraty przechowywanych w nich informacji o zdarzeniach spowo- dowanej, na przykład, przez załamanie się procesu rejecstracji lub działania systemu. 3.11. Oddzielne pliki dzienników zdarzeń serwerów wirtualnych 65 Zobacz również • Strona podręcznika man programu logresolve: man -M /ścieżka/do/ServerRoot/man/logresolve.8 3.11. Oddzielne pliki dzienników zdarzeń serwerów wirtualnych Problem Każdy z serwerów wirtualnych ma mieć oddzielny plik dziennika zdarzeń, ale nie po- winny być one stale otwarte, jak to ma miejsce w przypadku wielokrotnego użycia dy- rektywy CustomLog. Rozwiązanie W tym celu należy posłużyć się programem split-logfile znajdującym się w pakiecie ser- wera Apache. Aby podzielić plik dziennika zdarzeń po zakończeniu w nim rejestracji, należy wydać następujące polecenia (/ścieżka/do/ServerRoot należy zamienić na prawidłową ścieżkę): # cd /ścieżka/do/ServerRoot # mv logs/access_log logs/access_log.old # bin/apachectl graceful [należy poczekać na zamknięcie dotychczasowego pliku dziennika] # cd logs # ../bin/split-logfile access_log.old Aby rozdzielać zapisy do odpowiednich plików w czasie, gdy one powstają, należy do pliku httpd.conf dodać wiersz: CustomLog | /ścieżka/do/split-logfile /usr/local/Apache/logs combined Analiza Aby program split-logfile działał prawidłowo, format zapisów w dzienniku zdarzeń musi rozpoczynać się od dyrektywy „ v ” (po literze v musi znajdować się spacja). W ten sposób na samym początku każdego zapisu dziennika zdarzeń znajdzie się nazwa ser- wera wirtualnego i na jej podstawie program split-logfile będzie mógł zdecydować, do którego pliku powinna trafić dana pozycja dziennika. Przed przeniesieniem zapisu do od- powiedniego dziennika zdarzeń nazwa serwera wirtualncego zostanie z zapisu usunięta. Są dwa sposoby podziału dziennika zdarzeń — po jego zapisaniu, zamknięciu i rozpoczęciu zapisywania do nowego pliku lub na bieżąco, w miarę powstawania kolejnych zapisów. 66 Rozdział 3. Rejestracja zdarzeń Aby rozdzielić zamknięty plik, należy skierować go na wejście skryptu split-logfile. Aby roz- dzielać zapisy w czasie ich powstawiania, należy tak zmodyfikować konfigurację, by komunikaty o zdarzeniach trafiały do skryptu za pomoccą potoku. Każda z tych metod ma swoje wady i zalety. W przypadku pierwszej metody potrzeba dwukrotnie więcej miejsca na dysku (na przechowywanie pliku nierozdzielonego oraz plików rozdzielonych). Należy też dopilnować, aby plik dziennika zdarzeń został cał- kowicie zamknięty. (Niestety, nie ma prostej możliwości zrobienia tego bez całkowitego zatrzymania pracy serwera lub ponownego uruchomienia serwera z opcją graceful, a i tak możliwe jest, że jakieś powolne połączenie nie dopuści do zamknięcia dotychcza- sowego pliku dziennika przez dłuży czas po ponownym uruchomieniu serwera z opcją graceful). Rozdzielanie zapisów w miarę ich powstawania jest bardzo wrażliwe na za- łamanie się procesu rejestracji zdarzeń — mimo to, że serwer Apache uruchomi go po- nownie, komunikaty o zdarzeniach oczekujące przetworzenia mogą się spiętrzyć i utwo- rzyć w serwerze zator. Zobacz również • Receptura 3.10. 3.12. Rejestracja żądań proxy Problem Żądania przechodzące przez własny serwer proxy mają być odnotowywane w innym pliku niż żądania przychodzące bezpośrednio do serwcera. Rozwiązanie Żądania przechodzące przez własny serwer proxy można oznaczyć za pomocą dyrek- tywy SetEnv, dzięki czemu będzie możliwa ich rejestracja warunkocwa: Directory proxy:* SetEnv is_proxied 1 /Directory CustomLog logs/proxy_log combined env=is_proxied Analiza Serwer Apache 1.3 używa specjalnej składni dyrektywy Directory dotyczącej w szczególności żądań przechodzących przez moduł proxy. Mimo że znak gwiazdki (*) sugeruje, że do dopasowywania dokumentów można używać symboli wieloznacznych — nie jest to wcale symbol wieloznaczny. Można dopasowywać albo całe ścieżki, takie jak na przykład proxy:http://example.com/foo.html, lub za pomocą znaku * dopasowywać wszystko. Nie można użyć dopasowania takiego jak: proxy:http://example.com/*.html. 3.13. Rejestracja komunikatów o błędach różnych serwerów wirtualnych w różnych plikach 67 Gdy do różnych ścieżek proxy trzeba stosować różne dyrektywy — należy skorzystać z innego modułu. Ponieważ żądania przechodzące przez serwer proxy, a nie są obsłu- giwane bezpośrednio (czyli dany serwer jest serwerem proxy, a nie jest serwerem docelo- wym), w celu zastosowania dyrektyw do konkretnych dokumentów dostępnych poprzez proxy nie może użyć kontenera Files ani FilesMatch . Nie można też użyć sekcji Location ani LocationMatch , gdyż nie mogą się one pojawiać w kontenerze Directory . Można jednak, w celu podjęcia decyzji na podstawie ścieżki żądanego do- kumentu, skorzystać z modułu mod_rewrite. Na przykład żądania dotyczące obrazów przechodzące przez proxy można rejestrować w oddzielnym pliku za pomocą dyrektyw: Directory proxy:* RewriteEngine On RewriteRule .(gif|png|jpg)$ - [ENV=proxied_image:1] RewriteCond {ENV:proxied_image} !1 RewriteRule ^ - [ENV=proxied_other:1] /Directory CustomLog logs/proxy_image_log combined env=proxied_imag e CustomLog logs/proxy_other_log combined env=proxied_othe r Dyrektywy umieszczone wewnątrz kontenera Directory proxy:* będą dotyczyć je- dynie żądań przechodzących przez serwer. Pierwsza dyrektywa RewriteRule definiuje zmienną środowiska w przypadku, gdy nazwa żądanego dokumentu kończy się rozsze- rzeniem .gif, .png lub .jpg. Dyrektywa RewriteCond sprawdza, czy zmienna nie jest zde- finiowana, i w takim przypadku następująca po niej dyrektywa RewriteRule ustala war- tość innej zmiennej środowiska. Obie dyrektywy CustomLog w zależności od wartości zmiennych środowiska wysyłają do różnych plików informcacje o różnych rodzajach żądań. Zobacz również • Dokumentacja modułów mod_rewrite oraz mod_log_config. 3.13. Rejestracja komunikatów o błędach różnych serwerów wirtualnych w różnych plikach Problem W przeciwieństwie do informacji o zdarzeniach związanych z dostępem do serwera WWW informacje o błędach serwer Apache rejestruje tylko w jednym pliku. Należy wo- bec tego użyć środków, które spowodują, że komunikaty o błędach dotyczące serwerów wirtualnych będą trafiały do ich indywidualnych dzienników zdarzeń oraz jednocześnie do dziennika globalnego. 68 Rozwiązanie Rozdział 3. Rejestracja zdarzeń Istnieją co najmniej dwa rozwiązania tego problemu: 1. Można za pomocą potoku skierować komunikaty o błędachc do odpowiedniego skryptu, który skopiuje je i skieruje do odpowiednicch plików. 2. Można za pomocą potoku kierować komunikaty o błędach cdo kilku dzienników zdarzeń jednocześnie: ErrorLog | tee logfile1 | tee logfile2 logfile3 Analiza W przeciwieństwie do komunikatów o zdarzeniach związanych z dostępem, komuni- katy o błędach serwer Apache rejestruje tylko w jednym pliku. Jeżeli komunikat o błę- dzie dotyczy konkretnego serwera wirtualnego, a w jego kontenerze VirtualHost znajduje się dyrektywa ErrorLog, błąd zostanie odnotowany tylko w tym pliku i nie pojawi się już w żadnym dzienniku globalnym. Gdy w kontenerze VirtualHost nie ma dyrektywy ErrorLog, komunikat o błędzie trafi jedynie do dziennika globalnego. (Dziennik globalny definiuje ostatnia napotkana dyrektywa ErrorLog nieznajdująca się w żadnym kontenerze VirtualHost ). Obecnie jedynym rozwiązaniem tego problemu jest powielanie zapisów za pomocą od- dzielnego procesu (przez, na przykład, wysyłanie komunikatów o błędach do tego pro- cesu za pomocą potoku). Spośród przedstawionych wyżej dwóch rozwiązań pierwsze wymaga użycia własnoręcznie napisanego skryptu i jest bardziej elastyczne. Natomiast jeżeli wystarczy proste powielanie wszystkich zapisów dziennika do wielu plików jed- nocześnie, lepsze będzie drugie rozwiązanie, ale by ono działało, potrzebny jest program tee, którego nie ma na przykład w systemie Windows. To rozwiązanie może również prowadzić do opóźnień zapisywania komunikatów, gdy używany program tee nie opróżnia natychmiast swoich buforów wyjściowych po otrzymaniu każdego rekordu. W takim przypadku, przerwanie potoku lub załamanie systemu może doprowadzić do utraty komunikatów. Zobacz również •
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Apache. Receptury
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: