HA's memo: 12月 2020

2020年12月31日木曜日

Supremicro X11SDV-4C-TP8F購入

X11SDV-4C-TP8Fを購入してしまいました。
今年は家にいる時間が長いからかPCパーツをたくさん買ってしまったなぁ。

TDP 60WのXeon D-2123IT搭載なので省電力を期待していたのですが、結果はいまいちでした。
M2 SSDを一枚、メモリ32GBx2搭載状態で電源OFF時で16W、電源ON後15分程度経過した状態56Wという感じです。
BMCで15Wも消費しています。ASRock Rack X470D4UではBMC消費電力が3.5W程度だったのでかなり大食いな印象です。

X470D4U, X570M Pro4と同様にESXi6.7をインストール後省電力設定、BIOSでも省電力設定を行い、PCIeボード2枚とHDDを8台追加した構成のアイドル状態で80W程度となりました。X470D4U, X570M Pro4では上記に10G NIC(PCIe)を追加した構成で60W程度まで設定できていたので20Wの差です。
BMCの消費電力差12.5Wを引くと7.5W、10Gポートが2つ、SATAポートが4つ増えているのでこんなものかなと言う気がしなくも無いですが…。普段停止しておくにしても待機状態で16W消費とかもったいない感じがします。
BIOSでもう少し設定詰められると良いのですが。

2020年12月28日月曜日

raidz2のST4000DM004をWD40EZRZに交換

今年6月にHDD二台が故障したraidz2(ST4000DM004の8台構成)ですが、scrubを実行したところread failとなるHDDが二台出てしまいました。
うち一台は一時的なものだったようですが、他方は下記の感じでCurrent_Pending_Sector, Offline_Uncorrectableが3桁台に…。 8台中3台が3年未満で故障とは。

# smartctl -A /dev/sdf
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1160.6.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   059   055   006    Pre-fail  Always       -       10386248
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       96
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   087   060   045    Pre-fail  Always       -       513462226
  9 Power_On_Hours          0x0032   075   075   000    Old_age   Always       -       22634 (210 239 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       96
183 Runtime_Bad_Block       0x0032   099   099   000    Old_age   Always       -       1
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   088   088   000    Old_age   Always       -       12
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       2 3 3
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   045   040    Old_age   Always       -       32 (Min/Max 27/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       935
193 Load_Cycle_Count        0x0032   099   099   000    Old_age   Always       -       2628
194 Temperature_Celsius     0x0022   032   055   000    Old_age   Always       -       32 (0 20 0 0 0)
195 Hardware_ECC_Recovered  0x001a   070   064   000    Old_age   Always       -       10386248
197 Current_Pending_Sector  0x0012   098   098   000    Old_age   Always       -       720
198 Offline_Uncorrectable   0x0010   098   098   000    Old_age   Offline      -       720
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       21826h+07m+03.803s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       14648100184
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       28880173058

longtestでもエラーとなり、smartdもsyslogにメッセージを出すようになったので交換しました。
Reallocated_Sector_Ctが0のままなんですが、こう言うものなんでしょうか。
SMARTの情報ってイマイチ見方が分からないんですよね。

さて、前回交換時は多重障害になってしまいましたがresilverに数日かかったので、今回はCMRのものを試そうとWD40EZRZに変えてみました。
たまたまセール中にあたりST4000DM004より安く買えたのでお財布にも優しくラッキーでした。

で、resilverにかかった時間ですが、17時間弱で完了しました。
私の用途ではST4000DM004でも普段使っている時は全く問題ないんですけど、resilverなど長時間書き込みが発生すると影響が出てしまうような感じです。
大容量で安いCMRのHDDって無いんですよね。

# zpool status
  pool: tank
 state: ONLINE
  scan: resilvered 3.27T in 0 days 16:47:29 with 0 errors on Sun Dec 27 03:04:23 2020
config:

        NAME                                                STATE     READ WRITE CKSUM
        tank                                                ONLINE       0     0     0
          raidz2-0                                          ONLINE       0     0     0
            ata-ST4000DM004-2CV104_aaaaaaaa-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_bbbbbbbb-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_cccccccc-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_dddddddd-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_eeeeeeee-part1           ONLINE       0     0     0
            ata-WDC_WD40EZRZ-22GXCB0_WD-ffffffffffff-part1  ONLINE       0     0     0
            ata-ST4000DM004-2CV104_gggggggg-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_hhhhhhhh-part1           ONLINE       0     0     0

errors: No known data errors

2020年12月5日土曜日

送信者アドレスで接続先MTAを変更してSMTPSとSMTP認証を使用する

いくつかのISPのメールアドレスを利用しているのですが、受信はISPの転送設定を利用してVPSのMTAに集め、送信はISPのメールサーバを利用せずにVPSのMTAを経由させて直接配送していました。

MUAでFromアドレス毎にISPのメールサーバを指定するのが面倒なので、このように利用していたのですがDMARCも普及してきているようなので正しくISPのメールサーバを経由させるように設定変更することにしました。

まあ、なりすましメールと同じなので仕方ないですが、SPFの認証結果は気にはなっていたけど面倒なので長年放置していたと言う感じです。
ちなみに独自ドメインについては一応SPF設定はしてありますが、こちらのアドレスでメールを送信することはほとんどありません。

前置きが長くなりましたが、環境と条件は下記になります。

CentOS 8.2
postfix 3.3.1
Envelope FromがISPのメールアドレスの場合は、ISPのメールサーバを経由する。
上記以外のメールアドレスの場合は、直接配送する。
ISPのメールサーバは、SMTP over SSLで認証(SMTP Auth)ありとする。

まずは、/etc/postfix/main.cfに下記の設定を追加します。

sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependent_transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/password_maps
smtp_sasl_security_options = noanonymous

クライアントサイドのSMTP Auth有効化と、送信者アドレスによるtranspot mapの定義を行っています。
次にsmtp_sasl_password_mapsに指定した/etc/postfix/password_mapsを下記の形式で記述します。

[ISPメールサーバ]:ポート  アカウント名:パスワード

ファイルの作成後、postmapコマンドでハッシュファイルを作成します。
password_maps, password_maps.dbはプレーンなパスワード情報を含むため、rootのみ参照可能に設定します。
例えば、下記のようになります。

# cd /etc/postfix
# cat password_maps
[mail.example1.com]:465   foo@example1.com:password1
[mail.example2.com]:465   var@example2.com:password2
#
# postmap hash:password_maps
# chmod og-rxw password_maps*

sender_dependent_default_transport_mapsに設定した/etc/postfix/sender_dependent_transportは下記の形式で記述します。

メールアドレス  relay-smtps:[ISPメールサーバ]:ポート

こちらもファイルの作成後、postmapコマンドでハッシュファイルを作成します。
例えば、下記のようになります。

＃ cat sender_dependent_transport
foo@example1.com  relay-smtps:[mail.example1.com]:465
var@example2.com  relay-smtps:[mail.example2.com]:465
#
# postmap hash:sender_dependent_transport

relay-smtpsサービスを指定しているのがポイントになります。
次に/etc/postfix/master.cfに下記のようにrelay-smtpsサービスを追加します。

relay-smtps unix  -     -       n       -       -       smtp
        -o smtp_tls_security_level=encrypt
        -o smtp_tls_wrappermode=yes

設定後、postfixを再起動すれば完了です。
これで通常は適宜STARTTLSを使用し直接配送、設定したメールアドレスの場合はSMTPS(SMTP over SSL)を使用し各ISP経由で配送するようになります。

最後にsyslogに下記のメッセージを出し認証に失敗する場合は、SMTP Authの認証メカニズムが不足しているのでSASLのパッケージを追加します。

warning: SASL authentication failure: No worthy mechs found

恐らくcyrus-sasl-md5, cyrus-sasl-plainパッケージをインストールすれば解決するはずです。
認証アルゴリズムは、CRAM-MD5, DIGEST-MD5, PLAINがあれば問題ないかと思います。

参考)
Postfix Configuration Parameters: sender_dependent_default_transport_maps
Postfix TLS Support: Sending only mail for a specific destination via SMTPS

iPad Air 4購入

iPad Air 2を愛用してきましたが、iPad Air 4を購入してしまいました。
調べるとiPad Air 2は2014年12月に購入していました。
丸6年毎日使ってきたので一番使い込んだ機器かもしれません。

性能的には全く問題なかったのですが、ストレージが手狭になったのとバッテリーがへたってきたので新モデルを購入しましたが、バッテリー交換してもう少し使ってやればよかったかな…と思わなくもないです。