forum.lissyara.su

Добрый день/вечер/утро!

Можно ли ограничить использовавние ресурсов таких демонов как mysql, apache, squid, ftp с помощью добавления соответствующей информации в /etc/login.conf ?
Мне непонятно вызывают ли эти пользователи (www, mysql, squid, ftp) login()?
Попробовал ограничить юзера ftp по размеру файла в 1Гб, после перезaгрузки система все равно дала загрузить файл размером 1,5 Гб....

какая версия?

у меня тоже самое! перед обновлением мира работало на 7.0 current! (может что-то нахимичили на 7.0 stable)
сейчас FreeBSD 7.0-STABLE #0

мне подсказали что может из-за того что мир плохо обновился...

в общем можешь jail попробовать...

ProFTP писал(а):какая версия?

у меня тоже самое! перед обновлением мира работало на 7.0 current! (может что-то нахимичили на 7.0 stable)
сейчас FreeBSD 7.0-STABLE #0

мне подсказали что может из-за того что мир плохо обновился...

в общем можешь jail попробовать...

Версия 7.0 Stable. Я тут копался в форуме и нашел что нужно сделать cap_mkdb(1), пока не пробовал. Как сделаю отпишусь....

Grishun_U_S писал(а): Можно ли ограничить использовавние ресурсов таких демонов как mysql, apache, squid, ftp с помощью добавления соответствующей информации в /etc/login.conf ?
Мне непонятно вызывают ли эти пользователи (www, mysql, squid, ftp) login()?

это не решит проблем а только создаст.
Нужно ограничивать не системных демонов, а пользователей, запрашивающих различные сервисы. Ограничивать средствами самих сервисов (напр. мускиль), а также через вышеупомянутый login.conf

http://peterhost.ru/highload_report.shtml

ограничение ресурсов вообще как по мне на архаизм смахует... кастыли, построенные на пережитках громкой рекламы анлимитного трафика на хостингах.
у буржуев проще - нарезали тебе трафика там 1Тб и юзай ресурсов сколько влезет(условно).

Нужно ограничивать не системных демонов, а пользователей, запрашивающих различные сервисы.

а как же надежность системы? один демон занял все ресурсы и втал весь сервер? это не допустимо, поэтому стараются ограничивать еще и демонов - дабы иметь еще один рубеж защиты от возможного падения сервера

ограничение ресурсов вообще как по мне на архаизм смахует

вовсе нет
вот к примеру мне выделили 1 мб трафика, а процессор я жру на 100% и не даю серверу нормально работать и все это за 1$ в год (за 1 мб трафика нормальный тариф думаю)... нормальная ситуация?

и это я не утрирую... неоднократно наблюдал кривые админки, которые генерят более 100 ресурсоемких sql запросов для отображения одной странички

ev писал(а):а процессор я жру на 100%

дак paix и говорит, что лучше юзверов ограничивать, дал юзеру 3% проца и 32 метра оперативки, пущай как хочет так и крутится

дак paix и говорит, что лучше юзверов ограничивать, дал юзеру 3% проца и 32 метра оперативки, пущай как хочет так и крутится

юзеру в пределах демона - а это несколько иное

например, у меня 100 клиентов на одном сервере
я знаю что активны у меня не более 10 одновременно, выделяю каждому по 10%
и вот вдруг активность увеличилась и у меня стали активны 20 одновременно
ограничения на сервис нет - и один сервис (например апач) тормозит всю систему, а это не приемлимо... хотя бы потому, что я не смогу нормально работать по ssh и быстро решить проблему
поэтому и надо ограничивать еще сами демоны, дабы если и произошла перегрузка - можно было локализовать проблему и не дать завалить сервер полностью

к слову, юзеров тоже надо ограничивать
в идеале должно быть несколько контуров защит на различные случаи

ev писал(а):в идеале должно быть несколько контуров защит на различные случаи

+1, и ещё лопата

и каска еще

друзья, защита от перегрузок - совсем отдельная тема.
и гораздо правильней, устранять причину, а не следствие.

Пример:
Причина - на серв при досе от ботов валит куча запросов (на домен.)
Следствие - апач стал потреблять много ресурсов
Ваше решение - ограничить апач по ресурсам Чтобы он не оверлоадил систему. Что имеем в итоге? Апач, как честный префорк, тупо забьется форками для вашего домена. Все остальное будет лежать. Приемлемо? - Нет.

Вызвать оверлоад, чтобы вы не смогли зайти на шел, это паталогии активного свопинга. И тут также нужно причины а не следствия устранять. 100 юзеров, по 10% у вас сколько форков смогут наплодить апачевских а? и при этом все эти форки будут обрабатываться много дольше (дык вы сами их по ресурсам ограничили!) в результате серв полез в свопинг! Таких ситуаций надо избегать. max_clients не зря ведь придумали

Вы думаете, ограничив демона по ресурсам, все - обезопасили серв на все случаи жизни? как бы не так! всегда найдется еще один вариант, еще один кастыль.
Обязательное условие - мониторинг, нагиос например. И слежение со стороны админов.

Вообщем, не стройте себе иллюзий. Защита от перегрузок - это хорошо, и способ ограничения демонов имеет право на жизнь, но не в качестве панацеи, а в виде частного случая для решения конкретной задачи.

+
http://www.opennet.ru/guide.shtml

всегда найдется еще один вариант, еще один кастыль

вот поэтому и надо пытаться предусмотрать как можно больше вариантов

paix писал(а):и каска еще

друзья, защита от перегрузок - совсем отдельная тема.
и гораздо правильней, устранять причину, а не следствие.

Пример:
Причина - на серв при досе от ботов валит куча запросов (на домен.)
Следствие - апач стал потреблять много ресурсов
Ваше решение - ограничить апач по ресурсам Чтобы он не оверлоадил систему. Что имеем в итоге? Апач, как честный префорк, тупо забьется форками для вашего домена. Все остальное будет лежать. Приемлемо? - Нет.

Вызвать оверлоад, чтобы вы не смогли зайти на шел, это паталогии активного свопинга. И тут также нужно причины а не следствия устранять. 100 юзеров, по 10% у вас сколько форков смогут наплодить апачевских а? и при этом все эти форки будут обрабатываться много дольше (дык вы сами их по ресурсам ограничили!) в результате серв полез в свопинг! Таких ситуаций надо избегать. max_clients не зря ведь придумали

Вы думаете, ограничив демона по ресурсам, все - обезопасили серв на все случаи жизни? как бы не так! всегда найдется еще один вариант, еще один кастыль.
Обязательное условие - мониторинг, нагиос например. И слежение со стороны админов.

Вообщем, не стройте себе иллюзий. Защита от перегрузок - это хорошо, и способ ограничения демонов имеет право на жизнь, но не в качестве панацеи, а в виде частного случая для решения конкретной задачи.

+
http://www.opennet.ru/guide.shtml

Т.е. ты предлагаешь ограничивать демонов средствами самих демонов, я правильно понял?

демоны не причем, или я не понял?

в mysql есть свои ограничение на счет большого числа подключений к серверу и про использовании памяти и т.д....
такое есть и в ftp называеться квота

имелось ввиду чтобы пользователи или программы которые работаюбт с этити пользователями не перегружали сам сервер все равно по любым причинам, елси ftp будет без квоты, например, и т.д.

это решаеться с login.conf?

ну и флейм развели... )

Можно ли ограничить использовавние ресурсов таких демонов как mysql, apache, squid, ftp с помощью добавления соответствующей информации в /etc/login.conf ?

можно.

ты предлагаешь ограничивать демонов средствами самих демонов, я правильно понял?

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

paix писал(а):ну и флейм развели... )

Можно ли ограничить использовавние ресурсов таких демонов как mysql, apache, squid, ftp с помощью добавления соответствующей информации в /etc/login.conf ?

можно.

ты предлагаешь ограничивать демонов средствами самих демонов, я правильно понял?

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

НЕТ, не юзеров, а демонов! Именно демонов!!

НЕТ, не юзеров, а демонов! Именно демонов!!

надо ограничивать и юзеров и демонов но для разных целей
делать ограничение юзеров через ограничение демонов - не лучший выход

ev писал(а):

НЕТ, не юзеров, а демонов! Именно демонов!!

надо ограничивать и юзеров и демонов но для разных целей
делать ограничение юзеров через ограничение демонов - не лучший выход

О! Еще один..... Этого делать никто и не собирается. Есть задача ограничить сервис который подвергается ДОСу вот и все..

Есть задача ограничить сервис который подвергается ДОСу вот и все..

как я и писал выше - от этого может помочь именно ограничение самого сервиса (демона)
зависит от того, что именно досят

ev писал(а):

Есть задача ограничить сервис который подвергается ДОСу вот и все..

как я и писал выше - от этого может помочь именно ограничение самого сервиса (демона)
зависит от того, что именно досят

Прям все-все-все сервисы имеют такое ограничение?