移行作業したときの愚痴

久しぶりだし、雑に書く

続けてて偉い!

移行前が古い問題

レンタルサーバを借りてずいぶん経っていて、ようやく重い腰を上げてサーバの移行をした。

移行元のサーバはサポートが終わったOSで更新がなく、パッケージのリポジトリも404とかになっていた。

ついにはCMSからもパッケージが古くて更新できないよ!と怒られたので終焉。

セキュリティの観点で怒られるやつ、仕事じゃ許されないね。

作業したときのアレ

鬱憤を晴らす意図で書く

KUSANAGI、公式ページさぁ

早速ながら初期設定をしようじゃないかと「KUSANAGI 初期設定」で検索。

検索のトップにでてくるのは公式サイトの「KUSANAGIの初期設定」のページ。

どう見ても公式のページ。
「yum update」とか書いてるけど公式だし、とりあえず信じてみた、が、駄目。

なんと、このページは「KUSANAGI 8」の情報だった。

いまは「KUSANAGI 9」

バージョンを書けよ!
そもそもなんでこのページ残ってるんだ、ただの罠ぞ。

AIツールも古い情報に引っかかって余計な時間とトークンを使った。

このトラップを踏み抜いて無駄足を踏んだあと、正しく「KUSANAGI クイックスタート」のページにたどり着いた。

KUSANAGIの今のコマンド情報もこっち側のデザインの「KUSANAGI コマンド」で探せば良い。

正しいページの情報を見て、ほぼ、それほど詰まること無く進められたと思う。

kusanagi provisionコマンドのssl設定するなら、ドメインを先に用意

本来の手順では「kusanagi init」が先だが、躓いたタイミングが「provision」の方が先だったのこちらを書く。

今回はサーバ移行なので、ドメインについては移行元のサーバが生きている状態で進めるのだが、「provision」コマンドでプロファイルを作る時に「sslの設定、仮で書けるっしょ」とやったら駄目だった。

ちゃんとDNSでドメインを切り替えたあと、外からドメインで新しいサーバに向いてからじゃないと、sslの設定は失敗する。

結果として以下の順番の作業になった。
「provision」で新しいプロファイルを作り、Basic認証でカバーしながら移行作業をする。
> 移行が概ねできて見られる状態にしてDNSの切り替えを行う。
> DNS切り替えが反映されてきたら、別途SSL設定だけの「ssl」コマンドでhttps化する。

kusanagi initコマンドとBasic認証

「provision」コマンドでIPアドレスでブラウザからアクセスできたのだが、Basic認証がついててユーザーもパスワードもわからなかった。

これは、コマンドの「init」のページにBasic認証関連が書かれていたのに気付いていなかっただけ。

未熟。

古いサーバで「やっぱ移行しなきゃいかんよな」と思ってたメモ

webサーバ自体は動いていたし、攻撃を受けるほどでもない規模だし、ある程度のセキュリティ対策は古いなりにできていたんだと思う。

でも古いサーバで更新まわりは「移行しなきゃあかんな」となっていた。

まず「OSのサポートが切れた」
有名どころの無料のLinuxのOSだったが、消えた。当然サポートもない。
サポートが切れたOSは期間が空くほど不安になる。

また、OSでは無くパッケージ更新の方で「指定していたリポジトリが404でパッケージ更新できない」が発生した。
OSのサポートが終わるなら、当たり前ではある。

まあ、これはリポジトリの情報を調べて設定を変えれば多分どうにかなったと思う話だけど、「そろそろ移行しなきゃな!」と考えていたのでサボった。

移行できて偉い。

あとはどうでもいいこと

備忘録って自分の詰まりどころが誰かの役に立つと良いな、という善意の置き土産じゃんね。

また自分が「ここ詰まったんですけど!」という腹いせを書いて発散する場であり、
「そういやこういうことやったわ」という記憶を掘り出すトリガーである。

つまり脳に良い。

他人の役に立つかは二の次である。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください