Step Tracker

Маленькая инструкция как получить текущий дамп с ibody step tracker. 

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

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

Получить исходный код с репозитория через: 

• git - лучший способ, если планируете что-то менять и использовать долго и делать какие-то улучшения.. git clone https://github.com/0lvin/StepTracker.git && cd StepTracker ; 
• Или более простой через архивчик: wget https://github.com/0lvin/StepTracker/archive/master.zip && unzip master.zip && cd StepTracker-master/ 

Собрать исходный код, нужен любой дистрибутив линукс, можно даже в виртуальной машине, единственное требования в машине должен быть проброшено usb устройство. Нужно выполнить команду make и убедиться что появился файлик ibody. 

Узнать где же наше устройство, подключаем и сморим sudo dmesg | tail. Должно быть что-то подобное:

[  185.937678] usb 5-1: new full-speed USB device number 3 using ohci-pci
[  186.132776] usb 5-1: New USB device found, idVendor=10c4, idProduct=ea60
[  186.132784] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  186.132787] usb 5-1: Product: CP2104 USB to UART Bridge Controller
[  186.132790] usb 5-1: Manufacturer: Silicon Labs
[  186.132792] usb 5-1: SerialNumber: xxxxxxxxxxxx
[  186.137018] cp210x 5-1:1.0: cp210x converter detected
[  186.145153] usb 5-1: cp210x converter now attached to ttyUSB0

Из чего можно предположить что трекер сейчас висит на ttyUSB0 Поэтому попробуем запросить немного информации о нем:

sudo ./ibody -d /dev/ttyUSB0 -i
-- Will be used as tracker device: /dev/ttyUSB0
++ tracker id:
-> 5a 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c
<- 5a 42 00 22 aa 54 45 ff de ad be ef ff 00 00 00 f0
-- id will be: ff de ad be ef ff
-- Other values unknown for now.

Где вместо ff de ad be ef ff - будет серийник вашего устройства.

Теперь обновим время на устройстве: sudo ./ibody -d /dev/ttyUSB0 -t

И все же получим дамп нашей активности: sudo ./ibody -d /dev/ttyUSB0 -g

и в строчках вида:

-- 16.12.31 08:30:00 :>   24 steps, 0.016 km, 0.6 kkal

будет ваша активность.

Прогресс Mesa3d

Последнее время mesa3d достигли гигантского прогресса для большинства новых видеокарт добавили поддержку opengl 4.5. Часть даже получила поддержку Vulkan, и все же не вся эта радость уже есть в дистрибутивах. Для ого чтобы поиграться и самому собрать mesa3d можно воспользоваться такой последовательностью действий для debian:

• Получить последнюю версию исходных кодов:
  git clone git://anongit.freedesktop.org/mesa/mesa
• Собрать с понравившимися опциями:
  sudo apt-get install ccache
  sudo apt-get build-dep mesa vulkan
  cd mesa
  autoreconf -vfi
  CC='ccache gcc' ./configure --enable-texture-float --with-llvm-prefix=/usr/lib/llvm-3.9 --enable-gallium-osmesa --enable-opencl-icd --enable-opencl --with-vulkan-drivers=radeon,intel --with-sha1=libgcrypt
  make -j 6
  cd ..
• Скопировать новые библиотеки:
  mkdir lib
  cp -rv mesa/lib/* lib/
  cp -rv mesa/lib/gallium/* lib/
• Посмотрим, что скажет glxinfo: LIBGL_DRIVERS_PATH=`pwd`/lib glxinfo
• А теперь посмотрим как возросло количество fps в не тесте:
  LIBGL_DRIVERS_PATH=`pwd`/lib GALLIUM_HUD=fps glxgears, glxgears - можно заменить на вашу любимую игру

Эмуляция vs Виртуализация

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

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

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

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

Контейнеры - организуется через стандартную функциональность операционной системы по изоляции процессов и подмены ресурсов. Позволяет получить очень легковесную изоляцию вложенной системы от базовой системы и других запущенных контейнеров. Организовано через создание пространств имен для всех ресурсов системы, когда существуют базовое пространство доступное лишь в базовым процессам, и выделенные подпространств доступных в контейнерах. Главный недостаток отсутствие возможности запуска процессов рассчитанных на запуск под другой семейство операционных систем, так как процесс будет видеть тоже самое ядро что и основная система, частично это решается расширением количества подсистем доступных в базовом ядре или запуском дополнительных прослоек эмуляции API не доступного на базовой системе, как пример может быть использовано UNIX подсистема в NT ядре или Wine для Unix ядер.

Netconf клиент

Пример использования netconf протокола совместно с cloudify. 

Для использования этого протокола с использованием python есть несколько вариантов:

• использовать уже существующие библиотеки заточенные под конкретные устройства (не обязательно аппаратные, можно и программные реализации) - ncclient. Хорошее решение если кто-то побеспокоился и создал код для нужного устройства, если нет нужно разбираться и писать код;
• реализовать самому протокол посмотрев в стандарты: rfc6241 - общее описания какие команды, есть и как их использовать; rfc6242 - низкоуровневое описание как общаться. Ничего особо сложного в этом нет, но если использовать python или C больше похоже на изобретение велосипеда;
• остановится на решении которое бы реализовывало протокол, но сами пакеты пользователь формулирует в удобном ему виде.

Как пример последнего может быть cloudify-netconf-plugin :-) Код в репозитории можно разбить на 3 вида:

• реализация самого протокола общения netconf_connection.py, поддерживает NetConf 1.0 и 1.1 поверх ssh.
• реализация преобразования python словарей в xml нужного формата и обратно utils.py
• интеграция с cloudify xml_rpc.py

Как результат мы имеем дополнение к cloudify которое позволяет автоматизировать действия с настройками устройств поддерживающих этот протокол используя tosca yaml blueprints формат.

Cloudify позволяет сделать гораздо более широкие возможности чем поменять настройку какого-то устройства и при желании можно дописать плагинчик под что угодно, если плагинов по умолчанию или скриптования на bash c python вам не достаточно, но сейчас не об этом речь. Более подробно можно почитать на getcloudify.org.

Вернёмся к тому что представляет из себя плагин - он позволяет описать последовательность команд которые нужно отправить на устройство в yaml как последовательность действий внутри ноды указав действие которое нужно выполнить с указанием параметров для этого действия. Система изначально ориентирована на то что нужно получить описание интерфейса устройства в виде yang файла потом прогнать их через yttc для получения шаблона который потом подключить в нужный blueprint. Но никто не мешает напрямую писать нужные описания данных сразу в blueprint.

Запускать для turing машины это все достаточно просто(только нужно пометь в этой последовательности пароли и хост на реальные):

• mkdir turing
• virtualenv turing
• cd turing
• . bin/activate
• git clone git@github.com:cloudify-cosmo/cloudify-netconf-plugin.git
• pip install -e cloudify-netconf-plugin
• pip install cloudify
• touch netconf_inputs.yaml
• echo "netconf_ip: localhost" >> netconf_inputs.yaml
• echo "netconf_user: netconf" >> netconf_inputs.yaml
• echo "netconf_password: netconf" >> netconf_inputs.yaml
• cfy local init -p cloudify-netconf-plugin/blueprint_examples/turing.yaml -i netconf_inputs.yaml
• cfy local execute -w install

Код можно использовать как совместно с cloudify, так и без него только нужно написать обертку над модулями для запуска функциональности.

Netconf protocol

Инструкция по установке тестового сервера для проверки netconf протокола. Для этой цели вполне подойдет netopeer сервер, желательно его ставить на centos, так как установка на убунту сложнее так как нет части библиотек и нужно ставить их вручную.

• Для начала нужно скачать образ CentOS-7-x86_64-Minimal-1511.iso и запустить в любимой виртуалке Затем установить пакеты, которые в дальнейшем будут нужны для сборки сервера:
  • yum install libssh-devel libcurl-devel epel-release gcc libxml2-devel libxslt-devel libtool git wget libcurl-devel libssh2-devel libxml2 libxml2-python dbus-devel readline-devel
• И доставить еще немножко
  • yum install python-pip
  • pip install pyang
  Это нужно так как pip идет отдельном репозитории epel-release и как следствие поставить сразу пакет и репозиторий не получится.
• Поставить libnetconf библиотеку
  • git clone https://github.com/CESNET/libnetconf.git
  • cd libnetconf/
  • git checkout 0.9.x (commit 1f117e5a8017c3ec630f890faaee8ff28d382798)
  • ./configure --prefix=/usr
  • make
  • make install
  • ln -s /usr/lib/pkgconfig/libnetconf.pc /usr/lib64/pkgconfig/
  • cd ../
• Установить сервер
  • git clone https://github.com/CESNET/netopeer.git
  • cd netopeer/
  • git checkout libnetconf-0.9.x (commit 092e2ea95e77e1b6a2f93a53d43b1917532a1137)
  • cd server
  • ./configure --sysconfdir=/etc --prefix=/usr
  • make
  • make install
• Установить клиентские утилиты
  • cd ../cli/
  • ./configure --sysconfdir=/etc --prefix=/usr
  • make
  • make install
  • netopeer-configurator
• Добавить модуль для эмуляции расширения протокола
  • cd ../netopeer/transAPI/turing/
  • ./configure --prefix=/usr
  • make
  • make clean
  • make
  • make install
• И проверить, что у нас получилось:
  • netopeer-server -v 3 -d
  • ssh -p 830 root@localhost -s netconf

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