As I Please

MTのいんすとーるの練習と、その他びぼうろく・・・

hostname の変更:mina2.sama.to から jinkouki.net へ

  • 投稿日:
  • by
  • Category:

特に何か問題があったわけではない(んなことない)けど、ドメイン名を 'mina2.sama.to' から 'jinkouki.net' に変更しようと思います。
MTの設定はあまりいじらず、document root も同じところを保持したままで。
https://mina2.sama.to/asiplease/https://jinkouki.net/asiplease/に。

'jinkouki' は、「塵劫記」から。ちりあくたのよしなしごとを記するのに。
dust.netとか garbage.net とかも考えたのですが。。。いつかそちらに変更するかも。

windows10 で iphoneの音楽を bluetooth で聞く。

なんか、ペアリングしても出てこないのでおかしいとおもったら、どうもデフォルトで、a2dp synk が無効になっててダメらしい。

https://note.com/sasimin/n/n7ab2e6891f8a
を見て、Bluetooth Audio Receiver をインストールしたら、iphone側から音楽(音声)飛ばせるようになった。

proxyのフロントに stunnel

ということで、proxy の サーバとしてssl client認証で resumptionが使えるものとして stunnelを利用してみることに。
設定は

[squidproxy]
accept = 8888
connect = 3128
cert = /root/cert/cert.pem
key = /root/cert/privkey.pem
;client = yes
verifyChain = yes
verifyPeer = yes
verify = 2
CAfile = /root/cert/cacert.pem
としてOKに。
clientは、stunnelが、上位proxyに対して sslcinetとして接続する場合に使うもののようで、
今回のように clientからの接続を受けつけるときは不要。
これをつけたら、clientからの接続に対して証明書を返さず接続を受けつけないことになった。CAfileには、クライアントから接続してくる(オレオレ)証明書のCA証明書を指定。
これでこのCAで署名したクライアントからのみの接続を受けつけることに。

これで、windows10 だと、Edge,Chromeからの接続については、一度認証のために証明書の選択を聞かれるが、1回選択したらその後は聞かれないようになって問題なく使えるようになった。
ただ、この stunnelのクライアント認証、今度は Firefoxだと接続してくれなくなってしまった。Edge,Chormeは エンジンが chronium系ということでうまくったのか?

proxyの x509証明書認証 のフロントにsocat

proxyサーバへの接続にちょっと強い認証を行いたくていろいろ調べてる。
squidでも、cacert,capath,verifyなどあるみたいだが、うまくいかない。
古いバージョンだと、何かそのdirectiveもあったようだが。。。

claudeあたりに聞いてみると、squidそのものを推奨せず、
stunnel + squid,nginx とか、haproxy,nginx,apache のproxy機能をすすめてきたりしているが、、、。

とりあえず、 軽そうな socat で受けて、後ろの squidに流せばいいかと思って、テスト。

#flags="-d0 OPENSSL-LISTEN:8888,reuseaddr,fork,cafile=(client認証のためのオレオレ証明書のCAのpem),cert=(サーバーとして振る舞うため、その証明書のcert),key=(サーバー証明書の秘密鍵) TCP4:127
.0.0.1:3128"
として、localhost で待っている squid(port 3128) にリレーする設定とした。
proxyのセッションは複数張られるので、forkしてどんどん受けつけるようにした。

ところが、この、ブラウザからproxyとして接続してくるときに、クライアント証明書(PCにはインストール済み)で認証しているのだが、windows11 では接続時に自動的には渡してくれず、Edge,Chromeだと新たなセッションを張る度に認証ダイアログが出る始末。Firefoxはどうも自動的に渡しているようで、こちらは出なかった。

TLSのネゴシエーションのreusumption問題?らしく、過去のTLS接続時のデータをキャッシュして使うのが王道らしいが、socat はそこまでのことはやってくれないらしい。fork するだけならその通りだな。。。
TSLネゴシエーションのデータを、親プロセスで管理して、子供のセッションの認証時に共有してくれるタイプじゃないとつらそう。

結論としてはsocatをweb browser のプロキシーのフロントに置くのはおすすめしない、ですかね。
次は軽そうな stunnelにトライしてみる。

erc (emacs e-lisp irc client) が繋がらなくなった。

nadokaを使って ircに常駐していて、clientとして emacs 標準の ercを使っていたが、freebsd-14に上げたら繋がらなくなった。nadokaはちゃんと動いているのだが、ercが接続するときに ERC:closed という状況になっておかしい。

問題は、freebsd-14ではなくて、emacs-29 の標準の ercのバージョンが上がったことによるみたい。
emacs-29の ercのバージョンは 5.5 のようで、これには、server id を使う設定が増えていてこれが過去との互換性がなかったよう。
emacs-28 を /usr/local2 にインスートールしてしてみたところ、こちらのバージョンは 5.4で、これだとこれまでの設定(init.el) がそのまま使えて繋がる。
erc-server-alist あたりをちゃんと設定すればいいみたいだけど、、、面倒だからこのまま /usr/local2 を残すか。

ruby インストール(その他起動時)に openssl 関連のエラーが出る。

freebsd9に、ruby22 しか入っていなかったので、いきなり最新の3.3を入れようとした。
git cloneで srcを持ってきて、buildの mdに書いてあるように行ったが何かうまく逝かないことが多い。

httpsでファイルを持ってこようとしているところで、issure error が出ているのでなんだろう?と
思って探したが、
https://blog.takuros.net/entry/2014/05/17/172257
だったようで、rubyがデフォルトで見ている CAファイルが存在しなかった!
ここにあるように、

ruby -ropenssl -e "p OpenSSL::X509::DEFAULT_CERT_FILE"
を実行したら、"/usr/local/ssl/cert.pem"と返してきたが、こんなところにこんなファイルは存在していない。
それらしいのは、/usr/local/share/certs/ca-root-nss.crt のようなので、こちらをコピーまたはシンボリックリンクで対処した。

MovableType update 8.0.2 へ

  • 投稿日:
  • by

mysql8 に無事上がったので、次は MT8へ。
単に mt/以下を全て置き換え、mt-check.cgi で確認、mt-config.cgiもそのままで。
サイトすべて再構築してみたが特に問題無さそう。
あっさり普通に動いてくれたっぽい。

movabletype mysql5 から mysql8 へ

  • 投稿日:
  • by
  • Category:

そろそろ mysql5系列も終わりで、mysql8のほうがパフォーマンスが良いというので移行しようとしたが、単純にデータのバックアップ、restoreだと文字化けしてうまくいかない。webを探してみてもこれと行ってうまく行った例が無いような。table単位でこちょこちょ文字コードを直すとかやるなどあるが、それでもうまくいかない。
MT4のころから使ってきたのでmysqlも4,5とメジャー、マイナーバージョンアップしてきたが、最初はたしか 設定はutf8とはいえ、DB側とのやりとりはlatin1でほぼバイナリデータとして使ってきていたっぽい。
latin1のデータを良く見ると、中身はutf8データっぽいので、latin1 で mysqldump して mysql8にそのまま入れてがダメ、utf8で dumpして latin1,utf8でrestore してもダメ。

1年くらいこの問題を寝かしていたが、さすがにそろそろちゃんと解決しておかないとな、と思って試行錯誤。

結局、mysql5 からdumpしたデータに、

/*!40101 SET NAMES latin1 */;
というのが入っている(入っているが、ファイルの中身は utf8っぽい)ので、これを除去(grep -v)して、
これを mysql8 に流し込んだところ、どうもうまくいった。
phpmyadmin で見ても、mysql5では文字化け(だが、MTの管理画面、再構築後のコンテンツは文字化けしない)だったが、今度はちゃんと文字化けせずに表示される。かつ、管理画面も再構築後のコンテンツも特に問題ない。

長年ひっかかっていた文字化け問題、とりあえずこれで解決か。
次は、MT7から MT8にアップデートするか。