Linux

表題の通りですが、Wordpressやめました。 以前からやめたいな〜とは思っていたのですが、色々思うところがあり一気に実施しました。 旧来の記事が壊れているかもしれませんが、そのうち直します。。。

やすかったのでつい・・・ 購入の（いい）わけ 以前、GPD P2 MAXが壊れつつある話を書きました。 GPD P2 MAXが壊れつつある日記 代わりになるパソコンほしいな〜とは思っていたのですが、小さい端末はそもそも高いですし、フル機能パソコンである必要もないな、と思っていたので使い物になるかも含めてお試しに、というところです。 購入したのは今年初め辺り？から中古という名目でほぼ新品のものが投げ売りされている、Lenovo 14e Chromebook Gen 3 です。 物自体は2023年の商品で、Softbankから5G対応品として販売されているのが特徴ですね。 調べていて分かったんですが、同じ名称でWWAN非対応、性能が増強されているモデルもあるようです。 本体についてのレビューは沢山の方がされているのでそちらを見てもらうとして。液晶画面はIPSなど高輝度/広視野角なものに慣れきった今、下手したらブラウン管並みのノスタルジーを感じるぐらいイマイチですね。そんなことない？そう…。 VS Codeとかの日本語入力 ChromebookということでOSはChromeOSなのですが、開発用という名目でLinuxコンテナを動作させる仕組みがあります。内部ではLXCっぽいアレになっているそうです。 VSCodeが動きそうな話は事前に調べていたので、早速入れてみたのですがなるほど日本語入力が効かない。 ググると分かりますが、ChromeOSからLinuxアプリに対する日本語入力は昔から少し難があったようで、古くはLinuxコンテナ側でIMを動作させていた様子。2023年頃からは、cros-im？という仕組みが標準になりChromeOS側のIMを使うことができるようになったそうです。 それ以降に書かれた記事では、VSCodeはそのまま日本語入力できるようになった、みたいな記述が多く困っていたところ、ChromeOSにおいてもLinuxアプリはWaylandとX11でcros-imの挙動が変わる的な話を発見。（URL失念。。。） 確かに、ネイティブなLinux環境でもその辺でみんな（誰？）悩んでいるのはよく見ます。 というか、多分そういうことなんだろうなとは根拠なく思っていました。 試しに以下で起動してみた結果、日本語入力が普通に動作しました。 code --ozone-platform=x11 Waylandにこだわっているわけでもないですし、これでいいか、と。 ChromeOSは、Linuxコンテナ内で作られたdesktopファイルを読んでメニューにアプリアイコンを出している？そうです。ということで、基となるdesktopファイルのExec行を直接編集して、上記引数を追加してターンエンドです。やったぜ。 VSCodeでGithubアカウントへログインしようとしたところ、keyring周りのエラー。 ストレージ暗号化されているし弱い暗号化？で保管されても構わないよ〜とは思いつつ、gnome-keyringインストールしているのにな〜と。 ということで以下ドキュメント参考にargv.jsonへ設定追加で解決。 https://code.visualstudio.com/docs/configure/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code WWAN（5G）でDocomo回線を使う せっかくですのでWWAN機能も使いたいですよね。 ChromeOSはAndroidのテザリングを遠隔で有効化できるので、WiFiだけでもそんなに苦労はしないのですが…。 個人の都合で、SB回線のSIMはメイン機で使ってしまっているため、余っているIIJmio type Dあたりを使いたいところです。 APNなどを適当に**（フラグ）**設定してみたのですが、どうにも「モデムが登録されていません」だの「有効期限が切れている」だの出てきてうまく繋がりません。 調べたところChromeOSは、SIMロック時モバイルデータの設定画面に特定のキャリアしか使えない旨の表示が出るらしいです。つまりとくにSB限定になっているわけでもなさそう。 さて困ったな…と思いpovoのSIMを入れてみたところ接続されるじゃありませんか。えぇー(´・ω・｀)となりましたが、動作にキャリア差があるということはAPN設定周りの可能性が高いなと思案。IIJのサポートサイトをよく見ると、ありましたよ。Windows用の設定ページをよ〜くみると… 画像で。すんげえちっちゃく。 APNの種類 （タイプDの場合）インターネットおよびアタッチ （タイプA）インターネット そしてChromeOSのモバイル設定画面が以下。 すでにチェックが入っていますが、「Attach (IA)」はデフォルト無効です。 Androidにはそんな設定ないじゃんねえ(ヽ´ω`) きれいにフラグを回収しましたとさ。同じ轍を踏むな…！ 俺達のChromebookカスタムはまだまだこれからだ！！ Holloのほうでも書いていたのですが、ChromeOSのこういうチマチマしたカスタマイズ、りなざうで遊んでるときの感覚に近いですね。たのしい。 ChromeOSふっ飛ばして遊ぶというのも中々楽しそうなんですが、しばらくは普通に使ってみようかなあというところです。

前回、記事中に「旧サーバについては、ファイル移行中のフォールバック目的です。ファイル移動が終わったら削除可能です。」と書いていました。しかし、「削除可能」なのは、以下のようなリモートのキャッシュに記載されている旧URLアクセスへの対策を実施済みの前提となります。（書きわすれてた。） すでにローカルストレージで運用しているMastodonサーバの場合、リモートのサーバにキャッシュされている投稿の内容は、古いメディアURLを参照しています。 ここは書き換わることがありません。どのぐらいの期間、投稿をキャッシュするのかもリモートサーバ次第です。 ※基本ずっと残るものと考えたほうが良いでしょう。。 そのため、本来であればローカルストレージ上にすでにアップロードされている画像などのデータを残したままにする必要があります。しかし、それではせっかく移行したのに面倒で取り回しが悪いです。 悪い設定が増えてしまいますが、下記のように当該の旧URLへアクセスが合った場合、内部でオブジェクトストレージを参照するようにします。 尚、投稿やアカウント自体の削除に伴う画像の消去は考慮していません。使い方によっては危険なので、留意すべきです。 バケット内にoldという名前をつけ、そこに旧URLで参照させたいファイルをコピーします。 Mastodonのnginx（通常のセットアップで作成するリバースプロキシ）の前段に、HAProxyを配置する設計です。 Mastodonのnginxだけでも似たようなことは簡単にできると思います。Mastodonと密なnginxか、疎なHAProxyか、どちらの設定がどの程度複雑になるかを想定してを選ぶと良いかもです。 （前段にMastodonと疎結合なリバースプロキシが存在すると、VMのマイグレやマシンの更改時などに非常に便利とおもいますので、趣味が合う（？）方は是非。） まずMastodonの通信を受けるFrontendを作成します。 frontend don-tls-fr http-request set-header X-Forwarded-Proto https http-request set-header X-Real-IP %[src] #本来のヘッダの使い方と違うのでここはお好みで http-request set-header X-Forwarded-For %[src] http-after-response add-header alt-svc 'h3=":443"; ma=31536000' #IP直打ちとかhostが違うときはこっち（設定例未記載） default_backend error-bk bind *:443 ssl crt pemファイルフルパス alpn h2,http/1.1 bind [::]:443 ssl crt pemファイルフルパス alpn h2,http/1.1 bind quic4@:443 ssl crt pemファイルフルパス alpn h3 bind quic6@[::]:443 ssl crt pemファイルフルパス alpn h3 #仮想的に旧Media URLでもアクセス可能とする措置 acl ismastodonlocalfile path -i -m beg /system/media_attachments/ acl ismastodonlocalfile path -i -m beg /system/accounts/ #カスタム絵文字はあまり使っておらず、移行時に全て削除してしまったので以下で正常に移行できるかは謎。コメントアウトしておきます。 #acl ismastodonlocalfile path -i -m beg /system/custom_emojis/ acl ismastodonlocalfile path -i -m beg /system/site_uploads/ #旧URL（/system/ 配下）のCache以外のアクセスをobj-bkへ転送 use_backend obj-bk if { req.hdr(host) 丼FQDN } ismastodonlocalfile #通常アクセス use_backend don-bk if { req.hdr(host) 丼FQDN } 次にオブジェクトストレージと、Mastodon自体へのアクセスを行うBackendです。 ...

Mastodonのオブジェクトストレージとして利用してみるやつ。 Wasabiは2023年春ごろからPublic accessが原則使えなくなっています。詳細は以下参照。 Wasabiのパブリックアクセスが使えなくなった件（対応の仕方） 上記の@noellaboさんの記事では、nginxとlua（openresty）を用いた対応例が示されていますが、今回は別のアプローチとして表題の通りHAProxyを用いたゲートウェイを作ります。 https://github.com/jouve/haproxy-s3-gateway/blob/main/haproxy/haproxy.cfg 上記の「s3v4」と「upstream」をほぼそのまま利用します。set-var-fmtがHAProxy 2.5以降の実装であるため、標準で新し目のバージョンが入らないOSをお使いの人は適宜対応してください。 万が一アクセスキーなどが漏れても参照しかできないように、必要最低限のキーをWasabiで作成してそちらを利用します。 また、WasabiのEndpointのIPが変わっても動作するよう、resolverの設定を追加します。HAProxyはresolver設定を行わないと、プロセス起動時に名前解決を行ったきりそれ以降DNSへの問い合わせを行わない、という挙動を示します。（2.0等といった昔の版は確実に。最近のはちゃんと調べていないです。） 今回、Proxyを動作させるOSは既存弊Mastodonサーバと合わせてUbuntuとしたので、以下を参考にppaを追加します。 https://haproxy.debian.net/ また、上記の設定例だとアットマークを含む画像（サーバのaboutページなどに使われている）がうまく表示されないため、以下のようなFrontendを追加し、そちらを443待ち受けで使用するように変更。 また、backendも追加し、redispatchオプション+retry-onオプションによりオブジェクトストレージ側で404やリトライ可能エラーが出た場合に旧サーバ（非オブジェクトストレージ）の参照やエラー画像を返すサーバを指定しています。（旧サーバについては、ファイル移行中のフォールバック目的です。ファイル移動が終わったら削除可能です。　※2024/2/16追記記事を公開したのでリンク） frontend fr-1 bind :::443 v4v6 ssl crt <pemファイルなど> alpn h2,http/1.1 http-request set-path %[path,regsub(@,%40,g)] http-request set-var(txn.path) path acl ismedia var(txn.path) -i -m end png acl ismedia var(txn.path) -i -m end jpg acl ismedia var(txn.path) -i -m end jpeg acl ismedia var(txn.path) -i -m end bmp acl ismedia var(txn.path) -i -m end gif acl ismedia var(txn.path) -i -m end jfif acl ismedia var(txn.path) -i -m end webp acl ismedia var(txn.path) -i -m end mp4 acl ismedia var(txn.path) -i -m end avi acl ismedia var(txn.path) -i -m end mpg acl ismedia var(txn.path) -i -m end mov acl ismedia var(txn.path) -i -m end mkv acl ismedia var(txn.path) -i -m end flv acl ismedia var(txn.path) -i -m end webm acl ismedia var(txn.path) -i -m end m4v http-response del-header X-Amz-Id-2 http-response del-header X-Amz-Request-Id http-response del-header X-Wasabi-Cm-Reference-Id http-response add-header Access-Control-Allow-Origin * if ismedia http-response add-header X-Nsd-IsMedia Yes if ismedia http-response add-header X-Nsd-IsMedia No if !ismedia default_backend bk-1 backend bk-1 balance first option redispatch retry-on 404 all-retryable-errors server listen-wasabi localhost:8081 check server listen-origin-cache localhost:8082 check server listen-error-bk localhost:8083 check Mastodon側では以下のように.env.production（など）へWasabiのEndpointや書き込み可能なAccessKey、参照用FQDNの指定などを行います。 ...

しらんかった　こわいね　正しくはAdvertiseというらしい。 SwitchbotのAPI叩いてPlug miniの電力とか取りたいな～と適当にQiitaを参考にcurlでAPI1.1を叩くスクリプトを作っていたのですが、レートリミット（10k per day≒1 request per 8.6 sec）や値の即時性が怪しく感じたのでBLEで直接取得できないかと調べていました。 結果、できそうではあるものの、どうもコード的に認証とか何もないように見受けられたので、おや・・・？と思い確認したところ、表題の通りの動作をしているようです。 読めた図 ※リンク先コードのscannerに渡す引数を.scan(10,passive=True)に変更しています。おそらくGnome側のBluetooth管理に引っ張られていてうまく動かなかった。 これ、例えば部屋の間接照明の制御やパソコン等の消費電力測定目的なんかにつかっていると、悪人が狙えばそこそこの確度で在宅かどうかが判断できちゃったりしそうですね。 在宅がわかりそうなデバイスにはPlug miniを使わないようにしましょう。 追記 ちなみにうちのPlug miniは上記リンク先ブログのものとは異なるEspressifのOUIでBroadcastされていました。ESP系の市場規模から考えるとそりゃそうかと言う感じではある。。 上記コードではMACがわからないとだめだけど、少し書き換えてEspressifのOUI見つけたらとりあえず上記ルールでデコードしてみる、とかやると、街中でもいろいろなスマートプラグなんかを見つけられそうですね。やらないけど。 追記2 このへんで絞ればより探しやすいっぽい。やらないけど。 https://bitbucket.org/bluetooth-SIG/public/src/a02d375ef4a70852f663c2e7d8e18bd863374ed7/assigned_numbers/uuids/member_uuids.yaml#lines-935 https://bitbucket.org/bluetooth-SIG/public/src/a02d375ef4a70852f663c2e7d8e18bd863374ed7/assigned_numbers/company_identifiers/company_identifiers.yaml#lines-2985 Ｗｏａｎ　Ｔｅｃｈｎｏｌｏｇｙ　（Ｓｈｅｎｚｈｅｎ）　Ｃｏ．，　Ｌｔｄ． →技適検索で「214-116028」

MaxMind社への登録他は適宜実施。 # mkdir -p /opt/geoip/vol # mkdir -p /root/geoip # cd /root/geoip # cat << EOT >.env GEOIPUPDATE_EDITION_IDS=GeoLite2-Country GEOIPUPDATE_ACCOUNT_ID=<MaxMind ID> GEOIPUPDATE_LICENSE_KEY=<MaxMind License key> GEOIPUPDATE_FREQUENCY=72 EOT # docker run --env-file /root/geoip/.env -v /opt/geoip/vol:/usr/share/GeoIP --name geoip_update --detach --restart always ghcr.io/maxmind/geoipupdate # git clone https://github.com/ntsklab/geoip2-haproxy-ranges # docker build -t geoip2-haproxy-ranges . # docker run -d --name geoip_convert_csv --restart always -v /opt/geoip/vol:/usr/local/var/GeoIP geoip2-haproxy-ranges:latest HAProxyへ以下のような設定を入れる ここは自由に。 frontend XXXX acl isjp src -f /opt/geoip/vol/output/JP.txt acl isadminpath path -i -m sub /wp-admin acl isadminpath path -i -m sub /wp-login.php acl isadminpath path -i -m sub /xmlrpc.php acl isadminpath path -i -m sub /wp-signup.php acl isadminpath path -i -m sub /wp-activate.php http-request reject if !isjp isadminpath 終わり ...

様子見。 in-deep.blue はTLSオフローダとしてHAProxyを利用しておりますが、Debian Backports上にある2.6系から自前ビルドの2.8系に更新してみました。 2.8になって何が嬉しいかというとQUICの本対応です。（他にも色々ある） 実は2.6系から一応使えはしたのですが、Backportsのものは非対応です。どうせビルドするなら新しいものを・・・というやつです。 一応動いているように見えていますが、どこかで不具合が起きたら無効化します。 Mastodonも（見かけ上）QUICで接続されます。なおBackendは・・・（手抜き。） 追記 ビルドめも cd wk/openssl git pull git checkout opensslばーじょん ./Configure --libdir=lib --prefix=/opt/quictls linux-x86_64 make -j2 make -j16 install cd ../haproxy-2.8 git pull make TARGET=linux-glibc \ USE_LUA=1 \ USE_PCRE=1 \ USE_ZLIB=1 \ USE_SYSTEMD=1 \ USE_PROMEX=1 \ USE_QUIC=1 \ USE_OPENSSL=1 \ SSL_INC=/opt/quictls/include \ SSL_LIB=/opt/quictls/lib \ LDFLAGS="-Wl,-rpath,/opt/quictls/lib" ./haproxy -vv make install-bin cd admin/systemd make haproxy.service cp ./haproxy.service /etc/systemd/system/ mkdir -p /etc/haproxy mkdir -p /run/haproxy 2023/12/07 HAProxyの設定例も追記。 ...

今更ながら、ワイルドカード証明書が無料ってすごい時代ですね。 弊ドメインはマネージドなDNSサービスとしてGehirn DNSを利用しております。 https://www.gehirn.jp/dns/plan/ 安価にAPIなどで操作可能なマネージドDNSが利用できるので非常に便利です。 また、証明書は無料のLet’s Encryptを利用しております。（超弱小自己満個人サイトのため、これで十分です。） 今まで、VPSにおいてはin-deep.blueのみの証明書を用いていましたが、先日のVPS事業者移行よりHAProxyを導入し、自宅を含めたサーバ系ネットワークの構成を変更しました。 それにより、サブドメイン運用の各種サーバ（Mastodon sv1.in-deep.blue等）もHAProxyで通信の振り分けを行いたく思い、今回ワイルドカード証明書を取得することとしました。 Let’s Encryptでのワイルドカード証明書の取得については、基本的にCertbotの公式手順に従えばOKですが、使用するソフトウエアを選択させるくせに設定すべき内容がちゃんと出てこないため、ちょっと微妙でした。（整備しきれないなら選択肢作らずOthersの内容だけでいいんじゃないの、と。。。） Let’s Encryptにてワイルドカード証明書を取得するには、dns-01チャレンジを行う必要があります。 さて、先述したCertbotですが、プラグインでGehirn DNSの操作に対応しています。 https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins これにより、非常に簡単にワイルドカード証明書が取得できます。 設定方法は、Wikiにある通りGehirn DNS操作可能な権限を与えたAPI静的トークンを適宜セキュアに別ファイルへ保存し、--dns-gehirnオプションの指定と、--dns-gehirn-credentialsオプションにパスを渡すだけです。 あとは、以下の通りコマンド実行で、dns-01認証が可能なはずです。（ログとってなかった。かなしい。） # certbot certonly --dns-gehirn --dns-gehirn-credentials <クレデンシャル情報ファイルパス> -d *.in-deep.blue -d in-deep.blue -m <めーるあどれす> 発行された証明書は /etc/letsencrypt/live/in-deep.blue/ 配下に、最新版へのシンボリックリンクが作成されます。 # ls /etc/letsencrypt/live/in-deep.blue/ README cert.pem chain.pem fullchain.pem privkey.pem さて、証明書は無事発行できましたが、これをHAProxyへ食わせるためには更にひと手間必要です。 It designates a PEM file containing both the required certificates and any associated private keys. This file can be built by concatenating multiple PEM files into one (e.g. cat cert.pem key.pem > combined.pem). If your CA requires an intermediate certificate, this can also be concatenated into this file. Intermediate certificate can also be shared in a directory via “issuers-chain-path” directive. ...

こちらも参照 Ubuntu 20.04他で用いられているudisks2の自動マウントを無効化（備忘録） $ gsettings list-schemas | grep media-hand org.mate.media-handling org.gnome.desktop.media-handling $ $ gsettings get org.mate.media-handling automount true $ gsettings get org.gnome.desktop.media-handling automount true $ $ gsettings set org.gnome.desktop.media-handling automount false $ gsettings set org.mate.media-handling automount false

udisks2自体を（サービスまるごと）止める方法ばかり案内されていて、本質的な情報がなくて困ったのでめも。画像は試行錯誤の痕跡（？） udevルールに以下を追加 ENV{UDISKS_AUTO}="0" 以上。サービス止めて息の根封じる方法だとディスク管理画面（udisks2のフロントエンド？）が機能しなくなるので困りますよね。 こちらも参照。 Debian 11 Gnome/mate自動マウント無効化（備忘録）