古いノートPCでFedoraのXfceを導入するにはfdiskによる調整が必要

第3世代のCore i3を搭載したノートPCに、Fedora 45のXfce版をインストールしてみました。
古いノートPCはWindows11に対応していなかったり、使い道が無かったりするのですが、Fedoraのデスクトップ環境の中でも、比較的軽量なXfceを選択すれば、動画の再生やRDPのクライアントとしても使い勝手のよいPCの生まれ変わることができます。

しかしながら、Xfceの導入段階において、一番苦労したのは最初のインストール作業です。

通常のインストール方法では、パーティションテーブルがGPT形式で作成されます。
ところが、古いPCではマザーボードがGPT形式での起動に対応しておらず、そのままでは起動できませんでした。

そこで、事前に手動でパーティションを作成し、GPT形式ではなくMBR形式にする必要があります。

1.LiveCDからパーティションを作成

まず、Xfce版FedoraのDVDを作成し、LiveCDとして起動します。

起動後、端末からfdiskを実行して、パーティションを作成します。

sudo fdisk /dev/sda
o
n
p
1
[Enterのみ](最初のセクタ)
+1G
n
p
2
[Enterのみ](最初のセクタ)
+8G
n
p
3
[Enterのみ](最初のセクタ)
[Enterのみ](最後のセクタ)
t
2
82
a
1
w

これで、MBR形式のパーティションテーブルが作成され、以下のように区切られます。

パーティションマウント先サイズフォーマット形式
/dev/sda1/boot1GBext4(MBR,DOS)
/dev/sda2Swap8GBLinux Swap
/dev/sda3/(root)残り全部Btrfs

(参考:RJC社Techチーム「MBRとGPTの違い|確認方法・2TBの壁・変換の注意を実機で」)

2.Fedoraのインストール

パーティションの作成が終わったら、デスクトップにある「Install to Hard Drive」をクリックして、インストールを開始します。

インストール先の設定では、手動でパーティションを設定する方法を選択します。

ここで注意したいのが、「どのようにインストールしますか?」という画面です。

「ディスク全体」を選択するのではなく、次の項目をクリックします。

「If none of the options above apply, use the storage editor to create a custom partitioning before proceeding.」

これを選択すると、ストレージエディターで手動設定ができるようになります。

先ほど作成したパーティションについて、それぞれマウント先とフォーマット形式を上記の表のとおりに設定します。

この設定でインストールを進めたところ、無事に起動することができました。

(参考:作者不明「Fedora – 45 – 共通事項 – インストール」)

Fedora45のリリースとアップデート

Fedora 45は、PHPの脆弱性(CVE-2026-109618、CVE-2026-109619:PHP2shell、 参考:情報処理推進機構「PHPの脆弱性対策について」)の影響か、あるいはLinuxカーネルのTCPの脆弱性(CVE-2026-98432 参考:piyolog「Linuxカーネルの脆弱性 CVE-2026-98432 についてまとめてみた」)の影響かはわかりませんが、リリースのスケジュールが延期となっていました。
先日ようやくリリースされたため、メインサーバーとサブサーバーをFedora 45にアップデートしました。

方法は以下のとおりです。

まずは、Fedora 44で最終アップデートを行い、必要に応じて(カーネルのアップデートがある場合などは)再起動します。

dnf upgrade --refresh -y
reboot -n

次に、Fedora 45をダウンロードして、PGPを確認します。

dnf system-upgrade download --releasever=45

PGPは以下のサイトで確認します。 「Fedora Keeps You Safe」

そして、アップデートを実行します。

dnf5 offline reboot

アップデート後の状況として、WordPressのバージョンが6.9系から7.1系に変更されたため、データベースのアップデートが行われました。
Nextcloudに関しては特に変化はありませんでした(通常のアップデートと同じ作業です)。


また、アップデート後に不具合が発生しました。Webログ管理ツールの「awstats」がFedora 44用のままになっていたため、Fedora 45のSELinuxポリシーとの間で不整合が生じたことです。

状況を確認すると、以下の通りパッケージがfc44のままでした。

dnf list --installed awstats
# 出力結果:awstats.noarch 8.x-x.fc44 updates

この対処として、エラーが出た後に手動でポリシーモジュールを作成し、インストールしました。

sudo ausearch -m AVC -c awstats.pl -ts today | audit2allow -M awstats_local
sudo semodule -i awstats_local.pp

インストール後、以下のコマンドでポリシーが適用されたか確認します。

sudo semodule -l | grep awstats_local

運用していく中で、他に何かあれば、その都度対応して情報を共有する予定です。

PHPの大騒動とFedoraでのアップデート

世間的には令和8年10月21日午後11時の段階で、外部サーバー類のWebを使ったプログラムとして多く利用されているPHPの緊急メンテナンスをするよう告知がありました。
(参考:piyolog「PHPの2件の深刻な脆弱性(CVE-2026-109618、CVE-2026-109619)についてまとめてみた」)

FedoraでWordpressを利用している当サーバーもPHPのアップデートが必要となり、緊急メンテナンスを実施。

公式のリポジトリでは、PHPのアップデートが間に合わないため、Koji(ビルドパッケージ)からダウンロードしました。以下はその手順です。

1. Kojiをインストール

dnf install koji

2. RPMを取得

mkdir -p ~/php-8.5.12
cd ~/php-8.5.12
koji download-build --arch=x86_64 php-8.5.12-1.fc44

3. 取得したRPMを確認

ls -lh *.rpm

4. 更新内容を事前確認

dnf upgrade ./*.rpm --assumeno

問題がなければ、次へ進みます。

5. PHPを更新

dnf upgrade ./*.rpm

6. PHPのバージョンを確認

php -v
rpm -q php php-common php-cli php-fpm

PHPが「8.5.12-1.fc44」 になっていれば完了です。

追記、令和8年10月23日現在で、dnfによる公式のリポジトリでアップデートできるようになっています。

Sambaサーバーの遅延対策とRsyncによるバックアップの改善

Sambaは、WindowsとLinuxのファイルシステムをつなぐ重要なサーバー機能ですが、最近、一部のSambaサーバーで遅延が発生し、Windows端末での操作に支障が出ることがありました。

Sambaのアップデートでは、古いSMBプロトコルや認証方式の扱いが変更されることがあります。事務所では、古いスキャナーやプリンターなどを接続していることもあり、設定変更には慎重になります。

今回、実際に発生した問題について、2点変更したところ改善しました。

1.Rsyncのパーミッションエラー

Windowsにはrobocopyがありますが、差分バックアップではRsyncも比較的高速で便利です。当事務所では、RsyncとFedoraサーバーへのSSH接続のためにCygwinを利用しています。

Rsyncでは、

rsync --delete -t -v -r --perms /cygdrive/c/path //Sambaserver/backup-path

としていましたが、Sambaサーバー側でパーミッションのエラーが発生しました。

そこで、

--perms

を

--no-perms

に変更したところ、正常にバックアップできるようになりました。

--permsは転送元のパーミッションを転送先にも設定するオプションです。バックアップ先でパーミッションを再現する必要がなければ、--no-permsで問題ありません。

  1. 不要なサーバーではNT1を無効にする

古い機器との互換性のため、SambaでSMB1(NT1)を許可している場合があります。

今回、古い機器と接続する必要のないSambaサーバーについて、

;server min protocol = NT1
;ntlm auth = yes

として、これらの設定を無効にしました。

その結果、Windows端末からSambaサーバー上のテキストファイルを開く際などに発生していた遅延が改善しました。

ただし、古いスキャナー、プリンター、スマートフォンなどが接続されている場合は注意が必要です。設定変更後に、それらの機器からSambaサーバーを利用できるか確認した方が安全です。

今回、

  • Rsyncの--permsを--no-permsに変更
  • 不要なSambaサーバーでSMB1(NT1)を無効化

したところ、バックアップが正常に動作し、Windows端末からのファイル操作も改善しました。

古い機器との互換性が必要な環境では無理に設定を変更する必要はありませんが、必要のないサーバーまで古いプロトコルを有効にしておく必要もありません。
接続する機器に応じて、設定を分けておくことが重要だと思います。

サイトの閲覧障害と復旧について

ここ2日間ほど、サイトが閲覧できない状態となっておりました。

原因はWordPressのデータベース故障によるものです

現在は、過去のバックアップデータを用いて復旧作業を完了しております。

アクセスログやサーバーのメッセージログを確認し、障害が発生したタイミングは特定できましたが、根本的な原因については現在も調査中です。

再発防止に向けて、引き続き確認を進めていきます。

WordPressの緊急アップデートと脆弱性

たまにWordPressで重要な脆弱性が発見されることがあります。
WordPressは、利用者数が非常に多いため、どうしてもハッカーに狙われやすいという面があり、セキュリティの手を緩めることができません。

Fedoraサーバーを利用している場合、公式パッケージの更新が脆弱性公開に追いつかず、対応が遅れることがあります。
今回は緊急の脆弱性のようで、執筆時点ではFedoraパッケージではまだ対応されていないようです。

今回の内容については、piyokango氏のブログに早速情報がまとめられていました。
(参考:「WordPress Coreの脆弱性 CVE-2026-63030 / CVE-2026-60137 (通称「wp2shell」)についてまとめてみた」)

また、バージョンが対応済みかどうかを判定できるサイトもありました。
Searchlight Cyber「wp2shell: Pre Authentication RCE in WordPress Core」(脆弱性チェッカー・緩和策プラグイン公開ページ)

対応手順

Fedoraのdnfによるアップデートがまだ提供されていない場合は、Fedoraで提供されている更新用RPM(noarch.rpm)を利用して更新します。

1.バックアップの取得

作業前に、万一に備えてWordPressフォルダ全体をバックアップしてください。

tar -czf wordpress-backup-$(date +%Y%m%d).tar.gz /path/to/wordpress

また、必要に応じてデータベースもバックアップしてください。

2.更新用RPM(noarch.rpm)のダウンロード

Fedoraのパッケージサイト又はミラーサイトから、WordPressの更新用RPM(noarch.rpm)をダウンロードします。
(場所: Information for build wordpress-6.9.5-1.fc44)

※ src.rpm(ソースRPM)では更新できませんので、noarch.rpmを使用してください。

3.RPMによる更新

ダウンロードしたディレクトリで、次のコマンドを実行します。

dnf install ./wordpress-6.9.5-1.fc44.noarch.rpm

既にインストールされている場合でも、新しいバージョンへ更新されます。

更新後は、次のコマンドでバージョンを確認できます。

rpm -qi wordpress

又は

rpm -q wordpress

4.動作確認

WebブラウザからWordPressへアクセスし、正常に表示されることを確認してください。

更新後にパーミッションやSELinuxの問題でエラーが発生した場合は、必要に応じて次のコマンドを実行します。

restorecon -Rv /path/to/wordpress

また、Apacheのエラーログも確認してください。

journalctl -u httpd

Fedoraのリポジトリで更新版が提供されるようになれば、通常どおり

dnf upgrade wordpress

で管理することができます。

秘密保持重視から、オフラインの生成AIツールの利用

生成AIは、文書添削に非常に便利なツールですが、利用にあたっては
以下の点に注意が必要とされています。

・出力内容がニュアンスによって変化し、意図と異なる結論になる場合がある
・入力データに顧客情報や個人情報が含まれるリスクがある

特に法的文書を扱う場面では、いずれも重大な問題です。とりわけ、
個人情報等を生成AIにそのまま入力することは、顧客の同意がある場合
であっても、サービス側でどのように利用・学習されるか不明であり、
安易に行うべきではありません。

そのため、法律職が個人情報を扱う場合は、生成AIサービスのうち、
入力データをインターネットに通信しない、ローカル環境(オンプレミスサーバー等)
にインストールするタイプのものを利用する方が望ましいでしょう。

こうした形態は「ローカルLLM」と呼ばれ(参考:富士フイルムビジネス
イノベーション社「ローカルLLMとは?〜」)、現在利用可能な主な構成
としては、以下のようなものがあります。

・Ollama × gemma4
・Ollama × gpt-oss
・LM Studio × gemma、Qwen 等

なお、ローカルLLMはモデルデータだけでも数GB以上の容量があり、
快適に動作させるには高性能なグラフィックボード(GPU)が必要です。
これは生成AIの推論に、CPUやメモリに加え、GPUの並列計算機能が
不可欠であるためですが、近年のAI需要拡大によりメモリ関連デバイス
の価格が上昇しており、機器調達は容易ではありません。

しかし、生成AIを業務で活用する以上、データセンター等の契約サーバー
を除き、セキュリティ確保の観点から、こうした機器類を自前で整備
する必要があります。昨今の生成AI利用には、相応の費用と手間が
伴うのが現状のようです。

Fedora43→44にアップデート

当事務所のメインサーバー(クローズド環境)では、Fedoraを採用しています。このディストリビューションは、年2回程度のメジャーアップデートがあり、時期としては大型連休前後及び秋頃です。

今回もアップデートを実施しました。手順は以下のとおりです。

sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot

もっとも、アップデート後は動作検証を慎重に行う必要があります。不具合が発生すると業務に支障を来すおそれがあるためです。

前々回は、Popplerの仕様変更により登記情報の変換ができなくなり、対応に相当の工数を要しました。今回はそのような問題が生じないことを願うばかりです。

セキュリティ対策として SPF・DMARC を導入

いわゆる電子メールの仕組みは,昔ながらの POP3 や SMTP というプロトコルの上に成り立っています。
とても便利な一方で,セキュリティ面ではどうしても古い部分が残っており,大量送信が容易なことから,不正な攻撃に悪用されてしまうことがあるようです。

最近では,認証情報を狙った不審メールを大量に送り続けるタイプの攻撃が増えているとの報道もあります。
(参考:日本経済新聞「世界の不審メール7億通、8割は日本標的」)

こうした状況を受けて,特に Gmail や携帯キャリアのメールでは強力なフィルタが導入されています。
しかしながら,仕組みの詳細が公開されているわけではなく,システム管理者にとっては「どこで弾かれているのか分からない」状況になることも多いのが実情です。

Gmail では,SPF レコードや DKIM,DMARC といった認証技術の導入を強く推奨しているようです。
(参考:Google「認証方法について(管理者向け)メール認証の基本を学ぶ」)

当事務所でも,外部への送信メールを一部システムで利用していることから,今回は SPF レコードと DMARC の設定を行いました。

参考にしたのは次のサイトです。

設定後,オープン側のサーバー(基幹サーバーではありません)から送信したメールについて,SPF も DMARC も「PASS」と判定されるようになりました。これにより,Gmail やスマホキャリア宛ての返信メールでも,これまでより安定して届くようになったと思います。

今後もセキュリティへの配慮を続けながら,メールシステムの安定運用に努めていきます。

↓設定実施前のgmailのメールソース

↓設定実施後のgmailのメールソース