AKADEMIA GÓRNICZO-HUTNICZA
Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki
KATEDRA INFORMATYKI
HTTPD
Prowadzący:
mgr inż. Bogusław Juza
Autorzy:
Jacek Madej
Bartosz Ławniczek
Tomasz Kurek
2 z 38
Spis treści
1.
Protokół HTTP_______________________________________________________________________ 3
1.1.
Wstęp _______________________________________________________________________ 3
1.2.
Zapytania i odpowiedzi HTTP ___________________________________________________ 5
1.3.
Zapytanie HTTP ______________________________________________________________ 5
1.4.
Pola HTTP ___________________________________________________________________ 6
1.5.
Odpowiedź HTTP _____________________________________________________________ 8
1.6.
Cookies _____________________________________________________________________ 10
1.7.
Autoryzacja _________________________________________________________________ 10
2.
Apache jako demon HTTPD___________________________________________________________ 12
2.1.
Rynek serwerów______________________________________________________________ 12
2.2.
Dlaczego Apache _____________________________________________________________ 13
3.
Uruchamianie_______________________________________________________________________ 14
4.
httpd.conf __________________________________________________________________________ 15
4.1.
Dyrektywy blokowe ___________________________________________________________ 15
4.2.
.htaccess ____________________________________________________________________ 17
4.3.
Konfiguracja serwera _________________________________________________________ 18
5.
Moduły ____________________________________________________________________________ 22
5.1.
Mod_perl ___________________________________________________________________ 22
5.2.
Mod_php____________________________________________________________________ 22
5.3.
Mod_rewrite_________________________________________________________________ 22
5.4.
Inne moduły _________________________________________________________________ 22
6.
Serwery wirtualne ___________________________________________________________________ 25
6.1.
serwery wirtualne identyfikowane adresami IP ____________________________________ 25
6.2.
serwery wirtualne identyfikowane nazwami _______________________________________ 26
6.3.
serwery wirtualne identyfikowane numerami portów _______________________________ 26
7.
CGI _______________________________________________________________________________ 28
7.1.
Wstęp ______________________________________________________________________ 28
7.2.
Formularze __________________________________________________________________ 28
7.3.
Konfiguracja ________________________________________________________________ 29
8.
suExec _____________________________________________________________________________ 33
9.
Proxy ______________________________________________________________________________ 35
9.1.
Wstęp ______________________________________________________________________ 35
9.2.
Konfiguracja ________________________________________________________________ 35
10.
Źródła ____________________________________________________________________________ 38
10.1.
WWW ______________________________________________________________________ 38
10.2.
Literatura ___________________________________________________________________ 38
3 z 38
1. Protokół HTTP
1.1. Wstęp
Httpd jest demonem, który wykorzystuje protokół HTTP do serwowania dokumentów klientom.
Protokół HTTP jest zestawem wiadomości (posiadających swoje ściśle określone znaczenie) wymienianych pomiędzy
dwoma komputerami. Komunikaty te są transmitowane zwykłym tekstem poprzez połączenie zrealizowane nad
protokołem TCP/IP.
Protokół HTTP jest oparty o architekturę klient-serwer.
Komputer klienta przy pomocy przeglądarki WWW łączy się z serwerem z portem na który oczekuje demon HTTPD
(zwykle 80) i nawiązuje połączenie. Następnie przy pomocy protokołu HTTP klient wysyła żądanie o chęci pobrania
określonego dokumentu.
Serwer HTTPD odpowiednio interpretuje to żądanie i wysyła odpowiednią odpowiedź do klienta.
Sytuację tą ilustruje rysunek:
4 z 38
Kolejność czynności wykonywane podczas przykładowej sesji
1. W momencie wpisania przez użytkownika w przeglądarce adresu URL strony, który użytkownik chce pobrać
przeglądarka dokonuje analizy wpisanego tekstu.
2. Z wpisanego ciągu znaków wyodrębnia następujące fragmenty:
-rodzaj protokołu(http,ftp,...) – domyślnym protokołem jest HTTP
-nazwę hosta(lub adres IP jeżeli użytkownik taki wpisze)
-numer portu(domyślnie 80)
-nazwę dokumentu (np. strona html)
3. Kolejną czynnością jest określenie adresu IP hosta(jeżeli nie został wpisany w polu adresu w przeglądarce) – z
pomocą przychodzi DNS.
4. Następnie przeglądarka łączy się z danym serwerem na określonym numerze portu(w zależności od protokołu,
numeru podanego przez użytkownika) i próbuje pobrać żądany dokument.
Pobieranie dokumentu jest czynnością polegającą na wysłaniu sekwencji określonych wiadomości tekstowych
określanych mianem żądania(REQUEST). W odpowiedzi na te żądania serwer odsyła odpowiedź(RESPONSE) oraz
żądany dokument(lub komunikat o np. jego braku).
5 z 38
1.2. Zapytania i odpowiedzi HTTP
Zapytania oraz odpowiedź składają się z nagłówka(HEADER) oraz danych.
Różnorodność pól nagłówka zależy od wersji protokołu HTTP.
Pierwszą wersją protokołu był HTTP/0.9. Był on bardzo mało rozbudowany, nie posiadał pól nagłówka. Jedynym
komunikatem wysyłanym przez klient była linia określająca dokument do pobrania.
Wersja HTTP/1.0 protokołu umożliwiała już stosowanie różnych pól nagłówka, lecz nie pozwalała na określenie nazwy
domenowej hosta(patrz serwery wirtualne) oraz nie pozwalała na pobieranie kilku dokumentów jednym połączeniem.
Wraz z rozpowszechnieniem się sieci WWW oraz zwiększaniem rozmiarów stron WWW rozszerzono protokół o
możliwość tworzenia połączeń podczas których można pobierać kilka różnych dokumentów, obrazków, itd...
Wersja protokołu HTTP/1.1 umożliwiła również tworzenie tzw. serwerów wirtualnych.
1.3. Zapytanie HTTP
W zapytaniu HTTP decydującą rolę odgrywa pierwsza linia. W niej klient HTTP określa, jakie działania ma wykonać
serwer. Najczęściej chodzi tutaj o załadowanie dokumentu HTML - działanie uruchamiane poleceniem GET. Następnie
podawana jest ścieżka dostępu i nazwa dokumentu do pobrania z danej lokalizacji. Aby mieć pewność, że przeglądarka
i serwer będą "rozmawiać" w tym samym języku, do pierwszej linii zapytania dodawane jest jeszcze oznaczenie wersji
używanego protokołu. Przykładowy nagłówek może rozpoczynać się linią
6 z 38
GET /default.htm HTTP/1.0
Protokół HTTP zawiera inne polecenia, które nie są jednak tak często używane i obsługiwane przez wszystkie serwery
WWW.
Rodzaje poleceń:
POST wysyła zawartość formularza HTML do serwera. Stanowi to podstawę interaktywnych aplikacji WWW.
GET pobiera zawartość strony z serwera. Jest to najczęściej używane polecenie w HTTP
PUT wysyła do serwera dokument, który serwer zapisuje na swoim dysku lokalnym. Ponieważ niewłaściwe użycie
tego rozkazu może zakłócić poprawną pracę serwera, najczęściej nie jest on obsługiwany przez serwery.
DELETE kasuje dokument na serwerze. Również to polecenie ze względów bezpieczeństwa ignorowane jest przez
większość serwerów lub kwitowane komunikatem o błędzie.
HEAD służy do pobrania tylko danych o określonym dokumencie. Jest ona przydatna do pobrania np. inf. czy
określony dokument nie uległ modyfikacji od czasu ostatniego pobrania.
Inne metody Poniższe metody są zdefiniowane, choć nie są zbyt często stosowane:
LINK - wymaga aby informacja zawarta w nagłówku była skojarzona z dokumentem znajdującym się na serwerze
UNLINK - wymaga aby informacja zawarta w nagłówku była oddzielona od dokumentu na serwerze
OPTIONS - wymaga przesłania informacji o opcjach komunikacyjnych dostępnych na serwerze. Symbol gwiazdka
( * ) oznacza przesłanie wszystkich informacji dostępnych na serwerze
TRACE - wymaga aby cała zasadnicza część wysyłanego zapytania została odesłana w nienaruszonej postaci
POST /cgi-bin/post-query HTTP/1.0
Accept: text/html
Accept: video/mpeg
Accept: image/gif
Accept: application/postscript
User-Agent: Lynx/2.2 libwww/2.14
Content-type: application/x-www-form-urlencoded
Content-length: 150
<CR><LF>
ITEM=1234
&SUBITEM=10000
&user=john
1.4. Pola HTTP
W przypadku komunikacji opartej na protokole HTTP/1.0 po pierwszej linii zapytania HTTP mogą nastąpić dalsze linie
z opcjonalnymi polami HTTP. W polach tych przeglądarka przekazuje takie parametry, jak język żądanego dokumentu
lub podaje hasło dostępu do zastrzeżonej strony WWW.
Pola protokołu HTTP/1.0 zdefiniowane dla przeglądarki (a także dla serwera) opisane są w tabeli Znaczenie pól HTTP.
7 z 38
Znaczenie pól http
Pole zapytania
(przeglądarka)
Pole odpowiedzi
(serwer)
Opis
Metoda kodowania dokumentu
ACCEPT
Wersje kodowania MIME obsługiwane przez przeglądarkę,
CONTENT-TYPE Wersja kodowania MIME wysłanego dokumentu,
ACCEPT-
CHARSET
Zestawy znaków obsługiwane przez przeglądarkę,
Wybór języka
ACCEPT-
LANGUAGE
Język preferowany przez przeglądarkę,
CONTENT-
LANGUAGE
Język dokumentu,
Rozmiar dokumentu
CONTENT-
LENGTH
Rozmiar dokumentu wysłanego przez serwer, w bajtach,
Autoryzacja
USER-AGENT
Identyfikator / nazwa programu przeglądarki,
SERVER
Nazwa oprogramowania serwera,
FROM
Adres e-mail użytkownika,
REFERER
Ostatnio odwiedzony URL,
Data, buforowanie w pamięci cache, data utraty ważności
DATE
DATE
Czas zapytania / odpowiedzi,
EXPIRES
Data utraty ważności dokumentu wysłanego przez serwer,
IF-MODIFIED-
SINCE
Data utraty ważności dokumentu, po przekroczeniu której serwer powinien
wysłać zawartość dokumentu. Jeśli data utraty ważności nie minęła,
przeglądarka używa starej wersji dokumentu zapisanej w pamięci cache,
LAST-
MODIFIED
Data ostatniej modyfikacji danych,
PRAGMA
Niestandardowy rozkaz często używany w postaci "Pragma: no cache", aby
wyłączyć działanie pamięci cache serwera proxy,
Przekierowanie
LOCATION
Żądany dokument znajduje się pod podanym adresem,
Oczekiwanie
8 z 38
RETRY-AFTER Zapytanie powinno być powtórzone po podanym czasie,
Autoryzacja użytkownika
WWW-
AUTHENTICATE
Wymóg autentykacji,
AUTHORIZATION
Przesłanie identyfikatora i hasła,
Cookies
SET-COOKIE
Zapisanie cookie na dysku twardym klienta,
COOKIE
Zapisane cookie odsyłane jest do serwera razem z zapytaniem.
Content-Type: text/html
Date: Tue, 15 Nov 1994 08:12:31 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT
From: Stars@WDVL.com
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Location: http://onet.pl
Referer: http://wp.pl
Server: CERN/3.0 libwww/2.17
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1.5. Odpowiedź HTTP
Serwer, po przyjęciu i przeanalizowaniu zapytania, generuje odpowiedź, której struktura jest podobna do struktury
zapytania. W pierwszej linii serwer podaje, w której wersji protokołu HTTP została utworzona odpowiedź, aby klient
mógł ją poprawnie odczytać. Po tej informacji następuje trzycyfrowy kod statusu odpowiedzi (patrz tabela "Kody
odpowiedzi serwera WWW"). Dla łatwiejszego zrozumienia kod statusu opatrzony jest opisem tekstowym, np. "403
Access denied
", który ujrzymy po nieudanej próbie zalogowania się za pomocą nazwy użytkownika i hasła. Jeśli
nie zostały stwierdzone żadne błędy, zobaczymy komunikat
"HTTP/1.0 200 OK.".
Kody odpowiedzi serwera WWW
Kod odpowiedzi
Opis
Potwierdzenia
200 OK
Dokument został przesłany poprawnie.
201 OK
Serwer odebrał dane od przeglądarki i odesłał żądany dokument.
202 OK
Polecenie zostało odebrane i uznane za poprawne, jednak serwer wykona je dopiero
później.
204 No Document
Serwer wykonał polecenie, jednak w rezultacie do przeglądarki nie są wysyłane żadne
dane.
9 z 38
Odmowa dostępu
301 Moved Permanently
Żądany dokument nie jest już dostępny pod podanym adresem. Jeśli serwer zna nową
lokalizację dokumentu, może ją wskazać w polu Location.
302 Moved Temporarily
Żądany dokument jest czasowo niedostępny pod podanym adresem. Nowa lokalizacja
podawana jest w polu Location.
304 Not Changed
Dokument żądany przez przeglądarkę nie zmienił się od czasu ostatniego pobrania
(patrz pole Expires). Serwer nie wysyła dokumentu podobnie.
Niepoprawne zapytanie
400 Syntax Error
Zapytanie wysłane przez przeglądarkę zawiera błąd i nie może być obsłużone.
401 Authentication needed
Przeglądarka / użytkownik muszą zostać najpierw zidentyfikowani, aby uzyskać dostęp
do dokumentu.
403 Access denied
Przeglądarka / użytkownik nie mogą uzyskać dostępu do dokumentu, nawet po
zidentyfikowaniu.
404 Not Found
Żądany dokument nie został znaleziony.
Błąd
500 Internal Error
Wskazuje na wewnętrzny błąd serwera.
501 Unknown Action
Serwer nie może wykonać działania (GET, PUT, DELETE, POST).
502 Server Not Found
Taki komunikat generuje serwer proxy pośredniczący w transmisji, jeśli serwer
wywoływany przez przeglądarkę nie zostanie znaleziony.
503 Server Overload
Serwer jest przeciążony i nie może obsłużyć zapytania klienta. Użytkownik powinien
spróbować jeszcze raz później.
HTTP/1.0 200 OK
Date: Wednesday, 02-Feb-95 23:04:12 GMT
Server: NCSA/1.3
MIME-version: 1.0
Last-modified: Monday, 15-Nov-93 23:33:16 GMT
Content-type: text/html
Content-length: 2345
<CR><LF>
<HTML><HEAD><TITLE> . . .
10 z 38
1.6. Cookies
Wśród pół nagłówka znajduje się również pole Cookie. Pole to pozwala na zostawienie przez serwer określonej ilości
danych na dysku klienta oraz na wysłanie (podczas ponownej wizyty na danym serwerze) zostawionych u klienta
danych.
Dane te pozwalają serwerom np. na identyfikacje użytkowników podczas kolejnych wizyt na tych stronach.
Jest to mechanizm nieco kontrowersyjny ale bardzo często wykorzystywany.
Serwer wysyłając Cookie może określić czas ważności danego Cookie.
Zazwyczaj wysyłaną informacją jest określony numer użytkownika, który oprogramowanie po stronie serwera kojarzy z
daną osobą i może np. w zależności od wcześniej określonych preferencji użytkownika wyświetlić odpowiedni banner
reklamowy.
HTTP/1.0 200 OK
Date: Wednesday, 02-Feb-95 23:04:12 GMT
Server: NCSA/1.3
MIME-version: 1.0
Last-modified: Monday, 15-Nov-93 23:33:16 GMT
Set-Cookie: 1235212, 15-2
Content-type: text/html
Content-length: 2345
<CR><LF>
<HTML><HEAD><TITLE> . . .
1.7. Autoryzacja
Wprawdzie większość zasobów World Wide Web dostępna jest dla wszystkich, jednak pojawia się coraz więcej
serwisów, do których dostęp wymaga podania hasła. Hasło takie otrzymuje się zazwyczaj po wcześniejszej rejestracji.
Autoryzacja przebiega na podstawie pól protokołu HTTP, który specjalnie do tego celu wyposażono w procedury
pozwalające na rozpoznanie użytkownika i przyznanie mu praw dostępu do określonych zasobów WWW.
Jeśli na życzenie użytkownika przeglądarka żąda zastrzeżonej strony WWW, serwer wysyła odpowiedź o kodzie
"401", który oznacza, że użytkownik musi zostać jednoznacznie zidentyfikowany, zanim uzyska dostęp do zasobu.
Ponieważ protokół HTTP dopuszcza wiele różnych metod autoryzacji, w polu WWW Authenticate serwer określa, z
jakiego algorytmu korzysta i dla jakiej grupy zasobów wymagana jest autoryzacja. Przeglądarka po przyjęciu żądania
autoryzacji zmusza użytkownika do wpisania identyfikatora i hasła w odpowiednim okienku dialogowym.
Po wprowadzeniu hasła przeglądarka wysyła do serwera nowe zapytanie, przesyłając tym razem w polu Authenticate
hasło użytkownika. Aby przy następnej próbie otwarcia strony WWW nie trzeba było podawać tego samego hasła,
przeglądarka zapamiętuje hasła odpowiadające poszczególnym serwerom i później, w razie potrzeby, automatycznie
przesyła je do serwera.
We wcześniejszym etapie rozwoju Internetu taki mechanizm zabezpieczania witryn wystarczał.
Obecnie nie jest już wystarczający. Istotną wadą tej metody jest przesyłanie hasła nieszyfrowanym kanałem.
W HTTP/1.1 wprowadzono rozszerzenie mechanizmu autentyfikacji.
Metoda ta nazywa się Digest Authentification .
Zapewnia ona znacznie większy stopień bezpieczeństwa,
11 z 38
ponieważ niezaszyfrowane hasło w ogóle nie jest przesyłane. Aby użytkownik mógł się "przedstawić", serwer wysyła
do przeglądarki tzw. Challenge w postaci ciągu znakowego. Do tego ciągu przeglądarka dokleja hasło, po czym całość
szyfruje za pomocą algorytmu DIGEST. Dopiero tak przygotowany ciąg znaków wysyłany jest do serwera. Serwer po
swojej stronie łączy posiadane hasło z wysłanym wezwaniem, szyfruje je, a następnie sprawdza, czy to, co uzyskał,
zgodne jest z ciągiem przysłanym przez przeglądarkę.
12 z 38
2. Apache jako demon HTTPD
2.1. Rynek serwerów
Wśród najbardziej popularnych serwerów WWW liczy się tylko kilka :
-Apache
-Netscape
-IIS
-NCSA
Niezaprzeczalnie najpopularniejszym serwerem WWW jest Apache. W Polsce Apache ma 50% rynku. Jest to wartość
podobna, jak w innych krajach, gdzie Apache ma od 40% do 60% rynku (jedynym krajem, jaki znam gdzie Apache
ustępuje NCSA jest Japonia). Netscape w Polsce sumując różne odmiany (Enterprise, Commerce, FastTrack i
Communications) ma 5,7%, a Microsoft Internet Information Server ma 7,5%. Dane te są przedstawione na rysunku 2.
Jak widać na rysunku bardzo mocną pozycję ma wziąż serwer NCSA -- 10 % rynku i dość dobrą ma serwer CERN -- 2
%.
Rynek serwerów w Polsce
Apache
48%
NCSA
10%
IIS
8%
Netscape
6%
CERN
3%
inne
25%
Apache jest najpopularniejszym na rynku serwerem WWW. Jest wykorzystywany w większości witryn na świecie i
jego popularność wciąż rośnie. Jego historia wywodzi się z projektu NCSA.
13 z 38
Rynek serwerów na
świecie
Apache
59%
IIS
20%
Netscape
7%
inni
14%
2.2. Dlaczego Apache
Apache to jeden z najlepszych produktów w swojej klasie. Jego modułowa konstrukcja pozwala na rozbudowę
możliwości, nie ograniczając twórców modułów do danego języka programowania. Mogą one powstawać zarówno w
C, jak i w popularnym Perlu lub w PHP.
Istotną cechą jest poziom konfiguracji. Praktycznie wszelkie ustawienia zostały zgrupowane w pojedynczym pliku, co
znacznie ułatwia pracę wprawnym administratorom. Wszystkie dyrektywy, z których Apache korzysta, są opisane w
dokumentacji, zawierającej jednocześnie wiele przykładów rozwiązywania problemów najczęściej napotykanych przez
młodych adeptów administrowania serwerem WWW.
Prawa dostępu można określać na poziomie poszczególnych plików, grup plików opisanych wyrażeniami regularnymi,
katalogów, serwerów wirtualnych lub w odniesieniu do adresów IP, z których przychodzą zapytania. Umożliwia to
płynne prowadzenie polityki bezpieczeństwa i znacznie ułatwia wydzielanie tzw. bezpiecznych stref serwera. Liczne
moduły umożliwiają weryfikację danych klienta poprzez zwykłe pliki tekstowe z kodowanym hasłem, bazy danych czy
też usługi katalogowe LDAP.
Do ciekawszych dodatków rozszerzających funkcjonalność Apache'a należą przede wszystkim moduły mod_perl,
mod_php oraz mod_rewrite. Pierwszy z nich daje programującym w Perlu pełny dostęp do wszystkich wewnętrznych
faz obróbki zapytania przez serwer. Drugą istotną zaletą jest możliwość wykonywania dotychczas używanych skryptów
CGI ze średnio 10-krotnie większą prędkością, dzięki eliminacji tzw. faz fork i unfork. Moduł mod_php oferuje
wprawnym webmasterom osadzanie kodu popularnego ostatnio języka PHP w stronach HTML. Dzięki temu łatwe się
staje tworzenie w dość krótkim czasie nawet skomplikowanych aplikacji WWW. Ostatni z wymienionych modułów
oferuje możliwość "przepisywania" adresów URL w locie i jest jednym z najbardziej skomplikowanych i potężnych
modułów dostępnych dla serwera Apache.
+ wsparcie dla praktycznie wszystkich dostępnych obecnie technologii zawartych w konkurencyjnych serwerach
WWW
+ modułowa budowa i łatwość dostosowania do własnych możliwości open source
14 z 38
3. Uruchamianie
Aby uruchomić serwer apache należy wywołać polecenie httpd.
Program wywołany bez dodatkowych opcji poszukuje pliku konfiguracyjnego w podkatalogu conf.
Aby zmienić tą lokalizację należy użyć opcji –f.
Opcje wywołania serwera:
-D identyfikator : definiuje określony identyfikator używany w dyrektywach <IfDefine>
-d katalog : określa położenie głównego katalogu serwera
-f plik : określa położenie pliku konfiguracyjnego
-C „dyrektywa” : wykonuje zadaną dyrektywę przed rozpoczęciem przetwarzania pliku konfiguracji
-c „dyrektywa” : wykonuje zadaną dyrektywę po zakończeniu przetwarzania pliku konfiguracji
-v : wyświetla numer wersji apache’a
-V : wyświetla ustawienia kompilacji
-h : wyświetla wykaz dostępnych dyrektyw
-l : wyświetla listę modułów wchodzących w skład serwera
-S : wyświetla ustawienia pobrane z pliku konfiguracyjnego
Można również wykorzystać program apachectl dostarczany razem z serwerem. Służy on do uruchamiania,
zatrzymywania oraz zarządzania serwerem.
Parametry:
Start : uruchamia serwer
Stop : kończy pracę serwera
Restart : zatrzymuje i uruchamia serwer ponownie
Fullstatus : generuje raport o stanie serwera
Status : generuje skrócony raport o stanie serwera
Graceful : wymusza bezpieczny restart serwera.
Configtest : sprawdza poprawność konfiguracji
Polecenie ‘kill UID‘ (UID – id. procesu apache’a) zabija proces serwera.
Identyfikator procesu serwera można odczytać ze specjalnego pliku (określony w konfiguracji).
15 z 38
4. httpd.conf
Konfiguracji serwera apache dokonuje się przy pomocy specjalnego pliku konfiguracyjnego. Zazwyczaj jest to plik
httpd.conf znajdujący się w katalogu conf ale położenie tego pliku można określić uruchamiając program z parametrem
‘-f’. Zawartość tego pliku stanowią odpowiednie dyrektywy mające określone znaczenie i odnoszące się do określonej
części konfiguracji. Wielkość liter nazw dyrektyw nie jest znacząca przeciwnie do wartości parametrów tych dyrektyw.
W pliku tym dopuszcza się także stosowanie komentarzy(rozpoczynających się znakiem ‘#’) oraz na dołączanie innych
plików konfiguracyjnych (przy pomocy odpowiednich dyrektyw). Z powodów historycznych do plików
konfiguracyjnych zalicza się także pliki access.conf oraz srm.conf znajdujące się w katalogu razem z plikiem httpd.conf
lecz autorzy apache’a odchodzą od tego zwyczaju.
Kolejnym rozszerzeniem konfiguracji jest możliwość określenia ustawień osobnych dla różnych katalogów poprzez
zastosowanie plików .htaccess w których dokonuje się ustawień dla katalogu w którym znajduje się ten plik.
Ze względu na unix’owe pochodzenie serwera apache stosowana jest unix’owa konwencja oddzielania katalogów-
wszędzie (bez względu na system) w plikach konfiguracyjnych stosuje się ‘/’ do separacji katalogów(i plików).
4.1. Dyrektywy blokowe
Serwer Apache dysponuje bardzo rozwiniętymi możliwościami konfiguracyjnym. Jedną z większych zalet jest
możliwość ograniczenia pewnych fragmentów konfiguracji do poszczególnych katalogów, plików serwerów
wirtualnych.
<VirtualHost>
</VirtualHost>
Wszelkie fragmenty w pliku konfiguracyjnym zawarte pomiędzy tymi dyrektywami odnoszą się do konkretnego
serwera wirtualnego
Przykład:
<VirtualHost 192.149.45.10>
DocumentRoot /var/www/test/htdocs
ErrorLog /var/www/test/logs/error_log
TransferLog /var/www/test/logs/access_log
</VirtualHost>
<Directory>
16 z 38
...
</Directory>
Dyrektywy te ograniczają konfiguracje do określonego katalogu. Identyczną funkcję pełni dyrektywa
<DirectoryMatch>, która określa katalogi na podstawie wyrażenia regularnego.
Przykład:
<Directory /usr/local/httpd/htdocs>
...
</Directory>
<DirectoryMatch "^/www/day[1-7]">
...
</DirectoryMatch>
<Files>
...
</Files>
Użycie tej dyrektywy ogranicza działanie bloku dyrektyw do określonych przez parametr plików. Aby móc określić
pliki przy pomocy wyrażenia regularnego należy użyć dyrektywy <FilesMatch>
Przykład:
<Files special.html>
…
</Files>
<FilesMatch *.shtml>
...
</FilesMatch>
<Location>
...
</Location>
Dyrektywa <Location> pozwala na ograniczenie konfiguracji do określonych przez parametr adresów URL.
Analogicznie do w/w dyrektyw blokowych można zastosować <LocationMatch> w celu określenia adresów przy
pomocy wyrażenia regularnego.
Przykład:
<Location /extra/data>
…
</Location>
<Location /special/data>
…
</Location>
17 z 38
<LocationMatch "/(extra|special)/data">
...
</LocationMatch>
<IfDefine>
...
</IfDefine>
<IfDefine> pozwala na warunkowe dołączenie fragmentu konfiguracji do przetwarzania w przypadku zdefiniowanej
opcji określonej jako parametr tej dyrektywy. Opcję można dołączyć poprzez wywołanie serwera Apache z parametrem
–D opcja
Przykład:
<IfDefine DEBUG>
...
</IfDefine>
<IfModule>
...
</IfModule>
Dyrektywa pozwala na warunkowe dołączenie fragmentu konfiguracji w zależności od tego czy moduł (określony przez
parametr) został dołączony do programu.
Przykład:
<IfModule mod_rewrite.c.>
…
</IfModule>
4.2. .htaccess
Aby umożliwić wielu użytkownikom serwera pewną możliwość konfiguracji serwera WWW, bez konieczności zmian
w pliku konfiguracyjnym autorzy Apache’a udostępnili opcję, która pozwala na niemal dowolną (w zależności od
administratora systemu) zmianę konfiguracji serwera. Plik .htaccess umieszczony w określonym katalogu zmienia
sposób zachowania serwera dla plików znajdujących się w tym katalogu (i niżej).
Użycie tego pliku zastępuje użycie dyrektywy <Directory>, lecz niestety zmniejsza wydajność serwera(ponieważ przy
każdym odwołaniu do katalogu odczytywany jest plik konfiguracyjny).
Zmiany w pliku .htaccess są uaktywniane w momencie następnego odwołania do pliku z katalogu w którym znajduje
się ten plik (bez restartu systemu).
Zmiany domyślnej nazwy tego pliku dokonuje się przy użyciu dyrektywy <AccessFileName>
18 z 38
4.3. Konfiguracja serwera
Podstawowym fragmentem konfiguracji serwera apache jest ta część pliku httpd.conf, która odnosi się do działania
całego serwera. Jest to konfiguracja ogólna i niektóre jej fragmenty mogą zostać zmienione przez konfigurację
określonych katalogów.
Aby serwer apache mógł działać wystarczy plik konfiguracyjny uzupełnić o podstawowe dyrektywy:
<ServerRoot>
Składnia: ServerRoot katalog
Użycie: konfiguracja główna
Określa położenie katalogu w którym zainstalowano serwer apache.
Przykład:
ServerRoot /var/www
<DocumentRoot>
Składnia: DocumentRoot katalog
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta wskazuje apache’owi w którym katalogu znajdują się pliki HTML, które chcemy udostępniać innym
użytkownikom poprzez WWW.
Przykład:
DocumentRoot /var/www/htdocs
<ServerName>
Składnia: ServerName nazwa_domenowa
Użycie: konfiguracja główna, serwery wirtualne
Określa nazwę domenową serwera używaną w adresach URL.
Przykład:
<TransferLog>
Składnia: TransferLog plik | ‘|’ polecenie
Użycie: konfiguracja główna, serwery wirtualne
Określa lokalizacje pliku z logiem zapytań do serwera. Ciekawym rozszerzeniem tej dyrektywy jest użycie jako
parametru nazwy programu, który będzie odbierał (poprzez strumień wejściowy) generowane przez serwer. Przykładem
takiego zastosowania jest użycie do obsługi logów programu ‘rotatelogs’, który jest dostarczany razem z dystrybucją
serwera. Program ten okresowo zmienia pliki logów.
19 z 38
Przykład:
TransferLog /var/www/logs/access.log
<ErrorLog>
Składnia: ErrorLog plik|syslog[:funkcja]
Użycie: konfiguracja główna, serwery wirtualne
Określa lokalizacje pliku z logiem błędów, które wystąpiły w trakcie pracy serwera.
Przykład:
ErrorLog /var/www/logs/error.log
<ServerAdmin>
Składnia: ServerAdmin adres_e-mail
Użycie: konfiguracja główna, serwery wirtualne
Określa adres mailowy osoby, która jest odpowiedzialna za administracje serwera WWW. W przypadku wystąpienia
błędu przetwarzania często zazwyczaj generowana jest strona informująca o błędzie i tak umieszczany jest e-mail do
administratora strony.
Przykład:
W podstawowej instalacji proces serwera uruchamiany jest z uprawnieniami użytkownika root. Nie jest to zbyt
rozsądne rozwiązanie ze względu na bezpieczeństwo serwera. Zalecanym rozwiązaniem jest uruchomienie serwera z
uprawnieniami odrębnego użytkownika, który ma przydzielone minimalne uprawnienia, wymagane do udostępniania
stron WWW.
Aby móc skorzystać z tego rozwiązania konieczne jest utworzenie nowej grupy oraz nowego użytkownika (najlepiej
bez dostępu do shell’a). Następnie należy użyć dyrektywy
<User>
Składnia: User identyfikator
Użycie: konfiguracja główna, serwery wirtualne
Ustala identyfikator użytkownika przypisany serwerowi Apache.
Przykład:
User userwww
<Group>
Składnia: Group identyfikator
Użycie: konfiguracja główna, serwery wirtualne
Ustala identyfikator grupy przypisany serwerowi Apache.
Przykład:
Group groupwww
20 z 38
Aby użytkownik miał dostęp do dokumentów, które ma udostępniać poprzez www należy tym plikom dodatkowo
przydzielić odpowiednie uprawnienia.(dla katalogów: +x,+r,-w, dla plików +r,-x,-w).
Dodatkowo jeżeli chcemy aby użytkownik mógł wykonywać skrypty(CGI) należy nadać mu prawa uruchamiania tych
plików.
<ErrorDocument>
Składnia: ErrorDocument kod_błędu lokalizacja
Użycie: konfiguracja główna, serwery wirtualne, katalogi, .htaccess
Dyrektywa określa jaki dokument powinien zostać zwrócony klientowi w przypadku wystąpienia blędu o określonym
kodzie.
Przykład:
ErrorDocument 500 /error.html
ErrorDocument 404 /notfound.html
Przekierowanie może nastąpić do skrypty CGI, który może wykonać zdefiniowane przez autora czynności.
<DirectoryIndex>
Składnia: DirectoryIndex rozszerzenie
Użycie: konfiguracja główna, serwery wirtualne, katalogi, .htaccess
Określa plik, które ma zostać zwrócony do klienta w przypadku zapytania o katalog.
Przykład:
DirectoryIndex index.html index.php
<Pidfile>
Składnia: Pidfile plik
Użycie: konfiguracja główna
Dyrektywa określa położenie pliku w którym serwer zapisze identyfikator procesu (PID). Jest to korzystne w przypadku
konieczności zabicia procesu(kill),
Przykład:
Pidfile /var/www/logs/httpd.pid
<HostNameLookups>
Składnia: HostNameLookups on|off|double
Użycie: konfiguracja główna, serwery wirtualne, katalogi
Włączenie tej dyrektywy powoduje przy każdorazowym zapytaniu wykonane zostaje odwrotne odwzorowanie
adresu(revDNS). Informacja ta jest następnie zapisywana do logów.
Dodatkowo użycie jako parametru ‘double’ powoduje wykonanie dwukrotnego odwzorowania.
Użycie tej dyrektywy ma znaczenie przy autoryzacji dostępu.
21 z 38
Przykład:
HostNameLookups on
HostNameLookups double
<Options>
Składnia: Options [+|-] opcja [+|-] opcja ...
Użycie: konfiguracja główna, serwery wirtualne, katalogi, .htaccess
Dyrektywa Options jest bardzo uniwersalna i służy do ustawiania wielu różnych opcji:
-ExecCGI: pozwala na wykonywanie skryptów CGI.
-FollowSymLinks: pozwala na użycie linków
-Includes: pozwala na wykonywanie poleceń SSI
-Indexes: w przypadku na odwołanie się do katalogu zezwala na indeksowanie zawartości katalogu
-MultiViews: m.in. umożliwia uzgadnianie zawartości dokumentów w zależności od typu, wersji językowej
-SymLinksIfOwnerMatch: zezwala na użycie linków, jeżeli źródło i cel linku należą od tego samego użytkownika
Przykład:
Options +Indexes –FollowSymLinks +ExecCGI
<AddHandler>
Składnia: AddHandler nazwa rozszerzenie rozszerzenie ...
Użycie: konfiguracja główna, serwery wirtualne, katalogi, .htaccess
Dyrektywa uaktywnia istniejącą procedurę obsługi o danej nazwie i kojarzy ją z rozszerzeniami nazw plików.
Przykład:
AddHandler cgi-script cgi bat
<SetHandler>
Składnia: SetHandler nazwa
Użycie: katalogi, .htaccess
Dyrektywa działa podobnie do <AddHandler> ale obejmuje swym działaniem wszystkie pliki objęte dyrektywami:
<Directory>, <Location>, <Files> lub określone w pliku .htaccess
<Action>
Składnia: Action typ_pliku skrypt
Użycie: konfiguracja główna, serwery wirtualne, katalogi, .htaccess
Dyrektywa pozwala na przypisanie określonemu typowi plików (typ procedury obsługi) programu(skryptu), który przed
udostępnieniem go klientowi dokona wcześniejszego przetworzenia.
Przykład:
AddHandler moj-typ moje
Action moj-typ /cgi-bin/moj_skrypt
22 z 38
5. Moduły
Jedną z niewątpliwych zalet serwera apache jest jego modularna budowa i elastyczność.
Twórcy apache umożliwili programistom pisanie swoich własnych modułów, które mogą być dołączane dynamicznie
do serwera i realizować określone funkcje.
Właśnie ogromna ilość różnorodnych modułów stanowi o popularności serwera.
Moduły można dołączać statycznie w trakcie kompilacji lub dynamicznie w trakcie startu apache’a.
Aby móc dynamicznie dołączyć wybrany moduł należy w pliku konfiguracyjnym użyć dyrektywy LoadModule.
Częstym przypadkiem wykorzystania dynamicznie dołączanych modułów jest moduł mod_php, umożliwiający
udostępnianie stron napisanych w języku PHP.
Przykład:
LoadModule php4_module c:/php/sapi/php4apache.dll
LoadModule status_module modules/mod_status.so
5.1. Mod_perl
Mod_perl jest modułem pozwalającym na zastąpienie systemowego interpretera perla przez wbudowany, który jest
znacznie szybszy co zwiększa wydajność przetwarzania skryptów CGI napisanych w perlu.
Wydajność skryptów napisanych w perlu uruchamiana przy pomocy mod_perl jest 10 razy szybsza niż przy pomocy
systemowego interpretera perla.
5.2. Mod_php
Mod_php umożliwia serwowanie dokumentów napisanych w modnym ostatnio języku PHP.
Wykorzystanie PHP możliwe jest również bez tego modułu(patrz CGI).
5.3. Mod_rewrite
Moduł o ogromnych możliwościach.
Przy pomocy wyrażeń regularnych pozwala na zmianę adresów URL do których odwołują się klienci.
Moduł przydatny przy implementacji klastrów WWW.
5.4. Inne moduły
mod_access
Kontrola dostępu do plików w zależności od adresu IP i/lub nazwy komputera
23 z 38
klienta. Użycie tego modułu pozwala na dokładną kontrolę użytkowników, np.
administrator może zezwolić na wykonywanie skryptów CGI tylko pracownikom
firmy.
mod_actions
Odpowiada za wykonywanie skryptów CGI w zależności od typu danych lub
sposobu pobrania.
mod_alias
Pozwala mapować (udostępniać) część systemu plików w katalogu głównym
Apache'a, umożliwia też przekierowanie adresów URL. Część plików może
znajdować się poza katalogiem lub nawet na innym komputerze w sieci.
mod_asis
Deklaracja plików, które mogą być wysyłane bez nagłówków HTTP (pliki *.asis).
mod_auth
Moduł odpowiedzialny za uwierzytelnianie użytkowników na podstawie
zdefiniowanych plików tekstowych.
mod_auth_anon
Pozwala anonimowym użytkownikom na dostęp do danych podlegających
weryfikacji dostępu.
mod_auth_db
Uwierzytelnianie za pomocą plików DB (Berkeley).
mod_auth_dbm
Uwierzytelnianie za pomocą plików DBM.
mod_autoindex
Automatyczne tworzenie indeksów (wyświetlenie zawartości) dla katalogów,
które nie mają standardowych plików index.*htm*
mod_cern_meta
Emulacja plików CERN HTTPD, pozwala dodawać dodatkowe nagłówki do
wszystkich plików.
mod_cgi
Prawdopodobnie najpopularniejszy moduł. Pozwala wykonywać skrypty CGI po
stronie serwera i zwracać wyniki klientowi.
mod_digest
Uwierzytelnianie za pomocą algorytmu MD5.
mod_dir
Podstawowe operacje na katalogach. Zwykle używany do uzupełniania adresu,
np.
zostanie
zastąpiony
poprawnym
wywołaniem
mod_env
Moduł odpowiedzialny za przekazywanie zmiennych środowiskowych do
skryptów CGI/SSI.
mod_example
Demonstracja możliwości interfejsu programowego, Apache API.
mod_expires
Dodaje znacznik Expires (strona wygasa, traci ważność) do stron WWW
przesyłanych klientowi, ważne dla często zmienianych serwisów, które powinny
być zawsze aktualne.
mod_headers
Pozwala na dowolną modyfikację nagłówków HTTP.
mod_imap
Wsparcie dla map plików graficznych (.map), używane po stronie serwera
WWW. Zastępuje program CGI imagemap.
mod_include
Pozwala włączać zawartości plików lub wyniki działania skryptu do zwykłych
plików HTML i zwracać ich zawartość klientowi.
mod_info
Odpowiedzialny za informację o ustawieniach serwera Apache.
mod_isapi
Pozwala używać rozszerzeń serwerowych ISAPI. Tylko dla Apache'a w wersji
dla Windows.
mod_log_agent
Zapisywanie w logach nazw i wersji przeglądarek internetowych klientów.
mod_log_config
Konfigurowalne logowanie zdarzeń, pliki log zapisywane są w formacie
24 z 38
Common Logfile Format.
mod_log_referer
Logowanie odwołań do plików umieszczonych na serwerze.
mod_mime
Określenie typu pliku na podstawie rozszerzenia.
mod_mime_magic
Określenie typu pliku na podstawie kilku bajtów jego zawartości.
mod_mmap_static
Pozwala określić pewne niezmienne pliki, które zostaną umieszczone w pamięci
serwera Apache w celu szybszego dostępu.
mod_negotiation
Odpowiedzialny za uzgadnianie najlepszej reprezentacji danych w przeglądarce
klienta. Wprowadzony ze względu na zgodność z HTTP/1.1
mod_proxy
Apache staje się serwerem proxy dla stron WWW, przyspiesza dostęp do często
używanych danych, gdy serwer WWW (komputer) jest wykorzystywany do
zapamiętywania danych.
mod_setenvif
Pozwala modyfikować zmienne środowiskowe na podstawie wywołania (danych
klienta).
mod_so
Eksperymentalny. Ładowanie dodatkowych modułów podczas działania serwera.
mod_speling
Moduł odpowiedzialny za poprawianie pomniejszych błędów w adresach URL.
mod_status
Wyświetla bieżący stan serwera Apache.
mod_userdir
Ustawienia dotyczące katalogów domowych użytkowników.
mod_unique_id
Generuje unikalny identyfikator dla każdego żądania.
mod_usertrack
Śledzenie zachowania użytkowników za pomocą Cookies (tzw. ciasteczka),
szczególnie przydatne dla np. stałych klientów w sklepach internetowych lub do
określania preferencji użytkownika.
25 z 38
6. Serwery wirtualne
Serwer apache umożliwia uruchomienie wielu odrębnych witryn na jednym komputerze.
Jest to szczególnie przydatna i wykorzystywana możliwość zwłaszcza w firmach, które umożliwiają wielu klientom
utworzenie stron WWW na swoich serwerach.
Taką możliwość dają „serwery wirtualne” tworzone w obrębie jednego serwera apache.
Implementacja serwerów wirtualnych możliwa jest na kilka sposobów:
-serwery wirtualne identyfikowane adresami IP
-serwery wirtualne identyfikowane nazwami
-serwery wirtualne identyfikowane numerami portów
Do konfiguracji serwerów wirtualnych wykorzystywane są następujące dyrektywy:
6.1. serwery wirtualne identyfikowane adresami IP
Obecnie coraz rzadziej stosowanym rozwiązaniem jest tworzenie serwerów wirtualnych, którym odpowiadają inne
adresy IP.
Jest to spowodowane dwoma czynnikami:
-zakres adresów IP powoli się wyczerpuje
-protokół HTTP/1.1 umożliwia tworzenie serwerów o tym samym IP ale różnej nazwie domenowej
Do konfiguracji takiego serwera używa się dyrektywy <VirtualHost> której parametrem jest numer IP serwera.
Przykładowy fragment konfiguracji dwóch serwerów wirtualnych przedstawiony jest poniżej:
...
<VirtualHost 192.149.45.10>
DocumentRoot /var/www/test/htdocs
ErrorLog /var/www/test/logs/error_log
TransferLog /var/www/test/logs/access_log
</VirtualHost>
<VirtualHost 192.149.45.11>
DocumentRoot /var/www/proba/htdocs
ErrorLog /var/www/proba/logs/error_log
TransferLog /var/www/proba/logs/access_log
26 z 38
</VirtualHost>
...
Niestety nie wszelkie przeglądarki są zgodne z protokołem HTTP/1.1 dlatego rozwiązanie oparte o adresy IP nadal jest
wykorzystywane.
6.2. serwery wirtualne identyfikowane nazwami
Nieco innym rozwiązaniem jest tworzenie serwerów wirtualnych identyfikowanych nazwami. Jest to możliwe dzięki
temu, że w protokole HTTP/1.1 przeglądarki w zapytaniu przesyłają nazwę domenową witryny.
Zaletą tego rozwiązania jest wykorzystanie jednego adresu IP dla wielu serwerów wirtualnych.
Przykład konfiguracji:
...
NameVirtualHost 192.149.45.10
DocumentRoot /var/www/test/htdocs
ErrorLog /var/www/test/logs/error_log
TransferLog /var/www/test/logs/access_log
</VirtualHost>
DocumentRoot /var/www/proba/htdocs
ErrorLog /var/www/proba/logs/error_log
TransferLog /var/www/proba/logs/access_log
</VirtualHost>
...
Dyrektywa NameVirtualHost informuje apache, że żądania kierowane do danego adresu IP powinny być dalej
rozdzielane w zależności od nazwy domenowej witryny.
6.3. serwery wirtualne identyfikowane numerami portów
Jeszcze jednym rozwiązaniem pozwalającym na utworzenie kilku witryn jest utworzenie serwerów wirtualnych
identyfikowanych numerami portów.
Jest to sposób na uruchomienie kilku odrębnych serwisów w ramach tej samej nazwy domenowej i tego samego numeru
IP.
27 z 38
Przykład konfiguracji:
...
Listen 80
Listen 8000
<VirtualHost 192.149.45.10:80>
DocumentRoot /var/www/test/htdocs
ErrorLog /var/www/test/logs/error_log
TransferLog /var/www/test/logs/access_log
</VirtualHost>
<VirtualHost 192.149.45.10:8000>
DocumentRoot /var/www/test2/htdocs
ErrorLog /var/www/test2/logs/error_log
TransferLog /var/www/test2/logs/access_log
</VirtualHost>
...
28 z 38
7. CGI
7.1. Wstęp
Coraz więcej witryn używa różnego rodzaju skryptów do dynamicznego generowania stron.
Skrypty mogą w zależności od użycia np.
-zapisywać i przetwarzać dane pobrane od klientów poprzez formularze WWW
-pobierać dane z baz danych
-generować dynamiczne strony WWW
-rejestrować odwołania do stron i tworzyć statystyki
-chronić i/lub autoryzować dostęp do określonych części serwisu
Skryptem (programem) CGI można ogólnie nazwać każdy skrypt (program), który jest wykonywalne przez system
operacyjny na którym zainstalowany jest serwer WWW.
7.2. Formularze
CGI bardzo często wykorzystywane są do wprowadzania danych przez użytkownika poprzez formularze HTML.
Przykład formularza:
Zawartość formularza może zostać wysłana na dwa sposoby:
-metodą POST
<form action="http://www.serwer.pl/cgi-bin/post-query" method=post>
Item: <input typ=text name=ITEM><br>
Subitem: <input typ=text name=SUBITEM><br>
User: <input typ=text name=user><br>
<input type=submit value=wy
ślij>
</form>
POST /cgi-bin/post-query HTTP/1.0
Accept: text/html
29 z 38
Accept: video/mpeg
Accept: image/gif
Accept: application/postscript
User-Agent: Lynx/2.2 libwww/2.14
Content-type: application/x-www-form-urlencoded
Content-length: 150
<CR><LF>
ITEM=1234
&SUBITEM=10000
&user=john
-metodą GET
<form action="http://www.serwer.pl/cgi-bin/get-query" method=get>
Item: <input typ=text name=ITEM><br>
Subitem: <input typ=text name=SUBITEM><br>
User: <input typ=text name=user><br>
<input type=submit value=wy
ślij>
</form>
GET /cgi-bin/get-query?ITEM=1234&SUBITEM=10000&user=john HTTP/1.0
Accept: text/html
Accept: video/mpeg
Accept: image/gif
Accept: application/postscript
User-Agent: Lynx/2.2 libwww/2.14
. . .
Metoda POST zwykle używana jest do wysyłania większej ilości danych, gdyż ilość znaków które mogą zostać wysłane
metodą GET podlega ograniczeniu.
Dodatkowo dane przesyłane metodą POST nie są widoczne w pasku adresu przeglądarki.
Np.
http://www.serwer.pl/cgi-bin/get-query?ITEM=1234&SUBITEM=10000&user=john
7.3. Konfiguracja
Aby umożliwić wykonywanie skryptów CGI uprzednio należy odpowiednio skonfigurować serwer WWW, aby mógł
wykonywać skrypty lub programy napisane w różnych językach (np. w zależności od potrzeb użytkownika)
Częstym i zalecanym ze względów bezpieczeństwa nawykiem jest umieszczanie skryptów, które być uruchamiane
przez WWW w odrębnych katalogach(zwykle cgi-bin) dla których ustalamy odrębne uprawnienia oraz odpowiednio je
konfigurujemy.
Poniższe opcje służą do konfiguracji w/w katalogów i skryptów.
<ScriptAlias>
30 z 38
Składnia: ScriptAlias URL_prefiks katalog
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa pozwala na konwersje odwołań do adresów rozpoczynających się ciągiem URL_prefiks do programu CGI
położonego w katalogu określonym przez drugi parametr(dodatkowo muszą zostać ustawione odpowiednie prawa
dostępu do tego katalogu i skryptu).
Jednym z ciekawych zastosowań tego parametru jest imitacja katalogu przez skrypt CGI
Przykład:
ScriptAlias /cgi-bin /var/www/cgi-bin
<ScriptAliasMatch>
Składnia: ScriptAliasMatch wyrażenie_regularne katalog
Użycie: konfiguracja główna, serwery wirtualne
Funkcja zbliżona do <ScriptAlias> ale prefiks może zostać zastąpiony przez wyrażenie regularne
Przykład:
ScriptAliasMatch ^/cgi-bin/(*.cgi) /var/www/cgi-bin2/$1
<ScriptLog>
Składnia: ScriptLog plik
Użycie: konfiguracja główna
Dyrektywa umożliwia rejestracje błędów związanych z przetwarzaniem CGI w okeślonym przez parametr pliku.
Przykład:
ScriptLog /var/www/logs/cgi_log.err
<ScriptLogLength>
Składnia: ScriptLogLength liczba_bajtów
Użycie: konfiguracja główna
Określa maksymalny rozmiar pliku logów CGI
Przykład:
ScriptLogLength 10385760
<ScriptLogBuffer>
Składnia: ScriptLogBuffer liczba_bajtów
Użycie: konfiguracja główna
Określa maksymalny rozmiar pojedynczego bloku danych transakcji POST i PUT zapisywanego w pliku logów.
Przykład:
ScriptLogBuffer 1024
31 z 38
Istnieje także możliwość umieszczenia plików CGI w tym samym katalogu w którym znajdują się statyczne strony
HTML. Jest to rozwiązanie mniej bezpieczne. W obu przypadkach należy włączyć opcję zezwalającą na uruchamianie
CGI (ExecCGI).
W przypadku zastosowania odrębnego katalogu dla CGI fragment konfiguracji serwera wygląda następująco:
ServerName ww.test.pl
DocumentRoot /var/www/htdocs
Options +ExecCGI
ScriptAlias /cgi-bin /var/www/cgi-bin
Aby móc uruchamiać skrypty znajdujące się w katalogu ze stronami HTML należy dla skryptów CGI zdefiniować
odpowiednią procedurę obsługi(handler).
Przykładowa konfiguracja:
ServerName ww.test.pl
DocumentRoot /var/www/htdocs
Options +ExecCGI
AddHandler cgi-script cgi
Ten sposób obsługi plików jest wykorzystywany przy obsłudze skryptów napisanych w języku PHP(PHP jest bardzo
popularnym językiem używanym do dynamicznego generowania stron).
Strony napisane w języku PHP są po wywołaniu przez klienta przetworzone przez interpreter języka, a dopiero później
udostępniane klientowi.
Fragment konfiguracji realizujący to działanie:
ScriptAlias /php4/ "C:/php/"
Action application/x-httpd-php4 "/php4/php.exe"
AddType application/x-httpd-php4 .php
Skrypty CGI bardzo często korzystają ze zmiennych środowiskowych do określenia różnych parametrów.
Bardzo przydatną funkcją apache’a jest możliwość modyfikacji, definiowania lub usuwania zmiennych
przekazywanych do skryptów.
Możliwość ta może być przydatna w celach diagnostycznych w trakcie pisania skryptów.
<SetEnv>
Składnia: SetEnv zmienna wartość
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa pozwala na zdefiniowanie własnej zmiennej przekazywanej do skryptu.
Przykład:
SetEnv QUERY_STRING ?item=1&subitem=123
32 z 38
Przykład:
<VirtualHost host1>
SetEnv VHOST host_numer_jeden
...
</VirtualHost>
<VirtualHost host2>
SetEnv VHOST host_numer_dwa
...
</VirtualHost>
<UnsetEnv>
Składnia: UnsetEnv zmienna zmienna ..
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa usuwa podane zmienne środowiskowe
<PassEnv>
Składnia: PassEnv zmienna zmienna ..
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa przekazuje do skryptu wybrane zmienne środowiskowe.
Przykład:
PassEnv PATH
33 z 38
8. suExec
Skrypty CGI uruchamiane są przez serwer WWW z uprawnieniami użytkownika określonego przez dyrektywę <User>
lub użytkownika root. Jest to pewne niebezpieczeństwo ponieważ w ten sposób odpowiednio skonstruowane skrypty
mogą odczytywać(lub usuwać) pliki należące do tego użytkownika.
Aby temu zapobiec autorzy apache’a umożliwili wykorzystanie specjalnego programu(wrappera), który sprawdza
wykonywane skrypty pod kątem niebezpiecznych akcji oraz uruchamia je z odpowiednio zmodyfikowanymi
uprawnieniami.
Możliwy scenariusz ataku:
Apache jest uruchamiany z uprawnieniami użytkownika ‘userwww’. Inny użytkownik systemu uruchamia poprzez
przeglądarkę skrypt CGI, który usuwa pliki należące do użytkownika ‘userwww’.
Aby skonfigurować suExec należy odpowiednio zmodyfikować plik ‘suexec.h’ dostarczany razem ze źródłami
apache’a.
W pliku tym konfiguruje się m.in.:
-identyfikator użytkownika-właściciela procesu
-minimalną wartość UID użytkownika uruchamiającego suExec
-minimalną wartość GID grupy do której należy użytkownik uruchamiający suExec
-katalog w którym mogą znajdować się CGI
-plik z logiem suExec
Po skonfigurowaniu należy przekompilować serwer apache.
Działanie suExec:
SuExec przy każdorazowym wywołaniu skryptu sprawdza następujące warunki:
-czy ścieżka dostępu do skryptu zawiera ‘?’, ‘/’ lub ‘..’
-czy właściciel skryptu istnieje w systemie jako użytkownik
-czy istnieje w systemie grupa do której należy użytkownik uruchamiający CGI
-czy użytkownik uruchamiający CGI nie jest root’em
-czy UID użytkownika nie jest zbyt niski(niż określony w konfiguracji)
-czy grupa do której należy użytkownik nie jest grupą superużytkownika
-czy GID grupy nie jest zbyt niski(niż określony w konfiguracji)
-czy katalog w którym znajduje się CGI nie leży poza wyznaczonym obszarem
-czy inni użytkownicy nie mają dostępu do zapisu do katalogu ze skryptem
-czy uruchamiany skrypt nie jest programem setgid lub setuid
-usuwa niebezpieczne zmienne środowiskowe
-modyfikuje zmienną PATH
34 z 38
W przypadku nie spełnienia w/w warunków suExec nie zezwala na uruchomienie CGI i dodaje odpowiedni wpis do
pliku logów.
35 z 38
9. Proxy
9.1. Wstęp
Apache może pełnić rolę serwera proxy. Jest to rozwiązanie stosowane w przypadku podsieci zabezpieczonych
firewall’em.
Podsieć ma wtedy przeważnie zamknięty dostęp do sieci internet poprzez zablokowanie połączeń na większości portów
Wówczas odpowiednio skonfigurowany serwer udostępnia użytkownikom z podsieci dostęp do internetu.
Odpowiednio skonfigurowana przeglądarka WWW zamiast łączyć się bezpośrednio z żądanym serwerem łączy się z
określonym portem serwera proxy i kieruje do niego żądanie.
Serwer proxy następnie pobiera określoną stronę bezpośrednio od żądanego serwer(lub również poprzez inne proxy) a
następnie zwraca strony klientowi.
Rozszerzeniem serwera proxy jest buforowanie często pobieranych stron WWW, ograniczenie dostępu do określonych
„fragmentów” sieci lub monitorowanie odwiedzanych przez pracowników stron.
9.2. Konfiguracja
Aby skonfigurować apache’a jako serwer pośredniczący można skorzystać z następujących dyrektyw:
<ProxyRequests>
Składnia: ProxyRequests on|off
36 z 38
Użycie: konfiguracja głowna
Dyrektywa włącza funkcje serwera proxy.
<ProxyRemote>
Składnia: ProxyRemote wzorzec serwer_zdalny
Użycie: konfiguracja główna
Dyrektywa pozwala na określenie zdalnych serwerów proxy współpracujących z danym serwerem. Wzorzec może
określać jaki typ protokołu lub jakie adresy mają być obsługiwane przez dany serwer zdalny.
Przykład:
ProxyRemote ftp http://ftpproxy.test.pl:8080
ProxyRemote * http://w3cache.agh.edu.pl:8080
<ProxyPass>
Składnia: ProxyPass ścieżka URL
Użycie: konfiguracja główna
Dyrektywa pozwala na „przemapowanie” odwołań do określonego katalogu (i jego podkatalogów) na odwołania do
innego serwera.
Przykład:
ProxyPass /mirror http://onet.pl
<NoProxy>
Składnia: NoProxy domena|podsieć|adres-IP
Użycie: konfiguracja główna
Dyrektywa pozwala na określenie adresów(domen,podsieci) które są obsługiwane z pominięciem serwera proxy
Przykład:
<CacheRoot>
Składnia: CacheRoot katalog
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa pozwala na określenie katalogu w którym mogą być przechowywane buforowane strony.
<CacheSize>
Składnia: CacheSize rozmiar
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ustala pojemność pamięci podręcznej w kilobajtach
<CacheGCInterval>
Składnia: CacheGCInterval czas
Użycie: konfiguracja główna, serwery wirtualne
37 z 38
Dyrektywa
określa
odstęp(w
godzinach)
pomiędzy
kolejnymi
operacjami
usuwania
nadmiarowych
danych(przekraczających rozmiar pamięci podręcznej)
<CacheMaxExpire>
Składnia: CacheMaxExpire czas
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa określa maksymalny czas(w godzinach) przechowywania dokumentów w buforach pamięci podręcznej.
<CacheDefaultExpire>
Składnia: CacheDefaultExpire czas
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa określa czas ważności dla dokumentów pobranych za pomocą protokołu nie pozwalającego na ustalenie
okresu ważności.
<CacheDirLevels,CacheDirLength>
Składnia: CacheDirLevels(CacheDirLength) liczba(liczba)
Użycie: konfiguracja główna, serwery wirtualne
Przy pomocy w/w dyrektyw określa się sposób dzielenia nazw buforowanych plików i tworzenia z nich struktury
katalogów.
CacheDirLevels określa głębokość struktury katalogów
CacheDirLength określa długość nazwy podkatalogu
<NoCache>
Składnia: NoCache nazwa|domena nazwa|domena ...
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa określa nazwy domen dla których buforowanie stron nie będzie używane.
38 z 38
10. Źródła
10.1. WWW
http://webcompare.internet.com/webbasics/index.html
http://www.wdvl.com/Internet/Protocols/HTTP/
http://serverwatch.internet.com/
http://www.netcraft.com/survey/
10.2. Literatura
Ben Laurie, Peter Laurie - Apache . Przewodnik encyklopedyczny, wyd. HELION
Wyszukiwarka
Podobne podstrony:
httpd 4
HTTPD, J FORMS, Tworzenie formularzy HTML, mechanizm CGI
HTTPD, J HTTPD, httpd apache_1.0.3
httpd 3
httpd 4
httpd 2
więcej podobnych podstron