ну так RewriteEngine вам тут все-равно не поможет.
если вам нужно отобразить в нужный location директорию
вне documentroot - так именно для этого mod_alias и
сделан. больше ничем - увы.
все должны делать rm -rf /*
иначе диск у сервера переполнится
и да, лучше делать утром - когда впереди еще весь трудовой день...
нда, и где вы видели виртуальный хостинг, где клиентам выделяют
гарантированные ресурсы? кому такое надо - берет себе VPS нормальный.
большинство клиентов виртуального хостинга создают пустяковую нагрузку + достаточно
хорошо размазанную по времени. исходя из этого и определяют "заселенность" хостинговых
серверов. а дальше начинается игра "ловля грузчиков" с применением системного аккаунтинга,
сбора статистики запросов для сервисов (типа mod_status) etc. с последующим отключением,
переездом клиента на другой хостинговый сервер etc...
+1
нафиг в такой задаче отдельный демон не нужен (crontab - за глаза). ибо критерии
типа la1 (la5 и la15 и подавно) - смысл имеют на интервалах порядка минуты и более.
а что вы уже пытались делать?
что мешает, например, положить в DocumentRoot ту самую
требуемую директорию media/ ?
сбросить пароль поможет запуск mysqld с ключиком --skip-grant-tables
дальше
mysql -u root
и выполняем запросы:
UPDATE mysql.user SET Password=PASSWORD(’newpwd’) WHERE User=’root’;
FLUSH PRIVILEGES;
и что? небыло никакого стандартного мониторинга? никаких стандартов по
документированию, поддерживаемому ПО? у коли стоит freebsd 4.11 а у васи Debian/4.0
и все мониторятся по-разному? и на каждом свой набор самописных утилит "активного реагирования" ((с) gor-)? надеюсь, что нет.
еще раз. если вы уходя _удаляете все_ свои утилиты, о чем клиент
предупреждается заранее - возражений нет.
штука в том, что даже на отдельном сервере снести подобные
"скрипты" часто представляется невозможным, без нарушения нормальной работы.
вот удалили вы свой аналог limiter'а - и злые пользователи у клиента-хостера начнут
жестоко драться за ресурсы, в результате чего - для большинства из них это выразится
во мнении хостинг XYZ - "тормозит".
Andreyka, одним rlimit-ом на оверселленой хостинговой машине не напасешся. дело в том,
что проблемы (у пользователей) начинаются _задолго_ до того, как все станет раком.
т.е. обычно что-то типа (как заметил Борис) acct + скрипты, которые
откручивают "плохим" пользователям определенные услуги и/или меняют тарифный план.
либо (как делают практически на любом нормальном хостинге) - саппорт, который
ловит нагрузку и делает аналогичное вручную.
а для выделенного сервера limiter нафиг не сдался, это уже выяснили. другое дело, что
и задачи виртуального хостинга он не решает (только в "планах" определение характера утилизации CPU и т.п.).
думаю, нишу этого limit'ера занимает как-раз monit - может автору имеет смысл просто
предлагать платные услуги настройки monit + доработать его, если возникнут хорошие идеи?
видимо, вы никогда не работали в большой команде сисадминов. там это самое "сомнительное" ПО
является критической частью инфраструктуры. попробуйте снести настроенный nagios и
установить zabbix - это задачка на много человекочасов и оччень болезненная для поддержания
работы того самого "общего ПО".
ваше замечание имеет смысл только если "уходя" - вы нафиг убираете за собою все подобное служебное ПО, и клиент о подобной политике в курсе.
http://httpd.apache.org/docs/2.2/rewrite/rewrite_guide.html
Dimanych, с dns только round-robin можно сделать.
adm.unix - чтобы запросы раскидывались приблизительно
равномерно (иначе один из серверов будет простаивать) - нужно два IP с
настроенным на них round-robin + ucarp для каждого из двух IP.
с помощью dns - никак.
вы сумеете сделать разве round-robin dns (гуглите): части клиентов отдается одна запись, скажем "@ IN A IP1" - части другая "@ IN A IP2"
