MultiHOST жжот

Конечно, это для безопасности сайта, а не сервера в целом, но скрипты писать тоже нужно правильно, Вам не кажется так?

Давайте расставим все точки над И. Безопасность данного рода связана в 99% случаев от ленивых ВМ которые ставят бесплатные движки с открытым исходным кодом, которых как раз и ломают.

Почему крупные хостинги: eServer, .m и прочие не занимается такой ересью ? :)

В конце концов почему я не могу изменить настройку этой директивы глобально для своего сайта. ИМХО это параноидальный маразм.

Согласен, раньше мы боролись с этим, но зря, пришли к выводу, что это в 99% "наша" проблема, а не хозяина сайта, решили оставить эту проблему на плечах ВМ.

Аффтар жжошь! Обслуживаю нескольких клиентов на multihost, никаких проблем после отключения не заметил, а off для большинства клиентов имо всегда лучше чем on.

Не юзайте кривые скрипты и будет Вам счастье.

Надо это уточнить у сапорта, т.к. не проверял, но в suphp есть такая вот возможность указания одного php.ini для всех вложенных папок, для этого в .htaccess надо указать путь к своему php.ini, через директиву:

suPHP_ConfigPath /home/имя_юзера/

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

Логично и по умолчанию, лучше таких обезопасить.

Если это ересь тогда наверно разработчики PHP конкретные идиоты что в 6-й ветке собираются прикрыть эту опцию под корень :D

sysctl

Девушка подходит к программисту, и пытаясь заиграть спрашивает:

- Молодой человек, не подскажите сколько сейчас времени?

Программист нервно хватает её за руку и подносит к её лицу:

- На смотри

Это про Вас ;)

------------------------------

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

То что предлагает по умолчанию мультихост - извращение над юзерами.

:D :D :D зачет 😆

Согласен, взгляд у меня с другой стороны...

Хостер не может знать, что конкретно у Вас должно работать для всего сайта, а что нет. К тому же Вам нужен единый php.ini, а кому-то в каждом каталоге свой, и он так же может сказать если есть возможность значит она должна работать...

Насколько мне известно это не их "каприз", а стандартная работа suPHP он позволяет иметь в каждом каталоге разный php.ini (в некоторых случаях это очень удобно), и выше приведенную опцию для глобальной настройки наследования, поэтому тут дело не в хостере, а в технологии у cpanel.

под fcgi флаги php в htaccess не работают

придется переезжать если критично использовать тот же скрипт . как вариант уточнить у хостера, возможно у них есть площадка с mod_php , там решается через htaccess

скорее всего, ничего не поделать.

Там где ему надо пусть создает .htaccess :) Это стандартное действие.

Практически уверен что в конфигурационном файле можно провернуть такую штуку:

<IfModule mod_suphp.c>

suPHP_Engine ON

suPHP_UserGroup kvadroom kvadroom

php_flag displat_globals on;

</IfModule>

php_flag не работает, говорили же уже.