プリキュアデータサイトを運営しており、今朝も更新をしていました。
ふと気がついたことがあります。
「シリーズ別」のメニュー、最後が切れてしまっています。
この状態でスクロールすると、後のコンテンツ本文がスクロールして、メニューはスクロールせず、その結果メニューの下には行けないという結果に至ってしまいました。
とは言ってもこのメニュー、増えることはあっても減ることはないはずです。
そこで今回はこんなページを作ってメニューの一番上に置きました。
このページから全項目アクセスできるようになりました。
ちなみに仕様を書いたらだいたいGitHub Copilotが作ってくれました。
ラウンドワンとまほプリコラボが終わったあとこんなことを書きました。
このコラボ終了にあわせて、ボウリングをやめると言うことは考えていません。
ただ、今身体中から悲鳴が上がっています。
普段は座ったままパソコンと向き合っていますから、体を動かす機会がないわけです。
そんな中でのこのハードワークは体が壊れます。
なので、これからは月1回くらいのペースで、ゆるりゆるりとやろうかと思います。
また、プリキュアとのコラボが実現した時に、バンバンターキーが取れるように――
「ターキーへの道」はこれからも続きます。
というわけで「ゆるゆるボウリング」第13回スタートです。
基本レギュレーションは以下の通り：
これ以上体を悪くしないように設定しました。
前回が4月11日でした。
昨年5月10日に始まった「ゆるゆるボウリング」。
今回から2年目突入です。
5月1日から各種料金が引き上げとなっています。
この記事では変更後の金額を記載しています。
今回は安く済ませるために朝早くに入りました。
土休日は5時～10時の受付だと朝割1960円が適用されます。
そして明後日11日は私の誕生日。
ラウンドワンからはいくつかバースデークーポンが届いていました。
その中から300円引きクーポンを適用しています。
第6ゲーム終わりの休憩で「ふるシャカポテト クラシック・プレーン」（570円）
第12ゲーム終わりの休憩で「金のとりからプレミアム」（650円）
第18ゲーム終わりの休憩で「R-1アイス」（100円）
今回も制限数の24ゲームまで投げました。
結果はこちら。
ターキーですが、今回は前回同様1回出ました。
これを含んだダブル以上は以下の通り：
今回のムーンストライクゲームの結果です。
今ムーンライトストライクを達成すると、忍たま乱太郎とのコラボステッカーがもらえます。
さて、バースデークーポンの中には、カラオケ限定の「バースデーハニートースト」（無料）が入っています。
ルーム代金はクラブ会員の更新特典クーポンで1時間無料です。
カラオケはいつのまにかドリンクバーがつかなくなりました。
ただ、ドリンクバーがワンオーダー対象になりました（560円）。
合計は3540円（ボウリング2980円、カラオケ560円）となりました。
前回と統計値を比較します。
※アベレージ及びストライク率・スペア率・オープンフレーム率の増減は小数点以下第4位を四捨五入した上で算出して、小数点以下第3位を四捨五入しているため、単純な増減計算より0.01単位での誤差が生じることがあります。
| 項目 | 前回値 4月11日 |
今回値 5月9日 |
増減 |
|---|---|---|---|
| アベレージ | 127.63 | 128.88 | 1.25 |
| ハイゲーム | 171 | 164 | -7 |
| ストライク率 | 28/240 11.67% |
25/240 10.42% |
-1.25% |
| スペア率 | 78/212 36.79% |
83/215 38.6% |
1.81% |
| オープンフレーム率 | 134/240 55.83% |
132/240 55% |
-0.83% |
アベレージが若干よくなったものの、ストライクは前回より3減りました。
オープンフレームは前回より2減っているので、若干よくなっています。
自己ハイゲームは前回と変わらず178のまま。
1投目のピン成績を見ていきましょう。1番ピンのヒット率が低かったのですが、今回はどうだったのでしょうか…？
※ヒット率は小数点以下第1位を四捨五入。増減は小数点以下第2位を四捨五入した上で算出し、小数点以下第1位を四捨五入しているため、単純な増減計算より1単位での誤差が生じることがあります。
※第10ゲームは、第8フレームのデータが不正であるため今回のピン成績統計から除外しています。1つ上のアベレージ等のデータには反映しています。
| 前回値 4月11日 |
今回値 5月9日 |
増減 | |
|---|---|---|---|
| （対象フレーム数） | 230 | 230 | |
| 1 | 161 70% |
142 62% |
-8% |
| 2 | 171 74% |
146 63% |
-11% |
| 3 | 184 80% |
183 80% |
0% |
| 4 | 173 75% |
168 73% |
-2% |
| 5 | 160 70% |
157 68% |
-1% |
| 6 | 175 76% |
182 79% |
3% |
| 7 | 168 73% |
167 73% |
0% |
| 8 | 198 86% |
189 82% |
-4% |
| 9 | 212 92% |
194 84% |
-8% |
| 10 | 180 78% |
187 81% |
3% |
依然として1番ピンのヒット率は低いです。6番・10番のヒット率は上昇しましたが、それ以外は低下してしまいました（3番・7番は率で言えばごくわずかなので0%の表示になっています）。
1日1ターキーではなく、2ターキー、3ターキーと続けていきたいところ。
今後うまくいくのでしょうか？
5月5日に実施したMastodonサーバを最後に、当方で管理していたCentOSサーバ5台全てをAlmaLinuxへ移行しました。
Geminiの全面的バックアップを受けながら足かけおよそ2ヶ月に及んだ移行を振り返ります。
本格的に動き出したのは3月6日頃。
まずはCentOSからの移行先を探すところから始まりました。
要件としては
としてリサーチ要求を投げたところ、「Elevateプロジェクトを使ってAlmaLinux10へ移行するのがベスト」との回答が得られました。
今回の移行に当たっては、影響範囲の小さいところで先に実施して感触を掴んでから、大きな所を目指すこととしました。
その中で一番影響範囲が小さいのが、自分しか使っていないVPNサーバ。
このサーバはCentOS7→AlmaLinux8→AlmaLinux9と順を追って移行していきました。
3月15日に作業を開始しましたが、いろいろなところで止まりました。主立ったものとしては
…といったこともありながら、まずは1台AlmaLinux9まで移行が完了しました。
続いて2番目に影響範囲が小さいメールサーバに着手しました。
3月20日に作業を開始。VPNサーバと同様、メモリ1GBの中での作業という厳しい状況。
それに加えてディスクの空き容量にも余裕がなく、急遽用意したNFS（サーバに接続できる外付けドライブのようなもの）を含め、空けようにも空かない状態の中AlmaLinux8への移行を強行。
その結果、最初の再起動後のOS書き換え時に途中でストップ。この時点でSSH接続ができなかったため、コピペできないコンソール画面との戦いに陥りました。
その後再起動すると正常に起動したかのように思われましたが、アップデート用のコマンドをたたくとエラーが返ってくる事態に。
どうもCentOS7の中身でAlmaLinux8と主張するキメラ状態に陥ってしまっていたようです。
手作業で書き換えが上手くいかなかったファイルを書き換えて何とかAlmaLinux8が立ち上がるようになりました。
この勢いでAlmaLinux9への移行も行いましたが、またしても8系と9系のキメラ状態に。
こうなってはらちがあかないので、まず9系のファイルを8系に無理矢理戻して、まずは8系が起動するところまで戻しました。
そこから9系への移行を再度試行したもののまたしてもキメラ状態に。
Geminiも「これ以上あがくのは危険だから、クリーンインストールした方が早い」とさじを投げる結果となりました。
そしてクリーンインストールしたあとからも大変で、
…という「動かない」オンパレードに陥ってしまいました。
実に5日間（この間に平日があったので日常業務をこなしながら）かけて復旧に至りました。
ここからは一般向けサービスを提供しているサーバの作業となるため、事前に告知を出して挑みました。
ここまでの経験上、特にメールサーバであったような不整合が発生した場合の対応と、もし無理だと判断した場合の切り戻しを考慮して、メンテナンスウインドウを12時間に設定しました（以降も同じ）。
このサーバには数多くのサイトが載っていて、その大半がPHPで動いています。
開発時期がバラバラと言うこともあり、古いバージョンを含む複数バージョンのPHPが並列で動いていたのです。
このうち7.x系がAlmaLinux9では動かないとのことだったので、このサーバについては8系にとどめることとしました。
実は今回の移行前調査までは5.x系といういわば骨董品まで入っていましたが、調査したところ使っているところがなかったので先に削除しました。
メールサーバでの経験から事前にいろいろな設定をした上で移行作業を開始したところ、アップデート時にブートローダの設定書き換えに失敗して起動しなくなるという深刻な不具合が発生。
ブートローダ側はUSキーボードとして認識している一方でこちらはJPキーボードであるが故に、なんと半角の閉じ括弧）が入らないという事態に。
幸いTAB補完で何とか進めることができました。
正しく起動できるようになってからも、
…といったトラブルに見舞われましたが、Geminiの的確なコマンド出力により解決しました。
その結果12時間確保していたウインドウの内、5時間で作業を完遂することができました。
とはいってもその後一般利用者向けには影響のない範囲での不具合修正を行ったので、全作業が終わったのはその数時間後のことでした。
サブサーバの構成としてはこうなっています。
メインサーバと違ってブートローダも問題なく更新されました。
一方で、先ほど触れたとおりこのサーバではJavaプログラムが動いています。
そのプログラムは、サーバ起動時に立ち上がるように設定していたのですが、移行後立ち上がってきませんでした。
ログを見ると、「プログラム側のJavaのバージョン」が、「サーバ側のJavaのバージョン」よりも新しくて起動しなかったとのこと。
移行時に先に入れていた新しい方のJavaが消え、システムデフォルトの古いJavaが入ってしまっていたようでした。
また、Javaプログラムでは、MariaDB上でのシーケンス管理に専用テーブルを用いていましたが、MariaDBのアップデートで上手く動かなくなっていました。アップデートでシーケンス管理専用の機構が導入されたのでそれにあわせるようにして対応しました。
最終的には約5時間で移行作業を完了することができました。
着手の前日何したら良いかGeminiに聞いたところ、「メディアファイルのバックアップ」が提案されました。
確かに
はありましたが、メディアファイルについては抜け落ちていました。
最初はそのままGoogle Driveに送り込んでいましたが、1つ1MBもないファイルが数万あったのもあり、とてつもない時間がかかっていました。
そこで提案されたのがresticというもので、複数のファイルを1つの大きなファイルにまとめて転送することにより、Google Driveとの通信回数を減らすことができたのです。
事前調査でブートローダ領域が非常に小さいというエラーが出ました。
しかしながらこの領域は今から拡大することができない状態。
様々な環境変数を山盛りにしてチェックをスキップさせようとしても聞く耳を持たず。
やむを得ずこちらもクリーンインストールとなりました。
サーバ・データベース・メディアに加え共通の設定もバックアップしてクリーンインストール。
数百にも及ぶパッケージのインストールとMastodonの重量級ビルド、そしてバックアップの戻しを行い、一般利用者向けに影響のある部分については15時までに終了。
その後裏側部分の修正を行い、夜までには全ての作業を完了しました。
今回、当初はAlmaLinux10へ移行しようと考えていたのですが、今回は断念せざるを得ませんでした。
AlmaLinux10以降だと、現状のファイルシステムが認識できなくなり、それに対応するためにはフォーマット（＝全データの消去）が必要となってしまうため、実質再構築と同様の手間が発生することから、今回は断念しました。
各サーバとも週に1回（未明帯）フルバックアップを取っています。
今回の移行前までは以下のサーバを経由してGoogle Driveにバックアップを取る形としていました。
一旦別サーバ経由にしているのは、バックアッププログラムがGoogle Driveに対応していないからで、対応しているファイル共有の仕組みを使うためです。
ここまで出てきたサーバは、メールサーバ以外さくらのVPSで動いていて、インターネットを介さないローカル接続を行っていました。
ところがそれでもデータの滞留が発生し上手くバックアップが取れないこともありました。
そこで白羽の矢が立ったのが、「KAGOYA CLOUD VPS」。
さくらのVPSと比較すると、KAGOYAの方がよいという結論に至りました。
全サーバのバックアップを無圧縮レベルで詰め込んでも余裕が生まれるかもしれないレベルで大容量のサーバを契約しました。
そのサーバに一度格納した後、Google Driveとの同期を取る形にしました。
その結果、
…という環境を整えることができました。
Mastodonサーバで最初に投入したコマンドをメモしていましたので共有。
# 何度もこれを指摘されたので先にやっておくのがよさそう
sudo yum remove -y kernel-devel
sudo modprobe -r floppy pata_acpi
# NICが複数あってエラーになるので、設定を隔離する
# 作業用のバックアップディレクトリ作成
mkdir /root/network_backup
# eth1 と eth2 の設定ファイルを一時的に避難させる
# (これにより Leapp のスキャン対象から外れます)
sudo mv /etc/sysconfig/network-scripts/ifcfg-eth1 /root/network_backup/
sudo mv /etc/sysconfig/network-scripts/ifcfg-eth2 /root/network_backup/
# eth1 (virtio1) と eth2 (virtio2) をドライバから切り離す
echo "virtio1" | sudo tee /sys/bus/virtio/devices/virtio1/driver/unbind
echo "virtio2" | sudo tee /sys/bus/virtio/devices/virtio2/driver/unbind
# ip a で確認。lo と eth0 だけになっていれば成功です。
ip a
# 1. ELevateリポジトリのインストール
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
# 2. Leapp本体とAlmaLinux用データのインストール
sudo yum install -y leapp-upgrade leapp-data-almalinux
# ネットワーク系のエラーがいつまでたっても消えないので環境変数で黙らせる
LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_SKIP_NETWORK_INSTABILITY=1 LEAPP_NO_NETWORK_RENAME=1 leapp preupgrade
# 一旦preupgrade実施しないとanswerfileができないので
# PAM PKCS#11 モジュールの削除に関する確認（最も一般的な回答要求）
sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
# これで再実行したらどうだろうか？
LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_SKIP_NETWORK_INSTABILITY=1 LEAPP_NO_NETWORK_RENAME=1 leapp preupgrade
3月6日頃から動き出した移行プロジェクトはこの記事の投稿を持って完結。
長い戦いではありましたが、Geminiに情報を共有するとすぐにコマンドが出てくるというのを存分に生かして進めることができました。
今回の移行後のOSはこんな感じになっています。
少なくともあと3年はこの態勢で動かせるようです。
さて、さくらのVPSでは「ホストサーバー収容機材変更」を順次実施しています。
対象はメールサーバ以外の4台で、
…に引き続き、5月下旬（遅くとも26日までに作業可能となる予定）にはサブサーバの対応を実施します。
諸々の条件が許せば、これまでと同様に未明帯に1時間程度のウインドウでメンテナンスを設定する予定です。
決まり次第お知らせします。
これでようやっと予定していたメンテナンスが終わることとなります。
