AKADEMIA GÓRNICZO-HUTNICZA
Wydział Elektrotechniki, Automatyki, Informatyki i
Elektroniki
KATEDRA INFORMATYKI
Referat z przedmiotu "Administracja systemami komp."
httpd - instalacja, konfiguracja, moduły, suEXEC,
PHP4, CGI, serwisy wirtualne
IV Informatyka
rok akad 2000/2001
Semestr letni
Prowadzący:
mgr.inż. Bogusław Juza
Skład zespołu:
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 2 z 44
Spis treści:
1
Instalacja i przygotowanie do pracy serwera Apache ......................................................4
1.1
Kompilacja ze źródeł ..............................................................................................4
1.1.1
Instalacja automatyczna ..................................................................................4
1.1.2
Instalacja półautomatyczna..............................................................................4
1.1.3
Struktura pliku Configuration:.........................................................................4
1.1.4
Dyrektywy zarządzające modułami: ................................................................5
1.1.5
Ustawienia i reguły konfiguracji......................................................................5
1.2
Uruchamianie i zatrzymywanie programu Apache ..................................................7
1.3
Opcje wywołania programu Apache........................................................................8
1.4
Pierwsza witryna WWW.........................................................................................8
2
Konfiguracja serwera Apache .........................................................................................9
2.1
Dyrektywy blokowe................................................................................................9
2.2
Pozostałe dyrektywy .............................................................................................11
2.2.1
Dyrektywy o charakterze administracyjnym: ................................................. 12
2.2.2
Dyrektywy dotyczące zarządzania procesami potomnymi .............................17
2.3
Procedury obsługi typów plików ........................................................................... 18
2.3.1
Dyrektywy służące do zarządzania procedurami obsługi: .............................. 18
3
Serwery wirtualne......................................................................................................... 19
3.1
Serwery wirtualne identyfikowane nazwami ......................................................... 20
3.2
Serwery wirtualne identyfikowane adresami IP..................................................... 21
3.3
Serwery wirtualne identyfikowane nazwami domenowymi i adresami IP..............22
3.4
Serwery wirtualne identyfikowane numerami portów............................................ 22
3.5
Kilka kopii serwera Apache działające w systemie................................................ 23
4
Zmiana konfiguracji serwera w trakcie pracy................................................................ 25
4.1
Ponowne uruchamianie serwera ............................................................................ 25
4.2
lokalne pliki konfiguracyjne (.htaccess) ................................................................ 25
5
Interfejs CGI................................................................................................................. 26
5.1
Skrypt w katalogu cgi-bin ..................................................................................... 28
5.2
Skrypt w głównym katalogu dokumentów............................................................. 28
5.3
Dyrektywy zarządzające obsługą skryptów: .......................................................... 28
5.4
Dyrektywy służące do ograniczenia zasobów dla skryptów:..................................29
5.5
Pobieranie danych w skryptach CGI ..................................................................... 30
6
Program suEXEC i jego zastosowanie .......................................................................... 30
6.1
Instalacja programu suEXEC ................................................................................ 31
6.2
Działanie programu suEXEC ................................................................................ 32
7
Moduły programu Apache ............................................................................................33
7.1
Dynamic Shared Object (DSO) ............................................................................. 33
7.2
Implementacja ......................................................................................................34
7.3
Przykład użycia: ...................................................................................................34
7.3.1
Umieszczanie całego kodu Apache w bibliotece DSO: .................................. 34
7.3.2
Kompilacja i instalacja modułu Apache pochodzącego z dystrybucji w pliku
DSO
35
7.3.3
Kompilacja i instalacja własnego modułu Apache w pliku DSO ....................35
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 3 z 44
7.3.4
Kompilacja i instalacja własnego modułu Apache w pliku DSO poza drzewem
Apache 36
7.4
Zalety i wady DSO ...............................................................................................36
8
PHP4 ............................................................................................................................ 37
8.1
Instalacja .............................................................................................................. 37
8.1.1
Instalacja jako DSO....................................................................................... 37
8.1.2
Instalacja jako moduł statyczny .....................................................................38
9
Apache jako serwer pośredniczący (proxy) ...................................................................39
9.1
Dyrektywy sterujące serwerem pośredniczącym ................................................... 40
9.2
Buforowanie stron................................................................................................. 42
10
Materiały ..................................................................................................................44
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 4 z 44
1 Instalacja i przygotowanie do pracy serwera Apache
1.1 KOMPILACJA ZE ŹRÓDEŁ
Pierwszym krokiem jest pobranie i rozpakowanie kodu źródłowego Apache
(lista serwerów z kodem Apache jest dostępna pod :
).
Pliki z kodem są spakowane do postaci .tar.gz lub tar.Z.
1.1.1
Instalacja automatyczna
Możliwość automatyzacji procesu kompilacji i konfiguracji Apache pojawiła
się od wersji 1.3. Obecnie zadanie to jest realizowane przez skrypt configure i
związany z nim plik Makefile.tmpl (oba umieszczone w głównym katalogu
instalacyjnym).
Polecenia uruchamiające automatyczną kompilację Apache:
% ./configure
% cd src
% make
1.1.2
Instalacja półautomatyczna
Jeśli mamy źródła w wersji beta, należy przede wszystkim utworzyć kopię
pliku .../src/Configuration.tmpl o nazwie Configuration. Plik ten należy
następnie wyedytować w celu ustalenia odpowiedniej konfiguracji programu.
Informacje z plików Configuration i Makefile.tmpl są następnie przetwarzane
przez skrypt configure, czego wynikiem jest właściwy plik Makefile dla
Apache.
W większości przypadków modyfikacje pliku Configuration sprowadzają się
do zaznaczenia w nim modułów, które mają zostać włączone do
kompilowanego kodu. Określenia modułów można również dokonać za
pomocą parametrów przekazywanych w wierszu poleceń.
1.1.3
Struktura pliku Configuration:
Plik Configuration może zawierać następujące elementy:
ü Komentarze – rozpoczynające się znakiem #. Większość komentarzy
poprzedza wiersze zawierające polecenia włączenia modułów.
ü Reguły konfiguracyjne, rozpoczynające się słowem Rule
ü Polecenia umieszczane w pliku Makefile, nie zawierające prefiksu
ü Polecenia włączania modułów, rozpoczynające się słowem AddModule,
określające moduły, które mają zostać włączone do kodu wynikowego i
uaktywnione
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 5 z 44
ü Polecenia opcjonalnego włączenia modułów, rozpoczynające się
ciągiem %Module, określające moduły dołączone, lecz nieaktywne do
czasu wydania odpowiedniej dyrektywy.
Moduły są samodzielnymi blokami kodu źródłowego, obsługującymi
poszczególne funkcje programu Apache. Aby włączyć dany moduł do
kompilowanego kodu, wystarczy usunąć znak komentarza w odpowiedniej
linii pliku Configuration
Tworząc skrypty konfiguracyjne serwera można wykorzystywać dyrektywę
IfModule, pozwalającą uwzględnić obecność lub nieobecność modułu.
Przykładowo, aby uwzględnić obecność (lub brak) modułu odpowiadającego
za pliki logów można zastosować następującą konstrukcję:
<IfModule mod_log_config.c>
LogFormat “klient….”
</IfModule>
1.1.4
Dyrektywy zarządzające modułami:
ü ClearModuleList – dyrektywa ta usuwa wszystkie pozycje z listy
aktywnych modułów. Od momentu jej wydania Apache nie
będzie korzystał z żadnych modułów aż do chwili wydania
dyrektywy AddModule.
ü AddModule m1 m2 .. – dyrektywa ta uaktywnia moduły
wyszczególnione na liście. Moduły muszą zostać włączone do
kodu wynikowego podczas kompilacji za pomocą instrukcji
AddModule w pliku Configuration.
1.1.5
Ustawienia i reguły konfiguracji
Jeśli zachodzi konieczność ustalenia dodatkowych opcji kompilatora,
bibliotek czy plików włączanych, można tego dokonać przez zdefiniowanie
zmiennych:
EXTRA_CFLAGS=
EXTRA_LDFLAGS=
EXTRA_LIBS=
EXTRA_INCLUDES=
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 6 z 44
Skrypt Configure stara się samodzielnie ustalić dane o używanym systemie
operacyjnym i kompilatorze, toteż uaktywnianie i nadawanie wartości
zmiennym
#CC=
#OPTIM=02
#RANLIB=
jest w normalnych okolicznościach zbędne.
Umieszczane w pliku Configuration reguły pozwalają zaradzić kilku bardziej
niecodziennym problemom związanym z konfiguracją. Ogólna składnia
reguły wygląda następująco:
Rule NAZWA=warto
ść
Dopuszczalne wartości to:
ü Yes – żądana operacja jest wykonywana zgodnie z treścią reguły
ü Default – skrypt stara się samodzielnie dobrać najlepsze
rozwiązanie.
A oto lista podstawowych reguł, których można użyć:
STATUS – w przypadku użycia wartości yes skrypt Configure sprawdza, czy
moduł raportowania stanu serwera jest włączony. Jeśli tak, generowane
będą pełne informacje o stanie serwera. W przeciwnym przypadku reguła jest
ignorowana.
SOCKS4 – SOCKS jest protokołem przesyłania pakietów przez firewalle, w
którym informacje przetwarzane są częściowo po stronie klienta (więcej
informacji
na
stronie:
ftp://ftp.nec.com/pub/security/socks.csts
).
Uaktywnienie tej reguły pozwala serwerowi Apache realizować wychodzące
połączenia SOCKS, co znajduje zastosowanie jedynie w przypadku użycia go
jako serwera pośredniczącego. W przypadku ustawienia tej wartości na yes
należy pamiętać o dopisaniu do zmiennej EXTRA_LIBS ścieżki do bibliotek
SOCKS (lub skrypt configure przyjmie dla niej domyślną wartość : -
L/usr/local/lib –lsocks). Domyślna wartość tej reguły to no.
SOCKS5 – reguły tej należy użyć zamiast SOCKS4 w przypadku, gdy chcemy
korzystać z plików SOCKS 5.
IRIXNIS – w przypadku instalacji Apache w środowisku IRIX firmy Silicon
Graphics należy tej regule nadać wartość yes w przypadku użycia usług NIS.
Domyślna wartość to no
IRIXN32 – jeśli Apache instalowany jest w środowisku IRIX użycie wartości
yes nakazuje wykorzystanie bibliotek n32 zamiast o32. Domyślna wartość to
yes
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 7 z 44
PARANOID – w trakcie wykonywania skryptu Configure istnieje możliwość
wywołania przez moduły poleceń powłoki systemu. Ustalenie tej regule
wartości yes nakazuje drukowanie instrukcji wykonywanych przez moduły.
Domyślna wartość to no.
Oprócz powyższych istnieje grupa reguł, które skrypt konfiguracyjny stara
się ustalić samodzielnie. Mogą być one w razie potrzeby predefiniowane przez
użytkownika. W obecnej chwili grupa ta zawiera jedynie jedną regułę:
WANTHSREGEX – interpretacja wyrażeń regularnych odbywa się w Apache
zgodnie z konwencją POSIX. Apache zawiera własny pakiet do analizy
wyrażeń regularnych, jednak w razie potrzeby może wykorzystać
mechanizmy systemu operacyjnego. W takiej sytuacji należy tej regule nadać
wartość no, lub zablokować ją znakiem komentarza. Domyślna wartość
reguły wynosi no (może ona zostać zmieniona przez system operacyjny).
Po zakończeniu edycji pliku Configuration należy wydać następujące
polecenia:
% ./Configure
% make
1.2 URUCHAMIANIE I ZATRZYMYWANIE PROGRAMU APACHE
Aby uruchomić serwer należy po prostu uruchomić program httpd. Program
ten wczyta plik httpd.conf, który powinien być umieszczony w miejscu
wkompilowanym w kod (domyślnie /usr/local/apache/conf/httpd.conf).
Jeśli ten plik znajduje się w innym miejscu, należy wywołać program httpd z
jego ścieżką jako parametrem:
/usr/local/apache/httpd –f sciezka_do_httpd.conf
Jeśli coś się nie udało, na ekranie pojawi się komunikat o błędzie. W
przeciwnym przypadku serwer został uruchomiony i pracuje. W momencie
uruchomienia program serwera tworzy kilka procesów potomnych. Jeśli
Apache został uruchomiony przez roota, główny proces pozostanie jego
własnością, natomiast procesy potomne będą należały do użytkownika
podanego w pliku httpd.conf.
Aby serwer mógł działać po restarcie systemu, należy dodać odpowiednie
wpisy do plików startowych systemu (zazwyczaj rc.local lub plik w katalogu
rc.N ). Te wpisy spowodują uruchomienie Apache przez roota.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 8 z 44
Aby zatrzymać serwer, należy zatrzymać proces główny. PID procesu
głównego jest zapisywany do pliku httpd.pid w katalogu z logami (chyba, że
serwer zostanie inaczej skonfigurowany). Nie ma sensu zatrzymywać
procesów potomnych, gdyż zostaną one od nowa utworzone przez proces
główny.
Zazwyczaj komenda służąca do zatrzymania serwera będzie wyglądała
następująco:
kill –TERM `cat /usr/local/apache/logs/httpd.pid`
1.3 OPCJE WYWOŁANIA PROGRAMU APACHE
Uruchamiając program serwera (httpd) można użyć następujących opcji:
ü
-D identyfikator – definiuje identyfikatory używane w
dyrektywach <IfDefine>
ü
-d katalog – określa położenie głównego katalogu serwera
(ServerRoot)
ü
-f nazwa-pliku – określa położenie pliku konfiguracji serwera
ü
-C “dyrektywa” – wykonuje zadaną dyrektywę przed rozpoczęciem
przetwarzania pliku konfiguracji serwera
ü
-c „dyrektywa” – wykonuje zadaną dyrektywę po zakończeniu
przetwarzania pliku konfiguracji serwera
ü
-v – wyświetla numer wersji serwera
ü
-V – Wyświetla ustawienia kompilacji
ü
-h – wyświetla wykaz dostępnych dyrektyw
ü
-l – wyświetla listę modułów wchodzących w skład kodu
programu
ü
-S – wyświetla ustawienia pobrane z pliku konfiguracji (obecnie
wyłącznie opis bloków <VirtualHost>)
ü
-X – uruchamia pojedynczą kopię serwera. Opcja ta
przeznaczona jest wyłącznie do celów diagnostycznych i nie
powinna być używana w innych okolicznościach . Może ona
spowodować znaczne spowolnienie obsługi żądań.
1.4 PIERWSZA WITRYNA WWW
Z punktu widzenia Apache witryna WWW to po prostu katalog położony
gdzieś w systemie plików serwera. Katalog ten powinien zawierać co najmniej
trzy podkatalogi:
ü
conf – tu znajduje się plik konfiguracji serwera, instruujący
Apache w jaki sposób ma sobie radzić z różnymi rodzajami
kierowanych do niego żądań.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 9 z 44
ü
htdocs – tu znajdują się dokumenty, pliki graficzne i inne dane,
przekazywane klientom zgłaszającym żądania
ü
logs – ten podkatalog zawiera pliki logów, rejestrujących przebieg
działalności serwera.
Aby utworzyć witrynę, należy stworzyć katalog odpowiadający jej nazwie, a w
nim podkatalogi wymagane przez program Apache do pracy. Następnym
krokiem jest edycja plików konfiguracyjnych serwera.
W katalogu ServerRoot/conf znajdują się następujące pliki: srm.conf-dist,
access.conf-dist i httpd.conf-dist. W praktyce zalecane jest przechowywanie
wszystkich informacji w pliku httpd.conf-dist oraz pozbycie się pozostałych
(zostały wprowadzone jedynie dla zachowania zgodności ze standardem
NCSA). W wersjach wcześniejszych niż 1.3 należało oprócz usunięcia plików
wyczyścić odwołania do nich, natomiast począwszy od wersji 1.3 Apache
zadowala się stwierdzeniem, ze dany plik nie istnieje.
2 Konfiguracja serwera Apache
2.1 DYREKTYWY BLOKOWE
Apache udostępnia cały szereg tzw. dyrektyw blokowych, które pozwalają
ograniczyć zasięg działania zawartych w nich innych dyrektyw do
określonych serwerów wirtualnych, katalogów czy też plików. Dyrektywy
blokowe są niezwykle istotne w praktyce, gdyż to one umożliwiają
administratorowi uruchomienie większej liczby niezależnych serwerów WWW
poprzez pojedyncze wywołanie programu Apache. Tworzenie serwerów
wirtualnych zostanie omówione później.
<VirtualHost>
użycie: konfiguracja główna
składnia:
<VirtualHost serwer[:port]>
...
</VirtualHost>
dyrektywa ta pozwala określić nazwę domenową lub adres IP (I ewentualnie
numer portu) przypisany do danego serwera wirtualnego. Domyślnie
wykorzystywany jest port 80 lub port określony za pomocą dyrektywy Port.
Użycie w miejscu argumentu serwer ciągu _default_ powoduje, że zawartość
bloku będzie się odnosiła do wszystkich serwerów nie uwzględnionych w
innych blokach <virtualHost>. Zazwyczaj serwer jest nazwą domenową lub
adresem IP naszego hosta.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 10 z 44
Wewnątrz dyrektywy blokowej <VirtualHost> można używać niemal
wszystkich dyrektyw, za wyjątkiem następujących: ServerType, StartServers,
MaxSpareServers, MinSpareServers, MaxRequestsPerChild, BindAddress,
Listen, PidFile, TypesConfig, ServerRoot, NameVirtualHost. Dyrektywy User i
Group mogą zostać użyte wewnątrz bloku <VirtualHost> jeśli używany jest
program suEXEC.
<Directory> i <DirectoryMatch>
użycie: konfiguracja główna, serwery wirtualne
składnia:
<Directory katalog>
...
</Directory>
Dyrektywa ta pozwala na ograniczenie zasięgu działania bloku dyrektyw do
wybranego katalogu lub grupy katalogów. Należy tu podkreślić, że
specyfikacja katalogu traktowana jest jako bezwzględna, tj. dyrektywa
<Directory /> obejmie swoim działaniem nie system plików Apache, ale cały
system plików, poczynając od katalogu głównego. Nazwa katalogu może
zawierać symbole wieloznaczne „?” i „*”, a także nawiasy kwadratowe ([]),
służące do definiowania grup znaków. Umieszczenie znaku tyldy (~) na
początku nazwy katalogu pozwala na użycie w niej kompletnych wyrażeń
regularnych.
Dyrektywa <DirectoryMatch> działa tak samo, jak <Directory ~>.
<Files> i <FilesMatch>
użycie: konfiguracja główna, serwery wirtualne, pliki .htaccess.
składnia:
<Files plik>
...
</Files>
Dyrektywa ta pozwala ograniczyć działanie bloku dyrektyw do plików o
nazwie zadanej parametrem plik. Nazwa ta określana jest względem katalogu
DocumentRoot i może zawierać symbole wieloznaczne oraz wyrażenia
regularne poprzedzone znakiem ~. Dyrektywa <FilesMatch> używana jest
wraz z wyrażeniami regularnymi nie poprzedzonymi znakiem tyldy.
<Location> i <LocationMatch>
użycie: konfiguracja główna, serwery wirtualne
składnia:
<Location adres-URL>
...
</Location>
Użycie tej dyrektywy pozwala na ograniczenie zasięgu działania bloku
dyrektyw do zadanych adresów URL. Podobnie jak poprzednio, adresy mogą
zawierać symbole wieloznaczne oraz wyrażenia regularne poprzedzone
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 11 z 44
znakiem tyldy. W Apache od wersji 1.3 znaki „?” i „*” nie są zgodne ze
znakiem „/”.
Działanie dyrektywy <Directory> może zostać zmienione przez dyrektywę
<Files>, a ta z kolei przez nadrzędną do niej dyrektywę <Location>.
<IfDefine>
składnia:
<IfDefine nazwa>
...
</IfDefine>
Dyrektywa ta pozwala na warunkowe uaktywnienie bloku dyrektyw w
przypadku uruchomienia programu Apache z opcją –D nazwa. Pozwala to na
zamknięcie kilku wariantów konfiguracji w pojedynczym pliku httpd.conf.
<IfModule>
składnia:
<IfModule [!]nazwa_modu
łu>
...
</IfModule>
Dyrektywa ta pozwala na warunkowe uaktywnienie bloku dyrektyw w
zależności od tego czy moduł o danej nazwie został dołączony do programu
Apache. Poprzedzenie nazwy modułu znakiem „!” powoduje uaktywnienie
dyrektyw w przypadku, gdy moduł nie został dołączony. Bloki ograniczone
dyrektywami <IfModule> mogą być zagnieżdżane.
2.2 POZOSTAŁE DYREKTYWY
User identyfikator-uzytkownika
Użycie: konfiguracja główna, serwery wirtualne
Wartość domyślna: #-1
Dyrektywa ta ustala identyfikator użytkownika przypisywany serwerowi
Apache. Jej użycie wymaga uprzedniego uruchomienia głównego procesu
serwera, należącego do użytkownika root. Identyfikator użytkownika to:
§ Nazwa identyfikująca użytkownika przez nazwę jego konta
lub
§ #numer identyfikujący użytkownika przez jego numer w
systemie.
Tak identyfikowany użytkownik nie powinien mieć żadnych praw dostępu do
plików innych niż te, które chcemy udostępnić na WWW. Użytkownik ten nie
może również mieć prawa do wykonywania jakichkolwiek programów, które
nie są przeznaczone do uruchamiania w odpowiedzi na żądania obsługiwane
przez program httpd. Zaleca się utworzenie użytkownika i grupy
dedykowanych wyłącznie dla potrzeb serwera WWW.
Group identyfikator-grupy
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 12 z 44
Użycie: konfiguracja główna, serwery wirtualne
Wartość domyślna: #-1
Dyrektywa ta określa identyfikator grupy przypisywany serwerowi Apache.
Jej użycie musi być poprzedzone uruchomieniem głównego procesu serwera,
należącego do użytkownika root. Identyfikator grupy to:
§ Nazwa identyfikująca grupę poprzez jej nazwę lub
§ #numer identyfikujący grupę poprzez podanie jej numeru
Również i w tym przypadku zaleca się utworzenie oddzielnej grupy wyłącznie
na potrzeby serwera.
2.2.1
Dyrektywy o charakterze administracyjnym:
ServerName nazwa-domenowa
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta definiuje nazwę domenową serwera
DocumentRoot sciezka-dostepu
Użycie: konfiguracja główna, serwery wirtualne
Wartość domyślna: /usr/local/apache/htdocs
Dyrektywa ta określa nazwę katalogu, zawierającego pliki udostępniane
przez serwer WWW. O ile w pliku konfiguracji serwera nie użyto dyrektywy
Alias, ścieżka wyodrębniona z odebranego przez serwer adresu URL jest
dołączana do sciezki-dostępu podanej w dyrektywie, a powstała nazwa
identyfikuje położenie żądanego dokumentu.
TransferLog
– określa położenie pliku logów udanych transakcji
ErrorLog
– określa położenie pliku logów błędów
UseCanonicalName on|off
Użycie: konfiguracja główna, serwery wirtualne, katalogi, pliki .htaccess
Dyrektywa ta steruje sposobem tworzenia przez Apache adresów
wskazujących „na siebie”, co ma miejsce np. w przypadku przeadresowania
odwołania do adresu
http://www.aaa.bb.com/jakiskatalog
do poprawnej
formy
http://www.aaa.bb.com/jakiskatalog/
znaku „/”). W przypadku włączenia tej dyrektywy do przeadresowania
zostanie użyta nazwa serwera i numer portu zadane dyrektywami
ServerName i Port. Jej wyłączenie spowoduje użycie nazw określonych w
oryginalnym żądaniu.
Dyrektywa ta przydaje się w przypadku, gdy komputery użytkowników
należą do tej samej domeny, co serwer. W takim przypadku użytkownik może
odwoływać się do serwera za pomocą nazwy skróconej (np.”www”), zamiast
wpisywać
nazwę
pełną
(np.
Jeśli
dyrektywa
UseCanonicalName jest aktywna, podanie przez użytkownika adresu bez
końcowego znaku „/” (np.
http://www/katalog
) spowoduje przeadresowanie
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 13 z 44
żądania do adresu URL
/, podczas gdy przy
wyłączonej dyrektywie żądanie trafiłoby pod adres http://www/katalog/
ServerAdmin adres_e-mail
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta pozwala zdefiniować adres poczty elektronicznej, umieszczany
automatycznie przez Apache na stronach generowanych w przypadku
wystąpienia błędu.
ListenBacklog liczba
Wartość domyślna: 511
Użycie: konfiguracja główna
Dyrektywa ta określa maksymalną długość kolejki połączeń oczekujących na
obsłużenie. W normalnych warunkach operacja ta jest zbyteczna, jednak
może okazać się zbawienna w przypadku dokonania na serwer ataku metodą
SYN flooding, polegającą na inicjalizowaniu dużej liczby połączeń bez ich
finalizowania. W niektórych systemach takie nie do końca zrealizowane
połączenia są kolejkowane, co może doprowadzić do wyczerpania zasobów i
„zdławienia” systemu.
Dodatkowe informacje na temat dyrektywy ListenBacklog można znaleźć w
opisie parametru backlog w man pod hasłem listen(2)
ServerType inetd|standalone
Wartość domyślna: standalone
Użycie: konfiguracja główna
Dyrektywa ta określa sposób zarządzania przez Apache procesami
potomnymi.
•
Inetd – użycie tej wartości zabrania serwerowi Apache
uruchamiania całej grupy procesów potomnych oczekujących na
nadejście żądania obsługi. W zamian za to odebranie każdego
żądania powoduje uruchomienie pojedynczej kopii, która po
obsłużeniu żądania jest likwidowana. Metoda ta jest wolniejsza,
jednak redukuje konsumpcję zasobów systemu w okresach „biegu
jałowego”. Użycie serwera Apache w trybie inetd wymaga
odpowiedniego skonfigurowania demona systemowego inetd za
pomocą pliku /etc/inetd.conf. Wiersz definiujący ustawienia dla
Apache powinien mieć postać:
http stream tcp nowait root /usr/local/bin/httpd httpd –d katalog
•
Standalone – użycie tej wartości nakazuje serwerowi utworzenie
zbioru procesów potomnych oczekujących na nadchodzące
żądania.
ServerSignature off|on|email
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 14 z 44
Użycie: katalogi, plik .htaccess
Wartość domyślna: off
Dyrektywa ta umożliwia zidentyfikowanie serwera, który faktycznie obsłużył
dane żądanie (co ma znaczenie np. w przypadku użycia serwerów
pośredniczących).
Jej
włączenie
(ServerSignature
on)
powoduje
automatyczne dołączenia do generowanych przez serwer dokumentów stopki
(sygnatury), zawierającej numer wersji programu serwera i nazwę serwera
wirtualnego zdefiniowaną w dyrektywie ServerName. Użycie formy
ServerSignature email dodaje do stopki łącze mailto: zawierające adres
określony dyrektywą ServerAdmin.
ServerTokens min[imal]|OS|full
Użycie: konfiguracja główna
Wartość domyślna: full
Dyrektywa ta ustala zakres informacji, jakimi przedstawia się serwer
Apache:
§ Min[imal] – serwer zwraca tylko swoją nazwę i numer wersji
§ OS – servwer zwraca swoją nazwę i numer wersji oraz nazwę
macierzystego systemu operacyjnego
§ Full – serwer zwraca dane oisane powyżej oraz informacje o
wchodzących w skład jego kodu modułach
ServerAlias nazwa1 nazwa2 ...
Użycie: serwery wirtualne
Dyrektywa ServerAlias pozwala na zdefiniowanie listy alisaów, czyli
synonimów nazw identyfikujących dany serwer wirtualny. Protokół
HTTP/1.1 umożliwia odwołanie się do serwera poprzez nazwę za pomocą
pola Host: nagłówka HTTp. Podana w nagłówku nazwa powinna odowiadać
którejś z nazw zdefiniowanych w dyrektywach ServerName, ServerAlias lub
VirtualHost.
ServerPath sciezka
Użycie: serwery wirtualne
Protokół HTTP/1.1 umożliwia związanei z tym samym adresem IP kilku nazw
domenowych serwerów. W takiej sytuacji klient identyfikuje odpowiedni
serwer poprzez przesłanie w nagłówku żądania poal Host: nazwa-serwera.
Chociaż migracja do protokołu HTTP została już prawie zakończona, niektóre
przeglądarki będą zapewne jeszcze przez jakiś czas używały protokołu
HTTP/`.0 nie przesyłając pól Host. Z tego też względu stworzono dyrektywę
ServerPath, pozwalającą na dostęp do witryny przez podanie ścieżki
ServerRoot katalog
Użycie: konfiguracja główna
Wartość domyślna: /usr/local/etc/htppd
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 15 z 44
Dyrektywa ta określa położenie podkatalogów conf. i logs, zawierających pliki
konfiguracyjne oraz pliki logów. Jest ona wymagana w przypadku
uruchomienia programu Apache z opcją –f, natomiast użycie opcji –d
pozwala na jej pominięcie.
PidFile plik
Użycie: konfiguracja główna
Wartość domyślan: logs/httpd.pid
Jednym z ważniejszych parametrów opisujących pracujący program jest
przypisany mu identyfikator procesu (PID). Serwer Apache zapisuje tę
wartość w pliku, którego położenie określa właśnie dyrektywa PidFile.
Domyślnie plik ten nosi nazwę httpd.pid i jest umieszczany w podkatalogu
.../logs. Wartość odczytaną z tego pliku można wykorzystać do zatrzymania
procesu poleceniem kill.
ScoreBoardFile plik
Użycie: konfiguracja główna
Wartość domyślna: logs/apache_status
Dyrektywa ta jest w niektórych systemach wymagana do poprawnego
utworzenia pliku tymczasowego, wykorzystywanego przez serwer do
zarządzania procesami potomnymi. Najprostszą metodą przekonania się, czy
w danym systemie plik taki jest wymagany, jest uruchomienie programu
Apache i sprawdzenie, czy w wyniku tego został utworzony plik o nazwie
zadanej w dyrektywie. Jeśli okaże się, że plik taki jest niezbędny, należy
podjąć kroki w celu zapewnienia, by nie był on równocześnie używany przez
więcej niż jedne proces główny serwera Apache.
CoreDumpDirectory katalog
Wartość domyślna: <ServerRoot>
Użycie: konfiguracja główna
Dyrektywa ta określa położenie katalogu, w którym w razie awarii Apache
zapisze plik core. Domyślnie plik ten powinien być zapisywany w katalogu
określonym dyrektywą ServerRoot, jednak przypisane mu prawa dostępu nie
umożliwiają zapisywania tam danych przez proces serwera uruchomiony
przez zwykłego użytkownika .
SendBufferSize liczba
Użycie: konfiguracja główna
Wartość domyślna: ustalana przez system operacyjny
Dyrektywa ta pozwala powiększyć wielkość bufora transmisji używanego
przez procedury obsługi protokołu TCP/IP ponad domyślną wartość
określaną przez system operacyjny.
LockFile plik
Użycie: konfiguracja główna
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 16 z 44
Wartość domyślna: logs/accept.lock
Jeśli
Apache
zostanie
skompilowany
z
opcją
USE_FCNTL_SERIALIZED_ACCEPT lub
USE_FLOCK_SERIALIZED_ACCEPT, przed uruchomieniem musi on zapisać
na dysku lokalnym plik blokady. Operacja ta może okazać się niemożliwa w
przypadku umieszczenia katalogu logs w woluminie NFS. Nie jest również
wskazane umieszczanie pliku blokady w katalogu dostępnym dla wszystkich
do zapisu, gdyż jego przypadkowe utworzenie zablokuje możliwość
uruchomienia serwera.
KeepAlive liczba
Użycie: konfiguracja główna
Wartość domyślna: 5
Jeśli dany użytkownik raz odwołał się do witryny, istnieją spore szanse, że za
chwilę uczyni to ponownie. Minimalizację niepożądanych opóźnień można
uzyskać poprzez podtrzymanie otwartego połączenia, jednak liczbę odwołań
w trakcie tak wydłużonego połączenia warto ograniczyć, aby zapobiec
nadmiernej konsumpcji zasobów serwera. Ustalenie dopuszczalnej liczby
odwołań realizowane jest za pomocą dyrektywy KeepAlive.
KeepAliveTimeout czas-w-sekundach
Użycie: konfiguracja główna
Wartość domyślna: 15
Dyrektywa ta pozwala na ograniczenie czasu oczekiwania na kolejne żądanie
poprzez określenie limitu czasu, przez który połączenie będzie
podtrzymywane w stanie otwarcia. W chwili odebrania żądania uaktywniona
zostaje dyrektywa TimeOut.
TimeOut czas-w-sekundach
Użycie: Konfiguracja główna
Wartość domyślna: 300
Dyrektywa ta określa maksymalną długość czasu transmisji pojedynczego
bloku danych w trakcie transakcji. We wcześniejszych wersjach Apache
dyrektywa ta miała dość nieprzyjemne efekty uboczne, powodowała bowiem
błędy timeout w przypadku transmisji dużych plików łączami o niewielkiej
przepustowości. W związku z tym zmieniono jej działanie tak, by określała
nie maksymalną długość trwania całej transakcji, ale czas przeznaczony na
przesłanie pojedynczego bloku danych.
HostNameLookups on|off|double
Użycie: konfiguracja główna, serwery wirtualne, katalogi.
Uaktywnienie tej dyrektywy poprzez użycie argumentu on powoduje, że
każde odebrane żądanie poddawane jest operacji odwrotnego odwzorowania
adresu. Oznacza to, że wydzielony z żądania adres IP klienta jest
wykorzystywany do ustalenia jego nazwy domenowej, pobieranej z
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 17 z 44
odpowiedniego serwera DNS. Tak uzyskana nazwa domenowa jest następnie
rejestrowana w logach. Wyłączenie dyrektywy (off) powoduje użycie w tym
miejscu adresu IP klienta.
Począwszy od wersji 1.3 dyrektywa ta może również przyjmować wartość
double, co oznacza wykonanie dwukrotnego odwrotnego odwzorowania
adresu. Zgodność obu adresów oznacza pozytywny wynik testu.
Include plik
Użycie: konfiguracja główna
Dyrektywa ta powoduje wstawienie zawartości podanego pliku w miejsce jej
wystąpienia do pliku konfiguracji serwera.
2.2.2
Dyrektywy
dotyczące
zarządzania
procesami
potomnymi
Serwer Apache uruchomiony bez opcji –X tworzy w systemie pewną liczbę
procesów potomnych (serwerów roboczych), których zadaniem jest
obsługiwanie wszelkich nadchodzących żądań. Poniżej omawiamy dyrektywy
przeznaczone do zarządzania procesami potomnymi:
MaxClients liczba
Wartość domyślna: 150
Użycie: konfiguracja główna
Dyrektywa ta określa maksymalną liczbę obsługiwanych jednocześnie żądań.
W obecnej wersji Apache limituje ona tym samym liczbę możliwych do
równoczesnego uruchomienia procesów potomnych
MaxRequestsPerChild liczba
Wartość domyślna: 30
Użycie: konfiguracja główna
Dyrektywa ta określa maksymalną liczbę żądań, które może obsłużyć
pojedynczy serwer roboczy w czasie swojego „życia”. W przypadku ustawienia
wartości 0, czyli brak limitu procesy serwerów roboczych będą działały tak
długo, jak długo będzie działał proces macierzysty. Nałożenie limitu
minimalizuje skutki ewentualnych wycieków pamięci.
MaxSpareServers liczba
Wartość domyślna: 10
Użycie: konfiguracja główna
Dyrektywa ta pozwala ustalić maksymalną liczbę uruchomionych i
„bezrobotnych” serwerów roboczych. Liczba ta nie powinna być zbyt duża,
gdyż wiąże się to z niepotrzebną konsumpcją zasobów. Przy jej doborze
należy się kierować liczbą i rodzajem wykorzystywanych modułów oraz
innymi szczegółami konfiguracji serwera. Dodatkowe wskazówki można
uzyskać analizując stan wykorzystania pamięci.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 18 z 44
MinSpareServers liczba
Wartość domyślna: 5
Użycie: konfiguracja główna
Dyrektywa ta określa minimalną liczbę wolnych serwerów roboczych. Jeśli
liczba bezrobotnych serwerów spadnie poniżej tej wartości, to proces główny
rozpoczyna uruchamianie procesów potomnych z rosnącą częstotliwością,
poczynając od jednego na sekundę, aż do osiągnięcia wartości
MAX_SPAWN_RATE. Domyślna wielkość tej ostatniej wynosi 32 i może zostać
zmieniona w czasie kompilacji. Po osiągnięciu wymaganej minimalnej liczby
wolnych serwerów wartość częstotliwości ustalana jest z powrotem na 1.
Minimalna liczba wolnych serwerów nie powinna być zbyt duża, gdyż
powoduje to zajęcie wolnych zasobów systemu.
StartServers liczba
Wartość domyślna: 5
Użycie: konfiguracja główna
Dyrektywa
ta
umożliwia
określenie
liczby
serwerów
roboczych
uruchamianych w chwili rozpoczęcia pracy procesu głównego.
2.3 PROCEDURY OBSŁUGI TYPÓW PLIKÓW
Procedura obsługi (handler) jest reprezentacją w Apache akcji, która ma
zostać wykonana w momencie odwoływania się do danego pliku. Większość
plików jest po prostu udostępniana przez serwer, ale niektóre są traktowane
w specjalny sposób. Procedury obsługi w Apache nie zależą od typu pliku,
ale jest możliwe jednoczesne skojarzenie z danym plikiem typu i procedury
obsługi.
Poniżej przedstawiona jest lista predefiniowanych procedur obsługi:
ü Default-handler – plik jest wysyłany przy użyciu default_handler().
ü Send-as-is – plik jest wysyłany z nagłówkiem HTTP, w niezmienionej
postaci
ü Cgi-script – plik jest traktowany jako skrypt CGI
ü Imap-file – plik jest traktowany jako imagemap
ü Server-info – podaje informacje dotyczące konfiguracji serwera
ü Server-parsed – parsuje plik w poszukiwaniu SSI (Server-Side Includes)
ü Server-status – podaje raport dotyczący statusu serwera
ü Type-map – parsuje plik jako plik type map dla ustalenia zawartości.
2.3.1
Dyrektywy służące do zarządzania procedurami
obsługi:
AddHandler handler-name extension extension...
Użycie: konfiguracja główna, serwery wirtualne, <directory>, pliki .htaccess
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 19 z 44
Dyrektywa ta mapuje podane rozszerzenia nazwy plików na procedurę
obsługi handler-name. Mapowanie to nadpisuje wszystkie inne ewentualne
mapowania skojarzone z tym rozszerzeniem.
Na przykład, aby zaktywować obsługę CGI dla plików z rozszerzeniem .cgi
można użyć:
AddHandler cgi-script cgi
SetHandler handler-name
Użycie: pliki .htaccess, <directory>
Dyrektywa ta, umieszczona w pliku .htaccess lub w sekcji <directory> lub
<Location> powoduje, że wszystkie pliki w zasięgu jej działania będą
obsługiwane za pomocą danej procedury obsługi, niezależnie od ich
rozszerzenia.
Przykład: jeśli chcemy uzyskać raport o statusie serwera za każdym
odwołaniem do URL
http://servername/status
, możemy dodać do
access.conf następującą sekcję:
<Location /status>
SetHandler server-status
</Location>
RemoveHandler extension extension...
Użycie: <directory>, pliki .htaccess
Dyrektywa ta usuwa wszystkie procedury obsługi skojarzone z plikami o
podanych rozszerzeniach. Umożliwia to usunięcie w plikach .htaccess
procedur obsługi odziedziczonych z wyższych katalogów lub plików
konfiguracji głównej serwera.
3 Serwery wirtualne
Termin “serwer wirtualny” odnosi się do zarządzania kilkoma serwerami na
jednej maszynie, rozróżnianymi przez URL.
Obsługę kilku witryn identyfikowanych różnymi adresami URL można
zrealizować przez uruchomienie dwóch kopii serwera Apache. W praktyce
rozwiązanie to jest rzadko stosowane. Najczęstszą metodą jest wykorzystanie
kilku wirtualnych „klonów” serwera, obsługujących odwołania do różnych
adresów URL (zwykle związanych z tym samym adresem IP).
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 20 z 44
3.1 SERWERY WIRTUALNE IDENTYFIKOWANE NAZWAMI
Rozwiązanie wykorzystujące identyfikację serwerów wirtualnych poprzez
nazwy domenowe jest najbardziej polecane. Bazuje ono na dostępnej w
protokole HTTP/1.1 możliwości przesłania przez przeglądarkę nazwy
domenowej witryny (serwera). Oczywiście nazwy domenowe muszą być
zarejestrowane w systemie DNS. Załóżmy, że mamy dwie witryny:
, którym odpowiada ten sam adres IP
192.168.123.2.
Przykładowa treść pliku konfiguracji serwera będzie w tym przypadku
następująca:
User webuser
Group webgroup
NameVirtualHost 192.168.123.2
ServerName
DocumentRoot /usr/www/site.virtual/htdocs/w1
ErrorLog /usr/www/site.virtual/Name-based/logs/error_log
TransferLog
/usr/www/site.virtual/Name-
based/logs/transfer_log
</VirtualHost>
ServerName
DocumentRoot /usr/www/site.virtual/htdocs/w2
ErrorLog /usr/www/site.virtual/Name-based/logs/error_log
TransferLog
/usr/www/site.virtual/Name-
based/logs/transfer_log
</VirtualHost>
Kluczowym elementem jest tu dyrektywa NameVirtualHost, informująca
serwer Apache, że żądania kierowane do danego adresu IP powinny być dalej
rozdzielane w zależności od nazwy domenowej witryny. Dyrektywa
ServerName ma znaczenie pomocnicze i służy do ustalenia nazwy serwera
przekayzwanej z powrotem do klienta. Gdybyśmy nie użyli dyrektywy
NameVirtualHost, Apache zgłosiłby komunikat o konflikcie między adresami
www.witryna1,com
i
, gdyż oba odnoszą się do tego
samego adresu IP.
Serwery wirtualne mogą wykorzystywać wspólne bądź oddzielne pliki logów.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 21 z 44
Dyrektywa NameVirtualHost:
NameVirtualHost
adres[:port]
umożliwia
zdefiniowanie
adresu
IP
wykorzystywanego przez serwery wirtualne identyfikowane za pomocą nazw.
Podany w niej adres IP musi odpowiadać adresowi umieszczonemu w
nagłówku sekcji <VirtualHost>, w skład której musi z kolei wchodzić
dyrektywa ServerName, zawierająca nazwę domenową serwera.
Efekt działania tego układu jest następujący: w chwili odebrania żądania
skierowanego do serwera o danej nazwie domenowej, Apache przegląda bloki
<VirtualHost> i odnajduje ten, w którym w dyrektywie ServerName występuje
żądana
nazwa
domenowa.
W
przypadku
pominięcia
dyrektywy
NameVirtualHost, lokalizowany jest blok <VirtualHost> odpowiadający
właściwemu adresowi IP, a nazwa domenowa podana w dyrektywa
ServerName używana jest do utworzenia odpowiedzi na żądanie. Mechanizm
ten pozwala między innymi na zablokowanie dostępu do serwerów
chronionych za pomocą firewalli poprzez podanie adresu IP serwera
dostępnego swobodnie i nazwy domenowej serwera chronionego.
3.2 SERWERY WIRTUALNE IDENTYFIKOWANE ADRESAMI IP
Mimo, iż ogromna większość przeglądarek używa protokołu HTTP/1.1, nadal
istnieją takie, które wykorzystują HTTP/1.0. W związku z tym większość
administratorów korzysta ze starszej wersji protokołu.
Aby skonfigurować serwer Apache dla potrzeb identyfikacji serwerów opartej
na adresach IP, musimy stworzyć plik konfiguracji serwera o następującej
treści:
User webuser
Group webgroup
ServerName localhost
<VirtualHost 192.168.123.2>
ServerName
ServerAdmin
…
</VirtualHost>
VirtualHost 192.168.123.3>
ServerName
ServerAdmin
…
</VirtualHost>
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 22 z 44
Tak przygotowana konfiguracja pozwala bezproblemowo obsługiwać
odwołania do witryn
3.3 SERWERY
WIRTUALNE
IDENTYFIKOWANE
NAZWAMI
DOMENOWYMI I ADRESAMI IP
Oba rozwiązania przedstawione powyżej mogą zostać połączone w jedno.
Wtedy bloki <VirtualHost> odpowiadające adresowi podanemu w dyrektywie
NameVirtualHost będą obsługiwały serwery identyfikowane nazwami.
Pozostałe bloki będą zajmowały się obsługą żądań skierowanych pod
odpowiednie adresy IP. Przykładowy plik konfiguracji będzie wyglądał
następująco:
User webuser
Group webgroup
NameVirtualHost 192.168.123.2
>
ServerName
DocumentRoot /usr/www/site.virtual/htdocs/w1
…
</VirtualHost>
<VirtualHost www.witryna2.com>
ServerName
DocumentRoot /usr/www/site.virtual/htdocs/w2
…
</VirtualHost>
<VirtualHost 192.168.123.3>
ServerName
DocumentRoot /usr/www/site.virtual/htdocs/w2
…
</VirtualHost>
3.4 SERWERY WIRTUALNE IDENTYFIKOWANE NUMERAMI
PORTÓW
Technika identyfikacji serwerów wirtualnych oparta na numerach portów
pochodzi od metody bazującej na numerach IP. Główną zaletą tego
rozwiązania jest umożliwienie administratorowi uruchomienia większej liczby
witryn przy wykorzystaniu pojedynczego adresu IP i pojedynczej nazwy
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 23 z 44
domenowej. Innymi słowy, technika ta pozwala na obsługę wielu witryn bez
konieczności używania wielu adresów IP i bez angażowania techniki
identyfikacji za pomocą nazw – co eliminuje konieczność użycia protokołu
HTTP/1.1. Wadą takiego rozwiązania jest niechętne nastawienie
użytkowników do adresów zawierający niecodzienny numer portu.
Przykładowy plik konfiguracyjny mógłby wyglądać następująco:
User webuser
Group webgroup
Listen 80
Listen 8080
<VirtualHost 192.168.123.2:80>
ServerName
DocumentRoot /usr/www/site.virtual/htdocs/w1
...
</VirtualHost>
<VirtualHost 192.168.123.2:8080>
ServerName
witryna2.serwer.com
DocumentRoot /usr/www/site.virtual/htdocs/w2
...
</VirtualHost>
Dyrektywa Listen nakazuje programowi Apache prowadzenie nasłuchu
proów o numerach 80 i 8080. Po uruchomieniu całego systemu odwołania do
adresu
będą trafiały do domyślnego portu 80 i będą
przez serwer kierowane do witryny
. Aby uzyskać dostęp do
witryny2 należy wpisać adres:
3.5 KILKA KOPII SERWERA APACHE DZIAŁAJĄCE W SYSTEMIE
Alternatywną metodą obsługiwania wielu witryn jest uruchomienie kilku
kopii serwera Apache, używających różnych adresów IP. Logicznie odpowiada
to uruchomieniu serwera na dwóch niezależnych maszynach. Rozwiązanie to
wykorzystywane jest sporadycznie, głównie w przypadku, gdy konfiguracje
uruchamianych witryn różnią się znacząco, np. wartościami ServerRoot,
User czy ServerType. Dyrektywy te mają zasięg globalny i nie stosują się
indywidualnie do poszczególnych serwerów wirtualnych, toteż uzyskanie
pożądanego efektu wymaga uruchomienia serwera w kilku niezależnych
egzemplarzach.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 24 z 44
Załóżmy, że całą niezbędną konfigurację i dane zawiera katalog
.../site.twocopy, w którym znajdują się dwa podkatalogi: w1 oraz w2. Plik
konfiguracji serwera zawarty w katalogu w1 wygląda następująco:
User webuser
Group webgroup
ServerName
DocumentRoot /usr/www/site.twocopy/w1/htdocs
BindAddress
…
natomiast jego odpowiednik w katalogu w2 ma posta
ć:
User webuser
Group webgroup
ServerName
DocumentRoot /usr/www/site.twocopy/w2/htdocs
Ponieważ tym razem mamy do czynienia w systemie z kilkoma niezależnymi
kopiami programu Apache, musimy skojarzyć odwołania do poszczególnych
adresów URL z kopiami, które je obsługują. Służą do tego następujące
dyrektywy:
BindAddress adres
Wartość domyślna: *
Użycie: konfiguracja główna
Dyrektywa ta nakazuje serwerowi Apache obsługę określonego, pojedynczego
adresu, a nie – jak poprzednio – wszystkich adresów zdefiniowanych w
systemie.
Port numer
Wartość domyślna: 80
Użycie: konfiguracja główna
Dyrektywa port umieszczona w głównym bloku danych konfiguracyjnych
serwera (poza obrębem bloków VirtualHost) określa w przypadku
nieobecności dyrektyw BindAddress i Listen numer portu, na którym serwer
ma prowadzić nasłuch. Dyrektywa ta została wprowadzona jedynie dla
zachowania zgodności ze starszymi wersjami. Obecnie należy używać jednej z
dwóch dyrektyw: BindAddress lub Listen.
Listen nazwa-hosta:numer-portu
Użycie: konfiguracja główna
Dyrektywa listen nakazuje serwerowi Apache prowadzenie nasłuchu dla
więcej niż jednego adresu lub portu. Przez domniemanie serwer odpowiada
na żądania pojawiające się pod wszystkimi zdefiniowanymi w systemie
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 25 z 44
adresami IP, ale tylko w jednym porcie, określonym dyrektywą Port.
Używając dyrektywy Listen możemy więc ograniczyć ilość adresów IP,
natomiast rozszerzyć listę portów. Plik konfiguracji serwera może zawierać
kilka dyrektyw Listen, natomiast tylko jedną dyrektywę BindAddress.
4 Zmiana konfiguracji serwera w trakcie pracy
4.1 PONOWNE URUCHAMIANIE SERWERA
W praktyce od czasu do czasu zachodzi konieczność zatrzymania serwera
Apache i jego ponownego uruchomienia po zmianie pliku konfiguracji
serwera. Dzieje się tak najczęściej w wyniku dodania nowego serwera
wirtualnego. Można to zrobić w sposób radykalny, zatrzymując proces httpd i
ponownie go uruchamiając, jednak metoda ta wprowadza istotne zakłócenia
do działania witryn obsługiwanych przez dany serwer. Ostatnio
wprowadzone modernizacje umożliwiają dokonanie restartu serwera bez
nagłego przerywania pracy wszystkich procesów roboczych. Istnieją trzy
metody ponownego uruchomienia serwera Apache:
ü Zatrzymanie i ponowne jego uruchomienie, w wyniku czego dokona
ponownego odczytania swoich plików konfiguracyjnych:
% kill PID
%httpd opcje
ü Ten sam efekt można osiągnąć wydając polecenie kill z opcją HUP:
% kill –HUP
ü „miękki” restart serwera możemy wymusić za pomocą opcji –USR1.
Jej użycie powoduje ponowne odczytanie zawartości plików
konfiguracyjnych serwera, pozwalając jednocześnie pracującym
procesom serwerów roboczych na zakończenie obsługiwanych
transakcji przed zastąpieniem ich nowymi. Metoda ta nie powoduje
zakłóceń w dostępie do witryn obsługiwanych przez serwer.
% kill –USR1 PID
4.2 LOKALNE PLIKI KONFIGURACYJNE (.HTACCESS)
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 26 z 44
Alternatywnym rozwiązaniem problemu zmiany konfiguracji serwera w
trakcie pracy jest użycie pliku .htaccess. Plik ten, przechowywany w
odpowiednim podkatalogu .../htdocs jest rozszerzeniem pliku httpd.conf i
zawiera zmienne elementy konfiguracji serwera. W odróżnieniu od pliku
konfiguracji serwera, którego zawartość odczytywana jest raz, w momencie
startu serwera, zawartość pliku .htaccess jest odczytywana i analizowana
podczas każdego dostępu do zawartości witryny. Zaletą takiego rozwiązania
jest elastyczność, natomiast wadą zauważalny spadek wydajności.
Administrator może ograniczyć efekty działania dyrektyw zawartych w pliku
.htaccess przez użycie dyrektywy AllowOverride. Aby natomiast uniemożliwić
klientom witryny odczyt zawartości plików .htaccess, należy w pliku
konfiguracji dodać następującą sekcję:
<Files .htaccess>
order allow, deny
deny from all
</Files>
Podstawową ideą użycia plików .htaccess jest umożliwienie administratorowi
serwera dynamicznego modyfikowania zestawu dyrektyw konfiguracyjnych
bez konieczności zatrzymywania i ponownego uruchamiania serwera.
Możliwość taka jest szczególnie przydatna w systemach wykorzystywanych
przez wielu użytkowników, którzy sami utrzymują własne strony WWW, ale
nie mają uprawnień do zarządzania serwerem ani modyfikowania jego plików
konfiguracyjnych.
Do ustawiania nazw plików zawierających dyrektywy sterujące dostępem do
wybranych katalogów służy następująca dyrektywa:
AccessFileName plik
Użycie: konfiguracja główna, serwery wirtualne
Zasięg tej dyrektywy jest globalny dla całego pliku httpd.conf lub serwera
wirtualnego.
5 Interfejs CGI
Interfejs CGI umożliwia przetwarzanie danych przesłanych od klienta w
formularzu na serwerze za pomocą odpowiedniego skryptu.
Formularz przeznaczony do obsłużenia za pomocą CGI powinien wyglądać
następująco:
<FORM METHOD= GET|POST ACTION=”/mycgi.cgi”>
…
</FORM>
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 27 z 44
Lub
<FORM METHOD= GET|POST ACTION=”cgi-bin/mycgi.cgi”>
…
</FORM>
Pierwsza specyfikacja („/mycgi.cgi”) informuje serwer, że powinien użyć pliku
mycgi.cgi znajdującego się w katalogu .../htdocs. Druga – że do obsłużenia
żądania należy użyć pliku znajdującego się w katalogu /usr/www/cgi-
bin/cgi.
Skrypty powinny być plikami wykonywalnymi z punktu widzenia systemu
operacyjnego. Aby sprawdzić, czy tak jest rzeczywiście, można spróbować
uruchomić skrypt z linii poleceń, logując się wcześniej na konto użytkownika
przypisanego serwerowi Apache. W razie niemożności wykonania skryptu
można poradzić sobie na dwa sposoby:
1. Umieszczając w pliku konfiguracji serwera dyrektywę ScriptAlias,
wskazującą „bezpieczną” lokalizację poza przestrzenią witryny.
Rozwiązanie takie wpływa korzystnie na bezpieczeństwo systemu,
uniemożliwia bowiem włamywaczom odczytywanie treści skryptów i ich
analizowanie pod kątem ewentualnych luk w systemie zabezpieczeń,.
2. Wykorzystując dyrektywę AddHandler lub SetHandler do zdefiniowania
nowego typu procedury obsługi o nazwie cgi-script, skojarzonego z
plikami skryptów CGI. W takiej sytuacji skrypty umieszcza się w
głównym katalogu dokumentów witryny (DocumentRoot)
Skrypt CGI (a dokładniej odpowiedź serwera wygenerowana przez ten skrypt)
składa się z nagłówka i treści. Nagłówkiem jest cały tekst skryptu do
pierwszego pustego wiersza (do pierwszego ciągu znaków <cr><lf><cr><lf>,
chociaż Apache toleruje też same <lf><lf>); pozostała część tworzy treść
skryptu. Poszczególne wiersze nagłówka zakończone są znakami <cr><lf> lub
<lf>.
Pola nagłówka CGI mają następującą składnię:
Generic-field = field-name „:” [field-value] NL
Field-name = token
Field-value = *( field-content|LWSP)
Field-content=*(token|special|quoted-string)
Duże i małe litery w nazwie pola nie są rozróżniane, pusta zawartość pola
jest traktowana jako brak pola nagłówka.
Apache nie potrafi sam określić typu zawartości na podstawie samej nazwy
pliku – dlatego skrypt musi wygenerować przynajmniej jedno pole nagłówka :
content-type. Pominięcie tego pola spowodowałoby pojawienie się
komunikatu o błędzie zamiast odpowiedzi serwera.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 28 z 44
5.1 SKRYPT W KATALOGU CGI-BIN
Aby nadchodzące odwołania do skryptu wysyłać w odpowiednie miejsce (tj.
do katalogu .../cgi-bin) musimy zmodyfikować zawartość pliku httpd.conf
naszej witryny do następującej postaci:
User webuser
Group webgroup
ServerName
DocumentRoot /usr/www/site.cgi/htdocs
ScriptAlias /cgi-bin /usr/www/cgi-bin
Sam formularz, zawarty w pliku .html powinien na początku zawierać tekst:
<form method=get|post action=”cgi-bin/mycgi.cgi”>
5.2 SKRYPT W GŁÓWNYM KATALOGU DOKUMENTÓW
Skrypty można również umieścić wśród innych dokumentów, tworzacych
zawartość witryny. Rozwiązanie takie osłabia bezpieczeństwo systemu –
katalogi zawierające skrypty CGI należy skutecznie zabezpieczyć przed
dostępem osób niepowołanych.
Plik konfiguracji serwera będzie wyglądał w tej sytuacji następująco:
User webuser
Group webgroup
Servername
DocumentRoot /usr/www/site.cgi/htdocs
AddHandler cgi-script cgi
Dyrektywa AddHandler informuje serwer Apache, że wszystkie pliki o
rozszerzeniu .cgi mają być traktowane jak pliki wykonywalne. Formularz w
dokumencie .html powinien zawierać tekst :
<form method=get|post action=”mycgi.cgi”>
5.3 DYREKTYWY ZARZĄDZAJĄCE OBSŁUGĄ SKRYPTÓW:
ScriptAlias prefiks-URL katalog
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta pozwala na konwersję odwołań do adresów URL
rozpoczynających się ciągiem prefiks-URL na odwołania do programu CGI
położonego w danym katalogu. Innymi słowy, żądanie dostępu do adresu
prefiks-URL/aaa.cgi spowoduje wywołanie programu katalog/aaa.cgi.
Katalog musi być podany w formie bezwzględnej. Zaleca się, aby znajdował
się poza przestrzenią witryny użytkownika.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 29 z 44
ScriptAliasMatch wyra
żenie-regularne katalog
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta jest odpowiednikiem ScriptAlias, z tą różnicą, że zamiast
prostego porówniania prefiksuURL z wzorcem pozwala dokonać tego samego
z użyciem wyrażeń regularnych.
ScriptLog plik
Wartość domyślna: brak rejestracji
Użycie: konfiguracja główna
Dyrektywa ta umożliwia utworzenie logu zdarzeń związanych z obsługą
uruchamianych skryptów. Dyrektywa ta powinna być używana jedynie dla
celów testowania i tworzenia nowych skryptów.
ScriptLogLength liczba-bajtów
Wartość domyślna: 10385760 (10MB)
Użycie: konfiguracja główna
Dyrektywa ta określa maksymalny rozmiar pliku logu uruchomieniowego
skryptów. Po przekroczeniu tej wartości rejestracja jest wstrzymywana
(ostatni wpis jest zachowywany w całości)
ScriptLogBuffer liczba-bajtów
Wartość domyślna: 1024
Użycie: konfiguracja główna
Dyrektywa ta określa maksymalny rozmiar pojedynczego bloku danych
transakcji POST i PUT zapisywanych do logu.
5.4 DYREKTYWY SŁUŻĄCE DO OGRANICZENIA ZASOBÓW DLA
SKRYPTÓW:
RLimitCPU warto
ść|max [wartość|max]
Wartość domyślna: określona przez system operacyjny
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta posiada dwa parametry, określające miękki i twardy limit
czasu procesora przydzielony procesowi. Każdy parametr może być dany
liczbą, określającą czas procesora w sekundach lub słowem max,
oznaczającym maksymalną wielkość, dopuszczoną w systemie operacyjnym.
RLimitMEM warto
ść|max [wartość|max]
Wartość domyślna: określona rpzez system operacyjny
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta posiada dwa parametry, określające miekki i twardy limit
zajętości pamieci dla danego procesu. Każdy parametr może być dany liczbą,
określającą wielkość pamięci dla procesu w bajtach lub słowem max,
oznaczającym maksymalną wielkość dopuszczoną w systemie operacyjnym.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 30 z 44
RLimitNPROC warto
ść|max [wartość|max]
Wartość domyślna: określona przez system operacyjny
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta posiada dwa parametry, określające miękki i twardy limit
liczby procesów, które może uruchomić dany użytkownik. Każdy parametr
może być dany liczbą, określającą maksymalną liczbę procesów lub słowem
max, oznaczającym maksimum dopuszczone w systemie operacyjnym.
5.5 POBIERANIE DANYCH W SKRYPTACH CGI
Skrypty CGI dopuszczają dwie metody przesyłania danych: GET i POST.
Metoda przesłania danych jest zawarta w zmiennej środowiskowej
REQUEST_METHOD. W obu przypadkach dane formatowane są
następująco:
nazwapola1=wartosc1&nazwapola2=wartosc2&...
W przypadku użycia metody GET dane zapisywane są w zmiennej
środowiskowej QUERY_STRING, natomiast w razie użycia metody POST są
przesyłane do standardowego wejścia programu, skąd można je pobrać za
pomocą funkcji fgetc() (język C).
Skrypty CGI otrzymują dane w postaci licznych zmiennych środowiskowych.
Możliwe jest również przekazanie w ten sposób zmiennych zdefiniowanych
przez użytkownika serwera. Służą do tego następujące dyrektywy:
ü SetEnv zmienna wartość
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta definiuje zmienną środowiskową przekazywaną następnie
do skryptu CGI. Użytkownik może tworzyć własne zmienne środowiskowe
i nadawać im dowolne wartości.
ü UnsetEnv zmienna1 zmienna2 ...
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta usuwa podane zmienne środowiskowe
ü PassEnv zmienna1 zmienna2 ...
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta przekazuje do skryptu wybrane zmienne środowiskowe z
zestawu odziedziczonego przez Apache w chwili uruchamiania od
systemu operacyjnego.
6 Program suEXEC i jego zastosowanie
Wrażliwość systemu na ataki wykorzystujące skrypty CGI jest przedmiotem
ciągłej pracy członków Zespołu Apache. Systemy Unixowe udostępniają
pewną specyficzną metodę uruchamiania skryptów CGI, która znacznie
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 31 z 44
poprawia bezpieczeństwo takiej operacji – jest nią użycie tzw. programu
kopertującego (wrapper). Program taki jest rodzajem opakowania na inny
program (skrypt), które modyfikuje otoczenie uruchomieniowe skryptu, co w
tym przypadku sprowadza się do nadania mu odpowiednich uprawnień.
Problem z uruchamianiem skryptów CGI polega na tym, że każdy skrypt
uruchamiany
przez
program
Apache
dysponuje
takimi
samymi
uprawnieniami, jak serwer – jest odpalany jako proces należący do
użytkownika, do którego należy proces serwera. Również w systemach, gdzie
wielu użytkowników tworzy swoje strony WWW istnieje konieczność
odseparowania działania skryptów poszczególnych użytkowników.
Problemy te można rozwiązać przez użycie programu suEXEC, pozwalającego
na zmianę uprawnień skryptu lub programu uruchomionego przez serwer
Apache przez zmianę identyfikatora użytkownika, który jest właścicielem
skryptu. suEXEC jest uruchamiany każdorazowo w wyniku odebrania
żądania HTTP skierowanego do programu lub skryptu, dla którego prawa
dostępu użytkownika lub grupy są inne od praw przydzielonych serwerowi
Apache (czyli praw użytkownika i grupy określonych w pliku httpd.conf).
Dokładny
opis
programu
suEXEC
znajduje
się
pod
adresem
http://www2.idiscover.co.uk/apache/docs/suexec.html
6.1 INSTALACJA PROGRAMU SUEXEC
W celu zainstalowania programu suEXEC należy przejść do podkatalogu
support w katalogu, zawierającym źródła Apache i dokonać w treści pliku
suexec.h zmian stosownych do własnej konfiguracji Apache.
Następnie należy skompilować suEXEC poleceniem
% make suexec
I skopiować plik wynikowy w odpowiednie miejsce – tam, gdzie znajduje się
plik wykonywalny programu Apache.
% cp suexec /usr/local/bin
Kolejną operacją jest ustawienie odpowiednich praw dostępu do programu
suexec. W tym celu należy zalogować się jako root:
% chown root /usr/local/bin/suexec
% chmod 4711 /usr/local/bin/suexec
Teraz trzeba poinformować serwer Apache, gdzie ma szukać pliku
wykonywalnego programu suEXEC. W tym celu konieczne jest
zmodyfikowanie pliku .../src/include/httpd.h. Zmian należy dokonać w
miejscu:
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 32 z 44
#ifndef SUEXEC_BIN
#define SUEXEC_BIN HTTPD_ROOT “/sbin/suexec”
#endif
Drugą linię należy zmodyfikować do postaci :
#define SUEXEC_BIN sciezka_do_suexec
W wyniku zmiany usuwamy odwołanie do makrodefinicji HTTPD_ROOT,
której rozwinięcie powoduje poprzedzenie definiowanej ścieżki ciągiem
/usr/local/apache (lub innym – zależnie od konfiguracji Apache w danym
systemie).
Po dokonaniu tej poprawki pozostaje już tylko skompilować ponownie
program Apache:
% make
% cp httpd /usr/local/bin
Po uruchomieniu Apache w pliku .../logs/error_log pojawi się komunikat:
SuEXEC mechanism enabled (wrapper: /usr/local/suexec)
Aby wyłączyć program suEXEC można usunąć jego plik wykonywalny lub
przemianować go. Stwierdziwszy brak pliku Apache przejdzie bez problemów
do dalszej pracy.
6.2 DZIAŁANIE PROGRAMU SUEXEC
Działanie programu suEXEC polega na poddaniu uruchamianego przez
serwer skryptu CGI lub SSI szeregowi testów. Niepowodzenie testu powoduje
zapisanie odpowiedniego komunikatu do pliku logu, którego nazwa
określona jest makrodefinicją LOG_EXEC w pliku nagłówkowym suexec.h. W
większości przypadków niepowodzenie testu oznacza obecność błędu w
systemie operacyjnym, programie Apache lub suEXEC – lub też sygnalizuje
próbę nadużycia. Poniżej przedstawiono typowe sytuacje, które mogą trafić
się w codziennej praktyce:
ü Czy właściciel uruchamianego skryptu istnieje w systemie jako
użytkownik? Test ten jest dość sensowny, jako że istnieje możliwość
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 33 z 44
usuwania użytkowników z systemu bez fizycznego usuwania plików do
nich należących.
ü Czy w systemie istnieje grupa, do której należy użytkownik
uruchamiający skrypt? Podobnie jak w przypadku identyfikatorów
użytkowników
możliwe
jest
tworzenie
plików
należących
do
nieistniejących grup.
ü Czy użytkownik nie jest superużytkownikiem? Program suEXEC nie
zezwala użytkownikowi root na uruchamianie skryptów w trakcie obsługi
połączenia.
ü Czy identyfikator użytkownika ma wartość wyższą niż minimalna wartośc
określona w pliku suexec.h? W wielu systemach niskie wartości
identyfikatorów UID są zarezerwowane dla użytkowników obdarzonych
znacznymi uprawnieniami. Przykładem może tu być demon lpd,
operatorzy kopii zapasowych itd. „Progowy” test wartości UID zabezpiecza
przed wywołaniem skryptu za pośrednictwem takiego użytkownika.
ü Czy grupa, do której należy użytkownik nie jest grupą superużytkownika?
SuEXEC
nie
zezwala
członkom
grupy
superużytkownika
na
uruchamianie skryptów w trakcie obsługi połączenia.
ü Czy katalog macierzysty skryptu znajduje się poniżej katalogu głównego
dokumentów serwera (w przypadku dyrektywy UserDir poniżej głównego
katalogu dokumentów użytkownika)?
ü Czy katalog skryptu jest niedostępny do zapisu dla wszystkich innych
użytkowników?
ü Czy wywoływany skrypt w ogóle istnieje?
ü Czy właściciel skryptu jest jedynym użytkownikiem uprawnionym do jego
zapisywania?
ü Czy uruchamiany program to przypadkiem nie setgid lub setuid?
ü Czy docelowym użytkownikiem jest właściciel skryptu?
Po pomyślnym przejściu tych wszystkich testów program można uruchomić.
Warto też pamiętać o tej liście podczas konfigurowania i administrowania
systemem.
7 Moduły programu Apache
7.1 DYNAMIC SHARED OBJECT (DSO)
DSO jest mechanizmem Unixowym, pozwalającym na dynamiczne
linkowanie/ładowanie fragmentów programu do przestrzeni adresowej
wykonywanego programu. Takiego ładowania można zazwyczaj dokonać na
dwa sposoby: automatycznie przez program systemowy ld.so w momencie
startu programu wykonywanego lub ręcznie z tego programu przy użyciu
wywołań loadera dlopen() /dlsym().
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 34 z 44
Przy użyciu pierwszej metody DSO są zazwyczaj nazywane shared libraries
lub DSO libraries i nazywane libfoo.so lub libfoo.so.1.2. Pliki takie powinny
znajdować się w katalogu /usr/lib. Są one linkowane z głównym programem
na etapie kompilacji.
Przy użyciu drugiej metody DSO są zazwyczaj nazywane shared objects lub
DSO files. Pliki takie zazwyczaj znajdują się w katalogu programu głównego,
który dynamicznie ładuje je do swojej przestrzeni adresowej w trakcie
działania przez dlopen().
Apache 1.3 posiada dwie możliwości używania DSO: kompilacja głównego
programu Apache do biblioteki DSO dla dzielonego użycia lub kompilacja
modułów Apache do plików DSO dla późniejszego jawnego ładowania w
trakcie działania programu głównego.
7.2 IMPLEMENTACJA
Wsparcie dla dynamicznego ładowania poszczególnych modułów Apache
bazuje na module mod_so.c, który powinien zostać statycznie wkompilowany
w serwer. Jest to jedyny moduł Apache, który nie może zostać skompilowany
do pliku DSO. Po skompilowaniu modułu do pliku DSO można używać
dyrektywy LoadModule z modułu mod_so w pliku httpd.conf do ładowania
danego modułu przy starcie lub restarcie serwera.
Do uproszczenia tworzenia plików DSO z modułów Apache służy program
apxs (Apache eXtenSion).
Aby umieścić cały program Apache w bibliotece DSO należy włączyć regułę
rule SHARED_CORE=yes w pliku configuration (przy kompilacji). Kod
Apache jest wtedy umiejscawiany w bibliotece libhttpd.so. Tworzony jest
również program wykonywalny libhttpd.ep. Program httpd jest zamieniany
przez kod ładujący libhttpd.ep, który linkuje bibliotekę libhttpd.so.
7.3 PRZYKŁAD UŻYCIA:
7.3.1
Umieszczanie całego kodu Apache w bibliotece DSO:
Przy użyciu skryptu configure:
$ ./configure --prefix=/path/to/install
--enable-rule=SHARED_CORE ...
$ make install
Ręcznie:
- Edit src/Configuration:
<< Rule SHARED_CORE=default
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 35 z 44
>> Rule SHARED_CORE=yes
<< EXTRA_CFLAGS=
>> EXTRA_CFLAGS= -DSHARED_CORE_DIR=\"/path/to/install/libexec\"
$ make
$ cp src/libhttpd.so* /path/to/install/libexec/
$ cp src/libhttpd.ep /path/to/install/libexec/
$ cp src/httpd /path/to/install/bin/
7.3.2
Kompilacja
i
instalacja
modułu
Apache
pochodzącego z dystrybucji w pliku DSO
Przy użyciu skryptu configure:
$ ./configure --prefix=/path/to/install
--enable-shared=foo
$ make install
Ręcznie:
- Edit src/Configuration:
<< AddModule modules/xxxx/mod_foo.o
>> SharedModule modules/xxxx/mod_foo.so
$ make
$ cp src/xxxx/mod_foo.so /path/to/install/libexec
- Edit /path/to/install/etc/httpd.conf
>> LoadModule foo_module /path/to/install/libexec/mod_foo.so
7.3.3
Kompilacja i instalacja własnego modułu Apache w
pliku DSO
Przy użyciu skryptu configure:
$ ./configure --add-module=/path/to/3rdparty/mod_foo.c
--enable-shared=foo
$ make install
Ręcznie:
$ cp /path/to/3rdparty/mod_foo.c /path/to/apache-
1.3/src/modules/extra/
- Edit src/Configuration:
>> SharedModule modules/extra/mod_foo.so
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 36 z 44
$ make
$ cp src/xxxx/mod_foo.so /path/to/install/libexec
- Edit /path/to/install/etc/httpd.conf
>> LoadModule foo_module /path/to/install/libexec/mod_foo.so
7.3.4
Kompilacja i instalacja własnego modułu Apache w
pliku DSO poza drzewem Apache
Przy użyciu apxs
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.so
7.4 ZALETY I WADY DSO
Funkcjonalność Apache oparta na DSO posiada następujące zalety:
ü Pakiet serwera jest plastyczny w trakcie działania, gdyż można dodawać
nowe moduły za pomocą dyrektywy LoadModule w pliku httpd.conf,
zamiast używać komendy AddModule podczas kompilacji serwera. Dzięki
tej technologii można używać różnych wersji Apache (standard, SSL,
minimalna, rozbudowana) przy tylko jednej instalacji Apache.
ü Pakiet serwera może być w łatwy sposób rozbudowywany przez
dodatkowe moduły, nawet po instalacji.
ü Ułatwione jest tworzenie nowych wersji modułów, gdyż wystarczy para
DSO/apxs do utworzenia nowej wersji modułu poza drzewem Apache.
Następnie komendą apxs –i oraz restartem apachectl wprowadzamy nową
wersję naszego moduło do działającego serwera.
Technologia ta ma jednak następujące wady:
ü Mechanizm DSO nie może być używany na każdej platformie, gdyż nie
wszystkie systemy operacyjne dopuszczają dynamiczne ładowanie kodu
do przestrzeni adresowej programu.
ü Serwer jest około 20% wolniejszy przy starcie, gdyż dużą część zasobów
zajmuje wtedy Unix loader.
ü Na niektórych platformach serwer jest około 5% wolniejszy w trakcie
działania
ü Moduły skompilowane do plików DSO nie mogą używać symboli spoza
rdzenia Apache, libc i innych bibliotek używanych przez rdzeń Apache.
ü Pod niektórymi platformami nie ma możliwości nakazania linkerowi
wyeksportowania wszystkich globalnych symboli używanych w DSO
podczas linkowania do programu httpd.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 37 z 44
8 PHP4
8.1 INSTALACJA
8.1.1
Instalacja jako DSO
Aby można było zainstalować PHP4 jako DSO Apache musi mieć
wkompilowany moduł mod_so. Obecność tego modułu można sprawdzić
komendą httpd –l.
Jeśli moduł mod_so jest obecny, można przystąpić do wykonania
następujących kroków:
$ gunzip -c php-4.0.x.tar.gz | tar xf -
$ cd php-4.0.x
$ ./configure --with-mysql --with-apxs
$ make
$ make install
Jeśli pojawi się komunikat o błędzie, mówiący, że nie można odnaleźć
skryptu apxs, należy poszukać go w systemie i dostarczyć pełną ścieżkę do
niego: --with-apxs=/path/to/apxs
Na etapie konfiguracji może pojawić się kilka błędów. Jednym z
najczęstszych jest niemożność odnalezienia przez skrypt configure plików
wpisanych w opcjach. Problem ten można rozwiązać przez wpisanie pełnych
ścieżek dostępu do danych plików.
Po wykonaniu komendy make install w pliku httpd.conf powinna znajdować
się linia:
LoadModule php4_module libexec/libphp4.so
Jeśli gdzieś w pliku httpd.conf znajduje się linia ClearModuleList, powinna
się w nim również znaleźć linia:
AddModule mod_php4.c
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 38 z 44
Następnie należy skopiować php.ini-dist w odpowiednie miejsce (zazwyczaj
/usr/local/lib/php.ini) i wyedytować go, aby ustawić odpowiednie opcje
PHP.
Teraz należy wyedytować plik httpd.conf i upewnić się, że typ MIME PHP 4
znajduje się tam odkomentowany. Typ ten powinna określać linia:
AddType application/x-httpd=php .php
Teraz należy zrestartować serwer (apachectl restart). W tym momencie
serwer powinien być w stanie obsługiwać pliki PHP.
8.1.2
Instalacja jako moduł statyczny
Aby dokonać szybkiej instalacji php4 jako modułu statycznego należy
wykonać następujące operacje:
$ gunzip -c apache_1.3.x.tar.gz | tar xf -
$ cd apache_1.3.x
$ ./configure
$ cd ..
$ gunzip -c php-4.0.x.tar.gz | tar xf -
$ cd php-4.0.x
$ ./configure --with-mysql --with-apache=../apache_1.3.x --enable-
track-vars
$ make
$ make install
$ cd ../apache_1.3.x
$./configure
--prefix=/www
--activate-
module=src/modules/php4/libphp4.a
Zazwyczaj php budowany jest jako moduł Apache. Aby to było możliwe,
należy podać ścieżkę dostępu do kodu źródłowego serwera. Umożliwia to
opcja –-with-apache=”ścieżka dostępu”. Jeśli zostanie podana jedynie
wartość –-with-apache, skrypt będzie szukał kodu w domyślnym katalogu:
/usr/local/etc/httpd
Uwaga: Katalog podany w opcji –-with-apache powinien być głównym
katalogiem rozpakowanej dystrybucji Apache. Program konfiguracyjny
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 39 z 44
automatycznie przeszuka wszystkie podkatalogi w poszukiwaniu pliku
httpd.h.
Opcja –with-mysql odnosi się do katalogu zawierającego MySQL. Domyślnie
jest to /usr/local. Jeśli MySQL jest zainstalowany w innym katalogu, należy
podać w tej opcji pełną ścieżkę dostępu.
W momencie wpisywania ostatniej komendy libphp4.a jeszcze nie istnieje;
zostanie dopiero utworzone.
$ make
$ cd ../php-4.0.x
$ cp php.ini-dist /usr/local/lib/php.ini
Na tym etapie należy zamknąć obecny serwer i podmienić plik httpd na
nowy.
Następnie należy wyedytować plik /usr/local/lib/php.ini aby ustawić opcje
PHP. Do pliku httpd.conf należy dodać linię:
AddType application/x-httpd=php .php
Następująca linia może być pomocna przy debugowaniu – umożliwia
kolorowe podświetlanie składni:
AddType application/x-httpd-php-source .phps
W tym momencie każdy plik zakończony .phps będzie wyświetlany z
podświetloną składnią, a nie wykonywany.
Po ponownym uruchomieniu serwer powinien móc obsługiwać php.
9 Apache jako serwer pośredniczący (proxy)
Zabezpieczenie firmowych sieci i serwerów przed niepożądaną ingerencją z
zewnątrz jest jednym z najważniejszych problemów, przed jakimi stają
administratorzy WWW. Jedną ze sprawdzonych i popularnych technik jest
odgrodzenie chronionego systemu od świata za pomocą firewalla. Aby móc
pracować w ten sposób należy oprócz właściwego serwera zarządzającego
zasobami uruchomić jeszcze jedną kopię serwera Apache, która jako proxy
będzie pośredniczyć w połączeniach.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 40 z 44
9.1 DYREKTYWY STERUJĄCE SERWEREM POŚREDNICZĄCYM
Zajmiemy się tutaj takim skonfigurowaniem serwera Apache, aby zapewnić
dobre warunki pracy użytkownikom znajdującym się wewnątrz strefy
chronionej przez firewalla.
W katalogu witryny chronionej przez proxy powinny się znaleźć następujące
podkatalogi:
cache, proxy i real.
W katalogu proxy powinien znaleźć się plik konfiguracji serwera zawierający
treść mniej więcej postaci:
User webuser
Group webgroup
ServerName
Port 8000
ProxyRequests on
CacheRoot /usr/www/site.proxy/cache
CacheSize 100000
W powyższym zapisie ważne są następujace elementy:
ü Nazwa domenowa witryny ustalona dyrektywą ServerName
ü Numer portu (Port) ustalony na 8000. Pozwala to na zmianę serwera
pośredniczącego bez modyfikacji plików konfiguracji serwera należących
do użytkowników.
ü Dyrektywa ProxyRequests, włączająca serwer pośredniczący
ü Dyrektywa CacheRoot, definiująca katalog przeznaczony do obsługi
buforów pamięci podręcznej (cache)
ü Dyrektywa CacheSize, ustalająca wielkość bufora pamięci podręcznej na
100000 kilobajtów.
ProxyRequests on|off
Wartość domyślna: off
Użycie: konfiguracja główna
Dyrektywa ta włącza lub wyłącza funkcję serwera pośredniczącego.
Dyrektywy ProxyPass są uwzględniane również w przypadku wyłączenia
serwera pośredniczącego poleceniem ProxyRequests off.
ProxyRemote wzorzec serwer-zdalny
Użycie: konfiguracja główna
Dyrektywa ta pozwala na określenie zdalnych serwerów pośredniczących
współpracujących z danym serwerem. Parametr wzorzec może określać
protokół obsługiwany przez zdalny serwer, część adresu URL, który ma być
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 41 z 44
obsłużony przez ten serwer, może też być znakiem gwiazdki, co oznacza, że
zdalny serwer pośredniczący ma obsługiwać wszystkie żądania. Adres
serwera określony jest parametrem serwer-zdalny, którego postać jest
następująca:
Serwer-zdalny=protokó
ł://nazwa-hosta[:port]
ProxyPass
ścieżka URL
Użycie: konfiguracja główna
Dyrektywa ta umożliwia przetłumaczenie odwołania do danego katalogu
(oraz jego podkatalogów) na żądanie skierowane do innego serwera. Nasz
włąściwy serwer nie działa w tym przypadku jak typowy serwer
pośredniczący, a raczej jako zwierciadlane odbicie serwera zewnętrznego. Dla
przykładu odwołania do katalogu /tajne w witrynie witryna1 mogą zostać
przekazane do serwera o nazwie innyserwer.com w następujący sposób:
ProxyPass /tajne
ProxyDomain domena
Użycie: konfiguracja główna
Dyrektywa ta ma praktyczne zastosowanie wyłącznie w sieciach typu
intranet i określa domyślną domenę zawierającą serwer pośredniczący
realizowany przez program Apache. Nazwa domeny jest automatycznie
dołączana do wszystkich adresów, które jej nie zawierają, co zapewnia
poprawną interpretację odwołań wykorzystujących tylko nazwę hosta.
NoProxy domena|podsiec|adres-IP|nazwa-domenowa
Podobnie jak poprzednio, zastosowanie dyrektywy NoProxy ogranicza się do
użycia programu Apache jako serwera pośredniczącego w sieciach typu
intranet. Umożliwia one określenie listy komputerów obsługiwanych z
pominięciem serwera pośredniczącego (żądania kierowane do tych
komputerów przetwarzane są bezpośrednio). Lista parametrów dyrektywy
NOProxy zawiera specyfikacje komputerów podane w postaci kompletnych
nazw domenowych, ich fragmentów, adresów IP lub adresów podsieci.
ProxyPassReverse sciezka URL
Użycie: konfiguracja główna, serwery wirtualne
Reverse proxy umożliwia rozłożenie obciążenia pomiędzy kilka serwerów
poprzez odbieranie nadchodzących żądną i kierowanie ich do jednego z kilku
serwerów zajmujących się ich właściwą obsługą.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 42 z 44
9.2 BUFOROWANIE STRON
Innym powodem dla stosowania serwerów pośredniczących jest możliwość
buforowania przez nie danych pobieranych z sieci, co pozwala zredukować
obciążenie sieci i skrócić czas oczekiwania na pojawienie się żądanych
informacji.
Do zarządzania pamięcią podręczną serwera służą następujące dyrektywy:
CacheRoot katalog
Wartość domyślna: brak
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta ustala główny katalog przeznaczony do przechowywania
buforowanych plików. Serwer Apache musi posiadać do niego prawa zapisu.
CacheSize rozmiar
Wartość domyślna 5
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta ustala pojemność pamięci podręcznej w kilobajtach. Zadana
wartość może być przekroczona , ale nadmiarowe dane zostaną usunięte w
procesie czyszczenia buforów pamięci podręcznej.
CacheGcInterval czas
Wartość domyślna: nigdy
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta określa odstęp (w godzinach) między kolejnymi operacjami
usuwania nadmiarowych danych z buforów pamięci podręcznej.
CacheMaxExpire czas
Wartość domyślna: 24
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta określa maksymalny czas w godzinach przechowywania
dokumentów w buforach pamięci podręcznej. Ograniczenie to ma
zastosowanie również wówczas, gdy okres ważności zapisany w dokumencie
jest dłuższy niż wartość określona tą dyrektywą.
CacheLastModifiedFactor mno
żnik
Wartość domyślna: 0.1
Użycie: konfiguracja główna, serwery wirtualne
Jeśli dokument nie zawiera informacji o terminie ważności, jest ona
obliczana szacunkowo jako iloczyn czasu, który upłynął od ostatniej
modyfikacji i wartości parametru tej dyrektywy. Tak obliczony czas ma
priorytet niższy, niż wynikający z dyrektywy CacheMaxExpire.
CacheDefaultExpire czas
Wartość domyślna: 1
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 43 z 44
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta określa czas ważności dla dokumentów pobranych za pomocą
protokołu nie pozwalającego na ustalenie okresu ważności. Ma ona priorytet
nad dyrektywą CacheMaxExpire.
CacheDirLevels liczba, CacheDirLength liczba
Wartość domyślna: 3 i 1
Użycie: konfiguracja główna, serwery wirtualne
Nazwy plików zawierających buforowane dane tworzone są jako skróty
adresów URL dokumentów. Każda nazwa dzielona jest na n segmentów o
długości m znaków każdy, będących nazwami kolejnych podkatalogów;
wartość n (głębokość struktury katalogów) definiowana jest za pomocą
dyrektywy CacheDirLevels, zaś m (długość nazwy podkatalogu) – za pomocą
dyrektywy CacheDirLength. Rozwiązanie takie skraca czas dostępu do plików
zawierających buforowanie dokumenty, gdyż jednopoziomowe sruktury
plików są w większości systemów mało wydajne. Dla przykładu ustawienia:
CacheDirLevels 3
CacheDirLength 2
Spowodują, że wygenerowany na podstawie adresu URL skrót abcdefghijk
zostanie przekształcony w nazwę pliku ab/cd/ef/ghijk.
Skróty wykorzystywane przez moduł proxy Apache mają długość 22 znaków i
wykorzystują alfabet 64-znakowy, z czego wynika, że użycie trzypoziomowej
struktury katalogów o jednoznakowych nazwach daje 2
18
różnych
podkatalogów. Liczba podkatalogów powinna być dostosowana do
przewidywanej liczby wpisów w pamięci podręcznej. 2
18
pozwala na
efektywną obsługę pamięci przechowującej do kilku milionów elementów.
CacheNegotiatedDocs
Wartość domyślna: brak
Użycie: konfiguracja główna, serwery wirtualne
Umieszczenie w pliku konfiguracji serwera tej dyrektywy nakazuje serwerowi
proxy buforowanie dokumentów, których zawartość jest uzgadniana.
Dyrektywa ta ma znaczenie wyłącznie w przypadku użycia protokołu
HTTP/1.0, gdyż HTTP/1.1 zapewnia skuteczną kontrolę buforowania
dokumentów o uzgadnianej zawartości.
NoCache nazwa|domena nazwa|domena …
Wartość domyślna: brak
Użycie: konfiguracja główna, serwery wirtualne
Dyrektywa ta umożliwia wyszczególnienie nazw komputerów oraz (lub)
domen, dla których buforowanie transakcji nie będzie używane. Poszczególne
nazwy na liście parametrów oddzielone są spacjami.
Referat z przedmiotu "Administracja systemami komp."
Aleksandra Duda
Maciej Borowiec
Szymon Brandys
Strona 44 z 44
10 Materiały
Korzystaliśmy z następujących materiałów:
1. tutorial dostarczony z Apache
2. Ben Laurie i Peter Laurie „Apache-przewodnik encyklopedyczny”
3. PHP4 manual (instalacja)
Wyszukiwarka
Podobne podstrony:
httpd 4
HTTPD, J FORMS, Tworzenie formularzy HTML, mechanizm CGI
HTTPD, J HTTPD, httpd apache_1.0.3
httpd 1
httpd 4
httpd 2
więcej podobnych podstron