カテゴリー: Linux

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

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

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

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

１．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端末からのファイル操作も改善しました。

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

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

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

原因は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）を利用して更新します。

１．バックアップの取得

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

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

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

２．更新用RPM（noarch.rpm）のダウンロード

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

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

３．RPMによる更新

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

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

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

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

rpm -qi wordpress

又は

rpm -q wordpress

４．動作確認

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

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

restorecon -Rv /path/to/wordpress

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

journalctl -u httpd

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

dnf upgrade wordpress

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

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

生成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を採用しています。このディストリビューションは、年２回程度のメジャーアップデートがあり、時期としては大型連休前後及び秋頃です。

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

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のメールソース

想定外のPoppler更新で大混乱：登記情報変換の再構築記

弊所ではこれまで，登記情報等の PDF を変換する手段として，Fedora に含まれる Poppler の「pdftohtml」を利用していました。
しかし，変換時の不具合が発生したため，「pdftotext」へ切り替えることにしました。

この変更により，PDF→html に変換したうえで bash で文字操作を行っていた従来の仕組みを，PDF→テキスト（平文）へ変換してから処理する方式に改めました。

html とテキストでは性質が大きく異なります。
タグがなく，レイアウトの概念もないため，テキストの並び順や内容，さらには PDF の線の位置などから判断して精査する必要があります。

実際に確認してみると，土地や一般建物については情報の位置がほぼ一定で，それほど手間はかかりません。
一方，区分建物と会社登記はレイアウトや内容が多様であり，土地・一般建物に比べて複数のパターンに対応しなければならず，処理が複雑になりました。

さらに，テキスト精査は html を扱う場合よりも文字位置が安定せず，どうしても内容を逐一確認しながら処理する形となります。
そのため，bash の cut などの単純な文字操作では対応しきれず，変数展開を多用することになり，結果として処理速度も低下しました。

こうした調整を重ね，ようやく新しい登記情報変換システムが形になりました。
今後は，変換後のデータに誤りがないか確認しつつ，業務で安定して使えるよう整えていこうと思います。

登記情報から文字を抽出するソフトによる不具合

Fedora42 から 43 にアップデートした際，「pdftohtml」を含む Poppler が同時に 24.x から 25.x へ更新されました。
通常であれば特に問題は生じませんが，登記情報の PDF を html に変換したところ，書式が大きく変わってしまいました。

アップデート前

┏━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓&#160;<br/>　　　┃専有部分の家屋番号│７１０－１　～　７１０－４４　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┃&#160;<br/>　　　┠─────────┴─────────────┬──┬───────────┬─────┬───────────┨&#160;<br/>　　　┃　表　　題　　部　　（一棟の建物の表示）　　　│調製│平成８年７月１１日　　│所在図番号│　　　　　　　　┃&#160;<br/>

アップデート後

┏━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓<br/>　　　┃専有部分の家屋番号│７１０－１　～　７１０－４４　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┃<br/>　　　┠─────────┴─────────────┬──┬───────────┬─────┬───────────┨<br/>　　　┃　表　　題　　部　　（一棟の建物の表示）　　　│調製│平成８年７月１１日　　│所在図番号│　　　　　　　　┃<br/>
　　　

レイアウトが変わっただけでなく，アンダーバーを含む文字が取り込めなくなるなど，変換精度に影響が出ています。

これにより，申請書・委任状・各種物件データや役員データの管理で使用していた自作の変換ソフトが，文字数やタグ構造の変更にまったく対応できなくなりました。
仕様変更は避けられず，作業全体の見直しを迫られています。

そこで，変換手段を「pdftohtml」から「pdftotext」に切り替えることにしました。
ただ，「pdftotext」では登記情報特有の全角スペースがうまく変換されず，従来の「文字数で位置を特定する方法」が使えなくなりました。結果として，線やレイアウトを手がかりに判定する方式へ移行せざるを得ません。

一日でも早く状況に対応し，システムを復旧させたいところです。

Fedora42→Fedora43

２０２５年１０月２８日に Fedora 43 がリリースされたため，メインサーバー（クローズド環境）を早速アップデートしました。

手順は次のとおりです。

#事前準備
dnf upgrade --refresh
reboot -n

#ダウンロード
dnf system-upgrade download --releasever=43 --allowerasing
#(Fingerprintを確認)

#アップグレード実行
dnf system-upgrade reboot

アップグレード後，いつもどおり eFAX サーバーと Nextcloud の設定を再投入する必要がありましたが，
今回は dovecot（IMAP メール受信サーバー）で問題が発生しました。

dovecot が 2.3 から 2.4 にバージョンアップしたことにより，設定記述の方式が一部変更されています。
特に メールのパス指定 が変更されており，元の設定に戻す必要があります。

vi /etc/dovecot/dovecot.conf
mail_path = ~/mail
↓
本来のメールパス

また，「/etc/dovecot/conf.d」以下の 「10-mail.conf」 などの設定ファイルが削除または無効化されていました。
そのため，必要に応じて設定を再作成・再有効化する必要があります。
再作成する場合には，記述方法がver2.3とは異なっているので注意が必要です。
（参考　Dovecot CE「Upgrading Dovecot CE from 2.3 to 2.4」）

テキスト処理で一行目だけエラー？──原因は「BOM付きUTF-8」でした

先日，あるテキストファイルを使ってコマンド処理をしようとしたところ，一行目だけがどうしてもエラーになってしまうという現象に直面しました。

リストファイルの各行をもとにコマンドを生成し，コピペで実行しても一行目だけが動かない。
不思議に思い，最終的には一文字ずつ文字コードを調査して原因を特定するに至りました。

原因は「FEFF」──UTF-8のBOM

調査の結果，一行目の先頭に「FEFF」という不可視の文字コード（BOM: Byte Order Mark）が入っていることがわかりました。
この「FEFF」は，UTF-8でBOMありとして保存されたファイルの先頭に付く特殊なコードで，Linux系OS（Fedoraなど）では扱いに注意が必要です。

なぜBOMが入っていたのか？

使用していたクラウドソフトが，スマホ表示に対応するため標準でBOM付きUTF-8形式でテキストを記憶しなければならない仕様になっていたため，Windows側のテキストアプリケーションの設定で「BOMあり」ファイルを作ってしまっていたからです。

その結果，テキスト処理スクリプトやシェルコマンドなどが，一行目を正しく認識できなくなっていたというわけです。

対処法と今後の教訓

テキストエディタで保存形式を確認

・UTF-8（BOMなし）で保存できるようにエディタの設定を見直す

最後に

一見ただの文字列ファイルでも，見えないバイト列が処理を妨げていることがあるという良い教訓になりました。
今後も，テキスト処理を行う際には，BOMの有無や文字コードの確認を忘れずに対応していきたいと思います。

同じように「なぜか1行目だけエラーになる」などの不可解な現象でお悩みの方がいれば，ぜひBOM付きファイルでないか確認してみてください。