想定外のことがあって、しばらく休みになった。自宅謹慎とかではなくて、インフルエンザである。それで、懸案のブログサーバーのOS更新を試してみた。KUSANAGIを使わないのであれば、確認・移行用に新たなサーバー(VPS)を借りなくても、自分のPCに仮想環境を作って、無料でいくらでも試せることに気付いたのだ(KUSANAGIも仮想マシンを配布しているのかも知れないけど、使う気がないので、パスした)。

試した結果は、いくつか気になる点や注意事項はあるものの、現行のサーバーをインプレースで(「上書き」)更新しても大丈夫そうだった。今日1日(実質半日)で、仮想環境で、古かったOSを最新版に更新でき、テスト用ブログサーバーが動いた。しかも、PHPを7.0にしたせいか、何もしなくても4倍くらい速くなった。

最も気になるのは、「ゴミ」である。今使っているOSは古いため、最新版に更新するには、2回(2段階で)更新する必要がある。その過程でゴミが残って(あるいは、不足が生じて)動作に悪影響がないかと、今までの数年間の運用や試行錯誤でさまざまなゴミが溜まっているだろうから、その影響も気になる。

もしゴミをなくしたいなら、新しいサーバを借りて、最初からセットアップするべきだが、それはかなりの手間だ。

まあ、趣味だし、とりあえず動いたから、上書き更新でもいいような気がする(が、今までの経験上、そうやって手を抜くと、あとで思わぬトラブルが勃発して慌てるのだが)。それならほとんど時間が掛からないでできるし、トラブル対処の勘所も分かったので、もう少し考えてみよう。

以下は、更新に当たって起こったできごとや注意事項などのメモである。OS名を明記しないので、余り参考にならないかも知れない(が、よく読めば、自明なはずである)。

  • OSの更新は、基本的に、do-release-upgradeコマンドでできる(これは、ご丁寧にも、古い版のOSにログインした時に表示されたので、何も調べなくても分かった)。ただし、更新が失敗する場合やパッケージがあった。
    • 1つ前の版から最新にする時、do-release-upgradeが実行できなかった。これは、pythonが古くてaptというモジュールがなかったからのようで、一旦削除してインストールしなおしたら、動くするようになった。
    • mysqlのDBのディレクトリ名(/var/lib/mysql/*)に異常なものがあって、更新に失敗した。使っていないものだったので、そのディレクトリを削除したら成功した。
  • 現行サーバーの環境をコピーするため、ディスクの内容を新しい仮想環境に上書きしたのだが、ファイルの選択がいい加減だったので、/etc/fstabまで上書きしてしまい、ディスクのマウントがおかしくなってしまった。まあ、当たり前のことであるが、/が読み出しのみでマウントされて、fstabの修正もできなかったので、手で読み書き可にマウントしなおして編集できるようにした。
  • PHPはパッケージ版を使ってみた。すると、php-fpmはなぜか/etc/rc?.dから起動できず、プログラムの場所も分からず、再起動するにはOSを再起動しないといけなくて、面倒だった。良く調べたら、場所は/usr/sbin/php-fpm7.0だった。また、なぜか、/etc/init.d/php7.0-fpm startなら起動した。起動スクリプトの仕様が変わったようだが、他にも同様なことがあるので、要調査だ。
  • パッケージ版のPHPは、現在ビルド時に指定している、さまざまなモジュールをapt-getに"php-curl"のように指定して追加すれば、今使っているものと同等の機能のものがインストールできた。
  • 当然ながら、パッケージ版のPHPに移行するには、元々の(自分でビルドした)PHP関連コマンドを削除しないと、誤動作する。
  • ブログ(WordPress)を正しく動作させるためには、仮想環境にドメイン名を付け、それに合わせて、webサーバの設定とWordPressの設定(設定ファイルと「サイトアドレス」)を変える必要があった。webサーバの設定はもう少し綺麗にしたいが、仕様が難解で難しい。。。
  • ブログでは、以前PHP 7を試した時に生じた問題(ウィジェットの設定画面がおかしい)が再発した。しかし、検索しても同様の問題はないので、更に調べたら、自作のウィジェットが原因だった。一部の標準ウィジェットをカスタマイズするため、コピー・変更して使っていたのだが、その使い方がPHP 7に互換でなかったようだ。これはフックにできないだろうか。
  • PHP 7.0にしたら、ブログの表示は約4倍速になった。ただし、正規表現での検索は10倍くらい遅くなった。自作したものなので、効率の悪い点がありそうだ。また、ページを最初に表示する時は遅い。これは、PHP 7.0の動作(JITやキャッシュ?)に関係しているのかも知れない。
  • もう一つのブログや他のwebサービスも、問題なく動いている感じだ。
  • カレンダー・アドレス帳サーバーは、最初は予想外のエラー(HTTP 400)が出て動かず、ちょっと苦労したが、何とかなった。設定の、「信頼するドメイン」に、サーバー自身のドメインを追加する必要があるようだ。それがどういう意味なのか(自分すら信頼できないのか??)、今ひとつ分からない。
  • パッケージ版のwebサーバーも試したが、ログやSSL証明書の場所の設定を若干修正する程度で問題なく動いた。僕の用途では、最小構成で充分なようなので、得した気分だ。(20:47)
  • パッケージ版のPHPのバージョンは最新ではなく、約3か月遅れで、辛うじて許せるレベルだ。一方、webサーバーは、約10か月遅れなので、ちょっと古い感じだ。今までwebサーバーの問題を見たことがないから古くてもいいが、心配なのは、セキュリティ面だ。
  • https(SSL)の証明書は、現行サーバからコピーしたものではブラウザに文句を言われたが、sshの鍵は、コピーしたものがそのまま使えた。確かにそういうものだが、本当にそれでいいのかと思う・・・
  • OSを仮想環境にインストールしたせいか、runlevelが5(デスクトップ用らしい)になっていて、時々文句を言われた。直し方は不明だが、とりあえず動いたし、実環境は2なので、問題ない。

(2/16 17:21追記) その後、準備や調査をした結果を書く。

  • php-fpmが/etc/rc?.dから起動できなかった問題は、Linuxの起動時のプログラム起動システムが(、さまざまなものを経て、)今は、systemdというものに変わっているためだった。ただ、昔ながらの起動スクリプト(/etc/init.d/*や/etc/rc?.d/*)も残っているので、それを使ったら騙され失敗した。何とも中途半端だ。だから、php-fpmは、正しくはsystemctlコマンドで起動するべきだったのだ。だが、これもいつまで続くか分からないし、手で自作のサーバープログラムを追加するのは面倒そうなので、なかなか覚える気がしない。
  • ランレベルも同様で、昔は設定ファイル(/etc/inittab)があったのに、今はなくなっていて、"systemctl set-default multi-user"などのようにして変更するそうなので、分かる訳がなかった。
  • なかなか苦労して、webサーバの設定をかなり綺麗に簡素にでき、行数を半分以下にできた。今までは、文法が難解なので、いろいろなサイトのコピーをベースにして、おそるおそるいじっていたため、ゴミが多かったのだが、今回は観念して腰を据えて、気合を入れて文法を理解しつつ抜本的に作りなおしたので、「どうしてこうなんだろう?」という箇所はなくなり、ゴミもほぼ0になった。また、非推奨の処理もなくせた。でも、これがサーバの高速化に繋がるかと言えばそうでもない。だが、保守性の向上とかセキュリティホールができにくくなることには繋がる。以下に新旧の行数の比較を載せる。
    • 現行: 705行 (2ファイル)
    • 改良後: 310行 (4ファイル)
  • 自作のウィジェットがPHP 7.0でエラーになる問題も対処できた。どういう訳か、作成当時にエラーになったので止めていた方法(元になるウィジェットのサブクラスを作る)がすんなり通ったので、PHP 7.0でのエラーは起こらなくなり、コピーの部分もほとんどなくなった。不思議なことに、それが今のPHP 5でも通ったので、当時のPHP 5にバグがあったのか、僕の思い込みだったのか不明だ。

そんな訳で、OS更新までに残る作業は、作り直したwebサーバの設定の動作確認程度である。これが、(手でやる場合には)拒否・通過設定しているURLをブラウザで1個1個開いていくという、なかなか手間が掛かるうえに間違いやすい作業なのだが、設定修正のたびに繰り返すのは嫌なので、確認用スクリプトを作って自動化したいと思っている。

(2/18 17:02追記) その後、サーバのセキュリティ関連設定確認用スクリプトを作って確認し、問題を見付けて修正して、問題なくなったことが分かったのだが、その後でブログを見たら、みごとに崩れていて、とても参った。「完璧な設定」に見えたのは、どうも、サーバの各種プログラムの不思議な動作(いちいち停めないと駄目だったり、OSの再起動すら要る場合がある)やブラウザのキャッシュによって作られた「幻」だったようだ。

今でも、「修正できたと思ったら、実は駄目だった」の繰り返しである。このwebサーバは、なかなか一筋縄に行かないようだ。

それから、その設定確認用スクリプトを作っている時にも、大いにはまった。スクリプトは、準備として、外部(web)からアクセスできない場所にファイルを作る(それをアクセスしても、サーバの設定でブロックされることを確認する)のだが、2回目に実行すると、必ずサーバにssh接続ができなくなってしまう。いろいろな原因を疑って一つずつ潰して行ったのだが、原因が分からなかった。そして、試してみたら、現行のサーバでも同じ現象が起こった。それで、かなり悩んで、ふと、(自分で設定した)IPフィルタ(簡易なファイアウォール)かも知れないと思って調べたら、本当にそうだった。

ブログサーバを立ち上げた頃に、sshを頻繁に繰り返す攻撃を無効化する設定を、どこからか見付けて入れていたのだ。その後、そんな設定をしたなんてことはすっかり忘れていたのだが、今回の設定確認用スクリプトは、確認用ファイルを作るために、まさに頻繁にssh接続するので、すぐに限界(例: N回/時間)に達してしまっていた。OS更新テスト用の仮想環境も、ブログサーバの内容をほぼまるごとコピーしたので、設定が有効になっていたのだ。全くあてにしていなかったのにちゃんと動いてくれてうれしかった反面、思わぬ落とし穴にどうしたものかと思った。

一時的に無効にすることは可能だが、何度もやるうちに戻し忘れるのが嫌だ。それで、いろいろ考えて、確認用ファイルの作成と削除は、1ファイルごとにssh接続せず、まとめて1回のsshで実行するようにした。その(長々とした)コマンドを作るのがかなりの手間だったが、とりあえず動いて、問題は起こりにくくなった。めでたし、なのか??

(2/19 8:30追記) 大変な苦労の末、サーバの設定の改良が終わった。仮想環境では再起動しても壊れなかったので、おそらく大丈夫だろう。そして、今朝、実サーバにも適用した。いくつか問題が見つかったので、修正した。今のこれが幻でないことを祈るばかりである。

ちょっと残念なのは、いくつか、例外的な「汚い」処理が必要だったことだ。まあ、今の僕の技量ではそこまでってことだ。でも、今までの設定に比べたら、随分まともになったと思う。そんな訳で、設定の行数は361行に増えた。

  •   0
  •   0

コメントを書く

名前    

メール 

URL