Если сервер отвечает клиенту и сервер отправляет клиенту периодическую информацию по одному соединению, то может.
Решение -- вместе с пакетом передавать тип сообщения (ответ или информация) и обрабатывать должным образом.
poiuty, +1, настройка sendmail должна начинаться и сразу же оканчиваться его удалением :)
Вы уверены, что Ваш ДЦ/провайдер не требует, чтобы почта отправлялась не напрямую, а через его smtp-сервер?
BILLmanager, сильно допиленный под себя.
Не мучайтесь и поставьте CloudLinux. Он умеет жёстко ограничивать CPU для всех процессов одного юзера, распределяя между ними разрешённое время поровну.
Делиться он тоже позволяет, если время жизни скрипта очень короткое
Кстати, партнёрский договор можно скачать в биллинге ISPsystem в разделе "Договоры", если Вы партнёр.
Flantru, servts, зачем кормите тролля?)
Добавьте RemoteIPInternalProxy айпи_сервера
Мои мнения не меняются ежеминутно. Максимум один раз :) Выше я уже написал, к каким сообщениям были обращены мои посты. Если Вы почитаете начало темы, то увидите как раз сообщения "издалека в глобальных масштабах" о политике компании, цене и прочем, на которые я и отвечал.
Мнение "конкретно по данной теме и данной ситуации" опубликовано топикстартером ещё вчера в виде сообщения о том, что мы сделали рассылку и подтверждено в моём первом сообщении. Так как мнение по конкретной ситуации у нас с Вами совпадает, а Вы спорите с моими постами, то я решил, что Вы спорите с далёкой и глобальной частью.
Согласился я не со всеми ораторами, а с Postfix, так как получил сильный аргумент как раз по глобальному вопросу: публикация зашифрованного сообщения об уязвимости на форуме равносильна надписи о её существовании в changelog.
Проблемы автообновления я не хочу сейчас обсуждать. Очевидно, что политика "сетапить клиентам текущую версию и оставлять её такой навсегда" неверная.
Клиентам на администрировании мы периодически обновляем руками в рамках stablе-версии, фатальных проблем последнее время было ну совсем мало.
Вроде бы наше отношение к публикации конкретно этой уязвимости уже было показано той самой рассылкой из начала топика и обсуждать тут тоже нечего. Я пытаюсь отреагировать на сообщения вида "все разработчики всего софта всегда рассылают все сообщения о всех багах, а испсистем никогда ничего и никому" и показать, что молчание о багах тоже имеет смысл.
Сторонние сообщения об ошибках тоже бывают разные: это может быть "я знаю, что можно сломать таким образом" и "меня взломали таким вот образом". В первом случае нужно смотреть на степень доверия к репортёру, и если есть уверенность, что копия репорта не ушла на хакерские форумы (а вероятность этого достаточно велика, так как хакеру смысла репортить уязвимость в ISP нет), то молчать. Во втором случае нужно думать, был ли это разовый взлом или использование опубликованной уязвимости и, в любом случае, уже предпринимать какие-либо действия.
В первую очередь Вы должны были бы сообщить разработчику и не предпринимать никаких действий, пока не выйдет фикс.
Например, можно вспомнить недавнюю DoS атаку, связанную с cronrun: из благих побуждений был описан рецепт лечения баги до обновления (через удаление cronrun), но из-за слишком подробной информации уязвимость была легко вычислима и используема на необновлённых серверах. Из-за привлечения дополнительного внимания проблемы указались у на порядок большего количества людей, чем могли бы.
Если бы Вы описали фикс для текущей проблемы, то она тоже была бы легко вычислима и принесла бы намного больше проблем.
И тут привлекать сложные моральные принципы называния себя администратором или соучастником преступления становится немного сложнее: будет ли администратор, опубликовавший подробности уязвимости до фикса настоящим администратором, так как предупредил кого-то о том, как закрыть проблему, или он будет соучастником, так как дал хакеру необходимую для взлома информацию?
После фикса ситуация меняется, так как исправление звучит как "обновиться до последней версии", и тут я уже согласен с аргументом про форум/changelog из предыдущего сообщения от Postfix.
Это уже очень спорный вопрос.
Достаточно давно читал обсуждение, как нужно исправлять лично найденную проблему с переполнением буфера или другими критическими ошибками в open source-проектах. Есть два варианта:
Моё личное мнение говорит, что с точки зрения безопасности редко обновляющихся пользователей намного предпочтительнее первый вариант. Оно так же распространяется на продукты с закрытым кодом с соответствующими поправками.
Пожалуйста, не нужно считать мои сообщения попыткой защитить ISPsystem -- это моё личное мнение, касающееся разработки любых продуктов в целом.
Я прекрасно понимаю Вас как партнёра. Мне тоже было неприятно получить эту информацию не от ISPsystem. Но, поверьте, Вам и Вашим клиентам будет намного лучше, если бОльшая часть багов будет молча исправляться и выкатываться клиентам, а не описываться в рассылке по всему интернету.
