Миграция виртуального сервера Linux: перемещение пользователей, групп, почты и других настроек

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

В любом случае при переходе с одной системы в другую нужно учесть множество различных нюансов. Полностью восстановить функции и конфигурации может быть трудно, если вы не используете средства для управления конфигурацией (Chef, Puppet или Ansible). Кроме того, нужно не только переместить данные, но и настроить сервисы для работы на новой машине.

В предыдущем руководстве вы узнали, как написать сценарий для перемещения данных с исходного сервера на целевой. Теперь данные находятся на целевой машине. Осталось только переместить пользователей, группы, почту,  crontab и другие настройки.

Перемещение пользователей и групп

Кроме программ и сервисов, переместить нужно также группы и пользователей.

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

Вся информация о пользователях хранится в нескольких файлах. Вот основные файлы:

  • /etc/passwd: этот файл определяет пользователей и базовые атрибуты. Несмотря на его название, этот файл не содержит никакой информации о паролях. Он сосредоточен на именах пользователей, членах групп, домашних каталогах и оболочках по умолчанию.
  • /etc/shadow: этот файл содержит фактическую информацию о паролях для каждого пользователя. Для каждого из пользователей, определенных в файле passwd, он содержит отдельную строку, а также хэшированные пароли и некоторую информацию о политике паролей.
  • /etc/group: этот файл содержит информацию о доступных группах системы: имя и номер связанной группы, а также имена пользователей, которые используют ту или иную группу как дополнительную.
  • /etc/gshadow: этот файл содержит список групп системы. В нем указаны группы, пароли, с помощью которых пользователи, не входящие в группу, могут получить к ней доступ, список администраторов и других пользователей.

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

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

Лучше оставить большинство этих файлов как есть и настроить только необходимые значения. Сделать это можно несколькими способами.

Создание файлов

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

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

Сначала выясните, какой лимит ID между обычными и системными пользователями установлен на вашем компьютере. Обычно он составляет 500 или 1000 в зависимости от системы. Если у вас есть обычный пользователь, вы можете просто проверить файл /etc/passwd:

less /etc/passwd

Затем можно использовать это число (первый стандартный ID пользователя в третьем столбце), чтобы установить ограничение. Пользователи и группы ниже этого предела не будут экспортированы. Также нужно исключить учетную запись nobod», которой будет присвоен ID пользователя 65534.

Файл для синхронизации с /etc/passwd можно создать так:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/passwd.sync

Примечание: Вместо limit# укажите самый низкий ID обычного пользователя, который вы обнаружили в файле /etc/passwd.

Аналогичным образом можно создать файл для синхронизации с файлом group:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/group.sync

Также можно использовать определенный диапазон имен пользователей из файла /etc/passwd, чтобы получить нужные значения из файла shadow:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > /root/shadow.sync

Чтобы создать такой файл для /etc/gshadow:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > /root/gshadow.sync

Теперь эти команды можно добавить в скрипт после обычной команды SSH и передать их на целевую машину:

ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/passwd.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/group.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > /root/shadow.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > /root/gshadow.sync"
rsync 111.222.333.444:/root/passwd.sync /root/
rsync 111.222.333.444:/root/group.sync /root/
rsync 111.222.333.444:/root/shadow.sync /root/
rsync 111.222.333.444:/root/gshadow.sync /root/

Добавление пользователей вручную

Если вы хотите просто добавить комментарий в скрипт и добавить пользователей вручную, используйте команды vipw vigr: они блокируют файл на время редактирования и защищают данные от повреждения. Чтобы отредактировать файл вручную, введите:

vipw

Флаг –s редактирует файл shadow, а флаг –g – файл group.

У вас может возникнуть идея просто добавить строки из файлов непосредственно в конец соответствующего файла в новой системе следующим образом:

cat /root/passwd.sync >> /etc/passwd

Если вы выбрали такой метод, помните: если один из скопированных ID уже принадлежит какому-то пользователю в новой системе, у вас возникнет конфликт ID.

Вы также можете добавить каждое имя пользователя с помощью системных инструментов. Команда useradd позволяет быстро создавать учетные записи пользователей в соответствии с данными исходного сервера:

useradd -s /path/to/shell -m -d /home/username -p password -G supplementary_groups

Вы можете сослаться на файлы *.sync и добавить их.

Автоматическое добавление пользователей

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

Команда newusers может добавлять пользователей из файла. Она идеально подходит, но сначала нужно удалить ID пользователей и групп из файлов. Затем команда будет генерировать доступных пользователей и групп для новой системы.

Чтобы удалить ID групп и пользователей из passwd, введите:

awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' /root/passwd.sync > /root/passwd.sync.mod

Затем введите:

newusers /root/passwd.sync.mod

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

Затем вы можете скопировать второй столбец из файла shadow.sync во второй столбец связанной учетной записи в новой системе. Это переместит пароли ваших учетных записей в новую систему.

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

Перемещение почты и задач в новую систему

Переместив пользователей, можно переместить в новую систему и их почту. Кроме того, нужно реплицировать cron job.

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

ls /var/spool
anacron   cron   mail   plymouth   rsyslog

Каталог mail нужно переместить на целевой сервер. Для этого добавьте в скрипт такую команду rsync:

rsync -avz --progress 111.222.333.444:/var/spool/mail/* /var/spool/mail/

Также в каталоге /var/spool следует обратить внимание на каталог cron, в котором хранится cron и все задачи этого демона. Каталог crontabs содержит индивидуальные crontab-ы каждого пользователя.

Чтобы сохранить автоматизированные задачи всех пользователей, добавьте команду rsync:

rsync -avz --progress 111.222.333.444:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*

Это переместит crontab каждого пользователя в новую систему. Но есть другие crontab, которые нужно переместить. В каталоге /etc есть crontab и ряд других каталогов, содержащих информацию cron.

ls /etc | grep cron
anacrontab
cron.d
cron.daily
cron.hourly
cron.monthly
crontab
cron.weekly

Файл crontab содержит общесистемные данные cron. Другие элементы – это каталоги, содержащие другую информацию cron. Просмотрите их и решите, содержат ли они какую-либо информацию для вас.

Чтобы переместить информацию cron в новую систему, используйте команду:

rsync -avz --progress 111.222.333.444:/etc/crontab /etc/crontab

Переместив информацию cron в новую систему, вы должны убедиться, что все работает. Это делается в конце вручную.

Единственный способ сделать это правильно – войти в систему как каждый отдельный пользователь системы и вручную запустить команды в crontab. Это устранит проблемы с правами и путями.

Запуск сервисов

В конце сценарий должен перезапустить все сервисы.

К примеру, чтобы перезапустить стек LAMP на Ubuntu, нужно ввести:

service mysql restart
service apache2 re
start
service php5-fpm restart

Добавьте команды для перезапуска необходимых сервисов в конец скрипта.

Тестирование сайтов и сервисов

Добавив в скрипт все необходимые команды, протестируйте работу новой системы.

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

Для начала нужно проверить размеры каталогов. К примеру, если вы синхронизировали раздел /data, откройте этот каталог на исходной и на целевой машине и запустите команду:

cd /data
du -hs
471M .

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

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

ps auxw
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  27024  2844 ?        Ss   Feb26   0:00 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Feb26   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Feb26   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    Feb26   0:00 [kworker/0:0]
root         5  0.0  0.0      0     0 ?        S<   Feb26   0:00 [kworker/0:0H]
. . .

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

netstat -nlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1564/dnsmasq


tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      2886/cupsd


tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      752/smbd


tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      752/


. . .

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

lsof -nPi
COMMAND     PID        USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
smbd        752        root   26u  IPv6    9705      0t0  TCP *:445 (LISTEN)
smbd        752        root   27u  IPv6    9706      0t0  TCP *:139 (LISTEN)
smbd        752        root   28u  IPv4    9707      0t0  TCP *:445 (LISTEN)
smbd        752        root   29u  IPv4    9708      0t0  TCP *:139 (LISTEN)
. . .

Вы должны проверить версии пакетов важных сервисов (как показано в первом руководстве серии). Способ сделать это зависит от системы.

Если вы переместили веб-сервер или стек LAMP, вам обязательно нужно проверить, работают ли сайты на новом сервере.

Для этого нужно просто откорректировать файл hosts (на локальном компьютере), указать в нем новый сервер. Затем вы можете проверить, правильно ли сервер принимает запросы и как работают все компоненты.

Метод работы с файлом hosts отличается в зависимости от используемой операционной системы. Если вы используете операционную систему на основе nix, например OS X или Linux, вы можете изменить файл hosts в своей локальной системе следующим образом:

sudo nano /etc/hosts

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

111.222.333.444     www.domain.com
111.222.333.444     domain.com

Добавьте все поддомены (images.domain.com, files.domain.com и т.п.). Затем сохраните и закройте файл.

В системе OS X нужно выполнить следующую команду, чтобы сервер увидел обновления файла hosts:

sudo lookupd -flushcache

В Linux это произойдет автоматически.

В Windows нужно откорректировать файл C:\Windows\Wystem32\Drivers\etc\hosts. Добавить строки нужно так, как показано выше.

Отредактировав файл hosts на локальной рабочей станции, вы должны иметь доступ к тестовому серверу по доменному имени. Откройте сайт в браузере и проверьте все его функции. Убедитесь, что все компоненты могут взаимодействовать друг с другом.

После тестирования нужно удалить из файла hosts все только что добавленные строки.

Перемещение правил брандмауэра

Чтобы переместить правила брандмауэра в новую систему, обратитесь к руководству Перенос правил iptables на новый сервер.

Прежде чем перемещать правила в новую систему, просмотрите их и обновите все необходимые данные (IP-адреса, диапазоны и т.п.).

Настройка DNS

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

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

После этого можно изменить DNS-серверы домена и указать новый сервер. Убедитесь, вместо ссылок на IP-адрес старого сервера вы указали информацию нового сервера.

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

Просмотрите команды MySQL и убедитесь, что вы не потеряете и не перепишете никаких данных.

Заключение

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

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

Tags: