スモールビジネスのIT日誌

• (2021-02-22 07:01:32)

移行時の問題点

一週間くらい前に移行するかを検討した結果、当社の場合、特殊なDNS設定を行っているので、それが問題かなと判断した。

ところが、調べているうちに、ロリポップさんはいつの間にかSPF設定をしてくれていたことを発見した。

nslookup
set type=txt
ドメイン名
v=spf1 include:_spf.lolipop.jp ~all

それならば、SPF設定部分に関してはハイスピード移行で逆にロリポップのオリジナルDNSに戻せると思った。

ということで移行してみた。

準備：ネームサーバー設定を戻す

当社の場合、お名前.comのネームサーバーを使っていたので、これをロリポップに戻す。

ロリポップ ネームサーバー設定
uns01.lolipop.jp
uns02.lolipop.jp

お名前.com ネームサーバー設定
01.dnsv.jp
02.dnsv.jp
03.dnsv.jp
04.dnsv.jp

プラン変更の操作

スタンダードプランからハイスピードプランへの「プラン変更」は簡単だった。

管理画面で、プラン変更のボタンを押すだけでよい。

移行時の最終警告

プラン変更のボタンを押すと、最終確認のためのアラートがポップアップされる。

下記はアラートの要約で「 → 」の部分が当社の場合：

・PHP7.3および7.4のみ利用できる → OK

・共有SSLのアドレスは利用できなくなり、ロリポップ！ドメインがSSL化される → 共有SSLは使用していないので、OK

・独自ドメインの「http://独自ドメイン/」「http://www.独自ドメイン/」は同一ページになる → wwwのあるなしで、phpバージョンを変えたり、違うコンテンツにすることができたが今後不可、了解

・脆弱性対策(WAF)について、WAFは利用可だが、「検知・防御ログの確認」 と「.htaccess」での個別アクセス許可設定はできない → .htaccessによる個別アクセスはやっているかもしれないが、とりあえず無視

・Perlのバージョンが5.10から5.30へ変更。また「/usr/bin/perl」のパスが利用できなくなる → Perlで書いたCGIがある、まあ、しかし、Perlのバージョン間互換性の高さを考えれば心配いらないだろうと楽観

・Rubyのバージョンが2.6へ変わります。Ruby1.9および2.0は利用できなくなる → OK

・Pythonのバージョンが3.7へ変わります。Python2.7および3.4は利用できなくなる → OK


ボタンを押すと、すぐに管理画面の表示が少し変わる。

デザインと表示項目もちょっと違って見えた。

わずか4分で移行は終了した。

問題なく動作しているように見えた。

nslookupで確認

nslookupで、自分のドメインを打ち込むと、IPアドレスが表示されるが、確かに変化している。

nslookupコマンドの返答NSサーバは4分で移行していたが、ネット内の他のNSサーバでも全て変化しているわけでなかろうから、ネット全体に変化が行き渡るにはやはり、一日くらいかかるのだろう。

しかし、目先の移行はわずか4分で完了した。

案ずるより産むが易し、である。

サーバー番号が変更されない

若干戸惑ったことは管理画面に表示されている「サーバー番号」(おそらくWebサーバー)は変更されていなかったこと。

「usersxxx」のような表示から「spdxxx」のような感じの表示に変更されるはずだが・・

これはどういうことかと悩んでいたが、こちらは2時間程度でいつの間にか変更されていた。

メールサーバも変化した

あと管理画面から「メールサーバー番号」がしばらく消えたままになっていたが、翌日見るとこちらも表示されるようになっていたが、番号が変化していた。

もとよりWebサーバだけが変化すると予想していたので、これは予想外だった。

技術的な理由と言うより、運用上の理由だろう。

サーバー番号変更による影響は感じられない。

落とし穴：Perlではまる

予想外にはまったものがPerlのCGI。

当社ではPerlのフォームメールを一部使用している。

もう20年も前のプログラムだと思う。

Perlはバージョンが変わっても互換性がよく保たれているので、いままで手をかけることなく、動き続けてくれている。

ロリポップの移行情報ではPerlは5.10から5.30へバージョンアップするとか書いてあったが、問題なかろうと心配していなかった。

ところが、これではまった。

(1) Perlのパス「/usr/bin/perl」が使えなくなるということだったが、移行後も使えるではないか！・・気持ちが「使えない」という前提だったので「なぜ使えるのか？」と悩んだ。たんに使える状態をロリポップは残していると思われる。

(2) 「/usr/bin/perl」は使えないとし「/usr/local/bin/perl」を使うようアナウンスされているため、パスを変更したユーザーの中には使えなくなった人がいると思うわれるが、私もその一人

(3) パスを「/usr/bin/perl」に戻せば使えるはずだが、この状況が理解できなくて、いろいろはまった

「jcode.plを呼び出せません」

トラブルの現象は「jcode.plを呼び出せません」とか「502 Bad Gateway」とか言われる。

「jcode.plを呼び出せません」というエラーメッセージはうちのPerlプログラムの中に書かれているエラーで、「jcode.pl」が、Perl5.3に対応していないようだ。

解決策を求めて、サルのように検索した・・同じようにプラン変更でハングっている人々(Moval Typeユーザーさんたち)がいて、解決方法が書かれていた。

jcode.pl の682行目辺りのコードを次のように修正する(definedをトル)

684行目から「 defined」をトル
(修正前) &init_z2h_euc unless defined %z2h_euc;
(修正後) &init_z2h_euc unless %z2h_euc;

693行目から「 defined」をトル
(修正前) &init_z2h_sjis unless defined %z2h_sjis;
(修正後) &init_z2h_sjis unless %z2h_sjis;

このわずか2行の修正で動くではないか！ハッピーだった。

実際のPerlのバージョンは？

ロリポップで稼働しているPerlの実際のバージョンを知りたくて、sshで、自分のサーバにログインして調べてみた。

$ /usr/bin/perl -v
This is perl 5, version 16, subversion 3 (v5.16.3)

$ /usr/local/bin/perl -v
This is perl 5, version 30, subversion 3 (v5.30.3)

つまり、Perlプログラムの最初のパス指定で、
・「/usr/bin/perl」とすれば、Perl5.16が使えて、
・「/usr/local/bin/perl」とすれば、Perl5.30が使えるという理解でいいのか？

バージョンの調べ方はこのコマンドでよいのか自信がないが、Perl5.16が生きていると判断してよさそうと感じている。

中途半端なアナウンス

ロリポップさんは「Perl5.1は使えなくなる」と宣言しながら、使えるよう、こっそり残しているのはどうかと思う。

プラン変更で、CGIが使えなくなるユーザーの救済措置だろうということは見当が付く。

しかし、これは問題の先送りであり、逆に将来により大きなリスクを作ることになる。

プラン変更はユーザーもある程度覚悟してのぞむわけで、構成変更のよい機会だと思う。

下手な救済措置は長い目で見ればユーザーのためにならない気もする。

しかし、プラン変更でCGIが使えなくなり、パニくったユーザーが「元のプランに戻して欲しい」とか「何とかしてくれ」と泣きついてくる事例も起こりうるだろう。

そういう人々への対応よりも、こっそり救済措置を残しておいた方が楽だと判断したのかもしれない。

私だったら、両方のバージョンが使えることをアナウンスし、判断と対応はユーザーに任せるのがよいと思う。

jacode.plでuft-8が使えるようになった

jcode.plの修正で、いちおう動作するようになったが、「jacode.pl」も試してみた。

jacode.plはjcode.plの後継ライブラリの一つとかで、内容はよくわかないが、交換してみよ、とアドバイスするサイトもあったので、やってみた。

こちらも動作する、しかも、uft-8をサポートしなかったjcode.plに対して、サポートするとか。

今まで、PerlのフォームメールCGIを使うとき、htmlページも「Shift_JIS」にしていたが、今後は「uft-8」で統一できることが嬉しい。