Или самый простой и удобный медиацентр, понятный всем домочадцам

картнка для привлечения внимания

Привет, Хабр! С каждым днем собрать дома медиацентр становится все проще. Вариантов много – от HTPC из старого железа до безымянных устройств размером с флэшку. На хабре было много обзоров самодельных бесшумных HTPC, android-боксов и нет-топов для реализации домашних медиасерверов. Я испытал много разных вариантов, прежде чем найти самый подходящий для себя и, самое главное, для домочадцев.

Задача-минимум:
1. Собрать и структурировать всю медиатеку воедино
2. Сделать ее максимально доступной к просмотру на двух телевизорах в разных комнатах
3. Иметь возможность просмотра или загрузки (для оффлайн просмотра) фильмов из медиатеки на мобильных устройствах
4. Удаленный запуск торрентов с мобильных устройств
5. Бесшумная работа устройств.

Путем проб и ошибок, я пришел к использованию XBMC на стареньком Mac-mini + Rapsberry Pi.
Пробы, ошибки, и удобная конфигурация под катом.

Обсуждение анонимности нужно начинать не со слов прокси/тор/впн, а с определения задачи: анонимно подключиться к чужому серверу по SSH это одно, анонимно поднять свой веб-сайт это другое, анонимно работать в инете это третье, etc. — и все эти задачи решаются по-разному. Эта статья о задаче «анонимно работать в интернете как пользователь».

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

Во-первых, нужно адекватно оценивать потенциального противника. Если вы хотите быть «анонимным», значит вы пытаетесь избежать возможности связывания вашей активности в интернете с вашим физическим расположением и/или настоящим именем. Обычные пользователи и так не имеют возможности вас отслеживать (технически, социальные методы когда по вашему нику на форуме легко гуглится ваш аккаунт в соц.сетях со всеми личными данными мы здесь не рассматриваем). Ваш провайдер/соседи могут иметь возможность прослушать большую часть вашего трафика, но, как правило, вы им не интересны (да, соседи могут украсть ваши пароли, но заниматься отслеживанием вашей активности или вашей деанонимизацией они не станут). Что же касается владельцев используемых вами ресурсов (веб-сайтов, прокси/vpn-серверов, etc.) то у них в распоряжении множество средств по отслеживаю вас (DNS-leaks, Flash/Java-плагины, баннерные сети, «отпечатки браузера», множество разных видов кук, etc.) плюс серьёзный коммерческий интерес к тому, чтобы надёжно вас отслеживать (для таргетирования рекламы, продажи данных, etc.). Ну а правительство и спец.службы могут получить доступ и к данным, которые на вас собирают веб-сайты, и к данным, которые собирают провайдеры. Таким образом получается, что те, кто имеют возможность и желание вас отслеживать — имеют доступ к большинству возможных каналов утечки.

Во-вторых, каналов утечки информации очень и очень много. И они очень разнообразны (от внезапно отключившегося VPN до получения реального IP через Flash/Java-плагины браузера или отправки серийника на свой сервер каким-нить приложением при попытке обновления). Более того, регулярно обнаруживаются (и создаются) новые. Поэтому попытка блокировать каждый из них в индивидуальном порядке, уникальными для каждого методами, просто не имеет смысла, всё-равно что-то где-то протечёт.

В-третьих, при «работе в интернете» используется не только браузер — большинство пользуются так же IM, торрентами, почтой, SSH, FTP, IRC… при этом часто информация передаваемая по этим каналам пересекается и позволяет их связать между собой (.torrent-файл скачанный с сайта под вашим аккаунтом грузится в torrent клиент, ссылка пришедшая в письме/IM/IRC открывается в браузере, etc.). Добавьте сюда то, что ваша ОС и приложения тоже регулярно лазят в инет по своим делам, передавая при этом кучу деанонимизирующей вас информации…

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

Тихим, теплым, вечером разрабатывая систему кэширования через memcached и добавляя сервер меня вдруг посетила мысль.

С чего все начиналось

А все началось с того, что я перешел с Debian семейства к семейству RHEL. Примерно неделю назад я первый раз своими руками(не могу сказать что на Ubuntu это было своими руками) поднял сервер для разработки проекта. Я своими руками правил конфиги nginx, apache, php — раньше на Ubuntu все ставилось в пару команд и работало само. Впрочем, правя конфиги, я стал лучше понимать, как оно там все работает. Наверное это меня и подтолкнуло к мысли о memcached.

Последнее время много «шума» вокруг HipHop VM и kPHP: каждый социальный гигант своё детище хвалит. Больше всего интересовала связка, указанная в заголовке. О kPHP что-то говорить ещё рано, хотя уже заранее известно, что ООП не поддерживается. А вот HipHop VM уже можно пощупать. Кто-то об этом звере слышал, некоторые пытались устанавливать, некоторым это удавалось.

В топике описывается процедура установки HipHop VM из исходных кодов под Debian 7. Возможно, кому-то этот топик сэкономит время, нервы и поможет перешагнуть грабли, по которым прошлись мы.

Клиент сформулировал мне в HOSTKEY задачу — на 1 (один) сервер с 12 ядрами и 64Гб памяти надо примерно 3-4Тб места под более-менее однотипные виртуалки, но что бы работало все как на SSD и при этом уложиться в 16000р в месяц. Стали думать, вариантов было несколько:

• делаем все на SSD. берем 6 дисков по 500Гб типа Samsung 840 Pro eMLC, собираем их в страйп или еще как хитро, добавляем пару дисков по 3Тб для бакапа и… не проходим в бюджет. 2U сервер, 8 портовый RAID контроллер и диски по 12000р за штуку не пропускают.
• Делаем все на жестких дисках, берем 12x300Gb SAS 15K и опять не проходим ни в бюджет, ни в производительность.
• Используем RAID контроллер с внешним SSD кэшем – LSI CacheCade или Adaptec MaxCache. Идея получше, но нам надо 4 диска по 2Тб в RAID10 – придется брать 8 портовый контроллер и к нему SSD на 120Гб eMLC или SLC. Что бы к SSD был доступ, опять надо брать 2U корпус. Контроллер 8 портов + SSD стоит около 37000р, в бюджет не проходим.
• Используем новую LSI Nytro MegaRAID NMR8100-4i. Берем 1U систему, ставим в нее контроллер, ставим в нее 4 диска по 2Тб в RAID10 и вписываемся и в производительность и в бюджет. Нитра стоит 27000р, на ней уже стоят 2 диска по 44Гб, причем SLC!

Сказано – сделано, примерно 3 рабочих дня и 4 вариант у нас на столе. Посмотрим, на что он способен — не на рекламных проспектах, а на практике.

Ну чтож, пост на тему «наболело».
Скажу сразу для тех, кто хочет подчерпнуть что-то из текста: морали нет, выводов нет. Просто мысли о наболевшем.

Последние несколько недель тревожат меня 2 темы в плане Интернета:
1. Слежка органов.
2. Непостоянство сервисов.

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

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

Итак господа, приближается первое августа, поэтому задумался я над тем чтобы заиметь себе ip страны, в которой попроще с законодательством в сфере p2p, а именно Нидерландов. После достаточно долгих поисков нашел провайдера, который обещал два ядра от E3-1230, пару гигов памяти, 460 гигов винта и прекрасный нелимитированный(специально связывался с саппортом по этому вопросу — уверяют что канал не режут и после сотни терабайт) гигабитный канал за какихто 40 с копейками баксов. Единственное но — виртуализация OpenVZ — обычно я настраивал OpenVPN на XEN или KVM, поэтому все прошло не так гладко как обычно и поэтому я решил поделиться полученными знаниями.

Добрый день, хабровчане!

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

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

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

BitTorrent Sync Alpha был выпущен в апреле, а сегодня мы рады сообщить о его переходе на новую ступень — Beta.

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

До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

• Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка
• Подключаемся к провайдеру по BGP
• Организуем резервирование и распределение нагрузки между несколькими линками
• Рассмотрим вариант резервирования без использования BGP – IP SLA

В прошлой статье был общий обзор сети Hyperboria, в этой мы рассмотрим её структуру, какие она решает проблемы и её прямое назначение — Mesh сеть между wi-fi устройствами.

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

Моё первое знакомство с коллегой-блоггером по имени Phil Gerbyshak состоялось, когда я опубликовал весьма подробный комментарий о том, что воспринимаю энерджи-менеджмент (управление энергией) и тайм-менеджмент (управление временем) как независимые друг от друга вещи, обе из которых следует использовать полноценно. Я также дал понять, что склонен считать подход тайм-менеджмента превосходящим энерджи-менеджмент по части пиковой производительности.

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

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

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Как часто бывает, зацепив одну, на первый взгляд, маленькую тему, с желанием быстро все узнать и все настроить, приходится закапываться в дремучие дебри и читать не одну статью и/или мануал. Так и получилось у меня в этот раз. Изначально было желание просто узнать, как обновлять порты (или исходные тексты портов) чтоб при желании, устанавливать не устаревшее ПО, но пришлось закопаться немного по глубже.
Эта статья предназначена только для новичков во FreeBSD, опытные профи тут вообще ни чего нового, думаю, для себя не найдут. По этому, если вы на «ты» с этой системой, можете смело пропускать дальнейший текст.
Информации на эту тему хватает, но из 6-10 заметок и статей я взял, так скажем, лучшие наработки и опыт, и записал их в одну, с ссылками на более полные статьи, так что при желании можно получить более подробную информацию по каждому пункту.
Содержание статьи:
1) Выбор ПО для обновления исходных текстов.
2) Процесс обновления исходных текстов системы и портов.
3) Обновление системы(ядро и мир).
4) Обновление портов при помощи pkg_*, portupgrade, portdowngrade.
5) Заключение
6) Дополнительная литература.

Зачем всё это? — спросите вы. Да просто захотелось поделиться с общественностью некоторым опытом, полученным в процессе оптимизации vds под нужды одного общеизвестного блого-социального движка, который на обычном хостинге чувствует себя, мягко скажем, некомфортно.

Началось всё с того, что я ушёл от firstvds, где уже ничто не спасёт от тормозов. Ушел на ганди.нет, взял одну шару (1 share), которую дали на месяц бесплатно. Кстати, акция эта (This summer, your server is free!) вроде еще не закончилась. ;) И начал на этой шаре проводить зверские эксперименты с установкой разного ПО. Тестировал результаты с помощью siege.

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

Думаю, практически все обитатели Хабра (и я в том числе) ненавидят домашнюю уборку. Все эти горы грязной посуды, кучки разбросанных вещей и анекдоты в стиле «женщины моют посуду после еды, мужчины – перед едой» и рассказы про живность в кружке из-под чая, собственно, довольно обыденная вещь. До жены я практически так и жил ) При этом умудрялся ещё проходить еженедельные проверки комнат в общаге, устраивать вечеринки, что-то готовить и не отравиться. А также искал и находил нужную вещь в своём «творческом беспорядке». У меня «датчик необходимости уборки» включался уже когда в квартире невозможно было ходить, но потом зато квартира блестела чистотой.

Так как мужской праздник прошёл, и, я надеюсь, отметили вы его преотлично, скорее всего после этого беспределья нужно будет навести порядок. Так как информации о мужской точке зрения на уборку вообще нигде нет, решил поделиться несколькими советами по уборке и вообще поддержанию квартиры\дома в чистоте. Эдакий Home GTD.

^{Авария в первом дата-центре и автоматический перезапуск сервисов в другом}

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

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

К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.

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

Первое правило безопасности при разработке Веб приложений гласит: —

Не доверять данным пришедшим от клиента.

Почти все это правило хорошо знают и соблюдают. Мы пропускаем через валидаторы данные форм, кукисы, даже URI.
Но недавно я с удивлением обнаружил, что есть одна переменная, приходящая от клиента, которую почти никто не фильтрует.
Речь пойдет о компрометации веб приложения через подмену значения HTTP_HOST и SERVER_NAME.

Без синхронизаций и т.д., в варианте «есть хостинг» или «файловая помойка» и надо быстро выкатить хранилище пакетов для дистрибутива Linux (так чтобы можно было подключиться к этому репозиторию и поставить оттуда всё необходимое). Иногда обновляться в ручном режиме — копированием по тому же адресу с перезаписью. Раз в полгода или год. Задача типовая и я её опишу в полуавтоматическом режиме.