Коллеги, в первой части статьи о SElinux мы рассмотрели основные особенности работы с системой SELinux. Как и обещано, теперь публикуем вторую часть, в которой основное внимание уделено настройке политик. Что же, приступим.

Часть первая

Продолжаем

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

В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:

# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.

После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:

# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2

Pacemaker

Итак, менеджер кластера.

mcdiff

В составе Midnight Commander, помимо всем известного редактора mcedit, есть не менее замечательная утилита для сравнения файлов «бок о бок» (side-by-side) — mcdiff. В ней можно сравнивать и при необходимости производить полное или частичное слияние в обе стороны.



Историю появления утилиты mcdif когда-то уже рассказывал тут но ближе к делу…

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

Я работаю системным администратором Unix. Однажды к нам в отдел эксплуатации сервисов упал тикет от программиста с выдержой из лога application-сервера в заголовке: "pgbouncer cannot connect to server". Посмотрев логи pgbouncer'ов, я увидел, что периодически возникают lookup fail'ы при обращении к нашим DNS. Было установленно, что это связано не с работой наших DNS-серверов, а с ненадёжностью самого протокола UDP: иногда возникают потери пакетов по разным причинам.

В результате, было решено установить на каждом сервере с pgbouncer'ами по кэширующему BIND. И тут возникла интересная проблема: pgbouncer не перечитывал по сигналу HUP файл /etc/resolv.conf и продолжал обращаться к старым DNS-серверам. А перезагружать баунсеры категорически нельзя: есть проблемные проекты, которые очень болезненно относятся к разрывом сессий с базой.

В данной статье я расскажу как можно pgbouncer или любую другую программу, использующую библиотечный вызов getaddrinfo(), заставить перечитать resolv.conf и начать использовать новый DNS-сервер совершенно безболезненно для клиентов (без даунтайма).

Часть вторая

Прелюдия

Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.

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

Вводные

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

В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.

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

В качестве софта было выбрано:

• Debian Wheezy + LTS ядро 3.10
• iSCSI-таргет SCST
• DRBD для репликации
• Pacemaker для управления ресурсами кластера и мониторинга
• Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)

В итоге, в недолгих муках была рождена такая несложная схема:

От переводчика: Это перевод второй статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья — http://habrahabr.ru/post/209144/

---

Прием и передача пакетов данных

Введение

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей второй статье из цикла “Сетевое программирование для разработчиков игр”.


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

А сейчас я собираюсь рассказать вам, как на практике использовать UDP для отправки и приема пакетов.

BSD сокеты

В большинстве современных ОС имеется какая-нибудь реализация сокетов, основанная на BSD сокетах (сокетах Беркли).

Сокеты BSD оперируют простыми функциями, такими, как “socket”, “bind”, “sendto” и “recvfrom”. Конечно, вы можете обращаться к этим функциями напрямую, но в таком случае ваш код будет зависим от платформы, так как их реализации в разных ОС могут немного отличаться.

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

• Под рукой есть лишняя флешка?
• Есть желание заиметь удобный инструмент для борьбы с компьютерно-системными болезнями?
• Не хочется таскать стопку дисков?
• Пользуетесь Debian или его внучкой Ubuntu, или, может, они есть на виртуалке, заботливо созданой заранее?
• Любите GUI там, где они действительно уместны?

Расскажу-ка я о LiveUSB Multiboot. Это опен-сорс программа (под GPLv3), которая даёт возможность легко и просто создать загрузочную флешку и кинуть пару образов со всем самым нужным, чтобы при случае запуститься с неё и не мучаться с ношением и записью дисков.

Netavis Observer — программный продукт для организации видеонаблюдения с помощью IP-камер на базе Linux-сервера.

Netavis Observer написан на Java, так же используются такие продукты как Apache Tomcat, Webmin, Munin, Mysql.

Существует два варианта Netavis Observer — Bundled(поставляется в виде установочного iso-образа на базе Centos5 или Centos6) и Unbundled — набора rpm-пакетов для самостоятельной установки на сервер под управлением Centos или RedHat.

От переводчика: Это перевод первой статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.

---

Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.


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

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

Всем привет!

В прошлой статье мы начали разговор о преимуществах контейнерной изоляции (контейнеризации), теперь мне бы хотелось углубится в технические аспекты реализации контейнеров.

Вот и настал тот день, когда пришлось отложить в сторону кукбуки, рецепты, нож шеф-повара и немного позаниматься кукловодством.
Для начала постановка задачи довольно тривиальная — организовать для девелоперов возможность быстро и просто разворачивать окружение. Обязательное требование — для автоконфигурации использовать Puppet Enterprise

Как скоро я смогу вас заинтересовать, если скажу, что в этой статье речь пойдет о VPN-сервере, который может поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол «SSL-VPN», который неотличим от обычного HTTPS-трафика (чего не скажешь про OpenVPN handshake, например), может работать не только через TCP/UDP, но и через ICMP (подобно pingtunnel, hanstunnel) и DNS (подобно iodine), работает быстрее (по заверению разработчиков) текущих имплементаций, строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает как kernel-mode, так и user-mode NAT, IPv6, шейпинг, QoS, кластеризацию, load balancing и fault tolerance, может быть запущен под Windows, Linux, Mac OS, FreeBSD и Solaris и является Open-Source проектом под GPLv2?

То-то и оно. Такое пропустить нельзя.

Доброго времени суток, хабровчане!


Думаю многих из вас когда-либо посещала мысль «вот бы сохранить статьи с Хабра».
Такая же мысль посетила и меня два дня назад. Сохранить захотел не просто каждую статью, а только те, что в избранном, да не поштучно, а сразу всё скопом.
Первая мысль — надо написать скрипт, который всё это вытянет. Python я уже подучил, но вот с генерацией PDF на нем сталкиваться ещё не приходилось.

Закручинился я было… Но OpenSource и Хабр спасли меня!

Введение

В связи с тем, что не многие, как оказалось, знают про Stash немного о нём. На сайте производителя даётся такое описание:

Интерфейс Stash позволяет с легкостью выполнять задачи по администрированию и управлению. Stash хранит ваши растущие Git репозитории в безопасности в пределах зоны действия файервола. Добавляйте пользователей и группы пользователей, устанавливайте детализированный правила прямо из UI (пользовательского интерфейса). Создавайте и управляйте репозиториями в рамках Stash. Быть в курсе всех командных дел и вывести их в единый список – дело всего пары минут.

Грубо говорят Stash от Atlassian — это ваш локальный ГитХАБ. Особая прелесть этого инструмента заключается в том, что он очень тесно интегрирован с той же JIRA от Atlassian, что обеспечивает гораздо более удобную ревизию кода по выполняемой задаче и единый интерфейс для этого.

Установка

Установка указанного продукта достаточно проста. Но я всё таки нашёл для себя грабли.
Отчасти это было связано с тем, что ставил я на CentOS. С этим дистрибутивом я до недавнего времени опыта почти не имел.

Фактически данная статья это вольный перевод Getting Started руководства с сайта Atlassian в разделе установки в Linux.

Пригодится начинающим.

Хочу поделиться и обсудить возможности использования протокола IP через сети P2P на примере IPOP.

Кратко:

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

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

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

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

• вики, учет задач, тикетов, дефектов;
• система управления версиями/репозиторий;
• файловый сервер.

И если в случае первого и второго предлагается множество прекрасных средств, в частности для багтрекинга существуют известные каждому Redmine, Trac, а для управления версиями Subversion, Git, Mercurial, то для грамотной организации файлового хранилища приходится в очередной раз изобретать велосипед.

Abstract: О новом тренде — software defined strorge и главной родовой травме блочных устройств — обещании бесконечной надёжности.

Лирика

На горизонте новый buzzword: Software defined $thing. Мы уже имеем состоявшийся и сформировавшийся круг всего, относящегося к software defined networks (SDN), пришла очередь и storage (SDS). Видимо, дальше у нас будет software defined computing или ещё что-то подобное, потом резко всполошатся и подтянутся HP/VMWare и предложат (private) «software defined enterprise», который будет означать всё тоже, что было, но ещё моднее и актуальнее.

Впрочем, рассказ не про баззворды. За каждым таким странным названием (grid, elastic, cloud) стоит дальнейшее развитие технологий — построение дальнейших слоёв взаимодействия компонент (эм… взаимодействия участников взаимодействия, иначе не скажешь), основным мотивом которых является уход от гранулированности компьютерной системы, так, чтобы вся терминология, вся предметная область ушла от «межпроцессного взаимодействия» и стала автономной. В более-менее приличном виде мы это (в виде уже свершившегося факта) мы видим в волшебном мире javascript работе www, когда нас никаким образом не волнуют сервера, на которых крутятся задачи — всё общение происходит на уровне между браузером (с учётом его интимных подробностей DOM, JS и т.д.) и абстракцией, под названием URI, которой не важно — один это сервер или сотни разных.

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

Перед рассказом про SDS, посмотрим на уже состоявшееся: SDN (software defined network).

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

А между тем, сборка в память обладает двумя очень значительными преимуществами:

• Значительное увеличение скорости сборки за счет отсутствия операций ввода-вывода на жесткий диск (в большей степени это касается классических жестких дисков, особенно со скоростью вращения 5400 оборотов в минуту)
• Увеличение времени жизни вашего SSD за счет перемещения интенсивных операций записи в память

Если учесть, что в последние годы сильно вырос объем оперативной памяти на компьютере среднестатистического разработчика и повсеместно начинают применяться SSD, то аргументов «против» практически не остается.

Главная цель этой небольшой статьи — вызвать мысль: «А ведь действительно! И как я раньше об этом не подумал?».

Я опишу пример реализации такого подхода в Linux. Действия в других операционных системах будут практически идентичными, за исключением методов создания самого RAM-диска.