php 5.3 и Zend

[HOSTPLUS]

 

Видимо вы не умеете сервер готовить.

Не покупать же ради одного биллинга новый сервер

 

Готовить нужно пасту с соусом и сыром на ужин. Странная у Вас логика...

 

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

[partizansk.eu]

что нам теперь переносить домен с биллингом на другой сервер, где развёртывать php 5.3.x?

 

Кстати это одна из официальных рекомендаций по установке биллинга (на форуме неоднократно писалась данная рекомендация)

 

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

Это всего лишь рекомендация и не более...

 

HOSTPLUS, тем более не Вам решать, кому и где хранить биллинг (отдельно на выделенном сервере и/или VPS, либо на сервере с частью клиентскими аккаунтами). Не суйте нос в чужой бизнес и свои рекомендации по этому поводу оставьте при себе, ок? Если нет в штате хороших админов, либо боитесь чего-то - не стоит вообще тогда лезть в эту сферу деятельности.

 

Ждём ответа admin'a.

[HOSTPLUS]

между *совать свой нос* и *рекомендовать что-то, принимая во внимание ряд аспектов* огромная разница

 

п.с. просьба оставить Ваше детское самолюбие при себе

[admin]

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

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

Каждый сам решает как ему вести бизнес и какие меры безопасности принимать.

[xaker1]

На хорошо настроенном сервере никто не влезет)

[HOSTPLUS]

На хорошо настроенном сервере никто не влезет)

 

 

Наивное заблуждение, *хорошо* настроенных серверов в данном аспекте НЕ бывает в природе Просто разница между тем где размещён биллинг (на отдельном сервере или вместе с клиентами) заключается в том, что кроме потенциальных нарушений безопасности, основанных на использовании уязвимостей серверного ПО (ядра и прочее) ещё добавляется опасность потенциальных нарушений безопасности, основанных на использовании уязвимостей скриптов Ваших клиентов (на любом хостинге полно старых CMS, написанных кем попало и как попало). Всё закрыть нельзя (точнее теоретически можно, только тогда ничего работать не будет вообще фактически).

[partizansk.eu]

HOSTPLUS, за ~5 лет работы ни одного взлома не было, про разрывы писать не будем, это не по нашей части ))).

Это вам о чем-нибудь говорит? или снова к детям попытаетесь меня отнести.

 

Если у "ваших" админов кривые руки, это не наша проблема.

[partizansk.eu]

Каждый сам решает как ему вести бизнес и какие меры безопасности принимать.

Согласен.

[HOSTPLUS]

HOSTPLUS, за ~5 лет работы ни одного взлома не было, про разрывы писать не будем, это не по нашей части ))).

Это вам о чем-нибудь говорит? или снова к детям попытаетесь меня отнести.

 

Если у "ваших" админов кривые руки, это не наша проблема.

 

1) При чём тут были или не были взломы, если Вы всё делаете по вечному русскому принципу (пока гром не грянет, мужик не перекрестится), если с Вами не было ни разу ничего, это не значит, что у Вас всё на столько хорошо (нарушения доступа бывают даже у ресурсов платёжных систем), просто Вам повезло (не нашлось никого, кого бы Вы и Ваши сервера заинтересовали)

2) Никаких инцидентов с биллингом у нас тоже не было (опять же это не имеет никакого отношения к теме)

3) Речь идёт о том, что даже на отдельном сервере в любой момент могут случится ситуации несанкционированного доступа (в районе осени 2010 публично стало известно про существование серьёзной уязвимости в ядре CentOS 64-битной архитектуры, поищите в поиске, удивитесь столько провайдеров тогда получили проблемы, а сколько ПОСТОЯННО появляются только ПУБЛИЧНЫХ уязвимостей в Exim, Bind, FTP демоны вообще многие очень дырявые). Но это только если говорить про случай, когда закрыты основные источники нарушения доступа и вот тут как раз и появляются Ваши клиенты (обычно сами того не зная). Очень распространённый пример (возможно он именно Вас не касается, но такая опасность есть очень у многих провайдеров, причём некоторые из них знают про данный факт, но фактически ничего не делают, ибо (как я уже сказал ранее) если всё закрыть, просто ничего не будет работать. Пример:

PHP работает в режиме DSO (у апача), на сервере живёт юзверь с CMS старых типов (например Joomla 1.0), или в ручном режиме или используя ботов нашли этот сайт, через XSS (и прочее) заливается ряд скриптов, те (через exec ф-ции)заливают бинарник и запускают его в /tmp, бинарник является экслоитом (бекдором и т.д. на выбор), далее в зависимости от ряда факторов (версии, наличие патчей и т.д.) выполняются деструктивные действия (от банальных перехватов управления процессов апача и выставления заставок на сайтах Ваших клиентов, что мол есть такие крутые перцы, что сделали это, до повышения привилегий до уровня root со всеми вытекающими). Если в системе стоят запреты на исполнение данных ф-ций (PHP), их обходят через .htaccess (в DSO) или через загрузку своего php.ini (в CGI режимах)

 

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

 

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

[cryo]

Алексей, пришлите, пожалуйста, ссылку на сборку под 5.3 и нам. Может, там не всплывет проблема с ukrnames

[admin]

Скинул ссылку в личку, но наврядли причина в версии PHP.

[HOSTPLUS]

Скинул ссылку в личку, но наврядли причина в версии PHP.

 

публично релиз под PHP 5.3 станет доступен с 1 Августа (через order.bpanel.ru)?

[cryo]

Скинул ссылку в личку, но наврядли причина в версии PHP.

 

Переход на 5.3 + ZendGurad 5.5 решил проблему с именем функции, ukrnames заработал Спасибо.

[admin]

Скинул ссылку в личку, но наврядли причина в версии PHP.

 

публично релиз под PHP 5.3 станет доступен с 1 Августа (через order.bpanel.ru)?

Да.

 

Скинул ссылку в личку, но наврядли причина в версии PHP.

 

Переход на 5.3 + ZendGurad 5.5 решил проблему с именем функции, ukrnames заработал Спасибо.

Спасибо за информацию. Возможно у Вас в php 5.3 появилось что-то, чего не было в php 5.2.

[Vladimir812]

Мне киданите в лицу на 5.3 ссылочку тоже.

[Vladimir812]

В последнем билде admin.php не в нужном Зенде, прошу срочно исправить и выложить билд.

 

Fatal error: Incompatible file format: The encoded file has format major ID 1, whereas the Loader expects 4 in /home/*****/public_html/order/admin/conf/admin.php on line 0

[Lazek]

Этот файл вообще не закодирован по умолчанию..

[Vladimir812]

Я папку /conf не обновляю и там был в старом зенде этот файл, разобрался уже. Мы его сами зендили.

[partizansk.eu]

Хостеры имеющие свои собственные сервера могут обновить php до 5.3, а как быть реселлерам у которых биллинг установлен на сервере вышестоящего провайдера, где работает 5.2.x и вышестоящий отказывается в обновлении php? Можно сделать обновление в автоматическом режиме autoupdate из биллинга с выбором для php 5.2 и php 5.3? или заметку в каком режиме будет обновлено при autoupdate, иначе начнётся путаница и доп.вопросы. Хотя бы раз в две недели с выходом новых изменений шифруйте код для php 5.2, т.к эта версия php, думаю, ещё будет очень долго использоваться большинством хостинг-провайдерами.

 

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

[admin]

Можете приобретать хостинг или до упора использовать старую версию под php 5.2.

Смысла поддерживать бипанель под две версии php, одну из которых с предыдущего года уже и не поддерживает разработчик php, - я не вижу. Трудозатраты значительные и неоправданные.

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

[partizansk.eu]

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

И чтобы половина клиентов ушли со старыми скриптами? нет уж, спасибо. К примеру, форум линейки IPB 2.x.x на php 5.3 уже не работает.

Придёться в скором времени переносить биллинги на VDS раз на то пошло.

 

Сделайте, пожалуйста, рассылку и в требованиях пропишите, что с 1 августа новые версии продукта работают только с PHP линейки 5.3.

[admin]

Вообще-то IPB уже давно как версии 3.1

Надо следить за актуальностью своего ПО и не ставить аккаунт под угрозу, используя давно устаревшие версии скриптов.

[partizansk.eu]

Вообще-то IPB уже давно как версии 3.1

Надо следить за актуальностью своего ПО и не ставить аккаунт под угрозу, используя давно устаревшие версии скриптов.

Есть такие форумы с линейкой IPB 2.2.2, к примеру, где написано модулей только на одном ~ на 500$, на другом почти на 800$. При обновлении на 3 ветку, модули теряют свою работоспособность. Хорошо, пусть два таких форума можно перенести на другой сервер с php 5.2 но, взять клиентов с другими скриптами, которые в рассылке при опросе категорически отказались от перехода на 5.3 и таких большинство, это же большинство и приносит основной доход с окупаемостью самого сервера. Что делать с реселлерскими аккаунтами, которые также используют ПО Bpanel, к сожалению, пока незнаем.

 

Вот Вы головную боль создали этим переходом на 5.3...

[admin]

Для таких VIP клиентов действительно нужно выделять специальный сервер под ключ к их скриптам, но использовать из-за модулей старые версии ПО все равно небезопасно и непрактично. Жизнь не стоит на месте

Возможно нужно приводить в соответствие актуальной версии PHP и доп. модули, написанные за такие баснословные деньги.

[partizansk.eu]

Алексей, Вам сложно будет хотя бы раз в месяц шифровать Вpanel с выходом новых изменений под php 5.2.x? Подумайте о реселлерах... Ладно мы своих переведём на другой сервер с php ветки 5.3.x (не так уж и много у них сайтов висит на аккаунтах, договоримся как-нибудь), свой биллинг отдельно поставим на VDS с php 5.3.6 но, подумайте о тех, кто покупает реселлинг у сторонних провайдеров, где используют до сих пор php 5.2.x и которые категорически отказываются от перехода на ветку 5.3.x. Не нужно только говорить о давности скриптов, каждый вправе использовать ту версию скрипта, которая ему подходит. Не нам судить об этом, клиентам виднее. Рассмотрите ещё раз просьбу с поддержкой биллинга под php 5.2.x, пусть не частые будут обновления и то, думаю, многие им будут рады, в том числе и мы. Спасибо.

 

P.S. Модули писались и усовершенствовались около двух лет, их даже в паблике нет. Конечно это наши VIP-клиенты, с индивидуальными т.п., но отдельного сервера, либо VPS жирновато будет. Обычный shared справляется с нагрузкой, незачем клиенту переплачивать и нанимать админа, либо заказывать ещё и администрирование своего сервера.