Page 1 of 1

Интересное поведение VestaCP после переустановки сервера и восстановления backup

Posted: Wed Oct 23, 2019 9:53 am
by 1RONMAN
Итак, предыстория под катом:
ПредысторияShow
Приветствую всех! Снова возникли траблы по причине вероятно моей собственной тупости, так что сильно не пинайте, я пока только учусь.)

Сразу извиняюсь за многобукв и мою вероятную тупизну, постараюсь описать максимально подробно насколько могу всю суть.

Итак, суть проблемы: переустановил сервер, использовал 18.04.3 LTS вместо 16.04 которая была ранее.

Создал дополнительного пользователя User_not_admin назовём его так. Дабы не сидеть под Рутом. У пользователя есть права использовать команду sudo.

Переключился на этого пользователя, далее всё делал под ним:

- Установил Sprutio (к нему, разумеется, Docker)
- Установил Vesta CP в конфигурации с PHP-FPM без Apache.

Единственное различие по сборке Vesta с предыдущей - в этот раз я добавил Softaculous (на посмотреть), впрочем не думаю что это критично.

Далее после установки панель запустилась, сервисы запустились, всё корректно.
В Vesta у меня всегда было 2 пользователя:
- admin (создающийся по умолчанию)
- vestauser (которому принадлежат все сайты работающие на сервере, это НЕ User_not_admin под которым работаю в терминале)
Вопрос 1 - корректно ли это?

Едем дальше. После установки развернул backup скачанный с предыдущей установки.
Сначала пользователя admin, затем пользователя vestauser.
При этом у меня почему-то НЕ добавились IP кроме "основного" IP сервера (в панели ранее было 3 IP), пришлось добавить вручную.

После восстановления backup'а для пользователя vestauser возникла первая проблема - nginx перестал запускаться.

Вывод nginx -t ругался на файлы типа doman.ru.nginx.conf по адресу /home/vestauser/conf/web
Также ругался на файлы *.key *.pem и *.crt из той же папки выдавая что nginx к ним access denied. Т.к. время близилось к 5 утра поставил на файлы 766 права из под SU (потому что обычный юзер не может их менять, sudo тоже не хотела работать).

После этого опять же из под SU всё-таки удалось запустить nginx и один из доменов domain0 (который соответствует хосту сервера и имеет его "основной" IP заработал).

На данный момент вывод nginx -t под обычным пользователем без sudo такой:

Code: Select all

nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [emerg] open() "/home/vestauser/conf/web/domain[b]1[/b].ru.nginx.conf" failed (13: Permission denied) in /etc/nginx/conf.d/vesta.conf:3
nginx: configuration file /etc/nginx/nginx.conf test failed
Под sudo/root такой:

Code: Select all

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
2 домена из трёх domain1 и domain2 не работают, файлы accesslog и errorlog для них пусты. Работает только domain0.

ls -l для папки /home/vestauser/conf/web выглядит так:

Code: Select all

-rwxrw-rw- 1 vestauser vestauser 1789 Oct 23 01:39 domain1.ru.nginx.conf
-rwxrw-rw- 1 vestauser vestauser 1932 Oct 23 01:39 domain1.ru.nginx.ssl.conf
-rwxrw-rw- 1 vestauser vestauser 1831 Oct 23 01:39 domain2.ru.nginx.conf
-rwxrw-rw- 1 vestauser vestauser 1982 Oct 23 01:39 domain2.ru.nginx.ssl.conf
-rwxrw-rw- 1 vestauser vestauser 1674 Oct 23 01:39 ssl.domain1.ru.ca
-rwxrw-rw- 1 vestauser vestauser 2269 Oct 23 01:39 ssl.domain1.ru.crt
-rwxrw-rw- 1 vestauser vestauser 3243 Oct 23 01:39 ssl.domain1.ru.key
-rwxrw-rw- 1 vestauser vestauser 3944 Oct 23 01:39 ssl.domain1.ru.pem
-rwxrw-rw- 1 vestauser vestauser 1674 Oct 23 01:39 ssl.domain2.ru.ca
-rwxrw-rw- 1 vestauser vestauser 2281 Oct 23 01:39 ssl.domain2.ru.crt
-rwxrw-rw- 1 vestauser vestauser 3243 Oct 23 01:39 ssl.domain2.ru.key
-rwxrw-rw- 1 vestauser vestauser 3956 Oct 23 01:39 ssl.domain2.ru.pem
-rwxrw-rw- 1 vestauser vestauser 1674 Oct 23 01:39 ssl.domain0.ru.ca
-rwxrw-rw- 1 vestauser vestauser 2273 Oct 23 01:39 ssl.domain0.ru.crt
-rwxrw-rw- 1 vestauser vestauser 3243 Oct 23 01:39 ssl.domain0.ru.key
-rwxrw-rw- 1 vestauser vestauser 3948 Oct 23 01:39 ssl.domain0.ru.pem
-rwxrw-rw- 1 vestauser vestauser 1810 Oct 23 01:39 domain0.ru.nginx.conf
-rwxrw-rw- 1 vestauser vestauser 1957 Oct 23 01:39 domain0.ru.nginx.ssl.conf
При попытке доступа к domain1 или domain2 никаких ошибок браузер не показывает просто "превышено время ожидания ответа".

Насколько я понимаю суть проблемы в том что для папок неправильно заданы права, как следствие nginx не может получить доступ и работает некорректно. Проблема в том что я не могу понять какие именно права/владельцы нужны этим файлам и папкам.

В /etc/nginx/nginx.conf:2 указан пользователь www-data, но судя по выводу nginx ведь всё равно игнорирует эту настройку?

Короче я в каком-то месте реально туплю а в каком понять не могу, просьба не кидать сразу тапками.

Проблема заключалась в том что я некорректно установил VestaCP, установка под root решила проблему. После этого backup удалось развернуть в пару щелчков мыши и всё работает. Единственное для 2 из 3 сайтов пришлось заново задать пароли баз MySQL, но это мелочи. ;)

До первой перезагрузки, после которой снова началась та-же канитель. Как разберусь выложу сюда апдейт.

Update: канитель связана с тем что я в файле /etc/ssh/sshd_config выставляю параметр PermitRootLogin no, что вроде как правильно с точки зрения безопасности, но при этом создаёт проблемы nginx который ???не может выполняться от имени root и => становится бесправным и не может нормально работать.???

Вопрос к разработчикам VestaCP: объясните, пожалуйста, моя ошибка в том что я устанавливаю Vesta под root а затем запрещаю логин root? Нужно создать пользователя с sudo и установить под ним? Что-то я уже вообще потерялся.

После ещё одной попытки переустановки уже под вновь созданным пользователем и ещё одной переустановки уже под root вернулся к тому что имел до этого - 2 домена НЕ работают, третий работает. :( Nginx при этом ругается нехорошими словами Starting nginx: [emerg]: bind() to IP failed (99: Cannot assign requested address), перестаёт ругаться только после установки директивы

Code: Select all

# allow processes to bind to the non-local address
net.ipv4.ip_nonlocal_bind = 1

в файл /etc/sysctl.conf

Update2:
Моя ошибка заключалась в том что прописал дополнительные IP ПЕРЕД тем как восстановить backup и при восстановлении они автоматически присвоились соответствующим доменам, но при этом НЕ работали. Сделал так: поставил всем доменам "основной" IP сервера, удалил их и добавил заново, после чего заново прописал сайтам. Обычные команды типа "пересоздать web" перед этим пробовал, но толку было 0.

Возможно по этой же причине предыдущая переустановка под вновь созданным пользователем не увенчалась успеха. Завтра попробую ещё раз и отпишусь надеюсь уже по финальному решению, которое возможно будет полезно тем кто попадёт в похожую ситуацию.
Вкратце:

1. Был сервер на Ubuntu 16.04, появилось желание обновиться на 18.04 LTS

2. Переустановил сервер с новым дистрибутивом

3. Накатил backup'ы

4. Начались безудержные танцы с бубном

В чём они заключались? Nginx никак не мог получить нужные ему права, после чего естественно падал, периодически ругался на то что не может добавить IP

Code: Select all

Starting nginx: [emerg]: bind() to IP failed (99: Cannot assign requested address)
итд.

Затем всё вроде бы заработало, НО...до первой перезагрузки. После которой работал только 1 домен из трёх. Вероятно я бы ещё долго мучался с правами, копался в настройках /etc/ssh/sshd_config, добавлял разное в /etc/sysctl.conf и так далее, если бы в какой-то момент не пошел и не сделал тупую на первый взгляд вещь:

1. Выставил всем доменам "основной" внешний IP сервера на котором работает один из доменов (который работает всегда)

2. Удалил IP

3. Добавил IP обратно

4. Заново указал для какого домена какой IP

При этом reread ip не работает, rebuild web аналогично, то есть это можно сделать только руками. После этого 2 домена которые ранее не работали заработали снова. До первой перезагрузки.
Что как и почему - понятия не имею, я не знаком с Linux до такой степени чтобы определить причину этого поведения. Вполне вероятно что это либо глюк хостера, либо глюк моих настроек (впрочем не знаю каких потому что я просто устанавливаю Vesta на совершенно чистую систему и восстанавливаю backup), либо глюк где-то в самой VestaCP.
Так или иначе домены работать я на данный момент заставил, перезагрузки сервера к счастью дело нечастое, так что по идее это не будет слишком беспокоить, посмотрим что будет дальше..
К сожалению с моим уровнем познаний на данный момент больше сказать не могу. Проблема можно считать "решена".

Если кому-то будет не лень это читать - комментарии и предположения почему оно так а не иначе приветствуются.