Technologique
660 subscribers
143 photos
3 videos
42 files
945 links
Deeply involved developers about various aspects, tendencies & conceptions of programming technologies, FLOSS, Linux, security, cloud infrastructures & DevOps practices, distributed systems, data warehousing & analysis, DL/ML, web3, etc.
Author: @andrcmdr
Download Telegram
https://www.youtube.com/watch?v=y_RiG_9jEJ0

https://blog.docker.com/2017/01/whats-new-in-docker-1-13/

https://opennet.ru/opennews/art.shtml?num=45891

Выпуск cистемы управления контейнерной виртуализацией Docker 1.13

После шести месяцев разработки подготовлен релиз инструментария для управления изолированными Linux-контейнерами Docker 1.13, предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. Docker позволяет, не заботясь о формировании начинки контейнера, запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Код Docker написан на языке Go и распространяется под лицензией Apache 2.0.

Основные изменения:

Расширены возможности режима Swarm, начиная с прошлой версии интегрированного в состав движка Docker и предоставляющего средства кластеризации для упакованных в контейнеры приложений. Swarm даёт возможность управлять кластером из нескольких хостов Docker по аналогии с работой с одним виртуальным хостом. В новой версии обеспечена поддержка использования compose-файлов (docker-compose.yml) для развёртывания сервисов в режиме Swarm (сложный мультисервисный стек теперь можно развернуть на нескольких хостах одной командой "docker stack deploy"). Из плюсов применения docker-compose.yml отмечается возможность указания желаемого числа экземпляров каждого сервиса, применение политики обновления и определения условий запуска сервисов.
Улучшена обратная совместимость на уровне взаимодействия управляющего демона с инструментарием командной строки (CLI). Если раньше использование новой версии клинта со старой версией демона приводило к проблемам (выводилась ошибка "Error response from daemon: client is newer than server"), то начиная с выпуска 1.13 новые версии CLI учитывают особенности прошлых выпусков демона и могут использоваться для управления ими, что значительно упрощает организацию управления инфраструктурой с одной системы. На случай если клиент пытается выполнить действие, которое ещё не реализовано в демоне в новом выпуске добавлены средства для согласования функциональности клиента и сервера;
Реализованы две новые команды "docker system df" и "docker system prune" для отображения сведений об используемом дисковом пространстве и для выполнения операции очистки неиспользуемых данных;
Проведена реструктуризация интерфейса командной строки, все команды реорганизованы для более логичного соответствия объектам, с которыми они взаимодействуют. Например, команды "list" и "start", применяемые для вывода списка контейнеров и запуска контейнера, перенесены в команду "docker container" и теперь являются подкомандами ("docker container list" и "docker container start" вместо "docker list" и "docker start"), а команда "docker history" преобразована в "docker image history". Поддержка старого синтаксиса команд сохранена для обеспечения обратной совместимости;
Расширены средства мониторинга. Добавлена экспериментальная команда "docker service logs", позволяющая упростить отладку сервисов за счёт избавления администратора от ручного сбора логов из отдельных хостов и контейнеров. При выполнении "docker service logs" логи из всех контейнеров, в которых выполняется указанный сервис, будут перенаправлены в текущую консоль. Кроме того, в новой версии появилась точка сбора параметров (/metrics) с метриками контейнеров, образов и состояния управляющего демона, выводящая данные в стиле Prometheus;
В команде "docker build" появился новый флаг "--squash", позволяющий агрегировать все производимые при сборке слои файловой системы в один сводный слой, что может оказаться полезным при создании минималистичных образов контейнеров. Ценой такого объединения является увеличение накладных расходов при перемещении образов и невозможность совместного использования таких контейнеров. В команду сборки также добавлен флаг "--compress" для сжатия сборочного контекста, отправляемого из CLI в управляющий демон, что позволяет ускорить сборки, при которых осуществляется взаимодействие с демонами на других хостах;
Началось бета-тестирование Docker для облачных платформ AWS и Azure.
Сейчас будет длинный, но интересный пост про ИИ. Когда нейросеть распознаёт образ, она не видит "образы" в привычном для нас смысле. Нейросеть - это черный ящик. Внутри него находятся несколько слоёв коэффициентов ("нейронов"), которые определенным образом меняются в зависимости от того, что подают на вход. Допустим, мы научили нейросеть распознавать лошадей, обучив её на нескольких миллионах фото. Если теперь подать на её вход любое изображение, нейросеть преобразует его в многослойный набор коэффициентов и сравнит с теми наборами, которые получались, когда ей показывали лошадей.

"Лошадь" или любой другой образ для нейросети - это не картинка, а набор чисел. И вот здесь начинается интересное. Потому что образ "страус" может преобразовываться внутри нейросети в очень похожий набор чисел. И если, зная это, совсем немного подправить изображение лошади (изменение будет даже незаметным для человека), то нейросеть будет с уверенностью "видеть" вместо лошади страуса. Или любой другой образ. Для этого даже не надо знать, как нейросеть устроена внутри - её можно обмануть не открывая "чёрный ящик", просто показывая картинки и записывая её реакцию.

Вот подробная статья в Popular Science с иллюстрациями, не поленитесь посмотреть. Вжух - и нейросеть видит вместо здания страуса, вместо панды - обезьяну, а вместо одних дорожных знаков - совсем другие. Кто и зачем всё это исследует - по ссылке.
http://www.popsci.com/byzantine-science-deceiving-artificial-intelligence

Подобным атакам подвержены и системы распознавания речи. Учёные разработали специальные голосовые команды, которые для человеческого уха звучат как белый шум, но при этом голосовые ассистенты (вроде Siri или Google Now) их слышат и распознают. Встроив скрытую команду в выпуск радио, ТВ, или в Youtube-ролик, злоумышленнники могут направить людей на вредоносный сайт, украсть их личные данные или деньги. Это не фантастика: недавно в Техасе домашние устройства Alexa некоторых телезрителей отреагировали на голосовую команду, которую произнёс ведущий местной передачи. Правда, мой смартфон эти команды не распознал. Но на деморолике всё работает, посмотрите: http://www.hiddenvoicecommands.com/demo

Подробнее: https://www.theatlantic.com/technology/archive/2017/01/the-demon-voice-that-can-talk-to-your-smartphone/513743/

Посты по теме:

В чём проблема "чёрного ящика" ИИ и как её можно решить:
https://t.me/brodetsky/608, https://t.me/brodetsky/510

Как исследователи научились копировать алгоритмы машинного обучения из "черного ящика": https://t.me/brodetsky/565

Как работает перенос стиля с помощью нейросетей в приложениях вроде Prisma:
https://t.me/brodetsky/642
Весьма интересный спич по инфобезу с интересным гостем.
Вывод - чем сильнее мы зависим от цифровых технологий и данных, тем более небезопасен наш мир, а движемся мы к connected world и грань между доступом и использованием информации во благо или во зло становится всё тоньше, и всё более нам требуется экспертиза в области информационной безопасности.

https://www.youtube.com/watch?v=Yb7CjQBQ9XE

http://oper.ru/news/read.php?t=1051618634

Аудио версия:
http://oper.ru/video/getaudio/interview_infosec.mp3
Instagram пару часов назад наконец-то запустил Live видео трансляции в приложении для всей сети.

В течение некоторого времени Live видео трансляции станут доступны всем пользователям сети.

Ранее этот функционал был доступен только в бета версии приложения из Google Play для пользователей из западных штатов.

https://www.instagram.com/p/BPqAhqzAJzq/

PS: Не Periscope'ом единым!
Друзья, в эту пятницу, 27 января в 20:00 (UTC+6) компания Klika Tech (Минск, Беларусь) будет проводить вебинар (образовательный онлайн митап) — "Writing Scalable React Applications", на русском языке, по фронтэнд фреймворку React.js, который используется для работы с современными frontend веб-интерфейсами и для создания SPA (single page application) client-side веб-приложений.

Ведущим вебинара будет практикующий разработчик Михаил Ошер (Klika Tech).

Вебинар будет состоять из двух лекций по React.js:

· React Basics

· Dive into React

На первой лекции автор расскажет, что такое React и опишет его плюсы/минусы по отношению к другим решениям.

Первая лекция будет проводиться в эту пятницу, 27 января.

Вторая лекция, более практическая, где автор расскажет, как писать приложения с использованием библиотеки React.

Вторая лекция будет проводиться примерно через 2-3 недели. Дата и время будут уточнены заранее. Все записавшиеся в форме участники будут оповещены по электронной почте.

Лекции будут интересны всем, кто слышал о языке JavaScript или уже пишет на нём, кто хочет познакомиться с библиотекой React.js и научиться создавать с ее помощью SPA приложения любой сложности.

Трансляция будет проводиться на YouTube канале Klika Tech.

Ссылка на трансляцию первой лекции вебинара - https://www.youtube.com/watch?v=Pvdz5IytJGA

Ссылка на трансляцию и время проведения вебинаров будут высланы на почту.
Для этого запишитесь на вебинары в очень простой форме (Имя, E-mail):

· React Basics — https://goo.gl/pXsoeD

· Dive into React — https://goo.gl/g16QMB

Это необходимо для фидбэка автору.

Присоединяйтесь друзья в эту пятницу - будет интересно!

Об авторе:

Михаил Ошер, Fullstack Developer. За спиной более 6 лет коммерческой разработки, последние 3 года занимается исключительно SPA приложениями. Считает обязательным понимание SOLID/GRASP при написании приложений. Любит проектировать сложные системы. Имеет хобби следить за новинками в области frontend разработки и пробовать их на небольших проектах.

О компании Klika Tech:

http://klika-tech.com/about-us

YouTube канал Klika Tech:

https://www.youtube.com/channel/UC8piUMzAdKymweFEy3_kKrg
https://www.bloomberg.com/news/articles/2017-01-17/qualcomm-forced-apple-to-exclusively-use-modem-chips-ftc-says

http://www.theverge.com/2017/1/17/14303910/qualcomm-allegedly-bribed-apple-wimax-iphone-ft-complaint

http://hitech.vesti.ru/news/view/id/10781

http://hitech.vesti.ru/news/view/id/10778

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

Но регистрация патента на технологию в органах США (патентном бюро) доказывает лишь её авторство и первенство регистрации прав интеллектуальной собственности на технологические изделия, но далеко не первенство в создании технологии или её технологическое превосходство над другими аналогами.
В данном случае патенты и "патентный троллинг" - это инструмент недобросовестной конкуренции, для получения собственной выгоды, сегментации и увеличения доли в сегменте рынка и соответственно прибыли компании.
"Divide et impera" - сейчас это закон корпоративной рыночной экономики.

PS: "Клин клином выбивают" - теперь и сама Apple попала под патентный троллинг со стороны сначала Nokia (до Нового года), а теперь и Qualcomm.
Грядёт новая волна буткит и руткит кода с физическим распространением через USB.

До Нового года ребятами из Positive Technologies была обнаружена и опубликована уязвимость отладочного интерфейса DCI новых процессоров Intel семейств от Skylake и выше.

https://youtu.be/6soT3hZK_T4

https://youtu.be/QuuTLkZFsug

https://habrahabr.ru/company/pt/blog/318744/

https://xakep.ru/2017/01/19/intel-dci-problem/

http://safe.cnews.ru/news/top/2016-12-29_protsessory_intel_mozhno_vzlomat_po_usb

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

При помощи буткита, системного приложения (написанного на Rust с использованием NDK/Bionic), на Android устройстве и при подключении такого заражённого аппарата на "зарядку" через интерфейс MHL USB OTG и USB 3.0 порт к лэптопу на Skylake, через активированный несколькими инструкциями кода отладочный DCI интерфейс процессора удалось доставить руткит прямо в нужную область памяти лэптопа для внедрения кода в модули гипервизора ядра Linux используя инструкции и возможности виртуализации процессора Skylake, Intel VT (VT-x, VT-d), код руткита при этом будет исполняться в пространстве привелегий ядра и иметь доступ (как модули ядра или драйвера) к памяти всех процессов, реальной адресации, системным вызовам ядра, файловой системе и устройствам. Далее после доставки код по программе копировал сам себя (asm-quine trick) в памяти и размножал, записывал свои копии в загрузочные сектора (gpt, бутсектора системного раздела, в т.ч. резервные), разделы ФС (/boot, добавлялся в системный загрузчик для загрузки до ядра, добавлялся внешним модулем ядра как виртуальный драйвер, дампил себя в swap), записывал и скрывал свой код в резервных и скрытых блоках ФС и главное, код записывался как модуль в UEFI BIOS! Таким образом избавиться от всех копий руткита будет очень сложно - слишком много точек управления для передачи кода на загрузку.
Сам код работоспособен уже после передачи и внедрения на машину, даже без необходимости её перезагрузки.
Но чтобы убедиться что цепочка загрузки работоспособна после копирования было сделано так, что код вгоняет процессор в лимб (halt state), после чего есть только один вариант - перезагрузка (с загрузкой всех модулей руткита разумеется 😁).

Функциональность руткита.

Сразу возникла идея слушать помещение через микрофон веб-камеры (все веб-камеры имеют унифицированный интерфейс управления через USB шину - и да при активации сенсора камеры светодиод можно не включать 😉) и регулировать параметры чувствительности микрофона более высокоуровневыми системными вызовами, через ALSA и PulseAudio.
Обмозговали и сделали.
После перезагрузки и активации всех модулей для работы руткита, активировался микрофон лэптопа, снимал с него данные и отправлял их по сети в виде потокового фонового шумового трафика (не более 32 Kbit/s).

Красота!

После этого стало действительно страшно от осознания в насколько опасном технологическом мире мы с вами сейчас живём, не только софт, но и железо уязвимо и уже не до наших гикерских шуток - на ядрах архитектуры Skylake уже поставляются серверные процессоры Xeon, имеющие как виртуализацию так и отладку через DCI. Никто не знает, кто и что коннектит через USB к VPS/VDS серверам вашего проекта на удалённом виртуальном хостинге при их обслуживании (live usb flash, iLo usb, firmware updates) или регулярном мониторинге имея физический доступ к серверам.

Хоть я и не верю уже давно в святость американских корпораций (наверняка это сделано специально для упрощения распространения зловредов спецслежбами 😆) - тем не менее мы наваяли отчёт в Intel и её подразделение безопасности McAfee, приложили код.
Будем надеяться что пофиксят, обновлением bios firmware microcode update.
What am I supposed to do and how to survive:

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

— На процессорах Skylake не включайте при сборке ядра Linux модули гипервизоров Xen и KVM, без острой необходимости, отключайте поддержку VT-x и VT-d при сборке ядра и в BIOS.

— Используйте готовые сборки с патчами и патч-сетами для ядра, сборка ядра Linux должна быть с поддержкой nx-bit и security модулями (SELinux, AppArmor) и патчами grsecurity и PaX - в этом случае лучше юзать микро-дистрибутив Alpine Linux (возможно даже в Docker контейнере) для создания безопасного окружения для вашего проекта в удалённом дата-центре.

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

— Отключите в Android (в разделе Securuty меню настроек) установку приложений из неизвестных источников. Отключите режим разработчика, отладку через USB и ADB на смартфоне. Отключите MTP, PTP, DMS, DLNA и любые другие поддерживаемые протоколы передачи данных между смартфоном и компьютером. Активируйте любую передачу данных только по необходимости и после отключайте.

— Заряжайтесь только обычной зарядкой (dumb charger).

— Think securely - keep safety!

Всем добра!
Страшный сказ о том как программер (сотрудник проекта) в ночь с 31 января на 1 февраля по неосторожности дропнул продакшн БД сервиса GitLab.
Хранилище репозиториев не было затронуто - только сам сервис GitLab для управления кодовой базой проектов.
Из бэкапов (репликаций postgresql) восстановить ничего не получается, востанавливают с образа LVM тома с разделом ФС, содержащим копию БД, сделанного как раз на случай неудачи за несколько часов до инцидента - весьма показательный случай, когда у сервиса нет нормальной политики партицирования и постоянной репликации данных, и разумной политики доступа к данным на запись и изменение.

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

Вся информация в одном документе:
https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

Лучше конечно свои репозитории и движок GitLab поднимать локально, и нести всю ответственность за свои данные самому.

Ребята даже live stream сделали для большей прозрачности процесса восстановления данных, отслеживания ситуации и снятия социального напряжения - на заметку всем кто хочет превращать минусы в плюсы, а факапы в шоу. Хотя ребятам сейчас адреналина хватает и без шоу. :)

https://youtu.be/nc0hPGerSd4

https://opennet.ru/opennews/art.shtml?num=45957
Technologique
Страшный сказ о том как программер (сотрудник проекта) в ночь с 31 января на 1 февраля по неосторожности дропнул продакшн БД сервиса GitLab. Хранилище репозиториев не было затронуто - только сам сервис GitLab для управления кодовой базой проектов. Из бэкапов…
Официальная статья с полным изложением ситуации по данному инциденту в блоге уже восстановленного GitLab

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

Ребята пытались защититься и снять нагрузку от DDoS с БД, но пошли не путём маршрутизации трафика запросов, а путём самого слабого места PostgreSQL, её репликации.

Это ещё раз доказывает что PostgreSQL неудачное решение для распределения данных - она плохо масштабируется в распределённых системах и для неё реально мало качественных сторонних решений и инструментов для удобной работы с данными и управления БД, в сравнении с MySQL и тем более MariaDB, в которой все возможности шардинга, репликации и in-memory кэширования горячих данных встроены в движок или реализованы множеством сторонних инструментов.

Тем не менее с помощью OpenStack компонентов Cinder (с использованием платформ-хранилищ и файловых систем Ceph и GlusterFS), компонентов Manila, Swift и Trove можно настроить масштабирование и кластеризацию практически любой БД, но это всё внешние примочки и clusterfuck science - все возможности должны идти из коробки встроенными в движок БД.

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

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

Теперь в GitLab должны из этой ситуации сделать выводы, увеличить надёжность, ввести политику репликации и политику доступа к данным, лучше продумать архитектуру проекта.

Я честно сам не ожидал, что у такого серьёзного проекта как GitLab будет такая примитивная архитектура хранения данных - это первое, что необходимо продумывать в проекте, т.к. хранение и целостность данных это самая критическая точка в любом сервисном проекте.
Forwarded from Spalmalo Tech Talks
Обычно не публикую такое, извините, но это ооочень смешно https://twitter.com/thepracticaldev/status/826820232278847490 По ссылке видео.
Kernel.org отключит доступ по протоколу FTP к репозиторию версий исходного кода ядра Linux ftp://ftp.kernel.org 1 марта и к зеркалам других Open Source проектов ftp://mirrors.kernel.org 1 декабря этого года.
Останется доступ только по http/https.

https://kernel.org/shutting-down-ftp-services.html

https://opennet.ru/opennews/art.shtml?num=45935
😁😂
Распределённые параллельные вычисления наступают со всех сторон!

Если у вас есть код на Go, Rust или любом другом современном языке, поддерживающем какую-либо модель многопоточности и есть желание опробовать ваш код на кластере с процессорами Intel Xeon Phi - теперь такая возможность есть, вэлкам!

https://habrahabr.ru/company/intel/blog/320972/
https://youtu.be/MYxgfpWW5Q8

Недавнее испытание скоростной капсулы выполненной по технологии Hyperloop, двигающейся в туннеле и разгоняемой реактивным двигателем, разработанным в SpaceX.
Заметьте внутреннюю нарезку трубы туннеля - как у ствола винтовки. Это для улучшения вихревой аэродинамики и уменьшения сопротивления воздуха.
Можно почувствовать себя пулей в таком стволе - видео снято в формате VR 3D, всю прелесть которого вы можете уже сейчас прочувствовать на вашем смартфоне (и в очках CardBoard, если есть), открыв видео в официальном приложении YouTube (используйте смартфон как перископ) или плейере JauntVR - http://jntvr.co/Hyperloop (https://play.google.com/store/apps/details?id=com.jauntvr.android.player.cardboard).
Такого формата видео появляются уже довольно часто.
Собрались как-то раз на конференции Lang Next 2014 авторы и соавторы C++, Rust, D, Go поговорить о жизни и будущем системных языков программирования.

https://youtu.be/BBbv1ej0fFo

Там не хватало только Криса Лэттнера, автора Swift и LLVM, где-нибудь посередине группы.

Удивительно, Бьярн Страуструп и Роб Пайк на одной сессии одной конференции! Это как две рок-звезды на одной сцене одного концерта. Наверно их специально рассадили подальше друг от друга - слишком сильна гравитация вокруг них. 😆

https://youtu.be/BBbv1ej0fFo?t=6m45s - примечательно, что Роб Пайк говорит про позиционирование Go, больше как "server (i.e. network daemon) writing language... and now Go is a server-side cloud infrastructure language", и это очень верное определение.