PBX-Sphere Online — Как мы это сделали

27 августа 2015 года состоялся релиз облачной АТС PBX-Sphere Online 2.0.0.

Пожалуй, стоит начать с того, что, изначально, в 2011 году, проект «PBX-Sphere» планировался как серверное проприетарное программное обеспечение для СМБ, которое должно было решить проблему имплементации и сопровождения сложных VoIP технологий в простом и понятном программном продукте. И, вот, 1 июля 2011 года, вышел первый стабильный релиз PBX-Sphere Enterprise 1.0. Тогда мы получили много бета-тестеров по всему миру и несколько крупных клиентов. Вплоть до 15 октября 2013 года, мы выпустили еще 3 стабильные версии PBX-Sphere Enterprise, включая последнюю — 2.2.0. Еще, в течение полугода, мы активно продвигали наш продукт крупным клиентам. В итоге, по состоянию на середину 2014 года, у нас было менее 1000 активных конечных пользователей. Нельзя сказать, что это был провал, но мы ожидали гораздо лучшего результата.

И тогда, проанализировав с лихвой изменившийся за несколько лет рынок, мы поняли, что нужно переходить к моделе «Software as a Service» (SaaS), к облачным технологиям. За несколько месяцев мы разработали новый концепт продукта и приступили к рефакторингу PBX-Sphere Enterprise в PBX-Sphere Online.

Первым же вопросом стал выбор платформы развертывания системы. После некоторых исследований и экспериментов, мы решили выбирать из трех: Hetzner Dedicated Servers, Microsoft Azure, кластер из собственных серверов.

Расскажу подробнее:

Hetzner Dedicated Servers
Казалось, это идеальное решение… Физические сервера с Intel Core i7, 48 Гб RAM, 2 x 2 Tb HDD в RAID1 и FlexiPack — за 75 евро в месяц с гарантированной пропускной способностью в 200 Мбит/с. Чего еще желать?! Мы начали развертывание. По-началу, все было отлично. Мы развернули десятки серверов с CentOS 7 под разные роли продакшн деплоймента PBX-Sphere Online. Нагрузочное тестирование показало отличнейшие результаты. Воодушевленные таким положением дел, мы открыли PBX-Sphere Online 1.0 на такой конфигурации для промышленного использования для одного крупного клиента. Работало все отлично. Было несколько жалоб на то, что во время разговора могут наблюдаться кратковременные «замирания» звука. Мы это списывали на нестабильность интернет-подключения пользователей, так как никаких потерь в канале с нашей стороны не было обнаружено, да и Load Average на наших серверах был минимальным, как и размер использованной оперативной памяти и Swap. Но, вскоре, мы начали замечать, что кратковременные «замирания» звука наблюдаются почти всегда при использовании интернета по 3G сети, причем несколько раз за минуту, независимо от используемых кодеков. Мы решили разобраться в чем дело, ведь такой проблемы никогда не возникало при использовании тестовых серверов, расположенных у нас в офисе. Каково же было наше удивление, когда мы обнаружили, что пограничное оборудование Hetzner некорректно использует шейпирование, в результате чего, RTP пакеты ставятся в очередь на доставку к нашим серверам и обратно с задержкой, которая выше TTL пакетов RTP. Получается, что если у пользователя хороший интернет-канал и выбран TCP протокол обмена, то никакой проблемы, как-бы, нет. Неделя переговоров с саппортом Hetzner не дала никаких результатов. Дальше — больше. В течение 3 дней на наших серверах отказали 5 жестких дисков! Причем, 2 из них — на центральном SQL сервере. Благо, был дублирующий SQL сервер, так что для пользователей это прошло незаметно. На вопрос «WTF?» саппорт Hetzner ответил, что это нормально и в порядке вещей. После смерти еще двух жестких дисков и непрекращающихся сетевых проблем, стало понятно, что нужно искать другую платформу.

Microsoft Azure
Первые впечатления от Microsoft Azure можно описать тремя словами: круто, необычно, дорого. Это не просто виртуальные машины в привычном понимании этого слова, а целая отдельная среда со своими законами и тонкостями. Мы решили попробовать. Развернули PBX-Sphere Online и запустили ее в тестовом режиме. Долго присматривались, делали множество как нагрузочных тестов всех систем, так и тестировали в реальных условиях. Ждали когда же проявятся проблемы, с которыми мы столкнулись на Hetzner. Этого не произошло, никаких «замираний» звука не было. Но сразу была очевидна потенциальная проблема с IP-адресами. Как известно, в Azure есть 3 типа IP-адресов: локальный IP-адрес экземпляра и 2 внешних IP-адреса (VIP и PIP). Работа VIP-адреса похожа на работу домашнего роутера, когда на WAN интерфейс приходит внешний IP-адрес и чтобы «из мира» попасть во внутреннюю сеть, нужно «пробросить» определенный порт. Такой же механизм для VIP в Azure. Это приемлемо для всех экземпляров развертывания PBX-Sphere Online, кроме серверов Backend, в работе которых нужен весь диапазон портов для непосредственной передачи голоса во время звонка (RTP). Azure допускает «проброс» максимум 150 портов на 1 экземпляр. Поэтому, для RTP нужно использовать другой тип внешнего IP-адреса — PIP, все порты которого попадают в экземпляр. Это работает. Но VIP и PIP-адреса — динамические, по-умолчанию. То есть, после перезагрузки сервера VIP/PIP адрес может измениться. И если VIP-адрес легко определить по DNS, то PIP адрес можно определить только изнутри сервера, выполнив внешний запрос. Как же тогда настроить свою доменную зону?! Для авторизации конечного оборудования пользователя можно использовать доменное имя, которое является псевдонимом (CNAME) хоста экземпляра. Но PIP адрес Azure в DNS не предоставляет. Поэтому, один и тот же экземпляр производит авторизацию пользователей с использованием VIP-адреса, а голос (RTP) направляется через PIP-адрес. Для такой реализации, после каждой перезагрузки каждый backend-экземпляр должен запрашивать извне свой PIP-адрес и уже потом производить перенастройку для RTP. Благо, для RTP отдельная запись в DNS не требуется. Вообще, такой механизм ужасно неудобен, т.к. сервер напрямую зависит от внешнего ресурса, который сообщает IP-адрес. Как закрепить за экземпляром PIP-адрес, я не нашел. Еще один неприятный момент, это когда Microsoft выполняет техническое обслуживание в своих дата-центрах и, как следствие, часть серверов становится недоступной. Спасает избыточное резервирование вычислительных ресурсов в разных регионах, благодаря чему такие действия остаются прозрачными для наших пользователей и без потери качества. Но достигается это за счет наших прямых затрат, поскольку, мы должны обеспечить такое резервирование за свой счет. Во всем остальном, качество сервиса просто отличное, но, как я уже упоминал, довольно дорогое.

Собственный кластер
Этот вариант просчитывался только теоретически. Дело в том, что большая часть команды PBX-Sphere находится в Украине, а остальная — в России и Болгарии. PBX-Sphere ориентируется не только на страны СНГ, но, в большей части, на США и страны ЕС. Поэтому, как вы понимаете, ни Россия, ни Украина, ни Болгария для размещения серверов не подходит. А размещать сервера в других странах и обеспечивать их поддержку частыми перелетами технических специалистов очень накладно, даже с учетом возможного хеджирования валютных рисков. Возможно, в будущем мы вернемся к рассмотрению этого варианта.

Благодаря поддержке Microsoft, мы стали участниками программы BizSpark, по которой, в числе прочего, нам предоставляются сервисы Azure бесплатно на сумму 750$ в месяц, сроком на 2 года. Благодаря этой поддержке, а также прямым контактам с инженерами Azure, мы выбрали именно эту платформу для нашей PBX-Sphere Online. И, пока что, очень довольны этим.

И, вот, 27 августа 2015 года мы обновили PBX-Sphere Online на платформе Microsoft Azure до версии 2.0.0 для всех пользователей и впервые открыли публичную регистрацию. Сейчас каждому новому аккаунту предоставляется 25 бесплатных лицензий.

www.pbxsphere.com

На данный момент, интерфейс PBX-Sphere Online рассчитан на advanced пользователей. Но уже в этом году мы будем радовать вас новейшими инновационными решениями в области интернет-телефонии.

Будем искренне рады советам и конструктивной критике.

Успехов!

Сергей Вакула
Технический директор PBX-Sphere Online
Aspanta Limited

www.pbxsphere.com
facebook.com/pbxsphere

ссылка на оригинал статьи http://habrahabr.ru/post/266169/

Очередной развод пользователей от имени банков

Здравствуй, уважаемое сообщество

Сегодня обнаружил вот такую вот интересную штукенцию
image
image

Пользователю под предлогом выигрыша, предлагают ввести свои данные банковской карты.
Стоит только догадываться, что происходит далее:)

Сервер расположен в Германии, в дата центре «Hetzner».

ссылка на оригинал статьи http://habrahabr.ru/post/266167/

Строим real-time веб-приложения с RethinkDB

От переводчика: Совсем недавно узнал про эту довольно интересную базу данных и как раз наткнулся на свежую статью. На Хабре нет почти ни слова о RethinkDB, в связи с чем было решено сделать этот перевод. Добро пожаловать под кат!

image

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

RethinkDB — это open source база данных для real-time приложений. Она располагает встроенной системой уведомления об изменениях, которая беспрерывно транслирует обновления для вашего приложения. Вместо постоянного запрашивания новых данных, позвольте базе данных самой отправлять вам последние изменения. Возможность «подписываться» на потоковые обновления может сильно упростить архитектуру вашего приложения и работу с клиентами, поддерживающими постоянный коннект к вашей серверной части.

RethinkDB является безсхемным хранилищем JSON документов, но также поддерживает и некоторые особенности реляционных БД. RethinkDB также поддерживает кластеризацию, что делает её очень удобной в расширении. Вы можете настроить шардинг и копирование через встроенный веб-интерфейс. Последняя версия RethinkDB также включает в себя автоматический «fail-over» для кластеров с тремя и более серверами. (прим. переводчика: подразумевается возможность продолжения работы с БД в случае падения одного из серверов.)

Язык запросов в RethinkDB, который называется ReQL, нативно встраивается в код на том языке, на которым вы пишите своё приложение. Если, например, вы кодите на Python, то при написании запросов к БД будете использовать обычный для Python синтаксис. Каждый запрос составляется из функций, который разработчик собирает в цепочку, чтобы точно описать необходимую операцию.

Несколько слов о ReQL
RethinkDB содержит в себе таблицы, в которых хранятся традиционные JSON документы. Структура самих JSON объектов может иметь глубокую вложенность. Каждый документ в RethinkDB имеет свой основной ключ (primary key) — свойство «id» с уникальным для таблицы-родителя значением. Ссылаясь на primary key в своём запросе вы можете получить конкретный документ.

Написание ReQL запросов в приложении довольно похоже на использование API конструктора SQL запросов. Ниже, на языке JavaScript, представлен простой пример ReQL запроса для определения количества уникальных фамилий в таблице users:

r.table("users").pluck("last_name").distinct().count() 

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

  • table запрашивает определнную таблицу в базе данных
  • pluck достаёт определенное свойство (или несколько свойств) из каждой записи
  • disctinct убирает повторяющиеся значения, оставляя только по одному уникальному
  • count подсчитывает и возвращает количество полученных элементов

Традиционные CRUD операции также просты. ReQL включает в себя функцию insert, которую можно использовать для добавления новых JSON документов в таблицу:

r.table("fellowship").insert([    { name: "Frodo", species: "hobbit" },    { name: "Sam", species: "hobbit" },    { name: "Merry", species: "hobbit" },    { name: "Pippin", species: "hobbit" },    { name: "Gandalf", species: "istar" },    { name: "Legolas", species: "elf" },    { name: "Gimili", species: "dwarf" },    { name: "Aragorn", species: "human" },    { name: "Boromir", species: "human" } ]) 

Функция filter достаёт документы, которые соответствуют определённым параметрам:

r.table("fellowship").filter({species: "hobbit"}) 

Вы можете добавлять в цепочку такие функции как update или delete, чтобы выполнить определенные операции над документами, возвращенными из filter:

r.table("fellowship").filter({species: "hobbit"}).update({species: "halfling"}) 

ReQL включает более 100 функций, которые можно комбинировать для достижения необходимого результата. Есть функции для управления потоками, изменения документов, агрегации, записи и т.д. Также существуют функции, «заточенные» под выполнение стандартных операций со строками, числами, метками времени и геопространственными координатами.

Существует даже команда http, которую можно использовать для получения данных из сторонних Web API. В следующем примере показано как можно использовать http для получения постов с Reddit:

r.http("http://www.reddit.com/r/aww.json")("data")("children")("data").orderBy(r.desc("score")).limit(5).pluck("score", "title", "url") 

После того как посты получены, они сортируются по очкам и затем отображаются определённые свойства лучшей пятёрки постов. Используя ReQL «на полную мощность», разработчики могут выполнять действительно сложные манипуляции с данными.

Как работает ReQL

RethinkDB client libraries (далее «драйвера») отвечают за интеграцию ReQL в тот язык программирования, на котором ведется разработка приложения. Драйвера внедряют функции для всевозможных запросов, поддерживаемых базой данных. ReQL выражения расцениваются как структурированные объекты, которые похожи на абстрактное синтаксическое дерево. Но для того чтобы выполнить запрос, драйвера переводят эти объекты запроса в специальный формат "RethinkDB’s JSON wire protocol format", в котором затем передаются в базу данных.

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

В следующем примере показано как выполнить запрос в RethinkDB из-под Node.js с установленным драйвером ReQL для JavaScript. Этот запрос достаёт всех хафлингов (halflings) из таблицы fellowship и отображает их в консоли:

var r = require("rethinkdb");  r.connect().then(function(conn) { return r.table("fellowship")          .filter({species: "halfling"}).run(conn)    .finally(function() { conn.close(); }); }) .then(function(cursor) { return cursor.toArray(); }) .then(function(output) { console.log("Query output:", output); }) 

Модуль rethinkdb обеспечивает доступ и использование драйверов RethinkDB. Вы можете использовать этот модуль для составления и отправки запросов к базе. Показанный выше пример использует промисы для асинхронного контроля потока, однако драйвера поддерживают также и работу с обычными коллбэками.

Метод connect устанавливает соединение, который затем используется функцией run. для выполнения запроса. Сам по себе запрос возвращает курсор, который является чем-то вроде открытого окошка в содержимое базы. Курсоры поддерживают «ленивую выборку» (lazy fetching) и предлагают эффективные способы перебора больших объёмов данных. В примере выше я просто решил конвертировать содержимое курсора в массив, так как размер результата относительно мал.

Несмотря на то, что ReQL запросы пишутся в вашем приложении как обычный код, они выполняются на сервере БД и возвращают полученные результаты. Интеграция настолько бесшовна, что новички часто путаются в каком месте кода граница между их приложением и работой с БД.

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

function paginate(table, index, limit, last) {    return (!last ? table : table       .between(last, null, {leftBound: "open", index: index}))    .orderBy({index: index}).limit(limit) } 

Еще одно примечательное преимущество ReQL в том, что он предлагает также работу и с привычным SQL и хорошо застрахован от обычных атак-инъекций. Вы с легкостью можете включать в свои запросы внешние данные не беспокоясь о необходимости рискованной конкатенации строк.

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

Создание real-time веб-приложений с помощью changefeeds

RethinkDB обладает встроенной системой уведомления об изменениях, которая значительно упрощает разработку приложений, работающих в режиме реального времени. Если вы вставите функцию changes в конец цепочки, то в качестве результата запроса будет запущен беспрерывный поток, отражающий все происходящие изменения. Такие потоки называются changefeeds (далее «ченджфид»).

Привычные нам запросы к БД хорошо подходят к традиционной веб-модели «запрос/ответ». Однако, постоянное опрашивание сервера не практично для real-time приложений, использующих постоянное подключение к серверу или потоковую передачу данных. Ченджфиды предоставляют альтернативу обычному опрашиванию, а именно возможность постоянной подачи обновленных результатов в приложение.

Вы можете прикрепить ченджфид прямо к таблице, чтобы отслеживать любые изменения её содержимого. Вы также можете использовать ченджфиды с более сложными запросами, чтобы получать обновления только необходимых вам данных. Например, можно прикрепить ченджфид к запросу, в котором используются функции orderBy и limit, чтобы создать динамическую таблицу рекордов для многопользовательской игры:

r.table("players").orderBy({index: r.desc("score")}).limit(5).changes() 

Игроки сортируются по очкам и затем выводится первая пятёрка. Как только появятся какие-то изменения в этой пятёрке лидеров, ченджфид отправит вам обновлённые данные. Даже если игрок, который изначально не был в ТОП-5, наберёт достаточно очков и вытеснит другого игрока из пятёрки — ченджфид сообщит об этом и передаст все необходимые данные для обновления списка.

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

Когда вы выполняете запрос с командой changes, — будет возвращён курсор, который останется открытым навсегда (помните про окошко, да?). Курсор будет отображать новые изменения как только они становятся доступными. Ниже можно увидеть пример, показывающий как можно получать обновления из ченджфида в Node.js:

r.connect().then(function(conn) {    return r.table("data").changes().run(conn); }) .then(function(cursor) {    cursor.each(function(err, item) {          console.log(item);    }); }); 

Работа курсора ченджфида выполняется в фоновом режиме, а значит ваше приложения не блокируется. В исконно асинхронных окружениях, таких как Node.js, вам вовсе не нужно принимать какие-то дополнительные меры для корректной работы. Если вы работаете с другими языками, то вероятно понадобится установка фреймворков для асинхронного кода, или же ручное внедрение потоков. Официальные RethinkDB драйвера для Python и Ruby поддерживают такие популярные и широко используемые фреймворки как Tornado и EventMachine.

На данный момент, команда changes работает с функциями get, between, filter, map, orderBy, min и max. Поддержка других видов запросов запланирована на будущее.

При создании real-time веб-приложения с помощью RethinkDB, можно использовать WebSockets для трансляции обновлений на front-end. А такие библиотеки как Socket.io удобны в использовании и упростят этот процесс.

Ченджфиды особенно полезны для приложений, рассчитанных на горизонтальное расширение. Когда вы распределяете нагрузку между несколькими экземплярами своего приложения, то обычно прибегаете к помощи дополнительных механизмов, таких как очереди сообщений или in-memory db, чтобы распространить обновления на все сервера. RethinkDB переносит этот функционал на уровень вашего приложения, уплощая его архитектуру и избавляя вас от необходимости использования дополнительной инфраструктуры. Каждый экземпляр приложения подключается непосредственно к БД для получения новых изменений. Как только обновления доступны, каждый сервер транслирует их соответствующим WebSocket клиентам.

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

Масштабирование и управление кластером RethinkDB

RethinkDB является распределённой базой данных, нацеленной на кластеризацию и простое расширение. Чтобы добавить новый сервер к кластеру, достаточно просто запустить его из командной строки с опцией —join и указанием адреса уже существующего сервера. Если у вас в распоряжении кластер с несколькими серверами, вы можете настраивать шардинг и копирование индивидуально для каждой таблицы. Любые настройки и особенности, работающие на одном экземпляре БД будут в точности как надо и на кластере.

Сервер RethinkDB включает в себя также и веб-интерфейс администратора, открыть который вы можете прямо в браузере. С помощью этого интерфейса можно легко управлять и мониторить работу кластера. Вы даже можете настроить шардинг и копирование в несколько кликов.

RethinkDB позволяет применять ReQL-подход для конфигурации кластера, который идеально подходит для тонкой настройки и автоматизации. ReQL включается в себя простую функцию reconfigure, которую можно привязать к таблице для установки настроек шардинга. Также кластер предоставляет большую часть внутренней информации о своём состоянии и настройках через набор специальных таблиц в RethinkDB. Вы можете делать запросы к системным таблицам, чтобы изменять настройки или получать информацию для мониторинга. Практически весь функционал, предоставляемый через веб-интерфейс, построен на ReQL API.

Вы даже можете использовать ченджфиды в связке с ReQL monitoring API, чтобы получать поток данных о сервере. Например, можно было бы создать свой инструмент для мониторинга, который прикрепляет ченджфид к системной таблице со статистикой и в режиме реального времени передаёт данные для построения графика нагрузки чтения/записи.

RethinkDB 2.1, вышедшая недавно, имеет встроенную поддержку автоматического fail-over’a. Новый функционал улучшает доступность кластеров и уменьшает риск падения сервера БД. Если основной (primary) сервер неисправен, то остальные, вторичные рабочие сервера «выбирают» новый primary, который будет выполнять эту роль до тех пор, пока неисправный сервер заработает или будет удалён из кластера.
Поломки железа, или перебои в работе сети теперь не влияют на доступность данных до тех пор, пока большая часть серверов находится онлайн.

Установка RethinkDB

RethinkDB работает под Linux и MacOS X. Версия для Windows находится в активной разработке и еще не доступна для загрузки. В документации RethinkDB детально описан процесс установки. Мы подготовили APT и Yum репозитории для пользователей Linux, а также установщик для OS X. Вы также можете установить RethinkDB с помощью Docker или скомпилировать исходный код с Github. Чтобы в этом разобраться, вам поможет наша 10-минутная инструкция.

Оригинал: ссылка

ссылка на оригинал статьи http://habrahabr.ru/post/266085/

Как Webnames снимает с делегирования домены

Вчера случилось страшное в виде сообщения от WebNames "Домен opentown.org заблокирован вследствие нарушения правил регистрации и/или использования доменного имени"

По многолетнему опыту зная оперативность ответов службы поддержки на электронные письма, дозваниваемся и пытаемся узнать причину блокировки, выясняется, что пришло какое-то письмо от ФСБ. Все попытки узнать у сотрудника техподдержки какой же все таки пункт правил мы нарушили уперлись в глухую стену в режиме «точно не знаю, но в правилах есть».

Через 2 часа удалось получить от WebNames сканкопию письма из Лубянки, составлял которое либо шутник школьник, а не ФСБшник, либо в службу информационной безопасности ФСБ начали набирать школьников.

image

Первое, что бросилось в глаза, это гриф «конфиденциально», это что же получается, WebNames мне передал конфиденциальную информацию полученную от ФСБ? Но на деле всё проще, никакого грифа «конфиденциально» у ФСБ нет, есть разные уровни конфиденциальной информации от нелепого ДСП до «совсекретно», так что «гриф» по ходу дело изобретение школьника.

Второе, что насторожило — это печать, она там есть, но вот понять, печать ли это ФСБ или ООО «чижик-пыжик» не представляется возможным.

Вывод: если Ваш конкурент зарегистрирован на WebNames, можете состряпать такую вот бумажку, отправить горе-регистратору и на месяц забыть о конкуренте.

Но даже допустим это опус от ФСБ. Сама фраза "в действиях администраторов сайтов усматриваются признаки ст. 283 УК РФ" — это нечто. Кто не в курсе, это страшная статья «Разглашение государственной тайны», но судя по всему составлявший бумагу школьник не удосужился нагуглить содержимое этой статьи, иначе бы знал, что чтобы разгласить гостайну, надо сначала иметь доступ к гостайне, которого за редким исключением у вебмастеров нет… Более того, текст который был там опубликован по сети гуляет уже больше года и назвать его тайной язык не поворачивается. Но это лирика.

Повторно задаем вопрос техподдержке Webnames, какие всё таки правила мы нарушили с просьбой указать пункт правил, и в ответ получаем ссылку на правила регистрации доменных имен в зоне .RU и.РФ. Напоминаю, сняли с делегирования домен в зоне OPENTOWN.ORG

Попытки добиться от техподдержки ответа на вопрос, какое отношение правила зоны RU имеют к домены в зоне ORG пока не увенчались успехом, хотя еще есть надежда, что в штате компании есть хоть один юрист чей мозг не изуродован ЕГЭ.

Интереса ради изучаем эти правила, в частности п.5.5 по которому любого обладателя домена, как теперь выясняется не только в зонах RU и РФ, можно без суда и следствия поставить к стенке лишить домена.

5.5. Делегирование домена может быть прекращено регистратором на основании письменного решения
руководителя (заместителя руководителя или приравненного к нему должностного лица) органа,
осуществляющего оперативно-розыскную деятельность.

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

В нашем же случае в письме есть лишь предположение и просьба, чем отличается предположение от решения, а главным образом просьба от требования, думаю объяснять никому не надо. Но по всей видимости для господина Шарикова любая просьба ФСБ это приказ.

Начали копать дальше, нашлось разъяснение по порядку применения п. 5.5 Правил.

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

  1. Краткое указание информации, которая, по мнению лица, вынесшего решение, размещена с нарушением действующего законодательства;
  2. Квалификация согласно УК РФ или КоАП РФ правонарушения, условия для совершения которого создаются действиями администратора доменного имени, по которым проходит проверка или возбуждено дело.
  3. Правовое основание использования полномочий по направлению подобного решения, ограничивающего права администратора (ссылка на норму закона и пункт Правил регистрации доменных имен)
  4. Указание на исчерпание разумных способов связи с администрацией ресурса, хостинг-провайдером, либо их отказ в удалении информации, в случаях, предусмотренных настоящими разъяснениями.
  5. Контактная информация, позволяющая администратору урегулировать претензии непосредственно с органом, вынесшим решение, без привлечения регистратора.

Правовым основанием в письме указаны все те же правила российских доменов, про то, что пытались связаться с администратором или хостером вообще в письме ни слова, и не пытались, ну и конечно же никакой контактной информации как связаться с ЦИБом нет… печаль…

Попытка выйти из «бана»

В письме, предположительно из ФСБ, черным по белому написана просьба "приостановить делегирование доменов до удаления статей", и казалось бы нет особой проблемы, ну случилось, что помножилась глупость ФСБшников на боязливость регистратора, удалили материал и забыли как недоразумение.

Не тут то было, господа!

Отправив в ООО «Регтайм» скан бумаги о том, что данный контент удален, получаем ответ, дескать плевать они в данном случае хотели на просьбу ФСБ, в частности на фразу "до удаления статей", и будут четко следовать букве закона, то есть отправят почтой письмо в ФСБ и вот когда ФСБ им ответит, что можно делегировать домен, тогда они его и вернут, либо если ФСБ забьет отвечать, то вернут через месяц…

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

Судиться с ООО «Регтайм» будем в любом случае, хотя нет надежды на большую компенсацию, поскольку домен на частном лице, а доходы от рекламы как у нормальных людей идут на счет в европейском банке, не говоря уже об очевидной упущенной выгоде и потерях в будущем. Но отсудить пусть даже 12 рублей придется, хотя бы ради того, чтобы сделав перевод решения суда отправить его в ICANN, которому при такой практике давно пора лишить аккредитации таких регистраторов как WebNames, у которых перенести домен сложнее чем получить гражданство США, и которые к тому же творят вот такие вещи…

ссылка на оригинал статьи http://habrahabr.ru/post/266165/

Tanium может стать самым дорогим стартапом в сфере кибербезопасности

Tanium стал одним из самых дорогостоящих стартапов на рынке систем безопасности. В последнем раунде он привлек $120 миллионов от фондов TPG, Institutional Venture Partners и T Rowe Price, а также Andreessen Horowitz. В марте, по итогам предыдущего раунда оценка компании составила $1,7 миллиарда. Теперь она увеличилась более чем в два раза и достигла $3,5 миллиардов.

История знает еще два подобных случая, когда компаниям из области кибербезопасности удавалось привлечь настолько большую сумму в одном раунде. В 2009 году чешский разработчик антивирусного ПО AVG Technologies получил $200 миллионов, а в прошлом году американской компании Lookout удалось привлечь $150 миллионов.

Tanium занимается защитой корпоративных сетей от кибербатак. Инвесторы считают это направление весьма перспективным. По данным PrivCo, в этом году общие инвестиции в такого рода стартапы за один квартал в впервые превысили $1 миллиард.

После громких историй со взломом сети страховой компании Anthem и сервиса знакомств Ashley Madison многие фирмы увеличили расходы на усиление защиты от взломов. По итогам 2014 года мировые затраты на информационную безопасность должны были достигнуть $71,1 миллиарда, оценили аналитики Gartner. Это на 7,9% больше, чем в 2013 году.

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

«Год назад финансирование мог получить каждый, кто предлагал красивую идею, независимо от того, была ли у него возможность эту идею реализовать. Сегодня многие люди, особенно в верхних сегментах венчурного сообщества, понимают, что их финансирование было избыточным и часто оно тратилось лишь на развитие продаж и маркетинг», рассуждает Хиндави.

«Я поддержал Tanium, поскольку знаю, что Хиндави входит в элиту самых талантливых специалистов в области инфраструктурного софта, таких в мире не более полудюжины. Компания предлагает коммуникационную платформу, на которой можно строить мощные защищенные приложения. Ее потенциал может изменить подход американских компаний к кибербезопасности и управлению данными», приводят «Ведомости» заявление партнера фонда TPG Брайана Тейлора.

Объем заказов Tanium во II квартале вырос более чем на 250% по сравнению с аналогичным периодом 2014 года, а число проектов стоимостью выше $1 миллиона у компании в первом полугодии более чем удвоилось. Нынешний раунд финансирования был переподписан вчетверо, и сумма инвестиций, по словам Хиндави, могла бы быть увеличена еще на $30 миллионов. Теперь на счетах компании находится более $250 миллионов.

Развиваясь такими темпами, Tanium имеет все шансы стать самым дорогим стартапом в сфере кибербезопасности.

ссылка на оригинал статьи http://megamozg.ru/post/19108/