Cloudflare + ddclient で DDNS する

メモ書き。

要求事項

  1. Cloudflare + API v4.
    v1 は EOL していて使えない。具体的には http://www.cloudflare.com駄目で、api.cloudflare.com 的なエンドポイントなら OK. なお、IPv4 的な v4 ではない。
  2. ddclient v3.9.x
    v3.9 系でないと ↑ の API の EOL 問題で詰むので注意(一敗)。
    具体的には Ubuntu の場合 focal fossa までは v3.8 系までしかないので、groovy gorilla の stable パッケージを LaunchPad とかで持ってこなければいけない。パッケージもってきたら dpkg -i package.dpkg をしとけばそれで OK.

やり方

なんで設定ファイル誰も書かないんだろう?以下は完璧な設定ファイルの複製である。
言うことがあるとすれば、パスワードは Cloudflare のグローバル API キーを使わないとポシャるので注意(2敗)。似たようなのが多いんだよあそこ……

root:~ $ cat /etc/ddclient.conf
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

protocol=cloudflare
use=web, web=myip.dnsomatic.com
ttl=1

zone=[Apex domain. e.g. example.com]
login=[Mail address for login. e.g. mizuho@example.com]
password=[Cloudflare Global API Key]

[Domains for apply. e.g. subdomain.example.com]

以下のようにして実行すれば良いと思う:

root:~ $ ddclient -verbose

後はてけとーに crontab して定期実行かければいいのではないか。どうでもいいが実行あたり5分ぐらい間を置かないとスパム扱いされて強制的に更新が失敗する。地獄。

ソーシャルメディア、それは変わりゆく何かの写し鏡

某人の記事に触発されたのでなにか書こうと思う。

I tweet

黎明期の Twitter に触れたことがある。2009年のことであった。もっとも Twitter の発足は2006年らしいので何ともだが、今から眺めてみれば十分黎明期である。そのときは Intel のよくわからぬゲームをやるついでか何かでアカウントを作ったような気がする。アカウント名は明かさないが、調べてみたら今も作ったアカウントが生きている。

一種の人格のようなものを、今になってもこのアカウントを見ると想起させられる。そりゃそうだ。私の作ったアカウントだ。昔の私を見ているのだ。私は生きているのだから当然だ。

Twitter は現代のアレクサンドリア図書館のようになった。図書館がたどった運命のごとく、Twitter も将来何かしらの権力、または安直に人の感情一つで崩れるだろう。だが今の所は、とりあえず崩れてはいない。ジェンガみたいなものだ。ジェンガはあのピースを引っこ抜いて崩れれば終わりだが、逆に言えば崩れるまでは一生続く。しかし、終わりは来る。

私は今まで使ってきた @akgmoegi というアカウントがある。ヒュムノスばかり呟いていた。今はもうほとんど使っていない。不思議なことに、2009年のそれとは違い生気を感じない。当の本人がヒュムノスから離れてしまったのだから当然だ。

I toot: Mvt. I

2017年・4月。それは唐突に訪れた。それは Mastodon という。ざっくり言うと、象という意味だ。細かい部分は飛ばすとして、Mastodon のサーバの内、mstdn.jp なるところにとりあえず住み着くこととした。諸々の理由はやはり割愛してもらうとして、Twitter よりは住みやすいように感じた。当時は。

程なくして、(当時は死ぬほどやっていた)ヒュムノスを伝手に何人か一緒にいて楽しいような人が出来始めた。これが今に続く私のソーシャルメディア生の本当の始まりである。Twitter ではあくまでヒュムノスを呟くばかりで、純粋なコミュニケーションはほとんど取っていなかった。私は一人で生きていた。しかしこのとき、人のつながりが生まれた。この意味で、本当の始まりであると私は訴えるのである。

I toot: Mvt. II

ヒュムノスを伝手として知り合いができた。その知り合いをまた伝手として、とあるサーバ(以下「F」)の管理者と知り合うことになった。サーバ F は独特な登録方式をとっているという。もっとも私は当時では mstdn.jp で十分間に合っていたので当分はただの知り合いであった。

しかし、こうなるとああなるものである。このあたりの経緯はまったく覚えていないが、お察しの通り私は F サーバに移住することになる。かの登録方式とは、ズバリ好きな物事をプレゼンするみたいなことであり、私はヒュムノスの作品を作って通した。いや、能動的ではない。通った。何故か入れてしまったので、そのまま居着くことにした。不思議な出会いである。

そのときの私は、外部から見るとかなり冷たい印象であったらしい。発言は棘棘しく近寄りがたいといった具合である。はっきり申し上げると、実に勝手な解釈をしてもらったなと今も思っている。別に怒りもしないしどうとも思わないが、移住した周辺に言われたら流石にコトが起きていたかもしれない。そう言われると、困る。

I toot: Mvt.III

私の言語センスはどうも独特であるらしい。まあそうだ。トランポリンを「とらんぽりーんりーんりーん」などと言う人に対して、正常なセンスをお持ちとは言い難い。

まったく傍若無人に過ごしていたせいか、変なことばかり言っていたせいか、ともあれ Fサーバの住人と仲がよくなっていった。いいことだった。そしてごく最近に至るまで平和に過ごしてこれた。新しく来る人を迎えたり、去る人を静かに見送ったりもした。小さくも確かに火の灯った世界だった。

しかし、すべては過去のことである。

I submit a note

アレキサンドリア図書館の例えを出したのは、ただの言葉遊びではない。おそらくこの記事を見るFサーバの住民は私に対して一定の考えを持っているものと思う。それだけのことをした。

かつては楽しかった。しかし環境は変わる。かつ、アレキサンドリア図書館が現代になって復活することはないし、言うなれば、割れた皿は元に戻ることはない。

端的に言えば F サーバはかつての形を留めていないという結論に至った。三年という月日は一つのコミュニティを変貌させるのに十分な時間であり、実際変貌した。そうなった理由はいくらかの考察の末一定のものがいくつか出ている。詳細をここで述べることはしないしこの先公の場でのべることもしない。もはや公然の事実として、私は F サーバを離れることになる。

そして今は、Misskey のサーバを自前で立てて、そこで過ごしている。Mastodon も Misskey も ActivityPub を話すのだからソフト的な移行の手間はあまりない。私は F サーバを離れて、僻地でのんびり過ごす選択をした。今のところはこれが正解である。

Panta Rhei(万物は流転する)

ゆく川の流れは絶えずして、しかも本の水にあらず。その言葉は今も変わらずこの世に響き渡る。むしろ今もまったくその通りであり川の流れは時代を追うごとに速くなってゆく。大変な世の中である。

ソーシャルメディアは名前の通り社会の諸媒体をコミュニケーションという形で発現させたものである。社会が変わりゆくならその写像であるソーシャルメディア上にあるコミュニティも変わりゆく。Twitter で過ごしたしばらくの時も、月日を越えて今に至る F サーバも社会もとい各個人の生活が媒体を介してコミュニティを書き換えてゆく。ここに来て永久に続くものは何であろうか?恐らく何もない。

コミュニティには人間関係という典型的な問題の権化が付き物である。もちろん人間関係も毎日少しつづ形を変えてゆく。ときに歪になり、ときに美しくなる。ああしかし、嫌なことに負の方向に落ちてゆくのは本当に簡単なことなのだ。歪になってしまった形はさらに歪になっていく。皿にできた割れ目がやがて皿が割れる予兆であるかのように。思うに、私は人間関係の処理があまり得意ではなかったらしい。一つ叫んでよいのなら、私はどこで道を踏み間違えたのだろうか?教えて。

私は現実とネットの人格をまったく別にしているので、特にネットの出来事が現実に投影されることはまずない。しかし現実の結果はネットの人格に投影される。前述の話を元にするなら、私も長い日々を越えて変わってゆく。当初冷たいふうに思われていたのが今は面白ホモサピみたいに扱われることはその証左である(本意ではない!)。ならば、私はこの先どう変わっていくのだろうか?行く末を知るものは誰なのだろう。

終わりに

冒頭に述べた触発された記事というものがある。そちらは敢えてリンクを貼ることはしないが、文体が優しい。一方私はコンクリをドラム缶に突っ込んだような文体である。この差異は何たるか?書いてて思うのが「こいつ(私)斜に構えんな~」なので、ああいうようにしたい。書いた方、コツを教えていただきたい。こういう形の変貌は歓迎だ。

LuaTeX で table・wraptable の表上部の余白をうまく潰す

メモ書きなのでかなり雑に書く。

要求事項

  • Latexmk + LuaHBTeX(LuaTeX)
  • wrapfig の wraptable 環境

動機

wraptable 環境の上にできる謎の二行分の空白、うざいですね?回り込みをキメた途端に見た目が露骨に悪くなって辛くなる。調べたらコンテンツを先に調伏せよというお達しがあったが、見出しの直後に回り込みな表を置いたらどうやっても余白が大きくなりすぎる。

一方、table 環境の余白はいい感じなのでそのままで残したい。wraptable の上部余白は削り、table のそれは残す。面倒くさい。

しかし、どうにかして解決せねばならない。

最終的な完成例

%% Licensed under CC0.
%% etoolbox, to delete Jigoku top-margin for wraptable
\usepackage{etoolbox}

% (1) Make a macro to remove the margin
\newcommand*{\zerotablemargin}{
    \setlength\abovecaptionskip{0pt}
    \setlength\floatsep{0pt}
    \setlength\textfloatsep{0pt}
    \setlength\intextsep{0pt}
}

% (2) Make a macro to add themargin
\newcommand*{\deftablemargin}{
    \setlength\abovecaptionskip{6pt}
    \setlength\floatsep{14pt}
    \setlength\textfloatsep{22pt}
    \setlength\intextsep{14pt}
}

% (3) When wraptable env., remove the margin.
\BeforeBeginEnvironment{wraptable}{
    \zerotablemargin
}

% (4) When table env, add the margin.
\BeforeBeginEnvironment{table}{
    \deftablemargin
}

このコードなら、table 環境では必要は余白を従来どおり確保しつつ、気持ち悪い wraptable の上部余白をいい感じに切り詰められる。以下コードの説明。

まず、 etoolbox パッケージが必要なので読み込んでいる。TeX Live ならあるはず。

(1)・(2)で table 環境と wraptable 環境の上部の余白を設定するためのマクロを仕立てている。(2) の値がハードコーディングだが、これは printlen パッケージを読み込んで \printlength 命令で各個の余白を出力させて手計算(例: \printlength{\floatsep})した。

(3)・(4) ではそれぞれ table 環境と wraptable 環境の直前に(1)・(2)の余白命令を置くように命令をしている。\BeforeBeginEnvironment 命令は etoolbox から供されるものであり、環境開始命令(第一引数)(\begin{})のまったく直前に \BeforeBeginEnvironment で与えられた命令(第二引数)を置くものである。(3)の場合、\begin{wraptable} の直前に \zerotablemargin を置くわけだから、\zerotablemargin \begin{wraptable} となる。

つまり、以下の様になる:

  • table 環境ならば強制的に余白を作る
  • wraptable ならば強制的に余白を消す

すべての table / wraptable 環境に対していちいち命令を当てているので脳筋極まりないが、単純なので極めて安定して動作するものと思う。

失敗例

他すべて。

感想

TeX の組版は綺麗だが、面倒くさいことをやろうとすると思った以上に面倒くさいことを強いられる。代替になりそうな SATySFi は言語が OCaml だし情報もない。CSS組版は地獄と来た。HTML/CSSで TeX と同じことができるなら、CSS でパッチを当てるだけなのでずっと簡便に済むはずだ。しかしその日は遠い。

なお、完成例のコードは CC0 でばら撒くので、好きに使って結構です。

Edgerouter X で IPv4 PPPoE・IPv6 IPoE する feat. ndppd

何というてんこ盛り。知見があんまりないので苦しんだ。

前提条件

  • Edgerouter X。ファームウェアは EdgeOS v2.0.8-hotfix.1
  • NTT 東日本。ひかり電話なし。よって RA、IPv6 アドレスが /64 で降ってくることが前提。
  • 地獄プロバイダ・BIGLOBE。v6オプションライトを契約している。

以下 Edgerouter X を ER-X とする。

Edgerouter X の初期設定

ER-ペケに PC を繋げてやる

情報によれば、ER-X は初期状態では DHCP しないそうなので差し当たり PC に ER-X を直結する。そして PC の NIC なりのアダプタ設定で IP アドレスを手動設定する。

ER-X のアドレスは 192.168.1.1 らしいので、PC のアドレスは 192.168.1.2 あたりにすればいいだろう。設定したら ER-X にアクセスできるはずである。

どうでもいいが SSH でも接続できる。ssh ubnt@192.168.1.1 でアクセスできるんじゃない?パスワードも ubnt のはず(初期設定段階で試していない)。

本当の初期設定(IPv4 PPPoE)

多分最初ぐらいは GUI (=HTTP)でやると思うのでそれ前提。それっぽい画面が開いたら順々に設定を進める。ER-X を買うぐらいなら多分自力でやれると思うのだが……。ER-X の GUI はそこそこに優秀である。ほぼなんでも出来る。

設定のウィザードが出たら Port を eth0(か eth4)、 Internet connection type を PPPoE にする。Account Name Password は ISP から受けた通りにやる。

各種ファイアウォールで有効で構わないと思う。DHCPv6 PD なのだが、これはひかり電話を契約しているならチェックする。そして ndppd とかいう謎は忘れて良くなる。一方契約していないならチェックせず ndppd 地獄を経験する流れとなる。したくないならヤマハとか NEC のルータとか買えばどうにかなる(ND Proxy がある)。

DNS Forwarding はお好みで。必要なら Cloudflare DNS とか?One LAN はよくわからん。チェックしてるけど動いてる。LAN Ports はいわゆる DHCP なのでサブネットをいじりたいなら要設定。後から DHCP いじろうとすると結構辛いので慎重にやる。10.0.0.1/255.0.0.0 とかなら気持ちいいアドレスになる。

User setup はユーザ名・パスワード共に堅牢なものにする。初期状態なユーザ名・パスワードは全機種で一緒なので、攻撃に極めて脆弱である。必ず変える。か・な・ら・ず。まあ後で WAN からのアクセスを封じるので微妙なところではあるが、念には念を入れる。

本当にいいなら Apply ボタンを叩く。多分再起動を促されるので素直に従ったほうが良い。してる間に ER-X を PC から一旦切り離してアドレス設定なんかをもとに戻す。次は eth0 に WAN(NTT なら ONU からの線)を繋く。ちょっと待とう。起動し終わって IPv4 でアクセスできるなら後はどうにでもなる。ならなかったら天を仰げ。

第二の初期設定・身の回りを固める

ファームウェアを最新版に更新

多分初期設定(というより工場出荷状態?)ではファームウェアが v1 台だと思う。v2系がもうあるのでそっちに更新したほうが良い。v1 だとハードウェアオフロードに不具合がある([1-2] 参考)。v2 では解決している。なんせ v1 の CHANGELOG に確かにあったハードウェアオフロードの不具合の項が v2 のチャンゲログでは確かに消えている。

Ubiquiti のサイトから v2 系のファームをダウンロードして、GUI にアクセス → 下部の System → Upgrade System Image → Upgrade でよい。結構時間が掛かる。面倒なら、もっと面倒な UMNS とかいう奴でリモート更新ができるが……。

グッバイ外部からのアクセス

初期設定では GUI / SSH に外部からアクセスできる。グローバル IP アドレスさえあれば簡単。マジで画面が出てくる(経験済み)。これがユーザ名・パスワードの再設定を強く勧める理由である。もちろん外部からアクセスできると危険なので潰す。

ここからは SSH でやる。以下のコマンドを実行する。以後似たようなコマンドが出てくるときは最初の configure と最後の commit を実行する。コミットで本当に叩いた設定がおっけーなのか確かめて適用し、save で保存する。exit は configure モードを抜ける。

$ configure
# set service gui listen-address 10.0.0.1
# set service ssh listen-address 10.0.0.1
# commit; save; exit

10.0.0.1 の部分は DHCP なあたりで振ったアドレスに応じて変える。最悪アクセスできなくなるので、GUI のほうを先にやって commit した後 GUI アクセスが外部から出来ないか確かめれば安全。外部からというのは、即ちグローバル IP アドレスから入ればいい。

DNS を明示的に設定する

これは簡単。GUI なら下部にある System → Nameserver に色々詰める。SSH なら set system name-server 2606:4700:4700::1111 (Cloudflare DNS の場合)といったところか。

NTP もいじってしまおう

set system ntp server ntp.nict.jp とか? mfeed とかだと IPv6 な NTP を提供している。お好みでいいが変なところを選ぶ理由はない。

ハードウェアオフロードを設定する

ER-X は NAT と IPsec をソフトウェアではなくハードウェアで処理できる。しましょう。これも SSH で set system offload hwnat enable, set system offload ipsec enable で OK。GUI の Config Tree を見るともっともっとたくさん設定できそうだが、できない。思うに Edgerouter 6P とかもっと上位でやれるような機能も見えてしまうせいだと思う。ソフトウェアは同一で、ハードがコロコロ変わるような具合だ。繰り返すが ER-X は NAT と IPsec をオフロードできる。

IPoE をついに設定する

まあ IPv6 アドレスを拾ってきて、それを LAN に広報するだけなのだが。

IPv6 アドレスを拾う

[2-2] によると以下のよう。

set interfaces ethernet eth0 ipv6 address autoconf
set interfaces ethernet eth0 ipv6 dup-addr-detect-transmits 1

これで拾える。show interfaces を実行すると eth0 に IPv6 アドレスが /60 か /64 できているのが見えるはずだ。/60 なら DHCPv6 できるので、そちらを中心にやる(ここではやらない)。/64 なら地獄の下見に行ったほうが良い。辛い。

10分掛かるという情報もあるが、自環境の場合一瞬であった。再起動の時もういっぺん拾いにいくので IPoE の立ち上がりに時間がかかるという情報もある。これもまあ、再起動のほうが時間がかかるといった感じ。要は上のコマンドで第一段階はよろしい。

さて、NTT + ひかり電話ありなら DHCPv6 で多分 LAN に IPv6 をばら撒けるのでもう終わりでいいはずだ。しかし私の環境はないので、ndppd というよくわからんやつを突っ込むことになる。こいつを使えば LAN に IPv6 が行き渡るようになる。

LAN に IPv6 を広報する

[2-2] によると、以下の様な設定になる。

set interfaces switch switch0 description Local
set interfaces switch switch0 ipv6 address eui64 '2409:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64'
set interfaces switch switch0 ipv6 dup-addr-detect-transmits 1
set interfaces switch switch0 ipv6 router-advert cur-hop-limit 64
set interfaces switch switch0 ipv6 router-advert link-mtu 1500
set interfaces switch switch0 ipv6 router-advert managed-flag false
set interfaces switch switch0 ipv6 router-advert max-interval 600
set interfaces switch switch0 ipv6 router-advert other-config-flag true
set interfaces switch switch0 ipv6 router-advert prefix '::/64' autonomous-flag true
set interfaces switch switch0 ipv6 router-advert prefix '::/64' on-link-flag true
set interfaces switch switch0 ipv6 router-advert prefix '::/64' valid-lifetime 2592000
set interfaces switch switch0 ipv6 router-advert reachable-time 0
set interfaces switch switch0 ipv6 router-advert retrans-timer 0
set interfaces switch switch0 ipv6 router-advert send-advert true

commit; exit

呪文だ。当然だがコマンドに見えるアドレスっぽい奴は show interfaces で見える IPv6 アドレスを指定する。おそらくこの時点で、コマンドプロンプトとかを開いてみて ipconfig /all すると「IPv6 アドレス」と「リンクローカル IPv6 アドレス」の二つが見えるはずだ……私の ND Proxy 観が正しければ!正しくない可能性があるので参考程度に。

ndppd を仕込みに行く

まず ndppd(だいたい ND Proxy と等価) ってなんだよ。こいつは ND Proxy を ER-ペケで実現するデーモンである。ND Proxy とは……うん……極めて端的に言うと IPv6 版 NAT みたいなもの(NAT 機能自体はしない)で、こいつがあると外部と内部に一枚板を噛ませられるのでセキュリティがよろしくなるという魂胆だ([3] を参照な)。近隣LAN への広報でいい気もするが、よくわかっていない。調べてみてほしい……。

ndppd を ER-X にぶち込手段は以下の二つがある。

  1. ndppd を git から拾ってきてビルドする。ER-X は MIPS アーキテクチャなので普通に x86 ビルドしても動かない。GCC + MIPS みたいなやつがいる。長いので「Edgerouter X ndppd」とかでググってもらえれば([2-1] を参照)。
  2. 実は多少手順を踏めば apt が使える。具体的に言うと、apt のリポジトリに ndppd が転がっているので、それを apt install して ER-X に仕込む。おそらくこっちのほうが楽だろう。私は 1) のやり方で達成した後知ったのでこの手順は想像を含む。

1)の場合本当に辛い。MIPS という当初はアメリケ技術だったのが紆余曲折の末に中国に渡ったらしいアーキテクチャを採用しているのが悪い。それがためとはいえ、なんで Docker とかをルータの設定するのに使わなけりゃならないんですか?とあるサイトにはバイナリが置いてあったので最悪それを使う手もなくはない……。でも apt でやれるなら多分そこにバイナリがあるんじゃない?手動設定は大変そうだけど。

2)にはもっと説明がいる。実は ER-X の中身を改めると大体 Debian で、SSH からやればふっつーに init.d とか systemd とかが居座っている。上記リンク先の手順を踏めば多分 apt が使えるはずなので、apt install ndppd でおっけー。こっちができるならこっちのほうがいいだろう。ファームウェアが v1 系だと Debian 7 でこっちは ndppd がないので注意。v2 でなければこちらの方法は取れない。

前者の場合おそらく十人十色な設定があるので参考にする記事に従うのが良い。後者の場合、多分 /etc/ndppd.conf みたいなのがあると思うので、それを見てみる。

すると、[2-1] によると設定は以下のようにすればよいという。

proxy eth0 {
   router no
   timeout 500
   autowire yes
   keepalive yes
   retries 3
   ttl 30000
   rule ::/0 {
      iface switch0
   }
}

proxy switch0 {
   router yes
   timeout 500
   autowire yes
   keepalive yes
   retries 3
   ttl 30000
   rule ::/0 {
      auto
   }
}

もうすぐだ……。

ndppd を自動起動するようにする

書き疲れた。でももうすぐ終わりなのだ。ndppd をインストールしたのはいいが、特に手動導入の場合再起動した場合多分起動しないで混乱のもとになるのではないか。対応するコマンドが多彩すぎる(apt なら systemd なんですかね?手動の場合 init.d であろう)ので、apt なら systemctl、手動なら update-rc.d で気合する。

IPoE 接続をテストする

本当に書き疲れているんだよ。今この時点で5時だぞ。夕方じゃなくて朝な。早朝。それはよくて、IPv6/IPoE で接続できてるんかテストする方法はいくつかある。IPv6 テスター的なサイトを使うとか、fast.com でポチッとやって IP アドレスが IPv6 であるかとか。前者は純粋な接続テストで、後者は速度向上が実際になされているのか確かめるのに使える。

終わりに

IPv6 自体が早いのではなく、IPv6 に IPoE(フレッツ観)という接続方式を採用しているから早いというのはよく言われること(参考:「IPv6は速い」なんてことはない)である。

IPv4 ではもっぱら PPPoE で接続するのだが、こいつは認証機能とかをパケットに乗せていて各所で荷解きせねばならぬので遅い(参考: NTT フレッツ光における通信速度などの現状について、背景や仕組みから正しく理解する 2020)。しかも荷解きするところは混雑していると来た。一方 IPoE ではこっちの ONU かなんか自体を認証に組み込んでいるらしいので、接続を張るときはとにかく本質的な情報の送受信に徹すれば通信毒度が速くなりうる。

さて、もし、すべてが上手く行っていれば速度がよろしくなっているはずだ。行っていなければ、誰も踏み込んでいない地獄に貴方は踏み込んだということになる。健闘を祈る。

参考文献

[1-1] yabe.jp – EdgeRouter X がすごい

[1-2] yabe.jp – EdgeRouter X – 3. UPnP やポート転送を設定する ( UPnP / Port Forwarding )

先駆者様。しかし投稿日を見よ。2020年時点からみて4年も前である。色々古い。そのせいで今では問題がないことを問題にしていたりして混乱する(ハードウェアオフロードなど)。しかし参考になる情報は多々あった。

[2-1] Qiita – Edgerouter X(ER-X) 用に ndppd をカンタンにビルドする (ひかり電話なし)

[2-2] Qiita – Edgerouter (ER-X) で NDプロキシを使って IPv6通信を行う (ひかり電話なし)

ER-X + ndppd + IPoE で調べれば多分出てくるであろう記事。二本立て。かなり最近の記事なので大いに参考になりうる。ndppd 以外はこの記事を見れば間に合うのではないか?非常に素晴らしい。

[3] y2blog – IPv6(IPoE)ネットワークの構築(実践編:その1)

ND Proxy を詳しく説明している。多少フレッツ光観を元にしたネットワーク知識がないと読むのは難しめか。

Mastodon の構築でハマったこと4選

ふとマストドンを GCP 上で構築してみようとおもった。変なことしなければドキュメント通りに組めば大体通るのだが、いくらか罠がある。

ドキュメントは Ubuntu 18.04 Bionic Beaver を前提にしてあるが、ここでは Ubuntu 20.04 Focal Fossa を前提にしている。別にいける(いけた)。

1. apt install が通らない

件のドキュメントの前提ライブラリなどの導入コマンドはこれだ:

apt update
apt install -y \
  imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev file git-core \
  g++ libprotobuf-dev protobuf-compiler pkg-config nodejs gcc autoconf \
  bison build-essential libssl-dev libyaml-dev libreadline6-dev \
  zlib1g-dev libncurses5-dev libffi-dev libgdbm5 libgdbm-dev \
  nginx redis-server redis-tools postgresql postgresql-contrib \
  certbot python-certbot-nginx yarn libidn11-dev libicu-dev libjemalloc-dev

このうち libgdbm5 と python-certbot-nginx が focal に存在しなかったりして apt install は失敗する。これはそれぞれ libgdbm6 と python3-certbot-nginx と書き換えれば通る。

2. certbot も通らない

nginx の設定でマストドンの設定プロファイルを ln -s /etc/nginx/sites-available/mastodon /etc/nginx/sites-enabled/mastodon のように生やすのだが、これを先にやってしまって nginx を再起動してしまうとハマる。具体的には SSL の設定が違反を起こして(証明書がないと SSL の設定を書けないのだが、その設定を書かないと起動しないループになる)死ぬ。

解決方法は素朴に ln -s をする前に certbot を実行すれば良い。/etc/letsencrypt/… の下に証明書さえ生えれば ln -s して差し支えない。

3. オブジェクトストレージも通らない

思うにマストドンの設定ファイルはあまり楽しくない。

Google Cloud の Storage にファイルを叩き込みたいという希望は全人類が抱えている。なのでこれを設定する。

# S3_ENABLED=true
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=
# S3_REGION=
# S3_PROTOCOL=https
# S3_HOSTNAME=storage.googleapis.com
# S3_ENDPOINT=https://storage.googleapis.com
# S3_MULTIPART_THRESHOLD=52428801 # 50.megabytes

これが ~/live/.env.production.sample にある設定変数でこれを .env.production において適量設定すればよいのだが、S3_BUCKET がここにないせいで nginx は起動に失敗し我々は地獄に落ちる。

当然 S3_BUCKET を設定すれば解決する。Storage のバケット名でよい……はず。

4. アクセスもできない

なんでだよ。と思ったがデフォルトのプロファイルが悪さをしていた。rm /etc/nginx/sites-enabled/default を消して再起動で解決する。

Docker の長い引数を GNU Make で解決する

Docker の長い引数が辛い

Docker という人類の叡智の結晶に触れてから(書いる時点で)まだ数日も経っていない。しかし気づいた。Docker の引数は、長い。そして、難しい。叡智とはいうがどこに結実したかというともっと低レイヤーな部分で、コマンドは黒魔術めいている。

喚いてもしょうがないのでどうにかしたかった。ホモサピは三文節以上のコマンドを覚えられない(要出典)ので、引数がたくさんある場合は略するのが適当である。例えば docker run --interactive --tty --detach ...docker run -itd なりと略される。なるほど短い。しかし意味は理解不能になった。というか文字数が減っただけで引数自体は残っている。メインコマンドを除けば2文節だが、人類の無理に近い。またこういった略称は意味がわからなくなり無駄な認知負荷がかかる。どうにかしたい。

古のビルドシステムに立ち返る: GNU Make

Makefile というものがある。C のビルドや最近は Go の各種タスクの利用に使う。Makefile の実態は Make の設定記述書である。一見言語依存のビルドシステムに思われがちだが、もっと単純なことにも使える。

今回の目的は長い引数を滅殺することである。Make は C のややこしいビルドの記述を楽にやれる。その原理はややこしいコマンドをタスク単位にまとめて実行することである。タスクランナーに似ている。

タスクランナーのように動くなら、タスクランナーとして使える。

Docker のコマンドを Makefile にする

ここでは Makefile の仕様を詳説しない。結果だけ示す。

NAME=project
VERSION=latest

.PHONY: build
build:
	docker build --tag $(NAME):$(VERSION) .

.PHONY: start
start:
	docker run --interactive --tty --detach --name $(NAME) $(NAME):$(VERSION) ash

.PHONY: stop
stop:
	docker rm --force $(NAME)

.PHONY: attach
attach:
	docker exec --interactive --tty $(NAME) /bin/ash

.PHONY: clean
clean:
	docker rmi --force $(NAME)

主要なコマンドを make のタスクに詰めている。イメージの作成は make build で済む。コンテナの実行は make start 、コンテナに入るなら make attach などとする。

コマンドの引数もいちいち打たなくてよくなるから、略称でなくきちんと書けば済む。そうすると意味を失うことなく読みやすい Makefile になる。実行はすべて make を介して抽象的に行える。具体的な実行の委細は Makefile に委ね、必要なら Makefile を書き換えればよい。実行するコマンドは同じで挙動を上手に変えられる……。

あ、以上です。

参考文献・参考資料

DockerのMakefile

Makefile の部分は概ねここの受け売りである。先駆者のアイデアと知識があってこそのこの記事である。なお、引数の記述はわたしの方針に合わせて調節している。

とほほのDocker入門

引数の調査にこのサイトを利用した。インターネット上に四散している Docker の情報の中でも特にわかりやすいと思う。思えば HTML を手打ちしている時代からこのサイトにお世話になっている。つ、つまり……すごい、長寿……!

Make for Windows

もし環境が Windows ならこれをいれてパスを通せば動く。

Docker コンテナ内の Git で GPG 署名する

VSCode の Remote – Containers ありきです。生の Docker は頑張ってください(参考にはなると思います)。イメージは node:alpine を使っています。

結論

以下のようにする。

  1. apk add git gpg を実行して Git と GPG を導入する
  2. gpg --import <鍵名> を実行する(秘密鍵はどうにかして持ってくる)
  3. git config --global commit.gpgSign true を実行する
  4. git config --global gpg.program gpg を実行する
  5. git config --global user.siginingkey <鍵ID> を実行する
  6. ~/.profileexport GPG_TTY=$(tty) を書き足す
  7. 適当に色々やってコミット(git commit -S am "Message here..."
  8. (GitHub を使うなら HTTPSgit remote add なりする → git push

手順3~5はホストとコンテナの設定が一致するなら設定しなくてよいはず(ホスト側の設定が適用される)。

対象

  • Git コミットに GPG 署名する人
  • Remote – Containers で生成されたコンテナでも GPG 署名したい人

前提

  • Windows 10
  • Visual Studio Code
  • ↑ の拡張機能として Remote – Containers
  • コンテナは node:alpine、しかし Node 要素皆無なので Alpine なイメージなら対象内?

詳細

Git と GPG を導入する

Alpine Linux は Git と GPG が入ってないので入れなければならない。

GPG 用の秘密鍵をインポート(作成)する

コンテナ内に鍵がないと署名のしようがないので外部の使用している鍵を持ってくる(gpg --import <id>)なり新たに作成する。

各種 Git の設定

commit.gpgSign はデフォルトで署名する設定、gpg.program は利用する GPG プログラムの設定、user.signingkey は使用する GPG 鍵の ID の設定。

Remote-Container は標準でホストの Git 設定(C:/Users/USER/.gitconfig とか)をコンテナに持ってくるが、ここで沼を見た。ホスト側のプログラムの設定が絶対パス指定だとコンテナ内での Git の実行に失敗する。なおヒントになるエラー文は出てこなかった。鬼畜 Git ……

gpgSign signingkey は基本的にホストとコンテナの設定が一致すると思うので追加の設定はしなくてよいかもしれない。

export GPG_TTY=$(tty)

これがないとヒントというヒントがないエラー文が出てコミットなどに失敗する。鬼畜 Git ……

これは予想だが、本来は適当な GUI でパスワード入力を求めるはずが、Alpine では GUI の出しようがないのでそこらへんで死ぬものかと思われる。代わりに tty を指定することで CUI で入力を求めるようにしているのだろうか。

コミット・プッシュ

コミットは標準どおりに git commit -S -m "message" などとすればパスワードを求められた後成功するはずである。なお GitHub をリモートとして利用する際、リモートの URL は HTTPS 形式を指定するのが吉である。SSH での利用は Remote – Containers では HTTPS と比べ「限られたケース」としている。

後書き?

コンテナ初めて触ったときにこれをやったので随分な地獄をみた。Remote – Containers は GPG 署名にもうまく対応して欲しいところである。

参考資料

Developing inside a Container

Microsoft 公式の Remote – Containers 利用方法ドキュメント。

GitHubでVerifiedマーク

export の奴の記述があった記事。本当に素晴らしい。感謝。

情報の隠蔽と統制、その中の私

インターネット上の人格っていろいろあるけれど、あなたってどうしてます?本名出してる?―それはないか。じゃあ、住んでるところは?― 都道府県レベルなら、なくはない。それじゃ、年齢は?― 聞かれれば答える程度、の人はそこそこいるだろう。

私は、ほとんど明かしていない。本当に「情報」を明かさない方なので、逆に明かしている情報を明確に指せる。具体的には生誕地、市町村レベルの住所、生まれ年を除く生年月日(実質的に月日)の3つ。他は明かしてないつもり。明かしていたとしても、致命的なものではないものばかりだと思う。例えば血液型も明かしてるかもしれないけど、知ったところでどうしようもないでしょ。

それじゃあ、何故明かさないかっていうと、インターネットの匿名性を最大限に享受したいから。他にもいろいろあるが、端的に言うならそう。少なくともこの国、日本では実名を明かさなくてもインターネット上で活動できるし、住所なんてそもそも明かす必要がない。

私はそう人間の心理や先入観に詳しいわけではない。しかし直感として、年齢や性別を明かすとそれを元に知識や思考を勝手に判断されたり値踏みされたりする。結果として「君は若いんだから~」「人生経験が~」みたいな返答に結実される。

ファッキン。確かに人生経験は豊富であれば世渡り上手になり、若い奴の思考では大人の世界™では立ち行かないのはわかる(私が若いやつとは言わない)。スカム。人生の方針やら自分の思想やらは自由なのに、他人に年齢やらで指図されるのは気に入らない。話した内容を元に難所を指摘するとかならいいのだが。

つまり、むやみに情報を明かすと要らぬ先入観を抱かれる。そう思ってる節があり個人情報を明かさないという方針に繋がっている。匿名―名前は便宜的についているが―であればインターネット上でコミュニケーションを取る土台が平坦になる。人の属性ではなく、人の中身でコミュニケーションが取れる。

逆説的に言うなら、私は何歳と思われてもいいわけだ。10歳だろうが20歳だろうが50歳だろうが。性別だってなんでもいい。男だったり女だったり、両方だったり、そうでもなかったり。

一方で、個人情報を統制するのは非常に神経をすり減らす。現実のイベントをむやみに SNS などに垂れ流すと年齢ぐらいはすぐに暴かれてしまう。例えば仕事してると言えば(あかれぎは遵法です)少なくとも高校生以上ということが明らかになる。酒飲んだと言えば20歳以上で、その他有耶無耶は有耶無耶。

匿名性と引き換えに、この統制は発言内容の制限を招く。これは非常に厄介者で、ストレス発散に愚痴ろうと思ってもそれが個人情報に直結するなら話せない。楽しいことであっても直結するなら然り。非常につらい。

この方針はいずれ捻じ曲げるかもしれないし、ずっとこのままであるかもしれない。少なくとも今はそう。明日はわからない。

そんなポエムでした。

十月十九日

なんとなく書きたくなった。書こう。

流行りの何か

最近とちょっと前、私の周りで Scrapbox なるものが流行った(っている)。いわゆる文書管理システムで、書き物を整理するサービスといえばわかりやすいだろうか。

[ここで数十行に及ぶ Scrapbox 論考が生み出されたが、怪文書ということで削除された]

さて、Scrapbox が私の周りで流行った理由はよくわかる。文書管理システムとして使いやすいのだ。直感的にやりたいことがそれなりのレベルでできる。記法も慣れればわかりやすいし、バージョン管理もできるようだ。ハッシュタグなど現代的な要素も取り入れている。更にはプロジェクト別に文書を置けるので、公開非公開とか共用非共用とかの設定も易い。

[ここで十数行に及ぶ VCS との比較論考が生み出されたが、怪文書ということで削除された]

まあ、便利なのだ。サービスの思想とかは横に置いたとしても設計が優秀なので誰でもそつなく使える仕上がりになっている。

私の中の流行りは

流行りといっても色々あるだろう。世間の流行り、ホモサピの流行り、野毛山動物園のひよこの流行り。人それぞれ、動物それぞれ。もっともこいつらを話してもしょうがないので、私の中の流行りを紹介する。その名も、クッキークリッカー……!

そう、数年前日本中のインターネット世界を揺るがしたクッキー地獄、おばあちゃんが焼いたクッキーが宇宙を揺るがすクッキーバース、見るも食べるもすべてがクッキー。そんなゲームである。

相当の年月を経て、クッキークリッカーは相当に進化している。昔は光からクッキーを作るのがせいぜいだったらしいが、今ではクッキーの生まれる可能性を作れる。クッキーからクッキーを生み出せる。神殿にクッキーを捧げればもっとクッキーがもらえる。クッキー畑にクッキーを植えればクッキーが生える。魔法使いにクッキーを賄賂して魔法を唱えて貰えば更にクッキーが生み出される。そんな感じになっている。

あまりに有名なクッキーブランドなのでここで多くを語る必要はない。しかし、これだけは言っておきたい。クッキークリッカーをやれ。後悔はしない。

それぞれの流行り

そんなわけで、今回の記事のネタは「流行り」に決まりそうだ。あ、例のように書きながらネタ考えてるからあしからず。

今は夕方あたりだと思ってほしい。リビングの机で面倒くさい作業をしている。あまりの面倒くささに嫌気が差して、ふとテレビを眺めてみる。アナウンサーがニュースを伝えている。細々したものはともかく、大体の時間はここ最近有名な話が持ち出される、これは、いわば流行りの話題であり、私含めて色んな人がそれに釘付けになっている。

今は深夜ぐらいだと思ってほしい。じゃれあう人もいないし、話す人もいない。かといって寝る気もないので、暇つぶしに恐ろしげな某T社のまとめサイトであるサービスTの記事を見てみる。ビュー数が多いものがちらほらある。そのコメント欄は案の定荒れている。これもまた、広大なるインターネットの一泡沫でありながら流行である。

情報だらけの社会で何の流行りもないというほうがおかしい。この情報社会に生きる私(と愉快なホモサピ一同)は誰かの流行りに乗ったり、飽きたら降りたりしている。流行りは生まれ、消費され、消え去る。モノを大事に扱う考えは市井に広まっているようだが、情報……もとい流行りを大事に扱う考えは広まっていない。何かが流行らなくなったとしても、その何かが消え去るわけではない。

自分だけの流行り

忘れてもいいような(むしろ忘れたい)流行りもある。降りても大したことにならぬ流行りもある。しかし、忘れてはならないものがある。

かつて、大地震があった。テレビで取り上げられ、ネットで議論された。一種の流行りであったが、今や一年に一度しか思い出さない人が多勢だろうか。

日本列島規模に考えると死ぬので、もっともっと小さく考えてみる。一昨年ぐらいに PPAP が流行ったが、今では誰もが過去の一発屋ぐらいにしか思ってないだろう。しかし、ピコ太郎は今でもすばらしい楽曲を生み出している。流行りが終わっても、流行りの対象が消えるわけではない。

Everyone must die, PIKOTARO

まずは自分の流行りをもってみることから。それも、すぐには飽きないような何かを。忘れてはならないこと、忘れたくないこと、むしろ覚えていたいこと、色々ある。この連鎖が続けば、自分も幸せになれる(かもだ)し、流行の人も幸せになれる。

流行りを大事にしよう。いい理由であれ悪い理由であれ、生まれた情報には理由がある。大小はあれど、後世に伝わるようにしなければならない。過去を過去のままにするだけではなく、今に留めてもいいこともある。

六月十五日

プレアンブル、または序文的はじめに

最後の投稿からざっくり五ヶ月経ってしまった。ヒュムノスを含めない本筋ならまるまる六ヶ月分過ぎ去ったことになる。三日坊主というが私の場合半年坊主らしい。明智光秀でさえ即座にアノヨに召されるぐらいの長さだ。

で。

“六月十五日” の続きを読む

<span>%d</span>人のブロガーが「いいね」をつけました。