Хочется поделиться с хабросооществом информацией о том как я собирал домашний сервер.



Из софта на домашнем сервере будет «крутиться» следующий набор:

• torrent клиент с web-мордой
• DHCP — раздаем ip адреса и сетевые настройки
• TFTP — для сетевой загрузки
• OpenVPN — для хождения в сеть с нетбука из недоверенных сетей
• FTP/Samba/NFS — сетевые шары для доступа с домашних машин
• Radius — для WPA2 авторизации
• DigiTemp — мониторинг домашней температуры

Привет, Хабр! В ходе обсуждения одной статьи про «идеальную» домашнюю сеть, возник спор, что лучше, аппаратный NAS или мини-компьютер с Linux дистрибутивом. Автор предлагал использовать аппаратный NAS, т. к. якобы он проще в администрировании, не требует знаний Linux, да и вообще NAS тихий. Но при этом, для просмотра на DLNA-телевизоре видео, который он не поддерживает, предлагал включать ноутбук с транскодирующим DLNA. Меня это, мягко говоря, удивило, т. к. в идеальной сети такого быть не должно. Поэтому хочу представить своё видение одного из ключевых компонентов домашней сети — централизованного хранилища данных, и основано оно будет на мини-ПК с ОС Ubuntu Server.

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

• Linux — based систему на машинах-клиентах;
• Тонкие/толстые однотипные клиенты на различном железе;
• Сетевое хранилище клиентских данных;
• Предустановленный регламентированный софт;
• Openvpn/rdp к серверам приложений.
• Плюшевый (мягкий и пушистый) мониторинг linux клиентов типа Nagios.

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

Загрузочная флешка с набором нужного софта — замечательный инструмент системного администратора. Казалось бы, что может быть лучше? А лучше может быть загрузочный сервер!

Представьте, вы выбрали в BIOS загрузку по сети и можете установить ОС/вылечить компьютер от вирусов/реанимировать диски/протестировать ОЗУ/etc с PXE Boot сервера, ведь это куда удобнее, нежели бегать с флешкой от машины к машине.
А в случае большого компьютерного парка, такой инструмент и вовсе незаменим.

Вот такое меню встречает нашу команду инженеров при загрузке с PXE



Под катом вас ждет описание всех настроек, а так же небольшой сюрприз.

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

В универе файлов стало еще больше, количество компьютеров дома возросло до 3 штук, я начал делать бэкапы. Пока просто, делая копии текущих папок на компьютере, не особо заморачиваясь с их структурой. Под конец обучения я задумался, стоит ли хранить огромное количество своих документов на внешних серверах. Подумав немного, решил, что лучше так не делать и решил слезть с иглы Evernote. Предварительно я продумал структуру хранения файлов на компьютере, чтобы даже без поиска легко найти нужную информацию. Каждой теме, которая меня интересовала, я создавал папку в /home/username папке. Это я называл категориями. Внутри каждой категории были подпапки-проекты, обязательной была папка misc практически в каждой папке, чтобы в файловом менеджере не видеть кучи беспорядочно наваленных неструктурированных файлов. Например, у меня были папки Bioinformatics/Aligner, Development/Projects/GameOfLife. Были четкие правила наименования файлов и папок (без нижних подчеркиваний, camelCase, папки с большой буквы, файлы с маленькой). Всё вроде было хорошо, но я ленился и не всегда красиво выкладывал файлики в нужные папки, что в конечном итоге привело к захламлению моей структуры. Я решил попробовать что-то другое…

В сфере компьютерной безопасности использование генератора случайных чисел (ГСЧ) является основой для создания любой криптографической системы. К примеру, ГСЧ используются для защиты личных данных при обработке транзакций с кредитных карт, совершенных через Интернет. Хотя, не вам нам объяснять.



Интересная новость из области разработки генераторов случайных чисел пришла недавно из Швейцарии: физики из Женевского университета нашли способ получать случайные числа, используя принцип квантовой неопределённости при обработке сигнала с сенсора цифровой камеры Nokia N9.
Давайте попробуем разобраться, что же в этом такого.

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

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

Для сведения: Во многих упоминаниях данной статьи авторы ошибочно называют меня сотрудником Opera Software. На самом деле я ушёл из Opera больше года назад и сегодня работаю в новой компании — Vivaldi Technologies AS

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

Предыстория

Как я уже рассказывал в моей предыдущей статье, несколько недель назад в библиотеке OpenSSL была обнаружена уязвимость (CVE-2014-0160), получившая громкое название "Heartbleed". Данная уязвимость позволяла злоумышленникам добывать такую важную информацию, как, например, пользовательские пароли или закрытые ключи шифрования сайтов, проникая на уязвимые «защищённые» веб-серверы (поясняющий комикс).

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

О том, как я взял и съездил в Южную Америку

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

Эта история началась довольно давно, в жарком Израиле, где в гостях у своего одноклассника я между делом завел разговор о том, что правила в Google'е разрешают сотруднику иногда работать в том офисе, в каком он захочет, и рядом с которым оказался по своим личным делам. И он, одноклассник, убеждал меня, как же я должен пользоваться этим, благо география обширная (вот кстати и список). Но история пробуксовывала еще где-то год, пока не появились еще два одноклассника: Гостеприимный и Энергичный, и тогда я подумал: пора! Южная Америка – самое то.

Предыстория

Существует красивое решение для создания надёжного недорогого кластера основанное на DRBD + Proxmox VE. Страница в Wiki проекта Proxmox появилась 11 сентября 2009-го года и создана она была CEO компании Martin-ом Maurer-ом.



С тех самых пор это решение стало очень популярным, и никто не подозревал, что у этого решения есть скрытый подводный камень. В документации про это не пишут, а те, кто сталкивался с последствиями этой проблемы (например, зависание машины при онлайн миграции с одного хоста на другой), списывали всё на «случай». Кто-то грешил на железо, кто-то на Proxmox, а кто-то на драйверы внутри виртуальной машины. Конечно, хотелось бы, чтобы DRBD сам сообщал о своих проблемах, и, как-то подсознательно веришь в то, что он так и делает. Проверяешь /proc/drbd, видишь строку «cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate» и продолжаешь верить что DRBD не причём.