Перейти к содержимому


Фотография

Чем опасен shared хостинг

Форумы IBResource

  • Закрытая тема Тема закрыта
Сообщений в теме: 73
Fox Mulder
  • Участники
  • Cообщений: 95
  • http://

Отправлено

Хорошо, спасибо. Так что же мне делать пока я не могу переехать под отдельный апач. Как защититься?

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

;) :) :) Никак. Из того, что ваши домены посажены в "песочницу" (sandbox) и вы никого не видите, не следует, что вашими файлами не любуются кракеры из соседних сайтов. Если Алиса ест яблоко, это не значит, что яблоко ест Алису. :D

Повторюсь: типичная провайдерская машина - 100-200 пользователей на 2-4 IP. Чтобы отключить safe mode, но при этом оставить пользователя в "песочнице", нужно:
1. Выделить ему адрес IP (деньги!)
2. Запустить на этом адресе отдельную Апачу (расход оперативной памяти!)
3. Завести для этой Апачи дополнительного пользователя типа petrov_apache, создать индивидуальные конфиги и т.п. (расходы на администрирование!).

А пользователь платить не хочет, он хочет за свои 5 баксов в месяц иметь выключенный safe mode, из-за которого не ставится его интернет-магазин, любимый форум, веб-альбом и т.п. При этом он не имеет понятия ни о Юниксе, ни о PHP, и засыпает службу поддержки письмами. И уходить к другому хостеру он не хочет (потому как лень) и пишет истеричные письма на провайдерские форумы и т.п. - дескать, меня не предупредили, что у вас safe mode, вот у других, хороших, провайдеров, никакого safe mode нет в помине. А хостер не имеет юридического права в одностороннем порядке расторгнуть договор с таким народным мстителем... Знаете, чем это обычно заканчивается? Тем, что товарищу прописывают в конфиг сайта safe mode off. :) И сколько таких товарищей с отключенным safe mode - через год не помнит толком никто.

И самое забавное - хостер НИЧЕМ не рискует. Потому что взлом вашего форума через локальную файловую систему доказать НЕВОЗМОЖНО, в логах Апачи ничего подозрительного не остается. Если бы кракеры не стали хвастаться перед вами стянутой базой, вы бы ничего и не узнали. Поэтому у абсолютного большинства российских провайдеров safe mode выключен ВООБЩЕ, т.к. для хостера геморроя от включенного safe mode будет намного больше, чем от отключенного. Для 99% рядовых пользователей safe mode - не благо, а зловредное изобретение хостеров, чтобы наделать проблем при установке скриптов и развести пользователей на деньги для его отключения.

Извините за пространный текст, но говорю только о реальном личном опыте.

Из конкретных советов:

1. Бегите с хостинга, где вас уже подломали. Вы что думаете, админ у хостера будет заниматься вопросом, кто вас подломал? Да на фиг это ему нужно. Ведь на хостинге это ведь никак не отражается. Настрочит отписку или сделает вид, что ничего не произошло.

2. На новый хостинг берите только базу данных, а все остальное ставьте с нуля (стандартная схема действий при взломе).

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

4. Все-таки выбирайте хостинг с отдельной Апачей. Я вот навскидку зашел на сайт Каравана - у них за 10 баксов в месяц уже предоставляется отдельная Апача с конфигом, перезапуском и т.п. Это что, дорого для личного спокойствия??

А вообще лучше по таким вопросам пишите мне в личку.

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

Как интересно... Вот есть у меня шаред хостинг... Тысяча сайтов на сервере помимо моих. И что, вы утверждаете что права 400 на нужные файлы меня не спасут? :D

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Как интересно... Вот есть у меня шаред хостинг... Тысяча сайтов на сервере помимо моих. И что, вы утверждаете что права 400 на нужные файлы меня не спасут? ;)

400 - это право только владельца на чтение. И кто же у вас владелец? Если вы - то apache этот файл просто не увидит. Если apache - то его не увидите вы, зато увидят все, кто запускает скрипты под пользователем apache. :D

Файловая система Юникса создавалась задолго до Интернета и публичные демоны в этой концепции не предполагались. Когда появились httpd/ftpd/maild, им начали давать права доступа либо через смену пользователя, либо через биты группового доступа. Apache + PHP получает права через групповой доступ, т.е. на файлы в public_html/ выставляются права 640 или 660, владелец username, группа apache.

Safe mode по умолчанию предполагает ДОПОЛНИТЕЛЬНУЮ проверку username, и если он не совпадает с владельцем скрипта - в доступе отказывается.

Делаются попытки давать доступ по второму варианту - через смену пользователя, наподобие ftp. Во-первых, можно запускать php как скрипт. Во-вторых, есть модуль suphp. Оба варианта в промышленном окружении не живут, т.к. жрут кучу ресурсов.

Или у вас есть другие варианты?

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

Спасибо, почти убедили. Прямые руки решают.

G*g
  • Участники
  • Cообщений: 281
  • http://
  • Интересы:Люблю красивых телок!

Отправлено

Как интересно... Вот есть у меня шаред хостинг... Тысяча сайтов на сервере помимо моих. И что, вы утверждаете что права 400 на нужные файлы меня не спасут? ;)

400 - это право только владельца на чтение. И кто же у вас владелец? Если вы - то apache этот файл просто не увидит. Если apache - то его не увидите вы, зато увидят все, кто запускает скрипты под пользователем apache. :D

Файловая система Юникса создавалась задолго до Интернета и публичные демоны в этой концепции не предполагались. Когда появились httpd/ftpd/maild, им начали давать права доступа либо через смену пользователя, либо через биты группового доступа. Apache + PHP получает права через групповой доступ, т.е. на файлы в public_html/ выставляются права 640 или 660, владелец username, группа apache.

Safe mode по умолчанию предполагает ДОПОЛНИТЕЛЬНУЮ проверку username, и если он не совпадает с владельцем скрипта - в доступе отказывается.

Делаются попытки давать доступ по второму варианту - через смену пользователя, наподобие ftp. Во-первых, можно запускать php как скрипт. Во-вторых, есть модуль suphp. Оба варианта в промышленном окружении не живут, т.к. жрут кучу ресурсов.

Или у вас есть другие варианты?

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

Сообщение отредактировал G*g: 28 Март 2009 - 02:41


FatCat
  • Клиенты
  • Cообщений: 3 351
  • http://pharm-forum.ru
  • Город:נצרת עילית

Отправлено

G*g, alexei1966
Господа, вы уверены, что хирургам следует обсуждать инструментарий в присутствие пациента? :D

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

G*g, alexei1966
Господа, вы уверены, что хирургам следует обсуждать инструментарий в присутствие пациента? :D

Ой, дорогой FatCat - не надо этого делать, вы правы! Правда, вся эта ветка показала, что даже специалисты по php недостаточно знакомы с некоторыми реалиями Юникса. И хостинга. :) Я ведь в основном сижу на форумах сисадминов - там вот эта ситуация с PHP регулярно подымается новичками: да не может быть! - Может, может. - А вот есть лекарство! - А ты попробуй на загруженном хостинге. ;)

Насчет suphp - ну вот, с ходу относительно свежая статейка:
http://blog.stuarthe...-shared-server/

Производительность suphp оказалась по элементарному тесту в 25 раз хуже, чем у обычного php. Правда, suexec еще хуже. Для экспериментов в лаборатории подойдет, для промышленного хостинга - нет. Потому что при высокой нагрузке suphp еще и падает вместе с Апачей.

Есть сборка 2-й Апачи MPM Worker, которая позволяет запускать каждый виртуальный хост под своим пользователем. Я эту сборку мучил пару лет назад - падала от малейшего чиха. Сами разработчики предупреждают: она не для промышленного использования.

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

Насчет защиты с помощью open_basedir. Если safe mode выключен - на полную катушку работают функции exec, system и тп. (эксплойты приводить не буду - это очевидно). Если safe_mode включен - а зачем тогда open_basedir? :)

В общем, не случайно в тарифных сетках очень многих провайдеров сейчас значатся тарифы с отдельной Апачей на отдельном IP. Причем востребованность их растет, цены падают. И главный смысл перехода на эти тарифы - не играться с конфигами, а сесть в "песочницу", чтобы другие не достали.

И еще раз поддерживаю предложение - давайте обсуждать такие вещи в личке.

У меня другая просьба к уважаемым господам Sannis, FatCat и другим старожилам форума. Раз уж у нас начался диалог... Я наткнулся на глобальный баг в календарной системе IPB 2.3. Смысл: если при вводе события указать время суток, оно потом начинает скакать, как заяц. Причем этот баг есть и в версии 3.0, над ним явно работали, но все равно проблема осталась:
http://www.ibresourc...showtopic=57123
http://www.ibresourc...showtopic=53875

Мне календари в моем проекте нужны позарез. Не поможете с локализацией ошибки? А я чем могу - помогу с вопросами безопасности на хостинге, только лучше через личку.

ArtemedoN
  • Участники
  • Cообщений: 332
  • http://www.swtimeline.ru/
  • Город:Израиль

Отправлено

Очень интересная тема, даже статья на тему защиты. Почерпнул кое что. Спасибо.

G*g
  • Участники
  • Cообщений: 281
  • http://
  • Интересы:Люблю красивых телок!

Отправлено

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

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

Сообщение отредактировал G*g: 28 Март 2009 - 15:48


Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

Если safe mode выключен - на полную катушку работают функции exec, system и тп. (эксплойты приводить не буду - это очевидно). Если safe_mode включен - а зачем тогда open_basedir?

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

Вот-вот. Мне видимо, повезло, что безопасный режим выключен, а exeс не доступен? Лучше уж не говорить, какие все плохие, а админы глупые, а назвали хостинги, которыми лучше не пользоваться. От этого была бы всем польза :D

Arhar
  • Команда форума
  • Cообщений: 5 631

Отправлено

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

ArtemedoN
  • Участники
  • Cообщений: 332
  • http://www.swtimeline.ru/
  • Город:Израиль

Отправлено

У меня тогда возник вопрос в ту же тему защиты.
Имеет ли какое-то отношение к php как модуль апачи, как модуль сиджиай и как модуль фаст сиджиай?

Есть ли вариант safe_mode не включать, а поставить php модуль как сиджиай или фаст сиджиай?

Можете прокомментировать сам факт существования разный модулей php и чем это хорошо/плохо в целом и в плане "защиты от соседей" в частности?

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

:) Выдался свободный вечер. Давайте, попробую ответить всем интересующимся в форме вопросов и ответов. Которые, впрочем, следует воспринимать с известной долей юмора. Тем более что наступило 1-е апреля. ;)

*** Почему вы считаете, что виртуальный совместный (shared) хостинг небезопасен с точки зрения секретности данных?

При этом виде хостинга один и тот же демон запущенного веб-сервера обслуживает несколько виртуальных хостов. В реальности их число доходит до 100-200. Программы (скрипты, сценарии), которые запускаются от имени веб-сервера на любом виртуальном хосте, по умолчанию получают права веб-сервера. То есть - если Апача может считать файл с паролями к базе данных в вашем каталоге, этот файл может точно так же прочитать скриптом любой пользователь этого хостинга. При этом в логах не останется никаких следов.


Детали. В классическом Юниксе на файл предусмотрено 3 группы прав: User (владелец), Group (группа), Others (Прочие). Веб-сервер получает доступ к файлам через права группы, потому что других способов при совместном хостинге, к сожалению, просто нет (другие способы возможны только на более современных файловых системах, в частности, NTFS).

Обычно делается отдельный каталог, например, public_html, в котором создаются подкаталоги пользователей с правами 2750:

public_html/ivanov drwxr-s--- ivanov.apache
public_html/petrov drwxr-s--- petrov.apache
public_html/sidorov drwxr-s--- sidorov.apache

Аpache получает права на каталоги с дополнительным битом setGID, поэтому все файлы и каталоги, которые создаются средствами веб-сервера, будут также принадлежать группе apache и apache сможет с ними работать. Такой способ организации файлов и каталогов иногда называют способом BSD.

Таким образом, пользователь ivanov, зайдя по FTP, увидит содержимое только своего каталога, на который он имеет полные права, и сможет выгрузить туда нужные файлы, а к соседям petrov, sidorov и тп. зайти не сможет.

В то же время пользователь apache по умолчанию имеет права на чтение всех подкаталогов public_html/ - он сможет прочитать любые файлы в этих подкаталогах, однако ничего записать туда не сможет. Если веб-серверу нужно что-то писать, то на нужные каталоги следует вручную установить права 2770. Кстати, эта операция проделывается при каждой установке IPB.


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

*** Какой ужас! И что же можно сделать, чтобы скрипты PHP не могли "ходить к соседям"?

Существует два принципиально разных способа.

Первый - ограничивать права внутри самого mod_php. Это safe mode и open_basedir. При safe mode по умолчанию проверяются права владельца на скрипт и сравниваются с правами владельца файла, который этот скрипт пытается открыть. Например, если скрипт из каталога petrov пытается открыть файл в каталоге ivanov, в доступе будет отказано. Также может быть ограничен список программ, которые могут быть запущены скриптами php. При open_basedir ограничивается "сверху" каталог, внутри которого может открывать файлы скрипт данного пользователя.

Недостатки safe mode:
1. Целый ряд сложных скриптов, написанных на PHP, перестает работать.
2. Возможно создание файлов, которые сам пользователь не сможет удалить.
3. Адекватная настройка safe mode достаточна сложна для хостинг-провайдера: запретишь слишком много - будут недовольны пользователи, запретишь слишком мало - а зачем оно тогда надо?
4. Поддержка safe mode после долгих дебатов была полностью удалена из PHP 6. Главный аргумент: порождает в пользователях ложное чувство, что PHP работает "безопасно", а это не так. Читать здесь:
http://www.php.net/~...ting-notes.html

Хорошо также сказано в мануале PHP:
Chapter 42. Safe Mode
The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.


Недостатки open_basedir:
Не ограничивает функции exec(), system() и другие. Без safe mode директива почти бесполезна, в частности, прекрасно сработает такая строчка:

system('cat /path_to/conf_global.php')

Второй способ - динамически менять права веб-сервера на права пользователя в момент исполнения скрипта.

Наиболее известные реализации - suphp и запуск PHP в виде модуля CGI.

Недостаток: чудовищный расход ресурсов процессора. Производительность падает не в 2-3, а в 20-30 раз. Это связано с архитектурой Юникса, в которой никогда не предполагалось, что переключение контекста пользователя будет производиться динамически, для промышленных задач. Такие сложные скрипты, как IPB, OpenCommerce или Bitrix могут запросто повесить машину.

*** А если хорошо отладить safe mode? Решит ли это проблему совместного хостинга?

Ладно, пускай вы отладили safe mode. Но кроме php, существует еще целый ряд языков и интерфейсов. Это:

1. SSI (Server-Side Includes), появившийся в незапамятные времена. Если в ваш хостинг-план входит "поддержка shtml" - знайте, это оно и есть. SSI запускаются с правами веб-сервера и содержат замечательную инструкцию exec. Ее надо отключать (IncludesNoExec).

2. CGI (Common Gateway Interface) - общее название для скриптов на любом языке, которые читают со stdin и отдают поток на stdout. Чаще всего скрипты пишутся на Perl, Python, Tcl/Tk, Java, на Си и языке командного интерпретатора. По умолчанию все эти скрипты также запускаются с правами веб-сервера.

Наиболее распространенный способ решить проблему в CGI - запуск под suexec.

Недостаток: снова - чудовищный расход ресурсов и падение производительности во много раз. Для увеличения производительности, в частности, ставят такую среду, как mod_perl. Однако mod_perl по определению не способен к переключению контекстов и всегда выполняется с правами веб-сервера (говорят, что-то придумали в 2-й Апаче и 2-м mod_perl, но до промышленного использования когда еще дойдет).

*** И все-таки - если хостер все сделал правильно, можно ли быть уверенным в конфиденциальности моих данных на совместном хостинге?

Послушайте, любезный, я повторю еще раз: по умолчанию любой из 100-200 соседей по хостингу может забраться в веб-каталог к вам, как в свой собственный, потому что такова архитектура совместного виртуального хостинга. Чтобы клиенты не лазили друг к другу, администратор хостера должен индивидуально настроить ограничения для каждого языка и для каждой среды исполнения - отдельно для PHP, отдельно для SSI, отдельно для CGI, отдельно для mod_perl и т.п.. Это требует высокой квалификации и большого опыта администраторов. А можно и ничего не настраивать, при этом вопросов в техподдержку пользователи будут писать меньше. И сервера будут работать быстрее. А главное - ответственности хостера за взлом ваших данных ни-ка-кой. Ни юридической, ни моральной.

Добавьте к этому специфические дыры, которые могут быть в библиотеках любого скриптового языка. Например, не так давно прошла информация об эксплойте в PHP конкретных версий, который позволял отправлять на почту произвольный текстовый файл. Вы что, собираетесь следить за всеми библиотеками, которые стоят на хостинге?..

*** Я не верю, что совместный хостинг такой дырявый - вот мой сайт за много лет не сломали ни разу!

Как известно, оптимист - плохо информированный пессимист. Скорее всего, по вашему каталогу уже не раз гуляли разные кракеры, просто они вам в этом не признавались. :D Ну, стянул сопливый кракер вашу базу данных, и дальше чего с ней делать? Чтобы войти в форум, нужен пароль администратора. А для этого надо подобрать его по хэшу, что требует уже определенных познаний. И даже если он войдет в форум как админ - интереса в этом немного. Форум - не интернет-магазин с номерами кредиток. Такие взломы обычно остаются вообще незамеченными.

*** Если совместный хостинг такой небезопасный, зачем он вообще нужен?

Видите ли, 95-98% всех сайтов - это статические страницы. Максимум - к ним добавляется счетчик посещений, почтовая форма обратной связи и гостевая книга. Такой сайт клиенты разово заказывают у веб-дизайнеров или сами делают по шаблону, после чего ничего в них серьезно не меняют годами. Так вот, если даже злоумышленник заберется в каталог такого сайта через локальную файловую систему - он не увидит там ничего нового, кроме того, что и так можно увидеть через веб-браузер. А записать туда свои скрипты он не сможет, потому что каталоги для веб-сервера доступны только для чтения, но не для записи. Так что этим клиентам фиолетово, ходит по ним кракер или нет.

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

*** Так какой же хостинг мне нужен??

Вариант 1. Сейчас многие провайдеры предлагают тарифный план с отдельной Апачей и на отдельном адресе IP. Например, caravan.ru - всего около 400 рублей в месяц. В этом случае веб-сервер запускается под вашей учетной записью или учетной записью специального пользователя, типа apache_petrovи взлом его по локальной файловой системе становится невозможен. Только не забудьте убрать права на чтение для "всех", т.е. права на каталоги должны быть 750, а не 755. Дополнительный бонус - можете организовать к форуму полноценный доступ по https.

Вариант 2. VPS - Virtual Private Server. Фактически в рамках провайдерской машины вы получаете собственный сервер с правами root, который можете настраивать по своему разумению, заводить пользователей Unix, устанавливать свое программное обеспечение и т.п. Цены - от 500-700 рублей в месяц.

Вариант 3. Арендованный сервер. На зарубежных площадках - от 50-70 долларов в месяц, на российских - где-то от 150-200.

*** Я не верю ничему, что вы тут написали! Жил я прекрасно под совместным хостингом и ничего не происходило!
Я тоже ничему этому не верю. Я это знаю. :)

ArtemedoN
  • Участники
  • Cообщений: 332
  • http://www.swtimeline.ru/
  • Город:Израиль

Отправлено

alexei1966!!!!! хорошая статейка. Ушел читать пособие по юниксу.

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

Алексей, спасибо. Думаю многие почерпнут полезное из поста. Как же хорошо, что я "перерос" shared :D

Если кто-то придумает название для темы, перенесу в FAQ или Tricks ;)

ArtemedoN
  • Участники
  • Cообщений: 332
  • http://www.swtimeline.ru/
  • Город:Израиль

Отправлено

Тольков ФАК!
Предлагаю назвать так:
safe mode: off или on?
или
Разновидности хостинга и их уровень (степени) защиты

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Тольков ФАК!
Предлагаю назвать так:
safe mode: off или on?
или
Разновидности хостинга и их уровень (степени) защиты

А если так: "Почему для IPB не подходит shared хостинг?"

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

"Чем плох shared хостинг"?

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

А по мне, так бред. Т.е. все сказано правильно, но свалено в полную кашу совершенно непонятно кому адресованную и несет таким стилем... м.. знаете, "а в интернете есть сайты, а там страшные веши! Даже людей голых показывают, а еще любой хакер может узнать какого цвета у вас трусы". Ощущение, что навалено все, что человек слышал без осознания - к месту ли это сказано вообще. Особо рассуждения про mod_perl порадовали =) Очень поможет тут всем =)

Хотя проблему понять можно, человек сам ее обрисовал. Да, ламеров много, кто думает "ща хостинг сбацаю", только большинство из них дальше слов не уходят, вторая часть быстро сливается, третья в итоге пользуется готовыми панелями в которых, к счастью, за них подумали. Но если сидеть на сисадминских форумах, особо куда они стекаются - то и правда покажется, что шаред это такая жуть, а VPS - единственный выход. Особо если самому в этой каше не вариться - а по некоторым заявлениям видно это так и есть.

А "успокоительных" тут есть. Первая - есть отличные решения в виде готовых панелей. Для новичков. Где нормально все настроено включая safe mode. Второе - есть живучие решения без safe mod. Это и mod_fastcgi, это php-fpm (особо если его доделают), это патчи на апач, которые переключают uid чайлда....

В общем, выбирайте или хостинг где php от вашего же юзера бегает (а уж сколько проблем с правами, масками, записью тут избежите...) или просто хостера с именем и стажем - кто будет следить за php дырками, которые вдруг поломать могут safe mode (и которые частенько сами доводят его до ума смоими патчами)

Сообщение отредактировал MiksIr: 01 Апрель 2009 - 03:59





Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных