先日ちょっと書いた、ブログにボットが良く来る件でアクセスログを見ていたら、不正ログイン試行や悪質なアクセス※が結構多くて気になってしまった。

※例: シェルのコマンドを実行しようとするもの、大量のバイナリデータを送って来るもの。

以前にも何度か、目に付いた時に そのアクセス元近辺のIPアドレスをブロックするように設定したのだが、設定するスクリプトを変更するのは面倒だし失敗する可能性があるので、ブラックリストのファイルにIPアドレスを書いて、適宜追加できるようにしてみた。動作確認した時は うまく動いたのだが、たまたま翌日にカーネルの更新で再起動になった あとは繋がらなくなってしまった・・・

それでサーバ(VPS)のコンソールで調べたら、起動はしているもののNWが全然使えない状態になっていた。: ホスト名の検索(DNS)は駄目だし、プロバイダのDNSサーバにすらpingが通らなかった。

ログを調べると、networkd-dispatcherが"Unknown state for interface NetworkctlListState"という訳の分からないエラーを出していた。更新されたカーネルの問題・相性を疑っていたのだが、検索しても ほとんど出て来ないので、僕の環境の問題だと思った。

結局、(上のエラーの前に出ていたのだが、)systemd-networkdが起動しなくなっていたためにNWが使えなくなっていた。その原因は、上に書いたブラックリストのために追加した処理にバグがあり、必須のNWアクセスも遮断するようになっていたためだった。

そのバグというのが しょうもなくて、たった一個の余計な空白(下の $var のあと)が原因だった。シェルスクリプトに

if [ -n "$var " ]; then

のように書いてしまったのを気付かなかった(近眼+老眼+白内障(進行中)のコンボに加え、そもそも眼が不調だ)。$varが空の場合に以降を実行するのに、これでは 全く実行されない。その処理が重要で、実行されないとNWが全部遮断されてしまうのだ。。。

そもそも、空かどうか調べるのに"$var"のように " で挟んで書くのが良くなく(しかも面倒)、もっと間違い にくい書き方がある気はするが、今まで見たことがない。少し考えたい。

そこを直してサーバは回復し、ファイルに入れたブラックリストも ちゃんと動いた。

 

そして更にもう一個、隠れた問題が見付かった。Linuxの仕様なのか、NW-IFを有効にする前のスクリプト(/etc/network/if-pre-up.d/*)が何度も実行されるのだ。僕は そこに上述の悪質アドレスのブロックを設定するスクリプトを入れたのだが、今回初めて、それが何度(4回)も実行されていることに気付いた。

内訳は、実際のNW-IFに対するIPv4, IPv6が各1回、全体に対するもの?(IFACE="--all")、loopback(IFACE="lo")だった。

もちろん使う前に調べれば分かる・調べるべきことだが、余りにも おかしな・杜撰な仕様だ。今まで問題なかったので、スクリプトは何度実行されても問題ないようだが、念のため、一度だけ実行されるように修正した。

スクリプトに渡される環境変数のMETHODが"none", IFACEが"--all"の時だけ実行するようにした。ただ、これはどういう契機なのか分からず、将来は なくなるかも知れないので、実行されなかったら警告が出るようにした。

 

起きてから延々と作業して午後遅くまで掛かったが、そもそも、こんなIPアドレスのブラックリストなんて意味ないことに気付いた。

まず、不正・悪質なアクセスをするサイト(のIPアドレス)は無限にある。※ 良いブラックリストを手軽に入手できないかと検索したら、山のようにブラックリストが出て来たが、それらの いくつかと僕のブラックリストに共通のアドレスはなかった。

※今はまだIPv4がメインだが、v6なら本当に無限だ。それに、v6のアドレスは(プライバシー処理のため)基本的に「日替わり」だから、アクセス時のアドレスに永続性・再現性はない・・・

仮に 良いブラックリストを合わせて使うにしても、無限に多くのアドレスでフィルタリングできる訳はなく、段々重くなり、最後は破綻するだろう。

そして、悪質サイトはブラックリストに載ったらアドレスを変えるだろう。載らなくても随時変えるのではないか?※ 実際、以前アクセスして来たアドレスは、(ログを見る限り、)何度か失敗したあとはアクセスして来ない。それに対応するために余分な幅(例: v4なら256-65536個?、v6なら2⁶⁴個??)を持たせてブロックするとしたら、そのプロバイダの他の人までアクセスできなくなる。

※日本ではそうだが、固定IPアドレスの人が少ないこともありそうだ。そもそも固定にする意味がない。更に、上述のようにv6は基本的に固定でない。

そうやっているうちに、誰もアクセスできなくなりそうだ。

だから、IPアドレスでブロックする仕組みを作りは したし、定期的に不正・悪質なアクセスを調べようと思っては いるが、無意味だと思う。どこかで見たが、リアルタイムに挙動で判定するのが良さそうだ。それがWAFなのだろう。

手軽に使えるものがあるか、気になるところだ。

↓

(23:30) 少し探したら、手軽(無料・簡単)なWAFは なさそうだが、無料のものは いくつか見付かった(例: NAXSI, ModSecurity)。

が、インストールや設定は容易では なさそうなので今後の課題とし、まずは現状の脆弱性などの問題をチェックしようとした。: Nikto2というツールとオンラインのスキャナ(例: InnuniWeb, Mozilla Observatory (HTTP), SSLTrust Free Website Safety & Security Check, WordPress Security Scan)を使った。その結果、軽微な問題は見付かったものの、概ね大丈夫そうだった。

ただ、脆弱性に関して余りチェックをしないもの(HTTPヘッダ辺りが中心の感じ → クライアントに被害を及ぼさないかがメイン?)が多かったので、もっとサーバにキツそうなもの(例: w3af, OWASPのいろいろなツール)でチェックする必要がある。

とりあえず、チェックで見付かったHTTPヘッダ周りの問題を修正した(できないものもあった)。

• WebサーバとWPのセキュリティプラグインAll In One WP Securityが同じヘッダ(X-Frame-Options: SAMEORIGIN)を出していたため、設定値がおかしい(重複している)という警告が出たので、プラグイン側(Misc. → Frames → Enable iFrame Protection)を解除した。
  • 最初は どうして重複するのか分からず、苦労した。
• (サーバ・OS依存のようだが、)ETagはリスクがあるとのことなので削除した。
• httpsでのgzip圧縮にはリスクがある(BREACH攻撃)とのことだが、問題の起こらないタイプだけに制限しているので問題ない。
• 一番の問題は、Content Security Policy(CSP)に対応していないことだ。: ページの修正が要りそうなので、容易には対応できない。

その他に、TLSの問題・互換性をチェックするものもあったので(例: Observatory (TLS), TLS Checklist inspector)、チェックして修正した。

• 今はTLS 1.3に移行しつつあるようなので、(obsoleteらしい)1.1を止めて1.2と1.3に対応させた。
  • AEADというものに対応していなかったので、対応させた。
  • 1.3に対応させる時、Mozillaの、サーバの設定例を作るページが役に立った。
    • が、その設定と他のチェックが競合・矛盾する場合があって、(細かい問題ではあるが、)どうするか悩ましい。

あと、SQLインジェクションについても いくつかツールが見付かった(例: sqlmap, jSQL Injection)ものの、そもそもSQLインジェクションを良く理解していないので、正しくチェックできる方法を考える必要がある。

良く考えると、(考えなくても、)SQLインジェクションどころか、サーバのセキュリティ向上は2年以上前からTODOに入っており、今回も少ししたら忘れた振りをして放置する気がする・・・

 

PS. 全くの脇道だが、HTTPヘッダ関連を修正している時、Mozillaの設定サンプルにHTTP/2の設定もあって、調べたらサーバは対応しているので(もちろん、パフォーマンスが劇的に向上するなんて期待は しておらず、興味本位で)ちょっと試したくなった。

が、この「ちょっと」が いつもトラブルを招くのだ・・・ｗ (9/24 8:31)

↓

(9/24 14:39) やっぱり、ちょっとHTTP/2にしてみたｗ 今度は大きな問題は起こらず、webサーバの設定にHTTP/2を追加しただけで すんなり動いた。ただ、予想どおり、HTTP/2にしても速くならないどころか、わずかに遅くなった(例: このブログは約3%(約11ms)遅くなった)。ページの生成は並列に できないので、基本的には仕方ない。とりあえず試したかったのと、世の中の流れに追従するのが目的なので、まあいい。

HTTP/2にしても速くない(遅い)原因を考えてみたら、当たり前の気がする。: そもそもHTTP/1.1では複数の接続で同時に転送していたのを、わざわざ1本(想像)にまとめて その中で多重化しているのだから、スケジューリング・多重化・非多重化処理が増えて遅くなりこそすれ速くなる訳がない。

HTTP/1.1の複数の接続では両端の機器や経路へのリソース的な負荷が重くなるが、それが問題なければ、1本にまとめるより ずっと効率が良いと思う。

あと、ヘッダをバイナリにするとデータ量は減るだろうが、元々ものすごく大きいものではないし、エンコード・デコードの処理が増えるから やっぱり少し遅くなるだろうし、ボディ(本体)は もともとバイナリ可なので、何も変わらない。

結局、接続を減らして処理が多くなるのに速くなるという理屈が不思議だ。HTTP/2はリソース面でエコだとは思うが、速度は期待できない。

不思議なのは、JoplinのデスクトップアプリがHTTP/2を使わない(なぜかモバイルアプリは使う)ことで、最新版に更新しても同じだった。良く分からないが、Joplinには構わないことにしているので良い。

他のアプリでは、PC(Linux)ではEvolutionは1.1だったが、意外にもSeamonkeyは2だった。Thuderbirdの新しいコードを取り込んでいるのか。スマフォ(Android)ではDAVx5は2だった。

作業に付随して起こった ちょっとした問題(これで疲れた)は、CLI版を更新したら なぜか起動しなくなり(以前もそうだったので、頭に来て更新しないことにした気がする)、ちょっと調べたらnodeのモジュール@aws-sdk/middleware-endpoint※が不足していたので、自分でダウンロードして追加したら動いた。

※パス: ~/.joplin-bin/lib/node_modules/joplin/node_modules/@aws-sdk/middleware-endpoint

構成ファイルが駄目なのか、nodeのバージョンの関係か。誰も指摘しないのが不思議だが、Joplinには構わないことにしているので、ここまでとした。

↓

(9/24 18:12) 下のPS2にも書いたが、正直言ってHTTP/2はイマイチなので(実際、すぐにHTTP/3が出た)、対応したばかりだが止めた。処理が複雑な割に効果がないし、余計な機能はバグなどを生んでセキュリティ上のリスクになるから、ないほうがいい。

PS2. ようやくHTTP/2に追い付いたと思ったら、HTTP/3が出て居た。開発者ツールでGoogleのサイトを見ていたら"h3"というのがあって気付いた。今度はQUIC/UDPベースだそうで、応答は速そうだ。となると、結局HTTP/2はイマイチだったようだｗｗｗ でも、HTTP/3も目論見ほど いいのか疑問はある。 (9/24 17:31)

先日書いたが、このブログで使っているセキュリティプラグインAll In One WP Security(以下、All-in-one)の更新に伴う不具合らしきもののために管理画面にログインできなくなって、慌てた。その後調べたら、似たような問題が起こっている方が結構居て(→ 例)、やっぱりAll-in-oneに問題がある可能性が高く、別の もっといい(まともな)ものに換えたくなって居た。

必要な機能をリストアップしたものの、探したり試すのが面倒で放置して居た。が、昨日、ちょっとやる気が出たので試してみたら、元のものより良いものは ないうえに、プラグインには関係のない問題(REST APIが動かない)も見付かり(最後に書く)、そこでも苦労して いつものように「骨折り損の くたびれ儲け」となり、疲れた。

結局、(僕には だろうが、)All-in-oneが一番良かった。確かに どうしようもない問題が起こって信頼度や安心感は落ちたが、バージョンが大きく上がって、(人も替わって?)「たまたま」充分な動作確認ができないまま出しちゃったんだろうと想像・期待する。

まあ、某 窓に比べれば可愛いものかも知れないねｗ

でも、もしまた同じようなことがあったら使い続けるかは分からない。とは言え、今回の比較で、現状では いいものがないことが分かった(そもそも、All-in-oneにした時も そうだった!)ので、どうしようもないが・・・

それに、もしログインできないとかの誤動作が起こっても、緊急的にプラグインを解除して復旧させる方法が分かったので、それくらいなら大丈夫だｗ

 

以下、条件、候補・試したものと評価・感想を書く。

要求条件 (ALl-in-oneで使っている主な機能を重要な順に)

• ログインページURLの変更
• XML-RPCのブロック
  • 忘れて居たが、webサーバでブロックしているので実際には なくても良かった。
• 非ログイン状態でのREST APIのブロック
• 連続スパムでIPアドレスをブロック
• ユーザーリストの禁止
• 繰り返しのログイン失敗でIPアドレスをブロック
• 特定ユーザー名(adminなど)でのログイン試行でIPアドレスをブロック

試さなかったもの (予選落ち)

• Jetpack – WP Security, Backup, Speed, & Growth: 高速化がメインのようだし、関係ないものが詰め込まれているので止めた。
  • 以前、高速化で試したが、うまく動かなかったこともある。

試したもの (概ね試した順に)

• SiteGround Security
  • 使用データの収集を許可しないと、それを促すメッセージが出続けるので止めた。
  • また、REST APIが動いて居ないというエラーも出続けた。 → あとでWP自体(またはサーバ設定)に問題があることが分かり、対処した。
• Security & Malware scan by CleanTalk
  • 使うにはAPIキーが要る(自動的に取得できる)。
  • しばらく使うまで気付かなかったが、そのキーは有料サービス(クラウドの「ダッシュボード」, 確かUSD 6/年)の試用用(2週間しか有効でない)で、そのあともプラグイン自体は使えるが、機能としては今一つになること(例: ログが最新のものしか見られなくなる)や、最初に有料サービスであることが明示されなかったので騙された気分がしたので止めた。
  • ただ、クラウドも含めた機能としては悪くなかった。
• iThemes Security
  • 多くのレビューのとおりで、設定画面が変(デモ版みたいな感じで、細かい設定がない)で、ちゃんと動く気がしなかったので止めた。
    • これを ちゃんと使える人は居るのだろうか??
• Wordfence Security
  • ログインページのURLが変えられないので止めた。
    • 確かに、インストール前に見た説明にも書いてなかった。
    • 随分有名なようだが、こういう基本的なことができないのは不思議だ。
• Hide My WP Ghost
  • ログインページのURLを変えるにはwebサーバの設定変更が要るようなことが表示されたので、止めた。
    • あと、変更先のURLが変えられない感じだった。
• Anti-Malware Security and Brute-Force Firewall
  • 有料版でないと機能が貧弱なので止めた。
• WPS Hide Login
  • 名前のとおり、単体ではログインページのURLを変えるだけしかできないので、面倒で止めた。
• Defender Security
  • XML-RPCとREST APIのブロック機能がないので止めた。
  • 他の機能的は悪くなかったものの、無料版はいろいろ惜しい一方で、有料版は かなり高い(USD 7.5/月)。
  • アメコミ的な絵(スーパーマンとかMr. インクレディブル風)は好みが分かれるｗ、というか要らない。

最後に残った候補 (決断する ちょっと前に良さそうだと思った順に)

1. Security & Malware scan by CleanTalk
2. All In One WP Security
3. Defender Security

↓

ひとまずCleanTalkを試すことにしたのだが、良く考えてみると、機能面ではCleanTalkが断然いいということはなく、総合的にはAll-in-oneのほうが良さそうだと気付き、(耐え難いものを耐えて)All-in-oneに戻った。

そして、最後の判断材料とした2つの比較を示す。

• All-in-one
  • 長所
    • 必要な一通りの機能が揃っている。
      • 実際には ものすごく多くの機能がある。
    • 設定が細かくできる。
    • スパムコメントのブロックもできる。
    • 本当に無料で使える。
      • 有料版も あるはずだが、無料版で物足りないと思ったことがない。
  • 短所
    • WebサーバがApacheでないと使えない機能が結構ある。
    • マルウェアのスキャンは ない。
    • 近頃の信頼性(主に開発体制的なもの)に不安がある。
• CleanTalk
  • 長所
    • ファイアウォールにSQLインジェクションのチェック機能がある。
      • これだけは欲しい。別のもので できないかと思う。
    • マルウェアのスキャンが ある。(ただ、インストールされたあと(= 既に実行されたかもしれない)にスキャンするので、ほとんど意味がない。)
    • ボットのブロックができる。(本当に悪意のあるボットは正直にUAを出す訳がないから、あまり意味がない。単なる気休め。)※
      • あとで気付いたが、この機能はAll-in-oneにもある。
  • 短所
    • 「無料詐欺」的。
    • いろいろな通知メールが鬱陶しい。(設定が なくて停められない)

※興味があって、先月の このサーバへのアクセス中のボットかららしきもの(要求ヘッダに"bot"か"crawl"が入っているもの)を調べたら、2割未満だった。少なくはないが、中には悪性でない(とされる)もの(例: Google)も多いだろうから、ムキになってブロックするほどでもないと感じた。

 

最後に、頭に少し書いたREST APIの問題について。

SiteGroundでREST APIがエラーになったのが気になって調べた。: セキュリティプラグインのREST APIのブロックを解除してもエラーになった。最初はwebサーバの設定が悪いのかと思って試行錯誤したが、そうではなく、WordPressの既知の問題のようだった。

どういうことかというと、WordPressは ある時勝手にREST APIを追加したが(そもそも、これが何のためかも分からないし、普通に動かしているとセキュリティ上の問題になるのがおかしい)、普通の設定だと使えないことが多いのだ。

そのため、ちゃんと動かないので、特別ブロック・対処していないサイトでも 瓢箪から駒的に安全になっている・・・

そういう点ではWPは大変良くない感じで脱却したい気はするが、プラグインどころの騒ぎじゃないし、いろいろ手を加えて便利に使って居るので簡単ではない。

動かないのはセキュリティ面でいいものの、意図せず(何かの問題で)動かないのは気に入らないので、調べて動くようにした。結局、以下のいずれかをすればいいようだったが、このサーバでは最後のものしかうまく行かなかった。

• WPのパーマリンク設定をpost nameにする。 (→ 参照)
• REST APIのURL: /wp-json/*を/index.php/wp-json/*に換える。 (→ 参照)
  • /index.php?wp-json/* という情報もあった。
  • Webサーバなどの設定で行う。
• REST APIのURL: /wp-json/*を/?rest_route=/*に換える。 (→ 参照1 → 参照2)
  • Webサーバなどの設定で行う。

それで、Webサーバの設定を変えるのは大ごと(いつも苦労している)なので、手軽に、WPのURL書き換えプラグインRewrite※にルールを追加して対処した。以下のようにした。

最後に追加:

• • Pattern(元): wp-json(/.*)$
  • Match(書き換え後): rest_route=$matches[1]
  • 動作: 元のURLの"wp-json"以降("/"も含む)を"rest_route="のあとに付ける。
    • 上のページでは、書き換え後には/?が先頭にあるが、なくても動作した。おそらく、ここに来る前に付いている(相当な)のだろう。

※このRewriteは便利なのだが、WPの元々のルールに場当たり的に追加して来ているので、なくてもいいものや良くない動きをしているものがありそうだし、何かあったら回復できないので、なかなか爆弾的なものだ。

まあ、そもそも「これ、何に使ってんの?」、「何か いいこと あるん??」って聞きたいくらいだから、直しても何もいいことはないが、(いつものように)気分の問題で直した。

 

まあ、これで一個でもTODOが消化できたのは良かった。しかも、気付いていなかった問題も直せた。

終わってみると、全部、(ちょっと我慢すれば)やらなくても良かったことのような気がしないでもないが・・・ｗ

 

PS. 全く関係ない話。ブラームスを茶化したツイートがあった。: もし彼が今生きていてSNSでメッセージを送ったら、受け取った相手が「あなただけ なんでそんなに長いのよ」と嘆く場面で笑った。彼は何か 言い訳してた気がするが覚えてない。: ブラームス(の曲)は好きじゃないが、僕も同じ類だｗｗｗ

(他にも書きたいことはあるが、眠いので軽く。)

近頃、ちょっとしたことが いつの間にか良くなっていた、あるいは、わずかな手間で良くなった。

一番はVivaldi(Linux版)+日本語入力(Fcitx+Mozc)とツイッターの相性問題で、以前は日本語が まともに入らなかった※のが、ちゃんと入れられるようになった。ただ、元々他のサイトでは起こっていなかったので、ツイッター側の問題だったのかも知れない。

※入れている途中で消えたり、文字が抜けたり、消した文字が残って居たり・・・

少し前は、DM(チャット)は まだ今一つな感じもしたが、今は大丈夫かも知れない。

何だか分からないが、とりあえず直って良かった。

次もVivaldiとツイッターだが、ツイート中のビデオの再生開始直後と終わってから少しの間、ブラウザが動かなくなっていたのが解消できた。これは何かが直った訳でなくVivaldiの設定の問題だった(Tabs→"Mute Tab Audio"を"Prioritize Active Tab"から"All Tabs"にした)。本当は元の設定が いいが、無理なものは仕方ない。

最後は、このブログで使っているWordPressが、いつの間にか画像のlazy loading(遅延読み込み)をサポートしていたことだ。僕は、結構前にそのためのプラグイン(Lazy Load - Optimize Images)を入れていたのだが、挙動が ちょっと気に入らなかった(画像の出方が もったいぶっている、それで遅く感じる)ので、早速無効にした。

WPのlazy loadingは そうなっているのが全然分からないので、本当に働いているのか疑って開発者ツールで調べたら、ちゃんとページのスクロールに合わせて画像のアクセスが起こって居たからOKだ。 (→ 画像: 上半分あるいは下の右半分の右側にポツポツとある点のところで、画像を遅延読み込みしている。) きっと、画像が表示される直前に読むのだろう。賢い。某プラグインのように、画像が出てから変に凝ってフェードさせて出すなんて愚の骨頂だ。

前々回のPSに書いた、このブログのロゴ画像を「時替わり」で いろいろ出すのが意外に気に入ったので(+そこでも書いたように、ERNIE-ViLG Demoで描いた画像が気に入ったのも大きい)、それを改良した。

例によって やることは難しくないのだが、実装には結構手こずった。欲張るせいもあるが、老化で頭が回らなくなっているのだろうか?

以下のようにしたかった。

• ロゴとして特別に選んだ・作った画像でなく、ブログの投稿に使った画像全体(あるいは新規も)から、気に入ったものを随時選んで出し、あるいは「引っ込め」たい。
  • → 表示する画像を特別なディレクトリにアップロードするとか、それ用の名前にするとか、注釈(キャプション)を特別なファイルに入れるとかせず、WPの仕組みだけで実現して操作を楽にしたい。
  • かといって、前に書いたように、複数画像の対象への一括設定/解除やキャプションの一括更新ができないとかの馬鹿らしい・面倒なこともしたくない。

一方、表示候補の画像を検索するために対象に「マーク」を付けたいのだが、標準のWPだと画像にはタグなどが付けられないという問題がある。

それらが付けられるのは、投稿などだけ。

WPのカスタムフィールドを使えば実装できそうだが、使い勝手が良くない。そこで、プラグインで何とかできないか探したところ、Media Library Assistant(以下、MLA)というものが見付かった。※ 本来は、WPのギャラリー(複数画像をまとめて出す部品: この投稿の一番下にあるもの)を高機能にするものだが、上記のような、画像など(attachment)にタグなどを付ける機能を持っている。

※これは ものすごく高機能で、僕の用途には もったいないくらいで、とても使いこなせない。今回も、本来の用法でないために却って苦労したｗ

なお、単にランダムに画像を出すだけなら いろいろあるのだが、特に、タグなどで出す候補を指定できるものは なかった。

次のような処理にした。

• ギャラリーに表示する候補画像(画像以外、動画なども可能なはず)一覧を抽出できるように、MLAのattachment tag(Att. tag(画像: 右端の列))にギャラリー名(今回は"my_gallery"とした)を設定する。
  • こうすることで、ギャラリーに登録された画像を一覧することができる。
• 画像のキャプションはWPのTitle(画像: サムネイルの右の列)に設定する。
  • カスタムフィールドなどでも可能だが、使い勝手(特に一括更新)を考慮して そうした。
• ページの表示時は以下の処理を行う。 (注: 変更あり。最後に書く。: 9/14 8:42)
  1. 表示する画像情報がキャッシュされているか調べる。
  2. キャッシュされている場合、
     1. キャッシュから取得した画像情報からURLとキャプションを取得する。
  3. キャッシュされていない場合、
     1. ギャラリーの全画像数を取得する。
     2. 乱数で その中の1枚を選ぶ。
     3. 選んだ画像のURLとキャプションを取得する。
     4. そのURLとキャプションをキャッシュに格納する(今回は生存時間(TTL)は20分とした)。
  4. 画像のURLとキャプションをページの右上に表示する。

なお、前の版では、表示する画像をページ表示部とは別のプログラムで検索・選択していたが、今回はページ表示部だけで完結している。一長一短だが、こちらのほうが保守性は良い。

それから、やはり前に書いたが、表示する画像をページを表示するたびに検索するのは重そうなので、画像の生存時間(TTL)分キャッシュしておいて、その間は検索しないようにした。

キャッシュにはPHPのAPCuを使った。最初はファイルを使ったが、排他制御が厄介なのでAPCuにした。APCuにはTTL経過後にエントリがなくなる機能があるので、生存時間の実装がとても容易だった。

が、APCuにも排他制御の問題(複数のプロセスが同時にキャッシュを更新する場合)はあって、(この用途では必要ではないが、)一応実装した。apcu_entry()という関数を使った。

複数プロセスで同時に※キャッシュに書き込もうとした場合は、(当然ながら)先の情報を採用し、後から書き込むプロセスは、それまでに選んだものを破棄して先に書き込まれた情報を使う(すげ替える)ようにした。破棄した分の処理が無駄になって効率が悪いが、正しい方法は すぐには分からないので、とりあえず こうした。

※実際には同時でなく、どちらかが先になる。マルチプロセッサ/コアの場合は難しいが、OSが ちゃんと処理しているのだろう。

いろいろ苦労して(また疲れて)、動くようになった。結果は このページの右上のとおり(見るたびに変わっているはず)。

と、一言で終わってしまうが、いくら苦労したって、ちゃんと動けば それで終わりだｗ

 

(9/13 20:31, 9/14 8:42) 表示する画像の選択方法について

上述のように、当初は乱数で選ぶようにしていたが、様子を見ていたら、(PSにも書いたように、)ばらつき・偏りが大きいことが分かった。具体的には、頻繁に出る画像と なかなか出ないものがあった。気になって調べてみたら、最高/最低頻度の比が10前後と随分大きかった。

乱数の作り方・使い方に問題があるかと思って改良してみたが、余り改善できなかった。それから、通常の生成関数方法(PHPのrand())以外に いろいろ試したら※頻度比は2-3程度になったが、全く気に入らなかった。

僕としては全部の画像を平等に出したいので、特定のものが頻繁に出るのは全く許容できない。もし、特別気に入っているものを頻繁に出したいなら、そういう処理にする。

そういう用途では、音楽プレーヤーのような「シャフル」がいいのだろう。(処理が複雑になるのを別とすれば、)画像数が少なければ問題ないが、多くなった場合には一覧を作るのに時間が掛かりそうだ。

※試した内容や結果などの詳細は別の稿に書きたい。(→ 書いた) ただ、どの方法も「元」は同じ処理のようなのか、(下にも書いたが、)何万回も試行(実行)しないとだめなのか、頻度比に大きな違いはなかった。= 「効果なし」だった。

どうやら試行(実行)回数が少ないとばらつきが出るようだが、1000回以上でも頻度比が2では使い物にならないと感じた。

それで、実際の使い方に立ち戻って考えてみた。: ページを見る方にとっては、ページの変わる順番がどうであろうと、(一定時間経過後に)見るたびに変わればいいので、ライブラリ(ギャラリー)に格納された順番に表示するようにした。 → 最初はギャラリーの最初の画像を、切り替わりの時間になったら次に、最後まで行ったら最初に戻るようにした。

切り替わり時間(20分)ごとにリロードして表示されている画像の内容またはURLを記録するのを数十回も続けるのを2周以上※するような奇特熱心な読者にはバレるが、さすがにそういう方は居ないので大丈夫だ。

※計算したら、一周で約10時間掛かる・・・ → 実際にやるなら、スクリプトなどが良さそうだｗ

なんて余計なことを書かなければ いいのに、技術者なので つい書くｗ

変更後の処理は以下である。

1. 現在表示されている画像の情報がキャッシュされているか調べる。
2. キャッシュされている場合、
   1. キャッシュに格納した時刻から、現在表示されている画像の表示(経過)時間を求める。
   2. 画像の表示時間が切り替え時間(今回は20分)を超えている場合、
      1. キャッシュから取得した画像情報から現在表示されている画像の番号を取得する。
      2. 取得した番号+1の画像を選択する。
         • ただし、ギャラリー中の画像数以上になったら0(最初)にする。
   3. そうでない場合は、以降は実行しないで終わる。
3. キャッシュされていない場合、
   1. ギャラリー中の最初の画像(番号= 0)を選択する。
4. 選択した画像のURLとキャプションを取得する。
   • 画像の番号を指定してギャラリーから取り出す。
5. そのURLとキャプションと画像番号をキャッシュに格納する(生存時間(TTL)は無限)。
6. 画像のURLとキャプションをページの右上に表示する。

この変更のため、最後に表示した(現在表示されている)画像の番号も画像情報のキャッシュに保存するようにした。また、最後に表示した画像が分からなくなっては困るので、そのキャッシュの生存時間(TTL)を無限にし、画像を切り替えるタイミングは自分で計算するようにした。

この場合も複数プロセスでのキャッシュに対する同時アクセスは起こるが、どのプロセスの次の画像も同じ番号になるはずなので、構わず上書きするようにした。

 

PS. 本題には関係ないが、前の版もそうだったが、乱数が一様でないような感じがする。前の版は中央辺りに頻度の高いものがあり、その隣は頻度が他の1/2くらいと低かった。

今回は、まだサンプル数が少ないものの、全く出ない値(≒ 画像)がある。特に、最小と最大が出ていないのは、プログラムに誤りがあるのかも知れない。。。

(9/14 9:05) その後、やっぱり我慢ならないので、本文に追記したとおり、乱数は止めた。

昨夜、寝る前に突然やって来た。どうにか対処したものの、大変な寝不足になってしまった。

以下、簡単に流れを書く。

1. なぜか、ブログの管理画面にログインできなくなった。2要素認証(以下、2FA)が失敗する。
   • 一瞬、サーバが(一種のランサムウェアに)攻撃されて、絶対に入れない状態になったのかとも思った。
     • ただ、sshは問題なく、別のシステムの2FAは成功したので、ブログだけの問題なことが分かってホッとした。
   • あとで分かったが、セキュリティのプラグインAll In One WP Security(以下、All-in-one)の2FAが設定していないにも関わらずonになったようだ。
     • 近頃の更新で、All-in-oneに2FA機能が追加されたけど全然気付いていなかったのが、そもそもの敗因だった。
     • 自分では その2FAをonにした記憶がないので、勝手にonになったか、元々の2FAのプラグインと勘違いしてonにしたのかも知れない。
     • ただ、何も設定していないのに有効になる(できる)のは、とんでもなく ひどい!
       • 間違えて2FAの機能をonにするだけなら有り得るが、どのユーザーを2FAにするか、どんな方式(例: OTP, ハードキー)にするか、OTPなら確認のコード入力など いろいろあるのに、間違えて そこまで設定することは全くない。
     • 元々の2FAのプラグインの設定を流用して勝手に設定されたのだろうか?
       • 書いたあとで分かったが、All-in-oneの2FAをonにすると、管理者などの権限を持っているユーザーは2FAが有効になってしまう。罠だ。
         • そこで、All-in-oneの設定で、2FAを有効にする対象(権限・役割)を なし(全部チェックせず)にしたら、2FAの設定タブがなくなったので、もう間違うことはなさそうだ。
2. (元々の)2FAのプラグインが変な状態になったと考えて一旦無効にしようとしたが、管理画面に入れないからできない。
   • それで、コマンドラインでプラグインのファイルを削除したが、なぜか2FAを無効にできなかった。
     • その前に、元々の2FAのプラグインのサイトを参考に、設定ファイルで無効にする方法を試したが、効かなかった。
   • 良く調べたら、(上記のように、)元々の2FAのプラグインとは別の、All-in-oneが2FAのOTP入力画面を出していた。
     • 最後は、認証エラーで出ているエラーメッセージを、インストールしているプラグインのプログラムから検索して特定した。。。
     • 似たような画面なので全く気付かず、どうしてもログインできないのが不思議だった。
   • それで、コマンドラインでAll-in-oneのファイルを一時的に削除して どうにかログインし、All-in-oneの2FAを無効にして、今までどおりログインできるようになった。
3. PHPがダウングレードできない。
   • All-in-oneが悪いと分かる前、近頃更新されたPHPの互換性の問題で元々の2FAのプラグインが うまく動かなくなったかと思い、ダウングレードして試そうとしたものの、いろいろな依存関係のために諦めた。
4. メールがGmailに送れない。
   • ログイン画面のパスワードリセット機能を使おうとしたが、その案内メールが届かなかった。
     • 届くこともあるのが謎だったが、どうも後述のDNSの逆引きがうまく動いていないためのようだった。
     • 更に、そのメールはパスワードをリセットするだけで、2FAには何もしないので無駄だった。
       • そもそも、元々の2FAのプラグインにはバックアップコードがあるのだが、All-in-one(バックアップコードは有料)とは違うので使えなかった。
   • 調べたら、Googleがスパムと判定するためのようだった。
   • メールの送信元認証システムのSPFやDKIMなるものを設定しないとGoogleはスパム扱いするようなので、(深夜なので止めておけばいいものの・・・)「ちょっと」SPFを設定してみた。
5. SPFの設定がうまく行かない。
   • 自分のドメイン名を管理するDNSサーバにSPFを設定しても、チェッカーでは「SPFの設定なし」と出た。
     • 原因が良く分かっていないが、DNSの逆引き設定の不良(未設定?: 後述)とDNS情報の伝達遅延のせいだったようだ。
     • 書いたあとで調べたら、原因が分かった。 (9/9 13:56)
       • DNSサーバにSPFを設定する場合、TXTレコードとして書くのが一般的なようだが、以前はSPFレコードとして書く方式もあったけど廃れたようだ(→ 参照)。
       • 一方、僕は良く分からずに、(DNS設定画面のプルダウンメニューに出て来たから)SPFレコードで設定したので、チェッカーが「設定なし」としていたことが分かった。
       • SPFレコードからTXTレコードに設定し直したら、チェッカーもGmailへのメール送信も成功した。
         • 想像だが、未だにSPFレコードをサポートするのはGoogleくらいなのではないか??
6. DNSの逆引き(IPアドレス→ドメイン名)がおかしい(未設定?)。
   • このサーバの設定項目に逆引きがあるが、ドメイン名のDNSサーバに登録すれば不要だと誤解していて、設定していないのが駄目だったようだ。
   • ただ、今まで、ちゃんと逆引きできていたこともあるので、それは どこのを参照していたかが謎。
     • 記憶が定かでないが、一時設定していたけど止めたのが どこかに残って居たのかも知れない。
   • あと、不勉強なため、逆引きは どこが標準(権威を持つ)サーバなのか分からなかった。このサーバのプロバイダなのだろうか?
     • サーバのプロバイダに問い合わせたら、想像どおり、このサーバのプロバイダにしか逆引き情報は設定できないとのことだ。

 

悪戦苦闘して何とかなったが、All In One WP Securityの ずさんさに呆れたしムカついたので使うのを止めたい。が、代わりの いいものを探すのが面倒だ。あと、DNSの逆引きの件は もう少し調べて勉強したい。

それにしても疲れた。。。

 

PS. 今朝、どうにか片付いて力尽きた頃に、UKの女王が亡くなられたようだ。その頃のツイートに、「BBCの出演者が みんな黒い服になった」というようなものがあった。

頭の中で、時々、(Queenの)"God save the Queen"(1975)が流れ、メイのちょっと寂しげなギターや最後の余韻のようなドラムに浸る。

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

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

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

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

---

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

2021/6/19-23, 2022/1/7 Butty

構成

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

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

全体的な構成図

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

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

全体的な仕様・特性

入出力

• ライン入力(非平衡, 入力インピーダンス: 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)
• ランプ
  • 電源ランプ: 薄オレンジ色
  • ミュート通知ランプ: 赤色

正面より

 

内部

 

付属品

付属品一式

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

• 特性測定用アダプタ
  • 出力端子: 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)

残留雑音の周波数特性

• 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

振幅の周波数特性

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

位相

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

位相の周波数特性

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

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

コメント

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

歪み(THD)

注: アンプ出力が小さい場合(例: 下の「常用出力」の11mW)、ADC入力が小さいため、サウンドカード固有の歪み(出力が11mW(ADC入力は-22.4dBFS)の場合、約0.0055%)からの余裕が小さくなり、歪み率の精度や信頼性が良くない。そのため、測定ごとに値が変わる。 (2022/1/7)

• 常用出力(約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)の周波数特性

• 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

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

緑: 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にならないため。

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

• アンプ部
  • アンプ本体: 音松 [LM3886 パワーアンプキット SP-100] (改)(http://www.otomatsu.jp/component/content/article/31-home/264-2014-01-21-13-00-50.html)
    • ゲインを10に変更した。
    • 電源の平滑コンデンサを2200μFx2に変更した。
    • 電源on時ミュート時間を伸ばそうとしてミュート用コンデンサを47μFに変更したが、無意味だった。
  • DCサーボ部: 音松 上記アンプキット用[DCサーボキット] (改)(http://www.otomatsu.jp/component/content/article/31-home/264-2014-01-21-13-00-50.html)
    • DC ±15V電源で使うため、3端子レギュレータ(2個)を外した。
    • 中低域の歪み増大を解消するため、ダイオード(4個)を外した。
• スピーカー保護部: 自作
  • オペアンプ: 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)が最も良かったので使っている。

測定に関して

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

• 周波数特性、雑音などの測定
  • 測定ソフト: REW 5.20
  • サウンドカード: ASUS Essense STX II
• 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 元電源について記載, クロストークにコメントを追記, いくつかの特性の代表値を記載, 細かい加筆・修正; 2022/1/7 14:38 全体的な構成図を更新し、歪み率に関する注意を追加した。)

 

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

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

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

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

(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>

(2022/1/27 15:11) 仕様・特性が確定したので、図・写真をWPに取り込んで通常の表示に変更し、プラグインBetter Find and Replaceを不要にした。

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

↓

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

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

少し詳しく書くと、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 (テーマの中などで使用可能)

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

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

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

要は、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

見ても「は??」であろうが、正規表現というもので、ワイルドカードの千倍以上便利だｗ 上で、"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 補足・修正)