Administracja Sieciowymi systemami operacyjnymi.
Wykład 3
Proszę Państwa, nawiązując do tematów omawianych przez nas i
reprezentowanych na ćwiczeniach, pragnął bym umieścić w powyższym wykładzie kilka ciekawostek.
1) Proszę doczytać o macierzach http://pl.wikipedia.org/wiki/RAID.
RAID'a 5 instaluje się na min 3 dyskach.
Więc przy 4 jak najbardziej działa.
Oczywiście na np. 8 dyskach instalował, bym już RAID'a 6 (awaria dwóch dysków pozwala działać dalej całości).
Przykład , iż na 5-6ciu dyskach SSD da się wyciągnąć 2GB/s !!!!
Nie trzeba super 24dyskowych macierzy SAS (kto i po co jeszcze tego używa?).
[root@aaricia ~]# hdparm -tT /dev/md2
/dev/md2:
Timing cached reads: 7168 MB in 2.00 seconds = 3586.26 MB/sec
Timing buffered disk reads: 3004 MB in 3.00 seconds = 1000.87 MB/sec
[root@aaricia ~]# hdparm -tT /dev/md2
/dev/md2:
Timing cached reads: 7164 MB in 2.00 seconds = 3584.92 MB/sec
Timing buffered disk reads: 3358 MB in 3.00 seconds = 1119.25 MB/sec
[root@aaricia ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md4 : active raid5 sda4[0] sdd4[4] sdc4[2] sdb4[1]
2921472 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
md3 : active raid5 sda3[0] sdd3[4] sdc3[2] sdb3[1]
640189440 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
md1 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
393472 blocks [4/4] [UUUU]
md2 : active raid5 sda2[0] sdd2[4] sdc2[2] sdb2[1]
58601472 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
I przy tym wszystkim oczywiście nie należy zapominać, iż nie ważne, z jaką prędkością działa dysk. Lecz istotne bardziej są czasy dostępu do niego (gdzie w przypadku dysków SSD
w porównaniu z talerzowymi wartości te są diametralnie różne !!).
2) Jacek Rumiński - Język JAVA - Rozdział 4
"Programy Javy (zarówno aplety jak i aplikacje) są ze swej natury wielowątkowe. Świadczy o tym choćby najprostszy podział na min dwa wątki: wątek obsługi kodu z metodą main() (dla aplikacji) oraz wątek zarządzania stertą GarbageCollection...."
U mnie odpalony jeden program w javie (do zarządzania sieciami - mojego autorstwa) odpala kilkanaście wątków (aplikacja nie napisana wielowątkowo !!).
[root@Misiek ~]# ps -eLf;
UID PID PPID LWP C NLWP STIME TTY TIME CMD
grzegorz 1764 1747 1764 7 21 08:36 ? 00:06:22 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1946 0 21 08:36 ? 00:00:00 /usr/lib64/icedove/icedove-bin 1
grzegorz 1764 1747 1947 0 21 08:36 ? 00:00:12 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1967 0 21 08:36 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1970 0 21 08:36 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1971 0 21 08:36 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1972 0 21 08:36 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1979 0 21 08:36 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 1982 0 21 08:36 ? 00:00:05 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2010 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2024 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2046 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2061 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2062 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2073 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2076 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2077 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2086 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2125 0 21 08:37 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2161 0 21 08:39 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1764 1747 2557 0 21 09:24 ? 00:00:00 /usr/lib64/icedove/icedove-bin grzegorz 1857 1856 1857 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1866 0 16 08:36 pts/0 00:00:01 java Menu1 172.20.0.
grzegorz 1857 1856 1887 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1888 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1938 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1941 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1942 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1974 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1975 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1976 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1977 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 1978 0 16 08:36 pts/0 00:00:02 java Menu1 172.20.0.
grzegorz 1857 1856 2007 0 16 08:36 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 2051 0 16 08:37 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 2102 0 16 08:37 pts/0 00:00:00 java Menu1 172.20.0.
grzegorz 1857 1856 2103 0 16 08:37 pts/0 00:00:00 java Menu1 172.20.0.
Oczywiście nie możemy mówić o zwielowątkowieniu samej aplikacji, gdyż za to odpowiedzialna jest klasa Thread. Jednakże jest to z pewnością ogromne ułatwinie dla programisty.
Podobnie się również dzieje, jeśli na VirtulaBoxie czy KVM'ie odpalimy Jedno rzdzeniową maszynę, której jednak przydzielanych jest od razu N wątków. Między innimi także z tej przyczyny Microsoft nie pozwalał kiedyś instalować swoich systemów na VM.
2
htpasswd -c tylko za pierwszym razem (c -> create)
htpasswd -m /home/services/subversion/repos/repos1/conf/passwd-apache2 grzegorz
# Apache moduly
httpd -t -D DUMP_MODULES
# Pomiar wskaznika predkosci i utraty pakietow - apache-tools
ab -n 100 -c 1 http://www.eu.edu:80/
vserver wanwww2 exec apachetop -T 1 -f /var/log/httpd/misiek
Strony które poddają się Atakom:
http://www.strona.pl/login.php
/no-cache-here.php
/search?q=find+me
# Zwykly test obciazeniowy
siege -l -c 30 http://futra.com.pl # cat /var/log/siege.log
# Zabijacz serwera ;-(
siege -c 250 https://futra.com.pl
# ping flood - czeste pingi
ping futra.com.pl -f
# ping flood + ping duza paczka
ping futra.com.pl -l 64000 -f
Każdy, nawet początkujący użytkownik sieci internet zetknął się z apaczem świadomie lub nie. Apache jest oprogramowaniem, które można powiedzieć zdominowało w pewnym stopniu rynek aplikacji serwerowych. Do działania wykorzystuje on protokół HTTP
(RFC2616). Jak sama nazwa wskazuje Apache (a patche server) składa się z wielu modułów.
Można to zauważyć już na pierwszy rzut oka. W tym rozdziale zostanie opisana autoryzacja, obsługa języka PHP, CGI, virtualhosts oraz ogólna jego konfiguracja. Przedstawiona poniżej oparta została o apache z serii 2.x.
Instalacja
Apache w PLD jest podzielony na wiele małych pakietów, możemy dzięki instalować tylko potrzebne moduły. Jeśli nie możemy się połapać w tym gąszczu to możemy posłużyć się metapakietem apache, który za pośrednictwem mechanizmu zależności zainstaluje najważniejsze pakiety.
# poldek -i apache
Kiedy będziemy mieli zainstalowane wymagane pakiety, będziemy mogli wstępnie przetestować serwer, zatem uruchomimy usługę:
3
W katalogu /home/services/httpd umieszczamy jakąś testową stronę WWW którą nazwiemy np. test.html i sprawdzamy za pomocą przeglądarki czy się prawidłowo wyświetla: $ elinks localhost/test.html
Jeśli wszystko jest w porządku, to możemy przejść do właściwej konfiguracji serwera.
Pliki konfiguracji
Tytułem wstępu pragnę powiedzieć, że niniejszy dokument nie może być traktowany jako dokumentacja do Apache. Ma on na celu ułatwienie użytkownikowi zapoznania się z usługą oraz kilkoma jej możliwościami. Po bardziej szczegółowe informacje odsyłam do stron podręcznika systemowego (man) oraz dokumentacji on-line
/etc/httpd/httpd.conf - w tym katalogu przechowywane są pliki konfiguracyjne demona. Po instalacji poszczególnych składników Apache, właśnie w tym miejscu należy szukać plików konfiguracyjnych od nich.
/home/services/httpd - pliki domyślnej strony Apache, katalog z komunikatami o błędach oraz katalog przeznaczony dla skryptów cgi.
/usr/lib/apache
- moduły potrzebne do działania Apache oraz poszczególnych jego
składników. Warto o tym pamiętać w przypadku problemów z uruchomieniem usługi.
/usr/sbin - jest to katalog należący stricte do Apache, jednak warto o nim wspomnieć ze względu na to iż przechowywane są w nim jego binaria. Aby się dowiedzieć które należą do niego wydaj następujące polecenie
# rpm -ql apache |grep ^\/usr\/sbin
Aby nasz serwer obsługiwał dodatkowe funkcje musimy zainstalować odpowiednie moduły, wraz z modułami dostarczane, są pliki konfiguracji z dyrektywami konfiguracyjnymi dla tego modułu.
Apache domyślnie działa z uprawnieniami zwykłego użytkownika (http), dlatego trzeba zadbać o to by demon miał prawo do odczytu plików ze stronami WWW.
Bardzo pożyteczną cechą Apache jest możliwość tworzenia lokalnych plików konfiguracji, dzięki którym możemy modyfikować niektóre opcje konfiguracji. Pliki te mają nazwę
.htaccess i może ich używać każdy, kto ma tylko dostęp do katalogu ze stroną WWW.
Wygoda w ich używaniu polega na tym, że nie ma potrzeby restartowania demona po każdorazowej ich modyfikacji.
Podstawowa konfiguracja
Głównym plikiem konfiguracyjnym jest /etc/httpd/apache.conf. Spośród wielu opcji w tym pliku zajmiemy się dwiema podstawowymi:
ServerAdmin root@example.net
4
Powinieneś tutaj wpisać kontaktowy adres e-mail do siebie jako administratora tego serwera.
Poniżej znajduje się opcja ServerName. Powinna ona wyglądać tak jak w poniższym przykładzie.
ServerName example.net:80
Dosłownie jest to nazwa tego serwera. A dokładniej nazwa domenowa skonfigurowana na serwerze nazw opiekującym się Twoją domeną. Jeżeli nie posiadasz zarejestrowanej domeny, powinieneś wpisać tutaj adres IP.
Teraz zajmiemy się opcją DocumentRoot, którą odnajdziemy w
/etc/httpd/conf.d/10_common.conf Określa ona domyślny katalog w którym będzie przechowywana strona internetowa. Wpisując nazwę lub adres IP określony przez ServerName właśnie z tego katalogu zostaną pobrane i wczytane przez przeglądarkę pliki strony.
DocumentRoot "/home/services/httpd/html"
Domyślnie wszystkie żądania są tutaj skierowane. Ta lokalizacja nie jest obligatoryjna, więc nie musisz się jej trzymać. Może zostać zmieniona przy użyciu dowiązań symbolicznych lub aliasów wskazujących w inne miejsca.
Zgodnie z obecnym standardem tworzenia stron internetowych, domyślnym plikiem który jest automatycznie wczytywany po wpisaniu w przeglądarce adresu jest index, który w zależności od konstrukcji strony może mieć różne rozszerzenia. A więc skąd Apache wie, co ma zostać wczytane jako pierwsze? Do tego właśnie służy pakiet apache-mod_dir. Jego plikiem konfiguracyjnym jest /etc/httpd/httpd.conf/59_mod_dir.conf
Poprzez dyrektywę DirectoryIndex określa się czego i w jakiej kolejności ma szukać przeglądarka.
DirectoryIndex index.html index.html.var index.htm index.shtml \
index.cgi index.php
Oczywiście możemy podawać tutaj różne nazwy plików startowych stron w zależności od naszych potrzeb.
Strony użytkowników
Swobodne publikowanie stron internetowych przez użytkowników jest możliwe dzięki pakietowi apache-mod_userdir. Opcja UserDir w pliku 16_mod_userdir.conf definiuje nazwę katalogu przechowującego strony użytkowników wewnątrz ich katalogów domowych.
UserDir public_html
Przykład: Użytkownik Jan Kowalski posiada konto o nazwie: jan. W /home/users/jan jest jego katalog domowy. Swoją stronę internetową umieszcza w katalogu
/home/users/jan/public_html, zaś dostęp do nie uzyskuje za pomocą adresu http://example.net/~jan.
5
Aby strona się wyświetliła należy ustawić odpowiednie prawa dostępu - tak by Apache (domyślnie z prawami użytkownika http) miał prawo do odczytu. Katalog domowy jan powinien mieć ustawione prawa 711. Katalog przechowujący jego stronę czyli public_html powinien mieć 755. Każdy katalog zawierający elementy strony powinien mieć również uprawnienia 755. Pliki strony natomiast 644.
Virtual Hosts
Mechanizm hostów wirtualnych pozwala obsługiwać strony o różnych adresach domenowych na jednej maszynie. Mechanizm ten jest realizowany na dwa sposoby: hosty oparte o adresy IP oraz oparte o nazwy, pierwsza z metod wymaga osobnego adresu IP dla każdego wirtualnego hosta, drugi zaś korzysta z jednego. Z oczywistych względów dużo bardziej popularna jest druga z metod i właśnie ją będziemy opisywać.
Obsługa hostów wirtualnych jest związana z odpowiednią konfiguracją domen w systemie DNS - wymaga wpisów typu IN A wskazujących na nasz serwer WWW. Konfigurację serwera DNS opisano w tym dokumencie i będzie docelowo konieczna, jednak dla potrzeb testowych wystarczą nam wpisy w pliku /etc/hosts, który z kolei został opisany w tym dokumencie.
W naszym przykładzie dodamy obsługę domeny moja-strona.com, na początku należy stworzyć dodatkowy plik konfiguracji (dla porządku) o nazwie np. vhosts.conf, który umieścimy w katalogu /etc/httpd/httpd.conf/. Zakładamy, że wszystkie vhosty będziemy trzymać w katalogu /home/services/httpd/vhosts/. Plik będzie się zaczynał od następującego zestawu opcji:
NameVirtualHost *
<Directory /home/services/httpd/vhosts>
Order allow,deny
Allow from all
</Directory>
<VirtualHost _default_>
DocumentRoot /home/services/httpd/html/
</VirtualHost>
Opcja NameVirtualHost wskazuje, które adresy IP serwera mają być używane do obsługi hostów witrualnych, w tym wypadku wszystkie, co jest najczęściej spotykaną konfiguracją.
Sekcja Directory zezwala na dostęp do plików ze wskazanego katalogu. Pierwszy zdefiniowany virtualhost (_default_) ma za zadanie wskazanie serwerowi domyślnej strony, wyświetlanej w wypadku jeśli jakiś vhost nie jest skonfigurowany na naszym serwerze, w przeciwnym razie wyświetli się strona pierwszego w kolejności vhosta. Teraz możemy dodawać vhosty, wg. przykładu:
<VirtualHost *>
ServerName moja-strona.com
DocumentRoot /home/services/httpd/vhosts/moja_strona
</VirtualHost>
Wewnątrz sekcji VirtualHost znajduje się opcja ServerName, mówiąca o nazwie domenowej vhosta, a poniżej wskazanie są ścieżki do katalogu z plikami strony. Po uruchomieniu 6
mechanizmu hostów wirtualnych całkowicie bezużyteczne staną się globalne opcje ServerName czy DocumentRoot, od tej pory konfiguracja w całości opiera się o vhosty. W
konfiguracji hostów wirtualnych możemy umieszczać wiele opcji używanych w głównym serwerze (np.: ServerAdmin, ErrorLog), tak zdefiniowane opcje przesłonią globalne wartości.
Istnieje możliwość masowego konfigurowania vhostów, bez konieczności tworzenia wpisów dla każdego po kolei, służy do tego moduł vhost-alias dostarczany wraz z pakietem apache-mod_vhost_alias. Jego opis wykracza poza ramy tego rozdziału, więcej na jego temat odnajdziemy w dokumentacji serwera.
Ograniczanie dostępu na podstawie adresu
Czasami chcemy ograniczyć możliwość przeglądania stron dla konkretnych adresów lub klas adresowych. W tym celu użyjemy modułu apache-mod_authz_host, dzięki niemu będziemy mogli chronić przed dostępem do wskazanych katalogów. Jeżeli potrzebujesz chronić jedynie jeden lub kilka plików, stwórz w obrębie strony katalog o dowolnej nazwie i umieść je w nim.
Oczywiście musisz pamiętać o przekonstruowaniu linków na stronie.
Do konfiguracji Apache dodajemy podobną konstrukcję konstrukcję:
<Directory "/home/users/jan/public_html/intra">
Order allow,deny
Allow from 123.45.0.0/255.255.0.0
Allow from 56.67.9.34
</Directory>
Dostęp do katalogu intra mają wszystkie komputery z określonej w przykładzie sieci oraz jeden komputer (bądź urządzenie udostępniające NAT) o wymienionym adresie. Wszystkie połączenia nie pasujące do tych kryteriów traktowane są jako deny, zgodnie z porządkiem wyznaczonym przez dyrektywę Order.
Ograniczenie dostępu za pomocą loginu i hasła
Apache udostępnia mechanizm autoryzacji, który używany jest do wyodrębnienia z serwisu pewnej części przeznaczonej dla upoważnionych użytkowników. Ograniczenie działa na poziomie katalogów i podobnie jak w ograniczeniu dla adresu (opisanego powyżej) nie można w ten sposób chronić poszczególnych plików.
Apache wspiera wiele rodzajów źródeł uwierzytelniających: pliki tekstowe, konta systemowe, bazy LDAP i inne. My będziemy zajmować się autoryzacją za pomocą plików tekstowych, ze względu na popularność i prostotę tego rozwiązania. Istnieją dwa protokoły przesyłania hasła Basic i Digest (w postaci skrótu). Metoda Digest jest bezpieczniejsza jednak praktycznie nie jest obsługiwana przez przeglądarki WWW, tak więc pozostaje nam używanie metody Basic.
Zaczynamy od instalacji metapakietu apache-mod_auth oraz pakietu htpasswd-apache. Teraz dodajemy do któregoś z plików konfiguracji regułkę chroniącą katalog :
<Directory "/home/users/jan/public_html/private">
AuthType Basic
AuthBasicProvider file
AuthName "Witaj Janie, zaloguj sie."
AuthUserFile /home/services/httpd/.htpasswd
7
</Directory>
Opcja AuthUserFile wskazuje plik z loginami i hasłami użytkowników, jak widać ścieżka ta jest inna niż chroniony katalog ze względów bezpieczeństwa. Opcja Require określa jacy użytkownicy są akceptowani - tutaj każdy autoryzowany.
Teraz tworzymy plik z hasłami, poprzez dodanie pierwszego konta:
# htpasswd -c /home/services/httpd/.htpasswd jan
New password:
Re-type new password:
Adding password for user jan
Plikowi ustawiamy odpowiednie uprawnienia i własność, aby dostęp do niego miał wyłącznie użytkownik http:
# chmod 600 /home/services/httpd/.htpasswd
# chown http.http /home/services/httpd/.htpasswd
Po restarcie każde odwołanie do katalogu będzie wymagało podania loginu jan i hasła.
Istnieje także możliwość dodania obsługi grup - mechanizmu zbliżonego działaniem do uniksowych grup systemowych.
W wielu wypadkach będziemy chcieli dać możliwość użytkownikom tworzenia plików z hasłami z wraz z plikami .htaccess w katalogu określonym przez DocumentRoot. Stanowi to zagrożenie bezpieczeństwa, ze względu na możliwość wyświetlenia zawartości tych plików.
Możemy się zabezpieczyć przed tym instalując pakiet apache-mod_authz_host, dzięki któremu m.in. nie zostaną wysłane do przeglądarki pliki .ht*
Obsługa skryptów PHP
Ze względu na dużą funkcjonalność język PHP stał się już w zasadzie pewnym standardem w tworzeniu interaktywnych stron internetowych. Współczesne serwisy wykorzystują m. in.
bazy danych, dlatego zostanie również opisane jak taką obsługę zapewnić. Przeglądając listę dostępnych do zainstalowania pakietów z PHP na pierwszy rzut oka widać nacisk twórców dystrybucji jaki został nałożony na modularność. Daje to niesamowitą wolność w wyborze tego co jest Ci dokładnie potrzebne.
Zaczynamy od instalacji pakietu apache-mod_php, w ten sposób otrzymamy podstawową wersję PHP, dodatkowe pakiety instalujemy wtedy gdy potrzebna nam jest jakaś funkcjonalność. Najlepszą metodą sprawdzenia czy PHP działa jest użycie funkcji phpinfo(), aby z niej skorzystać stwórz plik z zawartością taką jak poniżej:
<? phpinfo(); ?>
następnie należy go umieść w katalogu /home/services/httpd/html, pod nazwą np. info.php.
Teraz wpisujemy w przeglądarce adres http://example.net/info.php, powinieneś uzyskać informacje m. in. na temat wersji PHP, konfiguracji serwera oraz obsługiwanych modułów.
8
Obsługa różnego typu systemów bazodanowych rozbita jest na osobne pakiety zawierające definicje funkcji PHP które ją zapewniają. Poniżej w tabeli znajduje się lista która to odzwierciedla.
Nazwa pakietu
Baza Danych
php-dba
Moduł dla PHP dodający obsługę dla baz danych opartych na plikach (DBA).
php-dbase
Moduł PHP ze wsparciem dla DBase.
php-filepro
Moduł PHP dodający możliwość dostępu (tylko do odczytu) do baz danych filePro.
php-interbase Moduł PHP umożliwiający dostęp do baz danych InterBase i Firebird.
php-mssql
Moduł PHP dodający obsługę baz danych MS SQL poprzez bibliotekę
FreeTDS.
php-mysql
Moduł PHP umożliwiający dostęp do bazy danych MySQL.
php-odbc
Moduł PHP ze wsparciem dla ODBC.
php-pgsql
Moduł PHP umożliwiający dostęp do bazy danych PostgreSQL.
php-sybase
Moduł PHP dodający obsługę baz danych Sybase oraz MS SQL poprzez
bibliotekę SYBDB.
php-sybase-ct Moduł PHP dodający obsługę baz danych Sybase oraz MS SQL poprzez CT-lib.
Aby skorzystać z którego kolwiek modułu wystarczy go po prostu zainstalować.
Przeprowadzając instalację w trybie wsadowym pamiętaj o zrestartowaniu usługi apache, o czym zostaniesz przez poldka poinformowany. Dystrybucja nie posiada niestety pakietów do obsługi bazy danych Oracle. Jeżeli jest Ci ona potrzebna musisz zbudować PHP włączając obsługę oracla z serwera CVS, instalując uprzednio Oracla którego posiadasz.
Warto jeszcze wspomnieć o narzędziach wspomagających zarządzanie bazami danych. Do obsługi bazy MySQL służy pakiet phpMyAdmin natomiast do PostgreSQL zainstaluj phpPgAdmin. Szerzej o tych aplikacjach w dokumentacji do tych systemów.
CGI
Aby nasz Apache obsługiwał programy CGI wystarczy zainstalować pakiet apache-mod_cgi.
Po przeładowaniu demona programy CGI obsługiwane będa w katalogu
/home/services/httpd/cgi-bin, zgodnie z ustawieniami w pliku /etc/httpd/apache.conf.
Żeby przetestować CGI wystarczy że utworzymy plik o następującej treści:
#!/bin/sh
echo "Content-type: text/html\n\n"
echo "Hello, World."
a następnie umieścimy go w odpowiednim katalogu z nazwą np. cgi.sh, nadamy mu prawo wykonywalności i w przeglądarce podamy adres http://example.net/cgi-bin/cgi.sh. Możemy do tego użyć również testowych skryptów przychodzących z pakietem apache-cgi_test.
Jeśli zechcemy wskazać więcej katalogów w których pozwolimy uruchamiać aplikacje CGI (np. dla hostów wirtualnych) wystarczy, że do któregoś z plików konfiguracji dodamy odpowiednio skonfigurowaną opcję ScriptAlias np.:
ScriptAlias /cgi-bin/ "/home/users/jan/cgi-bin/"
9
Ze względów bezpieczeństwa autorzy Apache zalecają by taki katalog leżał poza ścieżką wskazaną w opcji DocumentRoot.
Security Socket Layer (SSL)
Mechanizm ten wykorzystuje się w serwisach wymagających od użytkownika autoryzacji.
Najbardziej typowymi aplikacjami tego typu są różnego rodzaju klienci poczty. SSL
zapewnia szyfrowany kanał dla informacji przepływającej od użytkownika do serwera. Dzięki temu niemożliwe jest podsłuchanie hasła. UWAGA! Jeden certyfikat SSL może zostać przypisany tylko dla jednego adresu IP.
Konfigurację zaczynamy od zainstalowania pakietu apache-mod_ssl. W wyniku instalacji utworzony zostanie plik /etc/httpd/httpd.conf/40_mod_ssl.conf. Zanim zaczniemy go konfigurować należy wygenerować certyfikaty. Służy do tego polecenie openssl. Program ten znajduje się w pakiecie openssl-tools.
# openssl genrsa -out /etc/httpd/ssl/apache.key 1024
W wyniku tego polecenia zostanie utworzony plik apache.key który posłuży do tworzenia certyfikatu. Robimy to w następujacy sposób.
# openssl req -new -x509 -days 365 -key /etc/httpd/ssl/apache.key \
-out /etc/httpd/ssl/apache.crt
Proces tworzenia certyfikatu będzie wymagał podania kilku informacji. Zostaniesz o nie poproszony trakcie jego trwania.
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Województwo
Locality Name (eg, city) []:Miasto
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Firma
Organizational Unit Name (eg, section) []:Web Server
Common Name (eg, YOUR name) []:example.net
Email Address []:root@example.net
Pola, które widzisz w powyższym przykładzie należy wypełnić zgodnie z tym jak zostało to przedstawione. W przypadku kiedy serwer jest prywatną własnością i nie należy do żadnej firmy, w polu Organization Name możesz wpisać imię i nazwisko. Para plików: klucz oraz certyfikat powinny mieć takie uprawnienia, aby użytkownik http mógł je odczytywać.
Możemy teraz wyedytować plik /etc/httpd/httpd.conf/40_mod_ssl.conf. Pośród szeregu opcji interesuje nas w zasadzie tylko konfiguracja katalogu, do którego połączenie będzie szyfrowane oraz ścieżki do plików z kluczem oraz certyfikatem. Musimy odnaleźć początek sekcji o nazwie VirtualHost.
<VirtualHost _default_:443>
DocumentRoot "/home/services/httpd/html/webmail"
ServerName mail.example.net:443
ServerAdmin root@example.net
ErrorLog /var/log/httpd/error_log
10
TransferLog /var/log/httpd/access_log
Jak widać jej początek nie różni się niczym od konfiguracji VirtualHosts. Zwróć uwagę na opcję ServerName. Powinna ona kończyć się ciągiem :443 który oznacza port na którym ma nasłuchiwać demon. Przechodzimy dalej i zmieniamy takie opcje jak SSLCertificateFile oraz SSLCertificateKeyFile.
SSLCertificateFile /etc/httpd/ssl/apache.crt
SSLCertificateKeyFile /etc/httpd/ssl/apache.key
Podajemy tutaj ścieżki do plików które wygenerowaliśmy w poprzednim etapie.
Po zapisaniu i zakończeniu edycji pliku restartujemy Apache, aby nasze zmiany odniosły skutek. Aby nawiązać połączenie szyfrowane z webmailem należy w przeglądarce wpisać adres https://example.net/webmail. Aby ustanowić połączenie szyfrowane i za każdym razem nie wpisywać https://, powinieneś użyć mechanizmu vhosts. Stwórz katalog
/home/services/httpd/html/mail dla którego zrobisz wpis w pliku 20_mod_vhost_alias.conf.
Czyli zgodnie z tym czego już się dowiedziałeś, robisz wpis w pliku strefy domeny oraz konfigurujesz apache. Natomiast w katalogu /home/services/httpd/html/mail tworzysz plik o nazwie index.php z zawartością taką jak w przykładzie.
<?php
/**
* index.php -- Displays the main frameset
*
* Copyright (c) 1999-2002 The SquirrelMail Project Team
* Licensed under the GNU GPL. For full terms see the file COPYING.
*
* Redirects to the login page.
*
* $Id: index.php,v 1.13 2002/02/19 15:05:03 philippe_mingo Exp $
*/
header("Location: https://poczta.example.net\n\n");
exit();
?>
Oczywiście domena, która jest podana na listingu musi odnosić się do vhosta z opcją DocumentRoot ustawioną na /home/services/httpd/html/mail.
Indeksowana zawartość katalogu
Jest to bardzo przydatna funkcja, pozwalająca w łatwy sposób udostępnić zawartość katalogu na serwerze. Aby umożliwić indeksowanie musimy zainstalować moduł apache-mod_autoindex.
poldek -i apache-mod_autoindex
11
Aby uruchomić indeksy musimy włączyć opcję Indexes. W domyślnej konfiguracji, Apache ma włączone indeksy dla wszystkich podkatalogów wewnątrz /home/services/httpd/html (w pliku 10_common.conf). Jeśli ustawiliśmy inaczej to musimy włączać tą opcję dla każdego z katalogów osobno np.:
<Directory /home/services/httpd/html/katalog>
Options Indexes
</Directory>
Opcja nie zadziała wtedy, kiedy zainstalowaliśmy moduł apache-mod_dir i w katalogu znajduje się plik określony przez DirectoryIndex.
Uwagi
Po każdej zmianie konfiguracji w katalogu /etc/httpd/httpd.conf konieczne jest przeładowanie demona, aby na nowo odczytał swoje pliki konfiguracji. Możemy użyć w tym celu odpowiedniego wywołania rc-skryptu:
# service httpd restart
Jeśli będziemy modyfikować konfigurację działającego serwera produkcyjnego, to dobrą praktyką jest wcześniejsze użycie programu apachectl z pakietu apache-tools do sprawdzenia poprawności składni plików konfiguracji:
# apachectl configtest
Syntax OK
Na szczególną uwagę zasługują parametry rc-skryptu: reload|force-reload|graceful np.:
# service httpd reload
Użycie któregoś z nich wywołuje "łagodny" restart serwera (graceful restart), który pozwala dokończyć wykonywane prace przez procesy. Dzięki temu restart nie jest odczuwalny przez klientów. Parametry te mają jeszcze jedną ważną zaletę, wywołanie ich powoduje sprawdzenie konfiguracji serwera przed rozpoczęciem restartu, dzięki czemu nie musimy do tego używać programu apachectl.
Życzę sukcesów na nauce !!
Grzegorz Miśkiewicz
12