Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-talk] Re: [apache-talk] Re: [apache-talk] mod_ accel - вопросы к разработчику и к тем, кто его использует



Добрый вечер!

> > Как я понимаю, перенаправляется на http://backend/ в примере, значит
будет
> > "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 / http://127.0.0.1/

А на фронтенде прописать виртуалы с именами, которые разрешаются в 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           /       http://backend/
> Нельзя. Но можно, наверное, написать 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@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =






Спонсоры сайта:

[ Russian Apache ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"Russian Apache" includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/) See Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C) 1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.