今年の振り返り 2025

今年は 2025 年の振り返り記事を 2025 年内に用意できた。

2025 年どうだったか

月ごとの出来事を並べる。

1 月

  • 研究
  • 研究室の先輩から教えてもらった石岡にある温泉やさと温泉 ゆりの郷によく行っていた
  • EAH-AZ100 という無線イヤホンを買った
  • つくば高崎自然の森を散歩した

2 月

  • 研究
  • 22 時を過ぎると部屋の電気が自動で切れるように設定したところ、この 1 年での生活リズムが整った
    • カーテンをスマホから開け閉めできるようにもした
  • 理由ときっかけを忘れたが、つくば駅で拾った同行者を車で拾って向かった先が PC-98 とフロッピーディスクと古い Mac がある部屋だった日もあった
  • かすみがうら周辺を散歩してた
  • NotebookLM が登場し、いろいろな会社の IR 情報や GitHub リポジトリの情報をポッドキャスト方式で解説させる遊びをしていた
  • 浅草を散歩した後、勢い余って初 MOGRA 入場

3 月

  • 上旬は ICTSC2024 のホットステージに参加していた
  • 就活の ES や適性検査をぼちぼちやってた
  • Misskey に数年間寄付し続けていたら金属のカード貰えた
  • 深夜に突然引っ越しを手伝ってた
  • 深夜に突然引っ越しを手伝ってた2
  • つくば西スマート IC が開通したから使った
    • 研究学園に寄りながら帰宅するときには便利……？
  • 1 泊 2 日の北関東ドライブ一人旅してた
    • 「道の駅にのみや」で大量のいちごが販売されており、いちごの芳しい香りが売り場一面に広がっていた
    • 日本三大美肌の湯の1つであるところの喜連川温泉に入った
    • 那須どうぶつ王国ってあるなあと思い見て回った。こういう所に来るとソフトウェア名の元ネタの動物が色々発見できて面白い（Mac OS X Leopard、Gentoo, Python, Puffin, ……）

4 月

  • 新社会人になった直後の先輩を車で迎えに行った
  • この頃ぐらいから散発的に週末適当一人電車旅が発生するように
  • 下道限界ドライブだけが運転の目的ではないことに気づきはじめる
    • 適当に行きたい外食の店まで車を走らせてもよい……。
  • ひたち海浜公園のネモフィラを見に行った
    • 空と海と花が繰り広げる 3 種類の青色は見る価値がある
    • ネモフィラ以外の植物もかなり充実しており、3 時間ぐらい滞在した
    • 帰宅途中の友部 SA にもネモフィラがあった。お手軽ネモフィラ体験にオススメ
  • 就活が完了
    • インターン行きすぎクンだったかもしれない
    • パソコンとマネジメントの話をして面接官を笑顔にすると良い
    • ネモフィラを見ていたら内々定の連絡があった

5 月

  • Claude Code 試した
  • 研究室の Proxmox VE ホストで使っていた ext4 のファイルシステムが崩壊した
    • ストレージを置き換え、Proxmox VE をインストールしなおした
    • Proxmox Backup Server から VM と CT をリストアして復旧完了
    • 2 時間半ぐらいダラダラ作業してた
  • NHK 技研公開に行った
    • 地下駐車場での展示では、「マルチクラウドを活用した放送・配信アーキテクチャー」などと題し、安定して番組の送出を行うための仕組みの説明が詳細に語られていて面白かった
  • 大阪出張

6 月

  • 研究で設計・実装面の試行錯誤をかなり頑張っていた
    • 修論が本気でマズいのではないかと一番焦っていた時期
  • Gemini CLI 試したけどレートリミットがかなり厳しくて使わなかった
  • 大阪出張
  • 熱海に行った

7 月

  • 研究の中間発表会があった
  • 引き続き、研究の設計・実装面の調整をしていた
    • Markdown で研究のメモを取りながら血の気が引くような体験、もうしたくない
  • 研究のためにバイトの頻度を減らした
  • 情報処理安全確保支援士試験に合格
  • 運動不足につき水泳を週 2 ～ 3 の頻度でするように
    • 小学生の頃にスイミングを習っていたから泳げはした
    • 最初の頃は 25 m を泳ぐにしても息が上がっており、プールから出るときに酸欠っぽさによる眩暈があった
    • 趣味がパソコンから適度な運動に変わりはじめた
  • 長野に行った

8 月

  • 研究をしていて大阪万博には行けず、VRChat の韓国人フレンドの万博観光をメッセージで手助けしていた
  • VRChat の EN-JP ワールドに入り浸り、英会話ごっこを再開
  • 初ボドゲカフェ
  • リアル脱出ゲームで初めて脱出成功
  • 筑波大学 3F 棟 1 階のホワイトボードに修論に追われているイカ娘が描かれていた
  • NIGHT HIKE Mid 2025 に行った

9 月

  • なんとなく郡山 1 泊 2 日旅をした
  • XREAL One Pro という XR メガネを購入した。電車での移動中などにショルダーハックを気にせず作業できて便利だが、バスだと酔ってダメだった
  • 下道をドライブしていたら偶然にも上曽トンネルが開通する日の渋滞に当たり、とりあえず通過しておいた
  • 適当に喋ったことを文字起こししたものを LLM に食わせて TODO を整理する技を身につけた
  • 道の駅 常陸大宮や袋田の滝に行った。帰り際に寄った高戸小浜海岸は良かった

10 月

  • 内々定が内定に進化した
  • 研究
  • 暴力的にカワイイ 2025 に行った
    • つくばに車で行く途中で寄ったためお酒は飲めなかったが、帰宅の体験は自家用車なだけあって過去一よかった
  • マニュアル車で三県境や榛名山に行く VRChat のオフ会に参加し、スイフトスポーツの MT を運転した
  • 九州旅行に行った
    • 阿蘇くじゅう国立公園など
    • 草千里ヶ浜、本当にただの草原が広がっているだけのおもしろ空間だった
    • 日本三大美肌の湯の1つであるところの嬉野温泉に入った
  • キャンユースピークイングリッシュ？という VRChat のワールドにハマった
    • 表示された英単語を英語で説明し、他の参加者に当ててもらうゲーム

11 月

  • 雙峰祭の花火を見た
  • VRChat で「お前は日本人なのにもかかわらず日本の漫画やアニメのことを知らなさすぎだ」とのアドバイスを頂いたため、チェンソーマン第一部を少年ジャンプ＋で一気読みした後に「チェンソーマン レゼ篇」を映画館まで見に行った
    • 映画館に一人で行ったのがこれでそもそも初めてだった
  • Amazon Tours に参加し、千葉みなとFC QCB4 の見学をした
  • 24 歳になった
  • 初の皇居一周散歩
  • 初の我孫子駅の唐揚げそば
  • VRChat の先述したワールドを参考にして自作のワールドを作成していた
    • それっぽいギミックが完成した時点で飽きてしまい、放置……

12 月

  • 修論や修論ではない論文を書いた
  • 修論を書いていたら一瞬で 1 ヶ月が過ぎ、何も覚えていない
  • 筑波大学 3F 棟 1 階のホワイトボードに研究に追われている芽兎めうが描かれていた
  • VRChat で知り合った留学生と居酒屋で飲んだ
  • 初めて競馬場に行った（中山競馬場で中山大障害を見た）
  • 高校の頃以来会っていなかった高校同期と飲んだ
  • 折りたたみスマホに興味があったため Galaxy Z Fold 5 の中古を手に入れた
  • とりあえず修論を提出した

総評

  • 大学院は本当に大変だった
    • 自家用車と公共交通機関で旅行し続けたことで安寧が保てた
      • 新社会人になっても最初の頃はお試しがてら今の車を持ち続けようかと思っている
    • 1 月終わり頃の審査会まで引き続き頑張りたい
  • 学生の身分を活かし、数多くの旅行ができた
  • VRChat で英会話遊びをしていたら派生イベントがもろもろ発生して楽しかった
    • 海外の情報系人間と定期的に雑談する関係ができて良い
  • 水泳や散歩などの運動 + 食事への注意により、体重を 6 kg 程度減らせた
    • 健康第一
    • つくば住みの場合、夏場は水温が低めの洞峰公園プールで泳ぎ、冬場は水温が高めのみどりのプールで泳ぐと良いことがわかった

2026 こんな年にしたい

  • 人をご飯に誘う
    • 結局 2025 は一回も誘ってないのでは？
  • 健康第一
    • 社会人になる前から運動習慣を身につけられたのは良かった
    • 継続
  • 社会人一年目に伴う環境の変化にうまく順応する

昨年の振り返り 2025

今週のお題は「2024こんな年だった・2025こんな年にしたい」らしい。

昨年の振り返りを 2025 年にしているため、これは 2024 年の振り返り記事です。

  • 2024 こんな年だった
    • 1 月
    • 2 月
    • 3 月
    • 4 月
    • 5 月
    • 6 月
    • 7 月
    • 8 月
    • 9 月
    • 10 月
    • 11 月
    • 12 月
    • まとめ
  • 2025 こんな年にしたい

2024 こんな年だった

月ごとの出来事を適当に並べてみた。

1 月

  • VRChat で使っているミーシェ[^1]というアバターを Avatars 2.0 から 3.0 に対応した結果、しゃがんだときに前を向けるようになった
  • 1 月末には既に花粉の気配を感じ、病院に行って薬を飲み始めていた。花粉症シーズンは例年より楽だった気がする？
  • VRChat で無料英会話！と言いながらこの頃にも EN-JP Language Exchange[^2] に入り浸っていた
    • 2023-12 頃に留学生が研究室に来るようになってからは、英語を日常的に現実世界で話す機会がとうとう訪れたことにテンションが上がって練習を積む必要があると感じていたため

2 月

  • 卒論提出！
  • 卒研発表もした
  • 大学院の入学用書類も提出した
  • この頃はなぜか近場の公園にドライブして散歩することにハマっていた
  • ハリー・ポッターと賢者の石を原文で読んだ
  • 英単語の Anki デッキを作るためのツールを自分用に書いてた
続きを読む

中古 LTO-6 ドライブでホンモノの tape archive を作ったり LTFS を使ったりする

  • はじめに
  • 必要となる機材
    • SAS 接続と SAS HBA カード
  • テープカートリッジの挿入と書き込み
  • LTFS の構築・マウント・読み書き
  • おわりに

はじめに

複数のファイルを 1 つのアーカイブにまとめたいとき、サーバ管理者はしばしば tar というコマンドを使います。アーカイブの出力先には HDD 上のファイルや stdout を選ぶことが多いでしょう*1。

ここで FreeBSD の tar(1) の man ページを見てみると、「tape archive の操作をする」という簡素な説明が掲載されています。

tar -- manipulate tape archives

英語版 Wikipedia の記事によると、そもそも tar コマンドはファイルシステムを持たない sequential な I/O デバイスにデータを書き込むために開発されたものであったようで、その代表例として磁気テープの利用が挙げられています。tar という名称も tape archive が由来であるようです。

The name is derived from "tape archive", as it was originally developed to write data to sequential I/O devices with no file system of their own, such as devices that use magnetic tape.

tar (computing) - Wikipedia

これらのことから、「tar コマンドを使って磁気テープに書き込んだらそれはホンモノの tape archive では？」と思い、一生に一度は体験しておきたいと強く思ったため（？）早速機材を揃えて試すことにしました。

なお、この記事の執筆にあたっては Ubuntu 22.04 が動作する環境で作業を行いました。

*1:tar | lzop | ssh のように組み合わせて巨大なファイル群を転送することもあるかも

続きを読む

RubyKaigi 2023 に参加しました

今回は RubyKaigi 2023 に NOC（#RubyKaigiNOC）として参加した。RubyKaigi 自体初参加だったが、今まで知らなかった Ruby 言語を取り巻く事柄について知ることができたり、同じ興味を持つような方々と知り合いになれたりして、心から楽しめた。day -1 から一日ずつ振り返ってみる。

day -1（5/9）

つくばから松本に行くためには 5 時間ほどかかった。

中央線は揺れると聞いていたが、たしかに西八王子駅から西側ではパソコンに合わせている焦点がブレる程度には揺れた。

夕飯にそばが食べたくて Google Maps で営業中の表示があったお店に行ってみたが営業しておらず無念の帰宅……。しかし、その後に他の NOC の方々とご一緒させてもらうことができ、居酒屋などへ行けた。この日から day 4 までは毎日飲んでおり、大学の友達には「ぱぶゆが会期中にずっと酒を飲んでいる様子が Swarm で観測できた」と帰ってから言われた1。

day 0（5/10）

朝からひたすらケーブルを引いたり AP を配置したりなどの L1 作業をした。持ち前の方向音痴スキルにより迷子になっている様子をトランシーバー経由でスタッフさんたちにブロードキャストしていた。

少し前までは八の字巻きが一切できず、難しすぎないか？と思い続けていたが、当日の敷設作業中にはスラスラとできるようになり、同時に八の字巻きの偉大さを体感できた。

外が暗くなるまで作業をしているのは高校の文化祭を思い出させてくれて、ヘトヘトになったが楽しかった。

day 1（5/11）

RubyKaigi 1 日目。朝に来て残っていた敷設作業を完了させ、様々な発表を聞いた。

Matz Keynote

https://rubykaigi.org/2023/presentations/yukihiro_matz.html#day1

Matz Keynote では Ruby の歴史を聞くことができた。特に、2005 年当時に Ruby on Rails を用いて 15 分で Web アプリケーションを作るデモの動画が公開され、それで Rails が画期的であることが広まったという話が印象的だった。おそらく https://www.youtube.com/watch?v=Gzj723LkRJY がそのデモの動画なんだろうと思う2。 ちなみに、私はどちらかというと static type believer です。

RuboCop's baddest cop

https://rubykaigi.org/2023/presentations/gsamokovarov.html#day1

発表者が勤める会社 Dext ではメソッド呼び出しのときにかっこを省略するというスタイルが運用されている。そのようなルールを RuboCop で強制させるようとすると考慮することが非常に多く、単純に実現できるようなことではない。例えば Array や Hash の中でのメソッド呼び出しではかっこが省略できない。 発表者はなんとかして RuboCop にかっこ省略用 Cop を登場させることができたが、以降に複数のエッジケースが見つかり、それぞれを修正していった道筋が発表されていた。 parser gem を使ってインタラクティブに「ここのかっこ抜いたらパースできないですね」を見せている様子が画面に映っていて、見る側としてもわかりやすい発表だった。

Understanding the Ruby Global VM Lock by observing it

https://rubykaigi.org/2023/presentations/KnuX.html#day1

GVL（Global VM Lock；今では Giant VM Lock と呼ばれている）の様子を gvl-tracing gem と https://ui.perfetto.dev/ を用いて観測する様子が発表されていた。そもそもロックとは何か、という話からされていて丁寧だった。Ractor にはそれぞれに GVL があるので、CRuby 上で動作する Thread を用いた Ruby プログラムとは違って concurrency だけでなく parallelism も実現できるのだということを知り、使ってみたくなった。

Official Party

お互いに自分の好きなことなどを話せる機会がたくさんあり、かなり有意義だった。RubyKaigi 参加者の中にそこまで知り合いがいた訳ではなかったので若干戸惑った場面もあったが、最終的には「○○の話題なら××さんがよく知っている」というような風にして知り合いの知り合いな方々と繋いでもらうことができ、こういったイベントの良さが味わえた。

そして、Official Party 終了後には coins の大先輩である Matz さんとのツーショットを得ることができた（とてもうれしい）。

day 2（5/12）

RubyKaigi 2 日目。

JRuby: Looking Forward

https://rubykaigi.org/2023/presentations/headius.html#day2

Android で JRuby を動かすための Ruboto というアプリケーションがあることを初めて知った。実行に必要とする permission の要求が多すぎるのでまだ Play Store にはリリースできていないが、新しいセキュリティの requirements に適合したら publish するらしい？というような話をしていた気がする（曖昧）。

JRuby は parallel な動作を最初からサポートしている（GVL の制約がない）ので、スレッドを利用している既存プロジェクトに導入できればそれだけで有効に働いてくれることが期待できるらしい。

Yet Another Ruby Parser

https://rubykaigi.org/2023/presentations/kddnewton.html#day2

https://github.com/Shopify/yarp に関する発表。すでに CRuby や TruffleRuby、JRuby 内のパーサーとして YARP を使うような実験的フォークがあるらしい。特徴として error tolerance を提示しており、例えば class A の後には自動的に end があったものだとみなし、解析中に missing token をできるだけ残さないようにすることで後続する正しそうなソースの解析に取りかかれるようにしているらしい。

YARP は CRuby の内部や外部パッケージ等には依存していないので portability が高いとのことだった。

曖昧性のある文法や unary/binary 演算子、スペース、do キーワード、エンコーディングの扱いが大変らしい。

The Second Oldest Bug

https://rubykaigi.org/2023/presentations/jeremyevans0.html#day2

タイトルに惹かれて見に行った。 Ruby のバグトラッカーに 2 番目に古いバグとしてずっと残されていたものを完全に解消するまでの詳細が話されていた。 object_id(*1380888.times) のように、大量の引数と共にメソッドを呼び出すと Ruby 1.9 以前までは core dump を吐いてしまっていた。Ruby 2.2 では Ruby で定義されたメソッドについては問題が修正されていたが、C で定義されたメソッドでは問題が残っていた。

修正 PR は https://github.com/ruby/ruby/pull/7522 のようだったが、CRuby 筋は一切ないので差分だけ見てもあまりピンと来なかった。事前に https://silverhammermba.github.io/emberb/c/ をサッと読んだが、それだけでは知識が足りず。

夜

この日は他の会社に所属している方々をランダムに集めて作成されたグループに入り込み、居酒屋へ行った。

ソフトウェア開発のあるあるが話題の多くを占めていて、どこでも似たような問題に悩まされているのだな〜と共感していたのは覚えている。しかし、ちゃんと酔っていたので詳細まではしっかりと覚えていない……。でも、これも普段なら絶対に知り合わなかったであろう人同士で会話ができたという点で、物理イベントの魅力が体感できた良い機会だったと思う。

day 3（5/13）

RubyKaigi 3 日目。

15 時前から撤収作業をしなければならなかったため、発表はあまり聞かなかった。バッヂを手に入れたかったので午前中はスポンサーブースを回っていた。

GMOペパボさんのブースでアイコンを印刷してくれるサービスが実施されており、これに興味があったので最初に向かった。

各社のブースを回っている途中でおみくじやガラガラを試しにやってみたら、アンドパッドさんと Fastly さんのところでそれぞれ大吉と一等を出してしまった。運を使い果たした感がすごい。

NOC の撤収作業は 20 時半ぐらいまでやっていたので After Party には行かなかった。

RubyMusicMixin 2023

なんと、RubyKaigi が終わった後にデカい音を聴くことができるイベントがあった。落ち着いて話せる場所も併設されており、そこで音ゲー考古学やネットワークの話をする機会があった。

終盤になって急に MOGRA などで聴くタイプの楽曲が大量に流れてきて完全に最高になってしまった。まさかネオンライトのアレが目の前で実演されるとは思わなかった……。選曲がずっとオタクを刺しに来ており、朝まで DJ してほしかった。

観客にはかなり勢いがあって、私が参加する普段のクラブイベントではここまで盛り上がっていた例は見たことがなかった。超楽しかった。

day 4（5/14）

文字通り「ダムに行くよ」という前情報のみを得た上でレンタカーに乗せてもらい、ダムや円筒分水を見て回った。この車内で流れている曲もまた自分のプレイリスト勝手に覗かれてるんか？と思うぐらい好みが overlap していた。 運転手の方と国道走破について雑談していたら片道GO!というレンタカーサービスの存在を教えてもらえたのでかなり使ってみたくなった。 自動的にぼざろや咲-Saki-の聖地巡礼ができて有意義なドライブだった。

全国的にそう多くない円筒分水が長野の一部地域で並んでいるという情報が得られ、複数の円筒分水を見る機会があった。交差点チェックインアプリを書いていたおかげで素早く円筒分水ズにチェックインすることができた。

長峰山山頂展望台から見える中央自動車道は綺麗だったが、ちょうどそのタイミングで一眼レフのバッテリーが切れてしまって撮影できなかった。機会があればまた行きたい。

長野県の治水勉強デーだった。

day 5（5/15）

午前中は残っていた撤収作業をした。信州そばを食べ、松本城へ。天守の階段がとんでもなく急だった。次の日は研究室での予定があり、早めに帰らなければならなかったので松本ブルワリーにいた NOC の人々に挨拶をして帰宅した。

帰りの特急あずさ46号は洗堀計の故障3で 2 回急停車し、また別の車両で異音を察知したため 1 回急停車した。その結果、98 分遅れで終点の新宿に到着した。一瞬帰れるか心配になったが、つくばの循環バスの終バスにギリギリで間に合い、帰宅できた。 急停車する電車に乗車した経験が今までなかったので、それらが積もって一気にやってきたのかもしれない。3 回も停まるとは思わなんだ。

RubyKaigi2023 を終えて

大学入学時にちょうど某が流行りはじめてしまい、こういったイベントに全然参加してこなかった人としては、RubyKaigi 2023 のおかげで物理開催のイベントの楽しさを知ることができてよかった。

NOC 関連の仕事は L1 作業のみしかやらなかったが、大きな会場では事前の計測に基づいた物理構成の錬成や、前日作業のための入念な準備が必要であることを知った。せっかくなので大学でも同じようなことを自分の手で試してみたいと思い、勢いで WLC や AP、スイッチを入手しているところである。 私が所属するサークルの一つには物品管理がまともにされていないところがあるので、以下のような作業風景を見ながらうちもいい感じに整えようと思った。

機会があれば後の RubyKaigi にもぜひ参加したい。本当に。これほど魅力的なイベントがあるとは知らなかった。

最後に、オーガナイザーの皆様とスタッフの皆様、そして参加者の皆様、ありがとうございました。特に、NOC に誘ってくださった id:sora_h さん、参加のための準備をサポートしてくださった id:tomo_ari さん、一般社団法人日本Rubyの会の皆様、そしてクックパッド株式会社の皆様には厚く感謝申し上げます。

追記（2023/05/20 13:50）

Timee さんの「オライリー書籍プレゼント！」キャンペーンでも当選してしまった。ここまで来ると運が良すぎて逆に怖い（ありがとうございます）。

  1. 私自身は普段はそこまで飲まないが RubyKaigi では数多くの機会があった。会場ではクックパッドマートの冷蔵庫にビールが格納されており、そこから取り出して飲むこともできた↩
  2. 2000 年代前半って Impact フォントが流行っていたのだろうか（Flash アニメーションで使われがちな印象がある）↩
  3. 洗堀計って何？↩

ICTトラブルシューティングコンテスト2022（ICTSC2022）に参加しました

はじめに

2023/03/05 から 2 日間に渡って開催されていた ICT トラブルシューティングコンテストに参加しました。

ICT トラブルシューティングコンテストとは

ICT トラブルシューティングコンテスト（略称 ICTSC）は、任意団体であるようです*1。それと同時に、仲間とトラブルシューティング力を合わせることで様々な情報通信技術に関する問題を解決し、その回答の正確さや速さを競うコンテストだと思われます。

一緒に参加した人々

チームメンバーは以下の通りでした。

この 5 人でチーム word-unknown-tsukuba-otaku として参加しました。

解いた問題

私が解いたのは以下の問題です。この順番に解きました。提出した回答もセットでどうぞ。

それぞれどのような方針で解いたのかを簡易的に説明します。

奴の名は（qvf）

ユーザー alice で Linux のパスワード認証をしようとしても弾かれてしまうのでどうにかして直してほしい、という問題でした。/var/log/auth.log を見てみると、pam_ldap が LDAP サーバーに情報を見に行こうとしたときにうまくいっていなさそうだな、ということがわかりました。

私は LDAP まわりの知識がほとんど無いため、Linux のユーザー認証時に LDAP からの情報を参照する際に記述する必要のある設定ファイルを見てみることにしました。すると、どうやら /etc/nsswitch.conf 内で LDAP 用の記述が少し足りていないことがわかったので、これを追記することで「ログインできてシェルを得る」ことが実現できました。あとは報告書を書きました。

感想：研究室で今度 LDAP まわりを触る機会がありそうなので、その練習になった気がします。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-qvf-md

盲点の窓（rct）

host01 で nginx.service の様子を確認すると起動に失敗していることがわかります。nginx.conf からは blog.example.jp のための nginx の設定ファイルを参照しているのですが、このファイルはシンボリックリンクを間違えて自分自身に貼っているものになっており、その旨を伝えるエラーメッセージが出ていることもわかりました。

sites-available/blog.example.jp にあるものを sites-enabled/blog.example.jp に貼り直してあげて nginx.service を restart すると、これは正常に起動するようになりました。しかし、この段階では bastion から curl -H 'Host:blog.example.jp' 192.168.255.9 を叩いても 502 が帰ってきてしまいます。そのため、リバプロまわりがおかしそうだなと思い blog.service のファイルと sites-available/blog.example.jp を見比べてみると、前者を起動するときに listen する host は 192.168.255.9 になっているのに対し、後者で nginx がアクセスする際に指定しているのは localhost すなわち 127.0.0.1 になっており、リクエストが blog.service に届いていませんでした。このため blog.service が listen する host を localhost に変更し、これを restart して問題を解決することができました。あとは報告書を書きました。

感想：エラーログと systemd service のファイルを読むと流れに沿って解けるようになっていてよかったです。nginx の設定ファイル側を解決するだけではダメ、というように問題が二段重ねになっているところにリアルさが感じられて楽しかったです。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-rct-md

pingが飛ばない（vzx）

Host01 で ip route get 172.17.0.1 をしてみると Network is unreachable と言われてしまうので、経路情報が足りていないことがわかりました。そこでデフォルトゲートウェイの設定を流し込みました。しかし、それでも ICMP Echo Reply は帰ってきません（おおきなかぶ）。ルーター 172.16.255.254 で tcpdump をしてみると ICMP Echo Request までは届いているけれど、ICMP Echo Reply はキャプチャできなかったことがわかりました。ここでウーンと唸っていたらチームメイトに firewall の設定見た？と言われ、アッと思いすぐさま firewall の設定を見てみると TCP のものはすべて通す設定がありますが ICMP については特別 accept してる訳でもなく drop されていたことがわかりました。このため、ICMP は accept するようなルールを追加してあげることで問題を解決することができました。あとは報告書を書きました。

感想：やりたいことをまとめると複雑なものでは無かったのですが、VyOS 筋が一切なかったので入門しながら解くことになりました。良い体験でした。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-vzx-md

俺自身がDHCPサーバーとなることだ（wsm）

他のチームメイト 2 人がわからないまま残していたため心してかかりました。一見して dhcpd.conf 自体は問題なさそうだったので割と悩んでしまいました。また、初期状態のまま DHCP サーバーを起動すると SSH 接続が切れてしまい、何回か再展開を実施することになりました。

ip a で 10.0.0.1 が自分のマシンの network interface のうちどれかに割り振られていることは確認したのですが、ではこれが netplan の設定ファイルで本当にそうなるように書かれているのかと気になって確認してみたところ、なんと書いてありませんでした。これが原因なのかと思い、IP アドレスの固定の設定を netplan の yaml に入れて apply した状態で DHCP サーバーを起動したところ、SSH セッションが切れることなくうまく動いてくれました。おそらく DHCP で配ることを指定した範囲の最初の IP アドレスが machine-x に割り当てられるだろうと考えたので ping したり ssh してみたところ接続できたのでビンゴでした。あとは報告書を書きました。

感想：再展開キューに何度も積んでしまった。すみません！🙇‍♂️
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-wsm-md

Beer (sjq)

BGP ルーターに限らず、ソフトウェアルーターはそもそも BIRD*2 しか使ったことがなかったので、最初は苦戦しながら FRRouting のコンフィグを書きました。

素直に AS65002 から広報される prefix を FIB*3 に入れるようにすればよいです。1 回目の提出では広報されていることのみを確認し、対向の BGP ルーターを経由することなく 192.168.17.102 と繋がるような経路で疎通確認をしてしまったため 0 点でした。

チームメイトの中に趣味で iBGP をやっている人がいて、その方に 2 日目の最初にこの問題を一度任せましたが、途中でまた問題が手元に戻ってきました。その間にコンフィグには no bgp ebgp-requires-policy という設定が新たに入れられていました。これを調べてみたところ、no bgp ebgp-requires-policy という設定を router bgp 65001 内に入れることで filter 等を定義することなく FIB に経路情報を入れることができるものということでした*4。ただ、これだけでは足りてなかったようで、network interface の設定も FFRouting のコンフィグに入れてあげることで FIB に経路情報を登録させることができました。

感想：趣味では BIRD でしか BGP を扱ったことがなかったので刺激的でした。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-sjq-md

おわりに

ソフトウェアルーターらしきものは今まで BIRD しか触ったことがなく、今回 VyOS や FFRouting に触れたときに「これって R○X1200 とか Cisc○ みたいな書き味でコンフィグ書けるのか！便利だ〜」となりました。

コンテスト中の私は、高得点で専門性を要するような問題は他の方に任せて、あまり高くない点数のものを率先して解くようにしていました。SRE っぽいことはあんまりわからないのですが、BGP に関する問題は趣味でグローバル IPv6 アドレスを広報していたおかげでなんとかなりました。自分が LIR に払った 5 万円ぐらいのお金は今回だけでも回収できた気になれました。

両日とも 12:00 頃までは家で集中して各自が問題を解き、13:00 頃に大学に集合してからはアドバイスや相談をしあいながら黙々と解いていました。たまたま各領域に詳しい人が集まったので、うまく並列しながら問題の消化を進められたものと思います。

初めて参加したのですが、まさにこのようなコンテストがあると解きがいがあるなと思い、心から楽しめました。

そして、なんと優勝することができました！チームメイトには大変感謝しています！！運営の方々も魅力的なコンテストを開催して頂きまして本当にありがとうございました。

word-unknown-tsukuba-otaku が 1 位であることを発表するスライド

おまけに

4 人友達がいてよかった図

*1:https://icttoracon.net/about-ictsc

*2:https://bird.network.cz/

*3:Forwarding Information Base

*4:https://docs.frrouting.org/en/latest/bgp.html#clicmd-bgp-ebgp-requires-policy 参照

迅速な Swarm のチェックインへの取り組み

この記事は WORDIAN Advent Calendar 2022 の 25 日目の記事です。

はじめに

筆者は Foursquare Labs Inc. が提供する Swarm というサービスを日頃から利用しています。

Swarm は、ユーザーが現在位置周辺にある様々な施設や場所を選択して、その場にいたことの記録を残すためのサービスです。このとき、同時にメモや画像を残すこともできます。残した記録のことを「チェックイン」と呼び、記録を残すことを指して「チェックインする」と（大学の友達との間で）表現しています。

Twitter で "I'm at ○○○" という文言と一緒にリンクを共有しているアカウントを見たことはありませんか。そのような人々は Swarm と Twitter アカウントを連携させることでチェックインの共有をしているのです。

以下はそのようなツイートおよびチェックインの例です。

（対面開催された学園祭を見に行ったときの様子）

（鉄道開業150年記念 JR東日本パスが使える新幹線での最北駅まで来たので、ついでに山内丸山遺跡に行ったときの様子）

チェックインできる施設や場所について

チェックインを行う際に選べる場所は沢山あります。例えば、日本料理屋、コンビニエンスストア、大学の教室、駅、キャンプ場、居酒屋、イベント会場、ゲームセンター、公園、ダム、城、県境、サービスエリア、道の駅、橋、交差点など……。いろいろありますね。

さて、筆者はドライブと Swarm でチェックインしてコインを稼ぐことが好きです。これらの趣味が組み合わさると、上で後半に挙げたような場所でチェックインする頻度が非常に高くなります。特に、交差点でチェックインできることを知った日からは頻度が異常に高くなりました*1。

公式アプリを用いた交差点でのチェックインを行う際の課題

しかし、交差点でチェックインするときに少し困ることがありました。一つ目は、Swarm で現在位置周辺の場所を列挙させても最初から交差点が出てくる場合は少ないので、キーボードで「交差点」と入力して検索する必要があることです。二つ目は、運よく目的の交差点が最初から画面に表示されていて検索の必要が無かった場合でも、以下の 3 つの操作を最低限行う必要があることです。

  • 施設や場所の選択画面に遷移するためのボタンを押す
  • チェックイン対象の交差点を選択するボタンを押す
  • チェックインを作成するためのボタンを押す

これらの操作は画面をよく見てボタンを判別する必要があるため、手間がかかります。スマートフォン等は停車中であれば操作しても問題ありませんが*2、煩雑な操作をしていてつい夢中になってしまい、信号が青であることに気づかないようなことが起こるのは良いことではありません。

そこで、私は安全な交差点のチェックインを行うための Android アプリケーションを開発することにしました。

Interscheckin

Interscheckin は、交差点でのチェックインを補助するために作成された Swarm 利用者のための Android アプリケーションです。

このアプリケーションでは、前述の課題を解決することを目標としています。

一つ目の課題であった「『交差点』と入力して検索する必要がある点」は、Interscheckin に「運転モード」というチェックボックスを用意することで解決できました。運転モードが有効化されていると、公式アプリで「交差点」まで入力して検索したときと同等の検索結果をいつでも表示させることができます。

運転モードの有無による違い

二つ目の課題であった「チェックインをするために最低でも 3 回の操作をする必要がある」は、各場所を表す部分を長押しするだけでチェックインできるような操作を取り入れることで解決できました。

ロングタップでチェックインをしている様子の動画

ダウンロード

build_apk.yml で定義されている Workflow を実行すると Artifact としてビルド済み APK がアップロードされるようになっています。例えば、記事執筆時点で最新の APK は https://github.com/private-yusuke/interscheckin/actions/runs/3750231180 にある "outputs" をクリックすることでダウンロードできるようになっています*3。

Interscheckin で利用しているライブラリなど

だいたい以下のようなものを利用して作成されています。

また、この Android アプリケーションは開発の練習のための実験場として使っているという側面もあり、例えば CI で Instrumented test を走らせる試みをしています（無論、実際の開発現場では instrumented test を含めて自動的にテストするのは普通のことですが、その仕組みを自分の手で作ったことが無かったので試せて良かったと思っている）*4。GitHub Actions の macos-12 ランナーを利用してテストを実行しているのですが、4 回に 1 回ぐらいの確率で落ちるという超絶 flaky 状態なので、有識者の方がいらっしゃいましたら是非この Issue でコメントを残して頂けるとありがたいです。

おわりに

Interscheckin を開発することにより、簡単にチェックインができるようになりました。気になった方はぜひ利用してみてください！

また、このような私利私欲アプリケーションを作ってみると日常的に行う動作を補助できて大変楽しいので、みなさんも是非モバイルアプリの開発をしてみてください。

おまけ

ちなみに、他の私利私欲アプリの話をすると、（昔に作ったので中身はキレイではないですが）緊急警報放送をパースするための Android アプリケーション EWSParserApp もあります。NHK 総合で毎月 1 日正午に放送される「試験信号放送 〜緊急警報放送〜」に思いを馳せている方は、このアプリを起動してスマホのマイクで音を拾うと、流れている信号の内容を知ることができて面白いので試してみると良いかもしれません。

*1:短時間にチェックインしすぎるとコインが貰えなくなる現象を頻繁に体験するようになった

*2:道路交通法第七十一条 五の五を参照

*3:落ちてくる zip ファイルを解凍すると、中に app-release-unsigned.apk が入っている

*4:例：メモがチェックインに反映されていなかったのを修正した PR

2^64 個のグローバル IPv6 アドレスを用いたクイズを作ってみよう

この記事は 天久保 Advent Calendar 2022 の 18 日目の記事です。

はじめに

最近、コンピュータネットワーク周辺に興味のある私の友達が AS 番号を取得していました。なんとなく面白そうだったので、私も取得してみることにしました。

すると、契約時になぜか 280 個のグローバル IPv6 アドレスが無料で付いてきたのです。今回はこの資源を利用した遊びの 1 つを紹介します。

AS 番号とは

AS 番号とは、世界中にある Autonomous System（自律システム）それぞれを一意に定めるための番号です。では、自律システムとは何でしょうか。

ASは、統一された運用ポリシーによって管理されたネットワークの集まりであり、 BGPのような外部経路制御プロトコルによる管理対象となります。

出典：https://www.nic.ad.jp/ja/ip/asnumber.html

統一された運用ポリシー……？よくわからないので、実在する AS を見てみることにしましょう。例えば、以下のような AS が存在します。

名前 AS 番号
So-net AS2527
筑波大学 AS37917
さくらインターネット AS9370, AS9371, AS7684, ……
Google AS15169, ……

これらの AS を持つ組織は、その内に様々な部署や研究室、または拠点を持っており、そこで利用されているネットワークの資源を何らかの方法で管理していることが推測されます。それなりの規模がある組織で AS 番号が取得されている様子がわかります。

上に挙げた「さくらインターネット」は複数個の AS 番号を持っていますが、https://www.sakura.ad.jp/peering/ によればリージョンごとに上 3 つの AS 番号を利用してネットワークの運用をしているようです。このように、必ずしも 1 組織 1 AS のみ持つという訳ではありません。

Google も AS 番号を持っていますが、検索結果に 32 個も出てきたので省略しました*1。おそらく、買収した企業の AS 番号を Google LCC 名義に変更するのを何度も繰り返すなどのことをしているからではないかと思います。

AS 番号とグローバル IPv6 アドレスの取得

AS 番号とグローバル IPv6 アドレスは https://www.securebit.ch/internet/resources/autonomous_system から取得することができました。このとき、RIPE NCC の地域に住んでいない人は https://www.securebit.ch/server/internet_exchange から IX サーバーを借りる必要もありました。これら 2 つの費用を合わせると、初期費用 43,368 円（2022/10/03 時点）が必要でした。

/44 Bundle と書いてあるのに /48 の prefix がバンドルされていましたが、むしろ /48 よりも大きなものを頂いても困ってしまうので助かったような気分になりました*2。

AS 番号新規登録申請をした際には、上記ウェブサイトでは特にグローバル IPv6 アドレスが付いてくる旨は商品一覧ページに記載されていなかった気がします。しかし、申請フォームに各種情報を入力していたところ、「もしグローバル IP アドレスを持っていないなら無料で /48 のグローバル IPv6 アドレスを貸してあげるよ」という文言が書いてある欄を発見し、これはとんでもなく太っ腹であることだな、と思いながら BGP で広報できるグローバル IPv6 アドレスを 280 個*3貸していただくことにしました。

しかしながら、/48 のグローバル IPv6 アドレスを一人で使い切ることなどできるでしょうか（いや、できません）。そこで、贅沢なことですが 264 個のグローバル IPv6 アドレスを用いたクイズを作成してみることにしました。もっとも、これだけ使ってみたところで、まだ全体の 1/65536 しか使えていない計算になる訳ですが……。

AnyIP について

急に Linux カーネルの一機能の話をします。

通常、Linux では、ある 1 つの IPv6 アドレス（ここでは 2001:db8:beef:cafe::1 とする）に対する通信を受け取ってアプリケーションで処理するには ip addr add local 2001:db8:beef:cafe::1/64 dev dummy1 のようなコマンドを発行し、ネットワークインターフェイスに 1 個ずつ IP アドレスを割り振ってあげる必要があります。

しかしながら、この理屈でいくと、仮に 2001:db8:beef:cafe:babe::/80 以下のすべてのアドレスに応答したいとなったら、前述のコマンドを 248 個の IP アドレスの分だけ叩くことになりそうですね。そんなことは到底していられません。

そこで、Linux カーネルには AnyIP と名付けられた機能が実装されています。

The AnyIP feature of the Linux kernel allows you to bind a complete IPv4 or IPv6 subnet to your system.

Instead of adding all addresses manually to the kernel you can tell it to bind a complete subnet.

出典：AnyIP: Bind a whole subnet to your Linux machine

これは、例えば 2001:db8:beef:cafe:babe::/80 以下のすべてのアドレスに応答したいとなったら ip -6 route add local 2001:db8:beef:cafe:babe::/80 dev lo と一度叩くだけでそれを実現させてくれる機能です。今回は、この機能を活用して 264 個のグローバル IP アドレスを用いたクイズを作ってみることにします。

問題！正解のグローバル IPv6 アドレスはどれかな？

追記：このクイズは、すでに遊べません。以下の記述は当時の IP アドレスを例示用 IP アドレスに変更の上で残してあります。

注意：このクイズは、IPv6 の接続性がある環境でしか遊べません……。もし繋がらなかった場合は、IPv6 の接続性を持つマシン（大学の計算機など）に SSH して、そのマシンから curl コマンドを使ってアクセスするなどの工夫をしてみてください。

問題文：

http://[2001:db8:18a:2000::]:8080/

（問題文おわり）

上記の情報のみで、それっぽい正解が見つけられた方は、おめでとうございます。

ヒント

↓
↓
↓
↓
↓

（はてなブログって IPv6 アドレスを直接書いてリンクにすることができないようですね。もしクリックしてアクセスできないことに困っている場合は、コピーしてブラウザの上部バーに貼り付けてみてください）

↓
↓
↓
↓
↓

（もうすぐヒントが見えます）

↓
↓
↓
↓
↓

  1. （念のため）：http://[2001:db8:18a:2000::1]:8080/challenge にアクセスしてみましたか？
  2. 264 個のグローバル IPv6 アドレスを用いたクイズであることに注意
  3. IPv6 アドレスの表記方法：https://www.nic.ad.jp/ja/basics/terms/ipv6-text-representation.html
  4. 2001:db8:8a:2000 から始まる様々な IPv6 アドレスを指定してアクセスしてみよう
  5. 要素数が 264 の全順序集合と考えると、使えるアルゴリズムは……？
  6. 頭から確定させてみよう

正解

http://[2001:db8:18a:2000:2525:beef:4649:babe]:8080/challenge

見つけられた方は、おめでとうございます！！*4

ブラウザの URL 入力欄で少しずつ数値を変えていけば、いつか見つけられるはずです。賢くやるならば、64 回ぐらい試行錯誤することで正解に辿りつけたのではないかと思います。

もっとも、16 進数が使える場面で書かれがちなフレーズが含まれているので、カンが良い方は 64 回以下で当てたかもしれません。

想定解法（その 1）

まず http://[2001:db8:18a:2000::]:8080/ にアクセスしてみると、

You can make requests to: /host, /challenge

というメッセージが表示されます。そこで、http://[2001:db8:18a:2000::]:8080/host にアクセスしてみると、自分がアクセスしている IPv6 アドレスと同一のものが帰ってくることがわかります。また、http://[2001:db8:18a:2000::]:8080/challenge にアクセスしてみると、何やら意味深なコメントが含まれた JSON が帰ってきます。

{"result":-1,"comment":"Too poor to be true (The answer is greater than the value you specified)"}

ここで、そういえばこれは 264 個もの IPv6 アドレスを使ったクイズであったということを思い出します。

2001:db8:18a:2000::/64 以下の IPv6 アドレスでアクセス可能なものは 2001:db8:18a:2000:: から 2001:db8:18a:2000:ffff:ffff:ffff:ffff の 264 個です。

そこで、試しに http://[2001:db8:18a:2000:ffff::]:8080/challenge にアクセスしてみます。すると、メッセージは以下の形式に変化します。

{"result":1,"comment":"Too rich to be true (The answer is smaller than the value you specified)"}

今度は「値」が大きすぎるという旨のメッセージに変わりました。ここまで来れば、だいたい察しがつきますね。

いろいろ試してみると、
http://[2001:db8:18a:2000:2fff::]:8080/challenge では大きすぎて、
http://[2001:db8:18a:2000:1fff::]:8080/challenge では小さすぎる
というメッセージを受け取るので、次に探索すべきは
2001:db8:18a:2000:2000 から
2001:db8:18a:2000:2fff の間である、ということが判明します。これで、IPv6 アドレス下位 64 ビットのうちの上位 4 ビットを特定することができました。

これ以降は、この「大きすぎる」と「小さすぎる」の間をどんどん深掘りしていく作業になります。

想定解法（その 2）

以下のようなプログラムを書くことでも答えを導くことができました。

バグらせて無限にリクエストを送ることがないように注意！

おわりに

IPv6 アドレスがまだまだ余っているので、もし他によい遊び方がありましたら、ぜひ教えてください！*5

また、当 AS とピアリングすることに興味が出ましたら、ぜひご相談ください。当方、ピアリングの実験をしてみたいと常々思っています。

おまけ

サーバーで動いているプログラムのソースコードは以下のリンクから見ることができます。

https://gist.github.com/private-yusuke/d1bc5f3edaf720eb92747f305824f9d6

*1:2022/12/17 時点

*2:それに /48 の方がキリが良い。普通に誤記だと思う

*3:128 - 48 = 80

*4:ニコニコビーフ・よろしくベイブに特段意味がある訳ではない

*5:今回のクイズ以上に実用性のないものや、より実用性のあるものなど、なんでも