MCollective: пишем custom data plugin

Когда держишь ферму однообразных серверов, особенно на Амазоне, очень полезно использовать инструменты для быстрой конфигурации серверов и получения с них различной информации. Для этих целей у меня развернут Puppet и MCollective.

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

Например, той же роли: сколько у нас вторичных серверов БД, какие версии БД установлены и т.д. Можно, конечно, воспользоваться простым regexp фильтром. Но в данном случае он не очень удобен - имена ролей, в принципе, могут частично пересекаться. К примеру, роль у нас прописана в puppet манифесте для одного хоста
role = "db-master,puppet-master"
а на втором
role= "db2-master"
уже имеем сложность отличить при помощи regexp db от db2

Поэтому логично сделать простой data plugin, который самостоятельно распарсит роль и выдаст результат

Перенос блога с Wordpress на Blogger

Посмотрев статистику, я был весьма удивлен. Коротенькое сообщение "Перенос блога" привело много посетителей.

Судя по всему, тема по "переезду" с одного места на другое весьма животрепещуща :)

Поэтому коротко расскажу, как я переезжал с Wordpress на Blogger.

Amazon EC2. Миграция "LVM over software RAID" тома между инстансами

Имеем следующую задачу.
На одном инстансе Server1 на Amazon EC2 подключены несколько EBS томов, объединенных в software RAID10 (для повышения скорости работы). Поверх рейда установлен LVM, где хранятся большие объемы данных.

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

Самое логичное, что можно сделать в таой ситуации - перемонтировать EBS тома на новый инстанс и активировать RAID + LVM уже на новом сервере, сохранив при этом данные.

Далее я опишу эту процедуру.

Перенос блога

Блог переехал на гугльблоггер.
Надеюсь, проблем не будет

К сожалению, на фиды придется переподписаться :(

PS. Судя по количеству посетителей странички, народ интересуется процедурой переноса. Описал, куда деваться, вот тут

Amazon EC2: обновление ядра linux в AMI

Одним из первых вопросов системных администраторов, которые начинают работать с сервисами Amazon, является: "а как обновить ядро в моем инстансе?".

До сравнительно недавнего времени ответ был один: "никак". Точнее, ядро можно было сменить, но только на одно из предоставляемых Amazon. Однако, ничто не стоит на месте. Появилось сразу два решения этой проблемы.

Первое: Амазон выпустил свой Amazon Linux (на базе RedHat Linux, но с массой изменений, в частности, kernel версии 3.х.х). В случае использования этого дистрибутива, проблемы нет вообще: обычное обновление инстанса через обычный yum с репозитариев Amazon.

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

Вот про этот второй способ я и расскажу.

OSSEC 2.7 - продолжаем патчить segfault

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

Согласно документации настроил проверку логов, используя wilcards:
<localfile>
<log_format>apache</log_format>
<location>/var/log/nginx/*.log</location>
</localfile>

Разумеется, файлов с логами было довольно много, порядка 20-30 штук.
При попытке запустить ossec ловим segfault на вычитке конфигурации! Честно говоря, я был в шоке.
Убедился, что segfault вызывает именно наличие wildcard, и полез дебажить и читать исходники.

OSSEC - система IDS. Опыт начинающего :): ossec-logcollector segfault

Проблема детектирования вторжения и/или атаки рано или поздно встает перед любым админом.
Существует много разных IDS, базирующихся на разных принципах. От простых анализаторов логов до сложных аппаратно-программных комплексов.

Передо мной, собственно, поставили достаточно четкую задачу. Нужно пройти PCI DSS, в частности, решить проблему с широко известными в узких кругах пп.10.5 и 11.5 :)

Серверов много. Поэтому очень желательно решение с централизованным управлением и отчетами. Есть, конечно, коммерческие решения. Но они весьма и весьма недешевы. С другой стороны, меня заверили, что было немало прецедентов прохождения PCI с использованием OSSEC - Open Source Host-based Intrusion Detection System. Поэтому, закатав рукава, беремся за работу.

За основу была взята версия 2.7-beta. Выбор, может конечно, показаться несколько странным, но версия 2.6 имела ряд недостатков конкретно для существующего окружения и показала себя местами весьма нестабильной.

"Хозяйке на заметку" - Работаем вдвоем на одной консоли (шелл).Подводные камни при работе с ssh

Иногда в практике админа возникает необходимость проконтролировать, а что и как, собственно, делает пользователь и/или младший админ на консоли. Например, в процессе показа и обучения пользования ОС или какими-то ее особенностями. В частности, не так давно мне нужно было обучить junior админа некоторым небольшим фокусам в linux. Ну хорошо, если они (админ и обучаемый) сидят в одной комнате или хотя бы живут в одном городе. А если на разных континентах?

Очень удобно в таких случаях работать одновременно на одной консоли. Казалось бы - достаточно расшарить экран хотя бы по тому же скайпу. Но как быть, если учителю нужно набрать пару команд и показать результат и действия? Пользоваться платными сервисами для создания вебконференций? "Шурик, это же не наш метод!" (с) :) Все гораздо проще.