Critical Mass külön webszerverrel.

Elkészült a Critical Mass site első védvonala, kicsit máshogy, mint terveztem.

Eredetileg (a tegnapi tesztelés ennek volt a próbája) egyszerűen másik porton futó lighttpd-re akartam egy Apache VHost-on belüli Redirect direktívával dobálni a kéréseket. Ha tegnap nézegetted a criticalmass.hu-t, láthattad, hogy időnként átdob a http://criticalmass.hu:8080-ra – na hát az az volt. A lighttpd gyors, mint az állat (mondjuk egy gepárd), 8 instance-ban fut a fastcgi alatta (local socketen csatlakozik), és szép is volt az egész, kivéve azt a tényt, hogy a site-ot működtető Drupal engine minden egyes linket teljes URL-ként, és nem abszolút vagy akár relatív linkként generál le, tehát egy cikk, amit te a http://criticalmass.hu/node/443 címen látsz, az engine-ben nem /node/443 -ként, hanem teljes URL-lel: http://criticalmass.hu/node/443 -ként jelenik meg. Ez akkor szopás, amikor az URL-ben a portot reprezentálni kéne, tehát a cikknek így kéne kinéznie: http://criticalmass.hu:8080/node/443. Nos, nem így nézett ki, vagyis bár a főoldalt a 8080-as porton figyelő lighttpd szolgálja ki, minden mást a 80-as portról, vagyis az Apache-tól szed be a böngésződ. Képeket, linkeket, CSS-t, mindent.

A megoldás végén tehát az oldalt a 80-as portról kell kiszolgálni, így vagy úgy. Az egyik megoldás az Apache-on belüle proxyzás a 8080-as portra, de ezt elvetettem, mert nincs értelme: ugyan az oldalt a lighttpd szolgálná ki, de ugyanúgy használnám az Apache-ot, akkor meg minek?
Így aztán a site (és a lighttpd) külön IP-re mozgatása mellett döntöttem: a szerver kapott egy virtuális interface-t új IP-címmel, ezen a lighttpd a 80-as porton figyel, és a jelek szerint hiba nélkül szolgálja ki az oldalt.

Persze a dolognak Apache- és lighttpd-oldalról is voltak bonyodalmai:

• A lighttpd teljesen más szintaktikát használ a rewrite szabályokra, mint az Apache. A rewrite szabályoknak pedig (ninja a megmondhatója) a Drupal esetében (és mindenféle dinamikus contentkezelő engine esetében) jelentősége van: így érjük el azt, hogy az egyes postoknak ne olyan címe legyen, hogy http://criticalmass.hu/?p=345&t=4 (csak példa, nem tudom, pontosan hogy néz ki), hanem (az eddigi példával élve) ilyen szép: http://criticalmass.hu/node/443. For the reference, Drupalhoz a következő (innen szedett) rewrite rule-ok működnek gyönyörűen (persze tesztüzem, és remélem szólsz, ha anomáliát látsz a működésben):
  url.rewrite-final = (
  „^/system/test/(.*)$” => „/index.php?q=system/test/$1”,
  „^/([^.?]*)?(.*)$” => „/index.php?q=$1&$2”,
  „^/([^.?]*)$” => „/index.php?q=$1”,
  „^/search/node/(.*)$” => „/index.php?q=search/node/$1”
  )
• Az Apache konfig egy számomra logikátlan featúrájával kellett szembesülnöm: úgy gondolnám, hogy ha beállítok egy BindAddress direktívát, akkor azzal minden további konfig értékkészletét meghatározom, tehát onnantól nem tudok olyat mondani, hogy *:80, ami minden IP-n figyel. Most ez történt: egy „Listen 80” sor kellemetlen perceket okozott. Úgyhogy for the reference, a BindAddress beállítása nem elég.
  (Érdekes ezt egyébként működés közben látni: ahogy hozzáadod az eth0:1 virtuális interface-t a rendszerhez, az Apache egyből elkezd figyelni rajta, nem csak reload, meg ilyesmi után.)

Summa summárom, a criticalmass.hu DNS zónája át van írva, úgyhogy amint frissülnek a nameserverek, szép lassan átveszi a lighttpd a terhelést, közben tweakelhetem még, a terheléstől függően. (Azt hiszem a TTL 86400, tehát maximum egy nap kell az átálláshoz.) A jelenlegi felállás április végéig biztosan így lesz, talán utána is – meglátjuk.

Amire a hétvégi tesztüzem során kíváncsi vagyok:

• Keepalive adatok: hogy viselkedik a lighttpd keepalive szempontból.
• Cookie-k, és lesz-e ezekből zavar-kavar.