運用・保守 on KnightLiブログ

2026年の Linux サーバー向けディストリビューション選び：Debian、Rocky Linux、AlmaLinux、Ubuntu Server 比較

Thu, 07 May 2026 21:03:12 +0800

2026年に Linux サーバー向けディストリビューションを選ぶとき、重要なのは「どれが一番良いか」ではなく、「どれが自分たちの運用モデルに合うか」です。

最も安定したコミュニティディストリビューションが必要なら、Debian は今でも有力な第一候補です。RHEL 互換エコシステムが必要だが RHEL を直接購入したくない場合、Rocky Linux と AlmaLinux は CentOS 後の自然な代替です。クラウドイメージ、ドキュメント、素早いデプロイ、新しめのパッケージを重視するなら、Ubuntu Server が今でも最も楽です。

以下では、サーバー用途の実務目線で比較します。

早見表

ディストリビューション	最適な用途	主な利点	注意点
Debian	長期安定、自ホスト、基礎サービス	安定、簡潔、強いコミュニティ、自由ソフトウェアの伝統	標準パッケージは保守的。企業向け商用サポートは RHEL/Ubuntu ほど明確ではない
Rocky Linux	RHEL 互換の本番環境	RHEL に近い運用習慣。CentOS からの企業移行に向く	パッケージ更新は保守的。デスクトップや新技術体験は主目的ではない
AlmaLinux	RHEL 互換本番環境、クラウド、企業向け代替	RHEL 互換、活発なコミュニティ、明確なライフサイクル	RHEL と少し差異があるため release notes の確認が必要
Ubuntu Server	クラウドサーバー、コンテナ、開発デプロイ	クラウド対応が強い、資料が多い、デプロイが速い、LTS が長い	Snap、HWE カーネル、PPA はチーム内ルールが必要

一言で言うと次の通りです。

最も無難な汎用選択：Debian。
企業向け RHEL エコシステム代替：Rocky Linux / AlmaLinux。
クラウドと開発効率優先：Ubuntu Server。

Debian：岩のような安定性

2026年5月時点で、Debian の current stable は Debian 13 trixie です。Debian 12 bookworm は oldstable に移行しており、セキュリティと LTS サポートはありますが、新規サーバー導入では Debian 13 を優先して検討するのがよいでしょう。

Debian の特徴は一貫しています。

標準パッケージ選択は保守的。
システム構造がきれい。
商用ベンダーに強く縛られない。
コミュニティガバナンスが成熟している。
長期稼働する基礎サービスに向く。

次のようなサーバーなら Debian は扱いやすいです。

Nginx / Apache。
PostgreSQL / MariaDB / Redis。
Docker / Podman。
WireGuard / Tailscale。
ファイルサービス、バックアップサービス、監視サービス。
小規模な自ホストアプリ。

Debian の強みは「最新」ではなく「手間が少ない」ことです。多くのサーバーはインストール後、数年間は通常のセキュリティ更新と小さな保守だけで動かせます。

Debian に向いている場面：

システムをなるべく素朴に保ち、ディストリビューションベンダーの戦略に振り回されたくない。
apt、systemd、Debian のファイル構成に慣れている。
ソフトウェアが最新版でなくてもよい。
安定性、セキュリティ更新、予測しやすいアップグレードを重視する。

Debian にあまり向かない場面：

ベンダーが RHEL または Ubuntu だけを認証している。
SLA 付きの企業向け商用サポートが必要。
最新カーネル、最新 GPU スタック、新しいハードウェア対応に依存している。
チームの運用標準が全面的に RHEL 系エコシステムで書かれている。

私の判断では、個人サーバー、自ホスト、軽量 SaaS、小規模チームの基礎サービスでは、Debian は今でも非常に有力です。

Rocky Linux：CentOS 後の堅実な代替

Rocky Linux の位置付けは明確です。RHEL 互換エコシステムを必要とするユーザー向けであり、かつて CentOS Linux が企業本番環境で果たしていた役割を引き継ぎます。

2026年時点で、Rocky Linux 9 と Rocky Linux 10 はどちらもサポート期間内です。Rocky Linux 9 はより保守的な本番環境に向き、Rocky Linux 10 は新規プロジェクト、新しいハードウェア、より長い将来期間に向きます。

Rocky Linux に向く場面：

以前 CentOS 7 / CentOS 8 を使っていた企業環境。
RHEL 系のディレクトリ構造、パッケージ名、運用習慣が必要。
dnf、RPM、SELinux、firewalld に依存している。
ソフトウェアベンダーが RHEL-compatible ディストリビューションを明示的にサポートしている。
社内自動化スクリプトが Enterprise Linux 前提で書かれている。

利点は移行の抵抗が小さいことです。多くのチームは CentOS を前提に Ansible playbook、監視ルール、監査スクリプト、セキュリティベースラインを長年積み上げています。Rocky Linux への移行は、Debian や Ubuntu への移行より心理的負担が小さいです。

Rocky Linux の注意点：

パッケージバージョンは保守的です。これは Enterprise Linux の設計目標であり、欠点ではありません。
非常に新しいユーザー空間コンポーネントが必要な場合、EPEL、第三者リポジトリ、またはコンテナに頼ることがあります。
RHEL 互換は、すべての商用ソフトウェアベンダーが自動的に正式サポートするという意味ではありません。認証リストを確認してください。
Rocky Linux 10 はハードウェア基準や第三者エコシステムに新しい要件があります。本番投入前に検証が必要です。

私の判断では、サーバー環境がもともと CentOS / RHEL 系なら、Rocky Linux は非常に自然な代替です。特に安定した本番環境と企業内部サービスに向いています。

AlmaLinux：より能動的な RHEL 互換ルート

AlmaLinux も CentOS 後の重要な代替です。位置付けは同じく、企業向け、長期サポート、RHEL 互換です。

Rocky Linux との共通点は多くあります。

どちらも RHEL 互換エコシステム向け。
どちらもサーバー本番環境に向く。
どちらも 8、9、10 の長期サポート系列を持つ。
どちらも CentOS からの移行に向く。
どちらも多くの Enterprise Linux エコシステムツールを使える。

違いは、AlmaLinux が RHEL 互換を保ちながら、上流との差異をより積極的に記録・処理する点です。たとえば AlmaLinux 10 は古いハードウェア向けに x86-64-v2 アーキテクチャ選択肢を提供し、release notes で RHEL との差異を明確に説明しています。

これは一部のユーザーに有用です。RHEL エコシステムに留まりつつ、ハードウェア対応、パッケージビルド、EPEL 互換性でより柔軟なコミュニティディストリビューションを求める場合です。

AlmaLinux に向く場面：

RHEL 互換が必要だが、RHEL のリリース戦略に完全には縛られたくない。
コミュニティガバナンスと透明な release notes を重視する。
クラウド、コンテナイメージ、企業ワークロードで安定したベースシステムが必要。
CentOS や古い Enterprise Linux から平滑に移行したい。

注意すべき点は、AlmaLinux が「目を閉じれば RHEL と同じ」ではないことです。厳格なコンプライアンス、ベンダー認証、データベース認証、ハードウェア認証が必要な場面では、ソフトウェアベンダーが AlmaLinux を明示的にサポートしているか確認してください。

私の判断では、Rocky Linux と AlmaLinux はどちらも CentOS 代替になります。より保守的で伝統的な CentOS 的ストーリーを好むなら Rocky、コミュニティ透明性と柔軟な互換ルートを重視するなら AlmaLinux です。

Ubuntu Server：クラウド対応とデプロイ効率が最も強い

Ubuntu Server の強みは現実的です。クラウドプラットフォーム、ドキュメント、コミュニティチュートリアル、イメージ、自動化ツール、開発者エコシステムが強いです。

2026年の新規サーバー導入では、主力は引き続き Ubuntu 24.04 LTS です。Ubuntu LTS は通常 5 年の標準サポートを持ち、ESM による延長も可能です。クラウドサーバー、コンテナホスト、開発環境、CI/CD ノードでは、Ubuntu Server が最も早く使える選択になることが多いです。

Ubuntu Server に向く場面：

AWS、Azure、Google Cloud、Oracle Cloud、Alibaba Cloud、Tencent Cloud などのクラウドサーバー。
Docker、Kubernetes、GitLab Runner、CI/CD。
AI / GPU / CUDA 開発環境。
大量のチュートリアルとコミュニティ解法が必要なチーム。
開発と本番をできるだけ同じ環境にしたい場合。

Ubuntu の利点：

クラウドイメージの品質が高い。
公式・第三者ドキュメントが多い。
新しいハードウェア対応が比較的積極的。
LTS のリズムが明確。
開発者ツールチェーンを更新しやすい。
多くの商用ソフトウェアが Ubuntu 向け手順を優先して用意する。

Ubuntu の注意点：

サーバーで Snap を好まないチームもあるため、利用方針は事前に決めるべきです。
PPA は便利ですが、本番環境で乱用すると保守リスクが増えます。
HWE カーネル、クラウドカーネル、標準カーネルのどれを使うか明確にする必要があります。
極めてミニマルな安定性を好む人には、Ubuntu の標準構成は Debian より「にぎやか」に感じられます。

私の判断では、クラウドサーバー、コンテナ、開発デプロイ、AI ツールチェーンが中心なら、Ubuntu Server は通常最も効率的です。最も「純粋」なディストリビューションではありませんが、多くの作業で調査とつまずきを減らしてくれます。

四つをどう選ぶか

個人 VPS / 自ホスト

Debian または Ubuntu Server を優先します。

安定、省心、低メンテナンスを求めるなら Debian。チュートリアルに沿って新しいプロジェクトを頻繁にデプロイする、または新しめのソフトウェアスタックが必要なら Ubuntu Server です。

企業本番環境

Rocky Linux、AlmaLinux、または RHEL を優先します。

会社が以前 CentOS を使っていたなら、Rocky / Alma への移行コストが最も低いです。商用データベース、ハードウェア認証、セキュリティコンプライアンス、ベンダーサポートが関わる場合は、認証リストを先に確認してください。

クラウドネイティブとコンテナホスト

Ubuntu Server、Debian、Rocky / Alma はいずれも使えます。

開発効率を重視するチームなら Ubuntu Server。極簡安定を求めるなら Debian。企業標準が RHEL 系なら Rocky / Alma です。

AI / GPU サーバー

まず Ubuntu Server、次に Rocky / Alma を見ます。

理由は単純です。NVIDIA、CUDA、PyTorch、TensorFlow、ドライバ導入手順、コミュニティ経験は Ubuntu が最も多いことが一般的です。企業 GPU クラスターがすでに RHEL エコシステムで構築されている場合は Rocky / Alma も選べますが、ドライバ、CUDA、コンテナランタイム、監視ツールは事前検証が必要です。

伝統的な業務システム

Rocky Linux / AlmaLinux を優先します。

伝統的な Java、データベース、ミドルウェア、商用ソフトウェア、監査、運用標準は RHEL 系に寄りがちです。この場合、Rocky / Alma は Debian / Ubuntu より既存体系に合わせやすいです。

選ぶ前に見るべき指標

ディストリビューション名だけで選ばないことです。サーバー選定では、次の質問で判断するのがよいでしょう。

ライフサイクル：このバージョンは何年まで保守されるか。
アップグレード経路：メジャーバージョンアップは成熟しているか。平滑移行は可能か。
ソフトウェア供給元：第三者リポジトリに依存するか。誰が保守しているか。
セキュリティ更新：セキュリティアドバイザリ、パッチ頻度、CVE 対応は明確か。
ハードウェア対応：CPU、NIC、RAID、GPU、ストレージコントローラは検証済みか。
チーム経験：チームは apt と dnf のどちらに慣れているか。Debian 系か RHEL 系か。
ベンダー認証：業務ソフトウェアはそのディストリビューションを明示的にサポートしているか。
自動化資産：既存の Ansible、Terraform、イメージビルドスクリプトを再利用できるか。

本当のコストはインストール ISO ではありません。今後 5 年のアップグレード、監査、トラブルシュート、引き継ぎです。

私のおすすめ構成

2026年のサーバー選定でデフォルト案を出すなら次の通りです。

場面	推奨
個人 VPS、自ホスト	Debian 13
クラウドサーバー、素早いデプロイ	Ubuntu Server 24.04 LTS
CentOS 移行	Rocky Linux 9 / AlmaLinux 9
新規企業プロジェクト	Rocky Linux 10 / AlmaLinux 10。先にエコシステム検証
AI / GPU 開発	Ubuntu Server 24.04 LTS
強いコンプライアンスが必要な商用本番	RHEL、またはベンダーサポート確認後に Rocky / Alma

短い結論

Debian のキーワードは、安定、簡潔、コミュニティ、自由ソフトウェアの伝統です。長期稼働する基礎サーバーに向きます。

Rocky Linux と AlmaLinux のキーワードは、RHEL 互換、企業本番、CentOS 代替です。既存の Enterprise Linux 運用体系を持つチームに向きます。

Ubuntu Server のキーワードは、クラウド、ドキュメント、開発効率、エコシステムの完全性です。素早いデプロイ、コンテナ、AI/GPU、クラウドサーバーに向きます。

永遠に正しいディストリビューションはありません。チーム、業務、ハードウェア、ライフサイクルに最も合うものが正解です。サーバーで最良の選択は、たいてい一番流行っているものではなく、5 年後も保守する気になれるものです。

Nginx のレート制限設定：高頻度の 404・400 スキャンリクエストに rate limit をかける

Fri, 01 May 2026 05:41:31 +0800

Web サイトのログに突然大量の 404 や 400 が出る場合、原因は通常ユーザーがリンクを押し間違えたことではなく、自動スキャナーが .env、.git、wp-admin、phpmyadmin、xmlrpc.php といったパスを探っていることが多いです。

この種のリクエストには、いくつか問題があります。

access log が急速に大きくなる
error log が意味の薄い記録で埋まる
静的サイトやリバースプロキシの接続が無効なリクエストに使われる
本当に見るべき問題がスキャンノイズに埋もれる

Nginx では limit_req と limit_conn を使って制限できます。ただし先に一点だけ重要です。Nginx は「レスポンスステータスが 404 または 400 だったら制限する」という処理を標準機能だけで直接行うことはできません。レート制限はレスポンス生成前に行われるためです。

実際には、404 / 400 を生みやすいスキャンパス、異常なアクセス元、サイト全体の高頻度アクセスを事前に制限します。

基本方針

まずは三層に分けるのがおすすめです。

サイト全体にゆるいレート制限をかけ、単一 IP による高頻度アクセスを抑える。
よくあるスキャンパスには厳しめの制限をかけ、直接 404 を返す。
IP ごとの同時接続数を制限する。

より安全な導入順は、まずスキャンパスのルールと access_log off を入れて 1 日観察することです。それでもランダムパスの 404 が多い場合に、サイト全体の limit_req を追加します。

まず http でレート制限用 zone を定義する

limit_req_zone と limit_conn_zone は必ず http {} の中に置きます。個別サイトの server {} には置けません。

/etc/nginx/nginx.conf の http {} に直接書けます。

http {
    # 按客户端 IP 限速，普通页面请求
    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;

    # 更严格：疑似扫描路径
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;

    # 并发连接限制
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

別ファイルを作っても構いません。

`1`	`sudo nano /etc/nginx/conf.d/limit-zones.conf`

内容は次の通りです。

1
2
3

limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

前提として、nginx.conf の http {} 内で次が include されている必要があります。

`1`	`include /etc/nginx/conf.d/*.conf;`

次に server で zone を使う

サイト設定ファイルは通常 /etc/nginx/sites-enabled/www.example.com のような場所にあり、中身はたいてい server {} です。ここには limit_req_zone を書かず、前段で定義した zone だけを使います。

例：

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    # 全站温和限速：允许短时突发，降低误伤正常用户的概率
    limit_req zone=perip_general burst=30 nodelay;
    limit_conn addr_conn 20;

    # 对常见扫描路径严格限速，并关闭访问日志
    location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
        access_log off;
        limit_req zone=perip_scan burst=5 nodelay;
        return 404;
    }

    # 你原来的 location /、listen ssl 等配置继续放这里
}

サイト全体のレート制限で通常アクセスを巻き込むのが心配なら、最初はスキャンパスだけにしてもよいです。

location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
    access_log off;
    limit_req zone=perip_scan burst=5 nodelay;
    return 404;
}

各パラメータの意味

この行：

`1`	`limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;`

意味は次の通りです。

limit_req_zone：リクエストのレート制限に使うカウント用 zone を定義する。
$binary_remote_addr：クライアント IP を制限キーにする。$remote_addr よりメモリ効率がよい。
zone=perip_general:20m：perip_general という名前の共有メモリ領域を 20m のサイズで作る。
rate=5r/s：IP ごとに平均で毎秒 5 リクエストまで許可する。

この行：

`1`	`limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;`

基本は同じですが、より厳しい設定です。

perip_scan：疑わしいスキャンパス専用。
rate=1r/s：IP ごとに毎秒 1 リクエストだけ許可する。

この行：

`1`	`limit_conn_zone $binary_remote_addr zone=addr_conn:20m;`

意味は次の通りです。

limit_conn_zone：同時接続数制限に使うカウント用 zone を定義する。
$binary_remote_addr：ここでもクライアント IP ごとに集計する。
zone=addr_conn:20m：addr_conn という名前の接続数カウント用共有メモリ領域を作る。

実際に同時接続数を制限するのは次です。

`1`	`limit_conn addr_conn 20;`

これは、各 IP の同時接続を最大 20 本にする、という意味です。

burst と nodelay の考え方

例えば：

`1`	`limit_req zone=perip_general burst=30 nodelay;`

次のように理解できます。

rate=5r/s：長期的な平均レートは毎秒 5 リクエスト。
burst=30：短時間の突発分として 30 リクエストまで許容する。
nodelay：平均レートを超えても burst 内なら待たせず処理し、burst を超えたら拒否する。

nodelay がない場合、Nginx は一部リクエストを遅延させてキューに入れようとします。通常の Web ページでは nodelay のほうが挙動を理解しやすいことが多いです。API や特に敏感なエンドポイントでは、実際の挙動に合わせて調整します。

よくあるエラー：limit_req_zone の配置場所が違う

次のようなエラーが出た場合：

`1`	`2026/04/30 21:33:48 [emerg] 2290771#2290771: "limit_req_zone" directive is not allowed here in /etc/nginx/sites-enabled/example.com:9`

これは、limit_req_zone を許可されていない場所に書いたという意味です。

よくある誤りは、server {} の中に置いてしまうことです。

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;

    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;
}

これは動きません。

覚え方はシンプルです。

limit_req_zone は「プールを定義する」ものなので http {} に置く。
limit_req は「プールを使う」ものなので server {} または location {} に置く。
limit_conn_zone は「接続プールを定義する」ものなので http {} に置く。
limit_conn は「接続プールを使う」ものなので server {} または location {} に置く。

明らかに異常な IP を一時的に拒否する

ログから、特定の IP が継続的にスキャンしていると確認できている場合は、一時的に拒否してもよいです。

deny 45.95.42.164;
deny 185.177.72.51;
deny 185.177.72.5;
deny 185.177.72.56;
deny 185.177.72.58;

この種の deny は server {} にも、特定の location {} にも置けます。長期的に残すかどうかは、誤検知リスクとアクセス元を見て判断します。

チェックしてリロードする

変更後はまず設定を確認します。

`1`	`sudo nginx -t`

問題がなければリロードします。

`1`	`sudo systemctl reload nginx`

いきなりサービスを再起動しないほうがよいです。reload なら Nginx が新しい設定を滑らかに読み込むため、リスクが低くなります。

推奨パラメータ

個人サイトや静的サイトなら、まずは次の値から始めるとよいです。

通常ページ：rate=5r/s から 10r/s
スキャンパス：rate=1r/s
スキャンパスの burst=5
サイト全体の burst=30
IP ごとの同時接続：10 から 20

通常ユーザーのアクセスが少ないサイトなら、さらに厳しくできます。画像、スクリプト、API リクエストが多いサイトでは、通常ページの制限を少し緩めて、本物のアクセスを巻き込まないようにします。

一番安全なのは段階的に入れる方法です。

まずスキャンパスに access_log off + return 404 を入れる。
次に perip_scan の厳しいレート制限を加える。
1 日ログを見る。
ランダムパスの 404 がまだ多い場合、サイト全体のゆるいレート制限を有効にする。

Ubuntu 26.04 LTS の GPU とハードウェア対応アップデート: CUDA、ROCm、DPC++、そして各種プラットフォームの変更

Sun, 26 Apr 2026 19:35:57 +0800

前の記事が Ubuntu 26.04 LTS のデスクトップ全体像だったとすれば、こちらはハードウェアと計算基盤まわりの補足版です。今回の 26.04 では、AI、GPU コンピューティング、プラットフォーム互換性に関わる項目が、メインアーカイブや正式サポートの範囲にかなり取り込まれています。

先に結論を言うと、今回の注目点は単なるデスクトップやカーネルの更新ではなく、Ubuntu が Intel、NVIDIA、AMD の GPU コンピューティングスタックを、より体系的にディストリビューションへ取り込み始めたことです。

1. Intel DPC++ と関連コンポーネントが Ubuntu Archive に追加

26.04 から、Intel のオープンソース oneAPI DPC++ コンパイラが Ubuntu Archive から直接利用できるようになり、SYCL コードのビルドに使えます。ランタイムには Intel GPU 向けアダプタも含まれます。

あわせて、次の関連コンポーネントも Ubuntu リポジトリで利用可能になりました。

oneDPL。DPC++ library として、より高生産性な開発 API を提供
oneDNN。dpclang-6 でビルドされており、Intel GPU 上で実行可能

つまり、すでに SYCL、ヘテロジニアスコンピューティング、あるいは Intel GPU 上の AI ワークロードを見ている人にとって、Ubuntu 上での導入経路がかなり素直になったということです。従来のように外部スタックを丸ごと別管理する必要が薄くなります。

実運用上の注意点として、Ubuntu はこれらの Intel GPU 関連機能を使うにはユーザーが render グループに属している必要があるとも明記しています。

2. NVIDIA CUDA toolkit も `apt` で直接導入可能に

多くの開発者や運用担当者にとって、これは今回の更新の中でもかなり実用的な変更でしょう。

26.04 から、NVIDIA CUDA toolkit を Ubuntu Archive から直接インストールできます。

`1`	`sudo apt install cuda-toolkit`

意味があるのは、単にセットアップ手順が少し減るという話だけではありません。

Ubuntu 向けにソフトウェアを配布する開発者にとっては、CUDA runtime への依存関係を宣言するだけでよくなり、実際のインストールや互換性管理は Ubuntu 側がディストリビューションレベルで面倒を見る形になります。CUDA が Ubuntu 上でよりネイティブなシステム機能に近づき、別管理の外部スタックとして抱え込む必要が減るわけです。

3. AMD ROCm 7.1.0 が Universe に追加

AMD 側では、Ubuntu Universe に ROCm 7.1.0 が入りました。

このライブラリ群が提供する主なものは次の通りです。

AMD GPU 向け AI 学習・推論のバックエンド基盤
機械学習および高性能計算向けのソフトウェア基盤

さらに Canonical は、ROCm 関連コンポーネントを自社の CI/CD パイプラインで継続的に検証していると述べています。autopkgtests に加えて、次のようなユーザー空間アプリケーションも対象です。

llama.cpp
pytorch
Blender
Lemonade Server

ここはかなり重要です。Ubuntu は単にパッケージを置いただけではなく、ROCm をメンテナブルなソフトウェアスタックとして扱い、継続的に検証していることを意味します。

4. 本当のポイントは 3 社の GPU エコシステムが同時に進んでいること

DPC++、CUDA、ROCm を並べて見ると、26.04 の方向性がわかりやすくなります。

Intel: SYCL / oneAPI 系の機能を公式リポジトリへ取り込む
NVIDIA: CUDA toolkit にディストリビューション管理の導入経路を与える
AMD: ROCm 7.1.0 を Universe に入れ、継続的な検証も行う

Ubuntu 上で次のような用途に触れる人ほど、この更新の意味を感じやすいはずです。

ローカル LLM 推論
GPU アクセラレーションを使った学習やファインチューニング
Blender、科学技術計算、HPC
複数の GPU プラットフォームをまたぐ開発環境

要するに、Ubuntu は「GPU ドライバが入る OS」から一歩進み、AI と GPU コンピューティングに必要なユーザー空間ソフトウェアスタックもより包括的に担うディストリビューションになりつつあります。

5. NVIDIA Dynamic Boost がデフォルトで有効化

25.04 以降、対応する NVIDIA 搭載ノート PC では Dynamic Boost がデフォルトで有効になっています。

仕組み自体はわかりやすく、システム負荷に応じて CPU と GPU の間で消費電力を動的に振り分けます。ゲーム用途では、必要なときに GPU へより多くの電力を回し、性能を引き上げる形になります。

ただし有効になる条件は 2 つあります。

AC 電源に接続されていること
GPU 負荷が十分に高いこと

バッテリー駆動時には動作しません。

6. 新しい Intel 内蔵 GPU / 外付け GPU のサポートも前進

Ubuntu は新しい Intel GPU への対応も引き続き進めています。主な対象は次の通りです。

統合 GPU:

Intel Core Ultra Xe2
Intel Core Ultra Xe3

ディスクリート GPU:

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

これらのデバイスに関連して、Ubuntu はすでに利用可能な機能も挙げています。

Intel Embree を利用した GPU / CPU レイトレーシング描画性能の向上。Blender 4.2+ などで恩恵あり
“Battlemage” デバイスで AVC、JPEG、HEVC、AV1 のハードウェアエンコードをサポート
Intel Compute Runtime に新しい CCS 最適化を導入
Intel Xe GPU のデバッグサポートを有効化

さらに後続の 25.10 では、次のような機能強化も続きます。

Linux kernel 6.17 を通じて、開発コードネーム Panther Lake の次世代 Intel クライアントプラットフォームを初期サポート
IOMMU、PCIe サブシステム、マルチ GPU サポートの改善
Mesa 25.2.3 で Battlemage と Panther Lake 向けに VK_KHR_shader_bfloat16 を有効化
intel-media-driver 25.3.0 で Panther Lake のデコードと VP9 エンコードを追加
intel-compute-runtime 25.31 で Level Zero の USM プールやローカルデバイスメモリ上のイベント確保戦略を調整
level-zero 1.24 と level-zero-raytracing 1.1.0 で仕様対応と RTAS 拡張を強化

7. Nvidia デスクトップのサスペンド復帰も安定化

25.10 から、Ubuntu はプロプライエタリな Nvidia ドライバでサスペンド復帰を有効化し、復帰時の破損やフリーズを減らしています。

見た目に派手な変更ではありませんが、長時間稼働させるデスクトップや、サスペンドと復帰を繰り返す環境ではかなり大事な改善です。

8. ARM、Raspberry Pi、RISC-V、IBM Z でも要件変更がある

GPU ソフトウェアスタック以外にも、今回のリリースノートにはプラットフォーム面で覚えておきたい変更がいくつかあります。

ARM64 デスクトッププラットフォーム

25.10 から、ARM64 向け linux-generic カーネルは、UEFI で起動する ARM64 デスクトッププラットフォームへの互換性をより広く提供します。

Raspberry Pi の新しいブートレイアウト

25.10 で導入され、26.04 でも継続調整されている変更の 1 つが、Raspberry Pi 向けブートパーティションの新レイアウトです。

目的はブート信頼性の向上で、新しく書き込まれたブート資産はいったん「テスト」され、問題がなければ新しい “known good” セットとして確定されます。

特に覚えておきたいのはファームウェア日付の条件です。

Pi 3 / 3+ / CM3+ / Zero 2W: 追加作業は不要。ブートファームウェアはイメージ自体に含まれる
Pi 4 / 400 / CM4: ブートファームウェアの日付が 2022-11-25 以前であってはならない
Pi 5 / 500 / CM5: ブートファームウェアの日付が 2025-02-11 以前であってはならない

確認コマンドは次の通りです。

`1`	`sudo rpi-eeprom-update`

ファームウェアが古く、かつ Ubuntu 24.04 LTS 以降を使っているなら、次のように更新できます。

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi デスクトップイメージは desktop-minimal ベースに

25.10 から、Raspberry Pi 向け Ubuntu Desktop イメージは完全な desktop seed ではなく、desktop-minimal ベースになりました。

Ubuntu が示している利点は明確で、デフォルトのアプリセットが小さくなり、非圧縮イメージと実システムの両方で約 777MB を節約できます。

アップグレード後にこのデフォルトアプリ群をまとめて削除したい場合は、次を使えます。

`1`	`sudo apt purge ubuntu-desktop --autoremove`

一部のアプリを残したいなら、先に apt で手動インストール扱いにしておけば除外できます。

Raspberry Pi の swap は cloud-init 管理に

25.10 から、Raspberry Pi デスクトップイメージ上の swap ファイル作成は cloud-init が担当します。
初回起動前に swap サイズを調整したい場合は、ブートパーティション上の user-data を直接編集できます。

RISC-V の要件が引き上げ

25.10 から、Ubuntu 26.04 LTS の RISC-V 版は RVA23S64 ISA profile を実装したハードウェアを必要とします。

この要件を満たさないシステムでは Ubuntu 26.04 LTS を動かせません。もし以前の RVA20 プロセッサコアを使ったボードを使っているなら、Ubuntu 24.04 LTS のサポートラインに留まる必要があります。

Ubuntu の説明では、2026 年 4 月 時点で実機の RVA23S64 ハードウェアはまだ存在しません。そのため、現在サポートされる唯一の環境は、実質的には -cpu rva23s64 を指定した QEMU 仮想環境です。

IBM Z の最低要件は z15 に

26.04 から、s390x アーキテクチャの最低要件は z15 へ引き上げられました。

つまり次のようになります。

z14 / LinuxONE II およびそれ以前のシステムでは Ubuntu 26.04 LTS をインストールできない
z15 / LinuxONE III 以降では性能向上が期待できる

9. この内容を先に読むべき人

次のようなケースでは、この文章のほうがデスクトップ概要より優先度が高いはずです。

Ubuntu 上で CUDA、ROCm、SYCL、ローカル AI 推論を使う
Intel、NVIDIA、AMD の GPU を使った開発や計算処理を行う
Raspberry Pi、ARM64、RISC-V、IBM Z など、標準的な x86 以外のプラットフォームを運用している
アップグレード後のリポジトリ可用性、ドライバ挙動、ランタイム、プラットフォーム要件に敏感である

10. ひと言でまとめると

Ubuntu 26.04 LTS のハードウェアと AI スタック面での要点は、どこか 1 社の GPU だけが大きく強化されたことではありません。Intel の DPC++、NVIDIA の CUDA、AMD の ROCm が、より公式に、よりリポジトリ内で、より保守しやすい形で Ubuntu エコシステムへ入ってきたことです。

これまで Ubuntu を「まず OS を入れて、その上に GPU 環境は自分で組むもの」と見ていたなら、26.04 は AI やヘテロジニアスコンピューティングのワークロードを、ディストリビューション側がより積極的に支える方向へ進み始めた版だと言えます。

Ubuntu 26.04 LTS リリース：GNOME 50 と Linux 7.0 でデスクトップが大きく更新

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS は 2026 年 4 月 23 日 に公開され、コードネームは Resolute Raccoon です。今回は新しい長期サポート版で、標準サポートは 2031 年 4 月 まで続きます。Ubuntu Pro を使う場合は、セキュリティメンテナンスを 10 年 まで延長できます。

Ubuntu 24.04 LTS からアップグレードする場合、この版は単なる定例更新ではありません。24.10、25.04、25.10 の主な変化もまとめて取り込んでいます。なので、この記事は「アップグレード前に何を見ておくべきか」を素早く把握するための要約として読むのがいちばん向いています。

今回のリリースで特に重要な更新だけを先に押さえるなら、まず次の 4 点です。

GNOME 50 が LTS に入り、デスクトップ体験と表示まわりのサポートが一段進みました
Linux kernel 7.0 が新しい基準になり、ハードウェア対応と今後の保守基盤が更新されました
Ubuntu Desktop は正式に全面 Wayland へ移行しました
既定アプリ群がまとめて更新され、Firefox、LibreOffice、Thunderbird、GIMP が大きく新しくなりました

1. まずは重要な更新を確認

Ubuntu 26.04 LTS は長期サポート版で、標準サポートは 2031-04 までです
デスクトップ環境は GNOME 50 に更新されました
汎用カーネルは Linux kernel 7.0 に更新されました
Ubuntu Desktop のセッションは Wayland のみになりました
古いバージョンから 26.04 へ大きく飛び越して直接アップグレードすることはできません

まだ Ubuntu 22.04 LTS または 25.04 を使っている場合、公式にはまず Ubuntu 24.04 LTS か 25.10 へ上げてから、さらに 26.04 LTS へ進むことが推奨されています。

2. 最大の変化その 1：GNOME 50 が LTS に入った

今回のデスクトップ側で最もわかりやすい変化は、GNOME 50 がついに LTS に入ったことです。一般ユーザーにとって価値があるのは、単発の目立つ新機能というより、デスクトップ全体の使い勝手がまとめて良くなった点です。

小型画面や狭いウィンドウでの使いやすさが向上
通知をアプリ単位でグループ化可能
HDR、VRR、分数スケーリングなど表示関連の改善が継続
リモートデスクトップ、Wayland、NVIDIA ドライバ環境での滑らかさと安定性が向上
アクセシビリティ対応がさらに強化され、Orca スクリーンリーダーも目立つ更新が入っています

Ubuntu 独自の実用的な改善もあります。

GNOME Shell のグローバル検索から利用可能な snap アプリを直接探せる
検索からそのままウェブ検索を始められる
Yaru テーマは upstream GNOME の見た目にさらに近づいた
snap アプリの権限、ファイルアクセス、ドラッグアンドドロップの体験がより自然になった

普段デスクトップ版を使っているなら、この世代の LTS のポイントは「見た目が大きく変わった」ことではなく、以前からあった細かな引っかかりがまとめて減ったことにあります。

3. 最大の変化その 2：既定アプリが広く刷新された

24.04 LTS と比べると、26.04 LTS に含まれる標準アプリはかなり大きく更新されています。

Firefox は 150 へ
LibreOffice は 24.2 から 25.8 へ
Thunderbird は 140 へ
GIMP は 2.10 から 3.2 へ

さらに、日常利用で影響の大きい置き換えもあります。

PDF ビューアは Evince から Papers に変更
画像ビューアは Loupe に変更
ターミナルは Ptyxis に変更
システムモニターは Resources に変更
既定の動画プレーヤーは Showtime に変更

こうした変化から見える方向性は明確です。Ubuntu は GTK4、libadwaita、そして一部では Rust で再実装された新世代の GNOME アプリ群へ、より本格的に寄せています。

4. 最大の変化その 3：Wayland が唯一のデスクトップセッションになった

これは長く Ubuntu を使ってきた人ほど気になる変更です。

25.10 から始まっていた流れが、26.04 LTS で正式に定着しました。Ubuntu Desktop は Wayland バックエンドのみで動作し、GNOME Shell はもはや X.org セッションとしては動きません。

もちろん、これで古いアプリが全部使えなくなるわけではありません。公式リリースノートでも、X.org 向けアプリは XWayland 互換レイヤー経由で引き続き動かせると明記されています。ただし、古い GPU ドライバや一部のリモートデスクトップ手法、録画ツール、入力メソッドの細かな挙動に依存しているワークフローなら、アップグレード前の確認はやっておいたほうが安心です。

5. 最大の変化その 4：Linux kernel 7.0 と低層スタックもまとめて更新

Ubuntu 26.04 LTS の GA generic スタックは Linux 6.8 から Linux 7.0 に上がり、HWE スタックも 7.0 に統一されました。

公式が触れている低層側の変更の中で、一般ユーザーや運用担当に関係が大きいのは次のあたりです。

デスクトップ版とサーバー版の両方で crash dump が既定で有効
sched_ext により、開発者が eBPF を使ってスケジューリングポリシーを実装できる新しい拡張モデルが入った
linux-lowlatency バイナリパッケージは廃止され、linux-generic とユーザー空間の lowlatency-kernel パッケージによる低レイテンシ調整へ移行
amd64v3 アーキテクチャ変種は利用可能だが、既定では opt-in のまま

比較的新しいマシンを使っているなら、amd64v3 は気にしておいてよい項目です。公式が示している有効化方法は次のとおりです。

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

ただし、これは自動では有効になりません。Ubuntu は引き続き互換性を最優先にしています。

6. ハードウェア要件と導入の目安

Ubuntu Desktop 26.04 LTS に対して公式が示している推奨ラインは次のとおりです。

2 GHz のデュアルコア CPU 以上
6 GB RAM 以上
25 GB 以上の空きストレージ

マシンの性能がやや低めなら、公式には Xubuntu や Lubuntu のようなフレーバーも検討するよう案内されています。
サーバー版の下限はもっと低く、ドキュメントでは 1.5 GB RAM と 4 GB ストレージから始められるとされていますが、実際には動かすサービスの負荷次第です。

7. どんな人に優先してアップグレード向きか

すでに 24.04 LTS を使っていて、次のようなものを求めているなら、26.04 LTS はかなり有力です。

小さなパッチではなく、一世代分まとめて更新されたデスクトップスタック
より成熟した Wayland と表示サポート
新しくなった既定アプリ群
新しいカーネルと、より長い今後のサポート期間

一方で、古い X11 ワークフローや特殊なドライバ、独自のデスクトップ拡張に強く依存している場合、あるいは本番環境で変更に非常に慎重である場合は、アップグレード前に互換性確認を一度通しておくのが無難です。

8. ひとことでまとめると

Ubuntu 26.04 LTS の価値は、目立つ単独機能ひとつにあるわけではありません。ここ 2 年のデスクトップ、カーネル、アプリ、互換性の進化を、新しい LTS の基準に一気にまとめて載せたところにあります。

最短で言うなら、この版は「全体として新しくなり、全体として安定した」Ubuntu LTS であり、ひとつの派手な売りだけで成り立っている版ではない、ということです。

nftables フレームワークを理解する：テーブル、チェーン、ルール、セット

Sat, 18 Apr 2026 10:31:12 +0800

nftables を学び始めると、ついコマンドの細部に入りがちです。ルールをどう追加するか、handle をどう削除するか、ポートマッチをどう書くか。もちろんコマンドは重要ですが、先にフレームワークの概念を整理しておくと、ルールの読解、問題調査、ルールセット設計がかなり楽になります。

nftables は、次のような階層構造として理解できます。

table はルール空間を分離する。
family はルールが扱うネットワークプロトコルを決める。
chain はルールがどの段階で実行されるかを決める。
rule は具体的なマッチ条件とアクションを持つ。
set、map、verdict map は重複ルールを減らし、ルールセットを保守しやすくする。

以下では、概念を階層ごとに整理します。

table：ルールの名前空間

table は nftables で最も外側にあるルールコンテナです。異なる table は互いに分離されるため、関連するルールを同じ table にまとめるのが一般的です。

たとえば、フィルタリングルール、NAT ルール、独自のテスト用ルールを分けて置けます。こうすると境界が明確になります。デバッグ時にはどのルール群を変更しているかが分かりやすく、クリーンアップ時にも無関係な内容を誤って削除しにくくなります。

table 自体はパケットを直接処理しません。実際にパケット処理に関わるのは、table の中にある chain と rule です。

family：ルールが対象にするプロトコル

table を作成するときは family を選びます。これは、その table 内のルールがどの種類のパケットに適用されるかを決めます。

代表的な family は次のように理解できます。

ip：IPv4 のみを処理する。
ip6：IPv6 のみを処理する。
inet：IPv4 と IPv6 の両方を処理する。
arp：ARP を処理する。
bridge：ブリッジ層のトラフィックを処理する。
netdev：ネットワークデバイス入口に近く、より早い段階でトラフィックを処理する用途に向く。

通常のファイアウォールルールでは、inet がよく使われます。IPv4 と IPv6 のルールを同じ table に置けるため、似た構造のルールを 2 セット維持する必要がなくなります。

chain：ルールが実行される場所

chain は rule のリストです。パケットがある hook に入ると、chain 内のルールを順番に通過します。

chain は大きく 2 種類に分けられます。

基本 chain：カーネルのネットワーク経路上の hook に接続され、パケット処理の流れから直接呼び出される。
通常 chain：hook には直接接続されず、他のルールから jump されて呼び出される。

基本 chain では、通常いくつかの重要な属性を指定します。

type：この chain の用途。たとえば filter、nat、route。
hook：接続する処理段階。たとえば prerouting、input、forward、output、postrouting。
priority：同じ hook に複数の chain があるとき、どれを先に実行するか。
policy：どのルールにもマッチしなかった場合のデフォルト動作。一般的には accept または drop。

chain を理解するうえで重要なのは、ルールは「どこに書いても同じように効く」わけではないという点です。同じルールでも、input、forward、output のどこに置くかで意味はまったく変わります。

rule：マッチ条件とアクション

rule は、nftables が実際に判断を行う場所です。通常は 2 つの部分で構成されます。

マッチ条件：送信元 IP、宛先 IP、プロトコル、ポート、インターフェイス、接続状態など。
アクション：accept、drop、reject、counter、jump、return など。

ルールは順番に評価されます。パケットが処理を終了させるアクションにマッチすると、その後ろのルールは実行されません。マッチしなければ、chain の終端またはデフォルトポリシーに到達するまで処理が続きます。

そのため、ルールの順序は重要です。より具体的なルールは、通常より広い条件のルールより前に置く必要があります。そうしないと、実行される機会がない場合があります。

set：値の集合をまとめる

多数の IP、ポート、インターフェイスをマッチしたい場合、ルールを大量に並べると保守しにくくなります。set は、同じ型の値をひとまとめに管理するための仕組みです。

たとえば、信頼する IP の集合、拒否したいポートの集合、帯域制限したいアドレスの集合を set に入れられます。ルール側では、ある値がその set に含まれるかどうかだけを判定すれば済みます。

set の利点は次のとおりです。

ルール数を減らせる。
可読性が上がる。
後から要素を追加・削除しやすい。

ルールの中に同じような条件が大量に出てくる場合は、set の利用を検討するタイミングです。

map：マッチした値を結果に変換する

map は「参照表」として理解できます。入力値に応じて結果を返します。

たとえば、ポートごとに異なる mark を返す、アドレスごとに異なる処理パラメータを返す、といった表現ができます。多くの if/else 風ルールを書くより、map のほうが集中管理しやすく、保守もしやすくなります。

set が気にするのは「集合に含まれるかどうか」です。一方で map が気にするのは「この値に対応する結果は何か」です。

verdict map：マッチした値をアクションに変換する

verdict map は map の重要な使い方の 1 つです。マッチした値を verdict、つまりルールのアクションに変換します。

たとえば、IP 範囲ごとに accept、drop、または別 chain への jump を対応させられます。これにより、多くの分岐判断を 1 つの構造に圧縮できます。

ルールセットが複雑になってきたとき、verdict map はとても便利です。重複ルールを減らし、長い条件分岐の列ではなく、表に近い形でポリシーを表現できます。

概念からルール設計を考える

nftables ルールを設計するときは、次の順序で考えると整理しやすくなります。

まずルールが属する family を決める。
次に、どの table に入れるかを決める。
適切な hook と chain を選ぶ。
具体的な rule を書く。
重複条件が多い場合は、set、map、verdict map を導入する。

この順序で書くと、ルールは保守しやすく、問題も切り分けやすくなります。

まとめ

nftables の概念は複雑ではありませんが、階層が重要です。

table はルールの境界を管理する。
family はプロトコル範囲を管理する。
chain は実行位置を管理する。
rule はマッチとアクションを管理する。
set、map、verdict map は複雑さを管理する。

まずこれらの概念を理解してから具体的なコマンドを見るほうが、コマンドを直接暗記するより安定します。特にルールセットが増えてきたあとでは、概念が明確だと、問題がプロトコル範囲、実行段階、ルール順序、またはマッチ条件そのもののどこにあるのかを判断しやすくなります。

参考

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables クイック入門：テーブル、チェーン、ルールとよく使う操作

Sat, 18 Apr 2026 10:22:07 +0800

nftables は、Linux でよく使われるパケットフィルタリングとファイアウォールルール管理の仕組みです。端末の通信制御、トラフィック統計、ポートマッチ、簡単な帯域制限だけを行うなら、最初からルール体系全体を覚える必要はありません。まずは次の 3 つを押さえれば十分です。

table：ルールを入れるコンテナ。
chain：ルールが評価される場所。通常は特定の hook に接続します。
rule：実際のマッチ条件とアクション。

以下では、まずテスト環境で試しやすい最小構成の流れを整理します。

基本構成

先にいくつか変数を用意します。以降のコマンドで再利用します。

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

IPv4 と IPv6 の両方を扱える inet table を作成します。

`1`	`nft add table inet $table`

次に、forward 段階に接続する chain を作成します。

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

ここで、type filter はフィルタリング用のルールであることを示し、hook forward は転送されるパケットを処理することを示します。

よく使うマッチ方法

送信元 IP でマッチします。通常はアップロード方向の制御として考えられます。

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

宛先 IP でマッチします。通常はダウンロード方向の制御として考えられます。

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

MAC アドレスでマッチする場合、ether saddr で上り方向を制御できます。

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

ブリッジ、転送、アドレス変換を経由するネットワークでは、下りパケットを宛先 MAC で安定してフィルタできない場合があります。端末の通信制御を行うときは、まず ether saddr または IP ベースのルールから検証するのが安全です。

ポートでマッチする場合、TCP と UDP をまとめて対象にできます。

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

ポート範囲をマッチしたい場合は、比較式を使えます。

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

単一端末の通信量を集計する

特定 IP の上りと下りの通信量を集計したいだけなら、counter return を使えます。マッチしたらカウンターを記録して戻るため、後続に他の統計ルールがある場合でも余計なマッチ処理を減らせます。

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

統計結果を確認します。

`1`	`nft list chain inet $table $chain`

各ルールの handle を確認したい場合は、-a を付けます。

`1`	`nft -a list chain inet $table $chain`

handle は重要です。nftables で単一ルールを削除するときは、通常この値で対象を指定します。

簡単な帯域制限

帯域制限には limit rate over を使えます。たとえば、MAC アドレスごとに指定速度を超えた通信を制限します。

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

ここでの mbytes、kbytes は、日常的な M、K の単位として理解できます。手動で 8 倍換算する必要はありません。実際に使うときは、まず緩めの値でテストし、マッチ方向と効果を確認してから調整するのが安全です。

ルールの削除と整理

まず handle 付きでルールを表示します。

`1`	`nft -a list chain inet $table $chain`

次に handle を指定してルールを削除します。

`1`	`nft delete rule inet $table $chain handle <handle>`

chain を空にします。

`1`	`nft flush chain inet $table $chain`

chain を削除します。

`1`	`nft delete chain inet $table $chain`

table 全体を削除します。

`1`	`nft delete table inet $table`

日常的なデバッグでは、自分で作成した table だけを整理するのがおすすめです。システムや他のサービスが自動生成した table を直接変更しないほうが、ルールを書き間違えた場合でも戻しやすくなります。

使い方のポイント

nftables を使うときは、まず独立した table と chain を自分で作成すると扱いやすくなります。利点は次の 2 つです。

システム既存のルールと混ざりにくい。
デバッグ、flush、削除を安全に行いやすい。

ルールを書いたあとは、必ず nft list chain で実際のマッチ状況を確認します。特に MAC、インターフェイス、ポート、帯域制限のルールは、デバイス、ブリッジ構成、システムバージョンによって挙動が変わることがあります。複雑なルールを一度に書くより、まず小さい範囲で試すほうが安全です。

参考

https://www.right.com.cn/forum/thread-8369750-1-1.html

go2rtc は Xiaomi カメラ RTSP に直接接続します。NVR、HomeKit、Frigate に接続します。

Sat, 11 Apr 2026 08:14:47 +0800

この記事では、go2rtc を使用して Xiaomi カメラストリームを直接取得し、それを NVR、HomeKit、および Frigate に均一に分散する方法を記録します。

Docker のデプロイメント例

services:
  go2rtc:
    container_name: go2rtc
    image: alexxit/go2rtc:master-hardware
    restart: always
    network_mode: host
    privileged: true
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - /vol1/1000/docker/go2rtc:/config

go2rtc バックエンドアドレス:

`1`	`http://192.168.3.217:1984/`

ストリーム構成例

streams:
    micam1:
     - xiaomi://xxx
    #H265转H264,Homekit预览会用到
    #micam1_h264:
     #- ffmpeg:micam1#video=h264#width=1280#height=720#hardware#raw=-r 15
    micam2:
     - xiaomi://xxx
    micam3:
     - xiaomi://xxx

RTSP ストリームアドレスの形式:

`1`	`rtsp://192.168.3.217:8554/micam1`

画質とパラメータ

画質は 0 ～ 5 で指定します。

0 は通常、自動を意味します
1 は sd を意味します
2 は hd を意味します (go2rtc のデフォルト)

一部の新しいカメラは、3 で HD を備えている場合があります。古いモデルでは、3 のコーデック構成が壊れている可能性があるため、フリーサイズは推奨されません。

subtype=hd/sd/auto/0-5 を介して画質を指定できます。

1
2

streams:
  xiaomi1: xiaomi://***&subtype=sd

2 番目のチャンネルパラメーター channel=2 は、デュアルカメラシーンで使用できます。

1
2

streams:
  xiaomi1: xiaomi://***&channel=2

まとめ

go2rtc による統合ストリーミング後は、RTSP を NVR 録画、Frigate 分析、HomeKit プレビューに同時に使用できるようになり、メンテナンスコストが大幅に削減されます。

参考リンク

カメラサポートリスト: https://github.com/AlexxIT/go2rtc/issues/1982
公式説明ソース: https://github.com/AlexxIT/go2rtc/blob/master/internal/xiaomi/README.md
Docker イメージ: https://hub.docker.com/r/alexxit/go2rtc

Windows タスクマネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。

Thu, 09 Apr 2026 18:15:53 +0800

Windows タスクマネージャーを開くと、[プロセス] または [パフォーマンス] ページのデータがスタックしているように見え、CPU、メモリ、ディスク、またはネットワークの値が長期間変更されていないことがわかることがあります。一見するとシステムの異常のように見えますが、実際に実行されているプログラム、ネットワーク伝送、リソースの使用状況は正常に変化しています。

この状況は通常、システムが実際に停止したことを意味するのではなく、タスクマネージャーの更新頻度が「一時停止」に変更されたことを意味します。

現象

一般的な症状には次のものがあります。

「プロセス」ページの CPU、メモリ、その他のデータがジャンプしなくなりました
「パフォーマンス」ページのカーブが長期間更新されない
明らかにプログラムが実行されていますが、タスクマネージャーは非アクティブになっているように見えます。

問題が発生した場合のインターフェイスの例を次に示します。

理由

タスクマネージャーは、「更新速度」の調整をサポートしており、高速、標準、低速、または一時停止に直接設定できます。

これを「一時停止」に設定すると、インターフェイス上のさまざまな統計情報が更新されなくなるため、CPU、メモリ、またはネットワーク情報がすべて停止したように見えます。

下の図に示すように、このオプションは通常、タスクマネージャーの上部メニューの [表示] にあります。

Feiniu NAS にリモートアクセスする 2 つの方法と比較

Sat, 04 Apr 2026 11:00:00 +0800

Feiniu NAS には主に 2 つのリモートアクセス方法があります。

パブリックIP直接接続
FN Connectリモートアクセスサービス

以下は「使い方＋注意事項＋適用シナリオ」に沿って直接参照できるものをまとめたものです。

方法 1: パブリック IP 直接接続

これは、ホームネットワークにパブリック IP があり、ルーターでポート転送を構成する必要があるシナリオに適しています。次に、ブラウザまたは Feiniu アプリにパブリック IPv4/IPv6 アドレスとポート番号を入力してアクセスします。さらに DDNS を使用し、ドメイン名を通じてアクセスすることもできます。

注意事項

Feiniu プライベートクラウド fnOS のデフォルトポート: HTTP = 8000，HTTPS = 8001
ポート転送が設定されている場合、アクセスアドレスにはポート番号が含まれている必要があります。そうでないと、Feiniu NAS に正しくアクセスできません。
パブリック IP 直接接続には通常、追加のリレーがなく、速度損失が軽減されます。
セキュリティ証明書が正しく構成されていない場合、HTTP はプレーンテキストで送信されます。信頼できるネットワーク環境でのみご使用ください。
多くのブロードバンドネットワークでは、80、8080 などの一般的なポートがブロックされます。一般的なポートを接続できない場合は、人気のないポートを試してください。

方法2：FN Connectリモートアクセスサービス

FN Connect は、Feiniu が提供するリモートアクセスサービスです。
使用後は、Feiniu NAS を識別し、対応する方法でリモートアクセスを有効にするために使用される一意の FN ID を取得します。

注意事項

FN Connectを使用するには、Feiniuアカウントに登録またはログインする必要があります。
FN Connect は、HTTPS 経由で安全にアクセスできる、FN ID に対応するサブドメイン名の SSL 証明書を提供します。
FN Connectは、現在のネットワーク環境に基づいて、より適切な接続方法を自動的に選択します。
パブリックネットワーク直接接続が利用可能な場合、Web ページはパブリックネットワーク IP 直接接続を使用するかどうかを選択できます。
FN Connect のリレー転送にはトラフィックコストが発生するため、レート制限ポリシーが存在します。

2 つの方法の比較

维度	公网 IP 直连	FN Connect
上手难度	需要公网 IP + 路由器端口转发	登录账号后按引导配置，门槛更低
访问速度	通常更快、链路更直接	直连时接近直连；中继时可能限速
安全性	取决于你自己的证书与暴露策略	默认支持证书，HTTPS 访问更省心，依赖于飞牛本身的安全
维护成本	需要自行维护网络与安全配置	日常维护成本较低
适合人群	有网络配置经验、追求性能	追求易用与稳定的普通用户

提案を選択する

ネットワーク構成に精通していて、より高い帯域幅とより低い遅延が必要な場合は、パブリック IP 直接接続を優先してください。
使いやすさと安全なアクセス体験を重視する場合は、FN Connect を優先してください。
実際の使用では、FN Connect がデフォルトであり、条件が許せばパブリック IP 直接接続に切り替えるなど、混合することができます。

Ubuntu で Let's Encrypt 証明書を自動的に更新する (Certbot + Nginx)

Thu, 02 Apr 2026 00:00:00 +0000

Let’s Encrypt 証明書の有効期限は 90 日間のみです。オンラインサイトでは、証明書の有効期限切れによる HTTPS エラーを回避するために自動更新を構成する必要があります。

crontabを手動で追加する(推奨例)

更新タスクを自分で明示的に管理したい場合は、root ユーザーとして追加します。

`1`	`sudo crontab -e`

次の行を追加します (毎日午前 3 時に 1 回実行)。

`1`	`0 3 * * * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" >> /tmp/certbot-renew.log 2>&1`

このコマンドの意味は次のとおりです。

0 3 * * *: 毎日 03:00 に実行
certbot renew: 有効期限が近づいている証明書を確認して更新します (実際には毎日更新されるわけではありません)。
--pre-hook: 80/443 ポートの競合を避けるために、更新前に Nginx を停止します (スタンドアロンモードで一般的)
--post-hook: 更新後のNginxの起動
>> /tmp/certbot-renew.log 2>&1: トラブルシューティングを容易にするためにログをファイルに追加します

最初に更新のシミュレーションを行うことをお勧めします

スケジュールされたタスクを追加した後、まずプロセスが利用可能かどうかを手動で確認します。

`1`	`sudo certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" --dry-run`

シミュレーションが正常に更新されたことを確認した後、長期実行のためにスケジュールされたタスクに渡されます。

共通の注意点

webroot または nginx プラグインを使用している場合、多くのシナリオで Nginx を停止する必要はありません。代わりに、更新後に構成をリロードすることもできます。

`1`	`certbot renew --deploy-hook "systemctl reload nginx"`

certbot renew は、証明書の有効期限が近づいた場合にのみ実際の更新を実行するため、1 日に 1 回実行するのが通常の一般的な方法です。
長期的な運用とメンテナンスを容易にするために、ログディレクトリを長期的に追跡可能な場所 (/var/log/letsencrypt/ など) に変更することをお勧めします。

運用・保守 on KnightLiブログ

2026年の Linux サーバー向けディストリビューション選び：Debian、Rocky Linux、AlmaLinux、Ubuntu Server 比較

早見表

Debian：岩のような安定性

Rocky Linux：CentOS 後の堅実な代替

AlmaLinux：より能動的な RHEL 互換ルート

Ubuntu Server：クラウド対応とデプロイ効率が最も強い

四つをどう選ぶか

個人 VPS / 自ホスト

企業本番環境

クラウドネイティブとコンテナホスト

AI / GPU サーバー

伝統的な業務システム

選ぶ前に見るべき指標

私のおすすめ構成

短い結論

関連リンク

Nginx のレート制限設定：高頻度の 404・400 スキャンリクエストに rate limit をかける

基本方針

まず http でレート制限用 zone を定義する

次に server で zone を使う

各パラメータの意味

burst と nodelay の考え方

よくあるエラー：limit_req_zone の配置場所が違う

明らかに異常な IP を一時的に拒否する

チェックしてリロードする

推奨パラメータ

Ubuntu 26.04 LTS の GPU とハードウェア対応アップデート: CUDA、ROCm、DPC++、そして各種プラットフォームの変更

1. Intel DPC++ と関連コンポーネントが Ubuntu Archive に追加

2. NVIDIA CUDA toolkit も apt で直接導入可能に

3. AMD ROCm 7.1.0 が Universe に追加

4. 本当のポイントは 3 社の GPU エコシステムが同時に進んでいること

5. NVIDIA Dynamic Boost がデフォルトで有効化

6. 新しい Intel 内蔵 GPU / 外付け GPU のサポートも前進

7. Nvidia デスクトップのサスペンド復帰も安定化

8. ARM、Raspberry Pi、RISC-V、IBM Z でも要件変更がある

ARM64 デスクトッププラットフォーム

Raspberry Pi の新しいブートレイアウト

Raspberry Pi デスクトップイメージは desktop-minimal ベースに

Raspberry Pi の swap は cloud-init 管理に

RISC-V の要件が引き上げ

IBM Z の最低要件は z15 に

9. この内容を先に読むべき人

10. ひと言でまとめると

Ubuntu 26.04 LTS リリース：GNOME 50 と Linux 7.0 でデスクトップが大きく更新

1. まずは重要な更新を確認

2. 最大の変化その 1：GNOME 50 が LTS に入った

3. 最大の変化その 2：既定アプリが広く刷新された

4. 最大の変化その 3：Wayland が唯一のデスクトップセッションになった

5. 最大の変化その 4：Linux kernel 7.0 と低層スタックもまとめて更新

6. ハードウェア要件と導入の目安

7. どんな人に優先してアップグレード向きか

8. ひとことでまとめると

関連リンク

nftables フレームワークを理解する：テーブル、チェーン、ルール、セット

table：ルールの名前空間

family：ルールが対象にするプロトコル

chain：ルールが実行される場所

rule：マッチ条件とアクション

set：値の集合をまとめる

map：マッチした値を結果に変換する

verdict map：マッチした値をアクションに変換する

概念からルール設計を考える

まとめ

参考

nftables クイック入門：テーブル、チェーン、ルールとよく使う操作

基本構成

よく使うマッチ方法

単一端末の通信量を集計する

簡単な帯域制限

ルールの削除と整理

使い方のポイント

参考

go2rtc は Xiaomi カメラ RTSP に直接接続します。NVR、HomeKit、Frigate に接続します。

Docker のデプロイメント例

ストリーム構成例

画質とパラメータ

まとめ

参考リンク

Windows タスク マネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。

2. NVIDIA CUDA toolkit も `apt` で直接導入可能に

Windows タスクマネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。