StarDust Tears

サーバをリプレースした

 見てる人には関係ないが、このサイトを置いてるサーバをリプレースした。
 しばらく更新してなかったのはそのせい、と言いたいが作業は一晩で終わったのでそれはウソである(笑。 まあ下準備とかはしてたけど。

 関係ないとは言うたけど、せっかくなのでこれを機にブログタイトルのフォントを変えた。私がフォントを普通に選ぶと毎度同じようなのになるので(昔からセンスが変わってない)、最初にこのブログを構築してデザインをいじった際にはあえて毛色の違うものを選んだつもりだったのだが、実際に適用してみると思ったよりオシャンティー(死語)な感じになってしまってキモい! と言いつつそのままになってたのを、この度また変更しました。今回も意外性重視で選んだつもりである。
 ただメインページから読んでるGoogleフォントのCSSはURLが変わってるのですぐ反映されるけれども、フォント指定してるCSSはキャッシュが効いて古いままになるケースがある。すると両者のフォントが食い違い、指定のフォントが読み込めず既定の cursive フォントで表示されるのだが、手元の環境ではこのデフォルト cursive フォントがダサい! あまりにもダサいのでこれが私の意図したデザインと思われたら死んでも死に切れない。皆さんのローカル環境の cursive フォントがダサくないことを祈る。更新を反映させるためにはこのCSSファイルを直接開いてリロードし、

  font-family: 'Chelsea Market', cursive;
という記述があるのを確認していただきたい。その状態で表示されるのが私の意図したタイトルロゴのはずである。さらにダサくなったと思った人には申し訳ない。

 話は戻ってサーバリプレースだが、もともと自前のサーバ一個くらい持ってたいなーと思いつつインフラ関連の作業が苦手で面倒でもあるので、EC2のインスタンスをポコッと一つだけ立てて運用していた。仮想マシン一つにバーチャルドメイン三つも四つも設定するという全くクラウドらしからぬ貧乏運用である。なぜか固定IPも二つ割り当てていた。AWS では固定のグローバルIPも Elastic IP という独立したリソースとして管理でき、旧EC2インスタンスから新インスタンスにこの Elastic IP の関連付けを変更するだけで済んだ。便利だなあ。
 リプレースしたのは、最初の段階で仮想ネットワークとかよくわからんので適当に構築し、中身もいい加減に使ってたらグチャグチャになってきたのでそろそろどうにかしたい、くらいの理由である。なのでVPCから作り直した。 OS も Amazon Linux 2 になっていろいろ良くなってるみたい、というか具体的には Let's encrypt の証明書更新が完全自動化できるらしい、てのが決め手になった。今まで certbot による更新が失敗することがわりと多かったので cron で自動更新まで踏み切れていなかった。 Let's encrypt(というかcertbot)側の言い分では Amazon Linux は "support is very experimental at present" とのことなので仕方ないか、と思ってたのだがAWS側のドキュメントにはちゃんと手順が書いてあるではないか(だいたいはPythonのバージョンアップ周りで失敗するので --no-self-upgrade オプションを指定すれば旧でもいけるっぽい)。
 あと去年 Let's encrypt でワイルドカード証明書も発行できるようになったんだけど、更新時もDNSレコード書き込む必要があって自動化するにはDNSレコード変更するフックスクリプトを自前で用意しろとか言われて、CloudflareのDNSサーバなら対応プラグインがあるらしいんだけどさすがにそこまではやってない。

 それにしても、またいろいろトラブって時間かかるだろなあと思ってたリプレース作業が一晩で済んだのには我ながらビックリ。最初に書いた下準備として、旧サーバ側の MovableType を最新版に上げてやってからデータをバックアップするのにかなり手間取ったが、逆にいうとそれだけだった。 MovableType っていい加減枯れてきてもいいはずなのにイマイチ良くならないよなあ。MT一つでサイト4つくらい出力してるんだけど、path の設定が全体で一つしかないので、ドメインが違うと内部から LWP でリクエストしてる部分がうまくいかなかったりする。イケてない。かといって WordPress はもっと使いたくない。
 今回一番ハマったのは、サイト単位でエクスポートしたものをインポートしようとしたら失敗したこと。それも500エラーで落ちるので原因がわからん。一番画像が多いサイトなのでインポートするファイルが20MB以上あるのが悪いのだろう。別の軽いサイトのデータで試したらいけたし。とりあえず Apache の LimitRequestBody を無制限にしたがやはり落ちる。てことは Perl 側の問題か。めんどくせえ。Apache のログを見ると Broken pipeError writing request body to script とあるのでパイプバッファが溢れてるとかだったら相当面倒だぞ、と思ってしまった。そこでエクスポート側に分割エクスポートというのがあるので、そちらでファイルサイズを小さくできれば回避できると思ったのだが、これがまたうまくいかない。分割するというオプションを選んでも分割されないのである。そもそもエクスポートのボタンを押すとアーカイブ処理が走った後にDLの保存ダイアログが開くというUIなので分割して複数ファイルの場合はどういう動きになるんだ? というのがわからん。マニュアルを見ても説明がない。もしかしてDLしたファイルが複数のアーカイブに分割できるのではないかと思ったがそんなことはなかったぜ。管理者ユーザでシステム > 設定 > システム情報 を見ると「バックアップデータの復元に必要となります。」というオプションモジュールが複数あって、XML::LibXML::SAX とか XML::SAX::Expat とかどれがどんな機能に使われてるのかわからんがとにかく全部入れれば分割機能も動くのか? と思って片っ端から入れていった。ここまでまたハマった。
 私はあまり Perl で大規模なアプリとか書いたことがないので、CPANモジュールのことなどもよくわかってない。 perl -MCPAN -e shell とかキモい! と思ってたら cpanm というコマンドがあるのを今回初めて知った。もっと早く言ってよ、これで楽勝じゃん、と思ったが話はそれで終わらない。依存関係で ExtUtils::MakeMaker を入れようとすると Data::Dumper に依存しており Data::Dumper は ExtUtils::MakeMaker に依存している、という循環依存みたいな関係になっていて入らないのである。Makefile.PL を修正しろ、とか言われてもわからんわ! 何のためのパッケージ管理ツールなんだ。結論からいうと普通に root で作業してたので環境変数で /root/ 以下にモジュールがインストールされる設定になってたのが原因だった。最初から別のユーザから sudo で実行してれば回避できてたらしい。ファック。
 で、モジュール全部入れても分割エクスポートとやらはできなかったのでさっくり諦めて(現在に至るも未解決である)、再度 Broken pipe を何とかするか、と思ったのだが、これも Apache から perl にリクエストを渡すところで失敗してるわけだからOSレベルの問題かな? と思うじゃないですか。これがPHPモジュールなら、アップロードファイルのサイズ超過問題というのは完全にFAQであって、上記 Apache の LimitRequestBody に加えてPHP側の設定で post_max_sizeupload_max_filesize を適切に設定する必要がある。ところが perl のCGIの場合は perl の実行時設定みたいなものは見当たらない。どうしたものか。結論を言うと(そればっか)、いろいろ検索してるうちにたまたま見つけたのだが、MovableType の CGIMaxUpload という設定だった。そのまんまじゃん! ていうか、ファイルアップロードのサイズ超過の場合は普通に「ファイルが大きすぎます」というエラーが出ると、MTのマニュアルにそのスクリーンショットまで載っているのに、なぜ Internal Server Error で落ちてるのか。おかしくね? ついでに言うとうちの環境の設定ファイルにはこの変数の記述そのものがなかった。つまり未指定=既定値が適用される。これもどうかと思う。バージョンアップや移行の際は設定ファイル mt-config.cgi はコピーすることになっているから、設定ファイルが古くて腐っているのかもしれない。最初に構築した時にちゃんとウィザードで生成したかどうか、もはや覚えてない。どう見ても最小限の項目しかないし。それにしても、これも MovableType における FAQ レベルのアレだろうと思うのだが、FAQにもないし、マニュアルにもないし、環境変数リファレンスには載ってたけどそんなのわかってて検索しない限り見つからないでしょうが! ちなみにこの CGIMaxUpload の値は、CGI.pm の CGI::POST_MAX という設定値にそのまま渡されてるだけだった。解決した直後は Qiita あたりに記事書こうかと思ったんだけど、冷静になるとただの環境設定一つだし書くほどのことじゃねえかなと。その情報が見つからないんだけどさ。ここに書いちゃったからいいか。

 あと MT6 までは「サイト」と「ブログ」が別枠で「サイトの中にブログがある」という構造だったのでそれをMT7に上げたら「空のサイトの下に子サイトとして本来のサイトがある」形になってしまい、子サイトを独立させたいのだがうまくいかない。記事レベルでエクスポートして新しいサイトにインポートすればよいのだが、その場合は画像などのアイテムが付いてこないので上げ直して、記事中に書いてあるポップアップページのURLなどと整合性を取らなければならない。とてもやってられん(以前一度やった)。このへんもいかにも不親切だ。

 やはりMTはオワコンなのだろうか。つーか、いまだに個人無償版のソースを落としてきて入れてる奴がいないだけかもしれない。もう普通のブログサービスみたいになった Movable Type.net の方がメインみたいだし、逆にサーバ構築まで込みになった MovableType for AWS というのも出た(まさに今回構築したものがパックになったやつ。しかしそれに月額料金払うのもなあ)。ざっと見た感じ個人無償版というのは既にジャパンでしか提供されてないっぽい(?)。今回ドハマりした時点でもうMTやめて自前でCMSから実装しようかなあと一瞬考えたんだけど、さすがにリリースがいつになるかわからんのでひとまずやめた。が、いずれ脱MTは考えておいたほうがよさそうである。

トラックバック(0)

コメントする