Добрый вечер!
> > Как я понимаю, перенаправляется на в примере, значит
будет
> > "Host: backend" или все таки тоже поле, что было передано клиентом
frontend
> > серверу? Как я понимаю, последнее должно быть. Иначе, если первое, то
если
> > несколько виртуальных хостов, то работать не будет.
>
> Конечно же будет Host: backend потому как в противном случае если
> backend - name-based, то как-раз работать и не будет.
Ну если apache backend-а настроить на те же ServerName для виртуалов, что и
на frontend, но висящих на IP 127.0.0.1 backend-а, то apache backend-а будет
отрабатывать те виртуальные хосты, какие будут в Host: заголовке от
фронтенда к бекенду, даже если IP их будет разрешаться не в тот IP, на
котором висит виртуал бекенда. То есть если бы mod_accel передавал в
запросах к бекенду Host с тем же именем сайта, с которым к фронтенду
обратился клиент + в конфигах бекенда был прописан name-based виртуал на
127.0.0.1 но с ServerName www.suchserver.ru, то тогда бы можно было на
фронтенде описать один AccelPass для всех виртуалов типа:
AccelPass /
А на фронтенде прописать виртуалы с именами, которые разрешаются в DNS на
публичнвый IP, который слушает фронтенд! То все бы работало.
Именно такая фича была сделана в squid (ее даже не было в ранних версиях
squid-а, но потом по просьбе трудящихся сделали), но не стал использовать,
так как он держал backend-ы на медленных клиентах. Думал, что mod_accel
работает таким же образом, но очень жаль что не так. При существующем
дванном механизме mod_accel мне для 10-ти виртуалов придется завести 10-ть
на frontend-е, прописать 10 имен в DNS на 127.0.0.1 и на бекенде снова
прописать десять виртуалов...
Вопрос к разработчику:
еслия в файле accel_backend.c последнего модуля mod_accel в строке 258
изменю:
было:
ap_bvputs(fb, "Host: ", b->host, b->port_str, CRLF, NULL);
стало:
ap_bvputs(fb, "Host: ", ap_table_get(r->headers_in, "Host") ?
ap_table_get(r->headers_in, "Host") : b->host, b->port_str, CRLF, NULL);
То вроде фронтенд станет передавать Host именно такой, какой был в клиенте.
Модно поступить так, если мне нужна именна такая возможность, о которой я
говорил выше.
> > 2. Есть ли положительный опыт работы скрипта на сервере, где frontend
> > крутится на public_IP, а backend крутится на той же машине на 127.0.0.1
и
> > backend имеет много виртуальных хостов?
> А куда денется - работает.
А сколько виртуалов у вас на одном IP запущено, если не секрет? И
используете ли вы дествительно такую схему, о которой я написал выше -
фиртуалы прописываются как в конфиге фронтенда, так и в бекенде, но уже с
другими именами, которые разрешаются в IP 127.0.0.1 например?
> > 3. Можно ли случая, описанного в п.2 описать только одну директиву
> > AccelPass /
> Нельзя. Но можно, наверное, написать RewriteRule которое будет
использовать
> $HTTP_HOST в правой части.
Ну если запрос в бекенду в правой части AccelPass будет идти через DNS имя,
а не через IP, то тогда мне придуется все равно использовать разные DNS
имена для одного сайта как для фронтенда, так и для бекенда. А если бы Host
передавался какой от клиента пришел, то все бы упростилось :(
> > 4. Есть ли простое решение от следующего? Сейчас у многих виртуал-хостов
у
> > нас есть в конфигах запреты на директории для всех IP кроме такого-то
> > (например, для админ-скриптов)... Как я понимаю, в связи с переходом на
> > mod_accel, такие запреты надо будет переносить на frontend. То есть
конфиг
> > надо разносить, так как часть настроек все таки будет на backend.
> Проще всего протащить IP в заголовке X-RealIP/X-Forwarded-For и делать
> авторизацию по нему.
Речь не об авторизации шла, а об закрытии папок для такого-то IP командами
allow from и deny from. А они отрабатываются только для REMOTE_ADDR...
> Алексей Тутубалин
Алексей Звягин
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
