Linuxサーバーを移行する方法パート3-最終ステップ

序章

データと運用要件をあるサーバーから別のサーバーに移動しなければならないシナリオはたくさんあります。ソリューションを新しいデータセンターに実装するか、より大きなマシンにアップグレードするか、新しいハードウェアまたは新しいVPSプロバイダーに移行する必要がある場合があります。

理由が何であれ、あるシステムから別のシステムに移行する際には、さまざまな考慮事項を考慮する必要があります。 Chef、Puppet、Ansibleなどの構成管理ソリューションを使用していない場合、機能的に同等の構成を取得するのは難しい場合があります。データを転送するだけでなく、新しいマシンでも同じように動作するようにサービスを構成する必要があります。

前回の記事では、 rsyncを使用してデータを転送し、データベースを移行する方法について説明しました。この記事では、ユーザー、グループ、メール、crontab、およびその他の設定を移行することにより、移行を継続します。

ユーザーとグループの移行

あなたの主な関心事はあなたのサービスとプログラムかもしれませんが、私たちはユーザーとグループにも注意を払う必要があります。

動作するために特定のユーザーを必要とするほとんどのサービスは、インストール時にこれらのユーザーとグループを作成します。ただし、これにより、手動または他の方法で作成されたユーザーとグループが残ります。

幸いなことに、ユーザーとグループのすべての情報は、いくつかのファイルに含まれています。確認する必要のある主なファイルは次のとおりです。

/ etc / passwd ：このファイルは、ユーザーと基本属性を定義します。その名前にもかかわらず、このファイルにはパスワード情報が含まれていません。代わりに、ユーザー名、ユーザーとプライマリグループ番号、ホームディレクトリ、およびデフォルトのシェルに焦点を当てています。
/ etc / shadow ：このファイルには、各ユーザーのパスワードに関する実際の情報が含まれています。 passwdファイルで定義されている各ユーザーの行と、パスワードのハッシュおよびパスワードポリシーに関する情報が含まれている必要があります。
/ etc / group ：このファイルは、システムで使用可能な各グループを定義します。基本的に、これには、グループ名と関連するグループ番号、およびこれを補足グループとして使用するユーザー名が含まれます。
/ etc / gshadow ：このファイルには、システム上の各グループの行が含まれています。基本的に、グループ、グループ以外のメンバーがグループにアクセスするために使用できるパスワード、管理者と非管理者のリストが一覧表示されます。

これらのファイルをソースシステムから新しいシステムに直接コピーすることは良い考えのように思えるかもしれませんが、これは複雑さを引き起こす可能性があるため、お勧めしません。

発生する可能性のある主な問題の1つは、グループID番号とユーザーID番号の競合です。独自のユーザーとグループを作成するソフトウェアがシステム間で異なる順序でインストールされている場合、ユーザー番号とグループ番号が異なる可能性があり、競合が発生する可能性があります。

代わりに、これらのファイルの大部分をそのままにして、必要な値のみを調整することをお勧めします。これはさまざまな方法で実行できます。

移行ファイルの作成

新しいシステムにユーザーを追加するために使用する方法に関係なく、ユーザー、グループなどのリストを生成する必要があります。転送して追加する必要があります。

しばらくの間インターネット上を漂っていた方法を以下に示します。

変更が必要な上記の各ファイルに関連付けられたファイルを作成します。それらには、適切な転送情報がすべて含まれます。

まず、通常のユーザーとシステムユーザーの間のID制限がマシン上にあるかどうかを把握します。これは通常、システムに応じて500または1000のいずれかになります。通常のユーザーがいる場合、簡単に見つける方法は、/etc/passwdファイルを調べて、通常のユーザーアカウントがどこから始まるかを確認することです。

less /etc/passwd

その後、この番号（3列目の最初の通常のユーザーID番号）を使用して、コマンドの制限を設定できます。この制限を下回るユーザーまたはグループはエクスポートされません。また、ユーザー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とグループIDを削除したいと思います。このコマンドは、新しいシステムで次に使用可能なユーザーとグループを生成します。

次のように、passwdファイルからグループIDとユーザー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ファイルの2番目の列を、新しいシステムの関連するアカウントの2番目の列にコピーできます。これにより、アカウントのパスワードが新しいシステムに転送されます。

これらの変更のスクリプトを作成することもできますが、これは手動で行う方が簡単な場合の1つです。ユーザーとグループを構成した後は、ユーザーまたはグループの行をコメントアウトすることを忘れないでください。

メールとジョブを新しいシステムに転送する

ユーザーが古いシステムから転送され、実行中のrsyncコマンドによってユーザーのホームディレクトリにデータが入力されるようになったので、各ユーザーのメールも移行できます。 cronジョブも複製したいと思います。

スプールディレクトリに対して別のrsyncコマンドを実行することから始めることができます。ソースシステムのスプールディレクトリ内には、通常、いくつかの重要なファイルが表示されます。

ls /var/spool

anacron   cron   mail   plymouth   rsyslog

メールディレクトリをターゲットサーバーに転送したいので、移行スクリプトに次のようなrsync行を追加できます。

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

/var/spoolディレクトリ内で注目したいもう1つのディレクトリは、cronディレクトリです。このディレクトリは、スケジューリングに使用されるcronとatジョブを保持します。内のcrontabsディレクトリには、個々のユーザーのcrontabが含まれており、ジョブのスケジュールに使用されます。

ユーザーが割り当てた自動化されたタスクを保持したいと考えています。これは、さらに別のrsyncコマンドで実行できます。

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

これにより、個々のユーザーのcronタブが新しいシステムに追加されます。ただし、移動する必要のある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スタックを転送した場合は、新しいサーバーでサイトを確実にテストする必要があります。

古いサーバーではなく新しいサーバーを指すようにhostsファイル（ローカルコンピューター上）を変更することで、これを簡単に行うことができます。次に、サーバーが要求を正しく受け入れ、すべてのコンポーネントが正しい方法で一緒に動作しているかどうかをテストできます。

ローカルhostsファイルを変更する方法は、使用しているオペレーティングシステムによって異なります。 OS XやLinuxなどの*nixベースのデザインのオペレーティングシステムを使用している場合は、次のようにローカルシステムの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を使用している場合、新しいコンテンツを表示するには、コンピューターのhostsファイルをフラッシュする必要があります。

sudo lookupd -flushcache

Linuxでは、これは自動的に機能するはずです。

Windowsでは、管理者としてC:\Windows\Wystem32\Drivers\etc\hostsファイルを編集する必要があります。上記の*nixバージョンで行ったのと同じ方法で行を追加します。

ローカルワークステーションでhostsファイルを編集した後、ドメイン名に移動してテストサーバーにアクセスできるようになります。可能な限りすべてをテストし、すべてのコンポーネントが相互に通信し、正しい方法で応答できることを確認します。

テストが完了したら、hostsファイルを再度開いて、追加した行を削除することを忘れないでください。

ファイアウォールルールの移行

ファイアウォールルールを新しいサーバーに移行する必要があることに注意してください。これを行う方法については、次のチュートリアルに従ってください：Iptablesファイアウォールルールを新しいサーバーに移行する方法。

ルールを新しいサーバーにロードする前に、IPアドレスや範囲の変更など、更新が必要なものがないかどうかを確認する必要があることに注意してください。

DNS設定を変更する

新しいサーバーを徹底的にテストしたら、移行スクリプトを調べて、サーバーの一部が行った変更を元に戻さないことを確認します。

その後、スクリプトをもう一度実行して、ソースサーバーから最新のデータを取得します。

ターゲットサーバーに最新のデータがすべて揃ったら、ドメインのDNSサーバーを変更して、新しいサーバーを指すようにすることができます。古いサーバーのIPへのすべての参照が、新しいサーバーの情報に置き換えられていることを確認してください。

DigitalOceanのDNSサーバーを使用している場合は、ドメイン名の構成方法についてここで読むことができます。

DNSサーバーの更新には時間がかかります。すべてのDNSサーバーが新しい変更を取得した後、移行スクリプトを最後に実行して、元のサーバーにまだ送信されていた漂遊要求が転送されることを確認する必要がある場合があります。

MySQLコマンドを注意深く調べて、古いサーバーまたは新しいサーバーに書き込まれたデータを破棄したり上書きしたりしていないことを確認します。

結論

すべてがうまくいけば、新しいサーバーが稼働し、リクエストを受け入れ、以前のサーバーにあったすべてのデータを処理するはずです。引き続き状況を注意深く監視し、発生する可能性のある異常に注意する必要があります。

適切に実行された場合、移行は簡単ではなく、多くの問題が発生する可能性があります。ライブサーバーの移行が成功する可能性が最も高いのは、開始する前に、システムをできる限り理解することです。システムはそれぞれ異なり、毎回、新しい問題を回避する必要があります。発生する可能性のある問題のトラブルシューティングを行う時間がない場合は、移行を試みないでください。