До появления ботнета Mirai только особо интересующиеся знали о том, что находится внутри обычных IP камер. В большинстве случаев там стоит обычный линукс, причем частенько с дефолтным рутовым паролем, а то и вообще без него: у нас в офисе стоит такая камера, с прошивкой от декабря 2016 года и беспарольным рутовым телнетом.

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

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

Мы решили исправить эту ситуацию своей прошивкой, причем сделав ставку на Rust.

В прошлой статье про SecureBoot мне очень не хватало возможности сделать снимок экрана при настройке UEFI через BIOS Setup, но тогда выручило перенаправление текстовой консоли в последовательный порт. Это отличное решение, но доступно оно на немногих серверных материнских платах, и через него можно получить только псевдографику, а хотелось бы получить настоящую — она и выглядит приятнее, и вырезать ее каждый раз из окна терминала не надо.
Вот именно этим мы и займемся в этой статье, а заодно я расскажу, что такое DXE-драйвер и как написать, собрать и протестировать такой самостоятельно, как работают ввод с клавиатуры и вывод на экран в UEFI, как найти среди подключенных устройств хранения такое, на которое можно записывать файлы, как сохранить что-нибудь в файл из UEFI и как адаптировать какой-то внешний код на С для работы в составе прошивки.
Если вам все еще интересно — жду вас под катом.

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

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

Tarantool — это NoSQL база данных, которая хранит данные в памяти либо на диске (в зависимости от подсистемы хранения). Хранилище персистентно за счет продуманного механизма write ahead log. В Tarantool встроен LuaJIT (Just-In-Time Compiler), позволяющий исполнять код на Lua. Также можно писать хранимые процедуры на C.

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

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

Вам знакома такая архитектура? Хоровод демонов, пляшущих между web-server, cache и storage.



Какие минусы такой архитектуры можно отметить? Решая задачи в рамках такой архитектуры, мы сталкиваемся с кучей вопросов: какой язык(и?) взять, какой I/O framework выбрать, как синхронизировать cache и storage? Куча инфраструктурных вопросов. А зачем решать инфраструктурные вопросы, когда надо решить задачу? Безусловно, можно сказать, что нам нравятся некие технологии X и Y, и перевести эти минусы в рамки идеологических. Но нельзя отрицать тот факт, что данные располагаются на неком расстоянии от кода (картинка выше), что добавляет latency, что может уменьшить RPS.

Цель данной статьи — рассказать об альтернативе, которая построена на базе Nginx как web-server, bаlancer и Tarantool как App Server, Cache, Storage.

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



Программа, о которой пойдёт речь, называется Nigel’s Monitor, или просто nmon. Она, используя простой интерфейс ncurses, умеет выводить, в реальном времени, сведения о различных показателях, характеризующих состояние сервера. Среди них — данные по процессору и памяти, информация о сетевых ресурсах, о дисковых накопителях, о файловой системе и NFS, о процессах. Набор отображаемых показателей можно настраивать. Nmon имеет текстовый интерфейс, поэтому, для работы с ним достаточно подключиться к серверу по SSH.

Предлагаю установить nmon и поговорить о том, как им пользоваться.

Всем доброго времени суток, сегодня, 10 марта закончился онлайн этап NeoQuest 2017. Пока жюри подводят итоги и рассылают пригласительные на финал, предлагаю ознакомиться с райтапом одного из заданий: Greenoid за который судя по таблице рейтинга, можно было получить до 85 очков.

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

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

Добрый день, уважаемый читатель. На днях довелось мне поиграться с многим уже известной игрушкой от Google – Google Home. Штука хорошая — обзор ее я делать конечно не буду. В чулане совершенно случайно завалялись Raspberry PI 3 (RPi), Arduino Mega и еще им подобная мелочь, которую захотелось подключить к Google Home (GH) с целью голосового управления. Простого API у GH нет, но есть возможность с помощью стороннего сервиса организовать голосовое управление системой на RPi + Arduino с задержкой команд в несколько секунд.

Читая буржуйские форумы (справедливости ради, нужно отметить, человек я повернутый на автоматизации и IoT), обратил внимание на доселе мне неизвестное нечто, что называют Home Assistant (HASS), эту систему умельцы-то и прикручивают к GH.

В двух словах о самой платформе:

Система написана на Python, последний релиз был 29 января, текущая версия: 0.37.0

Поддерживаемые ОС:

• Windows 10
• Mac OS X
• Ubuntu 14.04
• Raspbian (Raspberry PI)
• iOS App – beta

Поддерживаемые компоненты: 545 шт., включая почти все TV/AV receivers, Broadlink, ZigBee, iCloud, Yandex TTS и многое, многое другое.

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

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

UPD: в этом посте отражено субъективное мнение автора в 2016-ом году. Сейчас я работаю над своим проектом в сфере обучения облачным технологиям.

Мне не раз приходилось слышать: «Upwork — это же геморрой. Мне приходится тупо кликать мышкой, смотреть фильм на ноуте, чтобы побольше высидеть часов. Поэтому я ушел на XYZ...». Вот этот тезис, личные проблемы с продуктивностью, а также немалое количество self-help книг, побудили меня написать этот пост. Вся моя IT-карьера, связана с Upwork (который был oDesk). Это немного-немало 10,000+ часов работы, 10+ лет проведенных в этой системе, с короткими перерывами.

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

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

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

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

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

Часть 1. Мониторинг инженерной инфраструктуры в дата-центре. Основные моменты.
Часть 2. Как устроен мониторинг энергоснабжения в дата-центре.
Часть 3. Мониторинг холодоснабжения на примере дата-центра NORD-4.
Часть 4. Сетевая инфраструктура: физическое оборудование.

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

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

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



С организационными моментами вроде разобрались, приступим к азбуке мониторинга в редакции DataLine :). Итак, сегодня речь пойдет о концептуальных вещах, которые нужно учитывать на этапе проектирования, внедрения и настройки системы мониторинга. Сабж рассмотрим на примере нашего мониторинга, построенного на базе Nagios и Cacti.

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

Я принёс батарею домой, отогрел, подключил к заряднику. Зарядник через полчаса показал ОК. Врал. Ничего там не ок. Лампочка ближнего света горела примерно 10 минут и потом быстро перешла в состояние «слабо грею воздух». Аккумулятор 6Ач, лампочка 55Вт.

Не покупать же новый аккумулятор? Зима, время есть. Есть ардуина даже и коробка всяких чипсов из Китая. Зря пылятся там что ли?



В далёкой советской армии 30 лет назад я проходил курс ухода за аккумуляторами. Основное отличие его от инструкций 21 века было таким: батарея должна проходить серию циклов заряда и разряда. Без этого, сколько её в заряднике не держи, какой бы он ни был умный, она сдохнет.

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

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

Мой автомобиль Skoda Octavia 2011 г. в. не предлагает возможностей управления с телефона, поэтому я решил исправить этот недостаток, а заодно и добавить функцию голосового управления. В качестве шлюза между CAN шиной и телефоном я использую Raspberry Pi с шилдом CAN BUS и WiFi роутер TP-Link. Протокол общения агрегатов авто закрытый, и на все мои письма предоставить документацию протокола Volkswagen отвечал отказом. Поэтому единственный способ узнать, как общаются устройства в авто и научиться ими управлять является реверс-инжиниринг протокола CAN шины VW.

Я действовал поэтапно:

1. Разработка CAN шилда для Raspberry Pi
2. Установка ПО для работы с CAN шиной
3. Подключение к CAN шине авто
4. Разработка сниффера и изучение протокола CAN шины
5. Разработка приложения для телефона
6. Голосовое управление с помощью Homekit и Siri

В конце видео голосового управления стеклоподъемником.

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

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

На сегодняшний день две мои самые любимые темы — SQLite и key-value базы данных. И в этот раз я пишу сразу про обе: этот пост посвящён Python-обёртке для используемого в SQLite 4 key-value хранилища на основе LSM.

Я не слишком внимательно отслеживаю релизы SQLite, но версия 3.8.11 привлекла моё внимание, поскольку в её описании заявлено серьёзное увеличение производительности по сравнению с 3.8.0. В сопроводительной информации я наткнулся на упоминание о новом экспериментальном расширении для полнотекстового поиска (о котором писал когда-то), и потому мне стало интересно, какая складывается ситуация с SQLite 4.

Изучив доступную информацию, я обратил внимание, что одной из задач разработчиков было обеспечить в новых версиях интерфейс для подключаемых движков баз данных. На момент написания этого поста в SQLite 4 уже было два встроенных бэкенда, один из которых — key-value хранилище на основе LSM. В последние пару месяцев мне доводилось поиграться с Cython, пока я писал Python-обёртку для встроенных k-v хранилищ UnQLite и Vedis. И я подумал, что было бы неплохо применить Cython для создания интерфейса движка БД на основе LSM, используемого в SQLite 4.

Разобравшись с исходным кодом SQLite 4 и крохотным заголовочным файлом LSM, я написал python-lsm-db (документация).