さーばー関連

概要 「NetMeister」のDDNS機能から「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」へ移行したよ！ 背景 とある施設において、複数拠点でIXルータ（最近終売した2215。。。）を用いてNWを構築しており、それらの遠隔保守のためフレッツ網内折り返し接続（≒v6オプション）によるVPNを使用しております。 ところで、NTTフレッツ光のIPv6アドレスの配布について、10G以外でひかり電話なしだとNTT側からRAで契約回線ごとに/64を配布されます。 そしてこの配布されるプレフィックスは基本的にONU交換や端末交換を行っても不変ですが、NTTやVNE等の都合で稀に変わることがあります。（俗に半固定、とか言われたりしますね。） 上記の問題を解決するため、IXシリーズではNetMeisterというクラウド管理システムへルータを登録することで、DDNS機能が無料で使える仕組みになっていました。（NetMeister無料版では、IPv4/v6共にインターネット経由での接続のみ対応。そのため、v6オプションのみの契約、記事公開時点では2408:210::/30に含まれるPrefixが降ってくる環境での接続は元来よりNetMeister Primeの契約が必要です。参考：NetMeisterサービス仕様 「NetMeister サービス仕様書」） 動機 しかし、去る2025/4/7に以下のリンクの内容がメールにて通知されました。 https://www.necplatforms.co.jp/product/netmeister/info/250407.html NetMeister ダイナミックDNSサービス（IPv6）無償提供終了のお知らせ （中略） IPv6 DDNSサービスの無償提供を終了し、新たにNetMeister Primeの一部として有償での提供を継続させていただくこととしました。 たいへんだ。 乗り換え先の検討 NTT東日本ではネームサービスというものがあり、公式でDDNSのような機能を提供しています。 https://flets.com/v6option しかし、v6ネームはインターネットに存在するDNSサーバ（例えば、Cloudflare 1.1.1.1）では名前解決ができない仕組みになっており、フレッツ網よりDHCPv6で取得できるDNSサーバを使用する必要があるなど、非常に不便です。 そこで、OPENプロジェクトによる以下のサービス「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」を使用することとしました。（β版、と言い張られておりますが。） https://i.open.ad.jp こちらのサービスはフレッツのネームサービスと違い通常のインターネットに存在するDNSサーバでも名前解決が行えるなど、大変に「けしからん」仕組みとなっています。 ちなみに最近知ったのですが、上記のOPEN IPv6 ダイナミック（以下略）をベースにした商用サービス「IPv6ダイナミックDNS」が開始していたようです。いつの間に。（2021/7らしいです。） https://ddns.e-ntt.jp インターネット上に存在する適当な無料DDNSサービスや私の実験用ドメイン（oyasumi.dev）などを使うという手もありそうに思ったのですが、今回の目的がまさにv6オプションによる折り返し接続であるため、そのために作られたサービスのほうが適当であろうという判断のもと、OPENのDDNSを採用しました。 IXルータでの使用 上記サービスの解説ページにもありますが、なんとIXルータにはDDNS更新機能があり、OPENのDDNSはこれに対応しています。そのため、今までのNetMeister DDNSと変わらずIXルータのみ設置している拠点でも自動でレコードの更新ができます。 動作としては、IXルータ側にてアドレス変更（IPv6だとRAによってIXへ新しいPrefixが配布された場合かな・・・？未検証。IPv6に関してアドレス変更もといソースアドレス選択周りは結構闇が深いのである・・・）を検知すると、ddns profileに設定されたアドレスへ指定のqueryをつけて投げる、という簡単な仕組みです。また、IFのアドレス変更がなくても1hに1回は更新を行う、という動作も可能です。大変便利ですね。 また、管理している拠点のうち一部はIPv6でのインターネット接続ができず、前述のNetMeister無料版の縛りにより中途半端にv4インターネット経由での接続が残る構成になっていましたが、今回ようやくその状態も解消しました。 結論 めっちゃ便利なのでさっさと乗り換えておきゃ良かった。これからもけしからん面白いフレッツサービスが生まれることを心より願っています。 おまけ 今回のOPEN DDNSに関してもソフトイーサ社はローンチ時に大変にけしからん参考になる文書を公開されているので、ぜひ読みましょう。楽しいゲームもあるよ。 https://i.open.ad.jp/news-160614

メモ 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を操作する方法については以下のサイト等を参考にしました。 ...

なんとなく動いている。 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で十分） ...

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

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の設定例も追記。 ...

公式ページの機能紹介にて「公開URLの発行」が明記されているにも関わらず、実際には利用できない様子。 制限事項に何かしら条件等の記載があるのかと思いきや、特になし。 不具合かもしれないけど、こういった事象の問い合わせ窓口が無いので解約します。 優良誤認では？と思ってしまう。 追記：実のところは、以下が原因なんだろうなとは思っています。が、公式ページを変えていないのはだめだと思う。 https://blog.noellabo.jp/entry/wasabi-public-access

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