Onderwerp: Apache mod_rewrite, subdomains rewriten?

Sorry for bugging in, maar ik heb een vraagje waar ik ook na een paar
uurtjes googlen en spelen niet uit kom...

Ik heb op mijn firewall een apache staan die ik dusdanig wil
configureren dat hij in principe alle requests redirect, met
uitzondering van een paar gedefinieerden die hij *wel* lokaal moet
serveren. So far, so good:

Het probleem is hierin dat ik zelf mijn DNS kan aanpassen (lees: zoveel
subdomains kan maken als ik wil), en de meeste requests bestaan uit
<iets>.kayeshu.net, waarbij dat <iets> redelijk variabel is, maar *wel*
meegegeven moet worden in de redirect, omdat de apache doos achter de
firewall dat weer gebruikt voor zijn name-based virtual hosting.

De URL waar hij zelf op moet reageren ziet er ook zo uit, in
dit geval statistics.kayeshu.net (en in de toekomst
dirtdevil.kayeshu.net en motd.kayeshu.net)

Ik heb al zitten spelen met mod_rewrite en RedirectMatch,
maar kom er domweg niet uit, en helaas blijkt de doc van apache vrij
kaal te zijn over specifiek dit probleem :-( PHP wil ik niet, de machine
moet zo minimaal mogelijk blijven, gezien de nogal slanke hardware die
er onder draait en de primaire functie van het doosje. (firewall)

Overigens, het gaat in dit geval om Apache 1.3 op OpenBSD 3.2, draaiend
op een oud sparc IPXje, voor zover van belang.

Iemand die mij een zetje kan geven, of het wellicht zelf heeft opgelost
en mij het noodzakelijk stukje httpd.conf kan toespelen?

Harmen
--
Nee, ik ben niet aardig!

Unezra qr Wbatr:
>Ik heb op mijn firewall een apache staan die ik dusdanig wil
>configureren dat hij in principe alle requests redirect, met
>uitzondering van een paar gedefinieerden die hij *wel* lokaal moet
>serveren. So far, so good:
>
>Het probleem is hierin dat ik zelf mijn DNS kan aanpassen (lees: zoveel
>subdomains kan maken als ik wil), en de meeste requests bestaan uit
><iets>.kayeshu.net, waarbij dat <iets> redelijk variabel is, maar *wel*
>meegegeven moet worden in de redirect, omdat de apache doos achter de
>firewall dat weer gebruikt voor zijn name-based virtual hosting.
>
>De URL waar hij zelf op moet reageren ziet er ook zo uit, in
>dit geval statistics.kayeshu.net (en in de toekomst
>dirtdevil.kayeshu.net en motd.kayeshu.net)

Eerst even samenvatten en kijken of ik het goed begrijp.

Bijvoorbeeld http://iets.kayeshu.net/x moet redirecten naar
http://ietsanders.kayeshu.net/x

Maar bijvoorbeeld
http://statistics.kayeshu.net is een gewone (virtuele) website
van deze Apache zelf.

Correct?

Ik heb nog niet helemaal door wat de uitdaging is geloof ik.
Want voor iets.kayeshu.net definieer je dan toch gewoon een
virtuele website, die niets anders doet dan redirecten naar
ietsanders.kayeshu.net?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman flushed h[is,er] message queue in nl.internet.www.server-side:
> Unezra qr Wbatr:
>
> Eerst even samenvatten en kijken of ik het goed begrijp.
>
> Bijvoorbeeld http://iets.kayeshu.net/x moet redirecten naar
> http://ietsanders.kayeshu.net/x
>
> Maar bijvoorbeeld
> http://statistics.kayeshu.net is een gewone (virtuele) website
> van deze Apache zelf.
>
> Correct?

Bijna.
Ik heb 2 machientjes staan, waarvan 1 firewall (dirtdevil), en 1
zwaardere machine (electrolux) die ik het echte werk wil laten doen. Het
verkeer komt binnen op dirtdevil, waar een lokale apache draait.

Dirtdevil moet kijken of het voor hem is (bijv. statistics.kayeshu.net),
en het dan serveren vanaf zijn eigen lokale filesystem met een normale
vhosts. Als het *niet* voor hem is, (ofwel, alles dat *niet* hard
gedefinieerd staat, een soort default dus) moet hij het intern
doorspelen naar electrolux, maar *met* behoud van de originele url,
(bijvoorbeeld electrolux.kayeshu.net of bofh.kayeshu.net) zodat
electrolux het weer in zijn eigen vhosts kan opzoeken en uit kan spugen.

In geval van nood (electrolux plat) kan ik 'm dan eenvoudig omgooien
naar een lokale vhost, met de mededeling dat electrolux plat is.

Mede hierom wil ik een default (*.kayeshu.net) redirecten ipv alle losse
vhosts, omdat ik anders al die vhosts moet aanpassen.

> Ik heb nog niet helemaal door wat de uitdaging is geloof ik. Want
> voor iets.kayeshu.net definieer je dan toch gewoon een virtuele
> website, die niets anders doet dan redirecten naar
> ietsanders.kayeshu.net?

Dat zou kunnen, maar dan moet ik alle vhosts op electrolux *en* op
dirtdevil definieren. Dat vind ik niet handig. Tenzij ik natuurlijk
ergens een simpele platte file kan aanmaken met alle vhosts, en die kan
sharen tussen beide servers.

Ik hoop dat het probleem zo iets duidelijker is :-)

Kan dit met een simpele rewrite constructie, of moet ik in dit geval
gaan denken aan een reverse proxy constructie? Dat laatste liever niet,
gezien de extra load op dirtdevil, terwijl ik zijn clockcycles liever
besteed aan firewalling dan aan apache.

Harmen
--
Nee, ik ben niet aardig!

Unezra qr Wbatr:
>Dirtdevil moet kijken of het voor hem is (bijv. statistics.kayeshu.net),
>en het dan serveren vanaf zijn eigen lokale filesystem met een normale
>vhosts. Als het *niet* voor hem is, (ofwel, alles dat *niet* hard
>gedefinieerd staat, een soort default dus) moet hij het intern
>doorspelen naar electrolux, maar *met* behoud van de originele url,
>(bijvoorbeeld electrolux.kayeshu.net of bofh.kayeshu.net) zodat
>electrolux het weer in zijn eigen vhosts kan opzoeken en uit kan spugen.

Maar wat is "intern doorspelen met behoud van originele URL"
precies? Welk mechanisme zou dat kunnen doen?

Een redirect kan het niet zijn, want die zou naar een andere URL
moeten redirecten. Een rewrite ook niet, want die werkt (VZIW)
alleen binnen de Apache instance en heeft niet als effect dat
Apache onder water de data bij een andere Apache ophaalt.

Ik vermoed dat je dan inderdaad op een reverse proxy zou
uitkomen, met een configuratie om de data bij de ene of de
andere server op te halen, afhankelijk van de URL.

En waarom kan dit niet gewoon via DNS? D.w.z. de betreffende
hostnames het IP-adres van electrolux geven.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman flushed h[is,er] message queue in nl.internet.www.server-side:
> Unezra qr Wbatr:
>>Dirtdevil moet kijken of het voor hem is (bijv. statistics.kayeshu.net),
>>en het dan serveren vanaf zijn eigen lokale filesystem met een normale
>>vhosts. Als het *niet* voor hem is, (ofwel, alles dat *niet* hard
>>gedefinieerd staat, een soort default dus) moet hij het intern
>>doorspelen naar electrolux, maar *met* behoud van de originele url,
>>(bijvoorbeeld electrolux.kayeshu.net of bofh.kayeshu.net) zodat
>>electrolux het weer in zijn eigen vhosts kan opzoeken en uit kan spugen.
>
> Maar wat is "intern doorspelen met behoud van originele URL"
> precies? Welk mechanisme zou dat kunnen doen?

Ik dacht aan een portforwarding zoals de meeste firewalls doen,
maar dat mechaniek zit een laagje te laag :-(

> Een redirect kan het niet zijn, want die zou naar een andere URL
> moeten redirecten.

Dat zou op zich nog mogen. Iets als: (in pseudo)
Redirect permanent *.kayeshu.net:80 *.kayeshu.net:8080

Dan ist gewoon een kwestie van een portforward aan zetten op 8080, en is
mijn probleem opgelost. Jammer dat mensen die achter een heel
restrictive firewall zitten er dan niet bij kunnen, maar da's niet een
groot probleem in dit geval.

> Een rewrite ook niet, want die werkt (VZIW)
> alleen binnen de Apache instance en heeft niet als effect dat
> Apache onder water de data bij een andere Apache ophaalt.

Damn. Daar hoopte ik dus op, dat dat met een rewrite *wel* kon.

> Ik vermoed dat je dan inderdaad op een reverse proxy zou
> uitkomen, met een configuratie om de data bij de ene of de
> andere server op te halen, afhankelijk van de URL.

Met als nadeel dat die machine het meteen wat drukker gaat krijgen.

> En waarom kan dit niet gewoon via DNS? D.w.z. de betreffende
> hostnames het IP-adres van electrolux geven.

Omdat electrolux achter een NAT doos zit en geen extern IPv4 adres kan
krijgen. Helaas ist maar een adsl pijpje waar het spul achter zit, en is
IPv6 nog niet voldoende ingeburgerd om echt veel nut van te hebben.

Dat is het hele probleem, ik heb slechts 1 IP naar buiten, en dat is het
IP van dirtdevil. Die machine moet ook keurig een paar pagina's serveren
(zijn eigen stats, en server-dood meldingen) maar daarnaast keihard
alles doorzetten naar electrolux.

Hmmm, ipv het doorsturen van de hostname, zou het wellicht *wel* wat
makkelijker zijn als ik rewrites aan maak als (wederom in pseudo):

<iets>.kayeshu.net electrolux.kayeshu.net:8080/<iets>

Harmen
--
Nee, ik ben niet aardig!

Unezra qr Wbatr:
>Rene Pijlman:
>> Ik vermoed dat je dan inderdaad op een reverse proxy zou
>> uitkomen, met een configuratie om de data bij de ene of de
>> andere server op te halen, afhankelijk van de URL.
>
>Met als nadeel dat die machine het meteen wat drukker gaat krijgen.

Eh, waarom eigenlijk? Het is wel extra software, maar toch niet
of nauwelijks extra activiteit?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman flushed h[is,er] message queue in nl.internet.www.server-side:
> Unezra qr Wbatr:
>>Rene Pijlman:
>>> Ik vermoed dat je dan inderdaad op een reverse proxy zou
>>> uitkomen, met een configuratie om de data bij de ene of de
>>> andere server op te halen, afhankelijk van de URL.
>>
>>Met als nadeel dat die machine het meteen wat drukker gaat krijgen.
>
> Eh, waarom eigenlijk? Het is wel extra software, maar toch niet
> of nauwelijks extra activiteit?
>

Hmmmm, het is een idee.
Balen, ik had gehoopt dat het iets heel simpels zou zijn, dat ik even in
een kwartiertje in elkaar zou zetten, maar helaas :-(

Is er iets te zeggen over de load die het geeft?

Ter info, de hardware waarop ik het spul draai is nogal minimaal. Het is
een Sun Sparc IPX, een Sun4c doosje tikkend op 40MHz met 16Mb memory en
een 500Mb hdd.

Harmen
--
Nee, ik ben niet aardig!

Rene Pijlman flushed h[is,er] message queue in nl.internet.www.server-side:
> Unezra qr Wbatr:
>>Rene Pijlman:
>>> Ik vermoed dat je dan inderdaad op een reverse proxy zou
>>> uitkomen, met een configuratie om de data bij de ene of de
>>> andere server op te halen, afhankelijk van de URL.
>>
>>Met als nadeel dat die machine het meteen wat drukker gaat krijgen.
>
> Eh, waarom eigenlijk? Het is wel extra software, maar toch niet
> of nauwelijks extra activiteit?
>

Ik zit me te bedenken, kan het natuurlijk ook over een *hele* andere
boeg gooien, waarmee ik het zelfs vrij makkelijk kan automatiseren.

Ik kan mijn firewall alles voor poor 80 domweg intern laten forwarden
naar de webserver, en een script laten lopen dat iedere 5 minuten de
status van het ding checkt. Gaat het ding dan plat, of zet ik ergens
zelf een parameter dattie plat ligt, pas ik on-the-fly een firewall rule
aan die 80 naar de interne webserver doorstuurt. Zo kan die config echt
minimaal blijven, hoef ik zelfs geen full-blown apache te hebben maar
kan ik met een veel kleinere webserver toe (minder kans op gaten, minder
overhead, minder whatever).

Hmmmmm, toch eens kijken.

Harmen
--
Nee, ik ben niet aardig!