Archive for the ‘WordPress’ Category

懸案だった、サーバのOS更新が無事終わった。更新後に再起動する時は、果たしてちゃんと立ち上がるか、少しドキドキしていた。結構大きいヤマが片付いて、一安心だ。あと4-5年は、こういった作業は不要だろう。

大きな問題はなかったのだが、いくつか気付いた点があったので、書いておく。

  • サーバには、なぜかdo-release-upgrade(OS更新スクリプト)がなかったが、パッケージupdate-manager-coreをインストールするだけで解決した。
  • テスト環境で起こった、do-release-upgradeの実行時に(Python(プログラミング言語)が)エラーになる問題は、なぜか起こらなかった。不思議だ。← 上に書いたように、do-release-upgradeを後からインストールしたからか?
  • なぜか、更新時にaptitude(ちょっと便利なパッケージ管理コマンド)が削除されたので、再度入れた。
  • テスト環境同様、更新後にrunlevel(OSの動作モードのようなもの)が5になっていたので、systemctlコマンドで2相当にしようとしたのだが、runlevelで見ると3になってしまった。でも、プロセス一覧を見ると、余計なものは動いていなかったので良しとした。おそらく、もうrunlevelも/etc/rc*.dの起動スクリプトも意味がないのだろう。だったら削除してほしい。。。
  • 作業で一番時間が掛かったのはバックアップで、圧縮後のサイズが9GBくらいになるせいか、1回80分くらい掛かった。更新自体は、最初は40分、2回目は20分くらいで終わった(それも結構長い気はする)。

そして、やっぱり、何をするにしても、特に、リスクのあることだったら、充分な準備をする価値はあると思った。

(23:47 若干加筆)

 

PS. みんなやっていることかも知れないけど、僕がコマンドライン(ターミナル)で作業をする時は、以下のようにしている。

  1. 実行するコマンドや順序を考えて(あるいは、どこかのページからコピーして)、どこか(例: Dropbox PaperやEvernote)に書く。
  2. それをターミナルにコピー・ペーストして実行する。

コマンドの例(PHPのバージョンを5から7に):
sudo aptitude remove php5
sudo aptitude install php php-cgi php-cli php-curl php-fpm php-gd php-intl php-mysql php-sqlite3 php-ftp php-net-socket php-sockets php-mbstring php-zip php-pdo-mysql php-exif php-apcu

こうすると、後で同じことや同様なことをするのが楽だし、何を実行するかあらかじめ考えるから、間違いが起こる可能性が減る。それに、上のような長大なコマンドだって、タイプミスせずに一発で打てる。更に、何をしたかの記録が残るから、後で何か問題が起こった場合にも、その時実行した処理に問題がなかったかを検討することができる。

また、トラブル対処などで、その場で(アドリブで?)コマンドを実行してしまった場合でも、なるべく、実行したコマンド文字列をコピーして、「**したら動いた」のように残すようにしている。

上のように書くと、「コマンドラインなんて古臭くて面倒だな」と思う人が多いかも知れないが、逆に便利だと思う。もし、GUIで上のPHPの例と同様な作業を記録するとしたら、「*を起動して、*を検索して、*と*と(中略)と*にチェックを入れて、インストールボタンを押す」なんて書くか、スクリーンショットを撮るしかないだろう。

前者の場合、オプションが多いと書くだけでも面倒なうえに、後日再実行しようとしてもコピー・ペーストは無理だから手間が多くなるし、後者の場合、手間に加えて、画像中の文字の検索は無理だから、後で調べるのが困難になるだろう(Evernoteは文字認識するから、検索できるかも知れない)。

  •   0
  •   0

ブログサーバーのOSを更新するため、2/26(日)に本サーバーを停めます。作業終了までは、断続的な動作になる可能性があります。

その日のうちに復帰する予定ですが、予期せぬ問題が起こった場合は、しばらく停まる可能性があります。

作業が終わりましたら、この投稿に追記してお知らせします。

よろしくお願いします。

2/26 10:56: 無事、OSの(2段階)更新が終わり、動作確認中です。ここまでの所要時間は約3時間でした。大きな問題はなかったです。

2/26 13時 動作確認が終わりました。正常運用に戻りました。

  •   0
  •   0

想定外のことがあって、しばらく休みになった。自宅謹慎とかではなくて、インフルエンザである。それで、懸案のブログサーバーの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

ブログサーバーのOS更新の件。

KUSANAGIについて、一番気になっている点(複数のブログ/httpサービスが実現できるのか)を調べたのだが、ドキュメントが貧弱過ぎて、確実なことは分からなかった。あと、全体をKUSANAGI固有の環境とか操作手順(コマンド)に変えてしまっているのが、(僕に言わせれば)何ともセンスが悪い。更に、セキュリティについては、元々良い訳ではなく、自分で設定を変更して向上させる必要があるようだった。しかも、そのレベルが低い。「(独自環境にしたんだから)そんなのデフォルトでやっとけよ」って感じだ。

そして、こんな(言い過ぎかも知れないが、いい加減な)会社に少なくとも10年も依存していいのかという疑念すら生じた。例えば、WordPressの更新がリアルタイムにでき(てい)るのだろうか? とか、数年で会社がなくなることはないのだろうか? などだ。そもそも、高速化しなくたって、何も問題はないのだ。

大体、あのキャラ(わざわざそんなのを作ったこと自体)も、起動時の大げさなバナーも全然気に入らない!

そんな訳で、僕の体温に反比例して、KUSANAGI熱は一気に醒めてしまった。

CentOSについても、10年のサポート期間は魅力だが、(今使っているOSの)5年だって大きな問題はないと思える。5年に1度、ちょっと手間を掛ければいいだけだ。逆に、10年も経つと、次のOSはものすごく変わっていて、更新は更に大変ではないだろうか。仕事でCentOSを使う可能性はあるが、そんなの会社でやれば充分で、自宅でまで苦労したくない。OSなんて、(WindowsやMacのなどを除いて)何だって良くて、ちゃんと動けばいいのだ。

という訳で、今は、今使っているOSの最新版に更新する方向に傾きつつある。

  •   0
  •   0

このブログサーバーのOSは、かなり古い。まだサポート期間内だが、もうすぐ切れる。それで、そろそろ最新版に更新しようかと思っている。それで、昨日、手順や起こりうる問題などを考えたり検索したりしていたら、思わぬ新機軸が見つかり、それまでの考えとは全く違う方向に行く(暫定の)結論になった。

まず、コンセプトや目指すところは、それまでの「現状維持」(単に今のOSを更新する)から、以下になった。

  • 管理の手間を減らす。
    • 毎月のようにPHPを更新(ソースからビルド)しているが、もう止めたくなった。
    • Webサーバの更新も、頻度は低いが、やっぱり面倒。
  • ブログの高速化 : 遅くても問題はないが、速い方が気持ちいい。

手段としてはKUSANAGIというシステムに移行する。

実際には、使っているサーバー会社のサポートするOSのページを見たら、KUSANAGIもサポートしているのを知り、それ(以前見たことがあるのだが)を使えばブログ(WordPress)を劇的に高速化できそうなことに気付いた。しかも、WordPressの環境が最初から全部構築されているので、PHPやwebサーバーなどの更新は自動で行われそうだし(そうでなくても更新のコマンドを実行するだけだろう)、Let's encryptのSSL証明書のサポートも入っているようなので、管理の手間がかなり減りそうなことが分かった。

KUSANAGIでは、副次的ではあるが、セキュリティの強化も期待できそうだ(少なくとも今よりは良くなりそうだし、自分でセキュリティに配慮する負担は減るだろう)。更に、新しいLinuxの勉強もできそうだ(というか、しなくてはならない)。というのは、サーバー会社が提供するKUSANAGIはCentOSで動くのだが、(それは今と同じLinuxではあるが、)系統が違うので、管理方法や操作が若干異なる。でも、仕事で使いそうだし、覚えておいて損はないと思う。また、CentOSはサポート期間が10年と長いのが魅力的だ(今のは5年程度)。

次に、移行手順だが、今使っているサーバーをいきなりKUSANAGIに変えることは無理だし危険だし苦労が多いので、そうはせず、「軟着陸」させる。

実際には、今のOSを更新するだけと考えていた時から、直接更新せずに一旦別のサーバーを借りて、そこで動作確認してから移行することを考えていた。それで、サーバー会社のページでKUSANAGIを見つけたのである。

移行手順は以下を考えている。

  1. 移行先のサーバーを借りる。(OS=KUSANAGIで設定)
  2. 新サーバーに、仮のドメイン名を付ける。(サーバー会社が提供するのが使える?)
  3. 新サーバーに、今のサーバーのコンテンツなどをコピーする。
  4. しばらく(3か月以内を目標)、動作確認と調整を行う。
  5. 新旧サーバーの切り替え
    1. 新旧サーバーのwebサーバーを停止する。
    2. 新サーバーのコンテンツを最新にする。
    3. 新サーバーのドメイン名を今のに変える。
    4. 新サーバーのwebサーバーを起動する。
  6. 仮のドメイン名の契約を終了する。
  7. 新サーバーの安定動作を確認後(3か月程度)、旧サーバーの契約を終了する。

移行期間は長くて半年程度と考えているので、コストは1万円未満(新旧サーバーの重複期間の使用料+仮ドメイン名の費用)だろう。

懸念事項は以下である。

  • KUSANAGIに致命的な問題がないか? → 出てからしばらく経っているので、大丈夫では?
  • いつまでKUSANAGIが続くか? → 終わったらまた考える。どうせ、後継が出てくるだろう。
  • 今使っているWordPressの機能・設定・プラグインが全部動くか。→ 駄目な時は代替を探す。
  • PHPが高速版(HHVM)に置き換わるが、他のPHPのプログラムが問題なく動くか。→ 動作確認して、調整する。それでも駄目なら、HHVMを使わない。
  • 自分で追加した機能がうまく移行できるか。→ 同等のものがKUSANAGIにあればそれを使い、なければ自分のを動かす。
  • HHVMがFacebook製なのが気に入らない。→ MSよりはマシなので、我慢する。
  • "KUSANAGI"とか"HHVM" (Hip Hop VM)とか、名前が気に入らない。KUSANAGIのキャラも気に入らない。→ 我慢する。
  •   0
  •   1

先日、ボロボロになっているのに気付いたヘッドフォン(DENON AH-D5000)のイヤーパッドだが、結局、PALADIAという純正でない物(約1300円)を注文し、昨日届いた。口コミに「届くのが遅い」と書いてあったので、年内に届くかなと思っていたのだが、予定より2日も早く、中国から届いた。

外見は、口コミどおりパッドが薄い。あと、やっぱり、ちょっとしょぼい。でも、「良く見れば」とか「何となく」のレベルだし、値段相応なので、問題はない。ただ、手順の説明書などが何もなかったので、ちょっと心細いものはあった。が、webを探せば、交換について書いたページは多い。

いつものように、不器用な僕は交換に苦労した。なかなかパッドが外れなかった。パッドを本体に止めている白い板の爪が堅くて、回してもパッドばかり回って板は回らず、外れなかった。「軽く回すと簡単に外れる」と書いてあるページがあったが、個体差があるのかも知れない。

そのままでは板が回らないし作業しにくいので、まず、古いパッドを引っ張って外し、裸になった板(→ 写真3枚目)の爪の辺りを細いマイナスドライバーで押した。こういう場合、力を入れ過ぎて指を怪我をしたり、物を壊したりするのが通例なので、慎重にゆっくりやったら、外れた。が、やっぱり、ちょっと失敗した。ドライバーを強く押し過ぎたせいか、板と本体の隙間にドライバーが入ってしまい、板の爪付近が割れ、本体にも傷が付いた。でも、一箇所だけだし、見えない部分なので、実害はない。そして、良くあることだが、なぜか、2個目を外すのには余り苦労しなかった。学習の効果なのだろうか?

新しいパッドは若干小さめで、板を嵌めるマチも狭くて、嵌めるのにちょっと手間取ったが、なんとかなった。本体にも問題なく付いて、交換が終わった。苦労したとはいえ、約40分くらいで終わった。回転を良くするためか、白い板に油が付いていたので、指がベトベト、かつ、表皮のかけらがくっついて汚くなった。

外見は、どうしてか、わずかな違和感があるのだが、知らない人には純正と言っても全く分からないと思う。ただ、ちょっと聴いた感じだが、若干、音量が下がって音も軽くなった気がする。低音が減ったのかも知れない。でも、僕はヘッドフォンは補助的な物と思っているので、問題ない。

交換してから気付いたのだが、ヘッドバンド(というのか?)部の表皮の剥がれや頭脂汚れもひどいので、実は裁縫をする必要があったのかも知れない。

 

PS. いつの間にか、WordPressが便利になっていた。digiKamで画像ファイルに付けたコメント(CommentかImageDescriptionかUserCommentかNotesかDescriptionかその他か)が、自動で画像下のコメント(キャプション)になる。これからは、どんどんコメントを入れたくなった。ただ、digiKamはコメントをさまざまなフィールド(少なくとも上記の全部)に入れまくるので、それはいかがなものかと思った。

どのフィールドにコメントを入れるかは、digiKamの設定で変えられるようだ。デフォルトだと7つのフィールドに対して読み書きするようになっている。同様に、評価(★)とタグも選択できる。さて、WordPressはどこを見ているのか? 「面倒だから、このままでいいか」という悪魔のささやきが聞こえたw 実際、画像のサイズに対して、コメントやタグのサイズなんてたかが知れているので、重複して保存したところで大きな問題ではない。(18:57)

  •   0
  •   2

実行速度が2倍以上高速になるというので、PHP(このブログを動かしているスクリプト言語)のバージョンを5から7に(なぜか6はない)上げてみた。

以前から興味はあったのだが、同じくPHPを使うカレンダーやアドレス帳のサーバソフトが対応していないという情報があって二の足を踏んでいた。が、近頃は検索しても余り出て来ないので、きっと対応できたのだろうと思って、試してみた。あと、PHP 7.1がベータになっているので、7.0系は安定したと思われたのも、きっかけけだった。更に、今日は元々PHP(元のバージョン)の更新をしようと思っていたのと、暇だったというのもある。

結果としては、残念ながら、体感速度は変わらなかった。そうであれば、それ以上調べても意味がないので、(面倒だし)正確な数値は測定していない。

移行作業ではいろいろな問題が起こった。

まず、PHP自体が起動しなかった。APCuというモジュール(apcu.so)がロードできなかった。PHP 7になって今までのものが使えなくなったようなので、ダウンロードして更新した。それから、設定ファイル(php.ini)中のコメントの仕様が変わったせいか、"#"(自分でも意識せずに使っていた)がエラー(もしかして単なる警告だったかも)になっていたので、";"に直したら、動いた。

それで、カレンダーやアドレス帳については全く問題なく動いたのだが、ブログがうまく動かずに焦った。

ブログにアクセスすると、「DBに接続できない」というエラーになった。検索したら、PHPにDB関連の設定(mysqli.default_socket)が要るようになったらしく、その設定を追加したらそのエラーは消えた。これは、PHP 7でmysqlモジュールが削除されたせいかも知れない。

ブログには繋がったのだが、今度は、僕の作った追加モジュールがエラーを出した。その中で、APCというキャッシュのモジュールを使っていたのだが、それが数年前にAPCuに変わり、それでも同じ関数名で使えていたのだが、PHP 7では駄目になったようだ。検索するとそんなことはないのだが、僕の環境では駄目だった。互換モジュール(apcu_bc)を入れようとしたのだが、ビルドでエラーになってしまった。

それ以上調べるのも面倒なので、僕のモジュールをAPCuに対応させることにした。それはとても簡単で、関数名の先頭をapc_からapcu_に変えるだけで良かった。ただ、コマンドラインのプログラムでテストすると、なぜか動かず、手こずった。調べたら、PHPの設定で、デフォルトではコマンドラインではAPCuが動かないせいだった。どうしてそうなっているのかは分からないが、そこを変更して試したら、テストプログラムが動き、めでたくブログも動くようになった。

本来は、まずは移行に関する資料などを熟読して検討すべきだったのだろうが、趣味のサイトなので、まあ動けばいいってことにした。それに、これから読むしw

という訳で、何か変な挙動を見掛けられましたら、お知らせ下さい。

その後、Wordpressのウィジェット管理ページがうまく動かないことが分かったので、5に戻した。いろいろあるものだな。。。(9/4 20:20)

 

PS. PHP 7にはいろいろ新機能があるようだが、僕は余り積極的ではない。まず、使っているいろいろな環境の処理系は全然7ではないから、覚えても使えないし、そもそもPHPの機能をフルに使っている訳ではないし、ちょっとコードが短くなる程度のことは別にどうだっていいからだ。

  •   0
  •   0

Vivaldiブラウザを試し始めてから、ずっと不満に思っていたことの一つは、webページをPDF化するアドオンがちゃんと動かないことだった(記録のために、毎週、このブログをPDF化して保存しているので、そのために必要なのだ)。1個動くのを見つけたのだが、実は有料で、お金を払わないと広告が出ることに気付いた。

ブラウザの印刷(出力=PDF)でもできるはずなのだが、どうしても、背景色や文字の色が出ず、白黒になってしまう。検索すると、CSSに"-webkit-print-color-adjust: exact;"を入れると出ると書いてあるのだが、そうしても駄目だった。

それでCSSの修正を試行錯誤していて、ふと気付いた。「この印刷用CSSには、そもそも色指定がないじゃん!」と。

そう。このサイトを作った時に、画面表示用CSSはいろいろ調整したのだが、印刷用は「印刷することはまずないだろう」と、オリジナル(Evanescence)のをほとんどそのまま使ったのだが、それは白黒印刷しか考えていなかったようだ。

とりあえず、画面表示用のを印刷用にそのままコピペして、「背景のグラフィック」をONにしてPDF印刷してみたら、ばっちり色が出た(上のCSSの追加設定すら不要だった)。追って細かい確認や調整をしよう。

それにしても不思議なのは、PDFでの印刷で事足りるのに、ページをPDF化するアドオンがなぜ必要なのかだ。まあいいか。僕のように間抜けな人用なのだろう。

PS. 印刷だとリンクのURLが保存されないことが分かった。ちょっと考えれば当然ではあるが、悩ましい。(11:48)

やはり、リンクが残っていた方がいいので、他のPDF化アドオンがちゃんと動くまでは、Firefoxを併用することにした。買い物などでも、Vivaldiには若干問題があるので、まあ仕方ない。そもそも、Vivaldiはβ以前なのだから、ほとんど普通に使えていること自体がすごいのだ。(15:46)

  •   0
  •   0

時間があったので、ブログの細かい記述を変更。大勢に影響はない。こういう、ちまちましたことも結構好きだ。

  •   0
  •   0

確認のために、ちょっとテーマを変えて戻したら、フォントサイズがおかしくなってしまった。訳が分からない。。。

直った。同名の古いテーマを使ってしまったらしい。焦った。(22:16)

  •   0
  •   0