10月7日、KUSANAGIのアップデートが来ました。
いつも通りコマンドを打ち込みます。
# dnf upgrade
しかしエラーが出てアップデートできない。
(競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)
KUSANAGI8のときに困らされたエラーかな?
オプションつけて、もう1回。
リストを見て、なんとなくイヤな予感がしたのですが構わず続行。
途中、やたら時間がかかって不安が増すも無事完了。
# kusanagi restart

えっ!?
bash: kusanagiコマンドが見つかりません
こんな感じのメッセージが。
悪夢の始まりでした。
テストサーバーを立てて原因を切り分ける
幸い、ConoHaのイメージバックアップは2週間前のものがありました。
テストサーバーを立ててイメージから復旧。
アップデートしてみます。
もしこれで成功するようなら、バックアップを取った後の私の環境に問題があったということ。
しかしKUSANAGIとNginxの部分はほぼ設定固まったからこそバックアップとったわけで。
環境変わらない以上はやはり失敗するはず。
一応確認した上で、真っさらのKUSANAGIサーバー立てて再テストするつもりでした。
ところが……

アップデート成功!?
これでKUSANAGIのせいでなく「おまかん」。
私の環境であることが確定しました。
しかし今回ばかりは理解不能に陥りました。
なんで? どうして? エラー出そうなところ触ってないのに!?
対処法を探す
「bash: kusanagiコマンドが見つかりません」で検索して対処法を探す。
しかしまったく引っ掛かりません。
もちろんrootじゃないというオチはありません。
いくつか試してから「KUSANAGI アップデート エラー dnf」で探してみたところ、こんな記事が。

これだ!
まったく私と同じ症状でした。
ただしこの方は失敗せずにうまくいった様子。
対処法は「アップデート前に」次のコマンドを打ち込むこと。
# dnf clean all
今更遅いかもしれないけど……うん、やっぱりダメでした。
KUSANAGIコマンドが動くようになる
とにかくアップデートに失敗してKUSANAGI吹き飛んだのは間違いない。
とりあえず、SFTP経由でWordPressのバックアップファイルを確保。
最悪の場合でも、これで今朝方深夜の状態には戻せます。
こうなればサーバー飛ぶの覚悟で色々試せる。
dnfコマンドを片っ端から打ち込んでみました。
すると、どれが効いたのかわかりませんがKUSANAGIコマンドだけは復活しました。

これで……なんとかなるかも……
復旧に一歩近づいたということですし。
KUSANAGIコマンドさえ使えるならトラブルシューティングの幅が一気に広がります。
なぜか管理画面にはアクセスできる
ここでおかしなことに気づきます。
当然ながら外部からサイトのフロントにはアクセスできません(プロトコルエラー)。
しかしなぜか管理画面にはアクセスできました。
開きっぱなしにしていた管理画面を更新してみたところ、ちゃんと表示される。
履歴から開いても表示される。
試しにWordPressをエクスポートしてみたところできました。
これでイメージから最新の状態に戻せるのは確定したのでありがたいのですが。
本当にいったいどういうこと?
SSL回りを確かめる
サイトに繋がらない場合、可能性の一つとして考えられるのがSSL。
なのでSSLコマンドの実行と301リダイレクトの解除を試してみました。
……が、どちらもだめでした。
ApacheとNginxを切り替えてみる
ここで試しにApacheと切り替えてみました。
Nginxの設定ミスなら動く可能性がありますので。
まあ、ダメ元です。
# kusanagi httpd

サイト復活した!
まじで?
ということはNginxの設定が原因となります。
しかし設定ファイルをいくら見直してもバックアップ当時とは変わったところない。
そもそもconfファイルは元々xmlrpcを停止した以外にさわっていません。

PHPのアップデートだったみたいだからそっちかなあ?
やはり記述が変わってるようには思えないんですけど。
復旧!
実はアップデート時に嫌な予感したのは「kusanagi-prem delete」とあったから。
なんでWEXALを削除?
私にわかるわけないので続行したのですが……本当にやめておけばよかった。
その嫌な予感を思い出して、

もしかしてWEXALが飛んでる?
試しに打ってみました
# pst status プロファイル
「pstコマンドが見つかりません」……やはりか。
KUSANAGI premiumを再インストール。
pstコマンドが復旧したのを確認。
サイトトップページにアクセス。

表示された!
無事、復旧しました。
まとめ
こちらのFAQは事前に読んでおいた方がいいと思います。

エラーが出た時点で検索していればこんなことにはならなかったのですが、なめてました。
最後にフォーラムの質問者さんの質問から引用します。
「–allowerasing」、「–skip-broken」、「–nobest」などののオプションを試せばいいのでしょうか?

「–allowerasing」は絶対試しちゃダメ!

本稿のようになってしまいます!
「–skip-broken」はやはりエラーが出て終わりました。
できればエラーが出て実行する前に、この文章を読んでいることを祈ります。