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

Вот так выглядят индикаторы:



В окончании проекта будет приведён весь код с пояснениями.
Код распространяется по лицензии WTFPL.
За информацию по лицензии, а так же за код для Ethernet модуля ENC28J60 ещё одно спасибо Lifelover.

Проект ещё не закончен, далее будет продолжение.

К сожалению, на текущий момент устройство ещё не собрано, и пришлось довольно много ждать (при разработке столкнулся с неприятными трудностями как при изготовлении плат, так и при закупке некоторых расходников).
Готовы модули индикации (2 из 3), хотя работать можно и только с ними. Частично собрана «библиотека» работы с LED-дисплеем.
Пока нет интерфейса взаимодействия между двумя контроллерами (здесь вопрос к хабровчанам, как сделать лучше — сам склоняюсь к реализации через UART).

Кого заинтересовал — добро пожаловать под кат.
Предупреждение: Много фото.

Вместо Intro

История создания проекта могла бы и не начаться, если бы не одно непритяное «Но» — в отделе имеется оборудование, которое должно работать бесперебойно, в режиме 24/7/365 (круглосуточно, без выходных, всегда) — собственно, это аппратные станции (оптические мультиплексоры, SDH-оборудование) и сервера SIP телефонии (а так же Call центр, но об этом нам сообщают сами операторы, их очень хорошо обучили реагировать на малейшие сбои).
Само оборудование находится в серверной, удалённой от кабинета, и достаточно зашумлённой (50-80db внутри — это норма, даже говорить приходится на повышенных тонах, т.к. иначе просто не слышно собеседника уже в полу метре).
В случае любых сбоев оборудования, необходимо их быстро устранять (сбои могут возникать как с нашей стороны, так и со стороны присоединённых операторов, а так же по независимым причинам, например, обрыв оптики, перегрузка на линии, прочие потери данных), в связи с чем требуется постоянно сделить за показателями работоспособности.
Меры принимаются, но ранее это происходило с некоторой задержкой в виду отсутствия возможности контроля.
Визуальный контроль за оборудованием возможен (индикация предупреждений и аварий предусмортена), но для этого требуется быть рядом с оборуддованием, что постоянно не представляется возможным.

Заинтересовавшихся прошу под кат. (Осторожно, трафик ~10-15МБ фото)

Причина разработки данной конструкции 3D-принтера

До сборки своего ЧПУ фрезера я планировал собрать 3D-принтер. Однако после того, как у меня появился ЧПУ фрезер, понял, что 3D-принтер мне в сущности не нужен. Но закупленный под него комплект (двигатели, линейный подшипники и пр.) и уже сделанный экструдер «раздражали» взгляд. Решил попробовать сделать компактную конструкцию на нестандартном для 3D-принтера приводе «рейка шестерня».



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

Привод был выбран по следующим причинам:

• Нашел мало упоминаний о таком выборе для 3D принтера, и стало интересно «а почему его не используют?»
• У меня есть ЧПУ фрезер, который весьма точно вырезает шестерни и рейки с модулем 1mm.

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

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



Одна из проблем с тем, как работает Wireshark, заключается в невозможности легко проанализировать зашифрованный трафик, вроде TLS. Раньше вы могли указать Wireshark приватные ключи, если они у вас были, и расшифровывать трафик на лету, но это работало только в том случае, если использовался исключительно RSA. Эта функциональность сломалась из-за того, что люди начали продвигать совершенную прямую секретность (Perfect Forward Secrecy), и приватного ключа стало недостаточно, чтобы получить сессионный ключ, который используется для расшифровки данных. Вторая проблема заключается в том, что приватный ключ не должен или не может быть выгружен с клиента, сервера или HSM (Hardware Security Module), в котором находится. Из-за этого, мне приходилось прибегать к сомнительным ухищрениям с расшифровкой трафика через man-in-the-middle (например, через sslstrip).

Логгирование сессионных ключей спешит на помощь!

Что ж, друзья, сегодня я вам расскажу о способе проще! Оказалось, что Firefox и Development-версия Chrome поддерживают логгирование симметричных сессионных ключей, которые используются для зашифровки трафика, в файл. Вы можете указать этот файл в Wireshark, и (вуаля!) трафик расшифровался. Давайте-ка настроим это дело.

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

Хочу рассказать и показать результаты проекта, который развивается примерно 10 лет. Развивается как хобби, поэтому бывает, что за неделю делается новое устройство, а потом за полгода – не делается ничего. Я очень не люблю словосочетание «Умный дом», поэтому дальше оно не встретится. Также тут не будет схем, примеров кода, опутанных проводами макетных плат и прочих скучных вещей. Будет много фото и рассуждений на общие темы.

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

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

Как это сделать на серверах или компьютерах, где установлен заббикс-агент, многие знают — есть встроенные элементы данных log[], logrt[].

Но как быть, когда нужно собирать логи с сетевого оборудования, на которое никак не водрузить Zabbix-agent’а? Вообще-то можно, конечно, настроить syslog-сервер на том же ПК, на которой есть заббикс-агент, а дальше при помощи log[] переносить эти данные в заббикс. Вот только элементы данных и триггеры по нему будут прикреплены к узлу сети с заббикс-агентом, что интуитивно малопонятно. А можно ли прикрепить эти данные непосредственно к сетевому устройству? Можно.

Для этого нам понадобится zabbix_sender, Zabbix API и rsyslog на машине с заббикс-сервером или заббикс-прокси. В качестве бонуса также получим быстрый контекстный переход в журнал syslog-сообщений с карты сети.
Как будет выглядеть результат? Ну, примерно вот так:
Контекстный вызов:

В этой статье я хотел бы осветить практические аспекты использования DHCP relay+option82 как возможность авторизации (в дальнейшем именно эта связка будет иметься ввиду), а так же привести примеры конфигурации свитча Dlink DES-3200-10 и isc-dhcp-server. Практически во всех статьях dhcp relay трактуют так: «можно вынести dhcp-сервер за пределы широковещательного домена». Однако почему-то не упоминают или почти не упоминают, что это хорошая возможность избавиться от широковешательных запросов в пределах того же самого широковешательного домена. И самое главное, на что акцентирую внимание — мы можем быть уверены, благодаря option82, что запрос пришёл именно со свитча с заданным маком и именно с порта с указанным номером, а следовательно — таким образом можно «авторизовать» пользователя.

В статье данные сведения по заголовкам кэширования (ЗК) для HTTP и соответствующее поведение сетей доставки контента (CDN). Если вам хочется разобраться, каким образом заголовки кэширования вписываются в современный веб, или вам просто интересно, о чём говорят ваши коллеги – эта статья для вас.

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

Что могут ЗК сделать для вас?

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

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

Давайте сразу начистоту: никто не любит платить за софт много. И для некоторых «много» — это всё, что больше цены ежедневного обеда. Даже когда речь идёт о профессиональном ПО для профессионалов, если на горизонте возникает чуть менее платный конкурент с меньшим количеством функций, он сразу же привлекает к себе множество внимания, а в головах изумлённой публики возникает вопрос: «А может, в признанном лидере рынка действительно уже перебор этих самых функций, и платить за них нет никакой причины?». В качестве ответа, некоторые производители начинают искать новые, относительное честные методы отъёма денег у населения, и вводят подписочные сервисы, которые в первом приближении, позволяют платить за софт намного меньше.

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

Сегодня предлагаю вам рассмотреть именно вторую модель, выяснив, что же компания Veeam предлагает своим пользователям на безвозмездной основе и так ли этого мало для ежедневного личного использования. Пусть даже если из-под “личного” проглядывает небольшая купи-продай контора, или простихосподи, стартап, который считает, что «кровавый вендор» хочет слишком много денег за свои продукты.
Если сомневаетесь, что они дают действительно мощные инструменты, не прося ничего взамен и что вообще так бывает — добро пожаловать под кат.

Коллега на работе купил себе новый автомобиль Chery Tiggo FL, куда китайцы напихали много различных функций за невысокую стоимость автомобиля. Одной из самых необычных штуковин в авто оказалось «волшебное» зеркало, которая наделено функциями барометра, альтиметра и компаса.

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



Итак, приступим к созданию «патча» на зеркало.

Работа портов ввода/вывода

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

• Часть 1. Работа портов ввода/вывода
• Часть 2. Подключение светодиода к линии порта ввода/вывода
• Часть 3. Подключение транзистора к линии порта ввода/вывода
• Часть 4. Подключение кнопки к линии порта ввода/вывода

Пример будем рассматривать на микроконтроллере ATMega8.

Программу писать будем в Atmel Studio 6.0.

Эмулировать схему будем в Proteus 7 Professional.

С внешним миром микроконтроллер общается через порты ввода вывода. Схема порта ввода вывода указана в даташите:



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



Pxn – имя ножки порта микроконтроллера, где x буква порта (A, B, C или D), n номер разряда порта (7… 0).
Cpin — паразитная емкость порта.
VCC — напряжение питания.
Rpu — отключаемый нагрузочный верхний резистор (pull-up).
PORTxn — бит n регистра PORTx.
PINxn — бит n регистра PINx.
DDRxn — бит n регистра DDRx.

Привет, Хабр! Сегодня хочу продолжить тему «скрещивания» arduino и android. В предыдущей публикации я рассказал про bluetooth машинку, а сегодня речь пойдет про DIY bluetooth вольтметр. Еще такой девайс можно назвать смарт вольтметр, «умный» вольтметр или просто умный вольтметр, без кавычек. Последнее название является неправильным с точки зрения грамматики русского языка, тем не менее частенько встречается в СМИ. Голосование на эту тему будет в конце статьи, а начать предлагаю с демонстрации работы устройства, чтобы понять о чем же пойдет речь в статье.

Так уж случилось, что последнее время приходилось заниматься оптимизацией и масштабированием различных систем. Одной из задач было масштабирование PostgreSQL. Как обычно происходит оптимизация БД? Наверное, в первую очередь смотрят на то, как правильно выбрать оптимальные настройки для работы и какие индексы можно создать. Если обойтись малой кровью не вышло, переходят к наращиванию мощностей сервера, выносу файлов журнала на отдельный диск, балансировке нагрузки, разбиению таблиц на партиции и к всякого рода рефакторингу и перепроектированию модели. И вот уже все идеально настроено, но наступает момент, когда всех этих телодвижения оказывается недостаточно. Что делать дальше? Горизонтальное масштабирование и шардинг данных.

Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.

На различных конференциях мы неоднократно рассказывали про наше облако для CLI-скриптов (видеозапись доклада, слайды). Облако предназначено для того, чтобы запускать различные PHP-скрипты по расписанию или через API. Как правило, эти скрипты обрабатывают очереди, и нагрузка «размазывается» приблизительно по 100 серверам. Ранее мы акцентировали внимание на том, как реализована управляющая логика, которая отвечает за равномерное распределение нагрузки по такому количеству серверов и генерацию заданий по расписанию. Но, помимо этого, нам потребовалось написать демон, который был бы способен запускать наши PHP-скрипты в CLI и следить за статусом их исполнения.

Изначально он был написан на Си, как и все остальные демоны в нашей компании. Однако мы столкнулись с тем, что существенная часть процессорного времени (около 10%) тратилась, по сути, впустую: это запуск интерпретатора и загрузка «ядра» нашего фреймворка. Поэтому, чтобы иметь возможность инициализировать интерпретатор и наш фреймворк только один раз, было принято решение переписать демон на PHP. Мы назвали его Phprocksyd (по аналогии с Phproxyd — PHP Proxy Daemon, демоном на Си, который у нас был до этого). Он принимает запросы на запуск отдельных классов и делает fork() на каждый запрос, а также умеет сообщать о статусе исполнения каждого из запусков. Такая архитектура во многом похожа на модель веб-сервера Apache, когда вся инициализация делается один раз в «мастере» и «дети» занимаются уже именно обработкой запроса. В качестве дополнительной «плюшки» мы получаем возможность включить opcode cache в CLI, который будет правильно работать, поскольку все дети наследуют ту же область общей памяти, что и мастер-процесс. Чтобы уменьшить задержки при обработке запроса на запуск, можно делать fork() заранее (prefork-модель), но в нашем случае задержки на fork() составляют около 1 мс, что нас вполне устраивает.

В этой небольшой статье я хотел бы рассказать о средствах мониторинга, использующихся для анализа работы DWH нашего банка. Статья будет интересна всем, кого не устраивают существующие готовые системы мониторинга и кого посещали мысли собрать таковую «под себя» из отдельных кусочков. Большое внимание в статье уделяется дашборду Grafana, который, по моему мнению, незаслуженно обделён вниманием на Хабре. По большинству компонентов системы мониторинга будет вкратце рассмотрен процесс инсталяции (под RedHat).


Тёплый ламповый дашборд

При настройке IPSec рано или поздно все сталкиваются с тем, что можно задать только IP-адреса удаленного VPN-сервера. Указание DNS-записей в настройках IPsec Policies и IPsec Peers не поддерживается.

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

• сменили одного провайдера на другого;
• решили изменить используемый статический IP-адрес;
• используется динамический (серый) IP-адрес.

Взяв даже простейшую схему, становится видно, что нам придется менять настройки трех роутеров-клиентов VPN-сервера:



И в каждом из трех роутеров сменить значения:

• IpSec/Policy/dst-address
• IpSec/Policy/sa-dst-address
• IpSec/Peer/address

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

Сегодня я попробую ответить на вопрос: «А что если вместо PHP писать на Python?».

Сам я долгое время задавался этим вопросом. Я писал на PHP 11 лет и даже являюсь сертифицированным специалистом. Я научился его «готовить» так, чтобы он работал в точности, как мне надо. И когда я в очередной раз читал на Хабре перевод статьи о том, как всё в PHP плохо, я просто недоумевал. Однако подвернулся случай пересесть на Ruby, а потом и на Python. На последнем я и остановился, и теперь попробую рассказать вам PHP-шникам, как нам питонистам живётся.

Сегодня, в эру высоких технологий и безупречного клиентского сервиса, всем хочется быть на уровне. Многие компании в независимости от ранга и размера постоянно стараются сделать общение с клиентом удобнее и приятнее. В нашем интерне-агентстве, руководителем, которого я и являюсь, одной из таких «приятностей» стало введение в эксплуатацию небольшой мини-АТС на базе Openvox и Asterisk, собранной своими руками. Но давайте по-порядку:

Проблема

Телефон — является одним из основных каналов связи с клиентами в нашей работе. За день поступает множество звонков, которые нужно обработать. От использования аналоговой линии мы отказались сразу, ввиду алчности и ненадежности местных провайдеров. Да и устарели нынче аналоговые технологии. Решение использовать GSM-связь было единогласным и непоколебимым. В первые несколько лет работы за прием звонков отвечал вот такой вот не убиваемый аппарат:



Изначально звонки принимал я и мой партнер по-очереди, находясь в разных углах одного офиса. Когда клиент звонил и прослушав несколько сигналов бездушного зуммера просил с кем-нибудь соединить, то с большой вероятностью он мог услышать свист ветра, который создавал сей финский девайс, пролетая из одного угла офиса в другой. «Многоканальность» была реализована за счет наличия в данном телефоне двух слотов для сим-карт. О записи разговоров речи не было, голосовое приветствие и меню отсутствовали, метод трансфера звонков от одного специалиста к другому был описан выше. Сплошные минусы, в общем, и самое главное, что звонивший к нам человек с первых минут мог подумать, что звонит очередную шарашкину контору из полутора фрилансеров. Что было достаточно обидно, ведь свою работу мы делали хорошо, с гарантиями и душой.

Вдоволь намучившись, одним прекрасным днем я сказал громкое «Хватит!» и не менее громкое «Нужно что-то предпринять!»