日: 2026年10月22日

BOSGAME E5 初期セットアップ記録 ――Ubuntu 26.04 LTS、four-mations出発準備

はじめに

シェイクスピアの悲劇を経て購入した、自宅サーバ用の小型PC、BOSGAME E5。

手元に届いた以上、いつまでも箱の中に置いておくわけにはいきません。

今回の目的地は、自室のローカルサーバ環境です。これまでLet's note CF-XZで運用していたNextcloudとAdGuard Homeを、より余裕のある環境へ移す。そのための第一歩として、まずはOSを入れ替え、SSHで管理できるところまで整えます。

導入するOSはUbuntu 26.04 LTS Desktop。

ホスト名は four-mations としました。

ここから先の作業は、まだ本番サービスの移行ではありません。まずは土台を作り、ネットワークを整え、手元の自宅NWから遠隔操作できる状態にします。

環境

項目設定内容
対象機器BOSGAME E5
CPUAMD Ryzen 3 5300U
メモリ16GB DDR4
ストレージ512GB NVMe SSD
導入OSUbuntu 26.04 LTS Desktop
ホスト名four-mations
有線インターフェースenp2s0
固定IPアドレス192.168.11.21/24
デフォルトゲートウェイ192.168.11.1
DNSサーバー192.168.11.1

さっくりとした手順

  1. Ubuntu 26.04 LTS Desktopをクリーンインストールします。
  2. システムパッケージを最新化します。
  3. OpenSSH Serverを導入し、リモート接続を確認します。
  4. 有線LANのIPアドレスを固定化します。
  5. IPアドレス、ルーティング、外部ネットワークへの疎通を検証します。

1. Windows 11 ProからUbuntuへ

1.1 ブートメディアから起動します

購入時のBOSGAME E5にはWindows 11 Proが導入されていました。

しかし、今回の用途は自室のローカルサーバです。Windows環境をそのまま使うのではなく、Ubuntuをクリーンインストールします。

Ubuntu 26.04 LTS DesktopのインストーラUSBを用意し、本体に接続します。

電源投入時に DEL を押してブートメニューを開き、USBメモリから起動します。キーは機器のファームウェア設定によって異なる場合があります。

1.2 既存のストレージを初期化します

インストーラの画面に従ってインストールを進め、インストールタイプでは「ディスクを削除してUbuntuをインストール」を選択します。

インストール先は、内蔵NVMe SSDの nvme0n1 です。

注意:この操作では既存のWindows環境と、対象ディスク上のデータが消去されます。 必要なデータが残っていないことを確認してから実行します。

1.3 ホスト名を設定します

初期アカウントの設定では、コンピュータ名を次のように指定しました。(本ブログのアイキャッチの顔になっている4パターン、5人のお姉さんたちのユニット名です)

four-mations

ユーザー名とパスワードを設定し、インストール完了後に再起動します。こうして、新しい自室サーバの土台ができました。

2. システムを最新化します

2.0 aptitudeを入れます。

これは完全に筆者の好みの問題。

sudo apt install aptitude

2.1 パッケージリストを更新します

初期起動後、ターミナルを開きます。

sudo aptitude update

2.2 インストール済みパッケージを更新します

sudo aptitude upgrade -y

OSを入れたら、まずはシステムを最新の状態に整えます。この先、SSHやネットワークの設定を行うにしても、最初に基本部分を整えておくのが順序というものです。

3. SSHで遠隔操作できるようにします

3.1 OpenSSH Serverを導入します

自室サーバとして運用する以上、毎回ディスプレイとキーボードを接続して操作するのは避けたいところです。

そこで、OpenSSH Serverを導入します。

sudo apt install -y openssh-server

3.2 SSHサービスを有効化します

sudo systemctl enable --now ssh

これで、システム起動時の自動起動と、現在のサービス起動を設定できます。

3.3 サービスの稼働状態を確認します

systemctl status ssh --no-pager

出力に Active: active (running) と表示されていれば、SSHサービスは稼働しています。

3.4 現在のIPアドレスを確認します

ip -br a

有線インターフェース enp2s0 に割り当てられているIPアドレスを確認します。

この段階ではDHCPによる自動割り当てです。実際に割り当てられたアドレスを確認し、クライアント端末から接続できる状態にします。

3.5 ローカルネットワークからSSH接続します

手元のPCなど、同じLANに接続したクライアント端末から実行します。

ssh <ユーザー名>@<現在のIPアドレス>

Windowsの場合はお好みのターミナルソフトを使ってください。

初回接続時にはホスト鍵の確認が表示される場合があります。接続先が正しいことを確認してから受け入れます。

ログインできれば、ひとまず本体にディスプレイやキーボードをつながなくても操作できるようになりました。

ここから先は、遠隔操作を基本に進められます。

4. 有線LANのIPアドレスを固定化します

4.1 固定IPを設定する前に

多くの企業や組織では、固定IPの競合や管理問題から、最初から固定IPを導入するパターンでしょうが、筆者は違います。「DHCPがリースしたIPは他のNW機器とIPが被りようがない」です。

なので、省力化を果たします。(省力化とは)ただし、ここは作業上の注意点があります。

SSH接続中にネットワーク設定を変更すると、接続が切れる可能性があります。 固定IPへの切り替え前に、現在の接続情報を控え、可能なら本体のローカルコンソールから復旧できる状態を確保しておきます。

4.2 アクティブな接続名を取得します

Ubuntu Desktopでは、NetworkManagerを利用してネットワーク接続を管理できます。

まず、有線インターフェース enp2s0 に対応するアクティブな接続名を取得します。

CON_NAME=$(nmcli -t -f DEVICE,NAME connection show --active | awk -F: '$1=="enp2s0"{print $2}')

取得した値を確認します。

echo "$CON_NAME"

Wired connection 1 や 有線接続 1 など、実際の接続名が表示されることを確認します。

何も表示されない場合は、設定を変更せず、インターフェースと接続状態を確認します。

4.3 固定IPアドレスを設定します

まず、IPアドレスを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.addresses 192.168.11.21/24

デフォルトゲートウェイを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.gateway 192.168.11.1

DNSサーバーを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.dns 192.168.11.1

IPアドレスの取得方式をDHCPから手動設定へ変更します。

sudo nmcli connection modify "$CON_NAME" ipv4.method manual

4.4 設定を反映します

接続設定を再適用します。

sudo nmcli connection up "$CON_NAME"

正常に反映されれば、Connection successfully activated などのメッセージが表示されます。

接続が切れた場合は、固定IPアドレスで再接続します。

ssh <ユーザー名>@192.168.11.21

接続できない場合は、本体のローカルコンソールからネットワーク設定を確認します。DHCPへ戻す場合は、対象の接続名を確認したうえで次の設定を適用します。

sudo nmcli connection modify "$CON_NAME" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
sudo nmcli connection up "$CON_NAME"

なお、これは対象接続のIPv4設定をDHCPへ戻す操作です。実行前に接続名が正しいことを確認します。

5. ネットワーク設定を検証します

5.1 IPアドレスとインターフェース状態を確認します

ip -br a

enp2s0 が UP となり、192.168.11.21/24 が割り当てられていることを確認します。

5.2 ルーティングテーブルを確認します

ip route

出力例は次のとおりです。

default via 192.168.11.1 dev enp2s0 proto static metric 100
192.168.11.0/24 dev enp2s0 proto kernel scope link src 192.168.11.21 metric 100

デフォルトルートが 192.168.11.1 を向き、送信元アドレスとして 192.168.11.21 が使われていることを確認します。

5.3 IPアドレスを指定して疎通を確認します

ping -c 3 1.1.1.1

応答が返れば、少なくとも指定した外部IPアドレスへの通信ができています。

ネットワーク環境によってはICMPが制限される場合もあるため、応答がない場合は、この結果だけでネットワーク全体の障害と判断しないようにします。

5.4 DNSによる名前解決を確認します

getent hosts google.com

IPアドレスが返れば、名前解決ができています。

続けて、必要に応じて次のコマンドでも確認します。

ping -c 3 google.com

こちらは名前解決に加え、相手からICMP応答が返ることも確認するものです。名前解決が成功しても、ICMPが制限されていれば応答が返らない場合があります。

おわりに

これで、BOSGAME E5の初期セットアップはひとまず完了です。

Ubuntu 26.04 LTS Desktopを導入し、ホスト名を four-mations に設定。SSHで遠隔操作できるようにし、有線LANのIPアドレスを固定化しました。

まだNextcloudもAdGuard Homeも移行していません。今回整えたのは、あくまでそのための土台です。

しかし、これで自室の新しいサーバを構築する準備が整いました。

次は、既存環境の設定やデータを確認しながら、サービスの移行と動作検証を進めていきます。

ピボット旅行2026-18『神様お願い!』

この言葉にピンと来た方は、グループ・サウンズの大御所、ザ・テンプターズの曲、あるいはそれをカバーした桃姫BAND(尾崎亜美)のタイトルを思い出すかもしれません。

しかし、筆者にとってこの言葉は、アニメ『かみちゅ!』のサブタイトルになります。

はじめに

筆者がこの旅を決めてから、プレイリストにぶち込んだ曲があります。

このタイトルにある『神様お願い!』を筆頭として、

  • 青春のいじわる
  • 野性時代
  • 時の河を越えて
  • 君に決定

そう、アニメ『かみちゅ!』のサブタイトルに使われていた曲です。

これらのサブタイトルは、1980年代のアイドルソングなどから取られています。タイトルだけを並べれば、当時の音楽に詳しい方なら別の景色が浮かぶかもしれません。

筆者の場合は、これらをAmazon Musicのプレイリストに放り込むところから、今回の旅が始まりました。

尾道を歩き、作品の舞台となった場所を訪れる。そのための準備として、まずは音楽から作品の世界に入っていくわけです。

……我ながら、ずいぶんと回りくどい準備運動です。

筆者にとっての『かみちゅ!』

以前の断章でも触れたとおり、筆者にとって尾道は、単にアニメの舞台だから訪れたい町ではありません。

そもそも、筆者が尾道という町を知り、実際にその空気を感じた後で『かみちゅ!』に出会っています。

作中では、中学生の一橋ゆりえが突然神様になってしまいます。けれども、物語の中心にあるのは、神様になったことによる壮大な冒険ばかりではありません。学校に通い、友人と過ごし、町を歩く。そんな日常の中に、神様や不思議な出来事が自然に溶け込んでいます。

この世界観が、実際に歩いた尾道の町と重なりました。

筆者にとって『かみちゅ!』は、作品を見てから舞台を訪ねたというよりも、先に五感で記憶していた町が、作品を通じてもう一度つながったような存在です。

だからこそ、今回の旅行で自転車を置いていく判断をしたのは、断腸の思いでした。自転車で尾道を走ることも、もちろんやりたかったことです。

しかし、今回あらためて確かめたかったのは、自転車で走ることそのものではありません。尾道という町を歩き、以前訪れた場所にもう一度立つことでした。

そして、せっかく尾道に来たのですから、『かみちゅ!』の聖地も巡りたい。

今回の行程では、そんな筆者にとって外せない場所を3か所回ることにしました。

尾道で確実に行ける3つの聖地

福本渡船「神様御用達」のフェリー

まずは、福本渡船です。

『かみちゅ!』に登場する来福神社は、神様がいる神社として描かれています。その神様にゆかりのある場所を巡る旅で、渡船という存在を外すわけにはいきません。

尾道の町と向島を結ぶ渡船は、単に対岸へ移動するための交通手段ではありません。海を挟んで向かい合う町の景色と、そこを日常的に行き来する人々の暮らしをつなぐ存在です。

そして福本渡船は、多くの人々に惜しまれながら、その長い運航の歴史に幕を下ろしました。

今となっては、かつてのように船に乗ることはできません。それでも、尾道の風景と暮らしを形作ってきた渡船の記憶までなくなったわけではありません。

今回の聖地巡礼では、作品に描かれた世界と、現実の尾道の町が重なる場所として、この渡船を記録に残しておきたいと思いました。

御袖天満宮

続いて、御袖天満宮です。

『かみちゅ!』に登場する来福神社。その境内のモデルとなった場所です。

作中では、主人公の一橋ゆりえが神様となり、三枝祀(みこ)の実家でもある来福神社を中心に、さまざまな出来事が展開します。

その来福神社の境内に対応するのが、ここ御袖天満宮です。

そして、この場所にはもうひとつ、映画ファンにとってもおなじみの景色があります。映画『転校生』で、人格が入れ替わる場面に登場する石段です。

ひとつの場所に、異なる作品の記憶が重なっています。

『かみちゅ!』の舞台として見るなら、神様が暮らす神社の境内。『転校生』の舞台として見るなら、物語が大きく動く石段。

実際にその場に立つことで、作品の中で見ていた景色が、現実の町の中に存在していることを確かめられます。

艮神社

そして、艮神社です。

こちらは、来福神社の拝殿に対応する聖地です。

御袖天満宮が境内のモデルであるのに対し、艮神社は拝殿のモデル。この2か所を巡ることで、作中の来福神社が、現実の尾道にある複数の場所から形作られていることが分かります。

特に印象的なのは、『かみちゅ!』のオープニングです。艮神社の社殿は、タイトルロゴと重なる場所としても知られています。

作品を見ていたときには、ひとつの神社として目に入っていた景色。しかし、実際の場所を訪ねると、境内と拝殿という異なる要素が、それぞれ別の場所に対応していることに気づきます。

御袖天満宮と艮神社。どちらか一方だけではなく、両方を訪れることで、来福神社という架空の場所を立体的に捉えられるわけです。

神様にお願いした後は

こうして、福本渡船、御袖天満宮、艮神社と、今回訪れたかった3つの場所を巡ることができました。

作品の中でひとつの場所として描かれたものが、現実の尾道では複数の場所に分かれている。その違いを確かめながら歩くのも、聖地巡礼の楽しみです。

そして、今回の筆者には、もうひとつ大事な目的がありました。

先ほど、尾道焼きというメインイベントを完食したばかりです。

神様にお願いをした後は、歩いて腹ごなし。

……とはいえ、尾道の坂道と石段を巡れば、それだけで十分に運動になってしまうのですが。

こうして筆者は、作品の記憶をたどりながら、再び尾道の町を歩いていくのでした。

PHP「php2shell」脆弱性への恒久的対応:PHP8.3-FPMを更新した際のondrej/phpの一時的退避とロールバック

前項で書いた

「php2shell」(CVE-2026-109618、CVE-2026-109619)

への恒久的対応として、PPA提供の php8.3(バージョン 8.3.35)から、Ubuntu公式の修正版(8.3.6-0ubuntu0.24.04.13)へとロールバック・パッチ適用したときの作業メモです。

概要

Ubuntu 24.04 LTS(noble)環境において、php2shell 脆弱性への対応として Ubuntu 公式セキュリティリポジトリの PHP 修正版を適用しようとしたところ、サードパーティリポジトリのパッケージが優先され、通常のパッケージ更新では修正版へ切り替わらない事象が発生しました。

原因調査の結果、ppa:ondrej/php の PHP パッケージ(8.3.35)がインストール済みかつ更新候補として選択されていることを確認しました。APTの仕様上、バージョン番号が大きいPPA版が優先されていたため、PPAをパージして Ubuntu 公式パッケージへロールバックすることでパッチ適用を完了させました。

本記事では、発生した問題、原因調査、ロールバック手順、パッチ適用確認および復旧手順を記録します。

環境

  • OS:Ubuntu 24.04 LTS(noble)
  • 対象パッケージ:PHP 8.3
  • サードパーティリポジトリ:ppa:ondrej/php
  • ロールバック先:Ubuntu 公式セキュリティリポジトリ(noble-security)
  • PHP-FPM:php8.3-fpm
  • Webサーバー:Apache
  • 発生日時:2026年10月22日 02:54 JST
  • 関連事象:PHPパッケージ更新時にPPA側で503エラーが発生。PHP更新後にPHP-FPMおよびWebサイトの動作を検証。

さっくりとした手順

  1. PHPの脆弱性対応パッケージが更新されない事象を確認します。
  2. 一時的に Ubuntu 公式セキュリティリポジトリを直接参照する設定を追加して検証します。
  3. apt-cache policy で PHP のインストール済みバージョンと候補バージョンを確認します。
  4. ppa:ondrej/php のパッケージ(8.3.35)が更新を妨げていることを特定します。
  5. ppa-purge を導入し、PHP PPAをパージして公式パッケージへロールバックします。
  6. PHPのバージョンと関連パッケージを確認します。
  7. changelog から該当の CVE 修正パッチが含まれていることを確認します。
  8. PHP-FPMとWebサーバーを再起動します。
  9. PHP-FPMのソケット、拡張モジュール、Webサイトの応答を確認します。
  10. 一時的なAPT設定を整理し、必要に応じてPPAを再登録します。

特記事項

筆者の好みでaptitudeを用いています。必要に応じてaptに切り替えてください。

1. 発生した問題と初期事象

1.1. 脆弱性パッチが適用されない

php2shell 脆弱性への対応として、Ubuntu 公式セキュリティリポジトリ(noble-security)で配信される修正版パッケージを適用しようとしました。

しかし、以下のコマンドを実行しても、期待した PHP の更新が行われませんでした。

sudo aptitude update
sudo aptitude upgrade

一時的に security.ubuntu.com を直接参照する設定を追加して検証しましたが、更新対象として認識されない状態が続きました。

1.2. PPA側の応答遅延と503エラー

パッケージ更新を試みた際、ppa:ondrej/php 側の応答が一時的に滞り、リポジトリへのアクセスで 503 Service Unavailable が発生しました。

※この事象は、運用中のWebサイトで発生したエラーではなく、PHPパッケージの取得元である外部PPAサーバー側の応答遅延に関するものです。

PPA側の修正パッケージ配信を待たずに即時保護を図るため、Ubuntu公式セキュリティリポジトリの修正版へ切り替えるべく、PPAのパージによるロールバックを実施しました。

※これは緊急的な安全確保のための対処です。記事の後半に再び ppa:ondrej/php に戻す手順も記載しています※

2. 原因調査:APTの候補バージョンを確認

2.1. apt-cache policyを実行

apt-cache policy php8.3

実際の出力結果:

php8.3:
  インストールされているバージョン: 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  候補:               8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  バージョンテーブル:
 *** 8.3.35-1+ubuntu24.04.1+deb.sury.org+1 500
        500 [https://ppa.launchpadcontent.net/ondrej/php/ubuntu](https://ppa.launchpadcontent.net/ondrej/php/ubuntu) noble/main amd64 Packages
        100 /var/lib/dpkg/status
     8.3.6-0ubuntu0.24.04.13 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0ubuntu0.24.04.12 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0maysync1 500
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble/main amd64 Packages

2.2. 原因を特定

実測結果から、以下の状態を確認しました。

  • インストール済みバージョン:8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • APTの候補バージョン:同じく 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • Ubuntu公式セキュリティ版:8.3.6-0ubuntu0.24.04.13
  • PPA版と公式版のAPT優先度:いずれも 500

PPA版と公式版のAPT優先度は同じ(500)ですが、バージョン番号の比較(8.3.35 > 8.3.6)により、APTはPPA版を「より新しい最新版」と判定し、候補として固定していました。

その結果、Ubuntu公式セキュリティリポジトリに修正版が存在していても、APTからは「古いバージョンへのダウングレード」とみなされ、通常の更新では公式版への切り替えが行われない状態になっていました。

3. PPAのパージと公式パッケージへのロールバック

3.1. ppa-purgeをインストール

sudo aptitude install -y ppa-purge

3.2. PHP PPAをパージ

sudo ppa-purge ppa:ondrej/php

PPAを無効化し、関連パッケージを一括でUbuntu公式リポジトリのバージョン(8.3.6系列)へロールバックします。
※途中でパッケージの置き換えに関する確認([Y/n])が表示されたら、Y を入力して続行します。

3.3. 公式パッケージのインストール・整合性確保

ppa-purge の依存関係解決によって本体や FPM が外れてしまうケースを防ぐため、公式リポジトリから必要な主要パッケージが揃っていることを確実にします。

sudo aptitude install -y php8.3 php8.3-cli php8.3-fpm

→ ただし、実際に必要な PHP 拡張モジュールも別途確認してください。

php -v

実行結果:

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies

3.4. PHP関連パッケージの状態を確認

dpkg -l | grep php8.3

PHP本体、PHP-FPM、必要な拡張モジュールがすべて 8.3.6-0ubuntu0.24.04.13 に揃っていることを確認します。

3.5. 脆弱性に対応したパッチであることを確認

外部サーバーへの通信を行わず、ローカルに解凍された変更履歴から該当の CVE 修正を確認します。

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -C 10 "CVE-2026-109618"

確認結果:

php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      bailout in Zend/tests/bug40770.phpt, Zend/tests/bug54268.phpt,
      Zend/tests/bug76846.phpt,
...
      tests/basic/oom_rfc1867_upload_progress.phpt,
      tests/output/oom_in_internal_output_handler.phpt.
    - CVE-2026-109618
    - CVE-2026-109619

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 19 Oct 2026 11:16:58 -0400

パッチ(CVE-2026-109618_109619.patch)が確実に組み込まれていることを確認できました。

4. PHP-FPMとWebサーバーの復旧

4.1. PHP-FPMを再起動

sudo systemctl restart php8.3-fpm

4.2. PHP-FPMの稼働状態を確認

sudo systemctl status php8.3-fpm --no-pager

Active: active (running) となっていることを確認します。

4.3. Apacheを再起動

sudo systemctl restart apache2

Apacheが正常に稼働していることを確認します。

5. 動作検証

5.1. PHP-FPMのソケットを確認

ls -la /run/php/php8.3-fpm.sock

ソケットファイルが存在し、WebサーバーとPHP-FPM間の通信路が正常であることを確認します。

5.2. PHPの拡張モジュールを確認

php -m

アプリケーションで必要な拡張モジュールがロードされていることを確認します(mbstring, mysqli, xml, curl 等)。

※PPA削除時に外れたモジュールがある場合は、公式リポジトリから個別に追加します。

sudo aptitude install php8.3-<module_name>

5.3. Webサイトへのアクセスを確認

curl -I [https://example.com/](https://example.com/)

HTTPレスポンスを確認し、503 Service Unavailable や 502 Bad Gateway が発生せず正常(200 OK など)に応答することを確認します。ブラウザからも主要機能の動作を検証します。

6. PPAの再有効化

6.1. PPAを継続利用する場合の再登録

将来的にPPA側の修正パッケージが配信され、PPA環境へ復帰させる場合は以下の手順で再有効化します。

sudo add-apt-repository ppa:ondrej/php
sudo aptitude update

6.2. 再登録後の候補バージョン確認

apt-cache policy php8.3

PPA側で修正版(CVE対応済みビルド)が提供されていることを確認した上でアップグレードを実施します。

apt list --upgradable 2>/dev/null | grep php8.3
sudo aptitude upgrade

まとめ

今回の事象は、Ubuntu公式セキュリティリポジトリにパッチが配信されていたにもかかわらず、ppa:ondrej/php のパッケージ(8.3.35)がバージョン数値の優先度によってAPTの更新候補を占有していたことが原因でした。

apt-cache policy で優先度と候補を正確に把握し、緊急度に応じて ppa-purge による公式版への一時ロールバックを選択したことで、即座に脆弱性を塞ぎつつサービスの正常稼働を維持することができました。

Powered by WordPress & Theme by Anders Norén