REG.RU отправил документ в ФАС

Вслед за жалобами, направленными в КЦ и РКН, крупнейший российский регистратор и хостинг-провайдер REG.RU отправил документ в Федеральную антимонопольную службу для инициирования проверки ООО «Бегет».

Согласно тексту жалобы, ключевые нарушения — это непредоставление корректной информации о факте сотрудничества с Регистратором REG.RU в момент, когда ООО «Бегет» было его посредником, а также некорректно предоставленная информация о порядке оказания услуг клиентам, когда после аккредитации «Бегет» компании стали прямыми конкурентами. Также в работе бывшего посредника обнаружены факты, свидетельствующие о введении в заблуждение клиентов с целью перевода доменных имён администраторов на обслуживание к себе, как к аккредитованному регистратору, от аккредитованного регистратора REG.RU. Кроме того, после расторжения договора между ООО «Бегет» и ООО REG.RU, контрагент предоставлял искажённую информацию об обстоятельствах случившегося.

REG.RU требует у ФАС провести проверку деятельности ООО «Бегет» на предмет соответствия требованиям антимонопольного законодательства, принять меры, направленные на пресечение деятельности ООО «Бегет», нарушающей конкурентное законодательство, а также привлечь компанию к ответственности за многочисленные нарушения в сфере антимонопольного законодательства.

Позиция нашей компании полностью прозрачна. Все документы, направляемые в компетентные органы, мы также публикуем в открытом доступе на разных площадках, чтобы клиенты могли с ними ознакомиться. Оценку действиям нашего бывшего посредника дадут профильные контролирующие организации
генеральный директор REG.RU Алексей Королюк

Полный текст жалобы в ФАС — regru062018.pdf

REG.RU требует у РКН проверить деятельность бывшего посредника Beget

Мы продолжаем подготовку обращений в профильные контролирующие организации с целью проведения проверок деятельности компании ООО “Бегет”. В четверг, 08.06.2018 была подана жалоба в Координационный центр национального домена сети Интернет. Вторая жалоба отправилась в Роскомнадзор 09.06.2018. Наш следующий шаг — ФАС.

Мы полагаем, что случившаяся ситуация для многих непонятна и кажется нелогичной в каких-то деталях, но с ходом истории, новыми раскрываемыми данными станет хрестоматийной и понятной во всех аспектах.






Расторжение партнерского договора с Reg.ru

Сегодня компания REG.RU пошла на шаг, который принес большие неудобства нашим пользователям. В одночасье они отключили нас от своего API, лишив возможности наших клиентов управлять своими доменами через нас.

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

Для всех доменов .RU/.РФ, которые находятся у нас на партнерских договорах с регистраторами, перенос к нам, как к регистратору, мы сделали бесплатным! Для переноса домена к нам вам нужно получить только Auth-код у текущего регистратора и ввести его в нашей панели.

О том, как это сделать, есть информация на нашем сайте.

Если у вас возникнут вопросы или понадобится помощь — мы предоставим ее по всем каналам связи с нами.

Что произошло?
В рамках регистрации доменов .RU/.РФ наша компания работала с компанией REG.RU, согласно партнерскому договору №485 от 07.10.2008. За это время мы стали одним из крупнейших хостинг-провайдеров и, полагаем, одним из крупнейших партнеров компании Рег.ру, а объем наших ежемесячных регистраций превысил 10 тысяч в месяц.

В 2016 году мы приняли решение стать аккредитованным регистратором в зонах .RU/.РФ, для того, чтобы наш клиент получал максимально качественные услуги. Мы успешно прошли аккредитацию и приступили к регистрации доменных имен как самостоятельный регистратор.


В статье на Хабре мы подробно описали причины, которые побудили нас стать регистратором:
  • Были случаи разделегирования доменов/не продления доменов, при том что API отдавала успешный код.
  • Частые проблемы с API.
  • Невозможность решать юридические вопросы напрямую с клиентами.
  • Желание предоставлять максимально качественный сервис и нести прямую ответственность перед клиентом.

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

Технические сложности
В письмах, которые reg.ru разослали клиентам, есть ссылка на личный кабинет, но самих учетных данных для входа нет. Фактически даже это действие было подготовлено не корректно с технической точки зрения. Всем, кто пострадал от действий REG.RU мы окажем всеобъемлющую помощь, чтобы вы могли продлить ваш домен вовремя.
Постараемся в ближайшее время решить данную проблему всеми возможными способами!

Долгожданная услуга VPS!

Рады сообщить, что мы реализовали услугу VPS, и теперь в Beget вы можете создать собственный виртуальный выделенный сервер!



VPS — это ваш личный виртуальный сервер с полным доступом и настраиваемой конфигурацией.


Самостоятельное администрирование, отсутствие ограничений на устанавливаемое ПО позволяет выйти за пределы возможностей виртуального хостинга


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






Чтобы начать пользоваться VPS:
  • Перейдите на вкладку VPS в панели управления или создайте новый аккаунт
  • Выберите подходящий тариф


Задайте название и параметры аутентификации


Нажмите кнопку «Создать сервер» и через несколько секунд сервер уже готов к работе!

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

Используйте и другие наши функции в панели управления
Заметим, что в панели управления останутся и другие важные и полезные функции, как регистрация доменов, управление DNS, настройками аккаунта, управление почтой и другие.

Подробнее о работе с VPS — в нашем руководстве по панели управления
beget.com/ru/manual/vps
cp.beget.com/vps
beget.com/ru/order/optimal

Если у вас есть предложения о том чего еще следует добавить, напишите нам и мы постараемся учесть все ваши пожелания.

Вылечим ваш сайт от вирусов

Мы сделали большой шаг в сторону лечения ваших сайтов от вредоносного кода. Теперь на аккаунтах виртуального хостинга вы можете вылечить зараженные файлы вашего сайта прямо в панели управления!


Таким образом, мы сможем решить важные для вас задачи по поиску и удалению критических уязвимостей:
  • Обнаружение вредоносных скриптов в файлах: вирусные вставки, веб-шеллы, бэкдоры, фишинговые страницы, дорвеи, спам-скрипты и другие
  • Автоматизированное лечение обнаруженных вредоносных скриптов: вставки аккуратно удаляются без повреждения работоспособности сайта, а вредоносные файлы удаляются
  • Регулярное обновление базы вредоносных скриптов: поддержка «вредоносов», написанных на php, perl, python, javascript, html, а также shell скрипты и опасные конфигурации
  • Сохранение резервных копий измененных скриптов
  • Поиск публичных уязвимостей в скриптах php
  • Лечение сайтов на любых CMS и фреймворках, написанных на php

Антивирус разработан компанией «Ревизиум».

Как работает антивирус:
  • Мы проводим периодическое сканирование ваших сайтов; каждый сайт будет проверен не реже чем раз в 14 дней
  • Если будут найдены вирусы, мы уведомим вас в панели управления
  • Все изменения после лечения можно отменить до начала следующего сканирования антивирусом

Как вылечить сайты:
Кликните по уведомлению о наличии вируса


Нажмите на кнопку «Вылечить» в появившемся окне


Статус лечения и откат изменений доступны в разделе Сервисы

Поддержка PHP 7.2

Мы добавили поддержку PHP 7.2

Из важных нововведений можно отметить:
  • Добавлена возможность перегружать абстрактные функции (RFC)
  • Добавлена возможность конвертировать нумерованные ключи при приведении типов object/array (RFC)
  • Запрещено передавать null в качестве параметра для get_class() (RFC)
  • Возможность расширения типа параметра (RFC)
  • Object typehint (RFC)
  • В ядро PHP добавлена Libsodium (RFC)
  • HashContext as Object (RFC)



Также хотим обратить внимание, что версия 5.4 перестала поддерживаться 3 сентября 2015 года, а версия 5.5 21 июля 2016 года. Они могут содержать критические уязвимости, которые не будут исправляться, а также значительно уступают по скорости работы и потребляемым ресурсам более новым версиям.

1 июля все сайты, которые работают на версиях 5.4 и 5.5, будут переведены на 5.6. Проверьте работу своих сайтов на новых версиях PHP, нажав на кнопку или и выбрав нужную версию.


Поддержка устаревших версий на нашем хостинге будет прекращена 1 августа.

Список изменений, ломающих обратную совместимость:
php.net/manual/ru/migration55.incompatible.php
php.net/manual/ru/migration56.incompatible.php

Дружим gRPC с долгоживущим проектом, PHP и фронтендом



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

Мы расскажем о том, как объединить внешнее API с внутренним и что делать, если у вас много кода на PHP, но хочется воспользоваться преимуществами gRPC.

Сейчас очень много говорят про микросервисы и SOA в целом. Наша инфраструктура не исключение: ведь мы занимаемся хостингом и наши сервисы позволяют управлять почти тысячей серверов.

Со временем сервисов в нашей системе стало появляться все больше: стали регистратором доменов — выносим регистрацию в отдельный сервис; метрик с серверов стало очень много — пишем сервис, который делает выборки из ClickHouse / InfluxDB; Нужно сделать эмулятор запуска задач «как через Crontab»; для пользователей — пишем сервис. Наверное, это многим будет знакомо.

Входящих задач в разработке много. Количество различных сервисов растет плавно и, вроде бы, незаметно. Заранее учесть все будущие нюансы невозможно, поэтому на смену одним API приходили другие, более лучшие. Но настал день, когда стало очевидно, что у нас развелось слишком много протоколов:


Чем больше становилось сервисов и связей между ними, тем дольше и сложнее было решать задачи: требовалось изучить несколько разных API, написать к ним клиенты и только потом приступить к реальной работе.

Ах, да… еще ведь документация нужна. Иначе в чатиках происходят такие диалоги:
— Ребят, как мне получить баланс пользователя из биллинга?
— Сделай вызов в billing/getBalance(customerId)
— А список услуг как получить?
— Не помню, поищи нужный контроллер в
Короче говоря, зародилась мечта о волшебном едином стандарте и технологии для создания сетевых API, которые решат все проблемы и сэкономят нам вагон времени.

Формируем требования
Немного подумав, мы составили свой небольшой список требований:
  • Используемый способ описания API должен быть декларативным
  • Результат должен быть однозначным и человеко-понятным: нужно проводить code review
  • Нужна возможность описывать как успешный flow, так и ошибки. Причем это должно делаться явно для каждого метода
  • На основе описания нужно генерировать как можно больше скучного кода для клиента и сервера

Из коробки он удовлетворял почти всем нашим требованиям. Если в двух словах:
  • Декларативное описание методов и структур данных
  • Он очень читабельный и простой. По получившимся .proto-файлам легко проводить code review. Синтаксис IDL близок к популярным ЯП
  • Завезены генераторы под большинство популярных ЯП (но есть нюанс. О нем ниже)
  • gRPC — просто механизм RPC без каких-либо строгих требований к организации API. Это дает возможность разработать собственные принципы и гайдлайны с учетом накопленного опыта

Однако, идеальных технологий не существует. Для нас возникло несколько камней преткновения:
  • Мы активно используем PHP и он не умеет в сервер gRPC;
  • Наш фронтенд по-прежнему ожидает привычный HTTP. На текущий момент мы были вынуждены «проксировать» запросы фронтенда через отдельное приложение, формирующее правильные запросы к внутреннему API. В подавляющем большинстве случаев это лишняя скучная работа. Хотелось бы внутри нашей системы все отдавать через один протокол с автоматической конвертацией в HTTP для фронтенда.
К счастью, мы достаточно легко решили эти проблемы. Далее я буду предполагать, что читатель знаком с gRPC. Если нет — лучше сначала обратиться к упомянутой выше статье.

И так далее, много технической информации
Надеюсь на Хабре топик не удалится, т.к. сохранять для Истории рынка не вижу смысла, черзе 5 лет устареет все. Просто запомним факт, что была такая новость ;)
habr.com/company/beget/blog/348008/