🚀 go-pugleaf

Jak zapewnie co poniektorzy z tu obecnych wiedza wplatany jestem w radosne
tworczosci pod tytulem dziwne serwery WWW wlasnej produkcji ;-))).. Z racji
moich zainteresowan, stworzylem kiedys szkielet nie forkujacego sie serwera
WWW... Nawet dzialajacego ;-))) Ktory mimo ze nie zostal opublikowany,
zostal wykorzystany do kilku roznych projektow... Jeden z nich (najstarszy
;-))) dziala juz ponad 9 miesiecy, pracujac 24 h/dobe i serwuje kilka
milionow hitow miesiecznie w najwiekszej Polskiej sieci reklamowej, nie
zajmujac nawet polowy procenta czasu procesora.

Pewien czas temu postanowilem unormalnic ten serwer - tzn. dodac normalna
konfiguracje (tzn. mozliwosc konfiguracji przez normalne pliki tekstowe) a
takze wszystkie normalne funkcje (wywalajac specyficzne pisane pod konkretne
rozwiazania) i go upublicznic. A jest co - zadko jaki serwer daje sobie rade
np. z tysiacem rownoleglych polaczen (w tym samym czasie) na zwyklym
Pentiumku z 64 MB Ram'u oraz FreeBSD. Co bardziej zainteresowanym proponuje
przetestowanie np. Apacha w podobnej konfiguracji.

W obecnej chwili stanelem w miejscu konfiguracji. Wczesniej serwer czesc
informacji mial wpisane bezposrednio w kod, reszte wyciagal sobie z roznych
baz danych (specyficznych dla kazdego uzytego rozwiazania). Teraz wypada
czytac jakies pliki konfiugracyjne. I powstalo kilka problemow/pytan:

- jak uwazacie na ile warto trzymac sie stylu plikow konfiguracyjnych
stworzonego przez httpd i utrzymywanego przez Apacha. Z jednej strony warto
trzymac sie hmmm 'standartu', z drugiej strony pliki konfiguracyjne Apacha
wydaja mi sie bardzo nielogiczne (a co najmniej - nie utrzymane w jednej
konwencji). Dam przyklad: Ustalanie pewnych parametrow w stosunku do
okreslonej grupy dokumentow. Mozna to robic przez az piec roznych metod
(<VirtualHost>, <Directory>, <Location>, <Files>, pliki htaccess). Rozumiem
jeszcze koniecznosc rozdzielenia konfiguracji calego serwera WWW od reszty
(zazwyczaj jest tam wiele opcji ktore mozna ustawic tylko dla calego serwera
WWW), oraz pliki htaccess. Ale <Directory>, <Location> oraz <Files> w pewnym
sensie sie dubluja. Wystarczylo by wprowadzic jednolity format okreslania
konfiguracji dla okreslonych url'i.

- Druga kwestia jest obsluga plikow konfiguracyjnych per katalog (ala
htaccess). Od razu zadaje pytanie na ile jest to uzywane w Internecie? I czy
tu trzymac sie opisu Apacha (tak jak to zrobili w komercyjnym serwerze WWW
Zeus 3 - gdzie konfiguracja calego serwera jest specyficzna dla Zeus'a, ale
httaccessy sa komatybilne z Apachem)?

- Trzecia sprawa - wirtual host o roznych IP. Istnieja dwie metody
implementacji:
  a) Serwer przybindowuje sie do portu 80 nie okreslajac adresu (czyli
akceptuje polaczenia na wszystkie adresy ip interfasow Unix'a). Dostajac
polaczenia sprawdza pod jaki adres ip bylo skierowane i wyszukuje sobie
odpowiedniego "VirtualHosta" z jego konfiguracja. Tak robi np. Apache. To
rozwiazanie ma jednak jedna wade - gdy podamy np. <VirtualHost
xxx.com.pl:8080> to Apache nie bedzie odbieral takich polaczen - bo jest
przybindowany tylko do portu 80. Trzeba Apachowi wczesniej przy uzyciu
komendy Bind lub Listen dopowiedziec ze ma sie dobindowac takze pod port
8080.
b) Serwer przybindowuje sie do okreslonych w "VirtualHost" adresow ip i
portow - dla kazdego VirtualHost z osobna. Z chwila jak mamy np. 2
virtualHosty - np: xxx.com i yyy.com - serwer przybindowuje sie do portow 80
na tych adresach (tylko tych adresach). Jezeli bedziemy probowali sie
polaczyc na inny adres danego Unix'a (np. 127.0.0.1 ;-))) to polaczenie nie
zostanie odebrane bo nie byl podany taki adres w ktoryms z VirtualHostow...
Teoretycznie mozna w jednym VirtualHost podac jako adres cos w rodzaju any -
co spowoduje ze dla tego VirtualHost'a serwer przybinduje sie pod port 80
dla wszystkich niewykorzystanych adresow. Ale powstaju tu pewna
niekonsekwencja w plikach konfiguracyjnych (jeden VirtualHost musi miec
podane any, reszta konkretne adresy ip/dns).

Oba rozwiazania maja swoje wady i zalety jezeli chodzi o konfiguracje. A ja
nie wiem ktore rozwiazanie jest (bedzie ;-))) bardziej przejrzyste dla
uzytkownikow.

To tak na poczatek. Nie wiem na ile bedzie zainteresowanie takim tematem -
jezeli jednak znalazly by sie bratnie dusze, znajace sie na rzeczy ktore w
krytycznych dla mnie sytuacjach (gdy bede mial kilka drog rozwiazania
jakiegos problemu) beda wstanie podpowiedziec ktore rozwiazanie jest wdl.
nich najlepsze to prosze o email'a z deklaracja pomocy w przyszlosci ;-)))

Steve
steve@home.pl