Archive for the ‘WordPress’ Category

苦節4か月。どうにか新しいアンプBA3886が完成した。あとは もう本当に些細なことしか残っていない。それで、まとめとして、作ったアンプの構成・仕様・特性に関する資料(カタログとか詳しい紹介資料的なもの)を書いたので載せる。

なお、Markdownから本文を生成した都合で図や写真をクリックしても拡大できないが、(元の画像は大きいので、)ブラウザの右クリックメニューで大きく表示できるはずだ。

→ 「何とか」した。画像をクリックすると、オリジナルサイズの画像が表示される。 (6/22 14:08)

また、あとで特性に関するコメント(他製品との比較も?)や技術的でない余談も書きたい。


ステレオ オーディオアンプ BA3886の構成・仕様・特性

2021/6/19-23 Butty

構成

BA3886は以下の各部よりなる。

  • アンプ部
    • アンプ本体
      • アンプIC LM3886により入力信号を増幅して、スピーカー出力に出す。
    • DCサーボ部
      • アンプのDC出力(オフセット)をカットする。
  • スピーカー保護部
    • アンプの出力に大きなDCオフセットを検出した時に、アンプの電源をoffにしてミュートし、スピーカーを保護する。
  • 電源部
    • 外部の元電源(ACアダプタ)を本機が使用する電源(±15V)に変換して供給する。
    • リップルフィルタにより、電源に含まれる雑音(主に高周波)を低減する。

全体的な構成図

BA3886 構成図 2021-6-21.png

スピーカー保護機能の構成図

BA3886 SP保護 構成図 2021-6-21.png

スピーカー保護部と電源部の回路図

BA3886 SP prot 20210604.png

全体的な仕様・特性

入出力

  • ライン入力(非平衡, 入力インピーダンス: 100kΩ)
    • RCAジャックx2 (白: L. 赤: R)
  • スピーカー出力(4-16Ω)
    • 丸・Y端子用端子(5.8Φ) x2(+, -) x2組(L, R)
    • 8Ωで特性の測定と動作確認をした。
  • 温度センサ出力
    • ミニジャックx1
      • RチャネルのLM3886付近に設置したサーミスタの出力
      • 温湿度計: タニタ TT-585 (改)に接続して使用する。

電源

  • DC 10-35V, 約31W (約0.89-3.1A)
    • 12, 24Vで動作確認した。
  • コネクタ: XHコネクタ 4ピンジャック
    • ピン1, 4を使用

スイッチ類

  • 電源スイッチ
  • ミュート ラッチスイッチ
    • スピーカー保護基板上のスライドスイッチ
    • Onにすると、しきい値付近のオフセットでの断続的ミュートを防止することが可能。 (通常はon)
  • スピーカー保護機能チェックボタン (L+, L-, R+, R-)
    • スピーカー保護基板上のプッシュスイッチ (青: L+, 白: L-, 赤: R+, 黒: R-)
    • 押すとスピーカー保護回路のセンス入力にオフセットが入力されてミュートする。

保護機能など

  • アンプIC(LM3886)内蔵の保護機能
    • 電源: 低電圧・過電圧
    • SPiKe(過負荷など?)
    • 過熱
  • DCサーボ機能
    • アンプのDC出力(オフセット)をカットする。
  • 出力オフセット検出でのミュート機能
    • 何らかのトラブルにより、スピーカー端子に しきい値以上のDC出力を検出した場合、アンプの電源をoffにして音を停める。
    • しきい値付近のオフセットでの断続的ミュートを防止することが可能。 (ミュート ラッチスイッチで切り替え)
    • チェックボタン(L+, L-, R+, R-)で保護機能をテスト可能

消費電力

  • アイドル(無音)時, 常用出力(約11mW)時: 約4.6W
  • 出力: 約0.8W(片チャネル)時: 約8W
  • 最大出力(約9.6Wx2)時: 約31W

大きさ・重さ

約14x14x7cm (突起物を含まず), 約530g (付属品を含まず)

外観

色・材質

  • 本体: 黒色
    • 材質
      • カバー(メッシュ): PP
      • ケース: PC+ABS
      • 滑り止め(底面): ハネナイト(NBR)
  • ランプ
    • 電源ランプ: 薄オレンジ色
    • ミュート通知ランプ: 赤色

正面より

DSC_3895_2964489332_v2.JPG

内部

DSC_3899_2964489332_v2.JPG

付属品

付属品一式

DSC_3911_2964489332_v2.JPG

(写真の左上から右下に)

  • 特性測定用アダプタ
    • 出力端子: RCAジャックx2
    • 内部接続コネクタ: XH 4ピン プラグ, ジャック 各1
  • ランプ光拡散キャップ (通常版)
  • 特性測定用負荷抵抗(8Ω)x2
  • 消費電流測定用アダプタ(抵抗 1Ω)
    • コネクタ: XH 4ピン プラグ, ジャック 各1
    • 電流(電圧)測定用ミノムシクリップ x2
  • 温度測定用温湿度計 (タニタ TT-585 (改))
  • 特性測定用アッテネータ
    • ゲイン: -16.5dB
    • コネクタ: 両端ピンプラグx2
  • テスト用スピーカー
  • ミュートのしきい値測定用オフセット生成用ボリューム (10kΩ B)
  • ミュート確認用電池ホルダー (単3x1)
  • リップルフィルタバイパス用ショートプラグ

アンプ部の特性・仕様

以下、特に記載のない限り、値は実測値。

最大許容入力(振幅)

  • 仕様: 約1V
  • 実測値: 約0.93V (片チャネル時)
    • 出力がクリップしない振幅

最大出力

  • 仕様: 約4Wx2チャネル
  • 実測
    • 片チャネル出力時: 約11W (THD: 0.0021%@1kHz)
    • 両チャネル時: 約9.6Wx2 (THD: 0.0021%@1kHz)

コメント

仕様と実測値の乖離が大きいが、短時間は上の出力を出せるものの、連続出力できるのは仕様どおり4Wx2程度が上限と考えられる。

ゲイン

信号発生器で生成した1kHz, -30dBFSの正弦波を入力し、出力との比を求めた。

  • 仕様: 10倍 (20dB)
  • 実測: 約11倍 (約21dB)

出力オフセット

入力をショートした時の出力のDC電圧を測定した。

LRともに1mV以下 (使用した機器では測定不可)

残留雑音・SN比

入力をショートして出力を測定した。

残留雑音

約17μV (A)

  • L: 14.6μV (A)
  • R: 16.6μV (A)
残留雑音の周波数特性

BA3886 Final check RN cmp 1.png

  • L: 青, R: 赤
  • 灰色: サウンドカードのみ

SN比 (1W出力時)

約105dB (A)

  • L: 106dB (A)
  • R: 105dB (A)

測定帯域は5Hz-20kHz。

本節の測定値はサウンドカード自体の雑音を補償したもの。ただし、グラフは補償していない。

コメント

使用したアンプIC LM3886のデータシートでのSN比は92.5dB(A, 1kHz, 1W)だが、本機のSN比がそれより大きい(約5倍)のは、以下の原因が考えられる。

  • 測定方法が本資料と異なるため。
    • データシートでは1kHzのSN比を求めている。
      • 実はデータシートの記載が誤っていて(、あるいは誤解させるもので)、広い帯域(例: 80kHz)の雑音で計算している可能性もある。
    • データシートに記載されている"Rs= 25Ω"がどの抵抗なのか不明。入力をショートする抵抗なのであれば、本資料(0Ω)と異なるので、雑音が増してSN比が低下する可能性がある。
  • BA3886のゲインが10と通常の約1/2のため。

周波数特性

振幅

両チャネル約8W出力時: 3Hz-20kHz: +0, -1.1dB

振幅の周波数特性

BA3886 Final check Amp cmp 1-2-1.png

  • L: 青系, R: 赤系
  • 暗色(一番下): 常用音量(約11mW)時
  • 中間色(中間): 出力約1W時
  • 明色(一番上): 出力約8W時
  • 灰色: サウンドカード直結 (出力: -10dBFS)

位相

両チャネル約8W出力時: 20Hz-20kHz: -0°, +3°

位相の周波数特性

BA3886 Final check Phase cmp 1-2.png

  • L: 青系, R: 赤系
  • 暗色: 常用音量(約11mW)時
  • 中間色: 出力約1W時
  • 明色: 出力約8W時
  • 灰色: サウンドカード直結 (出力: -10dBFS)

本節の測定値はサウンドカードの入出力特性を補正・補償したもの。ただし、グラフは補正・補償していない。

コメント

PCの再生系(JACK)を現状(44.1kHz)以外のサンプリングレートにするのは手軽でないため、測定は約20kHzまでとなっているが、サウンドカードは高いサンプリングレートをサポートしているし、本機も特に制限をしている訳ではないので、更に高い周波数も再生可能と思われる。ただ、そこに必要性を感じていないので、測定する予定はない。

歪み(THD)

  • 常用出力(約11mW)時 (ボリューム使用: 12時辺り): 約0.0070% @1kHz
    • L
      • 30Hz: 0.0019%
      • 1kHz: 0.0072%
      • 4kHz: 0.0078%
    • R
      • 30Hz: 0.0024%
      • 1kHz: 0.0068%
      • 4kHz: 0.0083%
  • 約1W出力時: 約0.0027% @1kHz
    • L
      • 30Hz: 0.0050%
      • 1kHz: 0.0025%
      • 4kHz: 0.0032%
    • R
      • 30Hz: 0.0059%
      • 1kHz: 0.0029%
      • 4kHz: 0.0035%
  • 約8W出力時: 約0.0014% @1kHz
    • L
      • 30Hz: 0.0026%
      • 1kHz: 0.0010%
      • 4kHz: 0.0015%
    • R
      • 30Hz: 0.0028%
      • 1kHz: 0.0017%
      • 4kHz: 0.0028%
各出力での歪み(THD)の周波数特性

BA3886 Final check Dist cmp 1-2.png

  • L: 青系, R: 赤系
  • 暗色(1kHzで一番上): 常用音量(約11mW)時
  • 中間色(1kHzで中間): 出力約1W時
  • 明色(1kHzで一番下): 出力約8W時
  • 灰色: サウンドカード直結 (出力: -10dBFS)
  • 各曲線の色が薄い部分(例: 高域)は、歪みがノイズフロア以下であることを示し、歪み率の信頼性は低い。
特記事項
  • 測定帯域(フィルタ)は10Hz-20kHz、負荷は8Ω。
  • 約1W, 約8W出力時はスピーカー出力のあとにアッテネータ(-16.5dB)を入れて測定した。
コメント
  • 使用したアンプIC LM3886のデータシートでの1kHz, 10WのTHD+Nは約0.003% (1kHz, 8Ω, Vcc=±28V, 10W, 80kHz)だが、本機の8Wでの歪み率がその約1/2なのは、以下の原因が考えられる。
    • データシートはTHD+Nのため。
    • 本資料の測定帯域が狭いため。
    • BA3886のゲインが10と通常の約1/2のため。

    今のところ、測定帯域が狭いためではないかと考えている。

  • 8W出力時に超低域(30Hz以下)の歪みが増大しているのは、電源やその配線の容量不足(、あるいはインピーダンスが充分に低くないこと)によると思われる。上述のとおり、仕様上の最大出力が約4Wなので仕方ない面もある。

クロストーク(チャネル・セパレーション)

片チャネルだけに信号を入れ、そのスピーカー出力(振幅)に対する、反対チャネル(入力なし)からの漏れ信号の振幅の比を求めた。

約0.6W出力時: 約92dB @1kHz

  • L→R (Lチャネルに信号を入れ、Rチャネルのスピーカー出力を測定)
    • 1kHz: 92.0dB
    • 10kHz: 77.6dB
  • R→L (Rチャネルに信号を入れ、Lチャネルのスピーカー出力を測定)
    • 1kHz: 106dB
    • 10kHz: 77.2dB

反対チャネルからの漏れ信号の振幅の周波数特性

BA3886 Final check Cross talk cmp 4.png
緑: L→R, 紫: R→L, 灰: サウンドカードL→R, R→L; スピーカー出力は-6.6dBFS相当(上の線)

本節の測定値はサウンドカード自体の漏れを補償したもの。ただし、グラフは補償していない。

特記事項

大出力(振幅)を測定するためにアッテネータを入れるとクロストークが悪化するため、アッテネータが不要な最大出力で測定した。

コメント

中高域でL→RとR→Lに差があるが、原因は分からない。一時はサウンドカード自体の特性かと思ったが、そうではなかった(上のグラフでは差がない)。線の引き回しや基板の作りが関係しているのだろうか。

アイドル時のアンプIC LM3886の温度

  • 無風時: 室温+18℃前後
  • 風がある時: 室温+16.5℃前後

スピーカー保護部の特性

以下、値は実測値。

出力をミュートするオフセットのしきい値(振幅)

DC (オフセット)

約+1.2V, -1.4V

AC (超低音をオフセットとみなす特性)

  • 1Hzの正弦波をミュートするスピーカー出力の振幅: LRともに約1.9V
  • 最大出力となる振幅(約9.3V)の正弦波がミュートする上限周波数(Hz): LRともに1.75Hz

制限事項

短時間(下記以下)で電源を再投入(off→on)すると、ミュートされて起動できない。再投入は、少なくともミュート通知ランプ(赤)が消灯するまで待つこと。

  • 電源の再投入間隔: 約5秒
  • ミュート後の電源の再投入間隔: 約20秒

コメント

起動(電源on)時のミュートを防止するコンデンサが放電するまで待たないと、起動時にDC-DCコンバータの電源制御端子が"L"にならず、アンプの電源がonにならないため。

主な使用モジュール・部品

  • アンプ部
  • スピーカー保護部: 自作
    • オペアンプ: MUSES 8820D
      • 手持ちを使った。特に指定はない。
    • ダイオード: RL205x4
      • 手持ちを使った。特に指定はない。ただし、オフセットのしきい値に関係する。
    • トランジスタ: 2SC1815 GRx3
      • 特性が近ければ何でも良いが、オフセットのしきい値に関係する。
    • リレー: オムロン G6A-274P-15 12VDC
      • アンプが稼働中はコイルが常時onのため、消費電力が小さい高感度型にした。
  • 電源部
    • DC-DCコンバータ: コーセル MGFW302415
      • 出力: ±15V, 1A
      • 上部にヒートシンク(約4x4x2cm, アルミ製)を付けた。
    • リップルフィルタ: コーセル SNA-03-223
  • その他
    • ヒートシンク兼ベース板: AData SSD SX900のマウンタ (アルミ製, 約10x10cm)
    • ケース: バッファロー Wi-Fiルータ WSR-300HPのケース (上半分を加工)
    • カバー: ダイソー 鉢底ネット 角型 (C029 No.4) (加工)

補足・コメント

アンプとは別だが、入力接続用コードは雑音に大きく関係する(とは言え、聞いて分かるほどの違いはない)。試したうちでは、エイトワンのもの(例: EAC-110)が一番雑音が少なかった。

また、外付け部品の元電源(ACアダプタ)は、歪み特性(特に低域)に大きく関係する。手持ちの数種類を試したところ、SAYAのアンプ SP192ABのACアダプタ(24V, 2.7A)が最も良かったので使っている。

測定に関して

使用した機材 (主要なもの)

  • 周波数特性、雑音などの測定
  • DC電圧・抵抗値などの測定
    • テスター: 三和 YX-360TR

測定結果についてのコメント

PCのサウンドカードとソフトを使用して測定したため、測定値の一般的な保証・認証や他者との比較妥当性はない。すべて「自称値」である。

測定しなかった・できなかったもの、載せなかったもの

  • ダンピングファクター: 手持ちの機材では正確に測定できないため。
  • スルーレート: 手持ちの機材では正確に測定できないため。
  • ダイナミックレンジ: 定義が想像していたものと異なっていたのと、様々な定義があるので、残留雑音から求めたSNRで代用することにした。
  • 矩形波(方形波)応答: 測定したが、あまり意味がないと思うので割愛した。

 


(6/22 7:05 測定方法などを加筆・修正, 残留雑音とSN比の測定値を修正; 6/22 8:49 クロストークの測定結果を修正; 6/22 11:27 クロストークの測定方法を修正して結果を訂正、全体を更新; 6/22 13:30 細かい加筆・修正; 6/22 14:00 本分をJoplinのRAWのMDを使うように変更; 6/23 7:32 元電源について記載, クロストークにコメントを追記, いくつかの特性の代表値を記載, 細かい加筆・修正)

 

PS. JoplinでMarkdown(MD)で書いたファイルを簡単にWordPressに入れられると思って居たが、意外に面倒だった。テキスト部分はコピー・ペーストやMD用プラグインで容易にできるが、画像までは面倒見てくれず、自分でファイルをアップロードし、Joplinの生成したファイルのパスをサーバ用にURLに変換してサイズを調整する必要があった。いろいろ試して、Better Find and Replaceというプラグインを使ってページ内で画像を指定する部分を自動変換することで対処した。他の同様なものだと、なぜかページが真っ白になるものがあった。相性問題か。

途中までは、MDでは手間が掛かり過ぎるからPDFを載せようとしたのだが、馬鹿らしいしビューアのプラグインでは見にくいので、MDを何とかした。

また、MDをインポートするプラグインも いろいろあるものの、画像込みの場合にはImport Markdownが一番手間が少なそうだ(ただし、画像は手でアップロードする必要がある)。

こういう、本題とは関係ないところで半日くらい潰れたw

(6/22 14:22) 備忘録として、JoplinのMD中の画像を表示できるようにするためのBetter Find and Replaceの変換ルールを書いておく。

  • Rule's type: Regular exp. (正規表現)
  • Find: (変換対象のパターン: JoplinのMDの画像リソース名(":/"で始まる32文字)を見付け、"alt="から画像ファイルのsuffixを見つける。)
(<img +)(src="):/([0-9a-f]{32}(\.[^"]+)?)" +(alt="[^"]+(\.[^"]+)")?( .*)?( />)
  • Replace With: (変換方法: 画像のパスをアップロード先にし、幅を制限する。クリックしたら画像を表示する。)
<a href="/wp-content/uploads/JMD/_resources/$3$4$6"
$1$2/wp-content/uploads/JMD/_resources/$3$4$6" width="100%" $5$7$8
</a>
  •  0
  •  0

起こりうる問題の検討と対処が終わったので、このドメインをIPv4/v6両対応にしました。当然ながら、このブログも両方対応です。

とは言え、アクセスする側からは何も変化はありません(何もする必要もないです)。あったら駄目ですw IPv6が使えて、IPv4より優先されているクライアントからは、IPv6でアクセスされます。もし問題がありましたら、お知らせ下さい。

なお、確認のため、当面、ブログのページ最下部にサーバとクライアントのIPアドレスを表示するようにしています。アドレスがなんか見慣れなくて : が含まれている場合はIPv6で繋がっています。

 

PS. やっぱり、個人的には、鳴り物*も、したり顔でユーザーに押し付ける下らねえ作業(例: 良く、「Aにしたら最初にすること10個」みたいなクソページにある、「AではBはこうする」)もなしの、「気付いたら なってた」ってのが一番いい。(v6追加なんて全然ローンチじゃないが※、)「シームレスローンチ」とでも言うのだろうか?

*ファンファーレ、「パフパフ」、「ドンドン」とかティーザーとかカウントダウンとかシャンパンとかクラッカーとか花火? それはそれで面白そうだwww

※もちろん、日本語で「ローンチ」って言うのすら嫌いで、ここに書くのも嫌だったw そういう人たちとは住む世界が違うと思っている。

そういう意味では、IPv6はなかなかうまいことやっている(運がいい)。IPv6自体は全くうまくなかったが、手をこまねいているうちにOSなどが対応していて、日本に限ってだが、フレッツのPPPoEがクソになったという無関係な方向から圧力が掛かって、意外にうまい具合に移行が進んでいる感じだ(棚ぼた?)。

こんなの、当時は全然思ってもいなかったw (「こんな複雑なの、永遠に使われねーよ」と思って居た。: まあ、先見の明がなかったな)

  •  2
  •  0

サーバのIPv6対応の一環でブログ関係の対応チェックと調整をしたついでに、ページ表示が遅いのを改善してみた。

実は、今までにも、MySQLの調整をしてわずかに速くなった「気が」していたw

無駄な処理やコメントを省いたら、気のせいか少し速くなった。

それから ちょっと調べたら、想像どおり、OGP(Open Graph Protocol, 説明)の画像の読み込みでの遅れがかなり効いていたので、LazyLoadというプラグインを使って画像を遅延読み込みにした。スクロールさせると画像がワラワラ出るのは個人的には余り好きでないが、遅いよりは良かろう。

最初は、画像が大き過ぎる場合(OGPに幅1000画素以上とかサイズ数MBの画像が指定されている、馬鹿みたいなサイトが多い)は使わないことを考えたが、画像のサイズを取得する時に読み込むので速くならない。

あと、OGPの処理(+画像取得・表示)をJS(= ブラウザ)にやらせて非同期にすれば綺麗だしかっこいいし軽い(仕事を押し付けられたブラウザにすれば迷惑かもw)が、JSは苦手でなかなか面倒なので※、上記の遅延読み込みにして、結果的に非同期に近くなるようにした。

※探せば、OGPを上記のようにJSでやるようなプラグインがあるかも知れない。 → ちょっと探した限りでは、なさそうだ。

そうしたら随分速くなって、今までは最初に表示する時は1秒を超えることがほとんどだったのに、新しいページなら0.3秒くらいで出るようになった。まあ、処理を後回しにしているので当たり前ではあるが、余り手間を掛けずに3倍速くなったw

(12/2 18:41) その後、やっぱり遅いことがあることが分かった。1秒以上掛かることがある。画像の遅延読み込みでOGPは速くなっても、MySQLが遅い場合がありそうだ。別のDBに換えたいが、なかなかいいものがない・・・

  •  0
  •  0

訳あって(まあ、訳もなく何かを作る人も少ないがw)、題に書いた機能が欲しくなった。が、調べても(プラグインでも)できないようだったので、自分で何とかした。

少し詳しく書くと、WordPress(およびプラグイン)では、サイト全体または投稿ごとににコメントできるかどうかの設定はできるが、既にコメントがある投稿をコメントできないようにすると、過去のコメントが表示されなくなってしまう。それは嫌なので、過去のコメントは表示されたまま、新しいコメントを投稿できないようにした。実装中に気付いたのだが、コメントの表示や投稿欄はテーマごとに実装している(新しいテーマはそうでないのかも知れないが、調べてはいない)ために、WordPressの設定やプラグインでは不可能なのかも知れない。

なお、「コメントの手動承認」を必須にすれば、新しいコメントは即座には表示されなくなるが、いちいち捨てるのは手間だし、(説明を読まずに)不可なのを知らずに投稿する人が出そうだから良くない。

いろいろなやり方はあるだろうが、以前、投稿の期限切れ処理をしないようにした時と同様に(結構安直に)、対象の投稿にタグで「コメント追加不可」をマークし、コメント表示・投稿ページでは、マークされている場合にはコメント投稿欄を表示しないようにして、新しいコメントを投稿できないようにした※。また、本ブログのWordPressの登録ユーザー(といっても自分だけだが)は引き続きコメントの追加ができるようにして、保守できるようにした。なお、コメント追加不可のタグは""とした。

※本ブログではタグを使っていないので、このような利用方法が可能である。

参考までに、以下にコメント表示・投稿ページでの追加処理に関係する関数などを挙げる。

  • 投稿($post)のタグ一覧の取得
    • $tags= wp_get_post_tags($post->ID);
  • 「コメント追加不可」タグが設定されているかの判定: 取得した投稿のタグのスラグが「コメント追加不可」タグのスラグ(RO_COMM_SLUGとする)と一致するかどうか(スラグ以外も使用可能と思う)。
    • $tags[N]->{"slug"} == RO_COMM_SLUG : Nはタグのインデックス(0..)。
  • WordPressのユーザーID: $user_ID (テーマの中などで使用可能)

なお、この機能はコメント投稿欄を表示しないだけなので、裏技を使えば投稿できそうな気がするが、不可にしているのに投稿して来たら問答無用でスパムにしてブロックすればいいので、大きな問題はない。

  •  0
  •  0

以前作って廃止した仕事用サイト、もしかしたら再就職活動の足し(例: 経歴に書く時の元ネタ、Webやアプリのサンプル)に使えるかと思ってちょっと見たくなったのだが、なかなか問屋が卸してくれなかった。WordPressでは画像などの添付ファイル以外のコンテンツはDBに入っているので、HTMLのようにブラウザで簡単には開けないのだ。そこで、一式を手元のデスクトップPCに移して、最小限でもいいから表示できるようにしようとした。

実は、サイトが生きていた時には定期的にPDFで保存していたのだが、(良くあるパターンで、)欲しいところを取ってなかったのでw、この作業をする羽目になった。

要は、WordPressのサーバ移行にからむ作業である。最初から面倒なことは分かっていたが、やる気(時間)はあった。

いろいろな作業が要るが、一番面倒なのは、文中の自サイト(自サーバ)へのリンクや画像のURLを書き換えることである。それらは大抵絶対パスのように格納されていて(例: "https://blog.piulento.net/archives/94939")、例えば新しいサーバのドメイン名やポート番号が違っていたら、問答無用で無効になってしまう。そして、WordPressは何も対処してくれない(何が正しいか分からないので、不可能だ)。

おそらく、自サイトへのリンクを付ける時に、ドメイン名などを外して相対パスのように(例: "/archives/94939")すればいいのだが、そういうサポートがないので、すぐに忘れてしまう。更に、画像のリンクは自動で付くので無理だ。

対処にはいくつかの方法があるが、コンテンツ(DB)を書き換える方法と、表示時に書き換える方法があるだろう。前者はまあ簡単だろう(置換するプラグインがあるだろうし、インポート機能でできるのかも知れない)が、移転のたびに手間が掛かるうえに、そのうちおかしくなってしまう(しかも、気付かない)可能性がある。そこで、僕は後者の、コンテンツやDBはそのままにして、表示時に変換する方式(オンザフライ)で対処したいと思った。

今気付いたが、コンテンツ中のローカルURLを相対パスのように置換すれば、オンザフライでの変換も不要になっていいかも知れない。ただ、上にも書いたように、WordPressにはそういうサポートがないので、投稿が増えるたびにそういう処理が要るだろう。

このサーバでは、(別な「小手先対処」のために)URLの書き換えをRewriteというプラグインでしているので、今回もそれが使えると思ったのだが、URL中のパスの部分だけしか変換できないようで(サーバからWordPressに来る時にそうなってしまうのか)、ポート番号は変更できかった。それで他を探したら、Real-Time Find and Replaceでできた。

なお、Rewriteは古過ぎるせいか、最新のWordPressではエラーになったので、修正が必要だった(今まで知らずに使えていたので、設定だけの問題かも知れない)。ご入用の方はお知らせ下さい。

今回は、ドメイン名は変えずに(ドメインは廃止するので、ホストテーブル(/etc/hosts)に書いて誤魔化すことにした)、スキーム("https"を"http"に)とポート番号(下例では80を9999に)を変えたので、以下のようなルールで変換するようにした。

元: @(http)(s)?:(//AAAA\.BBB)(/blog)(/.*)?@
置換後: $1:$3:9999$4$5

見ても「は??」であろうが、正規表現というもので、ワイルドカードの千倍以上便利だw 上で、"AAAA\.BBB"は元のドメイン名("AAAA.BBB")、"9999"は新しいポート番号である。例えば、元々のURL: "https://AAAA.BBB/blog/94939"(httpsはhttpでも可)は"http://AAAA.BBB:9999/blog/94939"に変換される。

なお、公開サイトで使うなどの場合のように「ちゃんと」(完全に)変換するにはいろいろな例外条件への配慮が要るが、今回は自分で見るだけなので、手を抜いた。

 

(7/31 21:40 一部の誤りを取り消し, 8/1 15:31 補足・修正)

  •  0
  •  1

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

このブログサーバーの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分くらいで終わった。回転を良くするためか、白い固定板に油が付いていたので、指がベトベト、かつ、表皮のかけらがくっついて汚くなった。

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

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

 

(2017/9/7 2:45追記) その後(7月頃)、パッドが固定板から外れてしまったので、両面テープで固定板に貼り付けた。やはり、マチが狭いのが良くないようだ。まだ大丈夫だが、剥がれたら新しい物に買い換えようと思っている。

 

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