カテゴリー: 通信

投稿日:

ESXi 6.5でVMDirectPath I/Oが設定できるけど使えない

ESXi6.5環境において、16Gb FC HBAのQLogic QLE2662に対して、VMDirectPath I/Oで仮想マシンから直接使える様にパススルー設定をした。
設定は問題なくできたものの、仮想マシンを起動してみると、全然認識してくれない。

よく、パススルー設定で選択できない、という話は聞くが、今回は、設定は出来ている。

ためしに8GbのFC HBA QLE2540 を使ってみると、同様の手法で設定でき、仮想マシンからちゃんと認識している。

ここら辺に糸口があるな、と調査。


＜調査過程は省略＞

結論からすると「VMware vSphere VMDirectPath I/O：プラットフォームとデバイスの要件」(英語版:VMware vSphere VMDirectPath I/O: Requirements for Platforms and Devices)の「PCI 機能リセット」設定の問題だった。

パススルー設定したPCIeデバイスは、物理サーバ起動時に初期化しているが、接続されている仮想マシンが起動する毎にPCIeデバイスの初期化を行う必要がある。
この初期化手法をどういう風に行うか、という設定を適切に行わないと、仮想マシン側で認識できないようだ。

設定はESXi上の /etc/vmware/passthru.map で行われている。

うまく動いたQLE2540のVender ID/Product IDを「esxcfg-info」コマンドで確認すると「1077」「2523」。
これは /etc/vmware/passthru.map で「1077 2532 default false」という定義で設定されている。
意味は、初期化手法がdefaultで、fptShareableがfalseなので全体初期化になる、というもの。
全体初期化であるため、１枚に複数ポートがある場合、別の仮想マシンに割り当てることができず、同じ仮想マシンに全部のポートを割り当てる必要がある、ということになる。

動かなかったQLE2662の方は「1077」「2031」。
記載が無いので、適切な初期化方法を見つけて追加する必要がある。
KBに「PCI ホスト ブリッジ直下の PCI 機能を VMDirectPath I/O で使用するには、FLR または D3Hot リセットをサポートする必要があります」とあるため「flr」の場合と「d3d0」の場合をそれぞれ実験。
結果、「d3d0」の時のみ仮想マシン側でもデバイスを認識してくれた。

ということで、/etc/vmware/passthru.mapの最終行に「1077 2031 d3d0 default」という記載を追加した。

なお、 passthru.map の修正を行った後は、ESXiを再起動する必要がある。 

# cd /etc/vmware/passthru.map
# passthrough attributes for devices
# file format: vendor-id device-id resetMethod fptShareable
# vendor/device id: xxxx (in hex) (ffff can be used for wildchar match)
# reset methods: flr, d3d0, link, bridge, default
# fptShareable: true/default, false

# Intel 82579LM Gig NIC can be reset with d3d0
8086  1502  d3d0     default
# Intel 82598 10Gig cards can be reset with d3d0
8086  10b6  d3d0     default
8086  10c6  d3d0     default
8086  10c7  d3d0     default
8086  10c8  d3d0     default
8086  10dd  d3d0     default
# Broadcom 57710/57711/57712 10Gig cards are not shareable
14e4  164e  default  false
14e4  164f  default  false
14e4  1650  default  false
14e4  1662  link     false
# Qlogic 8Gb FC card can not be shared
1077  2532  default  false
# QLogic QL45604 cards need to be reset with "link" and cannot be shared
1077  1634  link     false
1077  1629  link     false
1077  1636  link     false
1077  1656  link     false
1077  1644  link     false
1077  1654  link     false
# LSILogic 1068 based SAS controllers
1000  0056  d3d0     default    
1000  0058  d3d0     default
# NVIDIA
10de  ffff  bridge   false
# for QLE2662
1077  2031  d3d0     default
#
投稿日:

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」という形で対処方法が記載された。

その１：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」に変更することで対処できる

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

/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が設定されている可能性がある

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

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

その２：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
#

その３：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つに増えただけですね。

その４：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"
投稿日:

FacebookのオープンソースLTE基地局OpenCellularの資料がgithubで公開されてた

2016年7月にFacebookがLTE対応の基地局をオープンソースで作る、という話があった。
→ 「Facebookが作るLTE対応のOpenCellularプロジェクト」

その後、どうなってるのかな？と調べて見たところ、githubで関連資料の公開(https://github.com/Telecominfraproject/OpenCellular)が始まっていたので、メモ書き。

「TELECOM INFRA PROJECT (TIP)」の「OpenCellular – Wireless Access Platform Design」としてプロジェクトは進行中。

プロジェクトとしてのホームページは「Open Cellular」となっている。

プロジェクトの最新進捗報告としては2017/11/08付けの「An Update from the OpenCellular Project Group」である模様。

農村向けに64/128ユーザの同時使用をサポートした出力1Wの1800MHz帯LTE基地局を作成しテストを行っている。
少ない基地局数でも広範囲をサポートできるように700/800/850MHz帯向けの基地局も開発しており、回路図や基板設計までは完成している。

「OpenCellular Power」という発電設備（太陽光発電、風力発電など）、５年以上利用可能なバッテリー、リモート監視設備を１パッケージにしたものを開発しており、「OpenCellularの基地局」と「OpenCellular Power」をセットで設置すれば、５年くらい現地に行かなくても稼働させられるようにしている。

OpenCellularはソフトウェアでいろいろやることによりコストを下げている。
この部分は、OpenCellular-SDR、という形で開発している。
現状は、FPGA部分はXILINXの「ARTIX-7」を採用している。

そして、ソフトウェアなど、いろいろが、ちょうど先週githubで公開された。
「https://github.com/Telecominfraproject/OpenCellular」

ただ、「Docs available at https://github.com/Telecominfraproject/OpenCellular/wiki」とあるものの現時点では何もない。

投稿日:

HPE 5700 スイッチの日付設定

旧H3C系の流れをくむ「HPE 5700 Switch」の設定をしていたところ、現在時刻の設定を手動で行う場合の手順がよくわからなかったのでメモ

なお、使用したfirmwareのバージョンは「HPE Comware Software, Version 7.1.045, Release 2432P01」です

・現在時刻の確認

<HPE>display clock
18:01:34 Tokyo Fri 01/26/2018
Time Zone : Tokyo add 09:00:00
<HPE>

・NTPを設定している場合の確認

<HPE>display ntp-service status
 Clock status: unsynchronized
 Clock stratum: 16
 Reference clock ID: none
 Clock jitter: 0.000000 s
 Stability: 0.000 pps
 Clock precision: 2^-17
 Root delay: 0.00000 ms
 Root dispersion: 101.79138 ms
 Reference time: 00000000.00000000  Thu, Feb  7 2036 15:28:16.000
<HPE>

上記だと「Clock status: unsynchronized」なので、NTPサーバとの同期が取れていない。

・NTPサーバに関しての情報確認

<HPE>display ntp-service session
       source          reference       stra reach poll  now offset  delay disper
********************************************************************************
    [5]xxx.xxx.xx.xx1  INIT              16     0   64    - 0.0000 0.0000 0.0000
    [5]xxx.xxx.xx.xx2  INIT              16     0   64    - 0.0000 0.0000 0.0000
    [5]xxx.xxx.xx.xx3  INIT              16     0   64    - 0.0000 0.0000 0.0000
Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.
 Total sessions: 3
<HPE>

上記はNTPサーバを３つ指定している場合の出力。
接続できていないのでreferenceが「INIT」となっている。

・時刻の設定
標準のモード(system-viewを実行してない状態)でclock datetimeコマンドを実行して設定する

<HPE>clock datetime 16:09:00 2018/01/26
<HPE>%Jan 26 16:09:00:008 2018 HPE DEV/5/DEV_CLOCK_CHANGE: -User=**-IPAddr=** ; System clock changed from 14:48:09 Tokyo Wed 01/05/2011 to 16:09:00 Tokyo Fri 01/26/2018.
<HPE>

なお、NTP設定がされている場合は、下記のように「clock protocol none」を設定してから実行しろと表示される。

<HPE>clock datetime 16:09:00 2018/01/26
To manually set the system time, execute the clock protocol none command first.
<HPE>

clock protorolはsystem-viewでないと設定できなかったので、下記のように実行する。

<HPE>system-view
System View: return to User View with Ctrl+Z.
[HPE]clock protocol none
[HPE]quit
<HPE>clock datetime 16:09:00 2018/01/26
<HPE>system-view
System View: return to User View with Ctrl+Z.
[HPE]clock protocol ntp
[HPE]quit
<HPE>

・タイムゾーンの設定
日本で使う場合は９時間ずらす設定を入れる

<HPE>system-view
System View: return to User View with Ctrl+Z.
[HPE]clock timezone Tokyo add 09:00:00
[HPE]quit
<HPE>

・NTPサーバの設定
NTPによる時刻同期を行う場合は「clock protocol ntp」を実行し、
「ntp-service unicast-server IPアドレスまたはホスト名」でNTPサーバを指定する。
NTPサーバの指定が複数ある場合は複数回実行する。

<HPE>system-view
System View: return to User View with Ctrl+Z.
[HPE]clock protocol ntp
[HPE]ntp-service unicast-server xxx.xxx.xx.xx1
[HPE]ntp-service unicast-server xxx.xxx.xx.xx2
[HPE]ntp-service unicast-server xxx.xxx.xx.xx3
[HPE]quit
<HPE>

なお、誤って登録してしまった場合は「undo ntp-service unicast-server xxx.xxx.xx.xx1」と実行すると削除できる。