URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID8
Нить номер: 2320
[ Назад ]

Исходное сообщение
"Хостинг"

Отправлено sashas , 17-Май-04 07:57 
Народ, не подскажите технологии хостинга без использования кучи дополнительных IP-адресов. Ну нет у меня лишних айпишников, а хостинг нужен. Заранее благодарен.

Содержание

Сообщения в этом обсуждении
"Хостинг"
Отправлено Михаил , 17-Май-04 08:54 
>Народ, не подскажите технологии хостинга без использования кучи дополнительных IP-адресов. Ну нет
>у меня лишних айпишников, а хостинг нужен. Заранее благодарен.

а зачем куча-то?
в минимальном варианте одного адреса может хватить...

и что есть "хостинг" в твоем вопросе?
если нужно свой сайтик в инете держать, то это можно вообще на стороне хостить и тогда вообще свои ip-адреса не нужны.



"Хостинг"
Отправлено sashas , 17-Май-04 09:37 
>>Народ, не подскажите технологии хостинга без использования кучи дополнительных IP-адресов. Ну нет
>>у меня лишних айпишников, а хостинг нужен. Заранее благодарен.
>
>а зачем куча-то?
>в минимальном варианте одного адреса может хватить...
>
>и что есть "хостинг" в твоем вопросе?
>если нужно свой сайтик в инете держать, то это можно вообще на
>стороне хостить и тогда вообще свои ip-адреса не нужны.

Хостинг - это хостинг. Мне на моем серваке надо разместить сайты клиентов. С айпишниками проблема, поэтому jail такой, как я его понимаю, не рулит.


"Хостинг"
Отправлено uldus , 17-Май-04 09:48 
>С айпишниками проблема, поэтому jail такой, как я его понимаю, не
>рулит.

Если проблема обусловлена необходимостью запуска своего apache в отдельном jail для каждого клиента и name-based virtual хостинг никак не подходит, то можешь вешать jail на нереальных IP из интранет блоков. На реальный же IP повесить прокси который будет перебрасывать коннекты к нереальным в зависимости от имени хоста. Прокси можно построить на базе apache+mod_proxy или лучше apache+mod_accell.


"Хостинг"
Отправлено sashas , 17-Май-04 10:14 
>>С айпишниками проблема, поэтому jail такой, как я его понимаю, не
>>рулит.
>
>Если проблема обусловлена необходимостью запуска своего apache в отдельном jail для каждого
>клиента и name-based virtual хостинг никак не подходит, то можешь вешать
>jail на нереальных IP из интранет блоков. На реальный же IP
>повесить прокси который будет перебрасывать коннекты к нереальным в зависимости от
>имени хоста. Прокси можно построить на базе apache+mod_proxy или лучше apache+mod_accell.
>
Thanks. Буду разбираться. Хотя будут проблемы с удаленным заходом. Адреса-то интранетовские. :(


"Хостинг"
Отправлено keydet , 19-Май-04 17:49 
www.site-name.ru/~username не подходит?

>>>С айпишниками проблема, поэтому jail такой, как я его понимаю, не
>>>рулит.
>>
>>Если проблема обусловлена необходимостью запуска своего apache в отдельном jail для каждого
>>клиента и name-based virtual хостинг никак не подходит, то можешь вешать
>>jail на нереальных IP из интранет блоков. На реальный же IP
>>повесить прокси который будет перебрасывать коннекты к нереальным в зависимости от
>>имени хоста. Прокси можно построить на базе apache+mod_proxy или лучше apache+mod_accell.
>>
>Thanks. Буду разбираться. Хотя будут проблемы с удаленным заходом. Адреса-то интранетовские. :(
>



"Хостинг"
Отправлено Rohan , 19-Май-04 22:56 
При пробросе на серые адреса через прокси потеряется remote_ip. Можно пользоваться x-forwarded (если прокся правильная), но все равно каждому скрипту объяснять несколько напрягает.
Может быть есть возможность через что-то типа mod_setenv приравнять эти значения (не проверял)
Имею софт, который может пробрасывать http траффик на серые адреса по образу и подобию NAT, с сохранением remote_ip, отдам за скромную сумму в WMZ.
И еще - если апачи _реально_ запускаются каждый в своем ждайле, а не форкаются - памяти они гребут на полную катушку. Порядка 20 метров на штуку. Если сайтов сотня....
Классический вариант - mod_suexec + mod_php в safe_mode (тоже есть кучка недостатков)....



"Хостинг"
Отправлено uldus , 20-Май-04 13:55 
>При пробросе на серые адреса через прокси потеряется remote_ip. Можно пользоваться x-forwarded

Ничего не потеряется, mod_accel передает зпголовок X-Real-IP, далее на бэкенде восстанавливается изначальное содержание remote_addr, переменные окружения будут неизменными, переброс будет полностью прозрачным.

Модуль который лепит remote_addr из x-forwarded - http://www.lexa.ru/apache-talk/msg05816.html


>И еще - если апачи _реально_ запускаются каждый в своем ждайле, а
>не форкаются - памяти они гребут на полную катушку. Порядка 20
>метров на штуку. Если сайтов сотня....
>Классический вариант - mod_suexec + mod_php в safe_mode (тоже есть кучка недостатков)....

Вопрос с какими недостатками можно смириться.



"Хостинг"
Отправлено Rohan , 20-Май-04 18:19 
Недостатки php в safe_mode - файло создается с хозяином www(nobody).
Если файлы нужно и читать и писать и создавать - возникает чехарда с правами.

"Проблемы которые рождает mod_php"
Отправлено uldus , 21-Май-04 10:14 
>Недостатки php в safe_mode - файло создается с хозяином www(nobody).
>Если файлы нужно и читать и писать и создавать - возникает чехарда
>с правами.

Можно запускать php как cgi скрипт под FastCGI. Просто как CGI - слишком ресурсоемко, слишком тяжелый php на подъем.

На самом деле даже не в правах у mod_php проблема - он крайне нестабильно работает, лично постоянно сталкиваюсь с php скрипптами приводящими к тому что httpd впапдает в какой-то замкнутый цикл и начинает жрать 100% CPU времени, убивается только по kill -9, лимиты на CPU-time не спасают (более того подозреваю, что из-за них и memory_limit и возникает проблема).

Вторая менее очевидная пробелма - при apachectl graceful или stop иногда child httpd процессы не завершаются корректно (как предыдущий пункт, только нет 100% загрузки CPU). Поэтому приходится перезапускать по start/stop и между ними  проверять - не остались ли висячие httpd мертвяки, иначе apache не запустится.

Третья проблема нерешаема в принципе (только лимиты на память и уменьшение MaxRequestsPerChild), когда  php скрипт использует память, после того как он отработает эта память физически не освобождается и используется для дальнейших запросов памяти php-скриптами исполняемыми в этом child процессе. Т.е. скрипт использовал 8 МБ памяти, httpd процесс будет нести на своем борту эти 8 МБ до самой смерти.

От версии к версии появляются и исчезщают другие менее критичные проблемы. Когда приходится обновлять php - всегда ждешь где на этот раз спрятаны грабли.