Сегодня я хочу рассказать о панели хостинга VestaCP. Это бесплатная легкая панель, которая несмотря на минимализм обладает почти всем необходимым для хостинга функционалом. Распространяется по лицензии GPLv3.
На текущий момент поддерживаются дистрибутивы: RHEL 5, RHEL 6, CentOS 5, CentOS 6, Debian 7, Ubuntu 12.04, Ubuntu 12.10, Ubuntu 13.04, Ubuntu 13.10, Ubuntu 14.04.
Начнем с установки, заходим на сервер по ssh и выполняем:

# curl -O http://vestacp.com/pub/vst-install.sh
# bash vst-install.sh

Установочный скрипт спросит хотим ли мы установить панель и все ПО к ней, попросит указать адрес электронной почты администратора и hostname сервера.

После всех вопросов система сообщит что установка займет около 15 минут. Об окончании установки мы можем узнать по сообщению в консоли, а также по письму на электронную почту указанную нами в установочном скрипте.

Открываем ссылку указанную в сообщении и логинимся.

Видим интерфейс панели, сменим язык интерфейса. Для этого кликнем по «admin» в правом верхнем углу. Откроется профиль пользователя, выбираем «Language» ru и жмем Save. И видим русский интерфейс панели.

После установки панели мы получаем готовое к работе и настроенное ПО: веб-сервер(nginx сразу устанавливается фронтэндом к апачу), почтовый сервер, сервер баз данных, ftp-сервер и сервер DNS. Т.е сразу после установки панели мы можем создавать пользователей, загружать на сервер свои сайты и разворачивать их. Интерфейс панели интуитивно понятен и не вызывает затруднений в работе.

Есть возможность добавлять дополнительные ip на сервер, редактировать cron и правила iptables. Также присутствуют шаблоны пользователей.

Панель ведет графики нагрузки всех сервисов, логи, а также делает бекапы пользователей.

На мой взгляд, vestacp идеальный вариант для веб-мастера за счет своей бесплатности, открытости и богатого функционала. Для полноценного хостинга не хватает только жесткого разграничения ресурсов сервера(процессорного времени, памяти и т. д.).

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

Самой удобной утилитой мониторинга нагрузки на сервере, на мой взгляд, является atop. Огромным плюсом данной утилиты является постоянное ведение логов нагрузки на сервер, это удобно т.к проблемы обычно происходят когда мы не следим за сервером прямо сейчас. А с atop можно отмотать «время назад» и посмотреть нагрузку на сервер в момент проблемы. Данная утилита есть во всех дистрибутивах линукс, также она присутствует во FreeBSD.
Рассмотрим установку утилиты для Ubuntu/Debian, Cenos и FreeBSD.

Ubuntu/Debian:

# apt-get install atop -y

Centos:

# yum install atop -y

FreeBSD:
Определяем местонахождение порта:

# whereis atop
atop: /usr/ports/sysutils/atop

Переходим в каталог

# cd  /usr/ports/sysutils/atop

И устанавливаем порт

# make install clean

После установки мы можем запустить утилиту:

# atop

После запуска мы увидим окно типа такого:

*** system and process activity since boot ***

теперь мы можем видеть нагрузку на сервер в реальном времени. Сверху мы видим нагрузку в процентах на основные узлы сервера: процессор, ядра процессора, память, своп, дисковые устройства и сетевые интерфейсы. Если на какой-либо узел будет повышенная нагрузка, то он будет подсвечен красным цветом.

Снизу мы видим процессы с PID’ами, пользователями которым они принадлежат и данными нагрузки которые они создают. Если на какую-либо подсистему сервера идет повышенная нагрузка и нам нужно узнать какой процесс её создает, то мы можем сортировать эти процессы по нагрузке на определенный узел нажатием определенных клавиш.

m - сортировать по занимаемой памяти
d - сортировать по создаваемой нагрузке на диск
u - покажет таблицу нагрузки по пользователям
v - покажет подробную информацию по процессам
g - вернет вывод по умолчанию
n - сортировать процессы по нагрузке на сеть(доступно только с установленным патчем ядра)

Теперь разберёмся как смотреть логи atop. Тут все достаточно просто. Для просмотра лога за текущий день достаточно выполнить

# atop -r

Мы увидим обычное окно atop, как и при просмотре в реальном времени, только по состоянию на 00 часов 00 минут текущего дня. Время можно увидеть в верхней строке. Переместится вперед по времени можно с помощью клавиши t. Назад с помощью shift+t.
Сразу перейти на нужное время можно нажав -b, и в появившемся диалоге ввести нужное время.
Также хранятся логи нагрузки за предыдущие дни. В Ubuntu 14.04 они лежат в каталоге /var/log/atop/. Открыть можно примерно так.

# atop -r /var/log/atop/atop_20140915

Цифры в названии файла обозначают дату в формате ГГГГММДД.

Оглавление:

I. Удаление диска из массива
II. Добавление диска в массив после замены
 1. Определение таблицы разделов(GPT или MBR) и перенос её на новый диск
 2. Добавление диска в массив
III. Установка загрузчика

У нас есть сервер в котором 2 диска: /dev/sda и /dev/sdb. Эти диски собраны у нас в софтверный RAID1 с помощью mdadm. Один из дисков вышел из строя, в нашем случае это /dev/sdb.

I. Удаление диска из массива

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

# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md2 : active raid1 sda4[0] sdb4[1]
      1456504640 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sda3[0] sdb3[1]
      7996352 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sda2[0] sdb2[1]
      499392 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

В данном случае массив собран так. Что md0 состоит из sda2 и sdb2, md1 из sda3 и sdb3, md2 из sda4 и sdb4. На этом сервере md0 это /boot, md1 — своп, md2 — корень. Убираем sdb из всех устройств.

# mdadm /dev/md0 --remove /dev/sdb2
# mdadm /dev/md1 --remove /dev/sdb3
# mdadm /dev/md2 --remove /dev/sdb4

Если разделы из массива не удаляются, это как в нашем случае. Mdadm не считает диск неисправным и использует его, и при удалении мы увидим ошибку, что устройство используется. В этом случае перед удалением помечаем диск как сбойный.

# mdadm /dev/md0 -f /dev/sdb2
# mdadm /dev/md1 -f /dev/sdb3
# mdadm /dev/md2 -f /dev/sdb4

А затем снова выполним команды по удалению разделов из массива. Все, мы удалили сбойный диск из массива. Теперь можем писать в датацентр запрос на замену диска.

II. Добавление диска в массив после замены

  1. Определение таблицы разделов(GPT или MBR) и перенос её на новый диск

После замены поврежденного диска нужно добавить новый диск в массив. Для этого надо определить какая у нас таблица разделов: GPT или MBR. Для этого будем использовать gdisk Установим gdisk:

# apt-get install gdisk -y

Выполняем:

# gdisk -l /dev/sda

Где /dev/sda — исправный диск находящийся в raid. В выводе будет примерно это для MBR:

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

И примерно это для GPT:

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Перед добавлением диска в массив нам нужно на нем создать разделы в точности такие же как и  на sda. В зависимости от разметки диска это делается по разному.

Копирование разметки для GPT:

# sgdisk -R /dev/sdb /dev/sda

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

# sgdisk -G /dev/sdb

Копирование разметки для MBR:

# sfdisk -d /dev/sda | sfdisk /dev/sdb

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

# sfdisk -R /dev/sdb

  2. Добавление диска в массив

Когда мы создали разделы на /dev/sdb, то можно добавлять диск в массив.

# mdadm /dev/md0 -a /dev/sdb2
# mdadm /dev/md1 -a /dev/sdb3
# mdadm /dev/md2 -a /dev/sdb4

III. Установка загрузчика

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

# grub-install /dev/sdb

Если сервер загружен в recovery или rescue, т.е с live cd, то установка загрузчика выглядит следующим образом.
Монтируем корневую файловую систему в  /mnt:

# mount /dev/md2 /mnt

Монтируем boot:

# mount /dev/md0 /mnt/boot

Монтируем /dev, /proc и /sys:

# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys  /mnt/sys

Затем делаем chroot в примонтированную систему:

# chroot /mnt

И устанавливаем grub на sdb:

# grub-install /dev/sdb

Теперь можно попробовать загрузится в нормальный режим.

P.S. Если при установке загрузчика возникнет ошибка Could not find device for /boot/boot: not found or not a block device то вам сюда.

Автор: Артем Авдонин

Что делать если панель перестала быть доступна после смены IP? Для начала нужно проверить лог-файл панели. Он находится по адресу:

/usr/local/ispmgr/var/ihttpd.log

Вероятнее всего Вы увидите там ошибку вроде:

INFO Adding binding. IP:'%%YOUR_IP_HERE%%', port: 1500, cert key: '', cert path: '' INFO Finished with error. bind

Эта ошибка значит, что встроенный web-сервер панели не может начать слушать с указанным в конфигурации IP. Нужно выполнить следующие команды:

# killall -9 ihttpd

Для ispmgr4 # /usr/local/ispmgr/sbin/ihttpd YOUR_IP 1500

Для ispmgr5 # /usr/local/mgr5/sbin/ihttpd YOUR_IP 1500

Первая команда "убьёт" работающий web-сервер, а вторая запустит его на IP, указанном вместо  YOUR_IP. После этого Вы сможете зайти в панель по адресу:

https://YOUR_IP:1500

После этого Вам нужно указать новый IP вместо старого в ISPManager, раздел "Настройки", пункт "Адрес панели".

Рассмотрим как включить модули iptables, ppp и tun/tap в openvz-контейнере.

Включение модулей iptables

Выполняем на ноде:

# modprobe iptable_nat

Подключаем модуль в контейнер id 001:

# vzctl set 001 --save --iptables "ip_conntrack iptable_filter iptable_mangle ipt_state iptable_nat ip_nat_ftp ip_conntrack_ftp"

UPD:

# vzctl set 001 --netfilter full --save --setmode restart

Включение модуля ppp

Стопаем контейнер, а затем выполняем на ноде(001-id контейнера на котором надо включить):

# modprobe ppp_async

# modprobe ppp_deflate

# modprobe ppp_mppe

# vzctl set 001 --features ppp:on --save

# vzctl set 001 --devices c:108:0:rw --save

Запускаем контейнер и внутри него выполняем:

# mknod /dev/ppp c 108 0

# chmod 600 /dev/ppp

Включение модуля tun

На ноде выполняем(001-id контейнера на котором надо включить):

# modprobe tun

# vzctl set 001 --devnodes net/tun:rw --save

# vzctl set 001 --devices c:10:200:rw --save

# vzctl set 001 --capability net_admin:on --save

# vzctl exec 001 mkdir -p /dev/net

# vzctl exec 001 chmod 600 /dev/net/tun

Автор: Артем Авдонин

Для чего может потребоваться загрузка вашего сервера под linux recovery system? Очевидный ответ - для проведения диагностики и процедур восстановления работоспособности ОС. Что же из себя представляет сервер, загруженный в recovery? Это загруженный на Вашем сервере, по сети, образ linux. В нём уже установлены все основные утилиты, которые могут быть использованы при диагностике и восстановлении работоспособности сервера. И так, у нас есть сервер в вышеупомянутом датацентре, загруженный в recovery mode. Оглавление (постоянно обновляется)

1. Запуск и монтирование корневой файловой системы
2. Ошибки файловой системы
3. Проблемы RAID
4. Проблемы HDD
5. Сброс правил firewall
6. Доступ к данным на сервере
7. Сброс root пароля

Подключаемся к серверу по ssh. В качестве имени пользователя указываем суперпользователя root, пароль указывается при отправке сервера в recovery mode.

1. Запуск и монтирование корневой файловой системы

В случае, если в системе используется RAID массив, начнём с его запуска:

~# mdadm --assemble --run /dev/md2

Эта команда запускает software RAID массив с меткой md2. На серверах s4y чаще всего md2 является rootfs (корневой файловой системой). Но не исключено, что искомым будем массив с меткой md1. Массив md0 - раздел /boot По выполнению команды вы должны увидеть:

mdadm: /dev/md2 has been started with 2 drives.

Это значит, что RAID успешно запущен. Проверим нормально ли собрался RAID:

~# cat /proc/mdstat

Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md2 : active raid1 sdb4[0] sda4[1]
      1456634744 blocks super 1.2 [2/2] [UU]                     

unused devices: <none>

2/2 дисков добавлено в массив. Всё в порядке. В случае 1/2 или ошибок после ввода команды сборки массива обращайтесь в раздел Проблемы RAID. Монтируем md2 в любую удобную вам точку. В данном случае я понтирую файловую систему в точку /mnt:

~# mount /dev/md2 /mnt

Удостоверимся, что то, что мы примонтировали является rootfs нашего сервера:

~# ls /mnt
aquota.user dev initrd.img lib64 mnt root srv usr
bin etc lib lost+found opt sbin sys var
boot home lib32 media proc selinux tmp vmlinuz

Видим вполне стандартное дерево каталогов корневой файловой системы linux дистрибутива. Значит md2 является rootfs Вашего сервера. Если у Вас установлен шаблон без использования RAID, то нужно просто смонтировать /dev/sdaX, где X номер раздела с ОС. После монтирования файловой системы можно начинать работу по диагностике проблем ОС или работать с вашими файлами.

2. Ошибки файловой системы

Часто ОС не может загрузиться из за ошибок файловой системы. Что бы исключить или подтвердить и исправить данную проблему необходимо выполнить проверку файловой системы с помощью fsck. fsck должен выполняться на отмонтированной файловой системе. Выполните раздел 1 этого руководства, исключая монтирование fs. Запустите таким образом md0 и md2 (/boot и корневую fs). После того как массивы для проверки собраны выполняется fsck для md0 и md2:

~# fsck -y /dev/md2
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
/dev/md2 has been mounted 22 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 68650/91045888 files (0.2% non-contiguous), 6396596/364158686 blocks

fsck, в данном случае, выполнился без ошибок.

3. Проблемы RAID

Не загружающийся сервер может быть вызван не собирающимся, повреждённым, "развалившимся" RAID. Как запустить RAID указано в первой главе этой статьи. Запустите все имеющиеся у вас массивы и проверьте статистику mdstat:

~# cat /proc/mdstat
~# cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md1 : active raid1 sdb3[0] sda3[1](F)
7999476 blocks super 1.2 [2/1] [U_]
md2 : active raid1 sdb4[0] sda4[1](F) 
1456634744 blocks super 1.2 [2/1] [U_]
md0 : active raid1 sdb2[0] sda2[1](F) 
499700 blocks super 1.2 [2/1] [U_]

unused devices: <none>

Если вывод выглядит примерно так (обратите внимание на (F) и [2/1]) - это значит, что массив не собран и не работает. (F) - обозначает пометка массива как fail. [2/1] обозначает, что только один диск массива работает. Нужно удалить из массива сбойные разделы и попробовать добавить их снова:

~# mdadm /dev/md1 -r /dev/sda3
mdadm: hot removed /dev/sda3 from /dev/md1
~# mdadm /dev/md0 -r /dev/sda2
mdadm: hot removed /dev/sda3 from /dev/md0
~# mdadm /dev/md2 -r /dev/sda4
mdadm: hot removed /dev/sda3 from /dev/md2

Добавляем:

~# mdadm /dev/md0 -a /dev/sda2

Мы можем увидеть несколько ошибок и среди них

mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sda2" first.

Выполняем mdadm --zero-superblock /dev/sda2 и повторяем mdadm /dev/md0 -a /dev/sda2 для каждого удаляемого выше раздела. Проверим добавились ли разделы в массив:

~# cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md1 : active raid1 sda3[2] sdb3[0]
 7999476 blocks super 1.2 [2/1] [U_]
 resync=DELAYED

md2 : active raid1 sda4[2] sdb4[0]
1456634744 blocks super 1.2 [2/1] [U_]
[>....................] recovery = 0.1% (2332928/1456634744) finish=365.5min speed=66306K/sec
md0 : active raid1 sda2[2] sdb2[0]

499700 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Значит RAID собирается нормально. Если на одном из этапов возникла ошибка, то стоит попробовать сначала пересоздать всю таблицу разделов, возможно её что-то покрошило. Если даже после этого RAID не собирается, то нужно проверить жёсткие диски.

4. Проблемы HDD

Не загружается сервер? Не собирается RAID? Проверим диски! Конкретная ситуация - RAID на сервере не собирается. Разделы диска sda помечены как сбойные. Нужно проверить состояние s.m.a.r.t.  этого диска.

smartctl -a /dev/sda

Из всего вывода нас интересует только серийный номер диска и таблица s.m.a.r.t :

Model Family: Seagate Barracuda LP
Device Model: ST31500541AS
Serial Number: 5XW2PTK4

Из таблицы интересуют только показатели, связанные с bad blocks:

5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       23
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       15

Если показатели в последнем столбце отличнны от 0, это признак нарушения поверхности диска и он подлежит замене. Если значения равны нулю, но диск в RAID добавить не удаётся (или не удаётся смонтировать, в случае с шаблоном без RAID), то нужно выполнить проверку диска на badblocks. Процедура потребует времени - от 3  до 6 часов.

~# badblocks -v /dev/sda
Checking blocks 0 to 1465138583
Checking for bad blocks (read-only test): 0.01% done, 0:02 elapsed. (0/0/0 errors)

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

5. Сброс правил firewall

Случайно сохранили некорректные правила iptables и установили на автозагрузку? Вам нужно примонтировать вашу файловую систему (раздел 1) и исправить/удалить правила из автозагрузки. Путь до файла будет другой: файл бывший /etc/rc.local будет /mnt/etc/rc.local

6. Доступ к данным

Нужно просто снять бекапы? Выполняйте все действия из раздела 1. После этого Вы можете подключиться к серверу по sftp любым клиентом, например WinSCP и забрать Ваши файлы. Они будут находиться в каталоге /mnt

7. Сброс пароля

Для того, что бы сбросить root пароль нужно выполнить все действия из раздела 1 и выполнить chroot на папке в которую примонтирована корневая файловая система, в данном случае это /mnt

root@servername:~# chroot /mnt
servername:/#

Теперь можно менять пароль root:

servername:/# passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully