如何迁移Linux服务器第3部分-最后步骤

介绍

在许多情况下，您可能必须将数据和操作要求从一台服务器移动到另一台服务器。您可能需要在新的数据中心实施您的解决方案，升级到更大的机器，或者过渡到新硬件或新的 VPS 提供商。

无论您出于何种原因，在从一个系统迁移到另一个系统时都应该考虑许多不同的因素。如果您不使用 Chef、Puppet 或 Ansible 等配置管理解决方案，则可能很难获得功能等效的配置。您不仅需要传输数据，还需要配置您的服务以在新机器上以相同的方式运行。

在上一篇文章中，我们介绍了如何使用 rsync 传输数据和迁移您的数据库。在本文中，我们将通过迁移用户、组、邮件、crontab 和其他设置来继续我们的迁移。

迁移用户和组

尽管您的主要关注点可能是您的服务和程序，但我们也需要关注用户和组。

大多数需要特定用户操作的服务将在安装时创建这些用户和组。但是，这仍然会留下手动或通过其他方法创建的用户和组。

幸运的是，用户和组的所有信息都包含在几个文件中。我们需要查看的主要文件是：

/etc/passwd：这个文件定义了我们的用户和基本属性。尽管它的名字，这个文件不再包含任何密码信息。相反，它侧重于用户名、用户和主要组号、主目录和默认 shell。
/etc/shadow：此文件包含有关每个用户的密码的实际信息。它应该包含在 passwd 文件中定义的每个用户的一行，以及他们密码的哈希值和一些关于密码策略的信息。
/etc/group：此文件定义系统上可用的每个组。基本上，它只包含组名和相关的组号，以及使用它作为补充组的任何用户名。
/etc/gshadow：此文件包含系统上每个组的一行。它基本上列出了组，非组成员可以用来访问组的密码，管理员和非管理员的列表。

虽然将这些文件直接从源系统复制到新系统似乎是个好主意，但这可能会导致复杂性，因此不建议这样做。

可能出现的主要问题之一是组和用户 ID 号冲突。如果创建自己的用户和组的软件在系统之间以不同的顺序安装，则用户和组号可能不同，从而导致冲突。

相反，最好不要管这些文件中的大部分，只调整我们需要的值。我们可以通过多种方式做到这一点。

创建迁移文件

无论我们想使用哪种方法将用户添加到我们的新系统，我们都应该生成用户、组等的列表。应该转移和添加。

一个在网上流传了一段时间的方法如下：

我们将创建一个与上述每个需要修改的文件相关联的文件。它们将包含所有适当的转移信息。

首先，弄清楚你的机器上普通用户和系统用户之间的 ID 限制是多少。这通常是 500 或 1000，具体取决于您的系统。如果您有普通用户，一个简单的查找方法是检查 /etc/passwd 文件并查看普通用户帐户的起始位置：

less /etc/passwd

之后，我们可以使用这个数字（第一个常规用户 ID 号，在第 3 列中）来设置命令的限制。我们不会导出低于此限制的用户或组。我们还将排除用户 ID 为“65534”的“nobody”帐户。

我们可以通过输入这个来为我们的 /etc/passwd 文件创建一个同步文件。用您在 /etc/passwd 文件中发现的最低常规用户号替换 limit#：

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

之后，我们可以做类似的事情来制作组同步文件：

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

我们可以使用 /etc/passwd 文件中我们感兴趣的范围内的用户名从影子文件中获取我们想要的值：

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 命令之后将它们添加到我们的脚本中，然后 rsync 关闭它们，如下所示：

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 标志编辑关联的影子文件，传递 -g 标志编辑组文件。

您可能很想将文件中的行直接添加到新系统上相关文件的末尾，如下所示：

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。该命令将为新系统生成下一个可用的用户和组。

我们可以像这样从 passwd 文件中删除组和用户 ID：

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

我们可以像这样应用这个新修改的文件：

newusers /root/passwd.sync.mod

这会将文件中的所有用户添加到本地 /etc/passwd 文件中。它还将自动创建关联的用户组。您必须手动将不与用户关联的其他组添加到 /etc/group 文件中。使用您的迁移文件来编辑相应的文件。

对于 /etc/shadow 文件，您可以将 shadow.sync 文件中的第二列复制到新系统中关联帐户的第二列中。这会将您帐户的密码转移到新系统。

您可以尝试编写这些更改的脚本，但这可能是一种更容易手动执行的情况。请记住在配置用户和组后注释掉任何用户或组行。

将邮件和作业转移到新系统

现在您的用户已从旧系统转移，并且您的用户的主目录已由已运行的 rsync 命令填充，您也可以迁移每个用户的邮件。我们也想复制 cron 作业。

我们可以从对 spool 目录执行另一个 rsync 命令开始。在我们源系统的 spool 目录中，我们通常可以看到一些重要的文件：

ls /var/spool

anacron   cron   mail   plymouth   rsyslog

我们想将邮件目录传输到我们的目标服务器，因此我们可以在迁移脚本中添加一个如下所示的 rsync 行：

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

/var/spool目录中另一个我们要注意的目录是cron目录。该目录保存用于调度的 cron 和 at 作业。其中的 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 信息的目录。查看它们并确定它们是否包含您需要的任何信息。

再次使用 rsync 将相关的 cron 信息传输到新系统。

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

在新系统上获得 cron 信息后，您应该验证它是否有效。这是一个手动步骤，因此您必须在最后执行此操作。

正确执行此操作的唯一方法是作为每个单独的用户登录并手动运行每个用户的 crontab 中的命令。这将确保没有权限问题或丢失的文件路径会阻止这些命令在自动运行时静默失败。

重启服务

在迁移脚本结束时，您应该确保所有适当的服务都已重新启动、重新加载、刷新等。您需要使用适合您正在使用的操作系统的任何机制来执行此操作。

例如，如果我们在 Ubuntu 上迁移 LAMP 堆栈，我们可以通过键入以下内容重新启动重要进程：

service mysql restart
service apache2 restart
service php5-fpm restart

您可以按原样将这些添加到迁移脚本的末尾，它们应该按预期运行。

测试站点和服务

在您完成迁移脚本并运行所有同步和修改后，以及执行所有必要的手动步骤后，您应该测试您的新系统。

您需要检查很多区域。在测试时注意任何相关的日志文件，看看是否出现任何问题。

首先，您需要在传输后测试目录大小。例如，如果您有一个已重新同步的 /data 分区，您将需要在源计算机和目标计算机上都转到该目录并运行 du 命令：

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)
. . .

您应该像我们在第一篇文章中所做的那样检查您的重要服务的包版本，以验证您是否匹配重要包的版本。执行此操作的方法将取决于系统。

如果您转移了 Web 服务器或 LAMP 堆栈，则绝对应该在新服务器上测试您的网站。

您可以通过修改主机文件（在本地计算机上）以指向新服务器而不是旧服务器来轻松完成此操作。然后，您可以测试您的服务器是否正确接受请求以及所有组件是否以正确的方式一起运行。

您修改本地主机文件的方式因您使用的操作系统而异。如果您使用的是基于 *nix 设计的操作系统，例如 OS X 或 Linux，您可以像这样修改本地系统上的 hosts 文件：

sudo nano /etc/hosts

在里面，您需要添加一个条目，将您的域名指向您的新服务器的 IP 地址，以便您的计算机拦截请求并将其路由到新位置进行测试。

您可以添加的行可能如下所示：

111.222.333.444     www.domain.com
111.222.333.444     domain.com

添加在整个站点配置中使用的任何子域（images.domain.com、files.domain.com 等）。添加主机行后，保存并关闭文件。

如果您使用的是 OS X，则需要刷新主机文件以供您的计算机查看新内容：

sudo lookupd -flushcache

在 Linux 上，这应该会自动运行。

在 Windows 上，您必须以管理员身份编辑 C:\Windows\Wystem32\Drivers\etc\hosts 文件。以我们上面为 *nix 版本所做的相同方式添加行。

在本地工作站上编辑主机文件后，您应该能够通过转到您的域名来访问测试服务器。尽可能测试一切，并确保所有组件都可以相互通信并以正确的方式响应。

完成测试后，请记住再次打开 hosts 文件并删除您添加的行。

迁移防火墙规则

请记住，您需要将防火墙规则迁移到新服务器。要了解如何执行此操作，请遵循本教程：如何将 iptables 防火墙规则迁移到新服务器。

请记住，在将规则加载到新服务器之前，您需要检查它们是否有任何需要更新的内容，例如更改的 IP 地址或范围。

更改 DNS 设置

当您彻底测试了您的新服务器后，请查看您的迁移脚本并确保其中没有任何部分会逆转您所做的修改。

之后，再次运行该脚本以从源服务器中获取最新数据。

在目标服务器上拥有所有最新数据后，您可以修改域的 DNS 服务器以指向新服务器。确保每个对旧服务器 IP 的引用都替换为新服务器的信息。

如果您使用 DigitalOcean 的 DNS 服务器，您可以在此处阅读如何配置您的域名。

DNS 服务器需要一些时间来更新。在所有 DNS 服务器都进行了新更改之后，您可能必须最后一次运行迁移脚本，以确保任何仍然发送到原始服务器的杂散请求都被传输。

仔细查看您的 MySQL 命令，以确保您不会丢弃或覆盖已写入旧服务器或新服务器的数据。

结论

如果一切顺利，您的新服务器现在应该启动并运行，接受请求并处理您之前服务器上的所有数据。您应该继续密切监视情况并留意可能出现的任何异常情况。

正确完成迁移并非易事，并且可能会出现许多问题。成功迁移实时服务器的最佳机会是在开始之前尽可能地了解您的系统。每个系统都是不同的，每次，您都必须解决新问题。如果您没有时间解决可能出现的问题，请不要尝试迁移。