BeGet, сервисы в частности sphinx

alexeyymanikin, конкретно не ответили на простой вопрос: "Для чего мне, как партнеру, платить деньги за хостинг, который мне не нужен?"

Получается полная бессмыслица: "Чтобы заработать на вашей партнерской программе, нужно тратить деньги". Либо так, либо никак. Разве это не бред?

Все очень просто - делать либо хорошо, либо не как. Наработки у нас есть, можно сказать готовые к релизу - но вот детали требуют огромного количества времени.

---------- Добавлено 27.02.2017 в 16:50 ----------

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

Наверное стоит описать еще один нюанс нашей партнерской программы в сравнении с некоторыми аналогами - мы нацелены на долгосрочное и взаимовыгодное сотрудничество. Хостинг компании не могут отчислять 40% процентов за услуги которые они перепродают, такие как регистрация доменов, покупка CMS, покупка SSL. Одни из наших коллег по рынку хостинга решили эту проблему разделением платежей за хостинг и остальные услуги, при этом платеж за хостинг нельзя потратить на дополнительные услуги. Мы изначально зачисляем 40% платежей на партнерский баланс и уже если пользователь покупает домен с партнерского баланса списывается 40% от суммы покупки дополнительной услуги. В случае если партнер забирает средства до списания - его партнерский баланс уходит в минус, но мы заинтересованы в том, что бы все его приведенные пользователи оставались нашими клиентами и исходя из этого в последствии своими платежами нивелировали этот минус.

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

Добрый день, клиенты, коллеги.

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

/ru/forum/961280

/ru/forum/960421

При этом часть комментариев в этих постах не просто лишена смысла, а, наоборот - может сделать только хуже. По факту из ТОП10 Российских хостингов только у нас есть изоляция сайтов в рамках аккаунта, может быть и из ТОП50, но дальше ТОП10 я не анализировал. В свое время мы словили много проблем, багов и сбоев (и, конечно, сломанных сайтов =), вводя эту систему, хотя внешне она максимально проста. В этом посте я бы хотел рассказать, как она работает с точки зрения пользователя.

Для начала я бы хотел немного пояснить - в нашей системе под сайтом подразумевается директория на диске, под доменом - доменное имя (будь то домен или поддомен, не важно). Например /test.ru/public_html - это сайт, а http://test.ru - это домен.

Теперь, собственно, про изоляцию.

При создании акаунта у нас создаётся основной пользователь на сервере, по умолчании его логин и пароль совпадает с логином и паролем для входа в панель управления

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

Пример сайта в данном случае - alexeyxt.beget.tech. Опять же обычные права "владелец, группа, остальные" в данном контексте не совсем правильны, ну и "+" в конце прав намекает на posix acl. В директории сайта файлы так же принадлежат основному пользователю:

Но все процессы этого сайта работают не из под основного пользователя (под процессами сайта я подразумеваю, например, apache, php, python, nginx, отдельный ftp доступ, отдельный ssh доступ и так далее). Для этого сайта был создан отдельный пользователь:

Более внимательный читатель заметит, что ID это пользователя не совсем случайная величина =). Если посмотреть vhost apache для alexeyxt.beget.tech, там будет секция:

То есть все процессы этого пользователя, запущенные через Apache, а также порожденные от них, будут работать от пользователя alexeyxt__alexeyxtjbegetjtec__yq. Со стороны пользователя это выглядит так:

Если посмотреть posix acl, можно увидеть:

То есть этот пользователь имеет права на запись и чтение из директории сайта, но не из общей директории и не из директории других сайтов. Основной пользователь нужен в основном для:

• подсчета нагрузки (так как нагрузка всех сайтов учитывается у основного пользователя)
• удобства администрирования сайтов - один доступ FTP/SSH
• системных целей, например, запуск Cron задач, которым нужен доступ ко всем сайтам.

Опять же схема разделения с разными пользователями позволяет определять нагрузку каждого сайта в отдельности.

Это то, что можно назвать простой частью. Так как возможностей posix acl нам не хватало, мы сделали beget acl - набор патчей на ядро, которые реализуют наши потребности.

Тут нужно также отметить некоторые дополнительные методы защиты - все процессы Apache запускаются в отдельных docker контейнерах, что даёт дополнительную изоляцию от основной системы. Помещаются в определенные группы в зависимости от параметров и много другое. Но думаю основной принцип работы изоляции сайтов в данном посте я изложил.

какой-то набор слов, думаете "не линуксоиды" тут что-то поняли?

какой вывод делать из стать?

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

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

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

Прошу прощения, я обычно писал только технические статьи. К сожалению сложно написать статью которая будет одинакова понятна и полезна всем.

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

Спасибо, Алексей, а покажите-ка getfacl alexeyxt.beget.tech

И скриншот у меня выдает 403.

Спасибо за информацию.

Примерно также реализовывал в своей системе, тоже на базе itk, но меня остановило создание unix-юзверя для каждого домена, поэтому ограничился созданием отдельного www пользователя на аккаунт. Конечно это не даёт той межсайтовой защиты о которой мы говорим, но всё таки это лучше чем работа всего аккаунта от одного пользователя.

Т.е. у вас там тысячи unix пользователей и это не вызывает никаких проблем?

Dimanych, 64 бит ОС имеет 2 в 43 степени user_id пространство, не в это упрётся ;)

Если честно, то не вижу смысла в такой грамоздкой системе, стабильность и надёжность которой тоже сомнительна. Да, удобство в управлении безусловно плюс, но с другой стороны минус одна точкка доступа со стороны основного пользователя. Учитывая то, что многие вебмастеры используют вечно дырявый Windows Commander или что то подобное, то безопаснотсь в такой системе не на много выше чем на обычном шарике. Нет ничего лучше, как реальный отдельный unix пользователь.

Прошу прощения

---------- Добавлено 04.04.2017 в 23:24 ----------

Пример сервера для free хостинга

ну как сказать не вызывает, конечно проблем было много, но все они решаемы. Внедряли мы эту систему более полугода и в процессе внедрения было очень много проблем =)

---------- Добавлено 04.04.2017 в 23:28 ----------

не кто не мешает создавать отдельного пользователя ftp/ssh для каждого сайта. то есть это выбор каждого пользователя. Так же не нужно забывать про многосайтовые системы или сайты которым нужны общие данные. Вопрос исключительно в гибкости и удобстве.

Повторюсь, если у Вас свой VPS - это одно дело, если Вы клиент шаред хостинга - изоляция сайтов среди ТОП10 хостингов есть только у нас.

---------- Добавлено 04.04.2017 в 23:57 ----------

тест прикрепления картинки

Я понимаю пользу такого решения, в данный момент это будет пользоватся спросом, так как экономическая ситуация заставляет вебмастеров экономить. У них множество сайтов и само собой дырявые скрипты. Но изоляция не решает всех проблем, так как зараженные сайты генерируют огромные нагрузки и опасны другим серверам. То есть чистить всё равно надо.

Неизвестна остальная часть системы, по этому сложно что то понять.

По сути, всё это можно рещить с помошью mod_privileges.