установка виртуальных Апачей

Arefiev

Новичок
установка виртуальных Апачей

Имеется собственный хостинг-сервер на Debian.

Необходимо поставить несколько (3-5) виртуальных Апачей что бы разграничить зоны доступа для разных типов проектов.

Имеются варианты.

- Повесить каждый апач на 127.0.0.1:xxxx запущеный с правами соотв. пользователя. И пробрасывать к нему коннекты извне через squid слушающие внешний IP на 80 порту.
Но тогда для апачей это будет выглядеть как коннекты с 127.0.0.1. Что неудобно для сбора статистики и прочее.

- Админ предлагает поставить 1 Апач и чрутить PHP как CGI(FastCGI). Но мне все таки хочется работать с привычным mod_php.

Какое решение более правильное?
Какие еще возможны варианты?
 

Arefiev

Новичок
Автор оригинала: Dimush
а что конкретно разграничивать требуется?
Условно говоря есть разные классы проектов:
- проекты самой компани
- проекты коммерческих клиентов
- всякая бесплатная благотворительность
- тесты и эксперименты

хочется что бы юзера одной группы не имели НИКАКОГО доступа к файлам другой. Плюс разные настройки Апача и PHP.

Стандартную проблему про разделение прав пользователей на shared хостингах изучал, там часто упоминается решение "свой Апач каждому клиенту" - вот и хочу понять как это делается и какие есть подводные камни в этом варианте учитываю что таких виртуальных апачей будет немного а 3-5 штук.

-~{}~ 26.09.05 14:09:

Автор оригинала: svetasmirnova
Удобнее для сбора статистики =)
Да, конечно, вы правы.
Вопрос, в php REMOTE_ADDR даст мне в результате именно 127.0.0.х или реальный ip посетителя?
 

svetasmirnova

маленький монстрик
Это в случае использования squid надо будет посмотреть. В SERVER_ADDR должен быть именно 127.0.0.х Кстати, о статистике, есть же ещё переменная SERVER_PORT.
 

alexhemp

Новичок
Arefiev

squid, oops обычно для таких целей, персональные апачи на разные порты.
 

Arefiev

Новичок
Автор оригинала: alexhemp
Arefiev

squid, oops обычно для таких целей, персональные апачи на разные порты.
Хорошо, то что мне надо, а как пользоваться потом эти. Как разруливать порты. Нель зя же давать клиентам адреса типа host.com:8080

Мне же надо что бы все Апачи слушали порт 80.
 

Dimush

Guest
alexhemp, а в чем проблема.

Самом пробовать не доводилось, но вообще видел подобную схему в действии, вроде проблем не было.

-~{}~ 26.09.05 15:58:

Arefiev

100 у.е. за сервак отдаешь, а еще за 3-и реальных ip-штки доплатить жалко? :)
 

alexhemp

Новичок
Arefiev

Не так все делается...

Вешается на фронт-енд на 80 порт OOPS или сквид, которые по заголовку HOST переадресуют запросы на бэкенды запущенные на разных портах. Например на

10001, 10002, 10003 и т.п.

Можно еще для этого попробовать использовать nginix (наверное попроще даже будет настроить).

Но там могут вылезти проблемы разные, с HTTP заголовками в основном (потому как прокси-сервер их может изменять).

Да, щас посмотрел, для nginx не просто а очень просто

http://sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html

Типа

http {
server {
listen 80;
server_name one.example.com www.one.example.com;
location / {
proxy_pass http://localhost:10001/;
proxy_set_header X-Real-IP $remote_addr;
}


}
server {
listen 80;
server_name two.example.com www.two.example.com;
location / {
proxy_pass http://localhost:10002/;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
 

Arefiev

Новичок
Автор оригинала: alexhemp
Arefiev

Не так все делается...

Но там могут вылезти проблемы разные, с HTTP заголовками в основном (потому как прокси-сервер их может изменять).
В том и проблема, мож но ли сделать прозрачно это дело.

И еще при добавлении нового виртуального хоста на один из серверов придется скуид перенастраивать ?
 

alexhemp

Новичок
Arefiev
Конечно, а разве апач не придется перенастраивать (создавать новый конфиг-файл, запускать процесс и т.п.)
Не нужно будет новую DNS-зону поднять и сам сайт написать
Бесплатно ничего не бывает, тут плата минимальна - пара типовых строчек в конфиг.

Насчет заголовков - это я вас перепугал, на деле все не так страшно. у OOPS была проблема с if-modified-since - ее успешно решили, насчет остальных не изучал. Рекомендую попробовать таки nginx - заодно сможете снизить нагрузку на раздачу графики для этих серверов. Squid/OOPS это тоже могут, просто закэшируют ее, но для кэша нужно будет место :).
 
Сверху