Linux

 ええ、まあタイトルの通りでnextcloud18+php7.3の環境で、php7.4への変更を実施。
 変更手順はとりあえずnginxとphp-fpmとredisとか諸々止めて、php7.3および関連パッケージ全削除。
 その後、dnf module reset phpでphp7.3のモジュール指定を解除し、dnf module install php:remi-7.4でphp7.4(と関連パッケージの一部)をインストール。
 その後、インストールできていないphp7.4関連パッケージをインストールした後に各種設定ファイル(php.iniやwww.conf)を設定。
 なお、この際にphp-fpm7.4のコンフィグのデフォルト値から変更した箇所が1つだけ。

listen.acl_users = apache,nginx → コメントアウト

 この設定はlistenで指定したsockファイルへアクセスする際のアクセス権を指定しているみたいなのだが、デフォルトのままだとwww.sockに対してpermission deniedとなってしまった。
 で、この設定が有効だとlisten.owner/listen.groupが無効化されると言うことなので、逆に listen.owner/listen.group をphp7.3の時と同じ設定にしてlisten.acl_usersをコメントアウトすることで解決してる。

 で、そこまで設定して各種サービスを再起動し、rainloopやwordpress、prometheus/grafana等が正常に動作していることを確認したが、nextcloudの再ログインができない。
 利用者用アカウント、管理者アカウントともにパスワードが間違っていると返されて憤怒。

 どうも、php7.4に変更した影響でパスワードが認識できていないみたいだったので、一か八かでパスワードの再設定を利用者用アカウントで実施し、無事に変更したパスワードでログインできることを確認(クライアントソフトでの同期も確認)
 次いで、管理者アカウントもパスワードリセットを試みるもパスワードリセット通知メールが届かない。nextcloudのログを見ると管理者アカウントにパスワードリセット用のメールアドレスが登録されていないという旨のエラーがあり絶望。

 しかし、管理者ログインできないといろいろマズイので、とりあえずphpmyadminを導入し、データベースに接続し、管理者アカウントの情報にメールアドレスを追加(というか利用者アカウントの設定をもとにキーを作成)して再度パスワードリセットを実施。
 とりあえず無事にパスワード変更通知メールが届いたのでリンク先からパスワード変更、無事にログインができることを確認。

 とりあえずこれで無事にphp7.4への更新が完了したのでめでたしめでたし。
 同じようなことをしようとしている方へのアドバイスとしては、管理者アカウントについてはパスワードリセット用のメールアドレスをちゃんとしておくこと。

Linux

そのうち別途解説しようと思うが、rainroopのsieve連携を使用したサーバサイドメールフィルタを設定し、動作確認をしていたところ、ごく少数の送信元からのメールのみ、rejectされていることを確認した。
それほど重要なメールが送られることが無かったため気付かなかったのだが、同一のエラーとなるドメインにいくつかマズイ送信元があり、対策を迫られる。

# Recipient address rejected: Server configuration problem;
まずはリジェクトの理由。Server configuration problemであるため、根本的にはこちらのサーバの設定と言うことになる。

Feb 2 06:44:03 mail policyd-spf[11167]: Traceback (most recent call last):
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/bin/policyd-spf", line 809, in
Feb 2 06:44:03 mail policyd-spf[11167]: instance_dict, configData, peruser, peruserconfigData)
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/bin/policyd-spf", line 623, in _spfcheck
Feb 2 06:44:03 mail policyd-spf[11167]: mres = mfromquery.check()
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/lib/python3.6/site-packages/spf.py", line 591, in check
Feb 2 06:44:03 mail policyd-spf[11167]: spf = self.dns_spf(self.d)
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/lib/python3.6/site-packages/spf.py", line 1160, in dns_spf
Feb 2 06:44:03 mail policyd-spf[11167]: a = [t for t in self.dns_txt(domain) if RE_SPF.match(t)]
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/lib/python3.6/site-packages/spf.py", line 1210, in dns_txt
Feb 2 06:44:03 mail policyd-spf[11167]: dns_list = self.dns(domainname, rr,ignore_void=ignore_void)
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/lib/python3.6/site-packages/spf.py", line 1354, in dns
Feb 2 06:44:03 mail policyd-spf[11167]: for k, v in DNSLookup(name, qtype, self.strict, timeout):
Feb 2 06:44:03 mail policyd-spf[11167]: File “/usr/local/lib/python3.6/site-packages/spf.py", line 106, in DNSLookup_pydns
Feb 2 06:44:03 mail policyd-spf[11167]: if strict > 1:
Feb 2 06:44:03 mail policyd-spf[11167]: NameError: name 'strict’ is not defined
Feb 2 06:44:03 mail postfix/spawn[11120]: warning: command /usr/bin/python3.6 exit status 1
Feb 2 06:44:03 mail postfix/smtpd[11115]: warning: premature end-of-input on private/policy while reading input attribute name
Feb 2 06:44:03 mail postfix/smtpd[11115]: warning: problem talking to server private/policy: Success
Feb 2 06:44:03 mail postfix/smtpd[11115]: NOQUEUE: reject: RCPT from dns1.justsystems.com[163.44.223.114]: 451 4.3.5 hogehoge@foo.bar: Recipient address rejected: Server configuration problem; from=janedoe@brabra.com to=hogehoge@foo.bar proto=SMTP helo=
Feb 2 06:44:03 mail postfix/smtpd[11115]: disconnect from ns.brabra.com[www.xxx.yyy.zzz] helo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

 と言う訳で、ログを確認してみると、SPFチェックのpythonモジュールで問題が起きている模様。
 さらに言えばなんとなくSPFの判定に必須となる名前解決に何かある。

 これまで、
py3dns-3.0.2
pyspf-2.0.12
pypolicyd-spf-2.0.2
を使用してSPFチェックを行っていたのだが、これらのモジュールにバグがある模様。
ならば更新版があるのでは無いかとおもい各パッケージの最新版を探してみたところpy3dnsとpyspfには更新版があることを確認したのでアップデート。
結果 、
py3dns-3.2.1
pyspf-2.0.14
に更新され、無事これまでエラーだった送信元からのメールも正常に判定・受信されるようになりましたとさ。

No tags for this post.