サーバ

メモ https://hl.oyasumi.dev/@ntek/0192b99e-8468-733e-9592-447423dbc5fa

★2025/1/29 GithubのURLを変更しました Kubernetesでは、Deployment等のPod templateに対しイメージタグにてlatestを指定することは推奨されておりません そのため、sha256によるコンテナイメージのダイジェスト値指定か、バージョンタグを用いた指定を行う必要があります。 Pod templateにバージョンないしはdigest値を書くということは手動でアップデートの管理を行うということです。別に大した手間ではないですしそれでも良いのですが、せっかく（何が？？）ですので自動更新をさせてみたいものです。 但し、X.Y.ZバージョンのうちY部分の更新は何らかの管理者によるマイグレーション操作が発生する可能性を鑑みて、Z版のみ更新できるようにしてみました。（Z版で手動マイグレが必要にならない根拠は、無し。） 本来であれば以前記載した、「Deploymentでのアプリケーション単一性維持が保証できない問題」も含めて解決できる、何らかのOperatorを実装するほうがスマートです。しかし、当たり前ですがそういった実装には手間がかかりますので今回はKubernetesのCronJobでお茶を濁します。 今回の手法を実現するにあたり、JobのPodからKubernetesのDeploymentを書き換える方法を考える必要があります。 kubectl等の汎用クライアントを動かせるようにしてもよいのですが、このコマンドはフットプリントが結構大きく、また、kubeconfigファイルなどを用意する必要がある、応答を基に処理をしようとすると別途jsonの解釈が必要になる、信頼できそうな既製イメージでjqが入っているものが無さそうである、など、少々都合が悪いです。 そこで、今回はcurlコマンドとjqコマンドのみを用いてkubernetes APIを叩き、DeploymentのpodTemplateへ設定されているイメージのバージョン取得、及びその書き換えを行ってみます。 下準備として、PodからkubeAPIを叩くためにServiceAccountやRole等を作成します。以下に例を示します。 apiVersion: v1 kind: ServiceAccount metadata: name: updater namespace: hollo-1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: get-patch-deploy namespace: hollo-1 rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: updater namespace: hollo-1 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: get-patch-deploy subjects: - apiGroup: "" kind: ServiceAccount name: updater namespace: hollo-1 次に、Pod内部で実行するスクリプトを用意します。（力技。。。）curlでKubernetes APIを操作する方法については以下のサイト等を参考にしました。 ...

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

今更ながら、ワイルドカード証明書が無料ってすごい時代ですね。 弊ドメインはマネージドな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. ...

Twitterにダラダラ投げてたやつです。 2022年10月30日開催！ 奇祭『秋茄子と小鯖まつり』 いっぱいー！ 500円〜3,000円くらいでお安めにしました。 お釣りないように準備してきてもらえると助かります。 何台か欲しい人はカート的なやつを持ってきた方がいいかもです。 ※11:00開始予定 #akiba https://twitter.com/akihabalast/status/1586328591461072896?ref_src=twsrc%5Etfw ？ (@ 東京ラジオデパート in 千代田区, 東京都) https://twitter.com/nt776/status/1586534776185524225?ref_src=twsrc%5Etfw 待ちがww https://twitter.com/nt776/status/1586535210245816321?ref_src=twsrc%5Etfw 写真撮るのも憚られるぐらい、人が並んでました。（自分は10番目ぐらいでした。） めちゃめちゃに後ろが詰まっており、吟味する時間が全くなく、とりあえず元々目をつけてたSTARBILASのNASサーバと思われるものを2つ確保しました。 脳死でUDXとめたけど、遠いわ（（ https://twitter.com/nt776/status/1586539084138237954?ref_src=twsrc%5Etfw 重くはないけど体積があるものを2つ抱えてのUDX駐車場までの道のり、辛かった。 もっと近いところに停めるべきでしたね。。。 ﾋﾋﾋ https://twitter.com/nt776/status/1586549604619022336?ref_src=twsrc%5Etfw https://twitter.com/nt776/status/1586550060699250688 しざー✂ https://twitter.com/nt776/status/1586546952300154881?ref_src=twsrc%5Etfw 一人お疲れ様会兼UDX駐車場60分券入手のための食事をしました。おいしかったです。 このケースと電源だけで1500円の価値はあるね〜 https://twitter.com/nt776/status/1587036220080521217?ref_src=twsrc%5Etfw こっちはOKぽいね https://twitter.com/nt776/status/1587051774539546625?ref_src=twsrc%5Etfw 小鯖、CPU/メモリとかは無いだろうなと思っていたのですが、想定通り。1個1500円で、NAS向けのいいケースが手に入ったと思いましょう、というところです。が。 https://www.asus.com/jp/Commercial-Servers-Workstations/P9DI/ Haswell世代のマザー搭載で、意外と戦えそうです。 ただ、2台中1台、CPUファンが内部で外れており、CPUピンが曲がってしまっていました。悲しい。 https://twitter.com/nt776/status/1587035221605482496 軽症やな https://twitter.com/nt776/status/1587042089321508865?ref_src=twsrc%5Etfw 直せそう？と思い、以前購入した拡大鏡（？）カメラで確認。 ぐにゃあ https://twitter.com/nt776/status/1587045715486068737?ref_src=twsrc%5Etfw 位置的には正しくしてみた https://twitter.com/nt776/status/1587050065159340035?ref_src=twsrc%5Etfw その辺にあった精密ドライバとシャーペンでそれっぽく直してみました。 数日後・・・（CPU手配したりしてた。） うお！ピン折れ直したほう動いた！ https://twitter.com/nt776/status/1589465844899545093?ref_src=twsrc%5Etfw お～ https://twitter.com/nt776/status/1589466216951078913?ref_src=twsrc%5Etfw 無事動きました！適当なECC UDIMMを2枚挿してMemtest86+も走らせてみましょう。 OK https://twitter.com/nt776/status/1589553824439881728?ref_src=twsrc%5Etfw 大丈夫そうです。 めでたしめでたし。 ちなみに曲がってた辺り（AK33周辺？）は、Intelのデータシートを参照すると、VSSとSB_DQSN1などと書いてあります。DRAM Channel Bのデータストローブとかその辺ですかね。DRAM詳しくないですが。。