201304Окт

Смена владельца www домена в ISPmanager

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

Два дня саппорт хостера молчал, игнорируя письмо на email и сообщение в Live-чат, которые по его заявлению работают 24/7. Только на третий день они поправили ситуацию, отписавшись на мое дико гневное сообщение в биллинговой системе простым «Сайт такой-то работает нормально». Негодованию моему не было предела…

Не будем тыкать пальцем в хостера…

Хотя нет, будем — steephost.com, DDOS им в жопу…

Обнаружение проблемы со сменой владельца www домена в ISPmanager

Я на второй же день определения проблемы взялся переносить свои сателлиты к себе на VDS. (Благо FTP и cPanel работали). В ISPmanager впопыхах создал домены, распаковал все сайты и настроил chmod. Немного успокоившись, я понял, что в итоге на моем рабочем сервере получается дико дохера сайтов: как нормальных рабочих, так и левых говенненьких.

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

Решение нашел методом тыка с помощью небольшой подсказки с форума своего VDS-провайдера. Итак, долго запрягав, едем…

Смена владельца www домена на ISPmanager

Небольшой дисклаймер:

1. Без временного дауна сайта сменить владельца скорее всего не удастся, потому что придется физически перемещать файлы, менять владельца баз данных, перезапускать Апач и т.п. Поэтому советую делать такие вещи ночью, когда посещаемость минимальная. (У меня сайты работали у старого хостера, поэтому на своем VDS я экспериментировал с ними как хотел без ущерба для работы).

2. Я делал все через SSH, по FTP такое не прокатит.

3. Все описанное актуально для FreeBSD на моем VDS от firstvds.ru. У вас конфигурация сервера может быть другая. То есть все описанные пути к файлам и папкам могут отличаться.

4. Ну, и главное: если что-то надумаете делать, в меня камни не кидать — вы все делаете на свой страх и риск. :)

Погнали.

1. В ISPmanager под root’ом создаем нового пользователя (пункт меню «Пользователи») с доступом по SSH («Доступ к shell»). Можно привязать к другому IP-адресу, если он имеется, а можно не привязывать.

2. Для баз данных создаем нового пользователя. Во вкладке «Базы данных» выбираем нужную базу и нажимаем кнопку «Пользователи». На новой странице жмем «Создать» и вводим нужные значения. После создания у базы данных будет два пользователя.

3. Под рутом заходим по SFTP в директорию, где хранятся папки с файлами сайтов. Выбираем папку с нужным сайтом и перемещаем ее в директорию «www» нашего нового пользователя. В WinSCP это делается простым нажатием сочетания клавиш Shift+F6 (или через контекстное меню) и небольшим изменением полного пути до нужной директории. Выглядит это примерно так:

меняем

/home/ТЕКУЩИЙ_ПОЛЬЗОВАТЕЛЬ/data/www/*.*

на

/home/НОВЫЙ_ПОЛЬЗОВАТЕЛЬ/data/www/*.*

Внимание! С этого момента сайт уже будет «сломан». Так что поспешите.

Скорее всего перенос файлов можно сделать и через файловый менеджер ISPmanager с помощью кнопок «Вырезать» и «Вставить», но я этим способом никогда не пользовался, поэтому сказать ничего не могу.

4. Теперь нужно сменить владельца и группу у файлов и папок. Сделать это можно и по SSH, но у меня через WinSCP это идет довольно долго, поэтому я делаю через сам ISPmanager. С помощью файлового менеджера под рутом заходим в папку с сайтами уже в директории нового пользователя. Выглядит путь примерно так: /home/ПОЛЬЗОВАТЕЛЬ/data/www

Выделяем нужную папку (называется именем домена) и нажимаем «Атрибуты». Здесь в качестве владельца и группы выбираем нашего нового пользователя, а в поле «Рекурсивно» выбираем «только сменить владельца». Так у нас сменится владелец и группа у папки и у всех вложенных папок и файлов, а все права доступа останутся неизменными.

5. Сейчас можно сменить IP-адрес домена, если с владельцем еще меняется и айпишник сайта. Делается это просто в самой панели ISPmanager: вкладка «WWW домены», выбираем нужный домен, «Изменить» и выбираем нужный IP-адрес в соответствующем поле.

6. Теперь вносим изменения в конфигурацию сервера Apache в соответствии с произведенными перемещениями. В соответствующий файл, который у меня расположен по адресу /usr/local/etc/apache22/httpd.conf прописываются новые пути и владелец сайта. Делается это в двух секциях: Directory и VirtualHost. И там, и там нужно поменять все вхождения

/home/ТЕКУЩИЙ_ПОЛЬЗОВАТЕЛЬ/

на новый

/home/НОВЫЙ_ПОЛЬЗОВАТЕЛЬ/

В секции VirtualHost также нужно заменить значения в директиве SuexecUserGroup на новые: первое значение — юзер, второе — группа.

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

Что примечательно, даже после перезагрузки Апача в ISPmanager владельцем доменного имени остается старый пользователь (вкладка «Доменные имена»). Но все равно все работает нормально. Однако если кому-то, как мне, сей факт не дает покоя, через выбор нужного домена в указанной вкладке и кнопку «Изменить» можно поправить ситуацию.

7. Теперь можно оставить одного владельца базой данных. Во вкладке «Базы данных» снова выбираем нужную базу и через кнопку «Пользователи» удаляем старый логин.

Внимание! Теперь обязательно нужно поменять данные доступа к базе данных в конфигах сайта!

8. Перекидываем log-файлы со старого на нового пользователя. То есть их папки:

/home/ТЕКУЩИЙ_ПОЛЬЗОВАТЕЛЬ/data/logs

в папку

/home/НОВЫЙ_ПОЛЬЗОВАТЕЛЬ/data/logs

Названия log-файлов, понятное дело, соответствуют доменному имени и имеют вид:

ДОМЕН.ru.access.log
ДОМЕН.ru.error.log

Что странно, после перезапуска Apache несмотря на то, что в конфигурации ротации логов, которая лежит по адресу /usr/local/ispmgr/etc/rotate.conf, стоят старые пути до файлов логов, они корректно крутятся и после переноса. Как бы ни было, все должно быть по делу, поэтому…

9. Идем в панель ISPmanager, во вкладке «WWW домены», выбираем нужный домен, жмем кнопку «Логи». В окошке я поставил значения по умолчанию (как при создании нового домена):

  • Лог запросов: Включено (с ротацией)
  • Лог ошибок: Включено (с ротацией)
  • Период ротации: Каждый день
  • Хранить архивов: 10
  • Анализировать с помощью: webalizer (Каждый день)

И так с каждым доменом, если переносится несколько сайтов. Или можно сделать глобальную настройку для всех доменов по кнопке «Все логи» и установке отметки «Применить для всех WWW доменов».

После этих действий в папке /home/ПОЛЬЗОВАТЕЛЬ/data/etc создадутся файлы вида ДОМЕН.ru.webalizer.conf. В этих файлах — конфигурация Webalizer, сервиса статистики, работающего на основе log-файлов событий веб-сервера. В одноименной папке у старого владельца эти файлы можно «убить».

Помимо конфиг-файлов в папке основного («старого») пользователя еще лежат файлы вида ДОМЕН.ru.stat.passwd. Это данные доступа (логин-пароль) к сервису статистики Webalizer. По умолчанию это должны быть данные вашего текущего пользователя, но их можно поменять, зашифровав соответствующим образом пароль.

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

Любым удобным способом переносим указанные файлы из папки

/home/СТАРЫЙ_ПОЛЬЗОВАТЕЛЬ/data/etc

в папку

/home/НОВЫЙ_ПОЛЬЗОВАТЕЛЬ/data/etc

Поправляем путь до них в файле, который запрашивает пароли: /home/ПОЛЬЗОВАТЕЛЬ/data/www/ДОМЕН.ru/webstat/.htaccess

У меня не один и не два сайта, к тому же этой статистикой я не пользуюсь, поэтому просто не стал геморроиться с кучей правок.

(10). Почта. Стоит заметить, что у меня не было почты на доменах, так что проблемы с этим не было. Если у вас есть рабочие постовые ящики, то придется и с этим разбираться.

11. Перезапускаем Apache. У меня это команда в терминале:

/usr/local/etc/rc.d/apache22 restart

Если все правки были внесены корректно, то теперь по идее сайты должны быть рабочими и открываться уже с нового пользователя. Если менялся IP-адрес сайта(ов) и NS доменов не менялись, то должно пройти время на обновление DNS. В любом случае все следует проверить и перепроверить, локально настроив открытие сайтов по новому IP-шнику.

PS: Дописав статью до конца и проделав все эти шаги, я стал сомневаться: а не проще ли было все-таки пересоздать домены и заново залить и настроить исходники? :)

Гуд лак!

UPDATE (10.10.2013): Хотел бы еще добавить замечания моего друга (который почему-то захотел остаться инкогнито) по этому вопросу. Комментарий не дословный, а с моей адаптацией.

(0). ISP записывает файлы конфигурации при создании/редактировании объекта (домена, пользователя и т.д.). Именно с этим связано то, что нужно менять настройки Apache задним числом: после создания домена он прописался в настройках и ISP ничего там не меняет. Решить эту проблему можно как описано в статье, но несколько по-другому.

(1). До создания нового пользователя и переноса файлов включительно все делается как описано выше.

2. Далее ищем в /usr/local/ispmgr и /etc все файлы, содержащие имя домена ДОМЕН.ru, и меняем в них путь к сайту и все другие аналогичные пути, а также ID пользователя.

3. После внесения изменений в настройки Apache перезапускаем Apache, после изменения настроек nginx – nginx, и т.д.

4. После всего понадобится изменить настройки ISP: в файле /usr/local/ispmgr/etc/ispmgr.conf меняем Domain <домен> <uid> (это то, что я делал через панельку, чтобы изменилось имя владельца домена). Для перезапуска тупо делаем killall ispmgr.

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

Программные вопросы