VestaCP — vesta-nginx failed with «libc.so.6: version `GLIBC_2.14′ not found»

После очередного автоматического обновления, панель перестала отзываться.
Причиной тому были ошибки:

/usr/local/vesta/nginx/sbin/vesta-nginx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/vesta/nginx/sbin/vesta-nginx)

/usr/local/vesta/php/sbin/vesta-php: /usr/lib/x86_64-linux-gnu/libxml2.so.2: version `LIBXML2_2.9.0' not found (required by /usr/local/vesta/php/sbin/vesta-php)

/usr/local/vesta/php/sbin/vesta-php: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/vesta/php/sbin/vesta-php)

Фикс простой и написан на форуме Весты:

# apt-get update && apt-get --reinstall install vesta-nginx vesta-php

Debian 8 Viber проблемы с «xcb»

При попытке запустить Viber получаем ошибку.

$ /opt/viber/Viber
This application failed to start because it could not find or load the Qt platform plugin "xcb".

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, wayland-egl, wayland, xcb.

Решение. Доставить пакеты Читать дальше Debian 8 Viber проблемы с «xcb»

EnhanceIO + LVM on Debian Jessie

Пакет EnhanceIO в репе experimental
https://packages.debian.org/search?searchon=names&keywords=enhanceio

# cd /usr/local/src
# aptitude install python build-essential dkms
# wget http://ftp.de.debian.org/debian/pool/main/e/enhanceio/enhanceio-dkms_0+git20130620-5_all.deb
# wget http://ftp.de.debian.org/debian/pool/main/e/enhanceio/enhanceio_0+git20130620-5_all.deb
# dpkg -i enhanceio*

Create Cache
Читать дальше EnhanceIO + LVM on Debian Jessie

Опубликовано в рубрике linux

SW RAID + LVM + Flashcache on Debian Jessie

Итак, поднимаем производительность дисковой системы за счет кеширования на SSD

Имеется тазик с Debian Jessie 8 и тремя дисками:
2х SATA 2 TB - SW RAID 1-го уровня (/dev/sdb, /dev/sdc)
1x SSD 240 Gb - не размеченный диск (/dev/sda)

Поверх рейда используется LVM2 для логических разделов. Читать дальше SW RAID + LVM + Flashcache on Debian Jessie

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.

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

proxmox: qm list — нулевой размер диска

После обновления версии Proxmox до v2.2 (pve-manager/2.2/e94e95e9)
qm list стал показывать нулевой размер диска виртуальных машин:

~# qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       101 vm1.linevps.net      running    1024               0.00 162695
       102 vm2.linevps.net      stopped    512                0.00 19795
       103 vm3.linevps.net      running    2048               0.00 55934
       ....
       116 vm14.linevps.net     running    2048               0.00 63224

Фикс простой: Читать дальше proxmox: qm list — нулевой размер диска

Аппаратный рейд и Smart мониторинг дисков

Ставим пакет smartmontools и настраиваем мониторинг дисков.

При использовании аппаратного рейд контроллера Adaptec 2405.

Физические диски в системе видны как /dev/sgX. Но это в том случае, если загружен модуль sg.
Если устройст /dev/sgX нет, пробуем подгрузить модуль sg:

modprobe sg

Проверяем:

ls -la /dev/sg*
crw------- 1 root root 21, 0 Jul  5 14:41 /dev/sg0
crw------- 1 root root 21, 1 Jul  5 14:41 /dev/sg1
crw------- 1 root root 21, 2 Jul  5 14:41 /dev/sg2
crw------- 1 root root 21, 3 Jul  5 14:41 /dev/sg3
crw------- 1 root root 21, 4 Jul  5 14:41 /dev/sg4

Все нормально, диски видны.
/dev/sg0 - это непосредственно сам контроллер, sg1-sg4 - наши диски.

Теперь настраиваем smartmontools. Читать дальше Аппаратный рейд и Smart мониторинг дисков

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, установкой руками даты и т.д. не привели к успеху, к сожалению...
Пришлось ребутить клиенту виртуалку. После физического ребута нагрузка на процессор стала нормальной.