- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
alexeyymanikin, конкретно не ответили на простой вопрос: "Для чего мне, как партнеру, платить деньги за хостинг, который мне не нужен?"
Получается полная бессмыслица: "Чтобы заработать на вашей партнерской программе, нужно тратить деньги". Либо так, либо никак. Разве это не бред?
Не сдерживайте себя, интересно Ваше мнение.
Все очень просто - делать либо хорошо, либо не как. Наработки у нас есть, можно сказать готовые к релизу - но вот детали требуют огромного количества времени.
---------- Добавлено 27.02.2017 в 16:50 ----------
alexeyymanikin, конкретно не ответили на простой вопрос: "Для чего мне, как партнеру, платить деньги за хостинг, который мне не нужен?"
Получается полная бессмыслица: "Чтобы заработать на вашей партнерской программе, нужно тратить деньги". Либо так, либо никак. Разве это не бред?
В любом из вариантов будет негатив или отрицательные стороны. Либо будут блокировки партнеров с одним реффералом, либо нужно будет платить за хостинг либо ранжировать процент выплат. Я не в коем случае не спорю, что схема предложенная нами может подойти не всем - но факт в том, что она достаточно проста. Когда мы вводили эту схему процент отчислений, который мы платили был максимальный. Некоторые наши коллеги ранжировали его в зависимости от количества привлеченных клиентов.
Наверное стоит описать еще один нюанс нашей партнерской программы в сравнении с некоторыми аналогами - мы нацелены на долгосрочное и взаимовыгодное сотрудничество. Хостинг компании не могут отчислять 40% процентов за услуги которые они перепродают, такие как регистрация доменов, покупка CMS, покупка SSL. Одни из наших коллег по рынку хостинга решили эту проблему разделением платежей за хостинг и остальные услуги, при этом платеж за хостинг нельзя потратить на дополнительные услуги. Мы изначально зачисляем 40% платежей на партнерский баланс и уже если пользователь покупает домен с партнерского баланса списывается 40% от суммы покупки дополнительной услуги. В случае если партнер забирает средства до списания - его партнерский баланс уходит в минус, но мы заинтересованы в том, что бы все его приведенные пользователи оставались нашими клиентами и исходя из этого в последствии своими платежами нивелировали этот минус.
Отвечая на Ваш вопрос - да возможно схема с активным хостинговым аккаунтом не очень удобна для Вас, но она очень удобна нам и позволяет избежать множества проблем и ручной обработки, в 2010 году она позволили нам платить максимальный процент из всех участников рынка.
Добрый день, клиенты, коллеги.
В последнее время начали появляться посты с вопросами - нужна изоляция сайтов, как защитить сайты, хостинг с разделением пользователей - примеры можно посмотреть тут:
/ru/forum/961280
/ru/forum/960421
При этом часть комментариев в этих постах не просто лишена смысла, а, наоборот - может сделать только хуже. По факту из ТОП10 Российских хостингов только у нас есть изоляция сайтов в рамках аккаунта, может быть и из ТОП50, но дальше ТОП10 я не анализировал. В свое время мы словили много проблем, багов и сбоев (и, конечно, сломанных сайтов =), вводя эту систему, хотя внешне она максимально проста. В этом посте я бы хотел рассказать, как она работает с точки зрения пользователя.
Для начала я бы хотел немного пояснить - в нашей системе под сайтом подразумевается директория на диске, под доменом - доменное имя (будь то домен или поддомен, не важно). Например /test.ru/public_html - это сайт, а http://test.ru - это домен.
Теперь, собственно, про изоляцию.
При создании акаунта у нас создаётся основной пользователь на сервере, по умолчании его логин и пароль совпадает с логином и паролем для входа в панель управления
alexeyxt:x:1316:601::/home/a/alexeyxt:/bin/false
Все файлы принадлежат этому пользователю, за исключением директорий сайтов - владельцем их является root. Это сделано для того что бы пользователь не мог удалить директорию сайта
total 44
drwx------+ 6 root root 4096 Apr 4 19:11 .
drwx--x--t 32 root root 4096 Apr 4 19:17 ..
drwx------+ 2 alexeyxt newcustomers 4096 Apr 4 19:11 .gem
drwx------+ 2 alexeyxt newcustomers 4096 Apr 4 19:11 .local
dr-x------+ 2 root root 4096 Apr 4 19:11 .service
drwx------+ 3 root root 4096 Apr 4 19:11 alexeyxt.beget.tech
Пример сайта в данном случае - alexeyxt.beget.tech. Опять же обычные права "владелец, группа, остальные" в данном контексте не совсем правильны, ну и "+" в конце прав намекает на posix acl. В директории сайта файлы так же принадлежат основному пользователю:
/home/a/alexeyxt/alexeyxt.beget.tech/public_html
epsilon1 : /home/a/alexeyxt/alexeyxt.beget.tech/public_html [0] # ls -la
total 36
drwx------+ 3 alexeyxt newcustomers 4096 Apr 4 19:11 .
drwx------+ 3 root root 4096 Apr 4 19:11 ..
drwx------+ 2 alexeyxt newcustomers 4096 Apr 4 19:11 cgi-bin
-rwx------+ 1 alexeyxt newcustomers 11236 Apr 4 19:11 index.php
Но все процессы этого сайта работают не из под основного пользователя (под процессами сайта я подразумеваю, например, apache, php, python, nginx, отдельный ftp доступ, отдельный ssh доступ и так далее). Для этого сайта был создан отдельный пользователь:
Более внимательный читатель заметит, что ID это пользователя не совсем случайная величина =). Если посмотреть vhost apache для alexeyxt.beget.tech, там будет секция:
MaxClientsVHost 30
AssignUserId #66852 #601
</IfModule>
То есть все процессы этого пользователя, запущенные через Apache, а также порожденные от них, будут работать от пользователя alexeyxt__alexeyxtjbegetjtec__yq. Со стороны пользователя это выглядит так:
Если посмотреть posix acl, можно увидеть:
# file: index.php
# owner: alexeyxt
# group: newcustomers
user::rw-
user:alexeyxt:rwx
user:alexeyxt__alexeyxtjbegetjtec__yq:rwx
group::---
group:newcustomers:---
group:alexeyxt:--x
mask::rwx
other::—
То есть этот пользователь имеет права на запись и чтение из директории сайта, но не из общей директории и не из директории других сайтов. Основной пользователь нужен в основном для:
Опять же схема разделения с разными пользователями позволяет определять нагрузку каждого сайта в отдельности.
Это то, что можно назвать простой частью. Так как возможностей posix acl нам не хватало, мы сделали beget acl - набор патчей на ядро, которые реализуют наши потребности.
Тут нужно также отметить некоторые дополнительные методы защиты - все процессы Apache запускаются в отдельных docker контейнерах, что даёт дополнительную изоляцию от основной системы. Помещаются в определенные группы в зависимости от параметров и много другое. Но думаю основной принцип работы изоляции сайтов в данном посте я изложил.
какой-то набор слов, думаете "не линуксоиды" тут что-то поняли?
какой вывод делать из стать?
такое ощущение что тут у вас пропущен кусок текста после этого:
Со стороны пользователя это выглядит так:
в моем понимании изоляция - в данном случае это тогда, когда скрипты одного сайта не могут подняться выше папки домена, в папку соседнего домена (есть упоминание этого в статье).
ну а создание пользователя фтп и базы данных всегда было по умолчанию в стандартном cpanel и других панелек.
какой-то набор слов, думаете "не линуксоиды" тут что-то поняли?
какой вывод делать из стать?
такое ощущение что тут у вас пропущен кусок текста после этого:
в моем понимании изоляция - в данном случае это тогда, когда скрипты одного сайта не могут подняться выше папки домена, в папку соседнего домена (есть упоминание этого в статье).
ну а создание пользователя фтп и базы данных всегда было по умолчанию в стандартном cpanel и других панелек.
Прошу прощения, я обычно писал только технические статьи. К сожалению сложно написать статью которая будет одинакова понятна и полезна всем.
Когда я в соседних темах писал - "у реализована изоляция сайтов и скрипты сайта не могут выйти за пределы директории сайта", меня просили более подробно об этом рассказать.
Спасибо, Алексей, а покажите-ка getfacl alexeyxt.beget.tech
И скриншот у меня выдает 403.
Спасибо за информацию.
Примерно также реализовывал в своей системе, тоже на базе itk, но меня остановило создание unix-юзверя для каждого домена, поэтому ограничился созданием отдельного www пользователя на аккаунт. Конечно это не даёт той межсайтовой защиты о которой мы говорим, но всё таки это лучше чем работа всего аккаунта от одного пользователя.
Т.е. у вас там тысячи unix пользователей и это не вызывает никаких проблем?
Dimanych, 64 бит ОС имеет 2 в 43 степени user_id пространство, не в это упрётся ;)
Если честно, то не вижу смысла в такой грамоздкой системе, стабильность и надёжность которой тоже сомнительна. Да, удобство в управлении безусловно плюс, но с другой стороны минус одна точкка доступа со стороны основного пользователя. Учитывая то, что многие вебмастеры используют вечно дырявый Windows Commander или что то подобное, то безопаснотсь в такой системе не на много выше чем на обычном шарике. Нет ничего лучше, как реальный отдельный unix пользователь.
Спасибо, Алексей, а покажите-ка getfacl alexeyxt.beget.tech
И скриншот у меня выдает 403.
Прошу прощения
# file: index.php
# owner: alexeyxt
# group: newcustomers
user::rw-
user:alexeyxt:rwx
user:alexeyxt__alexeyxtjbegetjtec__yq:rwx
group::---
group:newcustomers:---
group:alexeyxt:--x
mask::rwx
other::---
---------- Добавлено 04.04.2017 в 23:24 ----------
Спасибо за информацию.
Примерно также реализовывал в своей системе, тоже на базе itk, но меня остановило создание unix-юзверя для каждого домена, поэтому ограничился созданием отдельного www пользователя на аккаунт. Конечно это не даёт той межсайтовой защиты о которой мы говорим, но всё таки это лучше чем работа всего аккаунта от одного пользователя.
Т.е. у вас там тысячи unix пользователей и это не вызывает никаких проблем?
Пример сервера для free хостинга
15879
ну как сказать не вызывает, конечно проблем было много, но все они решаемы. Внедряли мы эту систему более полугода и в процессе внедрения было очень много проблем =)
---------- Добавлено 04.04.2017 в 23:28 ----------
Dimanych, 64 бит ОС имеет 2 в 43 степени user_id пространство, не в это упрётся ;)
Если честно, то не вижу смысла в такой грамоздкой системе, стабильность и надёжность которой тоже сомнительна. Да, удобство в управлении безусловно плюс, но с другой стороны минус одна точкка доступа со стороны основного пользователя. Учитывая то, что многие вебмастеры используют вечно дырявый Windows Commander или что то подобное, то безопаснотсь в такой системе не на много выше чем на обычном шарике. Нет ничего лучше, как реальный отдельный unix пользователь.
не кто не мешает создавать отдельного пользователя ftp/ssh для каждого сайта. то есть это выбор каждого пользователя. Так же не нужно забывать про многосайтовые системы или сайты которым нужны общие данные. Вопрос исключительно в гибкости и удобстве.
Повторюсь, если у Вас свой VPS - это одно дело, если Вы клиент шаред хостинга - изоляция сайтов среди ТОП10 хостингов есть только у нас.
---------- Добавлено 04.04.2017 в 23:57 ----------
тест прикрепления картинки
Повторюсь, если у Вас свой VPS - это одно дело, если Вы клиент шаред хостинга - изоляция сайтов среди ТОП10 хостингов есть только у нас.
Я понимаю пользу такого решения, в данный момент это будет пользоватся спросом, так как экономическая ситуация заставляет вебмастеров экономить. У них множество сайтов и само собой дырявые скрипты. Но изоляция не решает всех проблем, так как зараженные сайты генерируют огромные нагрузки и опасны другим серверам. То есть чистить всё равно надо.
Неизвестна остальная часть системы, по этому сложно что то понять.
По сути, всё это можно рещить с помошью mod_privileges.