コンソールにアクセスせずにSSH経由でLinuxをリモートで再インストールする

サーバーを再インストールする必要がありましたが、サーバーは私の知り合いの友人によってホストされているようです。 非常に時代遅れのDebianがあり、最も重要なことは、システムがlvmのない通常のパーティション上にあり、スペースが非常に不十分に割り当てられていたことです。 それに物理的にアクセスすることはほとんど不可能でした;ローカル管理者に何かをすることを依頼することはできましたが、1週間かかるかもしれません。 サーバーには仮想KVMがありましたが、外部からアクセスすることはできませんでした。 ホスティング事業者に追加のIPアドレスがなく、ネットワークにアクセスすることは不可能であるかのように。 sshを介して実行中のシステムの下からサーバーを再インストールする必要がありました。 はい、タービンのローターをオフにせずに変更してから再起動すると、新しいローターで動作します！

最初のアイデアは、ram-diskにchroot環境を作成し、そこからlvmを作成してシステムをいっぱいにすることでした。 しかし、システムはパーティションテーブルの変更を許可していませんでした。

2番目のアイデアは、Debianディストリビューションのソースを取得し、サーバーのIPアドレスをフラッシュし、Debianインストーラー、sshサーバー、私のIPでinitrdを再構築し、このinitrdをデフォルトのブロックでgrub構成に置き換えて再起動することでした。 その後、ネットワークインストーラーでsshコンソールを取得する必要がありました。 スタンドでやった！ しかし、戦闘では、すべてが失敗に終わり、サーバーは上昇しませんでした。 ホストはサーバーを実際に必要としなかったため、ケースは消滅しましたが、未解決の問題を感じています。

どういうわけか、同僚はシステムとあらゆる種類の破壊的なアクション（rm -rf /など）について議論し、同僚の1人は、ルートパーティションが配置されているscsiディスクを切断でき、システムがピックアップしないと述べました。 これにより、3つ目のアイデアが得られ、1つ目のアイデアが得られ、ディスクが引きちぎられ、ディスクが返されます。返されたディスクは、システムが提供しなかったものとは異なります。 それがまさに起こったことです。 そして、ポイントごとに、物理コンソールにアクセスせずにシステムを再インストールする方法を教えてください。

警告！ 私たちがやるのは一方通行の道だけだということを理解しなければなりません。間違えたらシステムにアクセスできなくなります！ サーバーを復元するには、1,500キロメートル移動して鉱山に登らなければならない可能性があります。

システムのIPは192.168.56.102であると想定しています。 それはまさに私がスタンドで持っていたものでした。 さらに、プロキシを介したインターネットへのアクセス：

http://proxy:8080 

ソースシステムの使用を開始します。

＃システム＃0

sshでサーバーにアクセスします。

 ssh 192.168.56.102 

「Kill​​er System」用のディレクトリとファイルシステムを作成し、マウントします。

 mkdir /target mount none -t tmpfs -o size=1G /target/ 

Debianの最小インストールを展開する優れたdebootstrapユーティリティをインストールし、それを使用してchroot環境を作成します。

 export http_proxy='http://proxy:8080' apt-get -y install debootstrap 

FedoraとCentosには、それぞれfebootstrapとyumbootstrapに似たユーティリティがありますが、私はそれらを使用しませんでした。

chrootを展開します。

 debootstrap jessie /target/ http://mirror.mephi.ru/debian/ 

最初の引数はバージョン、2番目はインストールディレクトリ、3番目はリポジトリです。

最も必要なものをバックアップします。

 mkdir /target/backup cp /etc/network/interfaces /target/backup 

最も重要なことは、ネットワークインターフェイスの設定です。これらがないと、再インストールされたシステムにアクセスできません。

chroot環境に名前を付けます。

 echo "Killer_system" > /target/etc/debian_chroot 

「Kill​​er_system」という単語がbashプロンプトに表示されます。 これは重要なことです。それなしでは、現在どこにいるかはわかりません。

新しい環境に移行します。

＃システム＃1

 chroot /target 

便利なfsをマウントします。

 mount none -t proc /proc/ mount none -t sysfs /sys/ mount none -t devtmpfs /dev/ mount none -t devpts /dev/pts/ 

もう一度debootstrapを設定します。

 apt-get -y install lvm2 debootstrap 

さらに私の問題：推奨パッケージのDebian openssh-serverパッケージにはxauthパッケージがあり、その依存関係にはあらゆる種類のxライブラリがあります。 私は、ミニマリズムの支持者として、グラフィックスのないサーバーにxビットを配置したくないのです。 したがって、キー--no-install-recommendsを使用します。

 apt-get -y install openssh-server openssh-client openssh-blacklist openssh-blacklist-extra --no-install-recommends 

構成を修正します。 sshデーモンの代替ポートを設定して、ssh経由でchrootシステムにログインできるようにします。

 sed -i 's/^Port .*$/Port 11122/' /etc/ssh/sshd_config 

ルートアクセスを許可します。

 sed -i 's/^PermitRootLogin .*$/PermitRootLogin yes/' /etc/ssh/sshd_config /etc/init.d/ssh restart 

rootアクセスを与えることはできませんが、ユーザーを作成してsudo権限を与えることはできませんが、ここでは意図的に単純化します。

次に、debootstrapはデフォルトでパスワードを設定しないため、ルートパスワードを設定する必要があります。

 passwd root 

sshでchroot環境に入ります：

 ssh 192.168.56.102 -l root -p 11122 

これは、ディスクを切り離す元のシステムを完全に取り除くために行っています。 したがって、RAMには完全に自律的なシステムがあり、古いシステムには接続されていません。

このトリックは、ホスティング事業者を離れる場合に非常に適しています。ファイルをそのままにしておきたくはありません（私は知っています、妄想）。 この段階では、すばやくしたい場合は単にディスクをゼロで駆動します。

 dd if=/dev/zero of=/dev/sda bs=1M 

または、必要に応じて、複数のパスでのランダムデータ。 この方法の利点は、ddが終了するまで待機し、必要に応じて繰り返すことができることです。 戦闘システムから直接ディスクを上書きすると、ddの結果を見ることができなくなります。

ボリュームとパーティションを削除する簡単な方法を試してみましょう。

 # lvremove /dev/mapper/vg_old-root Logical volume vg_root/lv_root contains a filesystem in use. 

 # fdisk /dev/sda Command (m for help): d Selected partition 1 Partition 1 has been deleted. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Device or resource busy The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8). 

しかし、失敗。 この場合、パーティションは削除され、システムがクラッシュしますが、再起動しないと単純な方法では機能しません。 そして、過負荷になる場所はありません。

私たちは他の方法で行きます。 何があるかを確認します：

 pvs lsblk 

ルートパーティションはsdaドライブ上にあると想定しています。

ディスクを上書きして、lvmがピックアップしないようにします。

警告！ この瞬間の後、戻りはありません。次のステップでもそれほど悪意はありません。 ちょっと考えてみましょう。コンソールをチェックして、そこに座ってchrootの名前を正当化します：

 dd if=/dev/zero of=/dev/sda bs=1M count=100 

ディスクを切り離します：

 echo 1 > /sys/block/sda/device/delete 

ディスクが外れたことを確認します。

 lsblk 

ディスクを接続し直します。

 for i in /sys/class/scsi_host/host?/scan ; do echo "- - -" > $i ; done 

返されたことを確認します。

 lsblk 

sdaだった、sdbになった、素晴らしい。

重要な点：ブートディスク上で、ディスク全体のサイズのプライマリパーティションを1つ作成し、このパーティションをlvmに渡して、grubがその上に立つようにする必要があります。 他のすべてのディスクは、パーティションシステム（pvcreate / dev / sdc）を作成せずにlvmに完全に提供できます。 パーティションテーブルと、タイプ8e、Linux LVMの1つのプライマリパーティションを作成します。

 fdisk /dev/sdb n<CR> <CR> <CR> <CR> t<CR> 8e<CR> w<CR> # create new primary partition from start to end; 8e type 

スクリプトの元のバージョンはシステム全体に1つの論理ボリュームを作成していましたが、同僚がこのスクリプトを使用してLinuxを再インストールしたとき、いくつかのパーティション、特にログ用の別のセクションを作成するのは少し難しいことがわかりました。 マウントポイントを作成し、実際にパーティションをマウントする手順に注意する必要があります。

 pvcreate /dev/sdb1 vgcreate vg_root /dev/sdb1 lvcreate -Zn -L500M -n lv_swap0 vg_root lvcreate -Zn -L1G -n lv_root vg_root lvcreate -Zn -L2G -n lv_usr vg_root lvcreate -Zn -L2G -n lv_var vg_root lvcreate -Zn -L1G -n lv_var_log vg_root lvcreate -Zn -L1G -n lv_home vg_root mkswap /dev/vg_root/lv_swap0 mkfs.ext4 /dev/mapper/vg_root-lv_root mkfs.ext4 /dev/mapper/vg_root-lv_usr mkfs.ext4 /dev/mapper/vg_root-lv_var mkfs.ext4 /dev/mapper/vg_root-lv_var_log mkfs.ext4 /dev/mapper/vg_root-lv_home mkdir /target mount /dev/mapper/vg_root-lv_root /target/ mkdir /target/usr /target/var /target/home mount /dev/mapper/vg_root-lv_usr /target/usr mount /dev/mapper/vg_root-lv_var /target/var mkdir /target/var/log mount /dev/mapper/vg_root-lv_var_log /target/var/log mount /dev/mapper/vg_root-lv_home /target/home 

すでに戦闘システムをハードドライブの新しい場所に展開しています。

 export http_proxy='http://proxy:8080' debootstrap jessie /target/ http://mirror.mephi.ru/debian/ echo "NEW_system" > /target/etc/debian_chroot 

構成のバックアップコピーを配置するために戻ります。

 cp /backup/interfaces /target/etc/network 

今、私たちは新しいシステムを待っています：

＃システム＃2

 chroot /target 

コマンドプロンプトで、新しいchroot環境の名前に注目してください。

ファイルシステムのマウント：

 mount none -t proc /proc/ mount none -t sysfs /sys/ mount none -t devtmpfs /dev/ mount none -t devpts /dev/pts/ 

親chrootからこれらのファイルシステムをマウントすることもできます。

 mount -o bind /proc/ /target/proc mount -o bind /sys/ /target/sys mount -o bind /dev/ /target/dev mount -o bind /dev/pts /target/dev/pts 

opensshをインストールして構成します。

 apt-get -y install openssh-server openssh-client openssh-blacklist openssh-blacklist-extra --no-install-recommends 

 sed -i 's/^PermitRootLogin .*$/PermitRootLogin yes/' /etc/ssh/sshd_config passwd root 

必須のパッケージをインストールします。

 apt-get -y install vim sudo linux-image-3.16.0-4-amd64 grub2 lvm2 psmisc vlan 

はい、私はvimなしでは生きられず、nanoを嫌います：

 update-alternatives --set editor /usr/bin/vim.basic 

原則として、インストール時にまだ必要な場合はgrubが規定されていますが、それでもパンツと士気をサポートするために、次のように繰り返します。

 update-grub grub-install /dev/sdb 

ここで、最初に最も重要な設定を編集します。これがないと、システムは上昇しません。

 cat > /etc/fstab <<EOF # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vg_root-lv_root / ext4 errors=remount-ro 0 1 /dev/mapper/vg_root-lv_usr /usr ext4 defaults 0 2 /dev/mapper/vg_root-lv_var /var ext4 defaults 0 2 /dev/mapper/vg_root-lv_var_log /var/log ext4 defaults 0 2 /dev/mapper/vg_root-lv_home /home ext4 defaults 0 2 EOF 

ネットワークが何らかの形で私たちのために働いたので、すべてがinterfacesファイルで順番になっている必要がありますか？

 vim /etc/network/interfaces 

aptの設定で、プロキシ情報を追加します。

 echo 'Acquire::http::Proxy "http://proxy:8080";' > /etc/apt/apt.conf 

ホスト名の変更：

 echo new-system > /etc/hostname 

/ etc / hostsに行を追加します。

 echo "192.168.56.102 new-system.corp new-system" >> /etc/hosts 

管理者を追加：

 adduser admin usermod -a -G sudo admin visudo 

ファイルシステムのマウント解除：

 umount /dev/pts umount /dev/ umount /proc/ umount /sys/ 

そして、chrootを終了します。

 exit 

ファイルシステムのマウント解除：

 umount /target/usr/ /target/var/log/ /target/var/ /target/home/ 

/ devをアンマウントできなかった場合、/ targetはアンマウントできませんが、これは恐ろしいことではありません。

成功した場合、これを行います：

 umount /target/ 

そうでない場合は、次のようにします。

 sync ; sync ; sync ; mount -o remount,ro /target/ 

これらのコマンドは、ディスクキャッシュをフラッシュし、ルートファイルシステムを読み取り専用で再マウントします。 その後、オーバーロードすることができます。

ここでは、systemdを愛する皆さんからの驚きを待っています！ 彼は、私たちがchrootにいることを知っており、再起動を許可していません！ Googleはchrootを終了するようにアドバイスしていますが、どこにも行きません。 しかし、Magic SysRqが助けになります！

SysRqをアクティブにします（おそらくアクティブになっていますが、確認する必要がありますか？）。

 echo 1 > /proc/sys/kernel/sysrq 

そして過負荷：

 echo b > /proc/sysrq-trigger 

ドラムロール、驚くべき期待、私たちは本当に何かを忘れてしまい、サーバーは上昇していませんか？

 ssh 192.168.56.102 

やった！ 私たちは新しいシステムにいます！

initrdの再作成。 これは必須ではありませんが、将来的には再起動中のエラーを排除する予定です。

 update-initramfs -u 

chroot環境という名前のファイルを削除します。

 rm /etc/debian_chroot 

以上です。

 ## The end 

参照：

サーバーオーバーロードメソッドに関する興味深い記事