mdraid + mdadm + GPT+clone partitions

Итак, уже давно используются диски большого обьема. И вместо обычного MBR сейчас уже в ходу GPT.

Как известно, sfdisk не умеет работать с GPT, и в случае замены диска скопировать разделы с помощью этой утилиты уже не получится:
# sfdisk -s /dev/sda
WARNING: GPT (GUID Partition Table) detected on ‘/dev/sda’! The util sfdisk doesn’t support GPT. Use GNU Parted.

Что же делать ? Read more mdraid + mdadm + GPT+clone partitions

CPU load 100%

Заметил, что с 1 июля 2012г на одной из виртуалок cpu стал загружен на все 100%.
strace на процесс, кушающий весь проц не дало результата особого

# strace -p 27653
Process 27653 attached - interrupt to quit
futex(0x7f022b74a9d0, FUTEX_WAIT, 27655, NULL

на этом все, но заставило погуглить подобное поведение у других. В процессе поиска выявилось, что виной всему баг в ядре linux [пруф], связанный с добавлением “60-й” секунды.
Шаманство в виде остановки/запуска демона NTP, установкой руками даты и т.д. не привели к успеху, к сожалению…
Пришлось ребутить клиенту виртуалку. После физического ребута нагрузка на процессор стала нормальной.

Couldn’t find PV pv1. Check your device.map

Виртуалка на базе KVM с lvm2 внутри.
В свое время для увеличения дискового пространства был добавлен второй диск.

И вот при очередном обновлении ядра вылезла ошибка:

Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
/usr/sbin/grub-probe: error: Couldn't find PV pv1. Check your device.map.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postinst line 799.
dpkg: error processing linux-image-2.6.32-5-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 linux-image-2.6.32-5-amd64

При просмотре файла /boot/grub/device.map увидел, что там указан только один диск:

# cat /boot/grub/device.map 
(hd0)   /dev/vda
#

После добавления второго диска в /boot/grub/device.map:

# cat /boot/grub/device.map 
(hd0)   /dev/vda
(hd1)   /dev/vdb

обновление завершилось без ошибок:

# aptitude safe-upgrade
The following partially installed packages will be configured:
  linux-image-2.6.32-5-amd64 
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up linux-image-2.6.32-5-amd64 (2.6.32-35) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
done

 

Что и требовалось.

vsftpd: No /usr/sbin/vsftpd found running; none killed.

Итак, сервер: Debian Squeeze + ISPmanager + vsftpd.
При попытке перезапуска фтп демона пишет:

# /etc/init.d/vsftpd restart
Stopping FTP server: No /usr/sbin/vsftpd found running; none killed.

При этом init-скрипт пишет номер процесса:

# cat /var/run/vsftpd/vsftpd.pid  
4634

Но пишет неправильный PID.
По всей видимости, при установке ftp из панели ISPmanager, в конфиг /etc/vsftpd.conf была добавлена строка:

background=YES

Соответственно, в pid файл записывался некорректный пид процесса. Это древний баг, оказывается
Собственно, про это же написано и в /usr/share/doc/vsftpd/README.Debian:

The included init script uses start-stop-daemon's --background option to run
vsftpd in the background.  If you have "background=yes" in your configuration,
the wrong PID will be recorded in /var/run/vsftpd/vsftpd.pid, and the init
script may fail to restart or stop vsftpd later.  Just remove "background=yes"
from vsftpd.conf.

Т.е. комментируем или убираем вообще строку “background=yes”, после чего init-скрипт начинает нормально запускать/останавливать vsftpd

PS. Как все таки, иногда, полезно почитывать документацию 🙂

/lib/libc.so.6: version ‘GLIBC_2.11’ not found

Попал в руки сервер Debian Lenny 5.0.7 со следующими симптомами:
не добавляются юзеры,  часть сервисов отвалилась (exim и dovecot, в частности, остальное не проверял), а при попытке что-ли установить получаем:

dpkg: /lib/libc.so.6: version `GLIBC_2.8' not found (required by dpkg)
dpkg: /lib/libc.so.6: version `GLIBC_2.11' not found (required by dpkg)
E: Sub-process /usr/bin/dpkg returned an error code (1)

Смотрим почему:

# ldd -v /usr/bin/dpkg
/usr/bin/dpkg: /lib/libc.so.6: version `GLIBC_2.8' not found (required by /usr/bin/dpkg)
/usr/bin/dpkg: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/bin/dpkg)
linux-vdso.so.1 => (0x00007fffeccfd000)
libc.so.6 => /lib/libc.so.6 (0x00007f4a09e8d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4a0a1e0000)

Version information:
/usr/bin/dpkg:
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.8) => not found
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.11) => not found
libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Примечательный факт: /lib/libc.so.6 был не симлинком на libc-2.7.so, а был самостоятельным файлом.
Мдааа.. ))
На всякий случай попросил клиента заказать ipkvm и liveCD, а также показать /etc/apt/source.list (Откуда в lenny libc-2.11 ??).
После увиденного я вообще удивился как оно еще жило. Были подключены репы stable и sid (жуть !), да в придачу еще и от убунты репа. Apt-Pinning , естественно не использовался.

Пришлось хаком приводить систему в чувства.
Убрал лишние репы, скачал нормальный штатный deb пакет dpkg.
Так как установить его все равно не получится, подменил файл /usr/bin/dpkg на тот который из deb-пакета.
dpkg заработал, уже лучше.

Ну а дальше пошли уже мытарства по вычистке системы от всего лишнего и чуждого для этой версии. Вот тут как раз и пригодился ipkvm.
Загрузился в rescue режиме, поднял сеть, потом chroot /dev/sda1 (диск был разбит на root и swap)
Перелинковал libc.so.6 на libc-2.7.so ну и на всякий случай переустановил libc6, а то мало ли откуда там файл вместо симлинка взялся.
После чего попытка взлететь с родного винта.

Скажу, что на этот раз повезло и система поднялась удачно.
Правда, после этого было потрачено пару часов на вычистку и переустановку пакетов.
Но в итоге, все заработало как и должно работать, клиент доволен.
Ну и я доволен, что смог помочь )

/dev/null: Permission denied

Попался тазик, где происходит сабж.
Клиент чудным образом выставил на /dev/null левые права:

# ls -la /dev/null
-rw-r--r-- 1 root munin 38 2010-12-23 21:01 /dev/null

Фикс простой – получаем root-овые права и чиним:

# rm /dev/null && mknod -m 0666 /dev/null c 1 3
# ls -la /dev/null
crw-rw-rw- 1 root root 1, 3 2010-12-24 01:53 /dev/null

Вот теперь правильно и все работает.

На всякий случай нужно убедиться, что udev при старте системы выставляет нужные права. В его правилах должна быть строка:

# grep null /etc/udev/rules.d/*permissions.rules 
KERNEL=="null",         MODE="0666"

Очередная лажа с ядром.

Итак, вот что я сегодня выкопал.
Локальная уязвимость в ядре позволяет устроить ДоС.

Проверил на ядрах центоса, дебиана. Результат везде один – отказ в обслуживани. Запущенный процесс не убивается, никак.
Помогает физический ребут 🙂

В оригинале:

Simple kernel attack using socketpair. easy, 100% reproductiblle, works under guest. no way to protect 🙁
Process become in state ‘Running’ but not killalble via kill -KILL.
eat 100% CPU, eat all available internal file descriptors in kernel

Вот так.
Найдено здесь.
фикс: использовать grsecurity или патчить ядро.

Debian Squeeze 6.0 frozen

Сегодня, 6 августа, разработка дистрибутива Debian 6.0 (“Squeeze”) перешла в завершающую фазу – Debian Squeeze заморожен.
Это означает, что в дистрибутив уже не будут добавляться новые пакеты, а все силы будут направлены на “вылизывание” существующих багов.

В новой версии будет:
– ядро 2.6.32
– KDE 4.4.5, Gnome 2.30.0, LXDE 0.5.0, XFCE 4.6.2
– X.org 7.5
– OpenOffice.org 3.2
А также множество других новых и полезных пакетов, так что ждем выхода релиза  😛

Подробнее на сайте Проекта: http://www.debian.org/

Свежие версии mysql/php для Lenny

На сервере вполне уютно живет Debian Lenny, однако хочется использовать более свежие версии софта, того же MySQL или PHP (речь идет о ветке 5.2). А учитывая, что в репозитарии ну очень уж древние версии, в бекпортах толком ничего нет, то возникает вопрос – как быть ?
Ставить из тестинга или собирать из сорцов как-то лениво, да 🙂
Однако есть люди, которым не лениво, за что им можно сказать “спасибо”.

Итак, подключаем репозитарий dotdeb.org и ставим свежие версии нужного нам софта.

deb http://packages.dotdeb.org  lenny all
deb-src http://packages.dotdeb.org lenny all

Импортируем ключики:

gpg --keyserver keys.gnupg.net --recv-key 89DF5277
gpg -a --export 89DF5277 | sudo apt-key add -

Обновляем списки пакетов

aptitude update

Теперь можно обновить устаревшие версии mysql и php на более свежие:

aptitude safe-upgrade

Если необходима версия php 5.3, тогда в source.list необходимо добавить:

deb http://php53.dotdeb.org lenny all
deb-src http://php53.dotdeb.org lenny all

В итоге получим мускуля версии 5.1.48-0.dotdeb.0-log
И php версии 5.2.13 или 5.3.2