走行記録

前回のICPC 2023 Asia Yokohama Regional スタッフ参加記録 に書ききれなかったことを追記していきます。今回はスクリーンキャストについてです。 まとめ 中継に選手のスクリーン動画を出すことに2019年から挑戦しています。しかし、2023年度も中継で活用できるまでには至っていません。これまでの変遷と、課題について列挙します。 背景 ICPC 横浜大会では大会の中継を行なっています。 大会の様子を流したり、問題の解説をしたり、先生や過去の参加者に話をしてもらったりしています。しかしプログラミングコンテストの大会の中継として、本当にほしい絵は大会に実際に参加している選手の動きです。というわけで、ICPC プログラミングコンテストのシステム班としての作業の一環として、選手のコンピュータのスクリーンキャスト、すなわちコンピュータ画面の動画を取得し、中継素材として提供するという作業をしています。 当面の理想系は ICPC 世界大会の中継動画です。動画の途中に何度も、スコアボード、選手のコンピュータスクリーン、選手の顔、それから最近の選手の回答提出一覧が出ているのがわかります。 構成の変遷 ICPC でのコンテストネットワークの構成は、前にも示した通り、選手コンピュータと審判サーバへの出口からなります。 この選手のコンピュータの画面を動画として取り込み、視聴者に届けるのが今回の目標です。画面を動画として取り込むソフトウェアとして我々は ffmpeg を選手コンピュータ上で動かしています。ここまではどの構成でも同じです。そこから動画を中継や視聴者に提供する方法と経路にかなりの変遷があります。 2019 版 全自動で選手のスクリーンキャスト動画を合成し、YouTube Live に届けるサーバを立てました。ランダムなチームの動画を 30 秒ずつ作って合成しました。中継との連携は行わず、動画は中継の副チャンネルで流されました。 中継と連携しなかった理由は、そもそもどこまでできるか、当日ちゃんと動くかとか何も定かでなかったからです。また、コンテスト本番以外にそれと同規模のテストをする環境もありませんでした。VM4,5台や実機2台を用いた動作確認を事前にしたのち、本番で選手コンピュータ60台のスクリーンキャストを処理していました。 2019年度の動画配信構成 動画中継サーバが選手コンピュータの選定、録画リクエスト、合成、YouTube Live へのアップロードのすべてを行います。 動画中継サーバから選手コンピュータに ssh で接続し、ffmpeg を起動してスクリーンキャストを自分に送るようにする。 接続するコンピュータは30秒ごとに切り替える。 集まった動画4つを OBS でまとめて YouTube Live に流す。 利点 動画中継サーバの設定だけでコンテンツができる。 難点 中継と連携ができない。自由な操作はできず、ただランダムな4チームの動画が 30 秒ごとに流れる。 この後2年、コロナでオンサイトコンテストがなくなり、ICPCアジア地区予選横浜コンテストはオンラインで行われました。オンラインの場合は選手コンピュータが我々の管理下にはないので、スクリーンキャストを統一的に提供するのは不可能でした。 2022 版 中継班との連携を模索したもの。本番直前に問題が発覚しお蔵入りしました。 今回は中継版との連携のため、インフラは選手のスクリーンキャスト動画を全て中継班に渡すところまでにしました。動画を処理して視聴者に渡すところは中継班が担当します。ここで問題になるのは動画を渡す経路でした。中継班のコンピュータはコンテストネットワークの外にあり、コンテストネットワーク内の選手コンピュータや動画中継サーバにはアクセスできません。そのため、中継動画をインターネット経由でアクセスできるようにしました。 2022年度の動画配信構成 ポイントは動画アクセスポイントで、ここで選手のスクリーンキャストが以下の経路で提供されます。 選手コンピュータすべてで ffmpeg を起動し、動画中継サーバにスクリーンキャストを送る。 動画中継サーバは受け取った動画を HLS 形式で保存し、HTTP で提供できるようにする。 クラウド上に立てた動画アクセスポイントと動画中継サーバを VPN で接続し、上記の HLS をインターネット経由で読めるようにする。 一方で中継班は、スクリーンキャスト動画の合成のために、世界大会でも使っている中継用ソフトウェアである live-v3 の導入を提案してきました。これを使えば、スコアボードやチーム名をスクリーンキャストに組み合わせるのも容易ですし、特定のチームのスクリーンキャストを呼び出すこともできます。しかし、このソフトウェアとの接続でいくつかの問題がありました。特に二番目の問題が深刻で、これが原因で中継でスクリーンキャストの採用ができませんでした。 live-v3 が動画形式として mp4 と WebRTC Grabber しかサポートしていない。特に HLS がない。 対策として HLS → mp4 変換サーバを書き、上記の動画アクセスポイントに載せました。アクセスに応じて HLS の最新30秒を mp4 に変換して返すサーバです。内部的には ffmpeg を叩いて合成しているだけです。 live-v3 が「スコアボードの情報」として要求する情報に機密性の高い情報が含まれている。 これに気づいたのが現地でした。中継チームは 選手のOB/OGメンバでしたが、セキュリティ上の理由で彼らに審判サーバの管理者権限は渡せなかったので、採用できませんでした。これについては2023年度のところでもう少し解説します。 2023 版 インフラ的には 2022 年と同じで、 live-v3 対応のために審判サーバとの連携を工夫しました。 2022年度版に存在した問題は解決し、中継は動作したものの、いくつか難点がありあまり活用されませんでした。 解きたい課題 問題 live-v3 は審判サーバのデータを必要とします。しかし live-v3 が要求する情報には公開スコアボードに含まれる以上の情報が入っていて、その中には審判団とコンテスト運営チームの一部以外に共有できない機密情報もありました。 具体的には、live-v3 は審判サーバの /event-feed という API から提供されるデータを必要とします。 /event-feed はコンテストで起きたことのリストを時系列順に出したものです。 問題として、ここには中継班に提供するには危険なほど重要な秘密情報が入っています。例えばコンテスト中は選手から審判団へ問題に関する質問を送ることができますが、その問い合わせ内容が全て入っています。 解法 /event-feed を安全に中継班に公開するために、審判サーバの /event-feed から機密情報、非公開情報を全て落とすサーバを書きました。審判サーバの /event-feed を読んで、チーム名と公開順位以外のすべてを落として提供すようにしています。 結論が簡単になってしまったのでかんたんに見えますが、この解決策にたどり着くまでに週末を数ヶ月分消費しました。具体的には live-v3 の Kotlin ソースコード解析や、馴染みのないコンテスト API の調査が必要でした。 残された問題点 以上で課題は解決したのですが、以下の問題が新たに見つかり、その結果スクリーンキャストはあまり活用されませんでした。 HLS → mp4 変換サーバのため、動画は30秒ごとにしか取れない。 何らかの原因によって動画が10分遅れた。常に10分前の動画が見られる状態になっていた。 前者が致命的で、このため中継でゆっくり映像を解説できません。 また、後者はテストのときは見つかりませんでした。 次年度へ向けて 中継班が連続的に動画を見れるようにするためには、以下どちらかの解決策を取る必要があります。 live-v3 の出力 HTML に手を入れて HLS をサポート。hls.js を追加すればいいと思っています。 WebRTC Grabber なるものを使う。お手製ソフトを選手マシンにあまり入れたくないですが、コード自体は大した量がないので理解して進めます。 hlsの遅延や、WebRTC Grabber が世界大会で使われていることを考えると、後者を選択するのが良さそうです。前者に比べて変更する量がかなり多く、特にインフラの書き換えが必要になりますが。 余談 テストについて 2019年度のところで少し言及しましたが、スクリーンキャストインフラのテストには工夫がいります。コンピュータ実機60台を用いて事前にテストをするのは我々の予算と機材では難しいですし、一方である程度の負荷試験や接続試験はしないと何も保証ができません。今年度のスクリーンキャストの構成では、以下の構成のテストを行いました。 選手コンピュータ–動画中継サーバの構成のテスト。選手コンピュータからスクリーンキャストをし、動画中継サーバでそれを受け取って HLS 形式で保存。 動画中継サーバ–動画アクセスポイントの構成のテスト。動画中継サーバ上で ffmpeg を動かしてリアルタイムで HLS を生成し、動画アクセスポイントとつないでインターネット経由で HLS を見られるようにする。 動画中継サーバの負荷試験。スクリーンキャスト動画をあらかじめ10個 mp4 形式で保存。それらを並列で一台の動画中継サーバにライブストリームし、動画中継サーバ上で10個並列でHLS形式で保存。マシン負荷を計測。 live-v3 の機能テスト。2の構成と同じく動画中継サーバ上で HLS を10個作成し、動画アクセスポイントとつないで HLS をインターネット経由で見られるようにする。並行して審判サーバを動かし、10チーム参加のプログラミングコンテストを開催。 live-v3 でコンテストのスコアボードと HLS の動画の両方を処理できることを確認。 2023年度の構成とテスト範囲。テスト範囲は水色の楕円でおおよそ表されています テストはおおよそ VM をセットアップして行っていました。もちろん負荷試験は例外です。3の負荷試験は実機を動画中継サーバとして用意し、それに動画10本を並列で与えてCPUを5%も使用していないことを確認しました。その結果を見て、60個の動画でも大丈夫だろうという結論を立てていました。 一方で、以下のようなテストはあまりしていませんでした。 スクリーンキャストの遅延試験。選手コンピュータからスクリーンキャストを行い、動画中継サーバで受け取ってHLSで保存し、動画アクセスポイントとつないでインターネット経由でスクリーンキャストを見られるようにする。これを1時間放置し、動画の遅延を計測。 実際に競技プログラミングをやりながらスクリーンキャストを動かしての負荷や帯域の計測。動画の容量は作業によって変わるので。テストの際は、静止画だとだめだと思っていたので、システムモニタを起動したり一秒ごとに現在時刻を表示するスクリプトを動かしたりしていました。 完全に余談ですが、動画のテストをやるのはこの仕事が初めてだったので色々変な知見を得ました。例えばテスト2や4では実際のスクリーンキャストは不要なので、仮の動画を動画中継サーバ上で生成しています。ちょっと探すと以下のように ffmpeg でテスト用の動画が作れることがわかるので、この上に drawtext フィルタで動画番号や現在時刻を書き込んでテスト用動画を作っていました。 https://trac.ffmpeg.org/wiki/FancyFilteringExamples https://nico-lab.net/testsrc_with_ffmpeg/ 問題はテスト動画で何を使うかです。負荷や動画サイズの関係で静止画像はあまり望ましくなく、適度に動きがあるのが嬉しいです。はじめはマンデルブロ集合を使っていたのですが、これを長く動かしていると CPU を多く消費し動画が遅れたりすることがわかりました。そのためテスト動画をシェルピンスキーに変更しました。オートマトンやライフゲームだと長時間動かすとほぼ静止画になってしまう可能性があったので避けました。 感想 スクリーンキャスト整備はかなり大変な作業で、これだけで私の準備時間の 1/2 – 1/3 くらいを消費しています。これを続ける私のモチベーションは二つあります。まずは、せっかくシステム整備をしているのでコンテストを楽しくできるようなシステムを作れた方が嬉しいということ。コンテストセキュリティを考えると、システム担当以外にこの作業に触れる人はいません。それからもう一つ、スクリーンキャストを使えるところまで持っていけばもっと準備は楽になるんじゃないかと思っています。作業時間の多くは不明なところを明らかにするところであり、今までも ffmpeg の使い方やライブストリーム通信のプロトコルの調査、それから今年度は上記の live-v3 のソースコード解析などに時間を使ってきました。それらには再度時間を使う必要はありません。来年度 WebRTC に挑戦するなら、再度プロトコルやネットワークの調査が必要になりますが、それでも例えばネットワーク帯域などの心配をする必要はあまりありません。 一方で、例えばテストがもう少し気軽にできたら、トラブルが減るのではないかとは思います。今は本番と同等の試験ができるのは本番とそのリハーサルしかなく、実物を中継班に共有するのも現地でだけです。試行錯誤がもう少しできれば、もう少し安定したものを提供しやすいと思います。とはいえ、例えば本番の回数を増やすとかで対応したくはないですが。労力がかかりすぎるので。 FAQ Q. 任意のチームの動画が視聴者に見られるようになったりしませんか? A. YouTube Live を 60 チャンネル提供すると回線が大変そうで無理です。 動画アクセスポイントも公開してしまうと、動画アクセスポイント - 動画中継サーバ間の通信が莫大になるので無理です。 Q. コンピュータ画面よりも選手の顔を撮ったほうが良いのでは? A. そのためにはウェブカメラが必要で、全チーム分のウェブカメラを用意しセッティングするのはちょっと大変です。お金と労力両方の問題になります。やるとしても、スクリーンキャストが安定してできて労力が無駄にならないことを確認してからですね。 少数のウェブカメラをスタッフが手持ちで使って選手の様子を撮るのならありです。ボランティアが増えれば検討できると思います。 Q. スクリーンキャスト取得に失敗し過ぎでは? もう少しうまくできる方法があるのでは? A. 年に一回しか試せないので難しいです。私は動画専門エンジニアでもないですし、まずはコンテストがちゃんと動くことを優先しないといけないですし。 ボランティアは歓迎します、と言いたいところですが、コンテストセキュリティとの兼ね合いがあるので実働を頼むのは難しいです。意見は大歓迎です。 Q. 選手のコンピュータへの負荷が気になります。 A. CPU負荷は数%であることを確認しています。 Q. 世界大会の映像はかなり色々やっていますが、これと同等のことはできないんですか? 例えば正解を受け取ったときの選手の顔動画とか。 A. 選手顔動画は上記の通りです。あと、世界大会は映像ディレクターチームが8人とかいるという話を聞きました。こちらは映像ディレクター1人と、システムインフラで片手間の対応です。 Q. 動画アクセスポイントを建てなくても、コンテスト会場のIPで直接つないでしまえばよいのでは? A. コンテスト会場のインターネット出口の挙動は実地でないとうまく実験ができないので避けました。ネットワーク班に頼めばなんとかなった可能性はあります。

2019年に書いてから3年も経ってしまったのですが、今回はちゃんと書きます。特に、毎年やっていることも含めて詳しく書こうかと思います。 ICPC 2023 Asia Yokohama Regional に ICPC セクレタリーズのシステム担当の一人として参加してきました。やってきたことを紹介します。 ICPC セクレタリーズは過去の ICPC 参加者から構成されていて、ICPC の日本での大会をサポートしているボランティア団体です。過去の ICPC 参加者からなる会としては JAG こと ICPC OB/OG の会がありますが、こことは別で、もっと大会運営委員会に近いところの作業を手伝っています。 私はコンテストシステムの担当の一人として、以下の作業を行っています。2015年からやっていて、2016年を飛ばして8年目になります。 コンテスト用コンピュータの選定 コンテスト用コンピュータのインストール用イメージの作成 テスト用のインストールイメージの作成と配布 コンテスト用コンピュータへの計算機環境セットアップ コンテスト前後のプレゼンテーションの対応 コンテスト中のコンピュータの障害対応、およびそれをするためのコンピュータの監視 プログラミングコンテストの環境とは コンテストでは以下のような環境を用意します。 選手のためのコンピュータは全て大会側が用意します。全て同じ機種、同じ環境で用意します。これらはインターネットには繋がっておらず、代わりに「審判サーバプロキシ」とネットワーク接続されています。 一方、選手の書いたプログラムを評価する審判サーバはインターネット上の Google Cloud Platform 内に構築されます。審判サーバプロキシは選手からのリクエストを中継し、審判サーバへ届けます。 図のうち、選手用コンピュータと審判サーバプロキシはコンテストシステム担当の守備範囲です。ネットワークと審判サーバはそれぞれ別の班で担当しています。ハードウェア、ソフトウェアの選定と配置、障害対応を行います。 準備 今回は準備として主に以下のことをしていました。 6月–7月: 計算機環境のベースシステムを Ubuntu 22.04 へ更新。 公開から1年経過した Ubuntu LTS を使うポリシーにしているので今回更新です。何か起こった時の対処が難しいので早めに作業をしています。幸い、20.04 への更新に比べてはるかに安定してできました。 6月ごろから11月までずっと: 中継に渡すスクリーンキャストの仕組みを更新。 スクリーンキャストは 2019 年に導入してからその使い道を模索していました。2022 年に 中継を担当してくれるボランティアの人がついてくれたのですが、そこでうまくスクリーンキャストが活用できなかったので直すことになりました。修正はかなり大変でしたが、結果としてまだ不十分な感じになってしまいました。また来年度に続きます。 1/19追記: 個別に記事を書きました。 8月–9月: JAG 夏合宿への審判システムの提供。 ここ数年は JAG が行う模擬地区予選にコンテスト審判システムを貸し出してテストしてもらっていましたが、今年は JAG が模擬地区予選を行わないとのことで、代わりに夏合宿にシステムを提供することになりました。 9月–10月: コンテスト用コンピュータの選択及びレンタル機の発注。 コンテスト用コンピュータはいつもレンタルで調達していて、必要なスペックの決定と台数の計算をしています。コンピュータは選手用の他に、プレゼン、審判サーバへのプロキシ、選手コンピュータの監視、中継補助など色々な箇所に使っています。 10月中旬: テスト用のインストールイメージの公開。 10月–11月: インタラクティブ問題のテストツール対応。 今年のK問題ではインタラクティブ問題が出て、そのテストツールが選手コンピュータにインストールされていました。これは9月末に審判団から打診が来たもので、10月あたりに仕様のすり合わせを行いました。 10月–11月: レンタル機でのテスト。 コンテスト用コンピュータと同じレンタル機を借りて、コンテスト環境をインストールして挙動を確認します。それまでは VM でテストしていますが、 VM ではテストしにくい挙動はいくらでもあるのでそれをまとめてテストします。 11月: コンピュータセットアップ用の USB メモリの選定と発注。 コンテスト用コンピュータをセットアップするために USB のインストーラメディアを作っています。並列でインストールするために 20 個程度用意しています。以前は台数分の DVD-R を用意していましたが、レンタルコンピュータに光学ドライブがなくなったため USB メモリを使うことになりました。 本番 ICPC Yokohama Reginal 2023 は2023年11月25–26日に、横浜産貿ホール マリネリアで行われました。スケジュールにあるとおり、一日目は登録、開会式及びリハーサルを行い、二日目に本番のコンテストを行います。 スタッフは前日から会場に入って準備をします。 24日 準備 この日は準備です。電気とネットワークを配線し、選手のコンピュータを含むコンテスト用のコンピュータ全てを配置します。目標はモックコンテスト、すなわち会場の選手用コンピュータでボランティアだけで簡単なリハーサルコンテストをやることです。 システム担当の掌握範囲は現地のコンピュータのソフトウェア設定全部。選手用コンピュータ、コンテスト用の追加のコンピュータ、アナウンス用のコンピュータ、中継に使われるコンピュータなどの設定をします。選手用のコンピュータの物理配置や、電源配線、ネットワークなどは別の人たちに任せています。また、前に書いた通り、審判システムの設定はまた別のチームが行います。 会場設営は机、電気系統、ネットワークから始まりますが、この段階ではソフトウェア設定はできません。会場設営が進み、コンピュータと電源が配備されてからセットアップの開始です。選手用のコンピュータのインストールはテストイメージの場合と同様にできるので、やり方を指示した後は他の人に任せてあります。一方他のコンピュータ、例えば審判サーバへのプロキシやらプレゼン用のコンピュータやらのセットアップは自ら進めていきます。 ここでトラブルが二件。まず無線 LAN への接続がうまくいきませんでした。コンテスト用のネットワークは有線でやっているのですが、いくつかの会場運営用のコンピュータは無線を使おうと計画していました。テスト機ではうまくできたのに現地ではさっぱりです。$ sudo netplan –debug applyやら $ journalctl やらを繰り返した末に諦めて有線を配線してもらいました。 次に審判サーバプロキシが正しく動作しませんでした。プロキシを通して審判サーバにうまくアクセスできないのです。これは Ubuntu 22.04 の nginx が古くて最新の TLS を読めないことが原因だった模様で、 nginx オフィシャルのパッケージに差し替えて直りました。 会場の様子ですが、配線やPCのセットアップが一通り終わりました。現在、システムが正常に動作しているかを確認しています。 pic.twitter.com/78doEIFCRK — ICPC2023JP (@icpcjapan) November 24, 2023 無事モックコンテストがおこなえ、おおよそうまく行きました。一件だけ難しい問題を発見し記録。幸い本番では踏みませんでしたが次回には直します。 ホテル 自宅から横浜まで1.5時間くらいかかる上、スタッフとしてホテルが手配されているのでホテルに泊まります。一方、ちょうどトコジラミの話が Twitter で流行りだした頃なので何か対策したくなりました。 前もちょっと触れましたけど、都会のビジホは必ずいると言って良いほどいます。 海外の旅行者が持ち込んだり、都会の不衛生さが原因だとか言われてる。 海外の主要観光都市でも同じ問題が起きてるのはやはり旅行者だろうね。 https://t.co/4JH9xLQ9P1 — チカモリ (@tikamorifugeshi) November 15, 2023 旅先のトコジラミ対策は衣類用防虫剤のネオパラ一択です。2錠ずつ和紙で包んでる、あの臭いやつ。大袋で持参し、スーツケース内やベッドマット下やベッド内やクローゼット内や床の各所にバラ撒く。30か国超を旅し留学生寮や歴史的建物の年季入ったホームステイ部屋で地獄を見てきた、わたしの最適解。 https://t.co/uQqWNG1bAV — ☆せれん☆ の続き (@527_serendipity) November 16, 2023 慌ててパラジクロロベンゼンを買ったものの、そのまま撒くのは危険だと知り撒くのをやめたりしました。使用上の注意にも密閉容器でのみ使用しろとか、一部のプラスチックを侵食するとか書いてあります。 結局ゴミ袋セットを買い、リュックサックは全てバスタブ内で開封し、布を含むものは服もリュックも全てゴミ袋に収めておくことだけやっておきました。本当は自分が刺されるのもアレですが、刺されたらわかるんじゃないかと思って、リュック経由で自宅に持ち込む可能性だけ排除しました。この対応は多分あまり正しくなくて、トコジラミに刺されても最初はわからないようですね。複数回刺されるとアレルギー症状が出るとか。わからないうちに刺されて、そのまま服に隠れられると持って帰ってしまう可能性があるかも。ないのかな? 幸い私の部屋にはいなかったようで、今のところは何も異変は見つかっていません。 25日 開会式とリハーサル 8時すぎには会場に到着。前日できなかったスクリーンキャストのチェック。それからプレゼン系のチェックを行いました。前日にモックコンテストがうまくいかないとこの日の午前中もモックコンテストが入りかなり忙しくなるのですが、今年はうまくいったので仕事は少なめでした。一方、プレゼン系のチェックと作業が思ったより多く、ここで手間取りました。来年は楽になるようにチケットを切っておきました。 昼過ぎから選手が入場するため、その前に支給されたお弁当を食べます。そのあと選手のコンピュータの準備を済ませて選手を待ちます。 コンテスト中は私は選手の左斜め前、演台の下手側に座っています。前に書いた通り、ここからコンテスト用のコンピュータの監視、プレゼンの補助、それから障害対応を行います。障害対応の殆どは「コンピュータが動かなくなりました」に返事をすることです。以下のような格好で座っています。 13時あたりから選手が次々入ってきます。開会式の開始は14時なので、それまでは私は様子見です。プレゼン用コンピュータには選手用の注意事項を書いたスライドを表示し、5秒ごとにページ切り替えさせて、それを選手のディスプレイに転送しておきます。 14時開会式開始。そのあとリハーサルコンテスト。ここでは私はプレゼンの補助をしています。審判システムのデモが山場ですが、ここは別チームが担当しています。直前の体調不良でデモをやる人が交代したので大変そうでしたが、結果は好評でよかったです。 リハーサルコンテストでは選手のコンピュータの様子を監視しつつ質問に答えます。コンピュータが止まったり、テンキーが動かなかったり、ディスプレイが消えたりしました。大体はすぐ直りますが、リハーサルコンテストだと機材の入れ替えもあります。また、全然提出がないチームは様子を見にいったりします。 一件手順ミスがありました。インタラクティブ問題のツールが実行できないという報告が上がりました。ツールのビルド方法にミスがあることに気づき、再度ビルドして選手コンピュータに配り選手に通達します。 中継用のスクリーンキャストのテストもしていたのですが、そこの立ち上げも遅れました。手順を自動化しておかないと難しいですね。 プラクティスコンテスト後はチーム紹介。裏で本番の準備をして終了です。選手用コンピュータの内容も初期化し、インタラクティブ問題のツールも本番用に差し替えます。この日はここで終了し、ホテルに帰ります。 26日 コンテスト本番 6:30 に起きて 8時には到着。選手は 8:40 から入場し、コンテスト本番は 9:30 スタートです。やることはプラクティスコンテストと同じく選手対応ですが、本番なので緊張感が全く違います。案件次第では審判団に照会したり、コンテスト運営に影響することもあります。 本番まではまた注意事項を書いたスライドを選手ディスプレイに表示したり、スポンサーのCMビデオを流したりします。コンテスト開始直前にはまた選手へのプレゼンがあるのでそれの対応もします。 今年はコンテスト開幕直後に一件、ログインできないチームが出ました。すぐ解決できなかったので遠隔リブートで対応。3分のロスを後で補償することになりました。そのあともコンピュータが不安定になったチームが1チーム出ましたが、これは作ったプログラムがメモリを大量に確保していたためでした。プログラムを止めてもらって直りました。それ以外には目立ったマシントラブルはありませんでした。前日にハマっていたスクリーンキャストの立ち上げも開始から程なく行えました。後から10分くらい遅れているとの報告があり、これの対応はできませんでしたが。 コンテスト監視をしつつ問題の一般公開をしたり、合間をぬってスタッフ用お弁当を交代で食べたり、コンテスト後の問題解説用のスライドをプレゼン用のコンピュータにコピーしたりもします。 14:30 にほぼ全チームのコンテストが終了、1チームは3分のロスが出たのでロスタイムが支給されて 14:33 に全チームのコンテストが終了しました。この後はアナウンスがあったり、問題解説や結果発表のプレゼンがあったりでそれの対応をします。プレゼンが始まってしまうと選手用のコンピュータはもう選手がログインしないので、takeout ディレクトリの中身とログを集めて片付けの準備をしたりもします。その後、懇親会で選手が動いた後に全部のコンピュータの電源を遠隔で切り、片付けに入ります。片付けはインストール作業などがないので手分けして行います。今年は昨年よりも懇親会に顔を出せたのでよかったです。 27日 コンテストは終わってますが、疲れたので有給を取ります。また、テスト用のレンタル機の回収が来るので、それを返して私のコンテストは終了です。 感想 準備の量がかなり多いです。今回は基本システムの Ubuntu 22.04 へのアップデートがあったのでその分が多いのですが、それ以上にスクリーンキャスト対応がきつかったです。これを実現可能にしたくてこの仕事をやっている面もあるのでやっているのですが。まだ変更しなければいけないところが多く厳しいのですが、安定したらもうすこし準備が少なくなるのではないかと期待しています。スクリーンキャスト対応については別途記事を書きたいです。 本番のマシントラブルは昨年度と比べてかなり減りました。昨年度はよくわからない強制ログアウトやら画面ブラックアウトが数件ありましたが、今年は1チームロスタイム支給の他はマシントラブルはほぼありませんでした。このあたりは準備の成果もあると思っています。 完全に余談ですが、Twitter アイコンをバッジにして懇親会に持っていったらちょっと話しやすかったです。 昨年の ICPC で、自分の Twitter アイコンを大きな名札にして首から下げてた参加者がいて、懇親会でかなりわかりやすかったので私も今年それやろうかなと思っている。参加者ではないけど。 — Yu SUGAWARA (@gusmachine) November 22, 2023 これをやってた審判団もいたのが印象に残っています。

上の子の経験に基づいて「子供は3歳くらいまで抱っこをせがむのでそのあたりが一番重くて大変で、4–5歳になると抱っこがなくなる」と話したら、別の人が「うちの下の子は5歳でもずっと抱っこと言っていて大変だ」と言っていた。これを個人差と捉えていたんだけど、実は環境の問題で、下の子のほうが一般的に抱っこ要求が長引くのではないかと気づいた。 理由として、下の子の方が年齢の割に長い距離を歩かされることが多いと想像される。例えば、子供が5歳と3歳のときに家族の外出で歩く距離と、子供が7歳,5歳のときの距離を比べると後者のほうが長そう。なので、外出時に前者の5歳は疲れなくても後者の5歳は疲れ、後者の子だけ抱っこと言いそうな気がする。 もしこの推測が正しいとすると、うちも下の子の抱っこは長引く可能性がある。下の子は4歳になったばかりだが、この子もひょっとすると5歳くらいまで抱っこを要求するかもしれない。 とはいえ今のところ、うちの下の子は疲れて抱っこはあんまり多くないかもしれない。むしろ寝てしまう。抱っこがさらに大変だが。 追記: こんなことを書いていたら、親が私達三兄弟の疲れたときの挙動の違いを話してくれたことを思い出した。 文句を言わずに歩くので転んでしまう子 文句を言う子 「おっとっと」「おっとっと」と歩けないことをアピールし始める子 とかだったか。 追記2: これを書いて1ヶ月くらい寝かせていたのだが、その間に、「妻の抱っこ中に下の子が激怒して妻の顔をギタギタにひっかく事件」が発生した。もう安全に抱っこできる年齢じゃなくなったかもしれない。

結論 類似した記事にしたがって、Make のシナリオを書きました。 モチベーション 子供が大きくなると子供の予定も複雑になります。今日はプール道具を持っていくとか、今日は体操服を着て幼稚園に行くとか。あるいは早めに迎えに行くとか。今までは Google Calendar で共有イベントを作って管理していました。 今は母と同居していて、母にもいくつかの予定は共有したいです。母にも Google Calendar を見てもらいたいので、共有カレンダーを作成しました。ただ、毎回見てもらえるかとか不安があるので、ついでに Slack に予定を自動で流せないかと調べてみました。 Slack アプリは使えない 結論から言うと、Slack で Google Calendar の共有カレンダーの予定を特定のポストに流すのは、現在 Slack アプリ単体ではできません。Google Calendar for Team Events という Slack アプリが現在サポートが止まっていて、新規にインストールできません。 https://slack.com/intl/ja-jp/help/articles/360047938054-Slack-%E5%90%91%E3%81%91-Google-Calendar-for-Team-Events Google Calendar for Team Events は廃止される予定です。 現時点では、廃止は更なる通知があるまで一時的に停止されています。最終的な廃止日がわかり次第、詳細をお知らせします。Google Calendar for Team Events との既存のインテグレーションはこれまでどおりに機能しますが、ワークスペースにこのアプリをインストールしたり、設定を新規作成したりすることはできません。 実際、使っている人でも、挙動がすでにおかしいと言っていたりします。 https://zenn.dev/readyfor_blog/articles/e1e55a8f9d1d8e 2023年1月の2週目あたりから、急にSlackへ通知されなくなってしまいました。 上の slack.com のページには代わりに Google Calendar Slack アプリを使えと書いてあるのですが、こいつは私の要求通りには動いてくれません。 共有カレンダーが使うカレンダーリストに出てこない。 特定のチャンネルに post したりしてくれない。 Google Calendar から Slack に情報を流す方法を探す 別の方法を探しました。[google calendar for team events alternative] と検索しました。 https://zenn.dev/readyfor_blog/articles/e1e55a8f9d1d8e Make を使う https://azospiran.hatenablog.jp/entry/2023/04/06/120816 IFTTT を使う https://www.reddit.com/r/Slack/comments/ya9nm0/google_calendar_for_team_events_alternatives_with/ 開発者コンソールを使うとまだ当該アプリを入れられるよ。おいおい。 上に書いた通り、すでに動作が怪しいのでこの解決策は採用できません。 IFTTT か Make、あるいははじめの記事で参照されている Zapier あたりを試すのが良さそうです。自前で GAS を書いてもいいのですが、Google authentication と Slack authentication を管理するのが面倒そうだなと思いやめました。 Make を使ってみる 先例に習って Make を使ってみることにしました。 まず探したところ Make のこのテンプレートの説明がそのままだったんですが、想像していた挙動と違いました。こいつは Google Calendar を Watch Event するので、新たに作られたイベントが明日のものの場合、それを Slack に通知する、という挙動になります。明日のイベントを昨日以前に作っていた場合、なんの通知もありません。期待した挙動ではありませんでした。しばらく工夫していましたが、望んだ挙動にはなりませんでした。 結局自前でフローを描きました。だいたい以下のようなことを書きました。 - Google Calendar Search Events: - Start Date: {{now}} - Order By: Start Time (ascending) - Singel Events: Yes (たぶん...) - Filter: {{1.start}} less than {{setHour(addHours(now; 24); 23)}} - Slack: Create a Message - Text: {{formatDate(1.start; "M月D日"; "Asia/Tokyo")}} の予定です: {{1.Summary}} ({{formatDate(1.start; "HH:mm"; "Asia/Tokyo")}} - {{formatDate(1.end; "HH:mm"; "Asia/Tokyo")}}): {{1.Description}} これを毎日20:30 に流します。以下のようなメッセージが「予定」チャンネルに流れます。下のものはテストなので別の日付の予定が一緒に流れていますが、本来は一日分の予定が流れます。 よかったところ: 最終的にちゃんと動きました。 「全体をテストする」ボタンがあるので、テストができます。 よくなかったところ: 上にある通り、見つけたテンプレートの説明と挙動が全然違いました。さんざん試した挙句、結局いちから書き直しました。 「このモジュールだけテストする」ボタンは後段のイベントにはうまく動きません。Google Calendar Search events だけテストする、は動いています。しかし、その後の Slack: Create a Message を続けてテストしても、直前のカレンダーの実行結果は入っていないので、空のメッセージが出力されます。 Text format の UI がなにか変です。次に書きます。 Make の Text format UI が良くない Text format の UI がひどく悪くてイライラしました。カレンダーの時間をそのまま出力すると “2023-07-16T02:00:00.000Z” のように人間向きでない表記が出てきます。そのため上記の通り formatDate をタイムゾーン付きで呼ぶ必要があります。しかし 関数や変数は選択パレットから選ぶ必要があります。そうしないと単なる文字列として解釈されます。しかし、選択パレットから目的の関数/変数をマウスでクリックするたびに、それをおくべきテキストのカーソルが一番初めの位置に戻ります。そのまま配置しようとすると関数が行頭に置かれてしまします。さらに関数や変数はカットペーストやドラッグドロップで移動ができないので、間違って配置されたものは消して配置し直すしかありません。 チュートリアルを見たのですが、まず挙動が私のものと全然違って首を傾げます。 formatDate 関数はタイムゾーン付きのものを呼びたいのに、関数パレットから選択されるのはタイムゾーンなしの2引数のものしかありません。そして引数区切りの";" の入力方法がわかりません。結局 formatDate をもう一つ配置してそこから “;” だけ取ってきました。 Text Format を完全にキーボードで手書きできれば良さそうですが、その方法が簡単には見つかりませんでした。 終わりに Google Calendar の共有カレンダーにある予定を Slack の「予定」チャンネルに一日一度流すために、 Make.com を導入しました。期待通りの設定ができましたが、 Make.com の UI が難しくて設定に少し手間取りました。

ふと見たら私物ラップトップ (DELL XPS 9370) のキーボードがめちゃくちゃ歪んでいました。写真に撮っても気づかないレベルですが、触ると出っ張っていて驚きます。キーボードの下に配置されているバッテリーが膨れているのでしょう。緊急事態なので DELL 公式サイトで対処法を調べました。 バッテリーに関する文書 膨張したバッテリーは交換しろ。はい 互換バッテリーは火災を起こしたり等の危険がある。はい 純正バッテリーは売っていますか? DELL オンラインストアにはありません。うむむ。 公式の交換方法 によると、トルクスネジのドライバーが必要です。iFixitでも同等の説明を確認しました。 ぐっと睨んで、結局 Amazon でトルクスドライバーセットと互換バッテリーを買ってしまいました。8000円程度。

Hugo のテーマとして Hermit を使っていました。しかしこれは最終コミットが2020年6月であり、Hugo 0.71.1 の頃のものです。現行は0.110.0 なのでなかなかまずいです。 ところで News には一年以上前の 0.91.2 の情報までしかないんですが大丈夫ですか..? 昨年から気づいていたのですが、面倒で更新をサボってました。 通常の CMS? だとそれでもいいんだろうけど、 Hugo の場合はまだメジャーバージョンが 0 なので破壊的変更がありうるので心配。ちなみにバージョンは 0.71.1 から 0.89.4 まであがっている。 — Yu SUGAWARA (@gusmachine) May 5, 2022 重い腰を上げてテーマの乗り換えをすることにしました。Hugo Themes | blog で上から探します。条件は以下を考えました。 GitHub Stars が300以上ある。 デモがある。 モバイル版でちゃんと見える。 Lighthouse でのパフォーマンスが悪くない。 謎の js,css をロードしていない。 たくさんの web font をロードしていない。どうせ日本語で書くのでフォントは適用されないことが多いので。 Google Analytics 対応。手で入れてもいいけど。 以下のテーマを見ました。 academic : とっても有名。ただ Netlify しない場合の導入方法がよくわからないのと、Netlify は日本から遠いサーバしか居なかった記憶があるので嫌。 clarity: woff2 多い。 bear blog: むしろ何もないやつ. Google Analytics と image support くらいは欲しい。 papermod: これも何もない系。でも機能はある。よく見る価値はある。 hello friend: vercel が遠くてLCP/FID が遅い. あと謎のフォントが多い hello friend ng: デモがない。 jane: 何故か Google Tag Manager 由来でFIDが高い。これ async load されているみたいだから FID に影響を与えているのがよくわからない。 まず、デモのサーバが遠かったり、機能を加えているために遅かったりするのもあって上の条件があまり合理的じゃないことがわかりました。仕方ないです。かわりに適宜 Chrome のネットワークタブと HTML を眺めて適切なものを選びました。 今回は papermod を入れてみることにしました。軽い割に必要な機能はありそうです。 Star もたくさんついています。正しい道は academic をもっと調べることかもしれませんが。 やることはかなり面倒でした。 git submodule add でテンプレートを入れる。 サイトのテンプレートと出力結果を見ながら config.yaml を書き換える。 昔必要だった shortcodes やハックを消す。 GA4テンプレートとか、特殊なイメージ用タグとかを消しました。 RSS が出てそうか確認。 直前の記事が RSS で途中までしか出てなかったことを発見しました。 more tag 中にスペースが入っていました。 hugo で出力した後、URLなどが変わっていないか確認。 デプロイ firebase deployで Failed to get Firebase projectというエラー Analytics が動いていることを確認。

Debian Bookworm(testing) をインストールしたラップトップから obs を起動しても何も起きない。コマンドラインから起動すると以下のエラーが出る。 $ obs Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. zsh: IOT instruction obs 「obs qt_qpa_platform wayland」で検索。バグ報告を発見。 I encountered the same error but was able to start OBS after installing the qtwayland5 package. qtwayland5 をインストールしたら解決したとのこと。 $ sudo apt install qtwayland5 $ obs 動いた。 ちなみに qt6-wayland もあるけど開発状況はどんなんだろう、と調べたところこの通り。次のバージョンで移行するそう。 Plan to Upgrade OBS Studio to Qt 6 · Discussion #6481

Ubuntu 20.04 でディスプレイマネージャを gdm3 から lightdm に切り替えた場合、ユーザの初回ログイン時に “Screen Lock disabled” “Screen Locking requires the GNOME display manager.” という警告が出てきます。これの止め方の解説をします。 前回の、 Ubuntu 20.04 でディスプレイマネージャを lightdm にしたインストーライメージを作るからの続きです。 個人で使う場合は警告は気になりませんが、多数の人に使わせる場合は「この警告を無視してください」といちいち解説するよりは消したほうが良いこともあります。 ちなみに後で解説しますが、スクリーンロックをできるようにしてもこの警告は出ます。 解答 /etc/skel/.local/share/gnome-shell/lock-warning-shown というファイルを作ると、出てこなくなります。 上記の警告は各ユーザの初回ログイン時にのみでます。それを実現するため、警告が出たのちに ~/.local/share/gnome-shell/lock-warning-shown というファイルをつくっています。 そのため、あらかじめこのファイルを作っていれば警告が出なくなります。 警告コードは gnome-shell のこの辺りです。 上にファイル名が見えます。 この挙動はバージョンが変わると動作しなくなると思うので、それはご了承ください。 誤答 スクリーンロックソフトウェアを導入 gdm3 は自前でスクリーンをロックできます。lightdm はどうかというと、 screen lock 機能が消されています。(参考:canonical stackoverflow) そのため、他のソフトウェアを導入することになります。 Lock screen after switching from GDM to LightDM - Perfacilis のようなサイトを巡って適当に導入したのですが、上の警告は消えません。 警告のコードを見てみれば分かると思いますが、canLock関数が DisplayManager のことしか見てなさそうなのでこの方向では警告は消えないと思います。

Ubuntu 20.04 の標準のディスプレイマネージャーは gdm3 です。これを lightdm に変えたインストールイメージの作り方を解説します。 前回の、 Ubuntu 20.04 をオフラインでセットアップできるイメージからの続きです。 通常 lightdm をインストールすると、ユーザ向けのダイアログが開いてディスプレイマネージャを選択することになります。ユーザの操作なしに lightdm を選択するには少し工夫が必要でした。 Twitterスレ の清書になります。 Ubuntu 初期設定スクリプト(autoinstall)で gdm3 から lightdm に切り替えようとしている。https://t.co/jX72M8CzWw dpkg-reconfigure で変わるのを確認したので、これを非対話的にやりたい。https://t.co/rI4kugy1Y6 を見つけたがどの方法もうまくいかなかった。 — Yu SUGAWARA (@gusmachine) April 10, 2022 背景 ICPC アジア予選横浜大会で選手が使うコンピュータには Ubuntu がインストールされていて、ディスプレイマネージャは lightdm を使っています。 これには理由があり、今のところ gdm3 に移行できません。 一番良さそうな解法 これが最も簡単でした。 gdm3 をアンインストール, lightdm をインストールし、必要に応じて dpkg-reconfigure lightdm を実行する。 Step1. gdm3 をアンインストールする。 ubuntu-desktop は消しても良い ubuntu-desktop や ubuntu-desktop-minimal をインストールすると gdm3 がインストールされるため、大体の環境で gdm3 がインストールされていると思います。 ここから gdm3 を % apt-get uninstall すると、ubuntu-desktop も道連れでアンインストールされます。実態のないメタパッケージなので、消しても問題はありません。 Step2: lightdm を正しく設定する gdm3 をアンインストールしたのち lightdm をインストールすれば、起動時に lightdm が動くよう設定されます。 あるいは lightdm をインストールしたのち gdm3 をアンインストールした場合、その後に % dpkg-reconfigure lightdm で lightdm を設定し直せば大丈夫です。 ハズレ解法 以下、罠にかかった順番に解説します ハズレ1 lightdm をそのままインストールする。 単純に lightdm をインストールした場合、上に書いた通りユーザ向けの設定ダイアログが開いてディスプレイマネージャを選択することになります。 ユーザの操作ができない autoinstall の最中、gdm3 がインストールされた環境上に lightdm インストールした場合、そのまま gdm3 が選ばれることになります。 ハズレ2 lightdm をインストールしたのち、 gdm3 をアンインストールする % apt-get install lightdm したのち % apt-get remove gdm3 すると、ディスプレイマネージャが選択されていない状態になり、テキストログイン環境になります。 うえの正解の通り % dpkg-reconfigure lightdm を叩けば大丈夫です。 この作業をしていたときはそれに気づかず、テキストログイン環境になったのは ubuntu-desktop が削除されたためではないかと考えたため、正解にすぐたどり着けませんでした。 ハズレ3 lightdm をインストールしたのち、 dpkg-reconfigure lightdm を行う ちょっと調べたところ、Lubuntu 20.10 の安定のため「lightdm」と「xfce4-screensaver」に入替え〈H105〉 - Linux あれこれ に、 dpkg-reconfigure の話が載っていました。実際、% dpkg-reconfigure lightdm を叩くと設定ダイアログが開き、ディスプレイマネージャが選択できます。 しかしユーザ操作ができない環境中では gdm3 がそのまま選ばれます。 「dpkg-reconfigure auto answer」 とかで頑張って検索して Feeding input values to dpkg-reconfigure in a non-interactive way が出てきたものの、以下の方法ではうまくいきませんでした。 DEBCONF_DB_OVERRIDE を利用した方法 $ cat /path/to/config.dat Name: shared/default-x-display-manager Template: shared/default-x-display-manager Value: lightdm Owners: gdm3, lightdm Flags: seen Variables: choices = gdm3, lightdm % DEBCONF_DB_OVERRIDE='File {/path/to/config.dat}' dpkg-reconfigure -fnoninteractive lightdm debconf-set-selections を利用した方法もだめでした。 % echo 'lightdm shared/default-x-display-manager select lightdm' | debconf-set-selections -v 後から考えると、これは例の firebird ではうまくいくかもしれないですが lightdm ではうまく行かなそうです。 あたり1 lightdm をインストールしたのち、/etc/X11/default-display-manager を書き換えてから dpkg-reconfigure lightdm をする Reconfigure the display-manager non-interactively にあることをやったら通りました。 関連コードはここのようです。 https://github.com/canonical/lightdm/blob/170df31f7d9c00b049bdd158682472df915adeae/debian/lightdm.postinst#L15 しばらくこの方法を採用していたのですが、後に gdm3 を消して良いことがわかったので、正解の方法に変えました。 次回予告 lightdm を設定すると、ユーザの初回ログイン時に警告が出てきます。 今度は "Screen Lock disabled" "Screen Locking requires the GNOME display manager." が出てきたぞ。 screen lock ができないことよりこの alert が出てくる方が困るな。 — Yu SUGAWARA (@gusmachine) April 10, 2022 次回はこの警告の抑止方法をまとめました。

2022-07-24 追記 最後の実際のコードで、イメージを /target/cdrom 以下に mount する際、実際のデバイスを mount する代わりに mount --bind でパスを複製することにしました。 このほうが簡単ですし、デバイスを二回 mount するのは動かない場合があるためです。 主題 Ubuntu 20.04 をオフラインでセットアップできるイメージを作りました。 必要なパッケージ(ソフトウェア)はイメージを作る際に指定することで、イメージの中に取り込み、セットアップの際に自動でインストールされます。 ICPC アジア予選横浜大会で使用するイメージはこの形式をもとにしています。 Ubuntu 18.04 までの方法が使えなくなったので、代わりの方法を調べました。 背景 Ubuntuのインストールメディアにはパッケージはあまり付属していなくて、セットアップの際に必要に応じて追加パッケージをインターネットからダウンロードしてインストールする仕組みになっています。 インターネットに繋がっていないコンピュータに Ubuntu をインストールする場合はこれでは困ります。 ICPC アジア予選横浜大会 では選手が使うコンピュータを大会で提供しています。 会場のコンピュータはインターネットには繋がっていないので、オフラインでセットアップできるUbuntuのインストールメディアを作って使用しています。 Ubuntu 18.04 までは Community Help Wiki: InstallCDCustomization の記述に従って、追加パッケージを含んだ extras コンポーネントをイメージ内の apt archive に作り、 kickseed で自動インストールスクリプトを与えていました。 kickseed でパッケージを指定すると、追加した extras コンポーネントからもちゃんとパッケージをインストールできました。 Ubuntu 20.04 では Ubuntu Server で Debian Installer が廃止され、代わりに Subiquity というインストーラーが提供されるようになりました。 Subiquity 上で自動セットアップスクリプトを書く autoinstall が提供されるようになったので、スクリプトとイメージの書き方をこれに移行することになりました。 要求仕様 以下のような Ubuntu インストーライメージを作成します。 指定したパッケージがインストールされる。 インターネットのない環境でも動作する。 インターネットのある環境でも動作する。 最後のものは追加仕様です。コンテストに参加する選手向けに、作成したイメージを配布しています。その際インストールに手間取らないよう、インターネットがない環境とある環境両方で動くことを確認します。 autoinstall の基本 説明は他のドキュメントに譲ります。公式ドキュメントはチュートリアルを含め読みやすいですが、説明外のことをしたいときに何もわからないと思います。 Qiita の記事にはとてもお世話になりました。 Automated Server Installs | Ubuntu Ubuntu 20.04をAutoInstallで自動インストールしてみた - Qiita 正解 私が知る限りの正解は2通りです。 正解1 イメージにapt archive を配置し、 late-commands でそれを使うよう設定する イメージの中の適当なディレクトリに apt archive を作成し、late-commands の中でそれを /target/ から読めるようにします。その後 /etc/apt/sources.list を書き換えてそれを指定します。 これを採用しました。我々はイメージに /extra/pool/ ディレクトリを作り、そこに必要な *.deb パッケージを置き、 /extra/dists/focal/main/binary-amd64/ あたりに apt ftparchive を作成しました。その後、late-commands で以下のことを行いました。 /target/cdrom にイメージを再マウント。最後に説明。 echo ‘deb file:///cdrom/extra/ focal main’ > /etc/apt/sources.list apt-get update apt-get install $packages とりあえず動きます。難点として、user-data での指定が全然できないことが挙げられます。 late-commands でなんでもできるので、それをしているだけになります。 正解2 filesystem.squashfs の中に apt archive を配置し、 user-data ファイルの apt 節で指定 filesystem.squashfs の中に apt archive を作成し、それを参照します。 この場合 path が読めるのでそのまま user-data で apt.primary.uri: file:///path-to-archive/ の指定ができます。追加で packages 節でインストールするパッケージを選べると思います。 インストール先ディスクに数 GB がりがり書き込むことになるため避けました。しかし user-data で指定ができることを考えるとアリかも知れません。 不正解1 イメージに apt archive を配置し、user-data ファイルの apt 節で設定 イメージの中の適当なディレクトリに apt archive を作成し、user-data で apt.primary.uri: file:///cdrom/extra/ などと指定します。late-commands で /target/cdrom/ 以下に配置。 これをした場合、インターネットがある環境でのインストールに失敗します。インターネットが存在する場合、 apt-get update が late-commands 以前に走り、そのタイミングで上の file://cdrom/extra/ が読めずにエラーを吐きます。 インターネットがない環境でのインストールは成功します。 微かに正解 イメージに存在する apt archive に追加コンポーネントを配置 イメージの中に存在する apt archive に追加コンポーネントを作成します。上の 18.04 までの方法です。この場合以下の二つに分けられます 不正解 user-data ファイルの apt 節で指定 user-data で apt.primary.uri: file:///cdrom/ などと指定。 この場合、不正解1と同様にインターネットがある環境でのインストールに失敗すると思います。 さらに、 user-data で apt を指定する場合、任意に追加したコンポーネントを読むように指定できません。 autoinstall の user-data での apt の記述でできることは、disable_components を指定してコンポーネントを除外することだけです。任意のコンポーネントを追加できません。 正解 late-commands で指定 late-commands で /target/cdrom/ にイメージを mount して、 /etc/apt/sources.list を書き換え。 正解1とほぼ同様で、イメージに初めから配置されている archive を利用できるようになります。しかし配置されている archive がそんなに多くないのでこの道を通ることはやめました。 よくある質問 もう Ubuntu 22.04 が出ますよ。 Ubuntu 20.04 の情報は古くないですか? 古いです。 方針として Ubuntu LTS リリースをリリースから1年経ってから使うことにしています。以前リリース直後のものを使ったところネットワークドライバ周りのバグでトラブルが起きたことがあるので。 この作業は 2021 年に行う予定でしたが、 2021 年の ICPC アジア予選横浜大会はオンラインで行うことになったためインストールイメージの作業は中断されました。 つまり 22.04 への移行は来年にやります。 手作業でやるの大変じゃないですか 大変です。今回も d-i から autoinstall に書き換えるのに数ヶ月分の週末を使いました。必要なことはそんなに多くないので、何か他の方法をご存知の方がいたら教えていただけると助かります。 とはいえ、毎回トラブルを起こす箇所が異なるので、ここだけが完璧に直ったところで他で苦労しそうです。今までは例えば以下のようなところで詰まっていました。 upstart が systemd になる デフォルトの WM/DM が変わる ネットワーク管理方法が変わる 全然違う方法で似たようなことをしています ぜひやり方を知りたいです。 実際のコード user-data # (apt line なし) late-commands: - mkdir /target/cdrom - mount --bind /cdrom /target/cdrom - curtin in-target –target=/target – bash /cdrom/late-commands.sh - umount /target/cdrom late-commands.sh #/bin/bash set -eux echo 'deb file:///cdrom/extra/ focal main' > /etc/apt/sources.list apt-get update apt-get -y install $(cat /cdrom/packages | sed '/^[#]/d;/^ *$/d') # (以降設定が続く)