Archive for the ‘WordPress’ Category

Firefoxのアドオン(ContentBlockHelperとHTML Content Blocker)で切れるか試した。

テスト用動画 (テスト時は埋め込みプレーヤーにしていた)

↓ HTML Content BlockerでObjectをブロックしたら、表示されなくなった。

設定はPCの画面だが、スマフォでも同様の設定でブロックできる。設定の方法が分かりにくいが、種類のアイコンを押すとon/offし、下線がある状態でブロックされる。念のため、Mediaもブロックすることにした。

これで一安心か?

(3/16 21:06) 結局、どうしてか、実際にはうまく動かなかった(データ量が多かった)ので、今はFirefoxを使うこと自体を止めた。

 

※ページサイズを軽量化するため、動作確認後、動画の内容と個数を変えた。 → 動画の表示形態を変えた。 (3/16 21:06)

  •   0
  •   0

さっき、Wi-Fiでの画像取り込み機能の確認のついでに、何の気なしにスマフォのモバイルデータ量を見て驚いた。いつもは大体1日3MB以下なのに、どういう訳か、30MBくらいに激増していたのである。原因のアプリを調べたらOperaで、昼食の時に外でwebを見たら25MBくらい使っていた。それで、てっきりOperaが変なことをやるようになったのかと思って、(Wi-Fiで)Firefoxを試したが同様だった。Chromeでも同じだった。

良く考えてみたら、その時はこことリンクしている方のブログだけしか見なかったので、ページに問題がありそうだ。フォントをダウンロードしたのかと思ったが、このブログのスマフォドラレコの投稿に動画のリンクを貼っていた(動画の挿入するのにURLのペーストや「URLから挿入」を使うと、埋め込みプレイヤーになって便利なのでそうしていた)のを思い出した。調べたら、確かにその3つの動画は合計で21MBくらいだった。

それで、とりあえず、動画のリンクの出し方を普通のリンクにしてみた。それからキャッシュを削除してリロードしたところ、データ量は2MBくらいだったので、直ったはずだ。

極限までデータ量を削減していたつもりなのに、とんでもなく間抜けなことをしていた。。。 まったく油断も隙もない。

そして、今までモバイルで見られた方は(スピードもデータ量も)すごく重かったと思いますが、大変失礼しました。

 

PS. ブラウザにこういう大きいのを読まない設定があるといいのだが、なさそうだった。WordPressの出し方にも問題がありそうだ。テーマをいじって、モバイルの時はそういうのを出さないようにするのがいいのだろうが、面倒だ・・・

それに、自分のサイトは制限できるとしても、他人のサイトでも同様なことは起こるから、ブラウザなどでの対策が要りそうだ。と言っても、僕が余りにもケチっているだけで、実は、普通の人はだーれも気にしていないのかも知れないw

Firefoxのアドオンで埋め込み動画を切れることが分かったので、それを使うことにした。スマフォ版Firefoxは遅いが、データ量の削減の方が重要だ。

それから、PCでもスマフォでもOSを問わず同じアドオンが動くのは、Firefoxの大きなメリットだ。Chromeもスマフォでだってできると思うのだが、Googleの方針で無効にしているのか、できない構造なのか。 (3/11 6:03)

(3/16 21:01) ところが、今日外で使ったら、自分のブログを開くだけでもものすごく遅かったうえにモバイルデータを3MBも使った。前に家で見た、動画の入ったページを再度読もうとしたのだろうか。ただ、アドオンが効くはずなのにそれも駄目だったようだ。結局、Firefoxは使い物にならないことが分かったのでアンインストールし、Operaに戻した。

  •   1
  •   0

このブログでは、投稿後5年経過したものを自動で非表示にしている(以下、自動expire)。ただ、需要の点から一部の投稿(「MusicBeeの使い方」)は表示させたままにしたくなった。

今は自作のスクリプト(以下、expireスクリプト)で自動expireの処理をしているのだが、探すと自動expireするプラグインはいくつかあるから、それで手軽に実現できるなら乗り換えようと思った。が、どれも僕の要求をすべては満足できないことが分かった※。以下に要求と理由を示す。

  • 新規記事がデフォルトで自動expire対象になる。: 毎回設定するのは面倒だし、設定し忘れを防ぎたい。
  • (非表示になる日でなく)非表示までの期間(日数)が指定できる。: 日付を考えることなく、例えば「5年」という設定にしたい。
  • 自動expireした投稿にカテゴリやタグが付けられる。: 意図して非表示にしたものと、期限切れで非表示になったものを区別したい。
  • 可能なら、何もせずに既存の投稿が自動expire対象になる。: 最初に全部の既存の投稿に非表示までの期間を設定するのは手間(負荷が掛かる)なので。

※試したうちで一番要求に近かったプラグインは、Post ExpiratorとContent Schedulerだった。二つを合わせるといい感じなのだが。。。

それで、expireスクリプトを改良することにした。方法としては、自動expireさせたくない投稿にWordPressの管理画面で「印」(以下、保持マーク)を付けておき、expireスクリプトは、その保持マークがあるものは期限切れでも非表示にしないようにする(= 非表示対象にしない)のだ。

至ってシンプルで容易に実装できるのだが、すごく細かいところが気になった。どのような手段で保持マークを格納するかである。以下を検討した。

  • 「自動expireしない」というカテゴリを追加する。
  • 「自動expireしない」というタグを追加する。
  • 「自動expireしない」というカスタムフィールドと値を設定する。

カテゴリは一番使いやすいのだが、「自動expireしない」というのは属性なので、カテゴリ(投稿の分類・分野)にするにはふさわしくない気がした。実際には、非表示になっている投稿には期限切れになったことを示すカテゴリが付いているからそれと似たようなものなのだが、避けたい気がした(非表示になっている投稿の余計なカテゴリは、(その投稿自体が非表示なので、)外からは見えない点は異なる)。

タグもまあまあ使いやすいのだが、カテゴリ同様にふさわしくない気がする(ところで、タグとは何なんだろうか? 投稿のキーワード?)のと、投稿の下に表示されて今ひとつ美しくない(カテゴリも同様)。あと、一括して設定できるのに、一括して解除する方法がないのも不便だ(プラグインでもいいものがなかった)。

カスタムフィールドは、まさに属性を設定・格納する機能なので、「机上」では理想的で、投稿に見えないところもいいのだが、全然使いやすくない。プラグインを使わないと一括して設定・解除できないし、管理画面の投稿一覧に表示もできないし、検索もできない。投稿に見えないから、どうして残っているのかも分からない。

結構迷ったのだが、タグを使うことにした。投稿の下に表示される点は、見えることで残っている理由が分かるメリットはあるし、隠したくなった場合にはテーマを直せばどうにでもできるし、一括して解除できない点は、今のところ自動expireさせない投稿は少ないから、できなくても大きな問題ではない(もし多くなったら、スクリプトを作ればいい)と考えた。

なお、自動expireにしないタグは""と表示するようにした。これなら、一見意味不明(だけど、何となく重要そうなことが分かるw)で普通のタグ(文字列)とは区別できていいと思ったのだ(まあ、実際には僕はタグを使わないのだが)。本当は、(さまざまな案はあったものの、)金庫とか錠の絵文字が良かったのだが、(広く使える絵文字は)探しても見つからなかった。

自動expireにしないタグを付けた投稿の例

その機能を実装したので、明日テスト結果が出る。ちゃんと動いていたら、「MusicBeeの使い方」の各投稿にそのタグを付ければ、無事、「保全措置」が終わる。予定より随分前倒しだ(もっと先にすべきことはあるのだが、なかなか進まないw)。

(19:37 細かい修正・画像の追加)

 

PS. 余談だが、「MusicBeeの使い方」を電子書籍にすることも検討した。が、最新版のMusicBeeに対応していないことと(最新版はその次に対応しようかとも思った)、(自分の興味を除き、)電子書籍にすることにそれほど大きなメリットが感じられなかったのと、自分の仕事のプロモーションにするとしても、効果やその先が期待できなかったからである。もし効果があるのであれば、形態に関わらず既にあるはずだと思うのだ。

PS2. あとから気付いたのだが、「MusicBeeの使い方」だけならば、WordPressの「固定ページ」というものに変換すれば自動expireにはならない。ただ、ページのURLが変わってしまって見る方が不便だし(以前、国税庁が顰蹙をかっていた)、検索もリセットされてしまうので、そうしない方が良かっただろう。もちろん、従来のブログのURLからジャンプさせるようにもできるが、仕組みが複雑になって間違いが起こりやすいので得策ではない。 (2/4 6:53)

  •   0
  •   1

WordPress 5が出たので、とりあえず更新してみた。が、このサイトはテーマが古いせいか(調べたら、ベースはもう十年前のものだった・・・)、新しいエディタがうまく動かない。自動保存ですら「更新に失敗しました」と出るし、プレビューもできない。ダッシュボードのイベントにも同様の被害者の投稿が載っていたw ちなみに、仕事サイトは新しいテーマなので、大丈夫そうだ。

仕方ないので、クラシックエディタに戻した(プラグインで"Classic editor"で検索すれば出て来る)。まあ、新しいエディタをちょっと見た感じだと、「知的に進歩したWord」()みたいに却って面倒なだけの雰囲気なので、クラシックでいいやw

  •   0
  •   0

アクセス解析に使っているSlimstatに問題があるのでサポートに連絡したが、約1か月経っても回答がないので、悪い評価を付けた。その時に他のコメントを見たら、作者のとんでもない回答があってびっくりした。

コメント:

I requested an older version be an option after an upgrade. They decided to trot me out as a ‘naysayer’ in their Changelog. It shows a lack of concern for their users.

最後の回答 (太字にしたのは筆者):

Oh, and I would have expected that you stopped using Slimstat on your website, since you consider it such a poor product. Instead, I see that to this day you still (shamelessly) use it. Well, that in my book speaks to the quality of our product more than your own petty review. Thank you for being a loyal user anyway!

Best,
Jason.

(抄訳を載せようと思いましたが、馬鹿らしいので止めました。Google翻訳がなかなかいい感じです。)

上記回答のコピー:

Slimstat作者のすごい回答...

いくらなんでも、ユーザーに対してこの言い草はないだろう。更に、変更履歴にも揶揄する言葉を使うとは・・・ 余程のDQNなのだろうか。僕の問い合わせが無視されたのは当然だと納得した。Slimstat(随分改良した)を使って、このブログと仕事サイトへのアクセス状況に関していろいろ分かったから、あと少しで1か月経つので、そうしたら削除しよう。

そうか、僕も★1個を付けて使い続けていたら、同じように罵倒されるのか。早く消さなくちゃ。。。

 

PS. (後で知ったのだが)Slimstatは過去にセキュリティの問題を起こしていたし、作者はネットワークに関する知識があまりないようで、バグに関係するコードが酷いものだったので、使い続けるのは得策ではなさそうだ。

PS2. なんか、自分のことじゃないのに、読むだけで胸糞が悪くなる。。。英語でもこういう感情は伝わって来るものだな。

PS3. この作者は、元になったコメントを書いた人が相変わらずSlimstatを使っていると指摘しているが、どうやって調べたのだろうか? 偏執狂なのかスパイコードでも入れているのか、使う時には気付かなかったけど、結構怖い。

  •   0
  •   0

新しい仕事のプロモーションのために技術的な投稿を独立させる件が、とりえずできた。最後の案のように、個人用(ここ)と仕事用(新規)のホスト名・URLを別にし、逆引きホスト名を第3のもの(デフォルト)にした。当然ながら2つのIPアドレスは同じなので、どちらの要求も最終的には同じサーバに来るようになっており、サーバの入り口でURLのホスト名で分岐させて、表示するブログを分けている。

ちょっと残念だったのは、WordPressのマルチサイト機能が使えず(新規インストールでないからのように出ていたが、URLが別でも駄目っぽかった)、WordPressは新たにインストール・設定することになった。

ホスト名が違うので新たにSSL証明書を作ったり、久し振りにWordPressのインストール・設定をしたり(なぜか、今使っている版と違うところがあって、意外に手間取った)、気に入ったスタイルが全然なかったり、なぜか動かないプラグインがあったりして、結構時間が掛かった。とりあえず動くようになったが、果たしてこれで穴がないのか心配なので、少し様子をみることにする。

個人用と仕事用の切り分けは、以下の方針にしようと思う。

  • 今までの投稿は、ここにそのまま残す。ただ、特に転載したいものがあれば、修正して転載する。
  • 今後は、(純粋に)技術的な情報は新しい仕事用ブログに投稿する。

ここを定期的に読まれている方で、技術的な情報を楽しみにされている方はあまり居なさそうだから、新しい投稿は、仕事のプロモーション相手と、検索でたどりつくであろう不特定の方が読めればいいと思われるので、大きな問題はなさそうに思う。

ところが、新しいホストのドメインに無料のものを使ったら(この先の需要が不明なので、出費が惜しかったため)、FBのセキュリティ警告が出て貼れないことが分かり、一からやり直しの憂き目に・・・ (新たにドメインを取るとかして、WordPressのドメイン名を変えるだけではあるが、結構痛いなあ)

(10/28 21:31追記) いろいろ考えて、仕事用のドメインを取ることにした。すごくいろいろ考えて、いいドメイン名を考えついた。もちろん、はてなブログなどの無料サービスでも事足りるのだが、個人的な趣味とか、情報や使い勝手を一つにまとめたいからだ。

なお、ドメインを別にしても簡単に両方の存在はバレることが分かった。DNSの情報を見ても分からないが、IPアドレスでググれば2つのドメインが出て来るだろう。でも、まあ、そこまでして分かる人ってのは逆にこちらに関心を持ってくれていて、かつ、ある程度の知識がある人な訳で、そういう人にバレても特に問題はなく(ここと一緒なんだと触れ回る可能性は低そうだから)、逆にうれしいくらいな気がした(本当に? 良く分からん。まあ、何だっていいやw)。

(10/28 22:16追記) 昼間はいいドメイン名を考えついたと思っていたのだが、(決めてから時間が経ったせいか、)上を書いたあとで改めて見たら、余りにもおもしろくなくて(綺麗過ぎてインパクトに欠ける)却下し、その前に候補にしていたものが有力になった。が、明日になったらまた変わるかも知れない・・・

(10/29 20:43追記) その後二転三転して、結局、ドメイン名をローマ字で読むと(ちょっとインパクトがあって)覚えやすく、字面が綺麗過ぎないドメインにした。そんなことに随分時間を掛けたのは、我ながらしょうもないw

あと、WordPressは簡単にはドメインを変えられないようだったので、再インストールした。やっぱり、いくつか動かないプラグインがあったのが謎である。

(10/30 11:16追記) テーマを随分手直しして、なんとか見られるようになった。が、結局、このブログと似たようなデザインになってしまったw まあ、好みは変わらないね。あと、FaceBookはURLを貼った時にページの概略を保存するようで、それはいいのだが、IPアドレスをキーにしているらしく、別のURLなのに、このブログの画像が出てしまって参った。。。

(10/30 14:35追記) 上記の画像の問題は僕のミスだった。OGPという、サイトやページの概略情報を生成する時にサイトの画像を指定するのだが、その画像の指定が個人用のもののままだったため、それが出ていた。かなり昔に使い始めたために機能や使い方すら忘れていて、今回、別の用途(OGPの取得)に使おうとインストールしたら、誤動作した。

  •   2
  •   0

懸案だった、サーバの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