Всем привет!

Предлагаю сделать простую проверку безопасности на ваших серверах.

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

Замечу, что например апачевский юзер не должен иметь прав на изменение и удаление апачевских логов.

С Новым Годом!

Несколько лет назад после прочтения матрицы компетентности программиста я поискал аналогичную матрицу для системных администраторов. Ближашее что я тогда нашел это Sage Level Job Descriptions, но меня не оставляло желание составить для системных администраторов аналогичную таблицу.

Я несколько раз начинал это делать, потом бросал и снова начинал, и только теперь наконец-то сделал:

Постановка задачи

Описание проблемы

В работе используется большое количество физических серверов на базе Debian GNU/Linux. Разработчикам часто бывает нужно предоставить на растерзание клоны этих серверов, каждый раз клонировать руками неэффективно. Примечание: конкретный дистрибутив при описываемом методе не важен, метод очень легко адаптируется под любой дистрибутив.

картинка для красоты

Задача

Сделать автоматическую систему клонирования боевых серверов в виртуальные машины по крону.

Что получилось

virt_server> p2v.py foo full
WORKING WITH SERVER: 'foo'
READING CONFIG FOR 'foo'
CHECKING LOCAL CONFIG
CHECKING LOCAL CONFIG FOR 'foo' COMPLETED SUCCESSFULLY
CHECKING REMOTE CONFIG
CHECKING NODUMP FLAG: "lsattr -d /home/backupman/dumps | egrep '[\\w-]+d[\\w-]+[ ]/data/dumps'"
CHECKING REMOTE DUMP: 'sudo /sbin/dump a0f /dev/null /dev/null'
CHECKING IF WE ARE ABLE TO SSH TO: "ssh -T backupman@foo 'if [ -d /data/dumps ] ; then exit 0 ; else exit 1 ; fi'"
CHECKING REMOTE CONFIG FOR 'foo' COMPLETED SUCCESSFULLY
DUMPING FILESYSTEMS
GETTING THE DUMPS
STOPPING VM: foo2 
MAKING FS TYPE: ext3 ON PARTITION: /dev/mapper/foo
RESTORING DUMPS FOR: foo
INSTALLING BOOTLOADER FOR: foo
RESTORING CONFIG FOR: foo
STARTING VM: /etc/xen/foo.xm

Уровень: начинающим, продолжающим, ленивым

Что, опять? Но зачем!?

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

Постановка задачи

Описание проблемы

В работе активно используется Xen с HVM виртуализацией. Часто бывает нужно получить доступ к консоли виртуальных машин, причем в том числе и тем, у кого доступа на севера с Xenом нет. У Xenа для этого есть возможность создавать для каждой виртуальной машины VNC-консоль, но каждый раз подключаться через VNC вручную неудобно.

Задача

Сделать веб-страницу со списком запущенных виртуальных машин и внедренным в нее VNC-апплетом, который можно открыть по нажатию ссылки. По пути разобраться с тем, как можно работать с Xenом из Питона.

Что получилось

Список запущенных domU

Сама VNC-консоль

Уровень: начинающим

Опыт использования виртуализации на VirtualBox

Введение

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