2025/06/04(水)milter-manager は OpenDMARC を自動検出しない!

2025/06/04 4:57 サーバ運営・管理
最近気づいたんですが、Postfix 側の milter インタフェースも安定してきていて、
複数の milter を直感的に指定できるようになっていたり(当初から?)しているので、milter-manager を使う出番はそろそろ・・・
という状況ですが、一度にあれもこれもカスタマイズ出来ないので、milter-manager を使い続けているわけですが・・・

最初は、milter-manager 経由で動作させている OpenDKIM は機能しているのに、どう頑張っても OpenDMARC が付けてくれるはずのメールヘッダが一向に付かないので悩んでいました。
OpenDMARC を milter-manager 経由で稼働させている実績はどうやら一般的に皆無で、マイナーな milter なのか、と思ってたりしましたが・・・

そもそも、milter-manager に OpenDMARC milter が識別されているのかどうかになります。
なので、おもむろに
# /usr/local/sbin/milter-manager -u milter-manager --show-config
を実施すると・・・
# /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
define_milter("milter-opendkim") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:45
  milter.connection_spec = "local:/var/run/milteropendkim/dkim-milter"
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:38
  milter.enabled = true
  # default
  milter.fallback_status = "accept"
  # default
  milter.evaluation_mode = false
  # default
  milter.applicable_conditions = []
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:40
  milter.command = "/usr/local/etc/rc.d/milter-opendkim"
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:41
  milter.command_options = "start"
  # default
  milter.user_name = nil
  # default
  milter.connection_timeout = 297.0
  # default
  milter.writing_timeout = 7.0
  # default
  milter.reading_timeout = 7.0
  # default
  milter.end_of_message_timeout = 297.0
end
は、出てくるが、milter-opendmarc は出てきません。つまり、認識されていなかった。。orz...
ここから、自動認識させるための試行錯誤が始まります。

先ず、/usr/local/etc/milter-manager/defaults/freebsd.conf を修正してみます:
33行目あたりに、
  ["clamav-milter", []],
  ["milter-dkim", []],
  ["milter-opendkim", []],
  [
    "spamass-milter",
    [
      "Remote Network",
      "Unauthenticated",
      "No Stress",
    ],
  ],
とあるので、["milter-dkim", []] とある行の下に、 ["milter-opendmarc", []], を追加し、
  ["clamav-milter", []],
  ["milter-dkim", []],
  ["milter-opendkim", []],
  ["milter-opendmarc", []],
  [
    "spamass-milter",
    [
      "Remote Network",
      "Unauthenticated",
      "No Stress",
    ],
  ],
のようにします。これで、
# /usr/local/sbin/milter-manager -u milter-manager --show-config
を実施すると、"milter-opendmarc" は識別されるようになりました。
注意点としては、FreeBSD の場合、/usr/local/etc/rc.d 配下のスクリプトファイル名を milter-opendmarc にし、実行権を与えておくようにしておくことが必須です。

これで解決か?と思ったんですが、
今度はメールを受信する度に /var/log/maillog に
milter-manager[53830]: [egg][error] must set connection spec: milter-opendmarc
という、エラーが出て OpenDMARCは動作しません。再び、
# /usr/local/sbin/milter-manager -u milter-manager --show-config
とすると、
# /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
define_milter("milter-opendmarc") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:45
  milter.connection_spec = nil ← 注目
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:38
  milter.enabled = true
  ・・・・
要するに、milter-manager からは、接続先不明状態という状況。
幸いにも OpenDKIM が機能しているので、これを手掛かりに 自動検出スクリプトの修正を行いました。。。

先ず、/usr/local/lib/milter-manager/binding/lib/milter/manager にディレクトリを移動します:
修正したのは、
detector.rb
freebsd-rc-detector.rb
の2つ。新規に opendkim-config-parser.rb を参考に、 opendmarc-config-parser.rb を追加で作成しています。
結構あちこち修正したので、差分を提示しておきます。
1) detector.rb
--- detector.rb.old 2024-08-12 05:01:29.000000000 +0900
+++ detector.rb.new 2025-06-03 23:53:01.772724000 +0900
@@ -16,6 +16,7 @@
 require 'milter/manager/clamav-milter-config-parser'
 require 'milter/manager/milter-greylist-config-parser'
 require 'milter/manager/opendkim-config-parser'
+require 'milter/manager/opendmarc-config-parser'
 require 'milter/manager/rmilter-socket-detector'
 require 'milter/manager/rspamd-proxy-detector'

@@ -85,6 +86,10 @@
       opendkim_config_parser.socket
     end

+    def detect_opendmarc_connection_spec
+      opendmarc_config_parser.socket
+    end
+
     def detect_rmilter_connection_spec
       Milter::Manager::RmilterSocketDetector.new(rmilter_conf).detect
     end
@@ -138,6 +143,7 @@
       @clamav_milter_config_parser = nil
       @milter_greylist_config_parser = nil
       @opendkim_config_parser = nil
+      @opendmarc_config_parser = nil
     end

     def set_variable(name, unnormalized_value)
@@ -265,5 +271,14 @@
       end
       @opendkim_config_parser
     end
+
+    def opendmarc_config_parser
+      if @opendmarc_config_parser.nil?
+        @opendmarc_config_parser = Milter::Manager::OpenDMARCConfigParser.new
+        @opendmarc_config_parser.parse(opendmarc_conf)
+      end
+      @opendmarc_config_parser
+    end
+
   end
 end
2)freebsd-rc-detector.rb
--- freebsd-rc-detector.rb.old  2024-08-12 05:01:29.000000000 +0900
+++ freebsd-rc-detector.rb.new  2025-06-04 00:05:45.417658000 +0900
@@ -55,6 +55,10 @@
       @script_name == "milter-opendkim" or @name == "milteropendkim"
     end

+    def opendmarc?
+      @script_name == "milter-opendmarc" or @name == "milteropendmarc"
+    end
+
     def detect_rmilter_connection_spec
       Milter::Manager::RmilterSocketDetector.new(rmilter_conf).detect
     end
@@ -92,6 +96,12 @@
         "/usr/local/etc/opendkim.conf"
     end

+    def opendmarc_conf
+      @variables["cfgfile"] ||
+        extract_parameter_from_flags(command_args, "-C") ||
+        "/usr/local/etc/opendmarc.conf"
+    end
+
     def rmilter_conf
       extract_parameter_from_flags(command_args, "-c") ||
         "/usr/local/etc/rmilter.conf"
@@ -111,6 +121,7 @@
       spec ||= detect_enma_connection_spec if enma?
       spec ||= detect_clamav_milter_connection_spec if clamav_milter?
       spec ||= detect_opendkim_connection_spec if opendkim?
+      spec ||= detect_opendmarc_connection_spec if opendmarc?
       spec ||= detect_rmilter_connection_spec if rmilter?
       spec ||= detect_rspamd_proxy_connection_spec if rspamd?
       spec
@@ -141,6 +152,17 @@
           detector.detect
           detector.apply(loader)
         end
+      end
+      if opendmarc? and _profiles and !_profiles.empty?
+        _profiles.each do |profile|
+          detector = FreeBSDRCProfileDetector.new(@configuration,
+                                                  @script_name,
+                                                  profile,
+                                                  self,
+                                                  &@connection_spec_detector)
+          detector.detect
+          detector.apply(loader)
+        end
       else
         super
       end
@@ -206,6 +228,10 @@
     end

     def detect_opendkim_connection_spec
+      super || @base_variables["socket"]
+    end
+
+    def detect_opendmarc_connection_spec
       super || @base_variables["socket"]
     end
3)opendmarc-config-parser.rb
  opendkim-config-parser.rb をコピーし、下記の修正です:
--- opendkim-config-parser.rb   2025-05-26 02:31:08.119826000 +0900
+++ opendmarc-config-parser.rb  2025-06-03 23:47:40.989538000 +0900
@@ -16,7 +16,7 @@
 require "milter/manager/file-reader"

 module Milter::Manager
-  class OpenDKIMConfigParser
+  class OpenDMARCConfigParser
     def initialize
       @variables = {}
     end
当方は、ruby は殆ど扱った経験は無いので、「見よう見真似」と「推測」で修正しており、実際はもっと小規模な修正で出来るかもしれませんし、更なる修正が必要かもしれません。

上記の修正後、
# /usr/local/sbin/milter-manager -u milter-manager --show-config
を実施すると、
# /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
define_milter("milter-opendmarc") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:45
  milter.connection_spec = "local:/var/run/opendmarc/socket"  ← 注目
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:38
  milter.enabled = true
  # default
  milter.fallback_status = "accept"
  # default
  milter.evaluation_mode = false
  # default
  milter.applicable_conditions = []
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:40
  milter.command = "/usr/local/etc/rc.d/milter-opendmarc"
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:41
  milter.command_options = "start"
  # default
  milter.user_name = nil
  # default
  milter.connection_timeout = 297.0
  # default
  milter.writing_timeout = 7.0
  # default
  milter.reading_timeout = 7.0
  # default
  milter.end_of_message_timeout = 297.0

接続先も認識され、めでたく OpenDMARC が milter-manager で利用できるようになりました。

これで、今年2月にやりたかった DMARC 対応が、設備移転で全く出来なかった状況を脱し、やっと準備完了となりました・・orz

2025/05/26(月)〔FreeBSD Ports〕glib、gobject-introspection のコンパイルエラー

2025/05/26 24:05 サーバ運営・管理
FreeBSD の Ports を用いてソフトウェアの更新をする際、
portupgrade コマンドを常用している方々はそこそこ居られると思うのですが、
このコマンドを使用して glib と gobject-introspection をアップデートすると・・・
glib-2.84.1,2 depends on file: /usr/local/gobject-introspection-bootstrap/bin/g-ir-scanner - not found
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/glib20
*** Error code 1
のようなエラーとなって、構築不能となる。
要するに構築に必要な g-ir-scanner 実行ファイルが見つからないので、どうにも出来ないという状況。

この件の情報収集をしていると、「/usr/ports/UPDATING に記載がある」といいます。
確かに、提起のテキストファイル内の 20250402: と記載がある行の下に記載があります:
20250402:
AFFECTS: users of devel/glib20 and devel/gobject-introspection building outside of Poudriere
AUTHOR: arrowd@FreeBSD.org

New versions of glib started to require gobject-introspection as a build
dependency, while gobject-introspection requires glib to build. This forms a
dependency cycle that is dealt with by introducing the @bootstrap flavor for
mentioned ports. This solution is suggested by the upstream as well, see
https://discourse.gnome.org/t/dealing-with-glib-and-gobject-introspection-circular-dependency/18701

When building devel/glib20 in Poudriere no manual intervention is required.
The devel/glib20@bootstrap gets built first and provides for
devel/gobject-introspection@bootstrap. This in turn provides for a normal
devel/glib20 build, which finally fulfills a dependency for normal devel/gobject-introspection

Users that are building outside of the isolated environments will be ending
up with useless glib-bootstrap and gobject-introspection-bootstrap packages
installed after each update. These can be removed with

pkg remove glib-bootstrap gobject-introspection-bootstrap
正直、「どう対処するのか?」という観点では非常に判りにくいです:
Google翻訳をしてみました。
20250402:
影響: Poudriere 以外で devel/glib20 および devel/gobject-introspection をビルドするユーザー
作成者: arrowd@FreeBSD.org

glib の新しいバージョンでは、ビルド依存関係として gobject-introspection が必須になりました。一方、gobject-introspection はビルドに glib を必要とします。これにより依存関係の循環が発生しますが、上記の port に @bootstrap フレーバーを導入することで対処できます。この解決策はアップストリームでも提案されています。詳細は、https://discourse.gnome.org/t/dealing-with-glib-and-gobject-introspection-circular-dependency/18701 を参照してください。

Poudriere で devel/glib20 をビルドする場合、手動による介入は不要です。
devel/glib20@bootstrap が最初にビルドされ、devel/gobject-introspection@bootstrap に提供されます。これにより、通常の devel/glib20 ビルドが可能になり、最終的に通常の devel/gobject-introspection の依存関係が満たされます。

隔離環境外でビルドを行っているユーザーは、アップデートのたびに不要な glib-bootstrap および gobject-introspection-bootstrap パッケージがインストールされてしまいます。これらのパッケージは、

pkg delete glib-bootstrap gobject-introspection-bootstrap で削除できます。
更に見ていくと、どうもこの「フレーバー」という仕組みが最近 Ports に組み込まれたらしく、現行のportupgrade (Ver 2.4.16) ではこの仕組みを解釈出来ないことが原因の模様。

この解決方法を記載されていたページを見つけたので、ここで肝の部分だけ引用してみます:
1. glibをglib-bootstrapに変更(glib-bootstrapはgobject-introspectionが必要ない)する。
2. gobject-introspectionをgobject-introspection-bootstrapに変更する。
3. glib-bootstrapをglibへ更新する。
4. gobject-introspection-bootstrapをgobject-introspectionへ更新する。

具体的には以下のように実行します。

# pkg_replace glib=/usr/ports/devel/glib20@bootstrap
# pkg_replace gobject-introspection=/usr/ports/devel/gobject-introspection@bootstrap
# pkg_replace glib-bootstrap=/usr/ports/devel/glib20
# pkg_replace gobject-introspection-bootstrap=/usr/ports/devel/gobject-introspection
glibとgobject-introspectionのアップデート | 出口の興味関心あるもの
当方でもここで提示されている方法で、glibと、gobject-introspection を更新出来ました。
しかしまぁ。。 /usr/ports/UPDATING を注意深く見ている人はそう居ないような気も、、、

※注意(2025/06/05 追記):
 引用元サイトにて明記されていないので補足します。
 ・pkg_replace は、予め Ports の ports_mgmt/pkg_replace を別途インストールする必要があります。
 ・どうやら、構築時に lang/python-3.11.12 以上のバージョンと devel/meson-1.7.0 以上のバージョンが依存するらしく、
  少なくともこの2つが提起バージョン未満だと、上手くいきません。当方は、これでしばらく悩みました。

2024/06/20(木)FreeBSD 13.3R で dovecot 2.3.21 はそのまま構築できない

2024/06/21 16:36 サーバ運営・管理
先日、ちょっと嵌ったので自分メモ
FreeBSD 13.3 では、clang が Ver 17 になった影響か、dovecot 2.3.21 ではこんな感じで、コンパイルエラーになる:
test-mail-index-transaction-update.c:633:14: warning: comparison of function 'timezone' equal to a null pointer is always false [-Wtautological-pointer-compare]
  633 |         test_assert(timezone == 0);
      |                     ^~~~~~~~    ~
../../src/lib-test/test-common.h:20:8: note: expanded from macro 'test_assert'
   20 |         if (!(code)) test_assert_failed(#code, __FILE__, __LINE__); \ 
      |               ^~~~
test-mail-index-transaction-update.c:633:14: note: prefix with the address-of operator to silence this warning
  633 |         test_assert(timezone == 0); 
      |                     ^ 
      |                     & 
../../src/lib-test/test-common.h:20:8: note: expanded from macro 'test_assert'
   20 |         if (!(code)) test_assert_failed(#code, __FILE__, __LINE__); \ 
      |               ^ 
test-mail-index-transaction-update.c:648:42: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith]
  648 |                 hdr.day_stamp = tests[i].old_day_stamp + timezone; 
      |                                                        ^ ~~~~~~~~ 
test-mail-index-transaction-update.c:648:17: error: incompatible pointer to integer conversion assigning to 'uint32_t' (aka 'unsigned int') from 'char *(*)(int, int)' [-Wint-conversion]
  648 |                 hdr.day_stamp = tests[i].old_day_stamp + timezone; 
      |                               ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
test-mail-index-transaction-update.c:650:49: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith]
  650 |                 mail_index_update_day_headers(t, tests[i].now + timezone); 
      |                                                               ^ ~~~~~~~~ 
test-mail-index-transaction-update.c:650:36: error: incompatible pointer to integer conversion passing 'char *(*)(int, int)' to parameter of type 'time_t' (aka 'long') [-Wint-conversion]
  650 |                 mail_index_update_day_headers(t, tests[i].now + timezone); 
      |                                                  ^~~~~~~~~~~~~~~~~~~~~~~ 
./mail-index-transaction-private.h:127:77: note: passing argument to parameter 'day_stamp' here
  127 | void mail_index_update_day_headers(struct mail_index_transaction *t, time_t day_stamp); 
      |                                                                             ^ 
test-mail-index-transaction-update.c:654:63: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith]
  654 |                 test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp + timezone, i); 
      |                                                                             ^ ~~~~~~~~ 
../../src/lib-test/test-common.h:26:9: note: expanded from macro 'test_assert_idx'
   26 |                 if (!(code)) test_assert_failed_idx(#code, __FILE__, __LINE__, i); \ 
      |                       ^~~~ 
test-mail-index-transaction-update.c:654:37: warning: comparison between pointer and integer ('uint32_t' (aka 'unsigned int') and 'char *(*)(int, int)') [-Wpointer-integer-compare]
  654 |                 test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp + timezone, i); 
      |                                 ~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
../../src/lib-test/test-common.h:26:9: note: expanded from macro 'test_assert_idx'
   26 |                 if (!(code)) test_assert_failed_idx(#code, __FILE__, __LINE__, i); \ 
      |                       ^~~~ 
5 warnings and 2 errors generated.
gmake[3]: *** [Makefile:916: test-mail-index-transaction-update.o] エラー 1
gmake[3]: ディレクトリ '/usr/local/src/dovecot-2.3.21/src/lib-index' から出ます
gmake[2]: *** [Makefile:573: all-recursive] エラー 1
gmake[2]: ディレクトリ '/usr/local/src/dovecot-2.3.21/src' から出ます
gmake[1]: *** [Makefile:704: all-recursive] エラー 1
gmake[1]: ディレクトリ '/usr/local/src/dovecot-2.3.21' から出ます
gmake: *** [Makefile:548: all] エラー 2
軒並み、timezone 絡みのようで、この件に関するパッチが3つ公開されています:
その1 https://github.com/dovecot/core/commit/e983ead775671186b3c8567d59973d2e52b678c7
その2 https://github.com/dovecot/core/commit/1a7b1f66fe4b86cb642dbcfe5a0192c1b77d0e17
その3 https://github.com/dovecot/core/commit/867a37fa7b74f798a931fb582214b5377f57610e

〔その1 src/lib/ioloop-notify-kqueue.c を修正〕
@@ -11,6 +11,7 @@
1111  
1212 #include "ioloop-private.h"
1313 #include "llist.h"
14+ #include "time-util.h"
1415 #include <unistd.h>
1516 #include <fcntl.h>
1617 #include <sys/types.h>

〔その2 src/lib-index/test-mail-index-transaction-update.c を修正〕
@@ -6,6 +6,7 @@
66 #include "test-common.h"
77 #include "mail-index-private.h"
88 #include "mail-index-transaction-private.h"
9+ #include "utc-offset.h"
910  
1011 #include <time.h>
1112  
@@ -630,7 +631,9 @@
630631  
631632     /* daylight savings times were confusing these tests, so we'll now
632633       just assume that TZ=UTC */
633 -    test_assert(timezone == 0);
634+    time_t now = time(NULL);
635+    struct tm *local_time = localtime(&now);
636+    test_assert(utc_offset(local_time, now) == 0);
634637  
635638     hdr.messages_count = 10;
636639     t = mail_index_transaction_new();

〔その3 src/lib-index/test-mail-index-transaction-update.c を修正〕
@@ -648,13 +648,13 @@
648648         i_zero(&hdr);
649649         for (j = 0; j < N_ELEMENTS(hdr.day_first_uid); j++)
650650            hdr.day_first_uid[j] = 8-j;
651 -        hdr.day_stamp = tests[i].old_day_stamp + timezone;
651+        hdr.day_stamp = tests[i].old_day_stamp;
652652         memcpy(t->post_hdr_change, &hdr, sizeof(hdr));
653 -        mail_index_update_day_headers(t, tests[i].now + timezone);
653+        mail_index_update_day_headers(t, tests[i].now);
654654  
655655         struct mail_index_header new_hdr;
656656         memcpy(&new_hdr, t->post_hdr_change, sizeof(new_hdr));
657 -        test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp + timezone, i);
657+        test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp, i);
658658         test_assert_idx(memcmp(new_hdr.day_first_uid,
659659                     tests[i].new_day_first_uid,
660660                     sizeof(uint32_t) * 8) == 0, i);

これらのパッチを手動で当て、いつもの手順でコンパイルすることで、いくつか Warning が出るものの、通常通りの使用可能となるようです。
バージョンアップで、この不具合が解消されることを期待したいところ。

2023/11/12(日)Python 一部モジュール・ライブラリが更新できない

FreeBSD12 → FreeBSD13 に更新後、アプリケーションのライブラリ等が旧OSバージョンにて構築したものだったりすると、それが原因で謎の動作不具合起こしたりする場合が稀にあるため、「安定動作」を目的として、全てのアプリケーションを再構築します。

通常、OSバージョンアップの場合、前バージョンまでの動作互換性は保証しているので、必ずしも必要ではないはずなのですが、それでも不可解な挙動が生じる場合があり、それを未然に防ぐために「全てのアプリケーション再構築」という作業を行うことにしているのです。

多くのマトモな方々には信じられないかもしれないですが、この事業を始めたばかりの頃、
『たった1回のアプリケーション障害で、しかもたった1日で一方的なサーバホスティング解消』をされたことがあり、これは純粋にアプリケーションの不具合で、OSアップデートが問題ということでもなく、運用側でどうすることも出来ない不可抗力な原因の事象でした。

当然、「一方的」だったので、説明責任のかけらも果たすことが出来ませんでした。
まぁ、そんなに信用できないなら「最初から易々と近づくな」と言いたいし、何より舐められまくってますね。
そんな態度の「上から目線なクライアント」は、相手にしないことは言うまでもないです。
きっと、他所でも毛嫌いされていることだろうと思われます。
20年以上やっていますが、この類の不具合は、この件含めて2回。
2回目は説明責任果たせたので、理解してもらえました。過去20年に限れば安定稼働しています。

前置きが長くなり過ぎたのですが、ここから本題。
FreeBSD12 → FreeBSD13 にOSアップデートして、アプリケーション再構築をすると、一部の Python アプリケーションが再構築出来ずに、以下のようなエラーを吐いてしまう。
  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 972, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 850, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/local/lib/python3.9/site-packages/setuptools/__init__.py", line 18, in 
    from setuptools.dist import Distribution
  File "/usr/local/lib/python3.9/site-packages/setuptools/dist.py", line 34, in 
    from ._importlib import metadata
  File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 39, in 
    disable_importlib_metadata_finder(metadata)
  File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 28, in disable_importlib_metadata_finder
    to_remove = [
  File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31, in 
    if isinstance(ob, importlib_metadata.MetadataPathFinder)
AttributeError: module 'importlib_metadata' has no attribute 'MetadataPathFinder'

ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
*** Error code 1
この現象は、時々起きるらしく、外国のメンテナンス作業者の解決策として、どうやら
# cd /usr/local/lib
# rm -rf python3.*
としてから、
# portupgrade -rf python.3.9.18
(インストールされている Python バージョンに合わせる)
とすると、解消する模様。やや強引かつ豪快な解決手段だが、これが確実なのだとか。
これをやったら、確かに問題は解消しました。

2023/11/03(金)FreeBSD14 と FreeBSD12

2023/11/03 7:07 サーバ運営・管理
最低でも月に一度は記事をアップしようという目標を密かに立てていたのですが、実際、殆ど時間的余裕が無く、最後の投稿から7ヶ月経過してしまいました。。
質問やコメントにも目を通しているものの、殆ど反応出来ずな状態です。

さて、いつの間にか FreeBSD 12は、リリースから5年が経過しようとしています。2018/12/11 に 12.0 がリリースされました。
メンテナンスサポート期間は5年と定められたため、5年後の月末を以ってサポート終了です。
20231103.png

〔FreeBSD 公式サイト日本語版より https://www.freebsd.org/ja/security/#sup
FreeBSD 12.4 を稼動させるサーバ機器が7台あるのですが、そのうちの5台を急遽 13.2 (2023/04/11 リリース)へアップデート中。

さて、FreeBSD 14 ですが、これもいつの間にか近日リリースなのです。
FreeBSD14.png

〔FreeBSD 公式サイトより https://www.freebsd.org/releases/14.0R/schedule/

どういう新機能等があるのか、概要の意訳をして確認してみました:
・root アカウントのデフォルトシェルは、sh(1) になる。 → 何で?
・デフォルトのMTAは、sendmail(8) から dma(8) に変更される。 → 既に Postfix 使いなので、関係ないか?
・Locale が CLDR41.0 , Unicode 14.0 に対応 → ちょっと対応遅いと思う。
・Base64 ライブラリが標準装備になった
・portsnap は削除した。代わりに git を使え。 → えぇぇ!?(でも gitup が使えそうだ)
・pw(8),bsdinstall(8) は、ユーザホームディレクトリを /usr/home 配下ではなく、/home 配下に作成するようにした。→ まともにするための改修ですね。
・libfido2 ライブラリが 1.13.0 になった。→ あれ、既に(大手企業で流行りの)パスキーに対応しているらしい。
・OpenSSL ライブラリが、1.1.1 から 3.0.12 になった。→ 流石にこれはアップデート必須です。
・mergemaster(8) は非推奨になった。代わりに etcupdate(8) を使え。→ えぇぇ!?
・デバイスドライバ amr(4)、iir(4)、mn(4)、mly(4)、nlmrsa(4) 、twa(4) は削除した。→ 時代の流れだね。
・Wi-Fi6 に対応した。 → やっとか。
・FreeBSD15 以後は 32bitプラットフォームをサポートしない。但し、互換機能で32bit アプリケーションの動作は可能とする。 → これも時代の流れですね。。2029年には32bitCPU でFreeBSD は動作しなくなるのかな。

他、多くの項目ありますが、当方が興味なかったり、説明が難しかったりしたので、結構端折っています。

〔2023/12/16 追記〕
FreeBSD14 は、2023/11/20 付けでリリースされました。
FreeBSD13同様、5年間のサポート(2028/11/30 まで)を実施するようです。
また、本家から日本語のページが無くなってしまいました。非営利ベースで担当出来る人が居なくなった模様。

2023/04/06(木)Let's encrypt のサーバ証明書をpostfix で使う場合の注意

2023/04/06 16:15 サーバ運営・管理
今回、初めての経験だったのでメモ。。。
発端は、「こんなメッセージが出るんだが・・・」という一報。
20230406_1.png

証明書の更新は正常にできているので、謎の現象です。さらに「証明書の表示(V)...」で表示される内容を送ってもらうと・・・

20230406_2.png

こんな感じになるらしい。確かにここでは「期限切れ」になっています。

証明書の誤認識であることには間違いないので、クライアント側の設定で何か問題を引き起こしているのではないかと思うのですが、いろいろと不可解なので、一報を頂いた会社へ許可を得て出向いて、原因究明と解消を試みました。

証明書チェーンはあっているが、変にキャッシュしているのかと思い、色々と余計な「オレオレ証明書(最近まで使わせていました)」を削除したが、進展せず。

よく聞くと、最初の送信時だけ出て、電子メール送受信ソフトウェアを終了させない限りは「出ない」とのこと。
また、受信時は一切出ないとのこと。ということは postfix の問題か?

ということで、結局、試行錯誤と考察でひらめいたのが、postfix のhash DB です。
試しに
# postmap -F hash:tls_sni.map
# postfix reload
(tls_sni.map には、証明書の一覧などが所定フォーマットで記述してある)

とやったあと、試してみると、当初のメッセージは一切でなくなりました。
ここには、証明書の有効期限までもデータとして保存される作りらしい。

ということで、
2022/12/25 付けの記事 メールサーバの中規模改修と基礎知識(3)~ Dovecot+Pigeonhole,cert-bot
の最終部分に記述した内容は
#!/bin/sh

/usr/local/etc/rc.d/apache2 stop
/sbin/pfctl -d
/usr/local/bin/certbot renew -m user@example.com
/sbin/pfctl -e
/usr/local/sbin/postmap -F hash:/usr/local/etc/postfix/tls_sni.map
/usr/local/sbin/postfix reload
/usr/local/sbin/dovecot reload
/usr/local/etc/rc.d/apache2 start
のようにし、postfix が扱う証明書情報も更新しないと駄目です。
これでこの件は解決。

2023/01/09(月)dovecot に謎のエラー

2023/01/08 18:21 サーバ運営・管理
このメールサーバのみに出る固有のエラーメッセージだが・・・
Jan  8 17:31:43 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF
Jan  8 17:31:44 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF
Jan  8 17:31:47 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF
Jan  8 17:31:47 mx2 syslogd: last message repeated 1 times
Jan  8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF
Jan  8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF
Jan  8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF
Jan  8 17:41:42 mx2 syslogd: last message repeated 3 times
Jan  8 17:51:42 mx2 syslogd: last message repeated 1 times
Jan  8 17:51:44 mx2 syslogd: last message repeated 6 times
どうやら、外国のWebサイトにて Apple Mail クライアントの行儀の悪さが原因だという記事を見かけました。
しかしながら、接続元情報が一切出てこない上に、関連付けが出来る他の情報も無いため、断定しきれないですね。

「電子メールの送受信が出来ないという不満が出て来なければ、気にする必要無い」と結論付けていて、それはその通りとも言えますが、原因がハッキリしないエラーメッセージはあまり気分のよいものではないです。

Mac 環境での電子メール設定は、時折問い合わせを受けるものの、問題特定できない内容ばかりで都度悩むのですが、一方で、問い合わせ側の試行錯誤でいつの間にか解決してしまうので、成功事例みたいなものが共有できないんです。

かといって、手本を示すのと、検証の為だけにMac を買うということには絶対にならないので、悩ましいところですね。

2023/01/08(日)whois に障害??

2023/01/08 17:45 サーバ運営・管理
本日 日本時間 17:00 くらいから、こんな感じ:
mx2-root[97]# whois basekernel.co.jp
whois: connect(): Operation timed out
mx2-root[98]# whois basekernel.co.jp
whois: connect(): Operation timed out
メンテナンス情報とか見当たらないし、こういう事態は初めて、、

〔2023/01/08 17:51 追記〕
 キャッシュDNS再起動したら復旧。。orz 何だったのだろう??

2023/01/06(金)fml4 → fml8 へのアップデート

2023/01/06 5:00 サーバ運営・管理
事前調査では、なんだか面倒くさそうな記述が結構多かったんですが、
本家のチュートリアルを見る限り、そんな印象は受けなかったので、本家のチュートリアルを参考に実施しています。
先ずは fml8 を新規インストールします。(2022/12/31(土) fml8 の新規インストール 参照)
fml4 既存MLの fml8 移行の場合は、改めて fml8 で新規ML作成の必要は基本的に無しです。勝手に fml4 環境を上書きされることも無く、fml4 が既存でも問題はありません。

https://www.fml.org/software/fml8/ にて、チュートリアル → レシピ一覧 fml4 のMLを fml8 形式のMLへ変換する のリンクを辿っても閲覧出来ない。
チュートリアルページの下の方に
『II. fml のセットアップ~MLの作成』の項目があって、その下の fml4 のMLを fml8 形式のMLへ変換する
https://www.fml.org/software/fml8/Documentation/ja/tutorial/mergeml.fml4to8.html のほうを参照ください。

とはいえ、本家のチュートリアルどおりでは成功しませんので、下記手順を参考にどうぞ:
※ fml4 → fml8 移行に関しては、root ユーザで実施するのが無難です。
# makefml newdomain example.com /var/mail/example.com/~ml
( makefml newdomain バーチャルドメイン名 バーチャルドメインML 格納ディレクトリ )
既存の fml4 で運用している、バーチャルドメインにおけるML一式を格納しているディレクトリを指定します。
既存環境に上書きされることはなく、fml8 環境設定ディレクトリに対応付けが設定されるのみです。
尚、これは該当バーチャルドメイン上に複数のMLがあっても、最初の一度だけ実施でよいです。
23/01/06 00:43:01 makefml[1766] warn: /var/mail/example.com/~ml already exist. reuse it.
といったメッセージが出ますが、このメッセージは無視して大丈夫です。
次に、
# makefml mergeml ml-name@example.com /var/mail/example.com/~ml/ml-name
# cd /var/mail/example.com/~ml/ml-name
# chown fmladmin *
# chown -R fmladmin var
makefml mergeml にて、既存の fml4 で運用している、バーチャルドメインにおけるメーリングリスト個別ディレクトリを指定します。
makefml mergemlで、fml8 に適応したコンバートが行われます。
ファイル・ディレクトリ所有者が、一部 root になってしまうので、全て fmladmin (fml8 の実行権限ユーザ) に変えます。
postfix の場合、 /etc/mail/aliases /usr/local/etc/postfix/virtualtbl などにML関係の設定をしている場合は、必ず、それらを削除することを忘れないでください。
《※ postfix の設定を変更》
# vi /usr/local/etc/postfix/main.cf

《下記の例のように、alias を追加》
alias_maps = hash:/etc/mail/aliases
             hash:/var/mail/example.com/~ml/etc/mail/aliases

virtual_alias_maps = hash:/usr/local/etc/postfix/virtualtbl/forwardlist
                     hash:/var/mail/example.com/~ml/etc/postfix/virtual
# vi /etc/mail/aliases
《下記を追加》
fmladmin:       root

《追加後、下記を実行》
# newaliases
上記、makefml mergeml の実行で、雛形ファイルが自動生成されますので、それを流用します。
ただし、そのままでは使えないため、一部変更します:
# cd /var/mail/example.com/~ml/etc/postfix
# vi virtual
----- 以下、変更 -----
# example.com is one of $mydestination
# CAUTION: DO NOT REMOVE THE FOLLOWING LINE.
# example.com     example.com         ← コメントアウトまたは削除

### <VIRTUAL test-ml@example.com ML> ###

# 以下の5行に、@realmx.example.jp (postfix main.cf で指定の myhostname で示す実ホスト名)を追加
test-ml@example.com               test-ml=example.com@realmx.example.jp
test-ml-ctl@example.com           test-ml-ctl=example.com@realmx.example.jp
test-ml-request@example.com       test-ml-request=example.com@realmx.example.jp
test-ml-admin@example.com         test-ml-admin=example.com@realmx.example.jp
test-ml-error@example.com         test-ml-error=example.com@realmx.example.jp

### </VIRTUAL test-ml@example.com ML> ###
----- 変更はここまで -----

※ MLごとの個別変更で、題名に通し番号を追加する(makefml mergeml を使用しても、環境によっては引き継がれない設定がある。弊社環境ではこれが発生した)

# cd /var/mail/example.com/~ml/text-ml
# vi config.cf

----- 以下を、変更または追加(位置的には =cut 行の前) -----
article_header_rewrite_rules += rewrite_article_subject_tag
article_subject_tag = [$ml_name:%05d]
----- 変更はここまで -----
※ この設定で[test-ml:12345] みたいなのがメールタイトルの先頭に自動追加されるようになります。

# postmap hash:virtual
# postfix reload
これで、元通り fml8 での運用が出来るようになりました。
このアップデートは、ML利用者側から見れば、特に利点はありません。
fml4 が運営側にとって、維持困難になってきているので、主な目的はその解消といったところですね。

2023/01/04(水)セカンダリメールサーバの再構築

2023/01/04 6:22 サーバ運営・管理
セカンダリメールサーバは通常、利用者に開放しているメールサーバ(通常、プライマリメールサーバと称す)が不意にサービス不能状態になった時や、メンテナンス等で一時停止した際など、外部からの電子メールを代わりに且つ一時的に受け取るメールサーバです。
プライマリメールサーバの負荷が高く、応答が遅い時などもセカンダリメールサーバが活用される場面があります。

最近はセカンダリメールサーバを用意していない組織もあるようですが、弊社ではセカンダリメールサーバを備えています。
セカンダリメールサーバは、実は色々な構成があり、プライマリメールサーバのように、電子メールの発信のみを出来るようにしているものもあります。

弊社では、セカンダリメールサーバから電子メールの発信を出来るようにしていませんが、今回はプライマリメールサーバの負荷軽減目的で、明らかなコンピュータウィルスや、確実な spam メールを捨てる仕組みを設けました。
20230103.png

※ この図は、Postfix やメールサーバの構成をそのまま示した図ではありません。

受信メッセージの流れを中心とすると、上記のように感じかなと考えています。
milter-manager で受信メッセージのコンピュータウィルス検査と spam チェックを行います。
実はこれ、Postfix のオンラインマニュアル等を読んでもどうもよく判らないんです。たぶん、こんな感じかなという想像図。。
「outbound」というのは、プライマリメールサーバなどへ送信する場面を想定しています。

上記セカンダリメールサーバ固有の設定

先ず、spamassassin を milter インタフェースで動作させるために、spamass-milter を導入します。
一応、http://savannah.nongnu.org/projects/spamass-milt/ が公式サイトのようで、ダウンロードも出来ますが、永らく更新されておりません。
Ver 0.4.0 をダウンロードしてインストールしましたが、Ver 4.0.0 の spamassassin との組み合わせでも使えるようです。
# tar xvzf spamass-milter-0.4.0.tar.gz
# cd spamass-milter-0.4.0
# setenv CPPFLAGS '-I/usr/local/include -I/usr/include'
# setenv LDFLAGS '-L/usr/local/lib -L/usr/lib'
# ./configure --localstatedir=/var
# gmake
# gmake install
とすると、インストール完了です。
milter 形式だと、サーバ単位での spam 判定になってしまうため、少し緩め閾値で spamassassin の挙動を設定しておきます。
サーバ単位での spamassassin の設定は、/etc/mail/spamassassin/local.cf で設定します:
※ /etc/mail/spamassassin/local.cf の内容(変更部分のみ抜粋):

rewrite_header Subject
report_safe 0
required_score 17.0
経験上、閾値 17.0 では、殆どの spam は通過してしまいます。15.0 未満が妥当ですが、運用しながら、様子見で少しずつ下げていくようにします。

以下、FreeBSD 固有の環境になりますが、下記のスクリプトを /usr/local/etc/rc.d 配下に spamass-milter と言う名前で作成しておきます:
#!/bin/sh

# PROVIDE: spamass-milter
# REQUIRE: LOGIN
# BEFORE: mail
# KEYWORD: shutdown

#
# Add the following lines to /etc/rc.conf to enable spamass-milter:
#
#spamass_milter_enable="YES"
#
# See spamass-milter(8) for flags.
#

. /etc/rc.subr

name=spamass_milter
rcvar=spamass_milter_enable

command=/usr/local/sbin/spamass-milter
required_dirs=/usr/local/share/spamassassin

start_postcmd=start_postcmd
stop_postcmd=stop_postcmd

start_postcmd()
{
  sleep 1

  /usr/sbin/chown ${spamass_milter_socket_owner}:${spamass_milter_socket_group} ${spamass_milter_socket}
  /bin/chmod ${spamass_milter_socket_mode} ${spamass_milter_socket}
}

stop_postcmd()
{
  rm -f ${spamass_milter_socket}
}

load_rc_config $name
: ${spamass_milter_enable="NO"}
: ${spamass_milter_socket="/var/run/spamd/spamass.sock"}
: ${spamass_milter_flags="-f -p ${spamass_milter_socket} ${spamass_milter_localflags}"}
: ${spamass_milter_socket_owner="spamd"}
: ${spamass_milter_socket_group="mailuser"}
: ${spamass_milter_socket_mode="660"}

run_rc_command "$1"
※注:このスクリプトは Postfix のみの対応です。sendmail が MTA だと、不具合起こすと思います。

上記スプリプトに実行権を与え、更に /etc/rc.conf へ
spamass_milter_enable="YES"
の1行を追加しておきます。

ClamAV と、milter-managerも、インストールしておきます。過去記事を参考にしてください。
milter-manager をインストール後、
# /usr/local/sbin/milter-manager -u milter-manager --show-config
とやってみて、
define_milter("clamav-milter") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:44
  milter.connection_spec = "unix:/var/run/clamav/clmilter.sock"
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
  milter.enabled = true
  # default
  milter.fallback_status = "accept"
                  ・
                  ・
                  ・
define_milter("spamass-milter") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:44
  milter.connection_spec = "unix:/var/run/spamd/spamass.sock"
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
  milter.enabled = true
  # default
  milter.fallback_status = "accept"

といった表示がされるのを必ず確認しておきます。

最後に、Postfix 側の設定で、milter と関連するもののみ抜粋すると、
milter_protocol = 6
milter_default_action = accept
milter_mail_macros = {auth_author} {auth_type} {auth_authen}
smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock
non_smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock

transport_maps = hash:/usr/local/etc/postfix/virtualtbl/transport.map
header_checks = pcre:/usr/local/etc/postfix/header_checks
※ /usr/local/etc/postfix/virtualtbl/transport.map の内容:

example.jp                 smtp:[primary1.example.net]
example.net                smtp:[primary2.example.net]

※ /usr/local/etc/postfix/header_checks の内容:

/^From:\s*<>/m                  DISCARD
/^X\-Spam\-Flag:\s+YES/m        DISCARD
/^X\-Virus\-Status:\s+Yes/m     DISCARD

/^X\-Spam\-Level:/m             IGNORE
/^X\-Spam\-Checker\-Version:/m  IGNORE
/^X\-Spam\-Status:\s+No/m       IGNORE
/^X\-Virus\-Scanned:/m          IGNORE
/^X\-Virus\-Status:\s+Clean/m   IGNORE
のような感じ。
# postmap hash:/usr/local/etc/postfix/virtualtbl/transport.map
を忘れずに実施しておきます。

上記の、/usr/local/etc/postfix/header_checks の簡単な説明ですが、
「DISCARD」で終わる行は、電子メールヘッダ部分にて、左辺のパターンが出現したら「配信しました」と送信元に返答しつつ「メッセージを捨てる」という処理を行い、
「IGNORE」で終わる行は、電子メールヘッダ部分にて、左辺のパターンが出現したら「そのヘッダ行は削除して最終配信先へ送る」という処理を行います。
このファイルに記述された内容は、上から下へ順番に処理しますが、「DISCARD」で記述した行は、「そこで打ち切る」という挙動になるらしいです。

この構成で稼働させているが・・・

どうやら、header_checks の設定が上手く反映できていないみたいなのです。
IGNORE で「ヘッダ行削除」の挙動がどうも上手く行っていない模様。
X-Virus.... は上手く行っているが、 X-Spam.... が上手く行かない。。

取り敢えず実害はないのですが、セカンダリメールサーバ経由で受信したメッセージは、
X-Spam... は、受信者から見ると2回出てくることになり、不自然なのでどうにかしたいのです。
バグなのか、設定の問題なのか、、、 困っているところです。