Stonking(Ubuntu 26.10)の開発; 閉域網向けのSnap Store, Ubuntu Server向けドキュメントでのAI利用方針
SnapはUbuntuの特徴的な仕組みの一つで、あるパッケージに含まれるライブラリを含めてひとまとめにし、通常の.deb形式のパッケージでは管理に向かないソフトウェアを管理するためのものです。
Snapにはこれ以外に「そのパッケージの動作の範囲」を厳格に指定することで、セキュリティ的な懸念を最小化する、という仕組みもあります。
厳密な制約がもたらす「不自由さ」に賛否両論あるとはいえ、Webブラウザーのような大量の依存関係を持ち、なおかつ攻撃の起点になりうるようなソフトウェアを長期的にメンテナンスする[1] 上では現実的な解と言えるでしょう。
一方、「 通常のパッケージ」とは異なる形で配布されることから、異なる管理や配布方式が必要になる、という制約もあります。この制約は特に、企業や大組織で利用する場合に問題になります。企業や大組織が備える回線は限定的であり、インターネットから同じバイナリを繰り返しダウンロードすることで、自主的な疑似DDoSに相当する負荷を自組織の回線に与えてしまう可能性があるからです。
Snapにはこの問題が存在しており、「 Snap Storeの帯域が限定的である」「 プロクシー等で簡単にキャッシュできない」「 隔離環境(インターネット接続性のない環境)では利用しにくい」という制約が発生していました。
この問題を解決するソリューションとして、『Enterprise Store』 という専用のソフトウェア群が発表されています。Ubuntu Proの付帯サービスとして利用可能な形で、「 自社独自のストア」を作ることができます。キャッシュ・隔離環境での利用(他の環境でパッケージを登録する)などといった構成もサポートされています。HA構成も可能 で、「 企業でUbuntuを大々的に使う」環境の場合は利用を検討すると良さそうです。
[1] Ubuntu Weekly Recipe 第596回 も参照してください。Webブラウザーの多くは大量のライブラリに依存しています。そしてその「最新版」は最新のライブラリに依存することがほとんどです。ライブラリはバージョンによってはAPIに互換性がないため、Webブラウザーの「最新版」を導入するには最新のライブラリ環境が必要ということは珍しくありません。Ubuntuは現状、LTSにおいては15年のあいだソフトウェアをメンテナンスする必要があり、OSが持つライブラリが古くなってしまう可能性を無視できません。各種ライブラリをパッケージに同梱することで、「 OS側の古いライブラリにあわせてWebブラウザーのコードを書き直す」という不毛な問題を避けることができます。
Ubuntu Server関連のドキュメントの整理と、現時点におけるAIの導入についての方針 が提示されています。
以前の状況とは異なり、『 今日の状況では、「 あらゆる貢献を歓迎します」と言う前に、真に価値のある貢献の精神を守るためのガードレールを設ける必要があります』( 「 Saying “ we welcome all contributions” in today’s landscape is a position that needs some guardrails added to protect the spirit of true, valuable contribution.」 )という形で具体的な「ガードレール」が提供されるようになりました。
Ubuntu Serverのドキュメントにおいては、『 あくまで補助的なものとして使用し、人間に取って代わるものではないことを期待しています 。許容される使用例としては、以下のようなものがあります』( as a helper, and not as something that replaces them. Some examples of acceptable usage include:)ということで、具体的な例が示されています。
AIをスペルチェックや文法チェックツールとして活用する(Using AI as a spellchecker or grammar helper)
英語への翻訳に役立てるために使用する(Using it to help with translation into English)
下書きの構成と整理に役立てる(Using it to help outline and organize a draft)
敵対的に利用して、欠落部分を指摘する(Using it adversarially, to point out missing sections)
書式がスタイルガイドに準拠していることを確認する(Ensuring formatting adheres to our style guide)
また、「 AIアシスト」を利用した場合にはプルリクエストの説明欄に、使用した旨と使用方法を明記する必要があること、そして“ good first issues” “ Open Documentation Academy” タグの付与されたもの(これらは新しい貢献者向けに「意図的に設計された」課題です)は対象としないこと、といったアプローチが特徴的です。これらを補助するためのAI用アーティファクト (AGENTS.mdやツールごとのプロンプト例)が提示されています。
その他のニュース
kernel 7.0.0-28.28において、amdgpuの性能が極端に劣化する という問題が報告されています(最大で42倍ほど の劣化) 。ROCmベースのワークロードを実行している場合は更新を見送り、より新しいバージョンがリリースされるまで待つことをお勧めします。
stonkingの「設定」において、Ubuntu Certifiedかどうかを確認できるようになった というOMG Ubuntuの記事。「 単にUbuntuがプリインストールされている」と「Ubuntu Certifiedである」の区別が付くようになります。
Cephのノードで、systemdが70GBほどのメモリ消費を発生させていた、という事案のトラブルシューティング事例 。sos-reportには手がかりはなかったものの、systemdのコアダンプには大量のマウントテーブルのエントリが含まれており、なぜそんなことが起きたのかというとceph-volumeが起動のたびにクラッシュして再起動されており、その結果としてsystemdが肥大化していた、というものでした。自分でこうした問題を解決できないと感じた場合は有償サポートを、という形ではありますが、「 こうしたことが起きうる」ということを覚えておくと良さそうです。
26.04 LTSにおける、アップデート通知が届かなくなる 展開について。「 unattended-upgradeを無効にしてしまうと、自動アップデートが行われない、そしてユーザーへの通知も行われないのでアップデートする切っ掛けが失われる」( ので、もし無効にしたい場合はアップデートパッケージの存在を通知するgsettingsを適切に設定しなおす必要がある)というもので、unattended-upgradeを無効にしている場合は注意したほうがよいでしょう。
26.04 LTSでは「wall」による全ターミナルユーザー向け通知が壊れているというblog記事 。
注目すべきセキュリティー的な視点: NTPと時刻同期
システムのセキュリティ、特にCIAのうちIntegrityを保つためには、時刻はきわめて重要です。
システムのログ、特に分散したサーバー環境におけるログの妥当性は時刻によって保証されています。
サーバーの時刻が正しくなければ、ログに記録された発生したイベントの順序性は全く信用できなくなりますし、その環境においてはトラブルシューティングが成立しなくなることすらあります。極端な例としては「決済が完了するまでに商品が出荷されている」といった、一見すると完全に破綻した処理が起きているかのようなログが残されてしまうこともあります(処理そのものは破綻しないように設計されていることが期待されますが、時には処理が破綻することもあるかもしれません) 。
そして、「 あるサーバーの時刻が問題が起きていたタイミングにおいても適切に同期されていたか」ということを確実に保証できるように設計・構成されたシステムばかりではありません。時刻ずれを自主的に認識して停止するように構成されているサーバーはそれほど多くないからです。
また、時刻の正しさに強く依存するプロトコルの一つにKerberos認証があります。Kerberosは認証のための「チケット」と呼ばれるクレデンシャルに時刻を刻んでおき、時刻に基づいてその妥当性を管理することで攻撃難易度を確保している側面があり、キーを管理するKey Distribution Centerと各種システムが同じ時刻を刻んでいる必要があります(そしてこれは、Active Directory環境においてDCに時刻が同期しなければいけない理由でもあります) 。TLSなどのセキュアプロトコルも時刻が正しくなければ接続を確立できません。
こうした「重要な」時刻を保証するのがNTPdです。
NTPdプロセスの最大のポイントは、いわゆるWell-Known Portで待ち受ける必要があるということと、さらにシステムのRTCを更新する必然性があるゆえに、ルート特権で動作しないといけないことが前提になることです。これゆえに、NTPdに対する攻撃というシナリオがそれなりに現実的に存在します。これそのものは強制アクセス制御によって十分に回避できるものの、システム管理者にとって悩みのタネになることは間違いありません。APは枯れた技術であるので、多くの脆弱性が発見されるわけではないものの、C言語で実装されている以上、何らかの問題、あるいは何らかの問題と疑われる要素が発見されることは、そこまで珍しいことではありません。
ntpd-rsへの乗り換えはこうした背景により、「 モダンな」実装に切り替える動機が存在することによります(開発者の趣味、という側面がまったくないとは言えないものの、十分に正当化できる範囲でしょう) 。
また、デーモンとしてのNTPdだけでなく、NTPというプロトコルの側にも「軽んじられてきた」側面があります。時刻はシステムの運用上きわめて重要になる一方、NTS(NTPsec)があまり流行っておらず、平文通信に依存していたり、おまけにUDPであったりと、「 忘れられている」プロトコルでもあります。
しかし、適切な時刻がシステムに設定されていることは、ログの観察上極めて重要です。この一方、NTPではミリ秒単位のズレを完全に防ぐことはできません(NTPに適切に同期していないポストをすぐにシャットダウンして良いといった環境であればともかく、現実的にはそうではないことが多いでしょう) 。通常そこまで大きな問題がないとはいえ、「 完全に整合している時刻」を手に入れるためには、それなりの投資が必要です。
NTPによって時刻を同期させる以外の方法も、「 一応」存在します。インターネット接続性なしにNTPを実現するには、GPS信号を受け取ったり、あるいは原子時計ベースのハードウェアを準備してそれらをNTPサーバーとして実装する必要があります。一方これらは高価であったり、GPS信号を受け取るために窓にアンテナを配置したりといった必要性があり、データセンターのような場所で利用するにはなかなかに厳しさがあります(もしくは、データセンター単位で提供するNTPサーバーをGPSベースで確立して、「 データセンター単位にNTPサーバーを配置する」という力技のソリューションが必要です) 。
ワンチップ原子時計と呼ばれるソリューションは、サーバーハードウェア上に搭載できる原子時計で、常に正しい時刻を提供します。問題点はコストで、PCIeに実装されたカードスタイルのもので2000~3000USDほどします。気軽にEthernetアダプターさえ存在すれば動作するNTPのたぐいと比べると「だいぶ高い」ものになります。サーバー業界的にはクリスタルで実装された時計の精度問題を解決するためにずっと模索されている領域なのですが、2026年現在、画期的な解決は見られていません。
当分のあいだは、分散システムなので時刻がきわめて重要、といった特殊な文脈が存在しないかぎり、セキュリティの一要素としてNTPと向き合うことが続くでしょう。……あなたの管理するシステムでは、時刻同期のステータスを適切に監視しているでしょうか?