rTorrent — еще один из самых популярных torrent клинтов в мире Unix-подобных операционных систем (о Transmission я уже написал несколько ранее). При создании этого клиента, по заявлению автора, во главе угла стояли «высокая производительность и хороший код», а использование mmap для отображения файлов в память позволяет добиться на широкополосных каналах трехкратного преимущества перед официальным клиентом. Еще одной характерной чертой rTorrent является наличие множества различных web-интерфейсов «на все вкусы» для удаленного управления. Именно об установке и настройке всего этого я и хочу рассказать на этот раз.

С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

Многие слышали о различных оптимизированных и улучшенных ядрах, это — Zen Kernel и pf-kernel из известных мне. Кроме того, что они добавляют новые возможности (TuxOnIce, поддержка aufs), они могут улучшить производительность, благодаря улучшенному менеджеру задач (BFS) и планировщику (BFQ). В этом топике я хочу сравнить производительность pf-kernel со стандартными ядрами в Ubuntu и Arch Linux, а также описать процесс сборки и установки pf-kernel для Ubuntu. Тестировать Zen Kernel я не вижу особого смысла, т.к. во-первых, проект выглядит заброшенным, а во-вторых, набор патчей и там и там очень похожий.

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

Привет, `whoami`.

В этом посте я расскажу тебе об одном из методов автоматизации интернет-вещания – не самом надежном, но самом бюджетном. Сразу предупреждаю, что эта система заточена на использование ее под Linux, хотя с помощью знакомого многим «столярного инструмента», можно и под Windows реализовать. Эта статья расчитана на начинающих IT-шников, поэтому многие моменты я постарался «разжевать». Как у меня это получилось, решать тебе, мой дорогой читатель, но если мне удалось заинтересовать тебя, прошу под кат.

Хотелось бы поговорить с вами на актуальную нынче тему, а именно — про DDoS и методы борьбы с ним. Рядовые администраторы знают, что это такое, а вот для большинства вебмастеров это аббревиатура остается загадкой до того момента пока они на личном опыте не столкнуться с этой неприятностью. Итак, DDoS — это сокращение от Distributed Denial of Service (распределенный отказ в обслуживании), когда тысячи зараженных компьютеров отправляют на сервер множество запросов, с которыми он, в последствии, не может справиться. Целью DDoS атаки является нарушение нормальной работы сервера, а в дальнейшем — «падение» сайта или сервера целиком.

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

В этом топике расскажу как можно в пару скриптов наладить простой сбор статистики по аномальной активности в сети.

Аномальным для нас будет на момент снятия статистики:

1. Более 20 исходящих коннектов по 25 порту с 1 IP.
2. Более 100 исходящих коннектов по 80 порту с 1 IP.
3. Более 100 исходящих коннектов по 53 порту с 1 IP.
4. Придумывайте сами, всё гибко.

Статистику будем вынимать из кэша netflow маршрутизаторов. Будет ли это Cisco или FreeBSD — не важно. О настройке netflow на FreeBSD я рассказывал в предыдущих своих статьях.

Стоял как-то раз админ в курилке и думал — а как бы ему так в нерабочее время вдали от компьютера и интернетов узнать, что на каком-то из его серверов проблема возникла. Можно конечно посадить студента за монитор с Nagios, чтоб он если что звонил админу и говорил «Тут красненькое что-то появилось»… Стоп. Звонил. На мобильный. Нафиг студента, SMS можно получать. На этом мысль остановилась и админ пошёл пить кофе. Потом вернулся и сел за рабочее место, где в браузуре был загружен Google Calendar… и решение пришло само.

Думаю многие слышали о криптографии эллиптических кривых, о том
что работает она во много раз быстрее RSA и при несоизмеримо меньшей длине ключа обеспечивает несоизмеримо большую стойкость ко взлому. Если не слышали, то можно глянуть на wiki или почитать в книгах А.А. Болотова.
К сожалению, данный вид шифрования слабо распространен. Я постараюсь объяснить как им пользоваться и поможет мне в этом OpenSSL.

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

Видно, что популярным сегодня ключам RSA длиной 1024-2048 бит соответствует всего навсего 160-224битный ключ ECC (Elliptic Curve Cryptography)

Ну а чтобы понять какой RSA тормоз достаточно попробовать сгенерировать самый длинный из предложенных в таблице ключей (и пойти вздремнуть):

openssl genrsa 15360

Желающих прикоснуться к «next gen» криптографии, придуманной аж в 1985 году, прошу под кат.

Задача

Необходимо объединить несколько существующих разделов в один без потери информации. Такое может случиться, если заранее не был задействован LVM, а необходимо расширить пространство, например, для торрентов.

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

Это руководство описывает, как настроить репликацию базы данных в MySQL с использованием SSL соединение для шифрования.
MySQL репликация синхронизирует базу данных, что позволяет иметь точную копию БД на другом сервере. Все обновления БД на главном сервере автоматически реплицируются на другой сервер, что позволяет защитить базу от аппаратных сбоев. В этой статье будет показано, как реализовать репликации БД exampledb с сервера server1.example.com(ip адресом 192.168.0.100) на сервер server2.example.com(ip адресом 192.168.0.101) с использованием SSL соединения

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

• Серфить по репозиторию
• Просматривать логи
• Копировать директории для создания tags/branchs
• Создавать/удалять/переименовывать директории
• Извлекать/экспортировать (checkout/export)

При этом любая операция делается нажатием одной-двух кнопок, не считая ввода комментариев, и не требует помнить/вводить длинные пути, такие как:<br><br>

$svn cp "http://workserver.com/_main_repository/embedded_system/product_xxx/_trunk/main_task/ http://workserver.com/_main_repository/embedded_system/product_xxx/_tags/"

Под катом обзор внутренностей, результат можно скачать по ссылке svnb
Сделать исполняемым, запускать в директории — рабочей копии svn (запустить можно в любом месте, но тогда придется ввести путь до репозитория с которым вы хотите поработать).

P.S. В конце статьи добавил еще одно решение для улучшения юзабилити command line svn — автодополнение пути.

Недавно столкнулся с неприятной ситуацией — почтовый сервер попал в спам-листы. Дыру быстро нашли и залатали, но компания Oracle уже занесла наш сервер в свой черный список, причем блокировали нас ещё на стадии соединения.
Возник вопрос — куда писать? На сайте была только форма для клиентов, support@oracle.com предназначался для них же.
После недолгих раздумий, появилась мысль — а нет ли стандарта, определяющего почтовые адреса по которым надо писать в таком случае? Оказалось, что есть и описан он в RFC 2142.

Самое интересное содержится в таблицах, которые приведены ниже.

Третья часть. Предыдущие части: Первая, вторая.

В этой теме: управление памятью и процессорами виртуальных машин.

Память

Для того, чтобы понять, как XCP работает с памятью, нужно понять, как с ней работает Xen. В отличие от OpenVZ, Xen всегда выделяет память виртуальной машине (точнее, домену) в монопольное пользование. Память домена — это память домена и только. Никакого оверселла, никаких shared pages, никакого hypervizor swap (виртуальные машины свопиться, разумеется, могут). Если у вас есть 4Гб, то примерно 3.5Гб вы можете разделить между гостевыми машинами (512 уйдёт на dom0). Как вы будете их делить — ваша свобода. Но дать машине больше памяти, чем есть в наличии вы не сможете. Нет. Точка.

Зато в управлении реально выделенной памятью всё очень хорошо. В Xen 3.4 механизм управления памятью (xenballoon) основан на довольно сложной для восприятия мозгом, но простой с точки зрения гипервизора, основе: страницы памяти передаются (transfer) между доменом и гипервизором.

Предыдущая часть определяла терминологию. Теперь перейдём к обстоятельному объяснению «как это устроено». (тем, кому не терпится «взять и запустить» могут сделать с помощью руководств на сайте xen'а).

В этой части: подробнее про пулы и обзор устройства хостов и чуть-чуть о Xen'е.

Пулы

Весь XCP представляет собой один пул (поддержка нескольких пулов есть в очень отдалённых планах). В принципе, компания может иметь несколько пулов. Если используется разное железо для хостов, то придётся формировать пулы в пределах одинакового железа; в вырожденном случае это означает «один хост — один пул». В такой конфигурации возможность живой миграции отсутствует, а единственной опцией является экспорт/импорт виртуальной машины (медленно и неавтоматически). Соответственно, нужно иметь хотя бы пару одинаковых машин, чтобы получить возможности живой миграции (одинаковых означает «совсем одинаковых», вплоть до степпинга процессора). Чуть раньше возникли вопросы, можно ли в пул собрать разное железо. Официальный ответ: нет. Если очень захотеть, то можно, но все возможно возникшие при этом глюки будут вашими собственными именными граблями.

Каждый хост пула (его устройство обсуждается чуть ниже) имеет полную информацию о состоянии всех машин в пуле (хранит всю базу пула). Выполнять же операции может только один хост, именуемый «мастером пула». Мастер может легко меняться на ходу (без перезагрузки и остановке в работе виртуальных машин), в случае «смерти» мастера его роль может быть перенесена на другой хост силком. Если бывший мастер после этого загрузится, то произойдёт «pool split» — разделение пула на две неравные части, когда бывший мастер считает, что это он мастер, а все остальные подчиняются новому мастеру. Эта проблема легко решается силовой сменой настроек «бывшем мастере».

С мастерами следует играться осторожно, именно из-за игр с тем, кто мастер, я и получил ситуацию "Ghost in the Xen" (когда была запущена виртуальная машина, отсутствующая в списке машин облака). Впрочем, со времён XCP 0.1.1 ситуация немного поменялась, и поведение хостов в отстутствии живого мастера стало более разумным.

Среди всех энтерпрайзнутых систем виртуализации XCP единственная бесплатная и свободная. История XCP уходит в XenServer, который хоть и основывался на опенсорсном гипервизоре, но был вполне себе платным софтом. Цирикс опубликовала код XenServer под свободной лицензией и с этих пор XenServer начал плавно превращаться в Xen Cloud Platform.

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

С пользовательской точки зрения основным различием между обычным зеном (в составе большинства ОС) и XCP является процесс установки и количество добработок до запуска в продакт. XCP поставляется в виде ISO'шки с готовой ОС для dom0 (CentOS), адаптированной для обслуживания гипервизора и обеспечения работы хостов в облаке. Xen же обычно идёт в виде hypervisor + utils, подразумевается, что всё остальное человек создаст сам. Ещё некоторым бонусом для тех, кому приходится соприкасаться с продукцией Microsoft, являются подписанные драйвера для Windows (их с некоторыми ухищрениями можно установить и в зене, но в XCP они являются родными).

XCP — относительно своеобразная платформа. Она не «закрыта» в том смысле, как закрыт, например, hyper-v, но идёт в виде готовой ОС, многие аспекты конфигурации которой контролируются средствами платформы, а не ОС. Например, сеть: можно повесить ip-адрес на любой интерфейс ifconfig'ом, но последствия этого будут печальные — следует использовать инструментарий платформы для управления сетями и интерфейсами.

XCP состоит из нескольких компонент: xen, xapi, open vswitch, xe cli, stunnel, sqeezed обеспечивающих разные аспекты работы системы.

В начале о системных требованиях:

Иногда бывает необходимо принудительно разорвать активное соединение. Самый распространенный способ:

netstat -na
kill PID

Проблема в том, что один воркер может одновременно обслуживать несколько соединений, поэтому правильнее будет убить соединение а не воркер. Для этого на многих форумах рекомендуют использовать tcpkilll, cutter или awk+hping3. Однако, хоть эти утилиты и находятся в официальных репозиториях, мне не удалось заставить их разрывать соединения.

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

killcx 94.133.119.242:4403

В старые добрые времена наш проект неоднократно подвергался DDoS атакам разного типа, разной мощности и продолжительности. Мы отработали много разных методов защиты, а также оптимизировали саму структуру сервиса, частично в аспекте хостинга и расположения серверов. Важной частью выученного урока была правильная настройка DNS. Как показала последняя атака на Хабр и комментарии о проблемах, аналогичным нашим, не все уделяют защите DNS должного внимания, а очень и очень зря.

Для реализации понадобится уверенные знания работы TCP/IP и желание понять. В результате мы получим возможность сканировать удаленную машину на открытые порты от чужого адреса по следующией схеме (картинка из мануала по nmap):