Highlighter

четверг, 31 мая 2012 г.

Пробуем на вкус systemd

Я тут немножко приболел и в свободное время захотелось пощупать systemd в gentoo, и потавил его на компьюетер, который используется у меня как мультимедиа-центр.
Особенностью этого компьюетера явялется то, что домашняя папка пользователя shtsh (из-под которого запущен xbmc) и /usr/portage монтируются по сети, используя nfs.

Пара слов о systemd. Этот проект разрабатывается как современная, гибкая и быстрая замена существующих систем инициализации и породила множество споров (бинарные логи! зачем нужен ещё один велосипед?!). Однако в него уже влился проект udev и к нему намертво привязали Gnome. Кроме того, systemd продвигается RedHat и уже входит в состав Fedora, что заставляет подозревать, что в RHEL 7 (в крайнем случае 8) и его форках (CentOS, Scientific Linux, Oracle Linux и проч.) systemd будет. А в Mageia, Mandriva, OpenSUSE уже есть. В debian, gentoo, archlinux доступен для отдельной установки.

Вот мануал, поэтому повторяться я не буду. Только расскажу, что пришлось сделать и впечатления.

Сначала, я чтобы не заморачиваться, прописал в USE-флаги systemd. Затем обновил систему при помощи emerge -avuDN @world. Потом приступил к настройкам по мануалу.
После настройки ядра, установки и прописывания в grub, мне понадобилось следующее.

Включить сеть, которая у меня настраивается при помощи DHCP.
systemctl enable dhcpcd.service
Включить ssh
systemctl enable sshd.service
После этого я посмотрел статус загрузки (вывод systemctl) и понял, что NFS шары не монтируются, так как на момент монтирования ещё недоступна сеть. Поэтому пришлось разбираться. Для этого я сделал следующее:

Создал в /etc/systemd/system файлы с настройками монтирования
mnt-disk.mount
[Unit]
Description=/mnt/disk NFS share
Wants=rpc-statd.service
After=network.target

[Mount]
What=server.home:/mnt/disk
Where=/mnt/disk
Type=nfs
usr-portage.mount
[Unit]
Description=/usr/portage NFS share
Wants=rpc-statd.service
After=network.target

[Mount]
What=server.home:/usr/portage
Where=/usr/portage
Type=nfs 

Затем заставил их подключаться при загрузке:
ln -s /etc/systemd/system/mnt-disk.mount /etc/systemd/system/multi-user.target.wants/mnt-disk.mount
ln -s /etc/systemd/system/usr-portage.mount /etc/systemd/system/multi-user.target.wants/usr-portage.mount

В отличии от мануала,  у меня не было xdm.service, поэтому пришлось думать, как сделать свой.
/etc/systemd/system/slim.service
[Unit]
Description=SLIM Display Manager
Wants=dbus.target
Before=bluetooth.target getty.target vixie-cron.service
After=network.target acpid.service mnt-disk.mount

[Service]
ExecStart=/usr/bin/slim -nodaemon
Restart=always

[Install]
Alias=display-manager.service
WantedBy=graphical.target

И включить его запуск
systemctl enable slim.service

В результате у меня запускался slim и xbmc только после того, как смонтируется домашняя папка, расположенная на сетевой шаре /mnt/disk.

Стоит отметить, что по своим настройкам systemd сильно отличается от остальных систем загрузки. В частности, эти самые service, target, mount. Однако всё это достаточно подробно (по крайней мере, лучше, чем я могу рассказать) расписано в манах. В частности в systemd.service, systemd.target, systemd.mount и прочие. Аналогично с пунктами настроек. Онлайн можно посмотреть по этой ссылке.

Также стоит обратить внимание, что системный лог ведётся в своём формате и его можно смотреть утилитой systemd-journalctl. Я так понял, что можно использовать /dev/kmesg, но пока не разобрался, как.

Выводы:
  • Диалог приветствия при использовании systemd появляется буквально через несколько секунд после загрузки (без использования SSD!), однако сеть и прочее подключаются после этого.
  • Как следствие из вышесказанного - есть смысл отказаться от хомяка через NFS, что сильно ускорит загрузку xbmc. Собственно, я так и сделал.
  • Systemd очень сильно отличается от других систем инициализации и с её настройкой действительно нужно отдельно разбираться. Хотя, может, когда она начнёт массово использоваться, появится много подробных howto.
  • Пока непонятно, зачем это нужно - 5-10 секунд выигрыша при загрузке, когда сейчас основной тормоз- скорость инициализации оборудования до загрузки ОС, особенно на серверах. Но серверы и загружаются крайне редко.
  • Пока что единственную пользу вижу в одном - возможность рестарта демона при падении. Но это не так и часто нужно.

вторник, 15 мая 2012 г.

Дамб БД mysql по ssh

Проблема: есть сервер БД, где мало свободного места (на дамп не хватит). Нужно сделать дамп БД.

Решение:
ssh -T <user>@<host> “mysqldump -u <db_user> -p <other switches> database | bzip2 -9” | bzip2 -dc > database.dump

Стоит обратить внимание на опцию -T, с которой не будет создаваться псевдотерминал и не испортится бинарный поток.

вторник, 1 мая 2012 г.

Делаем из AMI vmdk

Есть амазоновский образ диска ami, нужно запустить его в виртуалке. Используется virtualbox. Попутно создадим образ диска другого формата (любой, поддерживаемый VB)

Это делается, в принципе, несложно.
Сначала нужно скачать Amazon EC2 AMI Tools.
Дальше поставить ruby и расшифровать образ.
Утилиты от амазона лежат в /media/sf_Common/ec2-ami-tools, образ лежит в папке /media/sf_Common/jira.

Для того, чтобы утилиты работали, нужно указать папку, где они находятся.
 export EC2_HOME=/media/sf_Common/ec2-ami-tools
Дальше распаковываем
/media/sf_Common/ec2-ami-tools/bin/ec2-unbundle -k our_private_key.pem -d /media/sf_Common -s /media/sf_Common/jira -m /media/sf_Common/jira/image.manifest.xml

После этого у нас появился файл image в папке /media/sf_Common/, это образ раздела.
Теперь у нас есть два варианта: создать виртуальный диск, с такими же характеристиками, как и у образа, либо просто примонтировать и скопировать всё с сохранением прав. Я выбрал второй вариант.

Создаём раздел на sdb и на sdb1 создаём файловую систему ext3.
Затем монтируем образ в /tmp/a, а наш диск в /tmp/b
mount -o loop /media/sf_Common/image /tmp/a
mount /dev/sdb1 /tmp/b

Копируем всё с сохранением прав
cp -ra /tmp/a/* /tmp/b

После этого чрутимся в новую систему
mount -t proc proc /tmp/b/proc
mount -o rbind /dev /tmp/b/dev
chroot /tmp/b/

ставим grub
grub
root (hd1,0)
setup (hd1)
quit

Проверяем, что у нас прописан правильный раздел в /boot/grub/menu.lst, выключаемся, удаляем все диски, которые не нужны и пробуем загрузиться. Мне пришлось дополнительно отредактировать /etc/inittab и раскомментировать строчку
1:2345:respawn:/sbin/mingetty tty1

В результате система стала предлагать залогиниться локально.
Ещё проблема может быть с тем, что в virtualbox нереально загрузиться с xen, но тут было обычное ядро.