Предлагаю сделать простую проверку безопасности на ваших серверах.
Суть проверки очень проста. Мы переключаемся под пользователя, из-под которого запущены сервисы, такие как вебсервер или база данных, и смотрим в какие файлы в системе он может читать и писать. Запускать надо из-под всех пользователей, из-под которых работают смотрящие в мир сервисы. Если раньше никогда не делали, могут открыться бездны, но не паникуйте и быстренько все поправьте.
Замечу, что например апачевский юзер не должен иметь прав на изменение и удаление апачевских логов.
Несколько лет назад после прочтения матрицы компетентности программиста я поискал аналогичную матрицу для системных администраторов. Ближашее что я тогда нашел это 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ом из Питона.
Несколько лет назад я начал разбираться с вируализацией, и у меня получились своего рода путевые заметки, которые я сейчас оформил и выкладываю сюда. Никаких откровений тут не будет, статья адресована начинающим админам. Задача которую я здесь решаю состоит в том, чтобы виртуализовать уже имеющиеся не виртуальные сервера на Linux и FreeBSD.
