Релиз Carbon Reductor 8.00.07

Релиз Carbon Reductor 8.00.07

Добрый день!

Начнём с наиболее важной информации: законопроект, согласно которому размер штрафа за незаблокированные ресурсы повысится и составит 50-100 тыс.руб, подписан В.В.Путиным 22.02.2017 и вступит в силу 24.03.2017. В связи с этим, пожалуйста, для тех, кто еще не ознакомился, почитайте статьи о правильной настройке сервера фильтрации и об установке резервного сервера. А для тех, кто хочет дополнительно застраховаться, обратите внимание на подписку
SLA3 — Аутсорсинг. На этом уровне техническая поддержка берёт на себя администрирование сервера с Carbon Reductor, а также здесь предусмотрена страховка от штрафов Роскомнадзора.

Теперь о релизе (обновление будет доступно для скачивания после 13 марта).


Ускорено внедрение за счёт автоматической оценки сервера

Автоматизированы и улучшены следующие задачи:

  • Сбор информации о сервере.
  • Оценка этой информации для выявления узких мест, способных приводить к проблемам фильтрации.
  • Принятие более рациональных решений для оптимизации производительности.
  • Утилиты для упрощения отладки и настройки оборудования на сервере.

Автоматическая оптимизация производительности из коробки

Система чем-то похожа на демон «tuned» от Red Hat. Мы воспользовались бы им самим, если бы он поддерживал такой профиль оптимизации настроек сервера как захват трафика.

Возможности:

  • Отключение и установка «плавающей» частоты процессора.
  • Определение оптимального размера буферов сетевых карт, участвующих в захвате трафика.
  • Автоматическая настройка RPS для более равномерной нагрузки на ядра процессора (только при необходимости).

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

Интеграция с маршрутизаторами

Расширен функционал интеграции с маршрутизаторами: добавлена возможность использования BGP.


Спасибо, что пользуетесь Carbon Reductor!

Страхуемся, чтобы на 200% проходить проверки АС «Ревизор»

Страхуемся, чтобы на 200% проходить проверки АС «Ревизор»

Мы решили дополнительно подстраховать пользователей Carbon Reductor от форс‑мажорных ситуаций в плане фильтрации.


Сейчас предполагается, что система фильтрации у провайдера должна работать идеально 100% времени. Мы прикладываем огромные усилия, чтобы это было действительно так, но причины пропусков в фильтрации не связаны непосредственно с продуктом.

Это могут быть сбои оборудования на сервере с Carbon Reductor: если внезапно выйдет из строя жёсткий диск, сервер, скорее всего, продолжит работу и даже будет продолжать осуществлять фильтрацию трафика, но не сможет выгрузить списки и добавить новые URL. Такая ситуация недавно случилась у одного из пользователей и, к сожалению, привела к штрафу в 30 тысяч рублей. Блоки питания, битые модули оперативной памяти, сетевые кабели — ситуация та же самая.

Часто бывает так, что полноценного мониторинга за сервером не настроено, а сотрудник, зарегистрированный в нашем helpdesk, получающий уведомления от нашего мониторинга, уволился. Соответственно, о возникшей проблеме, несмотря на наличие тикета в хелпдеске и отправленных писем, узнаёт не системный администратор через 5 минут, а директор, причём от РЧЦ или РКН. (Кстати, начиная с 2017 года мониторить состояние Carbon Reductor стало значительно легче, можете посмотреть примеры в документации).

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

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

Эта статья носит рекомендательный характер. Если для Вас сейчас накладно обустраивать второй сервер или нет возможности организовать ещё одно зеркало трафика, ничего страшного. Основной сервер как работает, так и будет работать, просто за ним нужно следить и обслуживать.

Ранее мы уже писали о том, как должен быть настроен сервер с Carbon Reductor.

В плане установки дополнительной копии Carbon Reductor в сеть оператора есть несколько плюсов:

  • Возможность самостоятельно обкатывать новые версии перед обновлением, то есть использовать второй Carbon Reductor как staging-сервер, а на основном отключить автоматическое обновление.
  • Снижение вероятности пропуска фильтрации из-за потери пакета (как анализируемого трафика, так и редиректов/разрывов) в сети провайдера (одновременно потерять два пакета — куда сложнее чем один).
  • Снижение вероятности пропуска фильтрации из-за выхода из строя аппаратной части.
  • Снижение вероятности пропуска фильтрации из-за плавающих проблем в программном обеспечении. Kernel panic, soft-lockup, повисания сети во время применения изменений настроек сети при большом числе VLAN, неисправная сетевая карта/рейд-контроллер и т.д.
  • Возможность спокойно проводить техническое обслуживание сервера с рестартом сети или перезагрузками (замена оборудования, обновления ядра Linux, установки параметров драйверам сетевых карт и других экспериментов).
  • Для пользователей 7-й версии возможность ознакомиться с 8-й версией до массового перехода.

Как активировать резервный редуктор:

  1. Скачайте с сайта Carbon Reductor.
  2. Установите на отдельный сервер.
  3. Протестируйте в режиме пробной версии.
  4. Отправьте регистрационный номер резервного редуктора на почту sales@carbonsoft.ru c пометкой «Активация резервного Carbon Reductor».
  5. Активация пройдет в течение суток.

Успехов и процветания! Спасибо, что пользуетесь Carbon Reductor!

Релиз Carbon Reductor 7.5.1 100

Релиз Carbon Reductor 7.5.1 100

Доброго времени суток!

Продолжаем оптимизировать работу Carbon Reductor под новые реалии контроля фильтрации трафика со стороны РКН. Повышена стабильность выгрузки списков, а фильтрация стала еще лучше.


Самое важное

SNI-фильтрация стала значительно надёжнее в большинстве установок, связано с нюансами трафика в зеркале. Возможен незначительный рост (2-10%) нагрузки на сервер.

Исправлена ошибка с неснимающимся режимом обслуживания на старых выпусках CentOS (6.6 и младше).

Улучшена производительность резолвера в работе со списками.

Повышена надёжность обновления Carbon Reductor

Улучшена стабильность системы обновления. Добавлена дополнительная проверка в момент запуска обновления на случай если скачались некорректные данные. Ранее в случае ответа с ошибкой всегда запускалось скачивание и при обновлении это могло привести к неработоспособности редуктора. Также обновление самого Carbon Reductor теперь нельзя запустить дважды (спасает при запуске ручного обновления во время автоматического обновления).

Работа со списками

Стали более отказоустойчивыми выгрузка реестра и обновление сигнатур. Обновление списков и загрузка URL/доменов/IP в ядро тоже подверглась улучшениям в плане надёжности и понятности. Логируется статистика модуля до загрузки URL и после.

Другое

  • Унифицировано логирование во многих подсистемах: файрвол, обновление сигнатур, режим обслуживания, загрузка URL. Позволит быстрее находить причину сбоев в работе.
  • Мастер настройки зеркала трафика и часть других скриптов теперь поддерживают устройства, именуемые не «eth».
  • Унифицирована система тестирования. Наведён порядок в тестовой инфраструктуре, не касается конечных пользователей напрямую, но это делает Carbon Reductor более защищённым от ошибок разработчиков.
  • Улучшена работа Carbon Reductor в режиме только редиректора для неавторизованных/заблокированных/неплатящих абонентов без каких-либо списков вообще. Также для неавторизованных пользователей не полностью фильтровался HTTPS-трафик — исправлено.
  • В веб-интерфейсе в разделе «Информация» теперь выводится информация о файле запроса и его подписи при отсутствии сертификата.
  • Mikrotik периодически отдаёт пустой ответ при запросе списка IP адресов, не отдавая никакого кода возврата. Теперь это учитывается в примере хука для интеграции с маршрутизатором.
  • Утилита для поиска по кэшу резолва запрещенных доменов теперь умеет искать как домены по IP, так и IP по домену — используется для ресурсов, которые часто меняют IP-адрес.
  • Обновлён плагин для collectd (`/usr/local/Reductor/bin/collectd_plugin`), теперь он соответствует новому формату собираемой по модулям ядра статистики.
  • Исправлено несколько опечаток в диагностике и веб-интерфейсе.

Спасибо, что пользуетесь Carbon Reductor!

Релиз Carbon Billing 5.22.01

Релиз Carbon Billing 5.22.01

Добрый день!

В Carbon Billing 5 вновь добавили несколько фич, упростили взаимодействие с интерфейсом и облегчили жизнь нашим пользователям, но обо всём по порядку.


Что нового?

Больше способов оплаты для Ваших абонентов — добавлены платёжные системы: PayAnyWay, Payfon24, JCC, Kassa24.

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

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

Для операторов связи, клиенты которых могут содержать в наименовании более 7 слов (особенно госучреждения), мы расширили поля для ФИО абонента в 5 раз. Теперь Вы можете вместить любое наименование без сокращений.

Добавлена интеграция связки Stalker + IPTV Portal — даёт возможность быстрого и эффективного запуска видео-услуг на базе IP-сетей.

Другое

  • Добавлена обработка 1С для редакции бухгалтерии 3.0 в связи с обновлением 1С.
  • При создании абонента теперь можно быстро ввести дату в соответствующее поле, например при указании даты выдачи паспорта. Ранее для ввода данных приходилось листать виртуальный календарь.
  • Добавлена возможность интеграции с Eltex SMG-1016M.
  • Исправлены ошибки, о которых Вы сообщили.
  • Повышена отказоустойчивость базы данных при перезагрузке сервера по питанию.

Спасибо, что пользуетесь Carbon Billing 5!

Релиз Carbon Reductor 7.5.0 204 и 8.0.0 1435

Релиз Carbon Reductor 7.5.0 204 и 8.0.0 1435

Добрый день!

Изменения в связи с обновлением АС «Ревизор»

Добавлен режим обслуживания

В случае, если новая версия Carbon Reductor содержит изменения модулей фильтрации, на время процесса обновления, 10-20 секунд, включается режим обслуживания. Правила файрвола не очищаются полностью, вместо этого добавляется REJECT для всех видов трафика. Эти правила применяются только для АС «Ревизор», если указан его IP‑адрес/подсеть, иначе — для всех абонентов. Это сделано с целью исключить пропуски фильтрации в процессе обновления Carbon Reductor. Такие обновления бывают раз в 2-3 месяца.

А также:

  • Теперь не указанный IP-адрес АС «Ревизор» считается ошибкой.
  • Добавлена регистронезависимая фильтрация DNS для всех абонентов, если не указан IP‑адрес/подсеть АС «Ревизор». Может повышать нагрузку на сервер.

Повышение надёжности фильтрации

  • Теперь в файлах модулей фильтрации выводится статистика по обеим базам данных — как buffer, так и readonly. Ранее счётчики показывались не совсем верно — в какой-то момент от buffer, в какой-то от readonly, что могло привести к ошибочному выводу о том, что база, по которой происходит поиск при фильтрации, обнуляется при обновлении списков или рестарте.
  • Загрузка URL, доменов и IP в ядро теоретически могла быть запущена в процессе обработки списков и использовать не до конца обработанные списки — исправлено.

Исправления в Carbon Reductor 8

  • В момент применения собственных списков в веб-интерфейсе выдавалась 404/500 ошибка.
  • L2-зеркало трафика, настроенное с помощью мастера не работало.
  • Использование страницы-заглушки Carbonsoft теперь считается ошибкой, т.к. ответ от сервера Carbonsoft не является гарантированным.
  • Мелкие проблемы с запуском при первой установке.
  • Ошибка в веб-интерфейсе, в некоторых случаях возникала надпись «Файл не найден».
  • Ошибка генерации и подписи запроса для получения списка запрещённых сайтов, в результате которой списки не выгружались.

Прочее

  • Исправлено — Satellite не удалял пустые временные файлы на каждый домен при проверке DNS, что приводило к заполнению inodes. Проверить текущую заполненность можно командой: df -hi /tmp/.
  • Теперь в отчётах Satellite указывается его IP-адрес. Полезно при использовании нескольких серверов Satellite.
  • Плагин collectd сломался при обновлении модулей. Теперь он поставляется в комплекте с Carbon Reductor, чтобы обеспечить его автоматическое обновление. Инструкция на github по работе с ним в скором времени будет обновлена и продублирована в документацию Carbon Reductor.
  • Добавлен режим для Satellite, обеспечивающий отсутствие расхождения содержимого списков на Reductor и Satellite на время проверки фильтрации (используется только в целях агрессивного тестирования разработчиками).

Спасибо, что пользуетесь Carbon Reductor!

Голосование за функционал Carbon Billing 5

Голосование за функционал Carbon Billing 5

Публикуем результаты первого голосования в декабре 2016 года.

46,7% участников выбрали для реализации:
«Списки сайтов, разрешенных при отрицательном балансе, т.е. сайты, находящиеся в «Справочнике» в разделе «ACL списки разрешенных сайтов» будут попадать автоматически в adress list MikroTik. Данная вкладка пока совместима только с оборудованием вендора Cisco.»

Голосование за функционал

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

Голосование Январь 2017


Спасибо, что выбрали Carbon Billing 5!

Итоги года 2016 Carbon Billing 5

Итоги года 2016 Carbon Billing 5

Добрый день!


Подводим итоги года.

За 2016-й мы интегрировали Carbon Billing 5 более 70 операторам связи. Добавили более 100 новых функций и возможностей для пользователей, упрощающих работу и закрыли более 750 мелких задач!

Закрытые задачи за год:
Задачи за 2016 год


Спасибо, что выбрали Carbon Billing 5. С наступающим!

АС «Ревизор» теперь производит непрерывную проверку фильтрации

АС «Ревизор» теперь производит непрерывную проверку фильтрации

Доброго времени суток!

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


У нас есть страница-заглушки: http://denypage.ru. Давненько, когда модуль DNS-фильтрации стал необходим для прохождения проверок ревизора без пропусков, мы приняли довольно тяжелое решение о том, чтобы при обновлении включить этот модуль.

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

Взглянули на нагрузку, которую она создаёт и в принципе ничего особо страшного не было. Доросла она где-то до 100-400 тысяч запросов в час и это никого не беспокоило.

После обновления АС «Ревизор», 21 декабря — нагрузка на страницу выросла до 7 000 000 запросов в час, и это только те, которые достучались до контейнера с nginx, обслуживающим эту страницу. Многие запросы стали заканчиваться ошибками HTTP/502 Gateway Timeout, которые фиксируются ревизором. К штрафу это, скорее всего, не приведёт, т.к. ответа от запрещенного ресурса не было, но из РЧЦ к Вам придут с вопросом: «а почему у Вас нет страницы-заглушки?».

Чтобы фильтрация работала как положено нужно настроить собственную страницу заглушку.

Настройка заглушки, варианты:

На отдельном сервере

Чтобы АС «Ревизор» её успешно распознавал, следуйте инструкции (имеющиеся веб-сервера использовать не рекомендуется, потому что инструкция требует выделить отдельный сервер, занимающийся ТОЛЬКО страницей-заглушкой, в противном случае отправленные с помощью DNS-спуфинга редиректы не будут обработаны этим сервером):

https://github.com/carbonsoft/reductor_blockpages

После настройки страницы надо указать в двух местах адрес, доступный всем абонентам и АС «Ревизор»:

  1. Menu -> Настройка алгоритма фильтрации -> URL страницы-заглушки.
  2. Menu -> Настройка алгоритма фильтрации -> IP для DNS-ответов.

На сервере с Carbon Reductor

Не рекомендуется при большой нагрузке. (1000+ абонентов/несколько ревизоров).

Включить можно в «menu -> Настройка алгоритма фильтрации -> Заглушка на этом сервере».

После настройки страницы надо указать в двух местах адрес, доступный всем абонентам и АС Ревизор:

  1. Menu -> Настройка алгоритма фильтрации -> URL страницы-заглушки.
  2. Menu -> Настройка алгоритма фильтрации -> IP для DNS-ответов.

Почему нельзя использовать нашу страницу заглушку в продакшене

  • Она изначально предназначена исключительно для целей тестирования работоспособности продукта во время демо-периода, а также в являлась временным решением многомесячной давности.
  • Канал до неё имеет ограничение в 100 Мбит/с, ресурсы процессора тоже имеют свои ограничения. Мы не можем гарантировать её 100% доступность.
  • Также мы не можем гарантировать то, что ревизор не опознает недоступность нашей страницы-заглушки как доступность блокируемого сайта.

В конце концов, отправлять трафик абонентов и ревизора на нашу заглушку — лишняя нагрузка аплинков, да и интернет штука далекая от 100% надёжности. В общем, единственный способ правильно решить проблему — разворачивать заглушку на отдельном сервере.

Если Вы пропустили статью о том, что обязательно нужно настроить, чтобы не иметь пропусков — пройдитесь по ней.

Релиз Carbon Reductor 7.4.9 и 8.0.0

Релиз Carbon Reductor 7.4.9 и 8.0.0

Доброго времени суток!

В этом месяце у нас сразу два релиза. Теперь Carbon Reductor доступен на платформе Carbon, проверенной годами эксплуатации Carbon Billing 5. Carbon Reductor 8 успешно внедрён у 5 провайдеров, в него полностью портированы все исправления и доработки из версии, поставляемой в RPM для CentOS (Carbon Reductor 7). Но обо всём по порядку.


Carbon Reductor 7.4.9 300


Файрвол

Снижена нагрузка на модуль SNI-фильтрации

Теперь туда попадают только пакеты длиннее 60 байт. SNI всё равно не может оказаться в SYN/RST/FIN и других коротких пакетах без данных, но полагаться только на TCP-флаги было бы неправильно.

Изменения и исправления в блокировке HTTPS по IP

При отключении блокировки HTTPS по IP не работала блокировка адресов вида https://1.2.3.4.ru/something. Опция «Блокировать HTTPS по IP» немного изменила своё поведение:

  • включено: Блокировать HTTPS по IP для всех записей в едином реестре, где встречаются HTTPS-ссылки;
  • выключено: Блокировать HTTPS по IP только в случаях, если иначе заблокировать ресурс невозможно.

«Под капотом» это выглядит как разделение списка IP в файрволе на 2 ipset:

  • `ip_https` — ресурсы, которые можно заблокировать только по IP, используется всегда, независимо от опций;
  • `ip_https_plus` — дополнительные IP адреса для блокировки на портах HTTPS. Включается опцией «Блокировать HTTPS по IP».

Опция «Использовать nslookup» использует резолвер для расширения списка IP для ipset `ip_https_plus`.

Исправлено: не блокировались нестандартные порты HTTPS при включении опции «оптимизация подсистемы роутинга»

На самом деле, пока всего 1 порт. Однако, несмотря на то, что это исправлено — рекомендуем всё равно эту опцию выключить, она является сильно устаревшей и даёт мало пользы в большинстве случаев.

Затем не забудьте проверить изменение нагрузки на сервер (до и после выключения и рестарта) с помощью утилиты `/usr/local/Reductor/bin/net_rx_top.sh`, оно не должно превышать 25000 прерываний на ядро. В противном случае необходимо решать проблему с производительностью, лучше горизонтальным масштабированием.

Опции «Использовать SNI» и «Использовать NOTRACK» теперь включаются при обновлении автоматически

Единоразово, затем их можно отключить. Благодаря тому, что свой IP адрес мы удаляем в цепочке `raw -> PREROUTING -> mirror_info` опция NOTRACK теперь полностью безопасна. SNI-модуль успешно прошёл экспериментальную фазу и хорошо себя зарекомендовал более чем на 80 серверах, перед тем как быть включённым по умолчанию.

Прочие исправления

  • редуктор не стартовал при основном маршруте через девайс, а не IP шлюза;
  • использование дополнительных правил фильтрации https приводило к невозможности старта Reductor;
  • DNS-спуфинг мог зацикливать HSTS-прокси, если его трафик попадал в зеркало. Сейчас трафик с его IP игнорируется.

Утилиты для отладки и обработка списков

Работа обработки списков URL ускорена в 7 раз

Однажды, в выходные была предпринята попытка всё переписать на Go, которая закончилась профилированием, изменением 8 строчек в одной функции.

Результаты замера скорости обработки списков. Окружение: CentOS 6, KVM, 2 виртуальных ядра, 1Gb RAM, виртуальный диск (qcow2, writeback), список `rkn.url_http`, на момент замера 39000 URL.

  • Старая версия, python 2.6: 0m21.163s
  • Старая версия, pypy2.7: 0m5.310s
  • Новая версия, python2.6: 0m3.312s
  • Новая версия, pypy2.7: 0m3.560s

Один из наиболее важных вариантов экранирования пропускался

Ошибка, связанная с всего-лишь одной запятой, имелась с ноября 2015 года, но никем не была замечена. Имеется только один подтверждённый факт пропуска одного URL. В итоге число предобработанных для загрузки в ядро на выходе повысилось с ≈43000 до ≈52000 (для алгоритма match-модуля это на самом деле крайне незначительно влияет на производительность).

Небольшое, но важное исправление в связке с маршрутизаторами по BGP

Скрипт для блокировки/разблокировки ресурсов по IP на маршрутизаторах некоторое время не мог найти файл `ip_block.load`. Это исправлено, но возможно имело последствия, так что всем использующим интеграцию с маршрутизаторами средствами BGP рекомендуется обновить хук и проверить, что успешно анонсируются все IP адреса. В противном случае может помочь инструкция.

Прочее

Добавлено:

  • утилиты для отладки: `support_info.sh` теперь показывает статистику по дисковому пространству;
  • утилиты для отладки: утилита показывающая информацию по доступным обновлениям. Запуск — `/usr/local/Reductor/bin/check_update_human.sh`;
  • выгрузка списков: возможность выполнять клиентские хуки до начала выгрузки. В `userinfo/hooks/rkn_download.sh` достаточно определить функцию `client_pre_hook()`.

Исправлено:

  • утилиты для отладки: скрипт `url_info.sh` пытался искать данные в старых списках;
  • мастер настройки сети: L3 vlan схема не работала из коробки, не хватало опции `VLAN=yes` в шаблоне конфига интерфейса;
  • обработка списков: списки Carbon Soft для временных решений качались в старом формате -> не использовались;
  • обработка списков: не выкачивались сигнатуры для URL с несколькими пробелами;
  • обработка списков: не работала DNS-фильтрация при пустых строках в списках провайдеров. Помимо этого обработка стала активнее и явнее отсекать невалидные данные, например URL с доменами первого уровня при обработке списков URL.

Резолвер

Не удалялись временные файлы

Могло привести к переполнению `/tmp/`, особенно там, где используется реальный `tmpfs`. Благодаря своевременному критическому обновлению проблема успела проявиться только на двух наблюдаемых мониторингом серверах, у одного из которых было отключено критическое обновление, где была устранена вручную.

Прочие исправления логики после переезда на новые списки

Теперь создаётся симлинк `/usr/local/Reductor/lists/https.resolv` для совместимости с `named fakezone generator`

С ним уже найдено и исправлено несколько багов:

  • домены для отправки в прокси по DNS могли начать блокироваться по IP из-за попадения в https.resolv;
  • запуск старого резолвера в cron.d приводил к занулению https.resolv;
  • создание https.resolv происходит даже если резолвер выключен;
  • мог быть заблокирован IP адрес страницы-заглушки.

Тесты

«Service reductor restart» всегда возвращал нулевой код возврата, даже если писал об ошибках. Это исправлено, так что у нас появились pairwise тесты параметров фильтрации, позволяющие за полторы минуты достаточно достоверно подтверждать отсутствие проблем в опциях и сочетаниях опций (пусть и только попарных, но это в разы лучше, чем ничего), приводящих к невозможности запуска.

Исправления

  • satellite: Carbon Reductor Satellite стал проверять фильтрацию в 2.5 раза быстрее благодаря более оптимальному алгоритму разделения ресурсов для проверки между потоками;
  • satellite: не разбирался реестр из-за неполного конфига;
  • диагностика/ошибки настройки: не показывались подробности по проблемам: интеграция с маршрутизаторами, уведомления админа редиректом;
  • мастер настройки: не запускался выбор метода обновления списков РКН (web, xml, pem);
  • интеграция с биллингом: не работала при ненастроенной DNS-фильтрации.

Reductor 8.0.0 1395


Отличия от 7 версии

Форма поставки

Основным различием является форма поставки приложения. Теперь Carbon Reductor поделен на отдельные приложения: reductor, blockpage и https_proxy (последние два могут быть отключены), а на подходе и satellite. Каждое приложение поставляется в виде изолированного chroot-окружения, где есть всё, что ему необходимо для работы. Помимо них есть ещё два обязательных контейнера:

  • base — даже не контейнер, а просто папка с утилитами для управления остальными контейнерами и парой конфигов в корне;
  • auth — система авторизации в веб-интерфейс управления сервером.

Все обновления бинарные

Подтягиваются только изменения, скачивание обновления отделено от применения. Незначительным минусом является, пожалуй, размер приложений, но он заметен только при первой установке через медленный канал. В чём-то это схоже с Red Hat Atomic Host / Docker, только без заморочек с «только один запущенный процесс на контейнер» и нет ограничений на работу с ядром хост-системы. Есть и минус — больше нет возможности отката на предыдущую версию, но мы что-нибудь придумаем.

Установка происходит с универсального ISO-образа

Образ автоматически сделает надёжную разбивку дисков, используемую платформой Carbon, соберёт при необходимости софтрейд. Подробнее о процессе установки можно узнать в соответствующей статье в документации.

Диагностика происходит раз в 5 минут

А не так как ранее — раз в час. Запускается отдельно для всех приложений. Веб‑интерфейс редуктора в диагностике показывает все найденные предыдущими запусками ошибками с подробностями, но не запускает саму диагностику.

Изменения в бизнес-процессах

Теперь новые внедрения происходят только для Carbon Reductor 8, а все изменения в первую очередь вносятся в неё, затем при необходимости бэкпортируются в Carbon Reductor 7.

Точного плана по прекращению поддержки Carbon Reductor 7 ещё нет, но мы обязательно сообщим о нём за 2-3 месяца и поможем переехать. Переезжать, пока, стоит только согласовав всё с технической поддержкой, лучше предварительно обкатав восьмую версию на тестовом сервере и убедившись в том, что с ней нет никаких проблем. Проблемы возникшие в результате самостоятельного обновления на 8 версию на продакшне, пока что, не являются критическими и не подлежат приоритетному решению.

Автоматический переезд с 7 версии на 8 сложен технически, в основном из-за недетерминированности хуков и изменений в именовании цепочек файрвола. Тем, кто использует Carbon Reductor без дополнительных наработок, будет значительно проще всё это сделать. Многие типовые хуки уже были включены в виде опций в дистрибутиве, некоторые стали частично бессмысленными после изменения схемы файрвола (ACCEPT в mangle для zabbix например).

Изменения за последний месяц в 8 версии

  • исправлены многочисленные мелкие проблемы с путанницей в местоположении файлов (меняющиеся данные находятся на отдельном разделе);
  • адаптирована к платформе Carbon система диагностики, теперь каждая проверка находится в отдельном файле и может быть запущена без запуска остальных;
  • загрузка списков в ядро стала отказоустойчивее к проблемам отдельных модулей — если один из модулей по какой-либо причине не работает, хотя и должен:
    1. Будет выведено соответствующее сообщение об ошибке.
    2. Скрипт продолжит работу.
    3. Зальёт списки в остальные модули, если это удастся.
    4. Завершится с ошибкой.

Спасибо, что пользуетесь Carbon Reductor!

Как продвинуть желаемый функционал в Carbon Billing 5?

Как продвинуть желаемый функционал в Carbon Billing 5?

Добрый день!


В последние месяцы уходящего года в Carbon Soft занимаемся оптимизацией, стабилизацией и багфиксом, чтобы в период повышенной нагрузки интернет у Ваших абонентов работал стабильно. Новый функционал и фичи продолжим разрабатывать с начала 2017 года. А пока, покрываем биллинг автотестами.

В первой половине 2017 г. запланировано

  • Разработка модуля Provisioning — позволит абонентам не почувствовать потерю связи между биллингом и NAS-сервером.
  • Развитие CRM — это позволит средним и крупным операторам связи автоматизировать работу с заявками, подключениями и прочим, и не пользоваться сторонним ПО для этого.

Голосование за функционал

На странице с биллингом появилась ссылка для голосования за добавление нового функционала, который предложили пользователи Carbon Billing 5. Функция, выбранная большинством, будет реализована в новой версии Carbon Billing 5 в течение 2-х месяцев. Чтобы добавить своё пожелание напишите на почту продукт-менеджеру denis@carbonsoft.ru с темой письма «Пожелания по функционалу». Прежний вариант – приобрести девелоперский пакет также остаётся в силе.

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

Принимайте участие:
Опрос, декабрь 2016


Спасибо, что пользуетесь Carbon Billing 5!

Среди наших клиентов