65 lines
11 KiB
HTML
65 lines
11 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="ja">
|
|
<head>
|
|
<meta charset="utf-8"/>
|
|
<title>スタイルのないメモ</title>
|
|
</head>
|
|
<body>
|
|
<h1>スタイルのないメモ</h1>
|
|
|
|
<div>
|
|
<h2 id="2025">2025年</h2>
|
|
|
|
<div>
|
|
<h3 id="20250112">1月12日</h3>
|
|
|
|
<p>しばらく間がまたあいたが、これには訳がある。普段Windows11上のWSL2を利用して生活をしているが、そのWindowsのPCが遅くなった。Dellのなんらかのメンテナンス用のプログラムが悪さをしているようで、ディスクアクセスが常に100%になる状況が続き、使用に耐えられない状態になった。ので、Windowsを再インストールしていた。</p>
|
|
<p>まぁ、これくらいならば、別にこのメモを書かない理由にはならないだろう。現にその作業自体は数時間で終わった。</p>
|
|
<p>問題はWSLである。私はYubikeyを利用していて、当然のことながらWSL上でも利用している。gpgの鍵をYubikeyに格納し、私が使っているパスワードは<a href="https://www.passwordstore.org" target="_blank">pass</a>で管理している。passの実態はgpgによるパスワードの暗号化であり、要するにyubikeyが使えないと全てのパスワードが利用不可能な状態になる、ということである。そして、passはこのWindowsのマシンでは、WSL上でのみ利用している。</p>
|
|
<p>で、YubikeyをWSL上で使うために、<a href="https://github.com/dorssel/usbipd-win" target="_blank">usbipd-win</a>を利用しているのだが、こちらはなんなく動作した。そしてWindowsを再インストールしたところ、これまでYubikeyをWSLで利用するために、カスタムカーネルを利用していたのだが、通常のカーネルでも動作することに気がついた。その昔、<a href="https://1-bit-wonder.github.io/blog/how-to-use-yubikey-with-wsl/How%20to%20use%20Yubikey%20with%20WSL%20via%20USB%20passthrough/" target="_blank">こちらのブログ</a>を参考にしてYubikeyをWSL上で使えるようにしたのだが、その時に必要だった、CONFIG_HIDRAWの有効化が、現在のカーネルの設定ではデフォルトで有効になっているらしい。</p>
|
|
<p>ならば簡単だ、と作業をすすめていったのだが、<code>ykman info</code>は動作するが、<code>gpg --card-status</code>は利用できない、という状態でしばらくはまっていた。<code>pcsc_scan</code>ではきちんとYubikeyが見えるのに、なぜかgpgからアクセスできない。困った。</p>
|
|
<p>困ったなぁ、とWSLのいろいろなバージョンをコンパイルしては失敗し、なぜだろうと頭をかかえていたのだが、結局原因はアクセス制御の問題だった。<a href="https://www.redhat.com/en/blog/controlling-access-smart-cards" target="_blank">Controlling access to smart cards</a>というレッドハットの記事があり、どうやらpolkitの設定をしないとpcscdにアクセスできないようで、実際に設定をしたら動作した。カーネルは全く関係がなかったのだ。</p>
|
|
<p>で、パスワードへアクセスできる状態をとりもどし、<a href="https://www.snthtns.jp/gitea" target="_blank">うちの物置</a>に置いてあるこのページのソースを、この問題のPCにcloneし、今この文章を書いている。</p>
|
|
<p>まぁ、他の端末で書けばよかったのでは、というごく当然のつっこみもあるだろうが、それについては知らないふりをするつもりだ。とにかくこのPCの復旧を喜ぼう。ちなみにこのPCは、Alienware Area-51mで、買ってから随分経つが、気に入っていてまだ使っている。あと数年は使うつもりだ。</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h3 id="20250104">1月4日</h3>
|
|
|
|
<p><a href="#20250102">前回</a>、「とはいえ様々な設定はなんとなく動かした、という感じで最適化しているわけではないので、まだまだチューニグが必要だろう。と、思いつつ、多分放置してそのままになるのだろうなぁ、と思っていたりする。」とか悠長な事を書いていたが、結果はボロボロ、サーバが落ちたりしたので、いくつか設定したところ、ようやく落ち着いてきた。</p>
|
|
<p>relaydや他のサービスがたまに落ちた。それはファイルディスクリプタの上限を上げたら解決した。</p>
|
|
<p>画像の変換をImageMagickからlibvipsへ変更したらロードアベレージがほぼ1を越えないくらいで稼働できるようになった。これはめちゃくちゃよい。OpenBSDの場合、gem、ruby-vipsがlibvips.so.42がないとエラーを出したので、シンボリックリンクをはった。</p>
|
|
<p>あと、redisが"max number of clients reached"とか言い出したので、設定ファイルにtimeoutの値をいれてみた。</p>
|
|
<p>そんな感じに、発生したエラーに場当たり的に対処していった他、サービスが落ちた場合に再起動するようにしたりした。</p>
|
|
<p>メモリ4GのVPS上のUbuntuでmastodonを稼働させていたとき、elasticsearchもそのサーバに同居させていたのだけれど、たまに落ちていたので、今回はelasticsearchは外に出した。こちらは何も手をいれないでもきちんと動いている。</p>
|
|
<p>本当はこの休み中に、自宅サーバのネットワーク構成も変更しようと思っていたのだけれど、こちらは手付かずだった。まぁ、一つでもやろうとしていたことができたので、よかったとしよう。で、よかったとしよう。</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h3 id="20250102">1月2日</h3>
|
|
|
|
<p>さて、年末の休みにはいってから、今現在まで、<a href="https://mastodon.snthtns.jp/" target="_blank">うちのmastodonサーバ</a>をOpenBSDで動かすための作業を行なっていた。とはいえ、お酒を飲みながらちびちびやっていたので、あるいは他の用事で出掛けたりして、なかなか作業がすすまなかった。</p>
|
|
<p>nginxを使えばもう少し楽だったのだと思うけれど(何しろ設定ファイルがプロダクトの中で管理されているのだから)、それだとOpenBSDで動かす意味もなかろうと思い、relayd.confとhttpd.confをせっせといじっていた。加えて、systemdがあるわけもなく、こちらもせっせといじっていて今に至る。とはいえ様々な設定はなんとなく動かした、という感じで最適化しているわけではないので、まだまだチューニグが必要だろう。と、思いつつ、多分放置してそのままになるのだろうなぁ、と思っていたりする。</p>
|
|
<p>他、結構ポカミスをやっていたりして、なによりも、移転先のサーバの、mastodonのブランチを間違えていた、というのが決定的なやらかしだった。なにしろ起動しない。本人はブランチを正しいと思いこんでいるのでなぜ起動しないのかが分からない。Railsのエラー自体はなんかrelationがない、とかいっているので、データベースの移行に失敗したのか、と明後日の方向に意識が向き、そしてそのあと年越しの初詣に行く用事もあったので、結局その時点では切り戻し。朝に家に帰ってきて、寝て、夕方に起きて、お雑煮にを食べて、お酒を飲んで、またちょこっと寝て、1月2日の0時くらいに再度トライをしはじめてエラーを眺めていて原因に気づいた、という状況。</p>
|
|
<p>で、そちらの作業をしながらこのメモを書いているのだけれど、起動したっぽい。けれどもなんか他のサーバの画像が取得されているような、されていないような気がする。まぁ、動いていそうだからいいか。</p>
|
|
<p>なんか実況中継みたいだけれど、上の1文を書いてから調べてみたら、ImageMagickがはいっていなかった。うーむ。3回くらいサーバを再インストールしたりしていたので、いつの間にか手順から抜けてしまった。場当たり的にやっているとこうなるのね。</p>
|
|
<p>と、なんだかんだドタバタしていたけれど、とりあえず作業は終わったっぽい。まだ何かあるかもしれないけれど、それは起こってから考えよう。</p>
|
|
<p>ということで、今年もよろしくお願いします。</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<h2 id="2024">2024年</h2>
|
|
|
|
<div>
|
|
<h3 id="20241225">12月25日</h3>
|
|
|
|
<p>今年も終わるので、今年はじめたこと、を何か最後に追加したくて、ブログっぽいメモ的な文章を書くことにした。まったくもって気紛れなので三日坊主になるかもしれないが、最低1ヶ月に1回更新するということにすれば、多分三日坊主にはならないだろう、という謎理論で三日坊主を回避しようと思う。</p>
|
|
<p>スタイルのないメモ、とあるように、基本的にCSSを一切使わないページにする。たまには20世紀の最後の頃に戻って、手書きでHTMLを書いてもいいだろう。それならば<a href="https://geminiprotocol.net" target="_blank">Gemini</a>ページを作ればいいのでは、と言われれば、反論する術はない。本当にそうだと思うけれど、そして今後そのようなことをしはじめるかもしれないけれど、まぁ、今はこのindex.htmlを編集していこう。</p>
|
|
<p>昔は日記サイトがごまんとあり、初めてホームページを作ると、掲示板と日記のリンク、そしてなによりもリンク集のページを追加することがならわしだったように、個人的な記憶の中の範囲では、思う。そもそも今日検索サイトの検索結果のリンクに個人のホームページを目にすることはほんとんどない。HTML直書きのページなど希少だろう。希少だとはいえ、このページに価値があるのか、というとそんなことはない。ただただ愚にもつかない駄文を連ねていく所存である。</p>
|
|
<p>しかも日記を書くつもりもあんまりない。自分の日常を開示する趣味はなく、<a href="https://mastodon.snthtns.jp/@hhh" target="_blank">mastodon</a>の方もほんとんどは新宿御苑の写真だらけだ。よって、結果的に日記となったメモも出現するだろうが、それは趣旨ではない。</p>
|
|
<p>まったく話は変わるが、googleの文字コードがShift_JISなのは、IE対策なのだろうか。ほんまかいなと思った方は、<code>curl https://www.google.co.jp/ | nkf -g</code>の結果を見てみると良い。少なくともこの文章を書いている今現在、<code>Shift_JIS</code>という文字列が返ってくる。</p>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|