...

суббота, 7 апреля 2018 г.

[Из песочницы] Ещё один пример автоматизации или PowerShell + Google Apps Script

Лень — двигатель прогресса…

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

1. PowerShell


Началось все с создания скрипта на PowerShell, где с консоли предлагалось ввести данные пользователя. В результате создавался пользователь AD в соответствующем OU, с заполненными полями.

2. Google Apps Script


Далее создаем почтовый ящик, который в моем случае хостится на Gmail. Благодаря этому можно использовать замечательный сервис Apps Script. В его основе лежит JavaScript. Обилие документации и небольшой опыт программирования помог разобраться с этим делом. Здесь аналогично передаем данные функции — аккаунт создан.

Этим же инструментом переделываем шаблон Welcome-письма, заменяя %username% и т.д. на реальные данные и отправляем pdf HR-ам, боссу, новому пользователю и конечно себе.

function createUser(name, lastName, gender, groups, password, title, department) {
  
  var userMail = email((name + "." + lastName).toLowerCase()); 
  var admin = email("admin");
  var recipients = admin + "," + email("hr") + "," + email("boss");
  var subject = "Welcome! " + name + " " + lastName + " - " + title;
  var body = "Welcome to the jungle";
  var attachment = makeWelcome(name, lastName, password);
  
  var resource = {
    "name": {
      "familyName": lastName,
      "givenName": name
    },
    "password": password,
    "primaryEmail": userMail,
    "changePasswordAtNextLogin": true,
    "organizations": [{
      "title": title,
      "department": department
    }],
    "gender": {
      "type": gender
    }
  }
  
  AdminDirectory.Users.insert(resource);  
  Logger.log(userMail + "'S BEEN CREATED");
    
  for (var i = 0; i < groups.length; i++) {
    addMember(groups[i], userMail);
  }  
  
  var options = {
    "attachments": [attachment],
    "name": "Sysadmin"
  }
  
  MailApp.sendEmail(recipients, subject, body, options);
  MailApp.sendEmail(userMail, "Welcome!", body, options);
}


3. UI, автоматизация


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

После отработки гугл-скрипта, через Backup and Sync (GDrive) данные ввиде текстового файла передаются в локальную сеть. Здесь за дело берется PowerShell — парсит файл и создает пользователя AD. Вот теперь красиво!

Let's block ads! (Why?)

Разбор задачек от Одноклассников на JPoint 2018

Очевидная проблема в коде Вадима в том, что track.hashCode() может возвращать как положительные, так и отрицательные значения.

Вадим же человек аккуратный ( вы посмотрите сколько assertов! ), значит, комментарий к методу он тоже написал аккуратно, а там указано, что метод вернет число в интервале от 0 до partitions исключительно.

Очевидным способом исправить проблему будет немного другая концовка метода, например, такая:

        return Math.abs( track.hashCode() ) % partitions;


Казалось бы — ура и в продакшен! Но есть одна менее очевидная проблема — по спецификации hashCode() вполне себе может вернуть и Integer.MIN_VALUE, а попытка взять от такого числа Math.abs ни к чему хорошему не приведет.

Ох, говорила мама, следи за скобками, сынок! Правильно будет как-то так:

        return Math.abs( track.hashCode() % partitions );


Другая, более серьезная проблема Вадима гораздо менее очевидна. Способ, который он выбрал для того, чтобы распределять данные по серверам не консистентен — при изменении количества партиций ( например, при добавлении серверов ) все треки перераспределяются по кластеру практически полностью. Если треков мало — проблем не много, а если кластер большой и треков там на сотни терабайт — их все надо переместить между серверами. А Вадим уже залил терабайты треков на сотню — другую серверов…

Эх, Вадим, Вадим! Использовал бы ты какой либо из вариантов консистентных хешей, не болела бы у тебя сейчас голова.

Let's block ads! (Why?)

Проверяй входящие данные. Исходная причина уязвимости и атаки на Cisco IOS

Cisco IOS function weak

В пятницу 6 апреля 2018 началась мощная атака на оборудование Cisco.

Много пишут о том, что главная причина, по которой эта атака успешна, это открытые во внешние сети сервисные порты Cisco Smart Install.

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

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

Вы лишь можете заставить изменить эти значения с помощью каких либо ограничивающих использование приёмов. Чему многие будут не рады. «Защита от дурака» это один из примеров этих обязывающих ограничений.

Про выбор по умолчанию
Есть исследование 2003 года «Спасает ли жизни выбор по умолчанию?», в котором есть диаграмма

image

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


Я хочу обратить внимание на корень самой уязвимости. В отчёте есть такая часть:
Переполнение буфера происходит в функции smi_ibc_handle_ibd_init_discovery_msg

Cisco IOS function weak
из-за того, что при копировании данных в буфер фиксированного размера их размер не проверяется. Размер данных и они сами напрямую берутся из сетевого пакета.

Т.е. при получении данных из вне не происходит проверки на их корректность.

Я считаю, что это то главное напоминание, которое нужно сделать в очередной раз.

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

P.S. Кстати, эта функция как раз примеров того, что программист просто взял значение по умолчанию, оттуда, где оно есть — из сетевого пакета.

Let's block ads! (Why?)

[Из песочницы] Знакомство с новым элементом dialog

Самоуправляемые виртуальные инфраструктуры: VMware обновляет vRealize Suite

На прошлой неделе VMware объявили об обновлении своей платформы управления облаком vRealize Suite. Оно выйдет 4 мая этого года, направлено на упрощение работы с SDDC (программно-определяемым ЦОД) и включает ряд новых функций.

Подробнее о некоторых из них расскажем под катом.


/ фото RobertCC

vRealize Operations: новые решения для предиктивного анализа


Одним из компонентов vRealize Suite, который получил обновление, стал vRealize Operations. Пользователи теперь могут задавать целевые показатели отдельных нагрузок в панели управления, а система будет сама их балансировать.

Например, эта функция позволяет оптимизировать используемые ресурсы узлов в сети, снижая затраты на эксплуатацию, соблюдать требования SLA и выделять дополнительное место в кластере для работы бизнес-критических приложений. Для этого vRealize запускает сервис Performance Automation, использующий методы предсказательной аналитики.

Еще один компонент vRealize Operations, который появится после обновления, называется Capacity Analytics Engine. Этот движок анализирует мощностные потребности и распределение ресурсов в режиме реального времени. За счет этого пользователи могут отслеживать и оптимизировать нагрузку. В основе движка лежит модель ARIMA, которая умеет предсказывать состояние системы (например, внезапные скачки трафика) на основании событий в прошлом.

Новые решения также позволят клиентам экономить за счет автоматического высвобождения неиспользуемых ресурсов и определения оптимального количества машин в виртуальной среде. Кроме того, пользователи смогут запускать сценарии «что если», чтобы планировать нагрузку (в зависимости от потребностей) для будущих проектов в облаке (например, в частном облаке на базе VMware vSphere).

Capacity Analytics Engine также может стать основой для внедрения систем МО в будущем.


/ фото U.S. Department of Agriculture PD

vRealize Automation: новые сервисные функции


vRealize Automation помогает настраивать серверы и рабочие столы в виртуальных, физических, частных, публичных и гибридных облачных средах. В этом релизе решение снабдили новыми функциями предоставления услуг, а также улучшениями, связанными с мультитенантной архитектурой и интеграцией продуктов:
  • Новые возможности для создания шаблонов приложений и работы с OVF. Появились 20 бесплатных шаблонов и 100 OVF-файлов «из коробки», которые помогут ускорить развертку приложений. Чтобы добавить эти опции, VMware объединились с Bitnami, компанией, занимающейся созданием библиотеки популярных приложений, и разработчиками разных БД (GitLab, Hadoop, Jenkins и MongoDB).
  • Обновление Custom Form Designer: теперь можно создавать формы запросов на обслуживание для элементов каталога vRealize Automation.
  • Расширенные возможности мультитенантной архитектуры: с помощью специальных фильтров новая версия позволит лучше понимать, что происходит с теми или иными элементами инфраструктуры и сетевыми сервисами. Помимо этого, появилась поддержка последней версии решения vRealize Orchestrator, которое также является мультитенантным.

Обновление vRealize Suite Lifecycle Manager


Этот продукт помогает автоматизировать управление жизненным циклом (от установки и конфигурации до мониторинга состояния) элементов vRealize Suite из единой консоли.

Обновленная версия предлагает следующие функции.

  • Интегрированный «магазин приложений»: этот релиз vRealize Suite дополнили аналогом app store, в котором есть продукты от VMware и партнеров компании. В магазине доступны пакеты управления для vRealize Operations, дополнительные пакеты для vRealize Log Insight, а также плагины и шаблоны приложений для vRealize Automation. Их можно будет загружать, развертывать и удалять с помощью Lifecycle Manager.
  • IT Content Lifecycle Management: даст возможность управлять жизненным циклом разработки в том числе автоматизировать выпуск версий, тестирование и развертывание приложений. Для этого предусмотрена интеграция с GitLab. Также функция позволит работать с компонентами инфраструктуры так, как если бы они были обыкновенными приложениями, и применять принципы DevOps для управления vRealize-контентом в разных средах.



P.S. Несколько материалов из Первого блога о корпоративном IaaS:
P.P.S. Несколько постов из блога на Хабре:

Let's block ads! (Why?)

[Перевод] Learn OpenGL. Урок 4.11 — Сглаживание

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

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

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

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

Так, например, одной из первых была техника суперсэмплинга (super sampling anti-aliasing, SSAA). Реализация выполняется в два прохода: сначала рендер идет во внеэкранный кадровый буфер с разрешением заметно больше экранного; затем изображение переносилось с уменьшением в экранный буфер кадра. Эта избыточность данных за счет разницы в разрешении использовалась для уменьшения эффекта алиасинга и работал метод прекрасно, но было одно «Но»: производительность. Вывод сцены в огромном разрешении отнимал порядочно сил у GPU и век славы этой технологии был недолог.

Но из пепла старой технологии родилась новая, более продвинутая: мультисэмплинг (multi sampling anti-aliasing, MSAA). Основывается она на идеях SSAA, но реализует их гораздо более эффективным методом. В данном уроке мы подробно рассмотрим подход MSAA, который доступен нативно в OpenGL.

Мультисэмплинг


Чтобы понять суть мультисэмплинга и как он работает, нам сперва придётся поглубже залезть в потроха OpenGL и взглянуть на работу её растеризатора.

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


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

Думаю, вы уже догадались о причинах алиасинга. Рендер данного треугольника на экране будет выглядеть так:


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

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


Слева показан стандартный подход определения перекрытия. Для выбранного пикселя фрагментный шейдер не будет выполнен, и он останется незакрашенным, поскольку перекрытие не было зарегистрировано. Справа показан случай с мультисэмплингом, где каждый пиксель содержит 4 точки подвыборки. Здесь видно, что треугольник перекрывает только 2 точки подвыборки.
Количество точек подвыборки может быть изменено в определенных пределах. Большее число точек – лучше качество сглаживания.
С этого момента все происходящее становится интереснее. Определив, что две точки подвыборки пикселя были покрыты треугольником, необходимо вывести итоговый цвет для этого пикселя. Первой догадкой было бы выполнить фрагментный шейдер для каждой перекрытой треугольником точки подвыборки и затем усреднить цвета всей точек подвыборки в пикселе. В этом случае пришлось бы несколько раз выполнить фрагментный шейдер с вершинными данными интерполированными к координатам каждой из перекрытых точек подвыборки (дважды в данном примере) и сохранить полученные цвета в этих точках. К счастью, на самом деле процесс мультисэмплинга работает не так – иначе нам пришлось бы выполнять немалое число дополнительных вызовов фрагментного шейдера, что сильно ударило бы по производительности.

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

Буфер кадра в результате содержит изображение примитивов с гораздо более сглаженными краями. Посмотрите, как выглядит определение покрытия подвыборок на уже знакомом треугольнике:


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

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


Как видно, чем меньше подвыборок пикселя принадлежат треугольнику, тем меньше его цвет соответствует цвету треугольника. Четкие границы треугольника теперь окружены пикселями слегка более светлого оттенка, что создает эффект сглаживания, если наблюдать с расстояния.
Но не только значения цвета подвержены работе алгоритма мультисэмплинга: буфер глубины и трафарета также начинают использовать множественные подвыборки для пикселя. Значение глубины вершины интерполируется для каждой из точек подвыборки перед выполнением теста глубины. Значения трафарета хранятся не для всего пикселя, а для каждой из точек подвыборки. Для нас это означает и рост объема памяти, занимаемой этими буферами, в соответствии с количеством используемых подвыборок.

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

Мультисемплинг в OpenGL


Для использования мультисэмплинга в OpenGL необходимо использовать буфер цвета, способный хранить больше, чем одно значение цвета на пиксель (ведь MSAA подразумевает хранение значения цвета в точках подвыборки). Таким образом, нам требуется какой-то особенный тип буфера, который сможет хранить заданное количество подвыборок – мультисэмпл буфер.

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

glfwWindowHint(GLFW_SAMPLES, 4);

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

После создания мультисэмпл буферов силами GLWL остается включить режим мультисэмплинга уже в OpenGL:

glEnable(GL_MULTISAMPLE);  

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

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


Действительно, края этого кубика выглядят гораздо более привлекательно. И тот же эффект скажется на любом объекте в вашей сцене.

Исходник примера находится здесь.


Создание основного кадрового буфера с включенным MSAA простая задача, благодаря GLFW. Если же мы хотим создать собственный буфер, например, для внеэкранного рендера, то придется взять этот процесс в свои руки.

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

Текстурное прикрепление с мультисемплингом


Для создания текстуры, поддерживающей множественные подвыборки, используется тип текстурной цели GL_TEXTURE_2D_MULTISAPLE и функция glTexImage2DMultisample вместо привычной glTexImage2D:
glBindTexture(GL_TEXTURE_2D_MULTISAMPLE, tex);
glTexImage2DMultisample(GL_TEXTURE_2D_MULTISAMPLE, samples, GL_RGB, width, height, GL_TRUE);
glBindTexture(GL_TEXTURE_2D_MULTISAMPLE, 0);  

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

Для присоединения такой текстуры к объекту кадрового буфера используется все тот же вызов glFramebufferTexture2D, но, в этот раз, с указанным типом текстуры GL_TEXTURE_2D_MULTISAMPLE:

glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D_MULTISAMPLE, tex, 0);

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

Рендербуфер с мультисемплингом


Создание рендербуфера с множеством точек подвыборки не сложнее создание такой текстуры. Более того, оно даже проще: все что нужно сделать, так это сменить вызов glRenderbufferStorage на glRenderbufferStorageMultisample при подготовке памяти под привязанный в данный момент объект рендербуфера:
glRenderbufferStorageMultisample(GL_RENDERBUFFER, 4, GL_DEPTH24_STENCIL8, width, height); 

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

Рендер в кадровый буфер с мультисемплингом


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

Изображение с поддержкой мультисэмплинга содержит больше информации, чем обычное, потому необходимо разрешить (resolve) это изображение, или, иными словами, преобразовать его разрешение к меньшему. Эта операция по обыкновению проводится с помощью вызова glBlitFramebuffer, что позволяет скопировать область одного кадрового буфера в другой с попутным разрешением присутствующих буферов с множеством точек подвыборки.
Данная функция осуществляет перенос области-источника, заданной четырьмя координатами в экранном пространстве, в область-приемник, также заданную четырьмя экранными координатами. Напомню урок по кадровым буферам: если мы привязываем объект буфера кадра к цели GL_FRAMEBUFFER, то неявно привязка осуществляется и к цели чтения из буфера кадра и к цели записи в буфер кадра. Для привязки к этим целям по отдельности использутся специальные идентификаторы целей: GL_READ_FRAMEBUFFER и GL_DRAW_FRAMEBUFFER соответственно.

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

glBindFramebuffer(GL_READ_FRAMEBUFFER, multisampledFBO);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBlitFramebuffer(0, 0, width, height, 0, 0, width, height, GL_COLOR_BUFFER_BIT, GL_NEAREST);

Собрав и запустив приложение мы бы получили изображение идентичное предыдущему примеру, не задействовавшему буфер кадра: кислотно-зеленый куб, отрисованный с использованием MSAA, в чем можно убедиться, рассмотрев его грани – они все так же гладки:

Исходники примера находятся здесь.

Но что делать в случае, если изображение из буфера кадра с множеством точек подвыборки мы бы хотели использовать в качестве источника данных для постпроцессинга? Напрямую использовать мультисэмпл текстуры в шейдере мы не можем. Но можно попробовать перенести изображение из мультисэмпл буфера кадра с помощью блиттинга в другой, с обычными, не мультисэмпл, буферами. А далее можно использовать обычное изображение как ресурс для постобработки, по сути получая все преимущества MSAA и добавляя сверху этого постобработку. Да, для всего этого процесса придется заводить отдельный буфер кадра, служащий чисто как вспомогательный объект для разрешения MSAA текстур в обычные, которые можно использовать в шейдере. В виде псевдокода процесс выглядит так:

unsigned int msFBO = CreateFBOWithMultiSampledAttachments();
// затем создайте еще один FBO с обычной текстурой в качестве прикрепления цвета
...
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, screenTexture, 0);
...
while(!glfwWindowShouldClose(window))
{
    ...
    
    glBindFramebuffer(msFBO);
    ClearFrameBuffer();
    DrawScene();
    // разрешение мультисэмпл буфера с помощью вспомогательного
    glBindFramebuffer(GL_READ_FRAMEBUFFER, msFBO);
    glBindFramebuffer(GL_DRAW_FRAMEBUFFER, intermediateFBO);
    glBlitFramebuffer(0, 0, width, height, 0, 0, width, height, GL_COLOR_BUFFER_BIT, GL_NEAREST);
    // теперь образ сцены сохранен в обычной текстуре, которая используется для постобработки
    glBindFramebuffer(GL_FRAMEBUFFER, 0);
    ClearFramebuffer();
    glBindTexture(GL_TEXTURE_2D, screenTexture);
    DrawPostProcessingQuad();  
  
    ... 
}

Если мы добавим этот код к примерам постобработки из урока по буферу кадра, то сможем применить все те эффекты к изображению сцены без зазубренных краев. Например, с эффектом размытия получится что-то подобное:

Поскольку для постпроцессинга используется стандартная текстура с одной точкой подвыборки, то некоторые методы обработки (поиск границ, например) могут снова внести в сцену заметные резкие края и зазубрины. Чтобы обойти этот артефакт придётся либо размывать результат, либо реализовать свой алгоритм сглаживания.
Как видно, для сочетания MSAA и техник внеэкранного рендера приходится учесть некоторые детали. Но все дополнительные усилия окупаются гораздо более высоким качеством результирующего изображения. Однако, помните, что активация мультисэмплинга все же может значительно затронуть итоговую производительность, особенно при установленном большом количестве точек подвыборки.
На самом деле в шейдеры можно передать мультисэмпл текстуры напрямую, без блиттинга в вспомогательную обычную. В таком случае возможности GLSL предоставляют доступ к отдельным точкам подвыборки в текстуре, что может использоваться в создании собственных алгоритмов сглаживания (что нередко в крупных графических приложениях).

Для начала потребуется создание специального сэмплера типа sampler2DMS, вместо привычного sampler2D:

uniform sampler2DMS screenTextureMS;

А для получения значения цвета в точке подвыборки используется следующая функция:
vec4 colorSample = texelFetch(screenTextureMS, TexCoords, 3);  // считывание из 4ой точки подвыборки

Здесь видно дополнительный аргумент – номер точки подвыборки (отсчет с нуля), к которой происходит обращение.

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

P.S.: У нас есть телеграм-конфа для координации переводов. Если есть серьезное желание помогать с переводом, то милости просим!

Let's block ads! (Why?)

Зачем выставлять в Интернет интерфейс управления или атака на Cisco Smart Install

Недавно Cisco узнала о некоторых хакерских группировках, которые выбрали своими мишенями коммутаторы Cisco, используя при этом проблему неправильного использования протокола в Cisco Smart Install Client. Несколько инцидентов в разных странах, в том числе некоторые из которых касаются критической инфраструктуры, оказались связаны с неправильным использованием протокола Smart Install. Некоторые эксперты считают, что ряд этих атак связан с хакерами, стоящими на службе государства. В результате мы занимаем активную позицию и призываем клиентов, снова, к оценке рисков и применению доступных методов нейтрализации рисков.

14 февраля 2017 года (да-да, тут нет ошибки, речь идет о 2017-м годе) группа реагирования на инциденты безопасности продуктов Cisco (PSIRT) опубликовала бюллетень, описывающий результаты активного сканирования, связанного с Cisco Smart Install Clients. ПО Cisco Smart Install Client — устаревшая утилита, предназначенная для удаленной настройки нового оборудования Cisco, в частности коммутаторов Cisco. В продолжение, Cisco Talos опубликовал заметку в блоге и выпустил инструмент с открытым исходным кодом, который сканирует устройства, использующие протокол Cisco Smart Install. В дополнение к описанному была выпущена сигнатура для системы обнаружения атак Snort (SID: 41722-41725), позволяющая детектировать любые попытки использовать эту технологию.

Протоколом Cisco Smart Install можно злоупотреблять, чтобы изменить настройку сервера TFTP, экспортировать файлы конфигурации через TFTP, изменить конфигурационные файлы, заменить имидж сетевой операционной системы IOS и настроить учетные записи, позволяющие выполнять команды IOS. Хотя это не является уязвимостью в классическом смысле, неправильное использование этого протокола может служить вектором атаки, который следует немедленно нейтрализовать. В течение конца 2017 года и в начале 2018 года Talos наблюдал, как злоумышленники пытались сканировать клиентов, используя эту уязвимость. Недавняя информация повысила актуальность этой проблемы и мы решили вновь к ней вернуться.

Хотя мы наблюдали только атаки, связанные с проблемой неправильного использования протокола Cisco Smart Install, недавно была раскрыта и исправлена ​​другая уязвимость в Cisco Smart Install Client. Эта уязвимость была обсуждена публично, и был выпущен код с доказательством возможности эксплуатации уязвимости (PoC). Для устранения проблемы неправильного использования протокола, клиенты также должны устранить эту уязвимость, установив соответствующее обновление.

Область действия


Как часть исследования Cisco Talos, мы начали изучать, сколько устройств потенциально уязвимо для этой атаки. Результаты были крайне тревожными. Используя Shodan, Talos смог определить, что более 168 000 систем потенциально могут быть обнаружены через “открытый в Интернет” Cisco Smart Install Client. Это лучше, чем результаты 2016 года, когда один из сотрудников компании Tenable сообщил о 251000 уязвимых клиентов Cisco Smart Install Client, “видимых” из Интернет. Могут существовать различия в методологии сканирования Cisco Talos и Tenable, но мы предполагаем существенное сокращение число доступных для атаки устройств. Кроме того, несмотря на то, что с момента нашего первоначального бюллетеня было отмечено падение объемов сканирования, Talos наблюдал резкое увеличение попыток сканирования для Cisco Smart Install Client около 9 ноября 2017 года.

image

Нейтрализация


Вы можете определить, есть ли у вас устройствас “поднятым” на коммутаторе ПО Cisco Smart Install Client. Запуск команды show vstack config позволит вам определить, активен ли Smart Install Client. Ниже приведен пример такой команды с получением ответа на нее:
switch # show vstack config | inc Role
Role: Client (SmartInstall enabled)

Дополнительные признаки активного Cisco Smart Install Client могут присутствовать, если включена регистрация уровня 6 (информационный) или выше. Эти журналы регистрации событий могут включать, но не ограничиваются ими, операции записи через TFTP, выполнение команд и перезагрузки устройств.

Самый простой способ нейтрализовать эту проблему — запустить команду no vstack на уязвимом устройстве. Если по какой-либо причине эта опция недоступна для клиента, лучшим вариантом будет ограничение доступа через список управления доступом (ACL) для интерфейса, пример которого показан ниже:

ip access-list extended SMI_HARDENING_LIST
     permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
     deny tcp any any eq 4786
     permit ip any any

Этот тип ACL разрешает только узлам, показанным выше, доступ к Smart Install Client, что значительно ограничивает возможность реализации атаки. В дополнение к этому в наших системах предотвращения вторжения (IPS) есть сигнатуры, позволяющие определить, осуществляется ли воздействие на Smart Install Client или нет.

Поддержка


Для этого и других вопросов важно помнить о приверженности Cisco поддержке пострадавших клиентов. Все клиенты, независимо от статуса контракта поддержки, получают бесплатную помощь по реагированию на инциденты, как и помощь, предлагаемая контрактным клиентам, для любого инцидента, связанного с известными или разумно подозрительными уязвимостями безопасности в продукте Cisco. Если вы столкнулись с инцидентом с продуктом Cisco, обратитесь в Центр технической поддержки Cisco (TAC):
  • В Москве: +7 495 961 13 82
  • В Санкт-Петербурге: +7 812 363-3328
  • Бесплатный звонок по России: 8 800 700 05 22
  • В Армении: 800-721-7549
  • В Беларуси: 8 800 101, then 800 721 7549
  • В Украине (основной): 0800 301 2090 (бесплатный номер)
  • В Украине (альтернативный): +380 44 390 2400
  • В Азербайджане: 088 9999999
  • В Казахстане: 8^800-121-4321 (наберите 8, подождите 2-го сигнала и затем набирайте остальные цифры). Затем наберите PIN, 800-721-7549
  • В Таджикистане: + 992 44 600 60 40
  • В Узбекистане: 800-721-7549

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

Выводы


Чтобы обеспечить безопасность и контроль периметра, сетевым администраторам необходимо проявлять особую бдительность. Легко «устанавливать и забывать» сетевые устройства, поскольку они обычно очень стабильны и редко меняются. Достаточно вспомнить результаты нашего позапрошлогоднего ежегодного отчета по кибербезопасности, в котором мы продемонстрировали результаты нашего исследования, доказывающего, что среднее время неустранения клиентами уязвимостей в сетевом и серверном оборудовании и ПО составляет в среднем около пяти лет. Объедините это с преимуществами, которые атакующий имеет при получении доступа и перехвате управления сетевым устройством и вы поймете, что маршрутизаторы и коммутаторы становятся очень заманчивыми целями для злоумышленников. Особенно если идет речь об устройствах, стоящих на периметре организации или оператора связи.

Наблюдая за активным использованием этого вектора злоумышленниками, Cisco настоятельно рекомендует всем клиентам пересмотреть свою архитектуру, использовать инструменты Talos для сканирования своей сети и удалить Cisco Smart Install Client со всех устройств, где он не используется.

Дополнительная информация


  • Бюллетень Cisco о неверном использовании протокола Cisco Smart Install
  • Бюллетень Cisco об уязвимости RCE в реализации функции Smart Install
  • Бюллетень Cisco об уязвимости DDoS в реализации функции Smart Install
  • Заметка в блоге Cisco Talos о некооректном использовании протокола Smart Install
  • Сканер Smart Install Client, разработанный Cisco Talos
  • Данная оригинальная заметка в блоге Talos
  • Руководство Cisco по усилению защиты устройств на базе Cisco IOS и IOS XE

Let's block ads! (Why?)

Массовая атака на оборудование Cisco

Коллеги, в настоящий момент в сети Интернет фиксируется мощная ботнет-атака. Все адреса сканируются на предмет наличия свежей уязвимости в программном обеспечении Cisco IOS (CVE-2018-0171, CVSS=9,8), позволяющей удаленно выполнять команды на устройствах Cisco. Бот заходит на устройство и удаляет конфигурацию, записывая вместо нее свои файлы.

Разработчики Cisco уже выпустили патчи для обнаруженной уязвимости (https://ift.tt/2pOudoB).

Мы рекомендуем установить патчи как можно скорее. Детали под катом.
Проблема связана с некорректной валидацией пакетов в клиенте Cisco Smart Install (SMI). Воспользовавшись уязвимостью, злоумышленник может модифицировать настройки TFTP-сервера и извлечь конфигурационные файлы через протокол TFTP, изменить общий конфигурационный файл коммутатора, заменить образ ОС IOS, создать локальные учетные записи и предоставить возможность атакующим авторизоваться на устройстве и выполнить любые команды.

Устройства Cisco, которые уязвимы к этой атаке:

Catalyst 4500 Supervisor Engines
Catalyst 3850 Series
Catalyst 3750 Series
Catalyst 3650 Series
Catalyst 3560 Series
Catalyst 2960 Series
Catalyst 2975 Series
IE 2000
IE 3000
IE 3010
IE 4000
IE 4010
IE 5000
SM-ES2 SKUs
SM-ES3 SKUs
NME-16ES-1G-P
SM-X-ES3 SKUs


Чаще всего, атака фиксируется на оборудовании провайдеров.

Рекомендации:

  1. Отключить протокол SMI на сетевых устройствах (инструкция тут: blog.talosintelligence.com/2018/04/critical-infrastructure-at-risk.html).
  2. Поставить последние обновления на уязвимые сетевые устройства.

Let's block ads! (Why?)

пятница, 6 апреля 2018 г.

Мессенджеры, пора делать следующий шаг

image

В последние пару лет, мессенджеры изменили привычный ход потребления контента, whatsapp, telegram, viber, простите. Теперь весь контент сосредоточен в них, аудитория растет дикими темпами, они многое изменили, но самое главное — им еще предстоит — способ доставки контента, а если точнее — P2P CDN.

Почему P2P CDN это необходимый шаг и как все может работать (и что это вообще такое?!) — всё это рассмотрим в посте.

Вступление


С момента запуска telegram — мессенджеры начали вбирать в себя функционал соц-сетей и уже очень сложно сказать, где соц-сеть а где мессенджер, только одно может намекнуть, что перед нами — мессенджер: контент можно посмотреть только в приложении или же веб-версия очень ограничена. (Утверждение справдливо для большинства мессенджеров, включая телеграм т.к веб версия имеет не все функции)

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

Проблема


Тяжесть контента — основная проблема которую надо будет решить мессенджерам, каждый решает её как может, whatsapp (Facebook) — оплачивает сервера засчет ваших данных, telegram — пытается сделать ICO и пойти в сторону блокчейна. Но основная проблема — дороговизна инфраструктуры — никуда не уходит, просто источник денег для поддержки — меняется.

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

Решение


Решение этих проблем очень простое и я бы сказал «нативное» — P2P CDN.

Не зря в последних версиях iOS компания Apple по умолчанию всегда держит включенным Bluetooth и Wi-Fi, не зря Telegram хранит гигабайты кэшированного медиа — всё это можно использовать, причем потратив минимум времени на разработку — объединив всех пользователей конкретного мессенджера в огромную Mesh сеть.

Mesh сеть — это объединение по типу каждый с каждым, когда все пользователи приложения (например в автобусе) образуют единую сеть в которой информация может передаватся изолированно от большого интернета

Но как? зачем?


Что бы сейчас создать Mesh сеть на iOS/Android надо написать пару строчек кода — для этого сущестуют готовые фреймворки от разработчиков платформы, в play market/app store есть куча никому не нужных «offline messanger» для общения в лесу или на самолёте.

Что же можно передавать через Mesh сеть?

  1. Контент в каналах
  2. Сообщения Пользователь-пользователь
  3. Любой тяжелый контент из канала/чата/личных сообщений

Как это должно работать?


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

Звучит не оптимально, правда?


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

Другими словами — практически моментально вы синхронизируете свою ленту новостей с человеком который уже загрузил её. И в дальнейшем, приложение может оптимизировать работу, загружая контент только на 1 устройство через интернет, передаявая по Mesh сети на сосединие устройства.

Но и это еще не всё — если вы находитесь в месте с плохой связью, а вам нужно передать документ вашему другу который находится рядом с вами — мессенджер может найти его и по P2P сети передать ему документ. Что в конечном итоге сэкономит интернет трафик как вам так и другу, да и даже мессенджеру!

Whitepaper как я себе вижу работы мессенджера по P2P
Мессенджер ведёт у себя список всех каналов/чатов с ID + ключами, в древовидном режиме хранится весь контент который был загружен, аналогично с ID и ключами подписи.

Переодически идет опрос эфира на наличее узлов вашей же сети — сети мессенджера, при успешном нахождении идет сравнение сравнение контента между вами и соседом.

Фактически каждый узел будет предоставлять список того, на что он подписан (желательно с возможностью отключения такой функции для определенного канала/чата). Если найденый сосед — из списка контактов — можно производить полную синхронизацию и отправлять ему сообщения локально. Если же неизвестный — только синхронизировать тяжелый контент.

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

При поступлении нового контента, тот кто его первый получил, например А — может отправить его всем участникам сети (по типу multicast).

Причем, это схема будет работать и в более классическом виде для Mesh сетей — когда между А и Б есть еще Х — который не подписан на тот же самый канал, что А и Б — он будет просто посредником, передавая трафик между ними.

Естественно — для неизвестных узлов нельзя передавать данные номера телефона, только ID, а лучше временный ID, косвенно связанный с ID внутри мессенджера.

А что с безопасностью?


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

С разговорами и чатами ровно точно так же — вам потребуется иметь соединение с интернетом только для начала общения (проверка ключей шифрования) — дальнейшее взаимодействие может быть P2P — вы гарантировано будете уверяны, что трафик получает именно ваш друг.

И много где будет эта самая «Mesh P2P сеть»??


Если вы житель большого города — везде.

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

Итог


Давайде подведем итог — выше я описал, как с помощью незначительной доработки мессенджера сделать его:
— Дешевле для обладателя
— Повысить скорость его работы
— Сделать привлекательным в странах с дорогим/медленным интернетом
— Усилить защиту от блокировок
— Новое поколение сервисов ориентированных на P2P
— Сделать возможным частичную работу без интернета

Но, это только мысли, я очень надеюсь, что Telegram/Whatsapp/любой другой крупный мессенджер решится на такую авантюру и мы наконец-то перевернём страницу истории, открыв главу распределенного интернета. И что-то мне подсказывает, что я прав и эту главу начнут именно мессенджеры, а не браузеры или операционные системы...

Let's block ads! (Why?)

[Перевод] Apache Kafka: обзор

Привет, Хабр!

Сегодня мы предлагаем вам сравнительно краткую, но при этом толковую и информативную статью об устройстве и вариантах применения Apache Kafka. Рассчитываем перевести и выпустить книгу Нии Нархид (Neha Narkhede) et. al до конца лета.


Приятного чтения!
Введение

Сегодня много говорят о Kafka. Многие ведущие айтишные компании уже активно и успешно пользуются этим инструментом. Но что же такое Kafka?

Kafka был разработан в компании LinkedIn в 2011 году и с тех пор значительно усовершенствовался. Сегодня Kafka – это целая платформа, обеспечивающая избыточность, достаточную для хранения абсурдно огромных объемов данных. Здесь предоставляется шина сообщений с колоссальной пропускной способностью, на которой можно в реальном времени обрабатывать абсолютно все проходящие через нее данные.

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

Мудрено звучит. Давайте рассмотрим каждый из этих терминов и разберемся, что он означает. А затем подробно исследуем, как все это работает.

Распределенный

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

Горизонтально масштабируемый

Давайте сначала определимся с тем, что такое вертикальная масштабируемость. Допустим, у нас есть традиционный сервер базы данных, и он постепенно перестает справляться с нарастающей нагрузкой. Чтобы справиться с этой проблемой, можно просто нарастить ресурсы (CPU, RAM, SSD) на сервере. Это и есть вертикальное масштабирование – на машину навешиваются дополнительные ресурсы. При таком «масштабировании вверх» возникает два серьезных недостатка:

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

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

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

Отказоустойчивость

Для нераспределенных систем характерно наличие так называемой единой точки отказа. Если единственный сервер вашей базы данных по какой-то причине откажет – вы попали.
Распределенные системы проектируются таким образом, чтобы их конфигурацию можно было корректировать, подстраиваясь под отказы. Кластер Kafka из пяти узлов остается работоспособным, даже если два узла лягут. Необходимо отметить, что для обеспечения отказоустойчивости обязательно приходится частично жертвовать производительностью, поскольку чем лучше ваша система переносит отказы, тем ниже ее производительность.

Журнал коммитов

Журнал коммитов (также именуемый «журнал опережающей записи», «журнал транзакций») – это долговременная упорядоченная структура данных, причем, данные в такую структуру можно только добавлять. Записи из этого журнала нельзя ни изменять, ни удалять. Информация считывается слева направо; таким образом гарантируется правильный порядок элементов.


Схема журнала коммитов

— Вы имеете в виду, что структура данных в Kafka настолько проста?
Во многих отношениях — да. Эта структура образует самую сердцевину Kafka и абсолютно бесценна, поскольку обеспечивает упорядоченность, а упорядоченность – детерминированную обработку. Обе эти проблемы в распределенных системах решаются с трудом.

В сущности, Kafka хранит все свои сообщения на диске (подробнее об этом ниже), а при упорядочивании сообщений в виде вышеописанной структуры можно пользоваться последовательным считыванием с диска.

  • Операции считывания и записи выполняются за постоянное время O(1) ( если известен ID записи), что, по сравнению с операциями O(log N) на диске в другой структуре, невероятно экономит время, так как каждая операция подвода головок затратна.
  • Операции считывания и записи не влияют друг на друга (операция считывания не блокирует операцию записи и наоборот, чего не скажешь об операциях со сбалансированными деревьями).

Два этих момента радикально увеличивают производительность, поскольку она совершенно не зависит от размера данных. Kafka работает одинаково хорошо, будь у вас на сервере 100KB или 100TB данных.

Как все это работает?

Приложения (генераторы) посылают сообщения (записи) на узел Kafka (брокер), и указанные сообщения обрабатываются другими приложениями, так называемыми потребителями. Указанные сообщения сохраняются в теме, a потребители подписываются на тему для получения новых сообщений.

Темы могут разрастаться, поэтому крупные темы подразделяются на более мелкие секции для улучшения производительности и масштабируемости. (пример: допустим, вы сохраняли пользовательские запросы на вход в систему; в таком случае можно распределить их по первому символу в имени пользователя)

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

В Kafka соблюдается принцип «тупой брокер – умный потребитель». Таким образом, Kafka не отслеживает, какие записи считываются потребителем и после этого удаляются, а просто хранит их в течение заданного периода времени (например, суток), либо до тех пор, пока не будет достигнут некоторый порог. Потребители сами опрашивают Kafka, не появилось ли у него новых сообщений, и указывают, какие записи им нужно прочесть. Таким образом, они могут увеличивать или уменьшать смещение, переходя к нужной записи; при этом события могут переигрываться или повторно обрабатываться.

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

Так устроен поток данных

Долговременное хранение на диске

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

  1. В Kafka есть протокол, объединяющий сообщения в группы. Поэтому при сетевых запросах сообщения складываются в группы, что позволяет снизить сетевые издержки, а сервер, в свою очередь, сохраняет партию сообщений за один присест, после чего потребители могут сразу выбирать большие линейные последовательности таких сообщений.
  2. Линейные операции считывания и записи на диск происходят быстро. Известна проблема: современные диски работают сравнительно медленно из-за необходимости подвода головок, однако, при крупных линейных операциях такая проблема исчезает.
  3. Указанные линейные операции сильно оптимизируются операционной системой путем опережающего чтения (заблаговременно выбираются крупные группы блоков) и запаздывающей записи (небольшие логические операции записи объединяются в крупные физические операции записи).
  4. Современные ОС кэшируют диск в свободной оперативной памяти. Такая техника называется страничный кэш.
  5. Поскольку Kafka сохраняет сообщения в стандартизированном двоичном формате, который не изменяется на протяжении всей цепочки (генератор->брокер->потребитель), здесь уместна оптимизация нулевого копирования. В таком случае ОС копирует данные из страничного кэша прямо на сокет, практически обходя стороной приложение-брокер, относящееся к Kafka.

Благодаря всем этим оптимизациям Kafka доставляет сообщения практически так же быстро, как и сама сеть.

Распределение и репликация данных

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

Репликация данных

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

В любом случае, один из брокеров всегда “владеет” секцией: этот брокер — именно тот, на котором приложения выполняют операции считывания и записи в секцию. Этот брокер называется «ведущим секции». Он реплицирует получаемые данные на N других брокеров, так называемых ведомыми. На ведомых также хранятся данные, и любой из них может быть выбран в качестве ведущего, если актуальный ведущий откажет.
Так можно сконфигурировать гарантии, обеспечивающие, что любое сообщение, которое будет успешно опубликовано, не потеряется. Когда есть возможность изменить коэффициент репликации, можно частично пожертвовать производительностью ради повышенной защиты и долговечности данных (в зависимости от того, насколько они критичны).

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

Однако, логично спросить:

— Как генератор/потребитель узнает, какой брокер – ведущий данной секции?
Чтобы генератор/потребитель мог записывать/считывать информацию в данной секции, приложению нужно знать, какой из брокеров здесь ведущий, верно? Эту информацию нужно где-то взять.

Для хранения таких метаданных в Kafka используется сервис под названием Zookeeper.

Что такое Zookeeper?

Zookeeper – это распределенное хранилище ключей и значений. Оно сильно оптимизировано для считывания, но записи в нем происходят медленнее. Чаще всего Zookeeper применяется для хранения метаданных и обработки механизмов кластеризации (пульс, распределенные операции обновления/конфигурации, т.д.).

Таким образом, клиенты этого сервиса (брокеры Kafka) могут на него подписываться – и будут получать информацию о любых изменениях, которые могут произойти. Именно так брокеры узнают, когда ведущий в секции меняется. Zookeeper исключительно отказоустойчив (как и должно быть), поскольку Kafka сильно от него зависит.

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

  • Смещение групп потребителей в рамках секции (хотя, современные клиенты хранят смещения в отдельной теме Kafka)
  • ACL (списки контроля доступа) — используются для ограничения доступа /авторизации
  • Квоты генераторов и потребителей — максимальные предельные количества сообщений в секунду
  • Ведущие секций и уровень их работоспособности

Как генератор/потребитель определяет ведущего брокера данной секции?

Ранее Генератор и Потребители непосредственно подключались к Zookeeper и узнавали у него эту (а также другую) информацию. Теперь Kafka уходит от такой связки и, начиная, соответственно, с версий 0.8 и 0.9 клиенты, во-первых, выбирают метаданные непосредственно у брокеров Kafka, а брокеры обращаются к Zookeeper.

Поток метаданных

Потоки

Потоковый процессор в Kafka отвечает за всю следующую работу: принимает непрерывные потоки данных от входных тем, каким-то образом обрабатывает этот ввод и подает поток данных на выходные темы (либо на внешние сервисы, базы данных, в корзину, да куда угодно…)
Простую обработку можно выполнять непосредственно на API генераторов/потребителей, однако, более сложные преобразования – например, объединение потоков, в Kafka выполняется при помощи интегрированной библиотеки Streams API.

Этот API предназначен для использования в рамках вашей собственной базы кода, на брокере он не работает. Функционально он подобен API потребителя, облегчает горизонтальное масштабирование обработки потоков и распределение его между несколькими приложениями (подобными группам потребителей).

Обработка без сохранения состояния

Обработка без сохранения состояния — это поток детерминированной обработки, не зависящий ни от каких внешних факторов. В качестве примера рассмотрим вот такое простое преобразование данных: прикрепляем информацию к строке

"Hello" -> "Hello, World!"

Потоково-табличный дуализм

Важно понимать, что потоки и таблицы – это, в сущности, одно и то же. Поток можно интерпретировать как таблицу, а таблицу – как поток.

Поток как таблица

Если обратить внимание, как выполняется синхронная репликация базы данных, то очевидно, что речь идет о потоковой репликации, где любые изменения в таблицах отправляются на сервер копий (реплику). Поток Kafka можно интерпретировать точно так же – как поток обновлений для данных, которые агрегируются и дают конечный результат, фигурирующий в таблице. Такие потоки сохраняются в локальной RocksDB (по умолчанию) и называются KTable.

Таблица как поток

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

При каждом обновлении можно сделать мгновенный снимок потока (запись)

Обработка с сохранением состояния

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

Проблема с поддержанием состояния в потоковых процессорах заключается в том, что эти процессоры иногда отказывают! Где же хранить это состояние, чтобы обеспечить отказоустойчивость?

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

Итак, какой же подход лучше?

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

Потоковый процессор может сохранять свое состояние в локальной таблице (например, в RocksDB), которую будет обновлять входной поток (возможно, после каких-либо произвольных преобразований). Если этот процесс сорвется, то мы сможем восстановить соответствующие данные, повторно воспроизведя поток.

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

Обработка с сохранением состояния, соединение KStream с KTable

KSQL

Как правило, код для обработки потоков приходится писать на одном из языков для JVM, поскольку именно с ней работает единственный официальный клиент Kafka Streams API.

Образец установки KSQL

KSQL – это новая фича, позволяющая писать простые потоковые задания на знакомом языке, напоминающем SQL.

Настраиваем сервер KSQL и интерактивно запрашиваем его через CLI для управления обработкой. Он работает точно с теми же абстракциями (KStream и KTable), гарантирует те же преимущества, что и Streams API (масштабируемость, отказоустойчивость) и значительно упрощает работу с потоками.

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

Альтернативны потоковой обработке

Потоки Kafka – идеальное сочетание силы и простоты. Пожалуй, Kafka – лучший инструмент для выполнения потоковых заданий, имеющихся на рынке, а интегрироваться с Kafka гораздо проще, чем с альтернативными инструментами для потоковой обработки (Storm, Samza, Spark, Wallaroo).

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

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

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

Kafka Streams позволяет вам сформулировать собственную стратегию развертывания, когда вам это потребуется, причем, работать с инструментом на ваш вкус: Kubernetes, Mesos, Nomad, Docker Swarm и пр.

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



Когда стоит использовать Kafka?

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

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

Kafka позволяет с легкостью разграничить коммуникацию между различными (микро)сервисами. Работая Streams API, стало как никогда просто писать бизнес-логику, обогащающую данные из темы Kafka перед тем, как их станут потреблять сервисы. Здесь открываются широчайшие возможности – поэтому настоятельно рекомендую изучить, как Kafka применяется в разных компаниях.

Итоги

Apache Kafka – это распределенная потоковая платформа, позволяющая обрабатывать триллионы событий в день. Kafka гарантирует минимальные задержки, высокую пропускную способность, предоставляет отказоустойчивые конвейеры, работающие по принципу «публикация/подписка» и позволяет обрабатывать потоки событий.

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

Let's block ads! (Why?)

[Перевод] Конференция DEFCON 22. «Вооружение Ваших домашних питомцев. Боевая Киска и отказ от служебной собаки». Джен Бренсфилд

Добрый день, DEFCON! Я рад присутствовать здесь. Меня зовут Джен Бренсфильд, я главный инженер по безопасности компании Tenacity и очень люблю свою работу, поэтому, когда наступает уик-энд, я просто не могу дождаться утра понедельника! Сегодня я расскажу Вам о том, как вооружить свою кошку, это весёлая история, со своими победами, поражениями и целой кучей слайдов.

Итак, зачем мне понадобилось вооружать своего питомца?

Известно, что 15% мирового Интернет-трафика посвящено кошкам. Кроме того, я часто выступаю с презентациями по поводу систем безопасности перед техническими и не техническими специалистами. Я заметил, что технические подробности утомляют людей, они начинают скучать, закатывать глаза и думать о посторонних вещах. Чтобы привлечь их внимание, я стал разбавлять свои презентации слайдами с картинками кошек и рассказывать о них разные смешные истории. Например, я начинаю презентацию такой картинкой:

Я как раз заканчивал одну из своих презентаций, когда ко мне подошёл человек и сказал: «Я хочу подарить Вам этот кошачий ошейник, здесь есть GPS, модуль сотовой связи и можно отследить местонахождение кошки в любое время, и если Вы волнуетесь за неё, то можно отправить SMS, и Вам придёт ответ с её GPS координатами».

Я не был бы собой, если бы мне в голову не пришла мысль: «Стоит добавить в этот ошейник маленькую WiFi-ищейку, и мы получим настоящую Боевую Киску»!

Что касается служебных собак, то на другой конференции хакеров, AT Outerz0ne, я встретил Lady Merlin, которая выгуливала своего пса в шлейке — жилетке с большими карманами по бокам, из-за чего он выглядел как настоящая служебная собака. Я сказал, что это круто, в кармане, наверное, лежит Pineapple, хакерский роутер, перехватывающий весь свободный трафик? Она ответила, что нет, это всё-равно, что использовать ноутбук, который скачет у Вас на коленях, мешая работать, но Pineapple это хорошая идея!

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

На этом слайде показан настоящий морской котик. Это правда, ВМФ США использует морских животных для защиты гаваней и розыска плавучих мин. И если Вы попытаетесь незаметно проплыть в порт, чтобы взорвать его, рядом с Вами тут же вынырнет дельфин Флиппер с экшн-камерой GoPro на плавнике.

В 60-х годах под эгидой ЦРУ действительно проводились исследования возможности шпионского использования домашних кошек, как показано на следующем слайде. Это «кошка-прослушка», в ухо которой вживлён микрофон, вдоль позвоночника расположена антенна, а на груди расположен передатчик с источником питания. Такое мог придумать только человек, курящий нечто очень забористое.

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

Сейчас я расскажу о требованиях, которые предъявлялись к моей Боевой Киске.

Основным требованием было не нанести кошке вред. Я не люблю кошек, но я не хочу им вредить.
Следующим условием была комфортность «одежды», то есть кошке должно было быть удобно как одевать, так и носить свою шлейку – жилетку. Нам не нужны были мигающие огни и прочее, что превращало бы нашу кошку в лёгко обнаруживаемую добычу.

GPS должен был записывать точки маршрута с соответствующими штампами даты и времени, для того, чтобы после возвращения кошки можно было отследить, где она побывала. «Ищейка-сканер» Wi-Fi должен был синхронизировать время с GPS модулем и собирать Wi-Fi SSID и прочие сигналы, имеющие отношение к Wi-Fi, для последующего анализа.

Смысл был в том, чтобы одеть на кошку ошейник или шлейку и выпустить гулять по окрестностям. Ошейник или шлейка должны содержать в себе GPS приёмник и Wi-Fi сканер-ищейку, чтобы отмечать на карте беспроводные точки доступа Wi-Fi, как это делается в боевых условиях.

Мы также использовали дополнительные средства слежения, такие как камера Mr Lee Cat Cam, которая крепится на ошейник, трекер для домашних животных Pet Tracker и гарнитуру Garmin. Для обеспечения совместной работы всех устройств можно было использовать портативный компьютер GumStix небольшого форм-фактора Stix длиной около 11 см, но довольно дорогой, микропроцессор Cotton Candy такого же форм-фактора и миниатюрный телеприёмник Rock Chip 3066 с двухядерным процессором A9, который можно подсоединить к телевизору для приёма потокового HD видео.

Так что я взял банку пива и сел поразмышлять над всем этим. Мне нужен был малый форм-фактор, GPS, Wi-Fi и сотовая связь. Как бы могло выглядеть подобное устройство? Возможно, как смартфон, который постоянно лежит в моём кармане. Но нужно было приложение, которое работало бы на Android, то есть требовалось написать соответствующий код для Android и Wi-Fi.
Может быть, такое приложение уже существует? Я нашёл, скачал и установил из магазина мобильных приложений для «Андроид» крутое приложение под названием WIGLE WiFi, а затем выбрал кота-добровольца для своих испытаний. Это кот моего друга Ривзи по имени Скитзи.

Это чертовски крупный кот с длиной туловища 55 см, обхватом груди 50 см и обхватом шеи 30 см. Теперь нам нужен был Cat Coat, или «плащ для кота», возможно, такого вида:

Если набрать в Google фразу «кошачье пальто», Вы увидите целую кучу фотографий девушек в пальто с изображением кошечек, так что этот вариант не подходит, поэтому я стал «гуглить» фразу «собачье пальто» и нашёл то, что мне могло подойти.

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

Последовательность действий изображена на слайдах.

Здесь он выглядит немного испуганным.

Затем мы выпустили кота…

И это окончилось неудачей! Пролезая сквозь забор, кот потерял свой плащ, видимо, он висел на нём слишком свободно.

Мы поймали кота, снова одели на него плащ, затянули поплотнее и повторили попытку. И вот сидим и ждём, и ждём, и ждём… мы прождали его 18 часов, а когда открыли дверь, то увидели, что кот вернулся голым, без своей боевой попоны.

Нас постигла неудача! Мы отследили последнюю известную отметку GPS, но попоны там не было. Из этого эксперимента мы извлекли такие уроки:

  • с котами очень трудно работать;
  • всегда тестируйте свою работу, прежде чем посылать дорогостоящее оборудование на улицу,
    при совершении дорогих покупок на Amazon мы можем получить Prime-аккаунт;
  • беспокойство о том, чтобы коту было удобно в одежде, приводит к потере одежды,
    нужно использовать устройство с такими же возможностями, но гораздо меньшего размера.

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

Я стал разбираться, что собой представляет этот «Ардуино»:
  • это открытая электронная платформа, основанная на простом в использовании «железе» и «софте», которая интересна для тех, кто занимается интерактивными проектами;
  • здесь имеется много слотов расширения для подключения датчиков, сами платы Arduino можно устанавливать друг на друга;
  • используется при создании роботов, машинок с дистанционным управлением, систем домашней безопасности и т.д.

Билли использовал чип «Ардунино» для проверки продуктов холодильнике, для роботизированной «руки» и для своих видео-игр. Он имеет действительно крохотный форм-фактор, это открытый ресурс и стоит очень дёшево.

К недостаткам «Ардуино» относится бедная документация, сомнительное качество и то, что требуется целая вечность, чтобы в нём разобраться.

Это всё хорошо, но я никогда не работал с «Ардуино», фирменным ПО и наборами маленьких чипов, я не являюсь профессиональным кодером и не умею паять. Но Билл сказал: «Не беспокойся, это легко»!

Мой план действия состоял из таких пунктов:

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

Я прочитал книжку, которая шла в комплекте с Arduino Unо, и ещё много руководств по инжинирингу и электронике, достал кучу светодиодов, чтобы испытать их работу с Arduino, хотя не собирался использовать никаких лампочек. Самым потрясающим было то, что я обнаружил программные библиотеки для Wi-Fi, GPS и SD-карты.

На сайте Джереми Блюма jeremyblum.com я нашёл много видео о конструировании всяких устройств на основе «Ардуино».

После всего этого я посчитал, что стал экспертом в этом деле. Итак, у меня была плата расширения Wi-Fi Arduino и плата расширения GPS Itead Studio.

Мне нужно было придать плате Wi-Fi функцию сборщика данных с записью на SD-карту, а плате GPS – функцию трекера, также с возможностью записи данных на карту, и объединить их в одно целое.

С платой Wi-Fi всё прошло идеально: установка была лёгкой, драйвера, скачанные с сайта Arduino, работали, после небольшой возни с параметрами и переменными всё получилось, как надо.

А вот с GPS было не так легко. Существует строка NMEA, National Maritime Electronics Association, в которой прописаны стандарты параметров работы GPS – приём, передача, координаты и прочее. Процесс загрузки модуля может производиться с любого места на земле – Вы просто подсоединяете этот модуль к источнику питания, и он начинает «слушать» космос. Устройство засекает 3 спутника, определяет позицию, и это занимает от 2 до 15 минут в зависимости от местных условий.

Плата расширения GPS также имела бедную документацию и в коробке с набором не было никакой инструкции. Мне потребовалась неделя, чтобы понять, почему модуль не работает, и в конце концов я выяснил, что ему нужна скорость передачи данных 34840 бод, которую я до сих пор нигде не могу найти.

В общем, я собрал все компоненты вместе… и потерпел неудачу.

Оказалось, что используется больше 80% памяти Arduino, количество библиотек и переменных слишком велико, и 32 КБ памяти Arduino Uno совершенно не достаточно — чип просто не может работать с такой нагрузкой.

Поэтому я купил микропроцессор Arduino Mega 2560 с 256 КБ памяти, опять соединил всё вместе, запустил, и оно заработало!

Arduino Mega 2560 имел:

  • больше памяти, что было намного лучше;
  • больше портов, что было намного лучше;
  • больший размер, что было намного хуже.

В поисках альтернативы я облазил весь Интернет и нашёл чип Arduino Mega Mini от компании JK Devices, который был меньше стандартного Mega.

Я продолжил поиски платформ маленького размера и нашёл микропроцессор под названием Spark Core, который представлял собой комбинацию двух модулей на одной печатной плате – спереди располагался модуль Wi-Fi, а сзади – чип Arduino.

К нему я докупил GPS чип марки GP-635T и плату для карты памяти SparkFun MicroSD Breakout.

Поскольку мне сказали, что доставки Arduino Mega Mini придётся ждать несколько недель, а все остальные платформы были или слишком велики, или имели слишком маленький объём памяти, я остановил свой выбор на продукции Spark. Платформа Spark Core имела такие технические характеристики:

  • процессор ARM 32-бит М3;
  • память объёмом 128 КБ, больше, чем мне нужно;
  • совместимость с SPI и I2С, то есть протоколы для взаимодействия микроконтроллера, внешних компонентов и сети интернет;
  • Wi-Fi чип TI CC3000;
  • совместимость с Arduino отсутствовала.

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

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

  • кто-то разместил библиотеки для SD карт на форуме, и они мне подошли!
  • кто-то разместил на форуме библиотеки для GPS, они работали и были совместимы с моим GPS модулем!

Однако с библиотеками для Wi-Fi было сложнее, потому что Spark Core был создан по принципу «интернет вещей», а Wi-Fi представлял собой фоновую службу, которую нельзя было с ним связать.

Но я хотел их связать! Для чипа Adafruit СС3000 существовали библиотеки, которые можно было скачать с сайта Adafruit, чтобы использовать его для сбора данных Wi-Fi, я скачал их, установил, и это сработало!

Итак, у меня был GPS, работающий на Spark, SD-карта, совместимая со Spark, набор SSID, работающий на Spark, и теперь мне нужно было соединить всю эту мелочь вместе. Для этого понадобилась пайка!

Кто из Вас умеет паять, поднимите руки! Вы видите – всего пару человек в зале! Изучение искусства пайки стало моим последним занятием. При этом я усвоил несколько важных правил, например, что паяльник нужно держать не за жало, а за рукоятку. Второе правило заключалось в том, что не нужно класть руки где попало, чтобы не получить ожог паяльником. Правило три гласило, что в интернете всё выглядит легко, но в действительности это далеко не так.

Итак, сначала я разместил на монтажной плате GPS-модуль и кард-ридер для SD-карты и связал всё это с контроллером Spark. Выглядело неплохо, и я решил проверить, как оно работает.

Домашние испытания прошли великолепно! Я взял устройство с собой и прогулялся вокруг дома – всё работало идеально! Оно показало, что вот моя сеть, вот здесь Wi-Fi моего соседа и так далее. Но когда я взял его с собой в автомобиль и немного проехался, то потерпел фиаско. В чём же была причина?

В том, что Spark был ярким представителем «Интернета вещей», а это означает, что он не должен никогда отсоединяться от Интернета! В данном случае от домашней сети Интернет. Я общался с ребятами на форумах по поводу того, что происходит с устройством при езде в автомобиле. Выяснилось, что чип Spark должен быть подключён к известной ему точке доступа, чтобы начать работать. Получалось, что пока он подключён к моей домашней сети Wi-Fi, всё работает без ошибок, но стоит отъехать на полмили, устройство перестаёт работать.

Я мог просканировать уникальный 32-х значный код SSID, который используется для идентификации моей беспроводной локальной сети. Чтобы Spark мог к ней подключится, он использует именно этот код. Происходило вот что: когда контроллер терял сигнал домашней сети WI-FI и пробовал подключиться снова, то искал сеть именно с этим SSID, но не находил её. Значит, мне нужно было просто успеть удалить этот код из памяти чипа, чтобы после потери сигнала одной сети он смог подключаться к другим сетям. После того, как я это проделал, проблем с WiFi больше не возникало.

Следующим этапом было испытание GPS. Я проехался немного и получил данные о точках W-Fi, всё отлично работало, я проехал ещё полмили и проверил координаты GPS. Я был на шоссе, а по карте выходило, что я нахожусь в озере. Вернувшись домой, я выяснил, что имеющиеся GPS библиотеки не могли правильно конвертировать данные спутников в координаты на карте. Получалось, что у меня нет библиотек GPS.

Тогда я раздобыл TinyGPS++, набор библиотек, которые извлекают данные NMEA, полученные GPS модулем, такие, как позиция, высота, скорость, дата, время, курс и т.д., и передают их чипу Arduino. Это было то, что мне нужно, но оно не работало со Spark. Я поговорил с Биллом, и он посоветовал использовать библиотеки для порта Ардуино.

Я снова погрузился в область космических наук. Это как с ракетой, когда Вы заправляете её топливом, ставите на стартовую позицию, нажимаете красную кнопку, и она взрывается. Или ракета сначала взлетает, а потом взрывается. Или всё-таки уходит в космос, и тогда Вы говорите: «Да, вот это и есть космическая наука»! Несколько хуже, когда внутри ракеты сидит обезьянка. В общем, я выяснил, что нужно поменять местами Arduino и Sparks, чтобы всё заработало. Для этого мне пришлось заняться кодировкой библиотек для портов Sparks, что ничуть не легче космических наук. Так что следующей специальностью, которой я овладел, была специальность кодера. Зато у меня наконец-то всё заработало как надо.

Следующей проблемой стало энергопотребление. Нужно было подумать, как улучшить его характеристики. Я решил использовать миниатюрный аккумулятор Elite 3,7 В ёмкостью 500 мАч, который мой друг Рикки использовал для своих авиамоделей, и приступил к тестированию его работы.

Выяснилось, что вариант экономии энергопотребление путём периодического отключения и включения питания всего устройства мне не подходит. Тогда я сделал так, чтобы можно было вводить в режим глубокого сна главный чип, при этом модуль GPS продолжал работать. «Засечки» данных каждые 30 секунд разряжали аккумулятор за 4 часа, сбор данных каждые 10 минут увеличивал время работы до 8 часов.

Наконец настало время делать ошейник. Выяснилось, что отпаивать детали в два раза веселей, то есть сложней, чем припаивать, и я спалил при этом много всякой полезной мелочи. Интернет снова мне не помог, зато ролики на YouTube несколько улучшили понимание процесса. Я спросил своего друга Джо, что мне делать, и он посоветовал обратиться к специалистам NovaLabs из Рестона, штат Вирджиния. Это был Тэд, сумасшедший учёный и по совместительству злой гений, который помог мне изучить EAGLE, и Брайан, мастер пайки, который объяснил мне, что правильному железу нужна правильная пайка. Они существенно облегчили мне жизнь.
Дальше я приступил к разработке конструкции кошачьего ошейника. Его можно было сделать несколькими способами. Джо предложил сшить вместе несколько лент и вставить между ними моё оборудование. Я пошёл к Майку и взял у него такую красивую леопардовую тесьму, которая идеально подходила нашему коту.

Теперь мне нужно было сшить их вместе. Кто из Вас знает, как это делается? Это искусство наших бабушек, так что мне понадобилась бабушка. Это бабушка моей жены, её зовут Нэнси, и она очень рада с Вами познакомиться.

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

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

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

Итак, мы вставили электронику в ошейник, одели его на кота и отправили его гулять. Когда он вернулся домой, я снял ошейник и ничего не обнаружил! Я проверил электронику – всё работало! Мы снова одели ошейник на кота и отправили его на улицу. Он залез в кусты и завис там на 20 минут, вылизывая себя. Я сказал Ривзу об этом, он подошёл к кустам, принялся их трясти, и кот оттуда выскочил.

Мы решили изменить технологию работы таким образом:

  • вынести ошейник на улицу и подождать соединения с GPS в течение 5-10 минут;
  • принести кота к ошейнику и одеть ошейник на кота;
  • отправить кота гулять в ошейнике.

Наконец-то нас ждала УДАЧА!

Данные, извлечённые из ошейника, выглядели так:

Здесь были дата, время, широта, долгота, название точек доступа Wi-Fi SSID, сигнал и его расшифровка.

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

Мы нашли ещё одну кошку, которую звали Коко, и испытали ошейник на ней. Полученные данные были намного разнообразней, а зона её перемещений намного шире.

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

Вот так мне удалось создать свою Боевую Киску!

Осталось решить вопрос, как можно усовершенствовать служебную собаку.

Итак, служебных собак в Интернете троллят больше, чем кого-то ещё. Для них можно использовать продукт компании Smoocon под названием WiFi Pineapple и дистанционный выключатель телевизоров TV В Gone на основе контроллеров Adafruit / Radiosnack. Устройство TV В Gone используют для того, чтобы одновременно отключать все телеприёмники в публичных местах. Всё это можно разместить в шлейке-жилетке, или собачьем рюкзаке. Для того, чтобы всё это работало, нужна программа Karma для обработки ответов на запросы в режиме Answers Probes, DNS Spoof, который направляет всё в Pineapple, и модуль RandomRoll.

На следующем слайде показано, как выглядит TV В Gone, разобранный на части. Для его потребовались мои таланты пайщика, в результате я получил компактный модуль, который модифицировал, выпаяв светодиоды.

Теперь всё это нужно было пропатчить, не приведи господь кому-нибудь заниматься подобным! С этим мне помогла Cept Irina & Friends из JoAnn’s Fabrics, расположенной в Стерлинге, штат Вирджиния. Так нам удалось создать комплект оборудования под названием «Denial of Service Dog», то есть «cобака для отказа сервиса» с модулем Wi-Fi.

У меня есть видео, где показано, как это работает. Вы видите, что снаружи шлейки расположен блок со светодиодом, и когда я нажимал выносную кнопку, он начинал мигать зелёным светом, показывая, что телепередача идёт, а затем автоматически выключался. Сейчас я покажу, как подключение выглядело на экране смартфона, когда я сидел в автомобиле. Сначала я нахожу точку доступа к Wi-Fi сети, присваиваю ей имя DEFCON и пытаюсь подсоединиться, при этом Karma сообщает, что «вот она я», после чего соединение устанавливается, и я выхожу в Интернет. Всё работало отлично, и теперь нам нужна была собака-доброволец.

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

Вот как его рюкзак выглядел сбоку и сверху.

Поднявшись на лапы, пёс принялся отряхиваться, что стало серьёзным испытанием для электронной начинки, и я в очередной раз похвалил себя за то, что научился хорошо паять.
После этого мы отправились в ресторан. Нас пустили туда с собакой без проблем, потому что мы сказали, что у нас служебная собака (в США служебными называют собак, которые помогают людям с ограниченными возможностями). Я нажал кнопку записи GoPro, но от волнения перепутал и нажал не ту, что надо, там всего было 2 кнопки. Мы сели за столик, к нам подошёл официант и спросил: «Почему на его жилетке написано cобака для отказа сервиса»? Мы ответили: «Знаете, сегодня целый день к нам все подходят с этим вопросом, мы не отвечаем, они разворачиваются и уходят»!

Телевизоры в ресторане были выключены, поэтому мы не смогли проверить работу нашего устройства и решили пойти в спортивный бар. Там телевизор был включён, но я не рискнул опробовать на нём наш TV В Gone, потому что люди смотрели чемпионат World Cup, полуфинальный матч с Аргентиной, и отключать трансляцию было опасно для здоровья.

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

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

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

В результате испытаний мы выяснили следующее:

  • несколько несчастных жертв случайно подключились к Karma и их устройства выдали сообщение «ошибка регистрации»;
  • только один человек спросил, почему на шлейке пса написано «cобака для отказа сервиса»,
    большинство людей, видя нашего пса, говорили: «Хорошая собачка»!

Выученные мной уроки заключались в следующем:
  • технически подкованный любитель без опыта прошивки устройств может создать функциональный ошейник для Боевой Киски за сравнительно короткое время;
  • в 2014 году всё ещё существуют незащищенные точки доступа Wi-Fi;
  • множество устройств всё ещё представляют собой пробные варианты;
  • до сих пор не существует патча от человеческой глупости;
  • с кошками и собаками действительно трудно работать!

Я хочу поблагодарить всех, кто принимал участие в моём проекте и сказать, что очень горд присутствовать здесь, среди Вас, ведь вместе мы способны делать великие дела!


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)