なんとなく動いている。 https://hl.oyasumi.dev/@ntek Holloとは 以下を参照。 https://docs.hollo.social/ja/intro Kubernetesで動かして何が嬉しいか Holloは基本的に一人用サーバのため、現状ではあまり嬉しいことはないように思える。ただ、弊環境はDocker等のコンテナ基盤が常時動作していないため、Kubernetesに載せた。 使用したKubernetesディストロとオペレータ等 k0s + Cilium CNI + Cloudflare tunnel ingress controller + CloudNativePG + NFS CSI セットアップ Holloは現在、S3互換オブジェクトストレージを必要としている。今回はCloudflare R2を使用。 HolloはHelmの提供を目指している？様子だが、まだ無いのでとりあえずYAMLで書いていく。 Containerが同時に起動してDBにアクセスすると恐らく壊れるので、DeploymentのストラテジをデフォルトからRecreateへ変更する。※k8sドキュメントにあるように、これではContainerの単一性は保証できないので本来はStatefulSetを使用すべきである。 Hollo本体 kind: Deployment apiVersion: apps/v1 metadata: name: hollo-app namespace: hollo-1 spec: strategy: type: Recreate replicas: 1 selector: matchLabels: app: hollo template: metadata: labels: app: hollo spec: initContainers: - name: wait-db image: busybox:latest imagePullPolicy: Always command: ['sh', '-c', 'until nc -z hollo-db-cluster-rw 5432; do echo waiting for hollo-db-cluster-rw; sleep 2; done;'] containers: - name: hollo image: ghcr.io/fedify-dev/hollo:<strong><version></strong> imagePullPolicy: IfNotPresent envFrom: - configMapRef: name: hollo-config ports: - containerPort: 3000 resources: limits: cpu: "2" memory: "2048Mi" volumes: - name: hollo-config configMap: name: hollo-config Service（宅内からの試験用にCiliumのLoadbalancer機能を使用。Calico等の人はMetalLBとか、よしなに。今回のようにCloudflare tunnel Ingressコントローラ使う場合はClusterIPで十分） ...

自分用メモです。そういうことにしておいてください。 追記 多分こっちの方が安上がりだし早い https://in-deep.blue/posts/2026-03-30-gbs-control-esp-idf/ 追記終わり 序章 アーケードゲーム基板や古の家庭用ゲーム機、オールドパソコン等様々な分野で利用されている海外製アップスケーラーであるGBS8x00シリーズですが、ここ数年GBS-Controlなる代替ファームウェアが流行しています。（私も、2020年頃に知人から教えてもらいました。） 私が関わっている気がする某所の録画設備では使用していませんが、コストパフォーマンスを考えると2024年9月末現在でも前述機械類に使う用途ではかなり良い選択肢であると思います。 そのためか、このファームウェアを使用した「GBS-C」を名乗る派生商品が、そこそこの数存在しています。 しかし、これらは正直なところかなり値段が「盛られている」ため、今回はなるべくやす～く、かつ技適問題もなく使えるようにしていきます。 また、上記完成品よりは安価な、「GBSボードの制御部へソケットで直接嵌合し乗っ取るモジュール」も販売されているようですが、値段を考えるとトータルでは上記の完成品と大差なくなってしまいます。こちらは公式Wikiから非推奨とされている方式ですので、今回はパスして自作していきます。 コスト重視で安く仕上げたい ゴールとしては、今回はナムコSystem 2×6基板の15kモードを現代のLCDへ映す目的で調整していきます。なお、GBS-ControlのWeb UIは後述の問題でまともに使えません。今後の課題ですね。 さて、公式Wikiに記載のあるいくつかのESP8266搭載ボードは日本において技適（技術基準適合証明）の問題があるため、別のものを探すことになります。 せっかくコスパよいボードを使うのですから、ここはなるべく安く行きましょう。ESP8266搭載品ということでESP-WROOM-02Dを使用します。記事公開時点でまさかの300円台です。やっす。 こちらのモジュール、Flashの容量が公式で使用しているものの半分（2MB）しかありません。 今回のゴールに必要な機能は動きましたが、付加価値であるOTA等は恐らく動かないでしょう。※どうせ無線は使い物にならないからいいかなって・・・。 ピンアサインの変更 Arduino IDEにて、ボードとしてGeneric ESP8266 Moduleを選択します。 GBS-Control公式のコードのままではピン指定の差分によりコンパイルが通りません。 以下にフォーク版を作っています。適当に活用してください。（最新への追従は保証しません） https://github.com/ntsklab/gbs-control Arduino IDE設定 書き込み設定は以下です。Flash sizeの指定はハイライトしているものを、Crystal Frequencyは26MHz、Reset Methodはno dtrまたはその下のno sync的なやつ、CPU Frequencyは下の画像では変更前ですが160MHzを選びましょう。他は公式手順通りです。 ハードウェア組み立て ピンアサインは以下です。ESPの電源は適当にボードの3.3vなどから取ってください。空中配線をする場合、配線材は適当にGBSボードに付属してくる電源線とかを切って使いましょう。 To GBS SDA : IO4 SCL : IO5 Debug : IO16 Etc EN : Pull Up RST : Pull Up 以下3つはオプション To OLED SDA : IO4 SCL : IO5 To Rotary Encoder ...

前回、記事中に「旧サーバについては、ファイル移行中のフォールバック目的です。ファイル移動が終わったら削除可能です。」と書いていました。しかし、「削除可能」なのは、以下のようなリモートのキャッシュに記載されている旧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の指定などを行います。 ...

こわいね。 関連する↓ SwitchbotのPlug miniはBLEで消費電力などのステータスをBroadcast（Advertise）している 以前に記載したように、消費電力量等をBLEで常にAdvertiseしているSwitchBot Plug miniですが、よくよく調べてみると公式から以下のようなドキュメントの提供があることに気が付きました。 https://github.com/OpenWonderLabs/SwitchBotAPI-BLE Plug miniの欄を見てみると、単にConnectすれば電源ON/OFFの制御ができるようです。 早速（？）AndroidのSwitchBotアプリではなく、BLEデバッグアプリ（LightBlue）から操作を試みてみました。以下の投稿には結果の記載がないのですが、画像の通りにドキュメントに記載のあるCharacteristic UUIDを指定した上でHEX値をValueへWRITEすることでON/OFF操作に成功しました。 尚、WRITE属性があるものが上記のUUIDだけだったので、それを選ぶことで操作が可能でした。らくちん。 ということで、例えばAdvertiseのメーカ（Woan Technology）とデバイスタイプ(0x67)を見て、Characteristic UUID等全て決め打ちでON信号を送り続けるESP32デバイスとか作ると、悪いことできそうだなと思いました。（粉みかん）（やらないけど） ユーザとしてできる対策については、Switchbot公式の注意喚起や 【注意喚起】SwitchBot製品の暖房器具への使用について 電気用品安全法および関連文書、経済産業省が定めるIoTデバイスセキュリティガイドラインなどを参照されたい。 https://k-tai.watch.impress.co.jp/docs/interview/1390416.html https://www.meti.go.jp/press/2021/04/20210401005/20210401005.html ・・・何も考えずに使うのは良くないなあと思いました（こなみかん）

しらんかった　こわいね　正しくは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の設定例も追記。 ...

実は二回目。 前職よりMajestouch 2 Tenkeyless FKBN91MRL/JB2を愛用しているのですが、Enterキーを叩くのが強い（ｯﾀｰﾝ!!!）のか、チャタリング及び無反応を起こすようになったため、キースイッチを他キーよりスワップしました。 Enterキーのスイッチを適当にしゅったろうで外したところ、足がもげていました。。。 Enterチャタったり効かなかったりのやつ、これである… https://twitter.com/nt776/status/1720088181566238951?ref_src=twsrc%5Etfw 冒頭に書いた通り実は交換は二回目です。前回は足がもげるまで酷使していなかったため、Scroll Lockキーとスイッチをスワップしていました。 しかし今回は物理的に使えなくなってしまったためEnterにはPauseキーのスイッチを移植し、しばらくはPauseなし生活をしていました。（最近だとvbaのデバッグとかでしか使わないしな。。。となり。） Pauseがないキーボードになった https://twitter.com/nt776/status/1720088358817616215?ref_src=twsrc%5Etfw 後日赤軸ではないCherry MX互換規格のスイッチが届いたため、とりあえずScroll LockとPauseに搭載。しばらくはこれで戦おうと思います。 互換スイッチ（おうてむ金軸？）をつけて無反応さんを排除　タクタイルだけどまぁ https://twitter.com/nt776/status/1723069075562037582?ref_src=twsrc%5Etfw

みなさん、どくラジは～　#どくラジ 聞いてますか？（？） 表題の通り、録音ファイルの切り出しをPowerShellで自動化した話です。ネタがなくてね。。。 録音機材：Panasonic SC-HC320 受信環境：東京都府中市 文化放送 FMワイド 91.6 MHz 録音時間：1:57～3:05 録音先：USBメモリ 上記機材ですが、録音周りが主機能ではないためかなり機能的に弱いです。なので、全くおすすめはしません。。（曜日指定できないのが致命的。）薄くてサイズ的には便利なんですけどね。 少し長い時間録音して、確実にどくラジが録音されるようにしてあります。ちなみにスタート時間がギリギリなのは、放送開始が早まることは比較的少ないかな・・・という考え。 最初はAudacityを用いて手動編集していたのですが、流石に毎週これをやる時間はなく・・・　マクロを組んだりと半自動化に取り組みましたが、どうせならファイルコピーと話数リネーム以外は全自動化したい！という考えが生まれてしまいAudacityを卒業しました。 SDRサーバ等を構築して全自動で録音、というのも考えたのですが・・・そこまで来るともうRadikoでいいのでは、となり。 ラジオ然としているのは結構大事だと個人的には思います。今回の場合はラジオ聴き器（ラジカセ）から手動でファイルをコピーする、そんな†温かみ†ですね。（訳：SDRサーバ構築や機材面が面倒） メインのコードは以下の通り。（_RUN.batは、以下を叩くだけなので省略。） pipでeyeD3を入れておく必要有りです。この辺を参考に、どうぞ。 https://eyed3.readthedocs.io/en/latest/installation.html $ErrorActionPreference = "Stop" #放送曜日が変わった場合、適宜startdateを変更 $startdate = "2023/7/7" #放送が延期やスキップされた場合、日付の計算に影響があるためskippedを加減算する $skipped = 0 #タグ文字列 $title = "名取さなの毒にも薬にもならないラジオ" $artist = "文化放送 - 名取さな" #切り出し時間 入力ファイル切り出し開始時間と、出力ファイル長さ $instart = 205 $outlen = 1835 #他定数 $workdirname = "C:\Audacity\DokuRadi\ffmpeg" $outdirname = "C:\Audacity\DokuRadi\どくラジ編集済" $rawdirname = "C:\Audacity\DokuRadi\RAW" $recordedfilename = "TR_0001.MP3" [void][System.Reflection.Assembly]::Load("Microsoft.VisualBasic, Version=8.0.0.0, Culture=Neutral, PublicKeyToken=b03f5f7f11d50a3a") Set-Location $workdirname $ibox1 = [Microsoft.VisualBasic.Interaction]::InputBox("RAWディレクトリへ格納の上、話数を入力（数字のみ）", "どくラジ変換ばっち") if ([int32]::TryParse($ibox1, [ref]$null) -eq $true) { $datecalc = (Get-Date $startdate).AddDays(7 * ($ibox1 - 1 + $skipped)).ToString("yyyy-MM-dd") $ofname = "$($outdirname)\$($title)_#$($ibox1)_$($datecalc).mp3" $ofnamet = "$($workdirname)\temp.mp3" if (Test-Path $ofnamet) { Remove-Item -Force $ofnamet } .\ffmpeg -i "$($rawdirname)\#$($ibox1)\$($recordedfilename)" -ac 2 -ar 44100 -ab 96k -ss $instart -t $outlen -af "afade=t=in:st=$($instart):d=1,afade=t=out:st=$($outlen + $instart - 1):d=1" "$($ofnamet)" Move-Item -Force $ofnamet $ofname eyeD3 --to-v2.4 "$($ofname)" eyeD3 --encoding utf8 -a "$($artist)" -A "$($title)" -t "#$($ibox1) $($datecalc)" "$($ofname)" Invoke-Item "$($outdirname)" } else { Write-Host "INPUT ERROR" } Workディレクトリ等がC:\Audacity\配下でカオスですが、これは僕が部屋を片付けられない人間なので、大変に致し方ないことなのです。 ...