Сбой сервера: расследование

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

Сервер находится под управлением Proxmox VE 8.1 (и это тоже внесло свою лепту).

Хронология событий

В свой день рождения, 8 апреля рано утром я получил сообщение о сбое бекапа на сервере:

INFO: Starting Backup of VM 100 (lxc)
INFO: status = running
INFO: CT Name: home.j.pws
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating vzdump archive './vzdump-lxc-100-2024_04_08-08_01_04.tar.lzo'
INFO: tar: ./srv/zigbee2mqtt-data/log/2024-02-14.21-39-56/log2.txt: File shrank by 6563806 bytes; padding with zeros
INFO: Total bytes written: 9412812800 (8.8GiB, 125MiB/s)
INFO: cleanup temporary 'vzdump' snapshot
ERROR: Backup of VM 100 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=./vzdumptmp1839852_100/' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | lzop >./vzdump-lxc-100-2024_04_08-08_01_04.tar.dat' failed: exit code

Зашёл на сервер, посмотрел немного логи, в dmesg обнаружилась тревожная запись о сбое диска (M.2 nvme) на чтение:

EXT4-fs (dm-10): mounted filesystem 52843e56-bdaf-4d03-a303-d9c0f4996f4a ro without journal. Quota mode: none.
nvme0n1: I/O Cmd(0x2) @ LBA 435174656, 128 blocks, I/O Error (sct 0x2 / sc 0x81) MORE
critical medium error, dev nvme0n1, sector 435174656 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
nvme0n1: I/O Cmd(0x2) @ LBA 435174712, 8 blocks, I/O Error (sct 0x2 / sc 0x81) MORE
critical medium error, dev nvme0n1, sector 435174712 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2

Первым делом решил перезапустить кластер pve-cluster и он не запустился с невразумительнымии сообщениями в логе.

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

$ ssh root@pve-host.local
Permission denied (publickey).

Так же лежал REST API сервер и Веб-интерфейс Proxmox.

Возвращаем доступ

Что случилось с SSH было решительно непонятно, я попросил местных зайти в локальную консоль и глянуть лог sshd — там всё чисто. Решил сделать забрасываемый бекдор для запуска отдельного SSH сервера на другом порту, что бы зайти и самому разобраться.

Для этого модифицировал ssh-сервер Dropbear: убрал у него проверку прав и прочего, заменил путь до authorized_keys с $HOME/.ssh/authorized_keys на локальный, собрал архивчик с ключами хоста и своими ключами доступа, снабдил это простым скриптом:

cd /tmp
wget https://example.com/ssh-debug.tgz -O ssh-debug.tgz
tar -xf ssh-debug.tgz
chmod -R 777 debug-package
cd debug-package
iptables -I INPUT -p tcp --dport 12345 -j ACCEPT
./dropbear -F -E -r d-key -p 0.0.0.0:12345 -vvvv

И попросил местных ввести команду на открытие шелла:

wget -O - https://example.com/backdoor | bash

Всё получилось с первого раза, скрипт открыл мне новый SSH по новому порту 12345. Дальше уже спокойно зашёл и разобрался.

Что же случилось

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

У меня запрещён password-login через SSH и доступ только по ключам.
Оказалось, что /root/.ssh/authorized_keys в Proxmox — это ссылка на /etc/pve/priv/authorized_keys , которого нет, т.к. pve-cluster не запустился и файловая система /etc/pve не примонтирована!

По итогу получаем пустой файл с ключами и залогиниться невозможно.

Дальше смотрим логи, что случилось с pve-cluster. И диск тут снова не при делах! Оказалось что он не стартует из-за косяка в файле /etc/hosts:

Starting pve-cluster.service - The Proxmox VE cluster filesystem...
[main] crit: Unable to resolve node name 'pve' to a non-loopback IP address - missing entry in '/etc/hosts' or DNS?
[main] crit: Unable to resolve node name 'pve' to a non-loopback IP address - missing entry in '/etc/hosts' or DNS?
pve-cluster.service: Control process exited, code=exited, status=255/EXCEPTION

У меня файл /etc/hosts раскатывается через Saltstack централизованно, и имеет вид:

# Full FQDN should resolve to external IP
10.20.30.40     pve.zone.local
# This record is required to enforce proper FQDN of host
127.0.0.1       pve
# Default ones
127.0.0.1   localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
::1     localhost6.localdomain6 localhost6
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

А Proxmox, как оказалось, такое не может. Локальный домен pve должен резолвится на внешний адрес, иначе кластер просто не стартует (и отрубает авторизацию по ключам бонусом). В качестве фикса приводим файл к виду:

# Full FQDN should resolve to external IP
10.20.30.40     pve.zone.local pve
# Default ones
127.0.0.1   localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
::1     localhost6.localdomain6 localhost6
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

И теперь кластер старутет без проблем.

Проблемы с диском

У диска действительно есть проблемы, и бекап всё так же отваливается, вот аналогичная проблема на немецком форуме (там тоже проблема с диском).

Утилита smartctl показывает проблемы в логе устройства:

.................
 Entry[13]
.................
error_count     : 15
sqid            : 4
cmdid           : 0x334d
status_field    : 0x2281(Unrecovered Read Error: The read data could not be recovered from the media)
phase_tag       : 0x1
parm_err_loc    : 0xffff
lba             : 0x19f03d38
nsid            : 0x1
vs              : 0
trtype          : The transport type is not indicated or the error is not transport related.
cs              : 0
trtype_spec_info: 0

Диск Patriot m.2 P300 (512 Gb) совсем новый, ему от роду восемь месяцев и записано всего 4 Тб (при заявленном ресурсе в 960 Тб), то есть наработка порядка 0.3% от ресурса.

Виртуалку с проблемами я склонировал в новое место, что бы работало пока и бекап, старую деактивировал и отключил бекап, что бы собой «распирала» проблемное место.

Договорился о замене диска, старый мне привезут, который сдам по гарантии.

Выводы

Проверяйте конфиги, особенно для удалённых машин (мой домашний Proxmox точно так же не поднялся бы из ребута и я заметил бы проблему раньше).
Оставляйте резервных администраторов с sudo .
Смотрите логи внимательнее 🙂 и не перезагружайте в случае сомнений.

PETRO.WS