Shema: А Вы хотите автономный завод по производству бабла?
Патчить всё равно много чего приходится.
Например, Postfix без патчей квоты не поддерживал (может, и сейчас не поддерживает), что ж теперь не пользовать им?
Тем более патч занимает как правило 3-4 лишних команды с консоли...
Вот это уже правильный подход =)
Патчить апач на предмет смены uid/gid после того как рожалка рождает чайлда.
Тогда и mod_php будет жить от клиентского юзера..
А если подпатчить ядро, то можно много других вкусностей получить на которые намекал kostich.
Мне ближе другая схема, chroot юзеров в их дереве. При этом и апач отлично работает,
и юзер ну никак не вылезет за пределы своего хом рута =)
Решение для FreeBSD:
Делаем отлельное дерево:
#!/bin/sh
D=/usr/JAIL/SHARE
cd /usr/src
mkdir -p $D
make installworld DESTDIR=$D
cd etc
make distribution DESTDIR=$D
далее его монтируем через mount_nullfs или nfs, кому как удобно
в какой-то каталог, например /usr/JAIL/null/user с правами рид онли.
Монтируем поверх него /usr/JAIL/home/user в /usr/JAIL/SHARE/usr/local/www
Патчим апач, который при старте чайлда меняет ему uid/gid, черутим в
Shema: да
всё равно новые копии апача запускаются довольно часто
скажем, на каждые 10 соединений новый демон
Ужос!:) Это кто вам так настроил? MaxRequestsPerChild обычно стоит 10000,
это 1 чайлд на 10 тысяч запросов. Если у вас рождается на 10 коннектов 1 демон,
то в 1 коннект выливается 1000 запромов?! Ну поставьте MaxRequestsPerChild 0,
оно вообще не будет перезапускать чайлды.
Shema:
конечно, на сайтах с нулевой посещаемостью немного потеряем - демоны будут простаивать
Пусть на шаред 100 хостов. 10 посещаемые, 90 посещаемые радко.
1 тяжелый апач занимает мегабайт 10, тоесть если пускаем только рожалки,
то 90x10=900 мегабайт у вас уйдёт только на эти пустышки которые будут простаивать.
Красота.. А ведь после 1-го коннекта родится ещё и чайлд, и он будет висеть пока их число не превысит лимит. Даже по 1 штуке на 90 апачей у вас 1800 мегабайт только на пустые апачи которые простаивают.
Shema:
Можно. Например, на Хайвее (по крайней мере так было 2 года назад) апач пускается из-под вашего логина, соответственно он может менять права на все файлы. Допустим в сайте есть "маленькая" дыра, позволяющая загрузить исполняемый код на сервер. Если права стоят правильно (исходники не доступны для записи от имени web-сервера), то, возможно, сайт останется невредимым. Но если все файлы принадлежат пользователю, от имени которого работает web-сервер, то права на файлы силы иметь не будут.
Оно не даст записать файл, а прочитать? =)
Если апач имеет права на то чтобы прочесть файл, то может легко уйти достаточно важная инфа.
Roxis: вместо монтирования можно просто делать hard линки
Эмм, весь /usr /include /bin и т.д. пофайлово в хардлинки для каждого аккаунта,
когда их допустим сотня на сервер.. Плюс обновление, замена библиотек.
Да там с простым обновлением libmysqlclient'а подохнешь перехардлинковывать не говоря уже о обновлении системы и нагрузке на файловую систему. Жесткий подход выйдет.
Может я не прав, но все кто предлагают смотрите топик.
Домены не 2-3 символьные, а буквенные.
P.S. По поводу бюджета действительно интересно, какой?
Вот интересный момент. Искал себе монитор, однако после того как посидел за ноутом,
17' с разрешением 1920x1200, передумал брать монитор. Потому как обычного монитора,
с таким разрешением при таких размерах не нашел.
Если вопрос в здоровье глаз, то я бы взял ноут с хорошей матрицой, и небольшим шагом. Вот так.
Каждому пользователю - по VDS и забыть о проблеме.
Угум, если есть деньги и нет желания заморачиваться настройкой смотрите продукты от swsoft :)
А если хочется бесплатно, то позаморачиваться придётся.
Кстати VDS работает по подобному принципу.
По-моему, у них таки ничего нет кроме идеи (возможно уже угасшей...)
Ну по сути imho они используют тот патч на который я ссылался.
Просто они ставят патченый уже апач или там модуль к линуксовому ядру.
apache + mod_fastcgi + php-fastcgi/perl-fastcgi
Тоесть это всё-тот-же apache.
И запускать его не standalone' а скажем через inetd?
Тоесть на каждый запрос пускаем по апачу чтоль или как-то иначе?
ответ утвердительный 😂 😂 😂 скажите, какая система поддерживает это сразу же после установки дистрибутива 😂
Вот тут граждане пишут, что это есть у них:
http://www.exteam.ru/index.php?cat=2&id=1
:)
вместо запуска apache для каждого юзера, можно запускать fastcgi сервера и только когда они нужны
Уточните пожалуйста url на софт о котором говорите. О каком fastcgi сервере идёт речь? Тоесть кто будет обрабатывать php код?
А Вы хотите автономный завод по производству бабла?
Патчить всё равно много чего приходится.
Например, Postfix без патчей квоты не поддерживал (может, и сейчас не поддерживает), что ж теперь не пользовать им?
Тем более патч занимает как правило 3-4 лишних команды с консоли...
Вот это уже правильный подход =)
Патчить апач на предмет смены uid/gid после того как рожалка рождает чайлда.
Тогда и mod_php будет жить от клиентского юзера..
А если подпатчить ядро, то можно много других вкусностей получить на которые намекал kostich.
Мне ближе другая схема, chroot юзеров в их дереве. При этом и апач отлично работает,
и юзер ну никак не вылезет за пределы своего хом рута =)
Решение для FreeBSD:
Делаем отлельное дерево:
#!/bin/sh
D=/usr/JAIL/SHARE
cd /usr/src
mkdir -p $D
make installworld DESTDIR=$D
cd etc
make distribution DESTDIR=$D
далее его монтируем через mount_nullfs или nfs, кому как удобно
в какой-то каталог, например /usr/JAIL/null/user с правами рид онли.
Монтируем поверх него /usr/JAIL/home/user в /usr/JAIL/SHARE/usr/local/www
Патчим апач, который при старте чайлда меняет ему uid/gid, черутим в
/usr/JAIL/null/user.
Патчик можно найти в сети (на вскидку http://fido.online.kz/files/apache_1.3.33.uid-chroot.patch) или поставить например модуль:
http://www.palsenberg.com/index.php/plain/projects/apache_1_xx_mod_suid
Всё, апач отлично работает, все файлы у него есть.
При этом получаем полное дерево файлов на r/o и каталог юзера с правами на запись,
по которому он спокойно может гулять =)
Однако выше chroot'а он не поднимется. И не прочитает/изменит каталоги/файлы соседей.
Никаких оверхедов по диску, никаких проблем с 1 юзер = 1 апач.
Аналогично туда-же черутится ssh, ftp, etc =)
да
всё равно новые копии апача запускаются довольно часто
скажем, на каждые 10 соединений новый демон
Ужос!:) Это кто вам так настроил? MaxRequestsPerChild обычно стоит 10000,
это 1 чайлд на 10 тысяч запросов. Если у вас рождается на 10 коннектов 1 демон,
то в 1 коннект выливается 1000 запромов?! Ну поставьте MaxRequestsPerChild 0,
оно вообще не будет перезапускать чайлды.
конечно, на сайтах с нулевой посещаемостью немного потеряем - демоны будут простаивать
Пусть на шаред 100 хостов. 10 посещаемые, 90 посещаемые радко.
1 тяжелый апач занимает мегабайт 10, тоесть если пускаем только рожалки,
то 90x10=900 мегабайт у вас уйдёт только на эти пустышки которые будут простаивать.
Красота.. А ведь после 1-го коннекта родится ещё и чайлд, и он будет висеть пока их число не превысит лимит. Даже по 1 штуке на 90 апачей у вас 1800 мегабайт только на пустые апачи которые простаивают.
Можно. Например, на Хайвее (по крайней мере так было 2 года назад) апач пускается из-под вашего логина, соответственно он может менять права на все файлы. Допустим в сайте есть "маленькая" дыра, позволяющая загрузить исполняемый код на сервер. Если права стоят правильно (исходники не доступны для записи от имени web-сервера), то, возможно, сайт останется невредимым. Но если все файлы принадлежат пользователю, от имени которого работает web-сервер, то права на файлы силы иметь не будут.
Оно не даст записать файл, а прочитать? =)
Если апач имеет права на то чтобы прочесть файл, то может легко уйти достаточно важная инфа.
вместо монтирования можно просто делать hard линки
Эмм, весь /usr /include /bin и т.д. пофайлово в хардлинки для каждого аккаунта,
когда их допустим сотня на сервер.. Плюс обновление, замена библиотек.
Да там с простым обновлением libmysqlclient'а подохнешь перехардлинковывать не говоря уже о обновлении системы и нагрузке на файловую систему. Жесткий подход выйдет.