やはり mac mini に作った ubuntu でディスク領域が足らなくなったのでメモ。
前はhttps://jinkouki.net/asiplease/2022/11/ubuntu-2204-on-vmware.htmlで、すでにある sda のサイズを広げるという手法だったが、今回は別ディスクを作成して、それを mount する形に。
これだと、不要になったら切り離せるし、イメージだけ持って行って別マシンにマウントすることも可能（？）かと。
といっても、このサイトを参考にしただけ。
https://www2.yukawa.kyoto-u.ac.jp/~koudai.sugimoto/dokuwiki/doku.php?id=ubuntu:%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%81%AE%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88
- vmware fusion 側で、まずは通常通り SCSI のディスク (今回は 70G) を作成
- マシンを再起動したら、/dev/sdb で見えることを確認
- mkfs.ext4 /dev/sdb で、 ext4 でまるごとディスクを1パーティションとして作成。 /dev/sdb1 が出来る。
- lbkid /dev/sdb1 で、uuid を調べる。
- /etc/fstabに記述
/dev/disk/by-uuid/$uuid /exthdd ext4 defaults 0 1
ぐらい？
screen5が出たということなので、これを FreeBSD-9 にまたインストールしてみた。そのメモ
これで、screen-5 がちゃんとインストールされた。ちょっと動かしてみたところ特に問題無く動いているっぽい。
いくつかの機器については、dhcpで固定アドレスを指定しておきたく、いままでは、
dhcp server rfc2131 compliant except remain-silent
dhcp scope bind 1 ip-address ethernet mac-address
と指定していたが、機器を再起動しても振られなくて、前に使っていたIPが割り当てられたりしていた。
ルータを再起動するとちゃんと振られるようだけど、毎回ルーターの再起動はちょっと困るので調べて見たら、よくある話のようで、
https://www.rocomotion.net/rtx1300-dhcp-setting/ を参照して、
dhcp server rfc2131 compliant except remain-silent use-clientid
dhcp scope bind 1 ip-address mac-address
と、'except use-clientid' を追加、また、ip-mac の対応について、'ethernet' を外してみたら、
ちゃんとリリース時に固定したいIPが割り当てられた。
特に何か問題があったわけではない（んなことない）けど、ドメイン名を 'mina2.sama.to' から 'jinkouki.net' に変更しようと思います。
MTの設定はあまりいじらず、document root も同じところを保持したままで。
https://mina2.sama.to/asiplease/ は https://jinkouki.net/asiplease/に。
'jinkouki' は、「塵劫記」から。ちりあくたのよしなしごとを記するのに。
dust.netとか garbage.net とかも考えたのですが。。。いつかそちらに変更するかも。
半角スペースに見えなくも無く、ちょっとプログラム書いたりしているときに間違いそう。
なのでちょっと探したら、こういうのを作ってくれている人がいる。
https://github.com/yuru7/udev-gothic
UDEV Gothic で、putty では 12point で表示がちょうどいいくらいになった。
ということで、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サーバへの接続にちょっと強い認証を行いたくていろいろ調べてる。
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にトライしてみる。
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 を残すか。
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 のようなので、こちらをコピーまたはシンボリックリンクで対処した。
そろそろ 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にアップデートするか。