Проблемы обновления ПО на хостингах

[leave]

Victor Gr., не хуже вас знаю ситуацию на хостингах. Только не боятся, а не могут. Потому что слетит нафиг половина скриптов клиентских. По этой же причине кое-где и 3.23 найти можно, и PHP 4.4.4 Новый софт ставится только на новые сервера. А поставить постгрю вместо мускля - не вижу проблемы. У самого на десятке серверов крутится - половина юзеров пользует беспроблемно. Правда, эти же юзера и mencoder зачем-то просили, но это уже не мое дело, а заказчика:)

[Llama]

Да, клиент такое существо что его надо перодически переводить с сервера на сервер. Старая добрая отмазка "там диск/паять/процессор etc. скоро сломаются/сгорят/etc." почти всегда позволяет договориться с клиентом. А там клиент встает перед фактом новых версий ПО. При грамотном подходе, поддержке и условии что хочтер не состояит всего из двух серверов - будет работать.

[Victor Gr.]

leave, да я и не претендую

Как раз таки могут, только бояться. Бояться, что скрипты перестанут работать.

Я не откажусь пользоваться pgsql, только если... Если будет время на переписываение скриптов/SQL-запросов и если в pgsql будут хоть какие-то преимущества перед mysql.

[leave]

Или если mysql станет платным
На самом деле, постргя мне нравится больше мускля - хотя бы с точки зрения администирирования. У нее есть только один минус (ИМХО) - отсутствие кластеризации родными средствами. Только 3rd-party костылями.

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

+1, как говорится.

[master_of_shadows]

leave, Llama, жОсткие вы ребята. Я бы у вас не хостился...

[Victor Gr.]

master_of_shadows, а куда поденешься... Все они такие. Разве что, некоторые переносят тебя на другой сервер без вопросов и без предупреждения, а потым ты как идиот пытаешься понять, почему ничего не работает.

Надо брать свой VPS с администратированием.

[Llama]

leave, Llama, жОсткие вы ребята. Я бы у вас не хостился...

Ну и дурак. Отгреб бы в один прекрасный день дыру в древнем php и плакал бы "восстановите меня из бэкапа".

Перевод на другой сервер - наиболее мягкий способ обновления версий ПО позволяющий учесть личные сексуальные проблемы клиента. Сравни это с традиционным "а сегодня у нас php5!".

[master_of_shadows]

Llama, чёта я ничего не понял... Дыра в пхп - это кривые руки админа не ставящего патчи, а перевод на новую версию софта - это головняк клиенту. Что не так?

[Llama]

Llama, чёта я ничего не понял... Дыра в пхп - это кривые руки админа не ставящего патчи, а перевод на новую версию софта - это головняк клиенту. Что не так?

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

[leave]

master_of_shadows, я ведь могу в целях секурности и обрезать глобалс и allow_url_fopen после чего у половины клиентов написанные криворукими программерами скрипты перестают работать.

Дыра в пхп - это кривые руки админа не ставящего патчи, а перевод на новую версию софта - это головняк клиенту. Что не так?

а когда 4 стала unsupported - что прикажете делать? оставлять как есть или устраивать головняк клиентам?

[Victor Gr.]

leave, так может в целях секьюрности вообще PHP отключить?

Есть разная секьюрность: одно дело, когда взламывают через ошибку в PHP, а другое -- когда через логическую ошибку в скрипте.

Первое -- забота хостера. Второе -- клиента.

[leave]

И третье: когда ломают хостера через клиента, у которого не хватило мозга работать через парсеры, а не городить удаленный инклуд без проверки входных данных.
А вообще да, PHP - зло, и его нужно отключать

[Llama]

leave, так может в целях секьюрности вообще PHP отключить?

Есть разная секьюрность: одно дело, когда взламывают через ошибку в PHP, а другое -- когда через логическую ошибку в скрипте.

Первое -- забота хостера. Второе -- клиента.

Ты узко смотришь. Во-первых - любые проблемы с безопастностью - всегда проблемы хостера - ибо спам-комплейны и прочие эбьюзы разгребать именно ему. Прблемы с безопастностью одного аккаунта оказывают влияние на весь сервер - скажем, установленый пхп-мейлер загоняет сервер в блэк-листы (это решается нормально организацией почты да и вообще системы хостинга конечно же), но и создается аномальную нагрузку на сервер мешая другим клиентам. Не говоря уже о DOS-атаках спровацированых утечкой ресурсов в клиентском ПО. Кроме того, клиент искренне не понимает, почему вдруг сломался его форум, почему хостер отказывается устранять последствия бесплатно и блокирует работу заведомо дырявого ПО, а то и всего аккаунта в некоторых случаях. Соответсвенно, в интересах и хостера и большинства клиентов - заранее вводить достаточно жесткие ограничения по безопастности. Конечно, менять правила задним числом - это мягко говоря нехорошо. Ни хостер ни клиенты шареного хостинга не должны расплачиваться за идиотизм и лень быдлокодеров, которым лениво писать проверку входящих параметров в наколенных поделках. По этому я использоую и рекомендую использовать другим доступные технические средства ограничения технического кретинизма - благо дыры находили, находят и будут находить в совершенно любом ПО. В приницпе, нормально организованя система не имеет соврешенно никакой потребности в openbasedir, safe mode и т.п. костылях. А вот hardened php, всяик mod_security, лимиты и т.п. - рекомендуются мною к использовани, при наличии четкого понимаю как оно работает. Правило тут одно: не используй то что не понимаешь до конца.

И третье: когда ломают хостера через клиента.

А вот это клиента вообще не должно волновать Совершенно. Никак. Хостер должен предоставить такое окружение, в котором конфиденциальность данных кодного клиента не ставилась бы под сомнение дырами в ПО другого клиента. К сожалению не существует пригодных для массового шареного хостинга адекватных механизмов квотирования производительности, так что речь пока только о безопастности.
То, что хостер боится обновлять сервера, т.к. у него может упасть cPanel - это его личные сексуальные проблемы. Если у админа дрожат руки перегрузить сервер с самосборным ядром, а менеджер не понимает необходимости serial console - это сугубо хостерские порблемы.

[leave]

сервер с самосборным ядром

ИМХО ужос! что угодно - но только не самосборное ядро. если, конечно, речь не про БСД, где pf и квотирование по дефолту выключены. надо тюнинг - нате вам sysctl. не более.

А вот это клиента вообще не должно волновать

так это хостера и волнует в первую очередь. хотя бы потому, что через не закрытую дырку в отсутствие basedir'а можно слить /etc/passwd. а когда на шареде ~500 акков, лобовой подбор очень даже возможен (берем для примера сипанель, где один пасс на ssh/ftp/панель. и поменять его можно и через passwd, и через гуй ).

менеджер не понимает необходимости serial console - это сугубо хостерские порблемы.

вот с примерно такого хостинга я и ушел в админы j2ee апп.серверов:)

[Victor Gr.]

Llama, наверное я смотрю узко. Но только по той причине, что сам не хостер, а клиент

Честно сказать, натерпелся у swisshost.by, где тебя на прошлой неделе перебросили на другой сервер, а ты потом удивляйся, почему вдруг что-то отвалилось. Где техподдержка на любой вопрос отвечает "Мы проверили, всё в порядке".

Так, сколько спрашивал насчёт обновления MySQL до 4.1 (хотя бы, чтобы unicode работал) -- ничего.

Так, пусть хостер что угодно делает, хоть каждый день по серверам перекидывает, абы всё работало и ничего не отваливалось.