Вступление

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

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

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

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

Конечно, после простого выкладывания показаний в Интернет я решил не останавливаться на достигнутом и замутил ещё распознавание показаний и графическое представление, об этом читайте в части 2 данного топика.

Приветствую, уважаемое Хабрасообщество!

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

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

Кому интересно — добро пожаловать под кат.

Еще не стих хабраэффект с нашей предыдущей статьи, а мы уже спешим поделиться с вами еще одной, не менее радостной новостью: онлайн редакторы документов Teamlab Office теперь можно развернуть на своем сервере и встроить в вебсайт или приложение. Бесплатно.

Это был спойлер, ну а подробности, как водится, под катом.

В данной статье рассмотрена связка Squid+TPROXY стоящий на отдельной машине. Как оказалось это тема почти не освещена на просторах интернета.

По роду занятия возникла задача фильтрации черного списка сайтов от РОСКОМНАДЗОРА. В ходе проверки нам пригрозили что если мы это не сделаем то введут санкции. Сказано сделано (всего на несколько минут) тупая и не очень дружественная к нашим клиентам реализация, которая просто не давала доступа ко всем сайтам внесенным в черный список. При этом фильтрация была просто по IP. И естественно перекрывала доступ ко всем сайтам на IP.

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

Недавно я наткнулся на топик "Сервер онлайн-вещаний на базе nginx" о замечательном модуле Романа Арутюняна (@rarutyunyan) для nginx: nginx-rtmp-module. Модуль очень прост в настройке и позволяет на основе nginx создать сервер публикации видеозаписей и живого вещания.

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

Началось всё с желания делать свои игры вместо того, чтобы делать чужие.
Полгода назад я (программист) и мой товарищ (художник) уволились с работы и решили начать делать проект мечты — раллийный симулятор.
Этот проект мы задумывали очень давно, но не хватало опыта и знаний, чтобы начать и закончить.
За несколько последних лет мы оба набрались опыта и созрели для того, чтобы наконец сделать этот проект.
Но за те 10 лет, что мы пробовали свои силы, наши наработки полностью устарели. Кодовая база оказалась сложно портируемой на мобильные устройства. Контент не соответствовал современным требованиям.
Пару месяцев мы ковыряли то, что у нас уже было в надежде понять, что же делать…
И пришли к выводу:
Надо прощупать почву

Нам надо было понять, каким образом ведётся разработка кроссплатформенного движка, способного адекватно работать как на ПК, так и на мобильных ОС. Как публикуется игра? Как ведут себя отдельные площадки и на каких условиях работают?
Нам нельзя на проекте мечты совершать детские ошибки. Проект должен разрабатываться и публиковаться с чётким пониманием: как, что и для чего делается.
И для этого мы взялись реализовать тестовый проект. Небольшую казуальную игру.
Эта статья о том, как мы публиковались на Google Play, как провалили публикацию на Greenlight и какие сюрпризы нас ждали в AppStore.

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

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

Но по-видимому, заноза прочно засела в голове, поэтому проснувшись в субботу я принялся творить.

Divine Elemente

Один из самых потрясающих проектов, которые я встречал за последнее время. Плагин Divine Elemente дает возможность дизайнерам создавать WordPress темы без каких либо навыков фронт/бэк-енда. К сожалению у меня не было возможности поработать с ним. Он доступен только для Windows. Для того что бы все работало необходимо создавать макет в соответствии со встроенным blueprint — это некий Bootstrap, Boilerplate или даже набор инструкций по наименовании слоев и групп. Разработчики обещают множество всего хорошего, в том числе: SEO friendly, валидную и семантичную верстку, читаемый код. Впечатляет!

Обычно после установки продуктов Mozilla в корпоративной среде требуется дополнительно установить:

• стандартный для компании набор плагинов
• сделать типовые настройки

Почему бы не интегрировать необходимые плагины и типовые настройки в дистрибутив?
Цель данной статьи — показать как можно перепаковать дистрибутив Mozilla, добавив необходимые компоненты.

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

Но наша цель — подготовить внутренний дистрибутив для своей организации, так что всё в порядке.

Что здесь интересного?

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

SaltStack (underfloor): что это и как с ним быть?

Многие уже имели опыт работы с системами автоматизированного управления конфигурациями, к которым относится Salt, и рассказывать подробно о том как его готовить и что он может я не стану, тут можно прочесть что это, а тут почитать как его быстро и легко приготовить.

SaltStack (lobby): типичное применение на простом примере

Итак, предположим, у Вас есть задача автоматизировать установку, внедрение конфигурационных файлов и мониторинг их изменений, перезагрузку в случае необходимости такого популярного сервиса как nginx. Для упрощения системы, сделаем предположение что обслуживаемые сервера построены на базе Debian Wheezy. (Для всех остальных, — читаем про grains систему, — она поможет определить на какой системе мы применяем стейт и соответствующим образом поменять его поведение).
Итак:

Думаю, большинству хабрапользователей хоть раз да приходилось кодировать видео. Возможно, вы хотели посмотреть свежую серию любимого сериала в метро, а ваш смартфон или иное портативное устройство никак не хотело играть этот кодек, или SmartTV отказывался декодировать звук в видеофайле, либо же вы застряли в 2004 и транскодировали H.264 в MPEG-4 для вашего старого DVD-проигрывателя. Или же, например, сжимали невероятного размера видео, снятое фотоаппаратом, во что-то более-менее приличное по размеру. Наверняка вы замечали, что это не самый быстрый процесс.

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

Что вообще следует понимать под распределенным кодированием видео? В моем представлении, есть 2 разных задачи:

1. Кодирование большого количества видеофайлов на множестве компьютеров одновременно
2. Кодирование одного видеофайла по частям на множестве компьютеров одновременно

Первая задача подразумевает наличие большого количества видеофайлов, сильно больше, чем компьютеров, на которых их можно кодировать, и довольно легко автоматизируется с использованием CLI-кодировщиков, например, HandBrake или FFmpeg и любых средств автоматизации, которые поддерживают распределение, вроде GNU Parallel или PPSS (к слову, о нем мало кто знает, рекомендую!).

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

Привет, друзья! Случилось однажды так, что для восстановления после травмы я прикупил себе такой вот прибор.

Со своими прямыми обязанностями он справлялся вполне удовлетворительно, но было одно «но», и заключалось оно в том, что спидометр путался в показаниях, и следовательно, показывал разные результаты по пройденной дистанции. Если идти достаточно медленно, то спидометр вообще молчал. И решено было сделать свой спидометр с… ну вы поняли.

Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync.

Всем привет!

Уже слышали про Bigdata? Ну да, веб растет, данных становится больше и их нужно держать под контролем и периодически анализировать. Базы данных — лопаются под нагрузкой, реляционная теория не совсем справляется с задачей, нужно решение. Маркетинг активно давит сверху, а железо острыми углами — снизу и попахивает суицидом.

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

Однако, если вдруг стало подташнивать и закружилась голова, можно дальше не читать — а полюбоваться на прекрасных птичек и забыть о вышенаписанном. Но будьте на чеку, Bigdata может завтра взять и постучаться в дверь ;-)

О системе OpenStack была масса статей на Хабре, однако ни одна не затрагивала вопросы разработки и тестирования составных сервисов. Скажу сразу, настраивать среду голыми руками дело не из легких и не совсем уж благодарное. К счастью, существует официальная программа под названием Devstack, которая представляет собой набор скриптов для автоматической установки OpenStack на локальную виртуальную машину. Ну вот, хотелось бы тут и закончить статью, однако не все так складно с этим Devstack. А именно, установить его — это целый процесс танца с бубнами и выбора правильных конфигурационных параметров. К тому же проект движется своим шагом, и то, что работало сегодня может вылететь при любом новом комите.

Задача

Необходимо построить среду разработки под OpenStack для тестирования, багфиксинга и добавления фич в сервисы системы (nova, keystone, swift, heat, etc.). Среда должна собираться почти автоматически, чтобы было возможно в любой момент стереть созданную виртуальную машину, создать новую, запустить скрипты и получить готовую среду через несколько минут. Причем среда должна быть такой же, как на прежней VM. Так как интересующий меня сервис на момент написания статьи является heat, то конфигурация будет ориентирована под него, однако путем замены пары строчек можно адаптировать всю конфигурацию под любой другой сервис.

Посвящается B_dot, пост которого заставил заинтересоваться возможностями консоли плотнее.

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

В этом посте будет рассказано о некоторых сочетания клавиш, которые могут упросить жизнь администраторам, работающим в консоли. Все они работают в bash'e. Сочетания клавиш я дополнительно проверял на циске (Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXH4), csh и zsh. Рассмотренное в других записях повторять особо не буду. Сочетания сгруппированы по использованной функциональной клавише.
Особенно полезен этот текст будет людям, которые любят использовать клавиши Home, End и Delete (которые в цисковой консоли «не работают»).

Безусловно, все те кто общается с ОС Linux хоть раз да имели дело(во всяком случае слышали точно) с командной оболочкой BASH. Но BASH не только командная оболочка, это еще и превосходный скриптовый язык программирования.
Цель этой статьи — познакомить поближе юзеров с bash, рассказать про синтаксис, основные приемы и фишки языка, для того чтобы даже обычный пользователь смог быстренько написать простой скрипт для выполнения ежедневной(-недельной, -месячной) рутинной работы или, скажем, «на коленке» наваять скриптик для бэкапа директории.

    В этой статье я рассмотрю по шагам подготовку к использованию Samba4 в роли контроллера домена вкупе с дополнительным файловым сервером так же на базе Samba4. Что в итоге мы получим? Два настроенных сервера с samba4, первый в роли domain controller, второй в роли member server с файлами пользователей. Функционирования этой связки я добивался около месяца, за сим, не поделится конечным рецептом просто не имею права…



    Немного предыстории: в компании используется файловый сервер на базе samba3.6 с LDAP Backend, который содержит список всех пользователей и групп с правами доступа. Права доступа на каталоги выставляются с помощью xattr_acl (Extended file attributes), в LDAP хранится список пользователей с соответствием группам доступа. Собственно требуется переехать с этой инфраструктуры на samba4…

.

Хочу рассказать вам про то как имея в интернете свой VPS-сервер можно поднять туннель в домашнюю сеть. И не платить при этом за статический IP провайдеру, и даже находясь за NAT, все равно сделать доступными в интернете свои домашние сервисы.

В каталоге бесплатных тем для Bootstrap есть симпатичная тема Lumen, в ней используется шрифт Source Sans Pro, в котором «из коробки» отсутствует кириллица. Эту проблему можно частично решить самостоятельно, скомпилировав шрифт из исходников. Почему частично — см. заключение.