Про измерение CO2 и его важность на Geektimes было уже немало публикаций (ссылки в конце статьи). Здесь же хочу описать проект компактного монитора уровня CO2, а также температуры, влажности и давления с Wi-Fi, обновлением прошивки по воздуху и интерфейсом в мобильном приложении. Сердца системы модуль на базе esp8266, сенсор CO2 MH-Z19 и фреймворк esp8266-arduino. И так, включим устройство в USB-розетку:

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

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

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Это первая статья в серии, где я буду документировать мой опыт написания веб-приложения на Python, используя микрофреймворк Flask.

Здесь список всех статей в серии:
Часть 1: Привет, Мир!
Часть 2: Шаблоны
Часть 3: Формы
Часть 4: База данных
Часть 5: Вход пользователей
Часть 6: Страница профиля и аватары
Часть 7: Unit-тестирование
Часть 8: Подписчики, контакты и друзья
Часть 9: Пагинация
Часть 10: Полнотекстовый поиск
Часть 11: Поддержка e-mail
Часть 12: Реконструкция
Часть 13: Дата и время
Часть 14: I18n and L10n
Часть 15: Ajax
Часть 16: Отладка, тестирование и профилирование
Часть 17: Развертывание на Linux (даже на Raspberry Pi!)
Часть 18: Развертывание на Heroku Cloud

Моя предыстория

Я разработчик ПО с двузначным числом лет опыта разработки комплексных приложений на нескольких языках. Впервые я познакомился с Python для создания привязок к C++ библиотеке на работе. Вдобавок к Python, я писал веб-приложения на PHP, Ruby, Smalltalk и, верите вы или нет, еще на С++. Из всего этого, я нахожу комбинацию Python/Flask самой гибкой.

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

КДПВ. Бут-менеджер rEFInd с темой оформления Regular.

На сегодняшний день практически все уже слышали про технологию UEFI. Говорить о том, что это такое и зачем оно нужно, я не собираюсь. Сегодня я бы хотел описать простейший сценарий установки Dual Boot системы с полной поддержкой UEFI, а также рассмотреть отдельно установку и настройку бут-менеджера rEFInd. Возможно вы уже видели подобные мануалы и гайды, но я постараюсь донести весьма доходчиво суть того, что мы будем делать и зачем. В других мануалах вы лишь смотрите за «магией» картежника и пытаетесь её повторить, делая, зачастую, элементарные ошибки. Кому эта тема интересна — прошу под кат.

Всем привет! Прошлая статья про прозрачное проксирование HTTPS с помощью Squid'a была вполне успешной. Приходило по почте множество отзывов об успешной установке данной системы. Но также и поступали письма с просьбами о помощи. Проблемы были вполне решаемыми. Но не так давно обратилась ко мне одна коллега с просьбой о помощи в установке этой системы на х64 архитектуре (Debian). Тут мы озадачились. Во-первых, оказалось, что прошлая статья непригодна для этого по причине отсутствия нужных исходников в репозитории Debian (там теперь 3.5.10). Найти нужные в первой статье Debian'овские исходники не удалось, а checkinstall выдавал странные ошибки. Во-вторых, хотелось более универсального решения, которое бы без проблем работало и на х64, и на х86, и (по-возможности) на других дистрибутивах. Решение было найдено. Получилось небольшое дополнение к предыдущей статье + некоторые уточнения. Данная инструкция позволяет скомпилировать как х86, так и х64 версии Squid'a и создать соответствующие пакеты. Инструкция будет разбита на несколько пунктов и подпунктов. Если интересно, идем под кат:

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

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

Zabbix сервер — это хорошо. Правильно настроенный, он мониторит серваки и необходимые мне узлы. В случае проблем на них он с радостью уведомляет меня по электронной почте. Не так давно выяснилось, что оба наших любимых провайдера (основной и резервный интернет каналы) решили не обеспечивать ИБП свое сетевое оборудование в здании. Поэтому когда вырубают электричество (а бывает такое!) Zabbix бы и рад разбудить веселым письмом, а никак! В общем, решил заморочиться уведомлением по sms. Именно через GSM модем чтобы не было зависимости от интернета.

Поискав по интернету варианты отправки sms Zabbix-ом, нашел варианты решения, но они показались мне длинными. Поэтому сделал по своему «на коленке». Постараюсь подробно описать не сложное рабочее решение и «грабли».

Рассуждения

При упоминании словосочетания «контейнерная виртуализация», многим на ум сразу же приходят Virtuozzo и OpenVZ, а также Docker. Ассоциируется же это все, в первую очередь, с хостингом, VPS и другими подобными вещами.

Дома, на личных компьютерах многие используют виртуальные машины: в основном, пожалуй, Virtualbox. Как правило, для того, чтобы работая под Linux, иметь под рукой Windows или наоборот. Однако, при наличии множества родственных Linux-операционок, я стал замечать, что использование виртуальных машин — это, мягко говоря, нерационально.

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

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

Проект Tagsistant позиционирует свое творение, tagfs, как следование за общей тенденцией. Интернет шаг за шагом пытаются переводить на семантические рельсы, а файловые системы, считают авторы проекта, закоснели в устарелых принципах — иерархия, директории, вот это всё.
И в принципе, я с ними в чем-то согласен. Представьте, что у вас есть несколько сотен фотографий, одни из которых сделаны в Кёльне, другие сделаны на закате, на третьих изображены девушки, а четвертые сделаны в 2010 году. Теперь вообразите, что вы хотите выполнить следующую операцию: получить список фотографий, которые сделаны на закате в Кёльне с вашей подругой, исключая те, которые были сделаны в 2010 году.
Да, возможно, скажет кто-то, можно ведь создать директории, например, Koeln, sunset, girls, 2010, потом рассовать в них софтлинки на файлы… Как-то так, но разве это предоставит необходимую гибкость и удобство в составлении запросов (хотя бы в решении приведенного выше примера)?
Да, можно попытаться воспользоваться EXIF-тегами. Но камера не указывает в них присутствия девушек на фото и других критериев, ограниченных вашей фантазией. А если речь вообще не о фотографиях, а об отчетах?
Можно попытаться писать своеобразные теги в атрибуты файлов, используя ext4, при помощи setattr\getattr — по крайней мере, я видел такое предложение в вопросе тегирования файлов, не пробовал. Но это тоже половинчатое решение, даже если будет работать.
Реальный пример для затравки, который я могу придумать, исходя из моих потребностей. У меня есть папка с огромным количеством разного картиночного хлама, когда-либо сохраненного в Downloads и позже протегированного (на самом деле, не одна). Я хочу получить из всего этого мусорного полигона список фотографий форумчан-девушек, которые сделаны в Киеве, содержат изображения пива и сделаны раньше 2012 года. Вместе с ними я хочу получить изображения всех админов форума, которые у меня есть:

$ ls ~/tagsistant/store/forum/girls/beer/=Kyiv/time:/year/lt/2012/+/admin/@/

Представляю вашему вниманию перевод очень ёмкой, и в то же время достаточно краткой (для такого масштаба проблемы) статьи Карла Чео. Я решил, что очень хочу сделать её перевод практически сразу, как только начал читать, и очень рад, что в итоге сделал это.

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

Важные замечания:

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

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

Не секрет, что в больших конторах тема фильтрации Интернета довольно актуальная. С этой задачей справляется немало программных и аппаратных решений. Но в настоящее время все те сайты, которые мы резали ранее, работают по протоколу HTTPS, т.е. порт 443. Как известно, данный протокол проследить, прослушать и т. п., невозможно. А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. фильтрует только HTTP, т.е. порт 80. Как же резать Вконтакте, Одноклассники, iphide.info и многие другие подобные сайты? Как блокировать доступ к личной почте в организации, если использование оной запрещено порядками в организации? Да, можно фильтровать по IP адресам, но они частенько меняются, да и на многих ресурсах несколько IP адресов. Блокировать их на уровне файрвола как-то совсем не православное решение, и не совсем удобное.

И вот, совсем недавно, мне один товарищ рассказал, что он поднимает у себя в конторе кеширующий прокси с фильтрацией HTTPS, меня это заинтересовало.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Эта статья подойдет сетевым специалистам, которые находятся в поисках примеров возможной автоматизации ip сети с помощью подручных инструментов.

Как один из вариантов автоматизации, это взаимодействие программной среды с CLI (Command Line Interface) оборудования, так называемый ‘Screen Scraping’. Собственно, об этом варианте и пойдет речь.

В качестве программной среды, будет использован язык программирования Python версии 3.3. Для сомневающихся в потребности изучения языка программирования, необходимо отметить, что базовые навыки программирования на Python достаточно просты в освоении и для решения описанных ниже задач являются достаточными. В дальнейшем с совершенствованием навыков будет совершенствоваться код и уровень производимых продуктов. Для удаленного взаимодействия с оборудованием в основном будет использоваться протокол SSH, поэтому в качестве работы с SSH, для облегчения задач, выбран дополнительный модуль для Python – Paramiko. Как правило рассмотрение решения конкретных задач, может способствовать лучшему усвоению материала, поэтому не затягивая процесс далее будут рассмотрены выборочные примеры задач по возрастающей степени сложности и их решение с использованием выше описанных инструментов (важно заметить, все ip адреса, логины, пароли, названия и специфические значения параметров с сетевых устройств — вымышленные, любое совпадение случайно).

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

Материал разбит следующим образом:

1. Введение
2. Примеры сессий
3. Проверка авторизации на сервере (LOGIN, PLAIN, CRAM-MD5), Base64
4. Проверка шифрования SSL/TLS
5. Анализ почтового трафика при помощи tshark. Расшифровка SSL/TLS
6. Ссылки на материалы

Дело было вечером, делать было нечего... © С. В. Михалков
Навеяно публикацией «Как я bind`ом вирусы искал…», а конкретно этой веткой комментариев. Надеюсь, не поздно размещаю.

Сидел я и думал, телевизор Samsung, WinPhone, (а впоследствии может кофеварка и пылесос) показывают суперназойливую рекламу, надо с этим чтото делать, и раз в WinPhone и телевизор(кофеварку, пылесос) плагина AdBlock нету, то он должен быть там где ходит их трафик, на роутере.

Примерно год назад у меня возникла «острая» необходимость перевести систему резервного копирования данных в корпоративной сети на бесплатные рельсы. До этого использовался платный продукт от Symantec, по нему, конечно, много нареканий, но он работал, хоть и не всегда справлялся. Как обычно, все надо было сделать «вчера», и я приступил к поиску вариантов.

Для начала начал искать решение для резервного копирования файлов, очевидным решением было простая настройка скриптов на Linux по cron, но это не очень удобное и надежное решение, если серверов более одного(а у меня их около 50-ти) и структура достаточно динамична. Тем более если инфраструктура смешанная, Linux + Windows. Хотелось что-нибудь простое в дальнейшем обслуживании и извлечении самих копий, например, переложить восстановление пользовательских файлов на группу поддержки. Порывшись пару часов в интернете, я наткнулся на интересный проект UrBackup, он удовлетворял всем моим условиям.

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.