postfix/dovecotメールサーバでWindows Live Mail 2012がエラーになる


qmail+vpopmailという古代の環境から、postfix/dovecotのiredmailメールサーバに移行した。
移行の詳細については別途記事にしますが、移行後、Windows Live Mail 2012ユーザからクレームが・・・

POP3で受信ができないという

原因は、Windows Live Mail 2012のPOP3アクセス機能が古い、という点に尽きる。
対処するにはサーバ側でセキュリティを弱める設定を入れる必要があった。

2020/09/10追記 その1については、iredmail公式にも「Allow insecure POP3/IMAP/SMTP connections without STARTTLS」という形で対処方法が記載された。

その1:POP3受信時にエラー

/var/log/dovecot/pop3.log に下記のログ

Feb 19 10:35:59 oflex-1096-1 dovecot: pop3-login: Disconnected (tried to use disallowed plaintext auth): user=<osakana@example.net>, rip=xxx.xxx.xxx.xxx, lip=xxx.xx.x.xxx, session=<brxUt4ZlTfPbavEx>

→ dovecotの「ssl = required」と「disable_plaintext_auth = yes」の設定により発生
これを「ssl = yes」と「disable_plaintext_auth = no」に変更することで対処できる

設定箇所は下記の3ファイル

/etc/dovecot/dovecot.conf ではsslとdisable_plaintext_authの双方が設定されている可能性がある
/etc/dovecot/conf.d/10-auth.conf ではdisable_plaintext_authが設定されている可能性がある
/etc/dovecot/conf.d/10-ssl.conf ではsslが設定されている可能性がある

3ファイルをそれぞれ確認して修正すること

うちの環境ではssl=requriedがdovecot.confと10-ssl.confの双方で設定されていたが、
10-ssl.confしか認識しておらずいくら設定しても反映されないと悩んだ。

その2:SMTP送信時にエラー1

/var/log/maillog に下記のログ

Feb 19 10:41:49 mailserver.osakana.net postfix/smtpd[8343]: NOQUEUE: reject: RCPT from clienthostname.osakana.net[xxx.xxx.xxx.xxx]: 504 5.5.2 <clienthostname>: Helo command rejected: need fully-qualified hostname; from=<osakana@osakana.net> to=<osakana@example.com> proto=ESMTP helo=<clienthostname>

→postfixの「smtpd_helo_restrictions」で「reject_non_fqdn_helo_hostname」が設定されているため発生

まずは、現在値確認

# postconf smtpd_helo_restrictions
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access pcre:/etc/postfix/helo_access.pcre reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
#

変更前の /etc/postfix/main.cf の該当部分を確認

# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
    reject_non_fqdn_helo_hostname
    reject_unknown_helo_hostname

変更後の /etc/postfix/main.cf の該当部分

# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
    reject_unknown_helo_hostname
#    reject_non_fqdn_helo_hostname

postconfを実行して、変更されたことを確認

# postconf smtpd_helo_restrictions
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access pcre:/etc/postfix/helo_access.pcre reject_unknown_helo_hostname
#

その3:SMTP送信時にエラー2

/var/log/maillog に以下のログ

Feb 19 11:04:48 mailserver.osakana.net postfix/smtpd[11966]: NOQUEUE: reject: RCPT from clienthostname.osakana.net[xxx.xxx.xxx.xxx]: 450 4.7.1 <clienthostname>: Helo command rejected: Host not found; from=<osakana@osakana.net> to=<osakana@example.com> proto=ESMTP helo=<clienthostname>

→postfixの「smtpd_helo_restrictions」で「reject_unknown_helo_hostname」が設定されているため発生

変更前の値はエラー1と同じなのでここでは省略

変更後の /etc/postfix/main.cf の該当部分

# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
#    reject_non_fqdn_helo_hostname
#    reject_unknown_helo_hostname

コメントアウト記述が2つに増えただけですね。

その4:SMTP送信時にエラー3

/var/log/maillog に以下のログ

Feb 19 11:07:08 mailserver.osakana.net postfix/smtpd[12710]: NOQUEUE: reject: RCPT from clienthostname.osakana.net[xxx.xxx.xxx.xxx]: 454 4.7.1 <osakana@example.com>: Relay access denied; from=<osakana@osakana.net> to=<osakana@example.com> proto=ESMTP helo=<clienthostname>

これは単純にテスト用にセットアップしたアカウントがSMTPポート25を使っていたせいで失敗していた。
ポート587に変更したら成功

fail2banで全JAILのステータスを確認したい


Linuxサーバでfail2banを使ってアクセス拒否設定を行っている。

JAILを複数している場合に、全部を一括で確認する手段が標準ではない模様。
調べたところ「kamermans/fail2ban-allstatus.sh」の下記コメントを発見

joergludwig commented on 20 Dec 2017
Shorter version:
fail2ban-client status | sed -n ‘s/,//g;s/.*Jail list://p’ | xargs -n1 fail2ban-client status

これを ~/.bashrc に対して下記のように追加し、「fail2ban-check」で確認出来るように設定した。

alias fail2ban-check="fail2ban-client status | sed -n 's/,//g;s/.*Jail list://p' | xargs -n1 fail2ban-client status"

CephのOSD毎のPlacement Groupの数を確認する



Cephのテスト環境を構築してみた。

シナリオ通りに構築を進めていき、とりあえずは問題なくは終わった。
終わったんだけど、最後にステータスでも確認してみるかとceph healthを実行してみたところHEALTH_WARNが・・・

[root@ceph01 ~]# ceph health
HEALTH_WARN too many PGs per OSD (480 > max 300)
[root@ceph01 ~]#

OSDにたくさんのPGが割り当てられてる、といってるけど、具体的にはどれくらいあるんだろう?

と調べていくと、stackoverflowにある、下記のPGとOSDの関係性に関する質問を発見
Ceph too many pgs per osd: all you need to know

そこで紹介されている「Get the Number of Placement Groups Per Osd」に、OSD毎のPG数をコマンドで確認する手法が掲載されていた。

「ceph pg dump」の出力結果を整形して見やすいようにしている、というものだった。

ceph pg dump | awk '
BEGIN { IGNORECASE = 1 }
 /^PG_STAT/ { col=1; while($col!="UP") {col++}; col++ }
 /^[0-9a-f]+\.[0-9a-f]+/ { match($0,/^[0-9a-f]+/); pool=substr($0, RSTART, RLENGTH); poollist[pool]=0;
 up=$col; i=0; RSTART=0; RLENGTH=0; delete osds; while(match(up,/[0-9]+/)>0) { osds[++i]=substr(up,RSTART,RLENGTH); up = substr(up, RSTART+RLENGTH) }
 for(i in osds) {array[osds[i],pool]++; osdlist[osds[i]];}
}
END {
 printf("\n");
 printf("pool :\t"); for (i in poollist) printf("%s\t",i); printf("| SUM \n");
 for (i in poollist) printf("--------"); printf("----------------\n");
 for (i in osdlist) { printf("osd.%i\t", i); sum=0;
   for (j in poollist) { printf("%i\t", array[i,j]); sum+=array[i,j]; sumpool[j]+=array[i,j] }; printf("| %i\n",sum) }
 for (i in poollist) printf("--------"); printf("----------------\n");
 printf("SUM :\t"); for (i in poollist) printf("%s\t",sumpool[i]); printf("|\n");
}'

これをテスト環境で実行してみると下記の様な出力を得られた

[root@ceph01 ~]# ceph pg dump | awk '
BEGIN { IGNORECASE = 1 }
 /^PG_STAT/ { col=1; while($col!="UP") {col++}; col++ }
 /^[0-9a-f]+\.[0-9a-f]+/ { match($0,/^[0-9a-f]+/); pool=substr($0, RSTART, RLENGTH); poollist[pool]=0;
 up=$col; i=0; RSTART=0; RLENGTH=0; delete osds; while(match(up,/[0-9]+/)>0) { osds[++i]=substr(up,RSTART,RLENGTH); up = substr(up, RSTART+RLENGTH) }
 for(i in osds) {array[osds[i],pool]++; osdlist[osds[i]];}
}
END {
 printf("\n");
 printf("pool :\t"); for (i in poollist) printf("%s\t",i); printf("| SUM \n");
 for (i in poollist) printf("--------"); printf("----------------\n");
 for (i in osdlist) { printf("osd.%i\t", i); sum=0;
   for (j in poollist) { printf("%i\t", array[i,j]); sum+=array[i,j]; sumpool[j]+=array[i,j] }; printf("| %i\n",sum) }
 for (i in poollist) printf("--------"); printf("----------------\n");
 printf("SUM :\t"); for (i in poollist) printf("%s\t",sumpool[i]); printf("|\n");
}'
dumped all in format plain

pool :  4       5       6       7       8       9       10      11      12      13      14      1       2       15      3       | SUM
----------------------------------------------------------------------------------------------------------------------------------------
osd.4   39      29      25      36      27      24      35      34      30      28      34      33      35      29      32      | 470
osd.5   36      35      28      31      21      29      27      37      37      30      32      36      37      27      37      | 480
osd.6   38      37      30      35      30      24      37      33      32      31      27      32      33      31      27      | 477
osd.7   33      34      30      31      25      34      35      42      32      33      21      30      31      28      33      | 472
osd.8   29      32      39      35      28      39      31      34      36      35      38      34      35      24      21      | 490
osd.9   32      34      33      33      37      38      39      27      30      31      28      29      27      26      26      | 470
osd.10  39      31      34      24      35      36      35      40      34      37      37      45      32      31      37      | 527
osd.11  25      26      30      33      36      42      27      30      42      31      28      32      28      35      31      | 476
osd.0   27      39      38      29      35      24      34      26      28      31      38      23      33      31      32      | 468
osd.1   29      30      29      28      43      24      34      30      22      34      30      37      34      44      29      | 477
osd.2   27      32      35      33      31      38      21      24      30      26      37      26      26      36      33      | 455
osd.3   30      25      33      36      36      32      29      27      31      37      34      27      33      42      46      | 498
----------------------------------------------------------------------------------------------------------------------------------------
SUM :   384     384     384     384     384     384     384     384     384     384     384     384     384     384     384     |
[root@ceph01 ~]#

また、NAKAMURA Minoru’s Home Pageにある「RADOS の概略 (RADOS と CRUSH と Placement Group の関係)」は、Cephの理解に役に立った

OpenStack上の仮想インスタンスを物理サーバ間移動(マイグレーション)させる手法について


2022/04/20追記

このページに記載しているのはOpenStack Pike(16番目のリリース)ぐらいまでの話です。

それ以降のOpenStackについては関わっていないので不明です。


OpenStackで仮想インスタンスを動かしている場合に、物理サーバ間を移動させる手法について、いまいちまとまっているものがなかったので、メモ。

・物理サーバを指定して仮想インスタンスを起動

→ 不可能

アベイラビリティーゾーン(availability-zone)というサーバをまとめたグループ(雑な表現)を指定して起動することまでしかできない

・仮想インスタンスを稼働中に物理サーバを移動させる

→ 可能

例えば起動ディスクを含めcinderボリュームを使っている場合、下記コマンドで実施できる

# openstack server migrate --live 移動先ComputeNode --block-migration 仮想インスタンスUUID --wait

なぜか「migrate」と「migration」の2つの単語が混じっている、という不親切なつくりなので、惑わされないこと。

上記だと、移動が終わるまでコマンドが終了しない。「–wait」を抜いた場合、下記の様な形でマイグレーションの進捗状況を確認することが出来る

# openstack server migrate --live 移動先ComputeNode --block-migration 仮想インスタンスUUID
# nova server-migration-list
# nova server-mgirationshow 仮想インスタンスUUID マイグレーション番号

「openstack sevrer show 仮想インスタンスUUID」では進捗のパーセンテージのみ確認可能。

それに対して、「nova server-mgirationshow 仮想インスタンスUUID マイグレーション番号」では、全体で何バイト転送する必要があり、現在何バイト転送が終了しているか、といった詳細を確認することができる。

参考資料
 nova Migrate instances
 nova Live-migrate instances

・止まってる物理サーバ上にあった仮想インスタンスを他の物理サーバで起動させる

→ nova evacuateコマンドで可能

# nova evacuate 仮想インスタンスUUID 移動先ComputeNode

nova evacuateは、元々起動していた物理サーバ上の「nova-compute」と通信が取れない場合に実行できる。

nova-computeと通信が取れる状態だとエラーになる・・・無理矢理実行したいのであれば、該当サーバ上のnova-computeを落とせばできなくもない。

参考資料
 nova Evacuate instances
 nova Recover from a failed compute node

・ERRORステータスになっててmigrateが出来ない

「nova reset-state 仮想インスタンスUUID」を実行することで、ステータスがリセットできる。

参考資料
 nova Troubleshoot Compute

CentOS7のdmesgにperf: interrupt took too longに関するメッセージが出力される


CentOS7で運用しているサーバで「perf: interrupt took too long (3989 > 3933), lowering kernel.perf_event_max_sample_rate to 50000」というような出力が発生しているのに気がついた。

$ dmesg|grep "kernel.perf_event_max_sample_rate"
[ 1502.981806] perf: interrupt took too long (2512 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[ 2019.987492] perf: interrupt took too long (3147 > 3140), lowering kernel.perf_event_max_sample_rate to 63000
[ 2910.077414] perf: interrupt took too long (3989 > 3933), lowering kernel.perf_event_max_sample_rate to 50000
$

パフォーマンス情報を取得するために、どれくらいの周期でデータを取得したらいいのかは、サーバのハードウェア構成などによって変化するため、自動調整するようになっているようだ。

まずは、長い間隔で収集(サンプリングレート)し、うまくデータが取れているようだったら、徐々に間隔を短縮していく、ということになっているようだ。

journalctlでログから発生時刻を確認する。

# journalctl |grep "perf_event_max_sample_rate"
 2月 27 10:44:11 blog.osakana.net kernel: perf: interrupt took too long (2512 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
 2月 27 10:52:48 blog.osakana.net kernel: perf: interrupt took too long (3147 > 3140), lowering kernel.perf_event_max_sample_rate to 63000
 2月 27 11:07:38 blog.osakana.net kernel: perf: interrupt took too long (3989 > 3933), lowering kernel.perf_event_max_sample_rate to 50000
#

この日は10:19頃にkernelアップデートのため再起動したことにより、サンプリングレートの値が初期化され、調整が必要になったようだ。

過去のログを遡ってみると「perf: interrupt took too long (5208 > 5190), lowering kernel.perf_event_max_sample_rate to 38000」というのが、一番低い値である模様。

最初の変更後の値が79000ということを考えると、起動時の初期値は80000以上だったと思われるので、周期が半分以下となったということである。

さて、kernel.perf_event_max_sample_rateの現在値は「/proc/sys/kernel/perf_event_max_sample_rate」で確認出来る。

# cat /proc/sys/kernel/perf_event_max_sample_rate
50000
#

値を変更する場合は、上記に値を入れる。

恒久的に変更するには、sysctlの設定ファイルを作成する。

CentOS7の場合、/etc/sysctl.d ディレクトリに設定ファイルを作成する。(/etc/sysctl.confに追加するという手もあるが、今後のパッチでsysctl.confが修正される可能性があるためお薦めしない。)

まず、現在の設定値を確認

# sysctl -a | grep perf_event_max_sample_rate
kernel.perf_event_max_sample_rate = 50000
#

/etc/sysctl.d/90-local.conf として設定値を入れた設定ファイルを作成

# echo "kernel.perf_event_max_sample_rate = 38000" > /etc/sysctl.d/90-local.conf
# cat /etc/sysctl.d/90-local.conf
kernel.perf_event_max_sample_rate = 38000
#

sysctlの設定をシステムに適用します。

# sysctl --system
* Applying /usr/lib/sysctl.d/00-system.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
* Applying /etc/sysctl.d/90-local.conf ...
kernel.perf_event_max_sample_rate = 38000
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
#

値が変更されたことを確認します。

# sysctl -a | grep perf_event_max_sample_rate
kernel.perf_event_max_sample_rate = 38000
#

2017/03/03追記
kernel.perf_event_max_sample_rate の値を調整した後、現在のところは同じメッセージは出力されていません。

2017/03/22追記
約1ヶ月経過しましたが、出力されていないので、うちの環境では38000で問題ないようです。

2018/07/09追記
別環境で作ったサーバでも38000で落ち着きました。