サーバーレスキューをリモートで頑張ってみた

この記事は、[MicroAd Advent Calender 2022](https://qiita.com/advent-calendar/2022/microad)の11日目の記事です。

## 概要と注意

この記事は、Ubuntuのinstallイメージ（iso）を使って、サーバーをレスキューした話です。
かなりニッチな話ですし、Live-CDなどを使えばもっと簡単に対応できるかもしれません。

また、リモートで作業する前提で書いていますが、
サーバーの目の前で作業できるのであればこれより遥かに簡単に対処可能です。

## きっかけ

マイクロアドでは、MAASを使ってサーバーにOSをデプロイするようにしています。
今回は、このMAASが引き起こした現象により、サーバーを操作できなくなったため対処することになりました。

MAASで管理していたホストをリリース（利用終了して開放）したあと、HW情報を更新しようとしてcommissionを実施した際に、
ipmi経由での接続ができなくなるということが発生しました。

![スクリーンショット 2022-12-09 16.02.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/930066b9-8c10-f5d5-848b-a0047d2dcc51.png)

このような **”BMC - Access denied while〜”** というログが出力され、電源ステータスが取得できない状況になりました。

## 根本的な原因

この原因は、MAASがcommission時に行っているBMCに対する設定処理の中で、
cipherの権限設定が意図しないものに上書きされていることが原因でした。
この問題はMAAS ver3.1までに含まれているバグで、3.2以降は改修されているようです。

## やったこと

### 起きている状況

この問題の対処には、ipmiの権限設定を修正するという対応が必要になります。
しかし、外部のLinuxホストからipmitoolコマンドで操作することができず、
問題のあるホストでOSを起動しipmitoolコマンドでローカルのBMCを操作する必要がありました。

### 問題になったこと

ここでの問題は、通常のトラブルであればMAASのレスキューモードを利用し、
Liveモードでホストを起動することができる為、ipmiの復旧を行うことができます。
しかし、電源操作ができなくなっていることで、レスキューモードを起動することができなくなっていました。
そのため、MAASの仕組み以外でLiveモードでOSを起動し、ipmitoolコマンドを実行できる必要がありました。

### 手順

幸い、今回の問題が起きている状態でも、WEB-UIを使ってBMCへ接続できる状況にありました。
そこで以下の手順でリモートから復旧作業を行いました。

1. UbuntuのインストールISOファイルをダウンロード
1. httpサーバーが動いているホストにISOイメージを保存（該当ホストのBMCからも参照できること）
1. ブラウザで、BMCへの接続
1. BMCのリモートコンソール等の機能に含まれる、Virtual Mediaなどの機能を利用し、
ISOイメージのURLを指定（マウント）する。
1. BMCから電源操作し、Boot指定でVirtual Mediaを使って起動する。
1. Ubuntuのインストーラーが起動するので、右上のHelpメニューから「Enter shell」でShellを起動し、
ipmitoolのaptコマンドでipmitoolをインストール
1. ipmitoolコマンドで、cipher_privsを現状設定を確認の上、編集します
1. MAASの画面上から、電源ステータスが取れるようになったことを確認

このような手順で、復旧することにしました。

## 実際の対応

ライブモードのLinuxとして起動するのは、Ubuntuのインストーラーでなくても問題ありません。

### Virtual MediaへISOファイルをマウント
サーバーメーカーのBMCにより設定方法が異なると思いますが、
今回問題が起きていたLenovoのIMM2では、以下のような感じで設定しました。

![スクリーンショット 2022-12-09 16.05.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/488cb709-7dba-b369-3530-74bd4b93f6ad.png)
この画面のMountボタンを押すと、ポップアップでURLを指定するページが表示されます。

![スクリーンショット 2022-12-09 16.05.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/d73735c4-0918-1cd4-2af5-a97ec331046e.png)

URLを指定して、「Mount the Image」をクリックすると、Virutal Media（CD）としてISOファイルをマウントできます。

### ISOファイルからboot

Lenovoのロゴが出ている状態で、F12キーを入力することでbootデバイスを指定できるメニューが出ます。
![スクリーンショット 2022-12-09 16.08.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/c2d1e369-0831-a8ae-8eae-bdf9eb9b6830.png)
この画面でF12キーを入力

![スクリーンショット 2022-12-09 17.04.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/8652435d-a637-f87c-deb3-7abf20067042.png)
メニューから、「CD/DVD Rom」を選択することでVirtual MediaのISOを起動することができます。

![スクリーンショット 2022-12-09 16.20.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/67be3db6-2d45-dd06-abb6-ffb414c3fff3.png)
しばらくすると、Ubuntuのインストーラーが起動します。

![スクリーンショット 2022-12-09 16.23.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/92ba721c-053c-5dc2-389a-913c236705a0.png)
右上にあるHelpから「Enter Shell」でroot権限のshellを起動します。

このあとは、aptでipmitoolをインストールして設定を変更するだけなのですが、
さらにリモートでやっている関係で問題が発生しました。

### keymapがおかしい

IMMの仮想コンソールを使っている影響か、キーマップを変えても文字が入力できずハマるという事態に。
やむなく現場に行くしか無いかと諦めかけていたところ、
インストーラーが起動している状態でもSSHできることが判明しました。

![スクリーンショット 2022-12-09 16.21.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/bd790ea2-232e-88e6-39e7-b31f0e03543a.png)
この **「Help on SSH access」** を選ぶと、次のような画面が表示され、SSHでログインできます。

![スクリーンショット 2022-12-09 16.21.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/b6d4df85-9f97-733b-1be2-5f8512022c81.png)
ここで表示されている情報でログインすることで、SSH経由で操作できるようになります。

### ipmitool使って復旧

無事にターミナルからログインできたら、ipmitoolをインストールして、
復旧対応を行います。

今回のLenovoサーバーは、通常以下のように設定されているのが正しい状態です。

```console
root@ubuntu-server:~# ipmitool lan print 1 |grep Cipher
RMCP+ Cipher Suites     : 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
Cipher Suite Priv Max   : aaaaaaaaaaaaaaa
                        :     X=Cipher Suite Unused
```

問題が発生しているときの設定値
```console
root@ubuntu-server:~# ipmitool lan print 1 |grep Cipher
RMCP+ Cipher Suites     : 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
Cipher Suite Priv Max   : XXXaXXXXaXXXaXX
                        :     X=Cipher Suite Unused
```

このように、本来"aaaaaaaaaaaaaaa"となるべきところが、"XXaXXXXaXXXaXX"となっていました。
これを次のようなコマンドで上書きします。

```console
root@ubuntu-server:~# ipmitool lan set 1 cipher_privs aaaaaaaaaaaaaaa
```
これにより、本来の設定値に上書きでき、以降MAASからも電源ステータスが取得できるようになります。

### この問題をMAASで回避する方法

MAASのCommission時に、 
**「Skip configuring supported BMC controllers with a MAAS generated username and password」** 
にチェックを入れてCommissionすることでこの問題を回避することができます。

![スクリーンショット 2022-12-09 10.23.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/20794/ed30c830-b89c-68ea-fff9-b4b40eb718f9.png)

なにより、MAASを3.2以降にバージョンアップしていれば問題ありません。
また、一部メーカーの機器でのみ発生するようでマイクロアドではLenovoサーバー以外では問題が発生していませんでした。

## おわりに

今回、かなりレアな対応をすることができました。
リモートで復旧までこぎつける方法を考えるのも楽しかった（というと怒られそう）です。

アドベントカレンダーのネタを考えているときに起きた問題だったので、
ちょうど良く記事が書けたのも良かったです。

そして今後のために、各種ツールをインストールしてあるLinux LiveのISOイメージを作ろうと思います。