Игорь Олемской — практические заметки по системному администрированию Linux CentOS

My colleague koct9i, whose daily job is developing and fixing OpenVZ kernel, was feeling bored last weekend, and to entertain himself he wrote a small utility called ioping. The idea is simple and straightforward: to wrote a utility similar to ping, which will show I/O latency in the same way ping shows network latency. The idea is very simple but I haven't see something like this. Actually, the tool was written to help investigating OpenVZ bug #1880).

I liked ioping and worked on it a bit, too, just for run. Among some other minor stuff I have added a man page and spec file, so it is now available as an RPM package.

Official project site: http://code.google.com/p/ioping/

My RPM packages and stuff: http://kir.sacred.ru/ioping/

Today, on my 28th birthday, I'm finally delivering on a promise to my readers which I made about two months ago. I've written a guide on how to host a web application redundantly in a cloud environment. While it's still a bit of a rough draft, it should be a good starting point for those who haven't worked in virtualized environments before. Also, it may show some of the more experienced systems administrators a new way to do things.

The guide: Redundant Cloud Hosting Guide

As always, if you find anything in the guide that needs improvement, I'm all ears.

A simple guide to redundant cloud hosting is a post from: Major Hayden's Racker Hacker blog.

c0b6ad7e-f251-11df-b20b-4040336e00ef

The discussions about the paravirt_ops, or «pvops», support in upstream kernels at Xen Summit 2010 last month really piqued my interest.

Quite a few distribution maintainers have gone to great lengths to keep Xen domU support in their kernels and it's been an uphill battle. Some kernels, such as Ubuntu's linux-ec2 kernels, have patches from 2.6.18 dragged forward into 2.6.32 and even 2.6.33. It certainly can't be enjoyable to keep dragging those patches forward into new kernel trees.

The paravirt_ops support for Xen guests was added in 2.6.23 and continues to be included and improved in the latest kernel trees. However, there are two significant problems with these new kernels if you're trying to work with legacy environments:

• the console is on hvc0, not tty1
• block devices are now /dev/xvdX rather than /dev/sdX

If you only have a few guests, these changes are generally pretty easy. Switching the console just requires some changes to your inittab or upstart configurations. Changing the block device names requires changes to the guest's Xen configuration file and /etc/fstab within the guest itself.

Considering the amount of environments I work with daily at Rackspace, changing the guest configuration is definitely not an option. I needed a way to keep the console and block devices unchanged so that our customers could have a consistent experience on our infrastructure.

Luckily, Soren Hansen offered to pitch in and a solution became apparent. Through some relatively small patches, the legacy console and block device support was available in the latest 2.6.32 version (2.6.32.12 as of this post's writing).

So far, I've tested x86_64 and i386 versions of 2.6.32.12 with the console and block device patches. It's gone through its paces on Xen 3.0.3, 3.1.2, 3.3.0 and 3.4.2. All revisions of Fedora, CentOS, Ubuntu, Debian, Gentoo and Arch made within the last two years are working well with the new kernels.

Legacy tty1 and block device support for Xen guests with pvops kernels is a post from: Major Hayden's Racker Hacker blog.

c0b6ad7e-f251-11df-b20b-4040336e00ef

Эта задача может быть полезна разработчикам, к примеру, для тестирования программного обеспечения почтовых рассылок.

В качестве MTA используется Postfix.

Добавляем к стандартному конфигу main.cf

local_recipient_maps =
transport_maps = hash:/etc/postfix/transport
luser_relay = dev

dev — это локальный пользователь, которому будет пересылаться вся почта. Если пользователь не создан, его можно создать командой

useradd -g mail -m dev

Добавляем файл /etc/postfix/transport

domain.ru   smtp:
*           local:

domain.ru — домен или e-mail, почту для которого нужно доставлять (к примеру, адрес администратора, на который почту все же нужно доставлять).

После каждого изменения файла /etc/postfix/transport необходимо запустить

postmap /etc/postfix/transport
postfix reload

Готово! Теперь вся почта, кроме @domain.ru и локальных ящиков, будет складываться в почтовый ящик пользователя «dev», который можно показывать разработчикам используя, к примеру, peer-библиотеку Mail_Mbox или IMAP-сервером типа uw-imap, который легко устанавливается командой

yum install uw-imap

IMAP-сервер можно включить в автозагрузку, к примеру, используя xinetd, для чего в файле /etc/xinet.d/imap параметр disabled нужно изменить на «no».