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



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

• Герметичное ударозащищенное исполнение корпуса;
• Постоянное отображение реального времени и текущих метеоданных: давления, температуры, влажности, а также истории их изменения в течение последних несколько часов и нескольких дней на экране;
• Читаемый на ярком солнце экран;
• Работа прибора в течение всего похода без подзарядки или замены элементов питания или подзарядки;
• Желательно сохранение истории метеоданных в энергонезависимой памяти.

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

Воистину говорят: лень — двигатель прогресса! Вот и мне, взбудоражила голову мысль, автоматизировать процесс измерения и тренировки кислотных аккумуляторных батарей. Ведь кто, в здравом уме, будет, в наш век умных микросхем, корпеть над аккумулятором с мультиметрами и секундомером? Наверняка, многие знают «народное» зарядное устройство Imax B6. На хабре есть статья про него (и даже не одна). Ниже я напишу, что я с ней сделал и зачем.

Привет, Хабр!
Мы в Хекслете активно используем Докер как для запуска самого приложения и сопутствующих серверов, так и для запуска пользовательского кода в практических упражнениях по программированию. Без этих легковесных контейнеров нам было бы в разы сложнее справиться с этими задачами. Докер –замечательная технология, но иногда возникают неожиданные проблемы. Одна из таких проблем (и ее решение) описана в блоге Phusion (это создатели Phusion Passenger), сегодня мы публикуем ее перевод.

Примерно год назад, когда Докер был в версии 0.6, мы первыми представили Baseimage-docker. Это минимальный образ Ubuntu, модифицированный специально для Докера. Люди могут пуллить этот базовый образ из Docker Registry и использовать его как основу для своих образов.

Мы были ранними пользователям Докера, используя его для CI и для создания рабочего окружения задолго до выхода версии 1.0. Базовый образ мы сделали чтобы решить проблемы, специфичные для принципов работы Докера. Например, Докер не запускает процессы под специальным процессом init, который бы правильно обрабатывал дочерние процессы, поэтому возможна такая ситуация, когда зомби-процессы вызывают кучу проблем. Докер также не делает ничего с syslog, поэтому важные сообщения могут быть утеряны. И так далее.

Однако, мы выяснили, что многие люди не понимают проблем, с которыми мы столкнулись. Да, это довольно низкоуровневые системные механизмы Unix, которые понятны далеко не всем. Поэтому в этом посте мы опишем самую главную проблему, которую мы решаем – PID 1 zombie reaping problem.

OEM-версии ОС от Microsoft, начиная с Vista, используют проверку подлинности, основанную на сличении трех компонентов:

• OEM-сертификата, вшитого в дистрибутив ОС
• бинарного ключа, вшитого в BIOS, а конкретно — в таблицу ACPI SLIC
• лицензионного 25-значного ключа производителя, вшитого в дистрибутив ОС

При успешном сличении трех этих компонентов происходит оффлайн-активация ОС. На корпусе ПК в этом случае имеется наклейка, содержащая лицензионный ключ конкретного экземпляра ОС (а не производителя), которым можно произвести онлайн-активацию ОС в случае ее установки не с образа, предоставляемого производителем ПК, а с «чистого» (MSDN) OEM-образа от Microsoft.

Кроме того, лицензионный ключ конкретного экземпляра ОС может быть вшит в текстовом виде в BIOS, в таблицу ACPI MSDM. В этом случае, при установке ОС ключ будет извлечен из BIOS и вшит в конкретный экземпляр ОС. OEM-наклейка на корпусе ноутбука в этом случае может уже не содержать лицензионный ключ. Такой способ используется для активации Windows 8/8.1

Кампания по продвижению нанокомпьютера black swift в самом разгаре (см. также публикацию на habrahabr). black swift построен на базе SoC Atheros AR9331, что позволило сделать его с одной стороны крошечными, недорогим, и малопотребляющим, а с другой стороны в распоряжении пользователя находится процессорное ядро MIPS 24Kc, работающее на частоте до 400 МГц.
Недавно на форуме black-swift.ru был задан вопрос

Есть потребность в документации по использованию JTAG-интерфейса в устройстве. Можно ли ожидать чего-нибудь в этом направлении?

В данной публикации я вставлю свои пять копеек приведу конкретный простой сценарий использования JTAG-интерфейса SoC Atheros AR9331 для отладки программного обеспечения.
Публикация может быть интересна не только разработчикам ПО для AR9331, но и всем интересующимся внутрисхемной отладкой на процессорах с архитектурой MIPS при помощи свободного ПО.

Админская загадка: На сервере произошло три oom kill'а, а мониторинг сказал только про два. Почему?

Конфигурация

Для мониторинга всего у нас настроена связка ganglia-shinken-logstash-elasticsearch-kibana. Полное описание довольно обширно, так что ограничусь только частью, имеющей отношение к проблеме.

В logstash присылаются логи со всех серверов. Он складывает их в elasticsearch. В конфиге logstash'а настроена реакция на всякие странные сообщения, которые свидетельствуют о проблемах. Если сообщение появляется, присылается event мониторингу (shinken), который разными методами начинает беспокоить админов.

Помимо syslog'ов, которые шлют сообщения от большинства приложений, у нас настроена ещё и отправка netconsole от всех ядер. Сама технология проста до невозможности — ядро помимо dmesg'а посылает сообщения в виде UDP-датаграмм на указанный IP и mac-адрес. MAC-адрес нужен потому, что netconsole очень низкоуровневая и заниматься разгадыванием «как из IP сделать MAC» (то есть ARP) не собирается. Благодаря низкоуровневости сообщения проходят даже в ситуациях полного катаклизма. Например, если программный коммутатор перестал работать (и сеть недоступна), сообщения всё равно будут посылаться. Более того, они будут посылаться, даже если в iptables сказано -j drop_vsyo_nafig. И, самое главное и ценное, эти сообщения успешно будут отправлены, если дисковая подсистема полностью не работает. То есть для post-mortem исследований «что именно случилось с зависшим сервером» — самое оно.

Очевидным кандидатом в «плохие» сообщения является сообщение от oom-killer'а.

[517935.914380] ntpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[517935.914730] Call Trace:
[517935.914807]  [<ffffffff816e14ce>] dump_header+0x83/0xbb
[517935.914877]  [<ffffffff816e155b>] oom_kill_process.part.6+0x55/0x2cf
...
с финальным торжествующим: 
[517935.951044] Out of memory: Kill process 4550 (apache2) score 247 or sacrifice child
[517935.951203] Killed process 4550 (apache2) total-vm:2610268kB, anon-rss:2012696kB, file-rss:3928kB

Итак, возвращаемся к загадке. Идёт пусконаладка, предпродакшен, как, вдруг, апач (точнее, wsgi-приложение) насасывается данных до неприличия, и его прибивают со словами «go be fat somewhere else». Админам приходит сообщение. Казалось бы всё хорошо (ну, в админском смысле «хорошо»). Но…

Случилось три oom'а, сообщения пришли о двух. Мониторинг в порядке, netconsole в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?

Предисловие

Страшная сказочка:

EDAC MC0: 1 CE read ECC error on CPU#0Channel#1_DIMM#0 (channel:1 slot:0)
EXT4-fs error: ext4_wait_block_bitmap:445: Cannot read block bitmap
Out of memory: Kill process 95 (sshd) score 31 or sacrifice child
CMCI storm detected: switching to poll mode
page allocation failure: order:1, mode:0x4020
invalid opcode: 0000 [#1] SMP

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

Часть из этих сообщений в примерах выше заставит вас погрузиться в бездны современной архитектуры процессоров («CMCI storm», удачи в поиске дороги назад, из дебрей интернетов)… Cтранные вещи в ядре могут нарушать ожидания о том, как работают компьютеры, делая последующую отладку очень затруднённой. Отсутствие знания о том, что случилось может даже оставить с грустным ответом «какая-то неведомая фигня, ребутнули, вроде, прошло».

Лирическое вступление

Когда администраторы сталкиваются с неожиданной проблемой (раньше работало, и, вдруг, после обновления, перестало), у них существует два возможных алгоритма поведения: fight or flight. То есть либо разбиратся в проблеме до победного конца, либо убежать от проблемы не вникая в её суть. В контексте обновления ПО — откатиться назад.

Откатиться после неудачного апгрейда — это, можно сказать, печальная best practice. Существуют целые руководства как готовиться к откату, как их проводить, и что делать, если откатиться не удалось. Целая индустрия трусливого поведения.

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

Завязка драмы

Облако «Instant Servers» Webzillа. Рутинное обновление хоста nova-compute. Новый live image (у нас используется PXE-загрузка), отработавший шеф. Всё хорошо. Внезапно, жалоба от клиента: «одна из виртуалок странно работает, вроде работает, но как начинается реальная нагрузка, так всё замирает». Инстансы клиента переносим на другую ноду, проблема клиента решена. Начинается наша проблема. Запускаем инстанс на этой ноде. Картинка: логин по ssh на Cirros успешен, на Ubuntu — зависает. ssh -v показывает, что всё останавливается на этапе «debug1: SSH2_MSG_KEXINIT sent».

Все возможные внешние методы отладки работают — метаданные получаются, DHCP-аренда инстансом обновляется. Возникает подозрение, что инстанс не получает опцию DHCP с MTU. Tcpdump показывает, что опция отправляется, но не известно, принимает ли её инстанс.

Нам очень хочется попасть на инстанс, но на Cirros, куда мы можем попасть, MTU правильный, а на Ubuntu, в отношении которой есть подозрение о проблеме MTU, мы как раз попасть не можем. Но очень хотим.

Если это проблема с MTU, то у нас есть внезапный помощник. Это IPv6. При том, что «белые» IPv6 мы не выделяем (извините, оно пока что не production-ready в openstack), link-local IPv6 работают.

Каждый раз при покупке батареек у меня возникало много вопросов:

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

Чтобы получить ответы на эти вопросы я решил протестировать все батарейки АА и ААА, которые удастся найти в Москве. Я собрал 58 видов батареек АА и 35 видов ААА. Всего было протестировано 255 батареек — 170 АА и 85 ААА.

«Чтоб ты жил в интересные времена!» — якобы старинное китайское проклятие.
Да, нам с вами повезло или «повезло» жить в действительно интересные времена (вариант — «в эпоху перемен»). Возможно, это на самом деле проклятие, особенно с точки зрения мифических древних китайцев. Однако факт остается фактом: то, что еще пара десятков лет назад казалось невозможным, сейчас доступно практически каждому. Особенно это заметно в нашей отрасли — информационные технологии и цифровая электроника развиваются просто какими-то совершенно фантастическими темпами. Функциональные возможности, быстродействие, миниатюрность и (относительная) дешевизна современных цифровых решений поражает воображение.
Еще совсем недавно сетевой компьютер размером меньше кредитки и стоимостью в несколько сотен рублей, пригодный для создания на его базе интересных самостоятельных проектов энтузиастами-одиночками с относительно невысоким уровнем знаний в области электроники и программирования, казался весьма отдаленной перспективой. И вот уже мы можем смело выбирать из десятка (как минимум) альтернатив! Давайте посмотрим, что сейчас можно приобрести буквально за несколько десятков долларов, чтобы построить вокруг этого нечто впечатляющее и даже, может быть, полезное.

Владельцы дисков WD серии Green сталкиваются с слишком частой парковкой головок. В этой статье было описано как решить проблему с помощью DOS-утилиты wdidle3 от поддержки WD. Со времен этой статьи прошло много времени, но проблема осталась. Да и сам метод решения с помощью DOS-утилиты не является гуманным.
В процессе решения этой проблемы наткнулся на программу idle3-tools, с помощью которой можно указать время парковки головок из Linux.

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Мое детство прошло среди людей которые все время на чем то летали. Строили, разрабатывали новое и тут же на нем летали. В 5 лет для меня стало открытием, что кто то в этом мире может не летать. К своим 26 годам я успел попробовать почти все на чем можно летать. Хочу поделиться своим опытом и рассказать о доступных возможностях.
Что бы начать летать у Вас есть такие варианты:

1. Парители (в этой статье)

• Параплан
• Дельтаплан
• Планер

2. Моторный полет (вторая статья)

• Легкий самолет
• Мотодельтаплан
• Паратрайк
• Парамотор
• Мотопланер

Предисловие.

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

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

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

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

Механические клавиатуры. Путеводитель.

Сейчас уже никто не подвергает сомнению успех мини-компьютера Raspberry Pi. Почти сразу же после выхода этого мини ПК в свет, стали появляться новые модели мини-компьютеров, получившие свою долю покупателей. Нечто похожее случилось несколько лет назад и с нетбуками, которых сейчас великое множество. И что интересно, в случае с нетбуками, идея получить небольшое (и главное — недорогое) устройство для работы в Сети и с офисными программами как-то подзабылась. Очень скоро стали появляться нетбуки, стоимость которых превышала стоимость некоторых мощных ноутбуков. Видимо, подобная судьба ждет и мини-компьютеры.

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

Краткое вступление

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

Когда люди запускают своей первый Docker-контейнер, они часто спрашивают: «А как мне попасть внуть контейнера?» и ответ «в лоб» на этот вопрос, конечно: «Так запустите в нём SSH-сервер и приконнектитесь!». Цель этого топика — показать, что на самом деле вам не нужен sshd внутри вашего контейнера (ну, конечно, кроме случая, когда ваш контейнер собственно и предназначен для инкапсуляции SSH-сервера).

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

Но давайте подумаем ещё.

1. Схема

Имеем:

• Frontend — NGINX проксирующий сервер для принятия и распределения нагрузки (IP — 1.2.3.4 — внешний, IP — 192.168.5.10 — внутренний DMZ) по хорошему он тоже должен стоять за firewall-ом, но тут схема для простоты понимания.
• Два сервера с поднятыми ownCloud
• cloud-1 IP — 192.168.1.11
• cloud-2 IP — 192.168.1.12
• Хранилище файлов NFS-storage IP — 192.168.1.20 для размещения данных пользователей с доступом по NFS.

Прочитав статью "Делаем backup Google или паранойя по поводу санкций. Owncloud и другие открытые решения", я решил, что пора дать второй шанс ownCloud'у после крайне неудачного опыта с 5 версией. В итоге оказалось, что за сей короткий промежуток времени ownCloud приобрел вполне добротный вид и способна работать в качестве повседневного инструмента — обнаруженные проблемы либо не существенны, либо имеют решение. Те, кто не знаком с ownCloud, могут узнать о его ключевых особенностях, к примеру, на официальном сайте или на opennet.ru. В этой статье я НЕ расскажу о том, как надо устанавливать ownCloud и как потом его с нуля настроить, потому что уже достаточно об этом писано-расписано-переписано, да и установка не представляет собой ничего сложного, я лишь кратко упомяну важные детали. Под катом будет информация о том, что же интересного умеет ownCloud, какие приложения в apps.owncloud.com мне показались стоящими внимания, затрону интеграцию с KDE и Android, а также скажу пару слов о подводных камнях и интересных местах, ну а в конце подведу итоги для тех, кому лень столько читать. ownCloud на своём сервере я использую в одиночестве, поэтому администрирование пользователями и всё сопутствующее будет описано крайне скудно. Осторожно: много картинок.