投稿

vCenterの動作確認のためにSTARTTLSを必須とするメールサーバを構築

背景 vCenter からのメール配信は STARTTLS に対応しているらしいのでその動作確認のために、 STARTTLS に対応したメールサーバを構築してみました。 https://kb.vmware.com/s/article/2063147   パブリッククラウドの利用や、昨今関心が高いセキュリティポリシー観点で平文の SMTP ではなく STARTTLS などで暗号化通信を行う環境が増えてくると思われます。その準備として、 vCenter サーバからのメール配信として STARTTLS を必須とするメールサーバーを構築しました。   Postfix のインストールと設定 証明書の生成 mkdir -p /etc/mail/certs/ cd /etc/mail/certs/ hostname openssl req -new -x509 -nodes -out server.pem -keyout server.pem -days 7000     Postfix のインストール yum -y install postfix     Starttls の設定 vi /etc/postfix/main.cf   以下の設定を投入 参考: https://www.postfix.org/postconf.5.html #smtpd_tls_security_level = may smtpd_tls_security_level = encrypt smtpd_tls_cert_file = /etc/mail/certs/server.pem smtpd_tls_key_file = /etc/mail/certs/server.pem ※必須にする場合は encyrpt 。任意にする場合は may にする   再起動して設定を反映 service postfix restart   設定の確認 /usr/sbin/postconf | grep -e smtpd_tls_security_level -e ...

「vSAN では、ロード バランシングに NIC チーミングは使用されません。」という説明文の解釈

vSAN は NIC チーミングのロードバランシング設定を無視する?   vSAN 関連のドキュメントに以下の記載に関連していろいろと調べてみた。     「 vSAN では、ロード バランシングに NIC チーミングは使用されません。」   上記の記載は以下のドキュメントで確認できる。   Basic NIC Teaming (vmware.com) vSAN ネットワークの設計 (vmware.com)   日本語の説明だけ読むと、以下の誤解が生まれそうな記載である。   誤解①: vSAN は NIC Teaming でロードバランシングポリシーが設定されていても常に Active/Standby で動作をする   誤解②: vSAN のロードバランシングは NIC Teaming 以外の機能を利用する   きちんと原文(英語)で前後の文脈を考慮するとそういうことではないと判断できる。 そもそも vSAN の仕組みをよく知らない人のために NIC Teaming のロードバランシング設定がどのような形で反映されるのかを確認しておく。     ①各仮想マシンが自分で vSAN データストアに直接 IO リクエストをするわけではなく、仮想マシンは稼働している ESXi に対し SCSI のリクエストを送信する ② ESXi は仮想マシンからの SCSI リクエストを vSAN データストアへの IO として処理する ③ ESXi は vSAN の IO を処理するために vSAN vmkernel port を利用する ④ vSAN vmkernel port は vDS につながっていて、 dvport ID に紐づいている ⑤ vDS のロードバランシングは dvport id 単位で実施されるため、該当の dvport id がどの Uplink を利用するかはロードバランシングポリシーによって決まる   つまり、 ESXi 上で稼働する VM から vSAN データストアへの IO リクエストは単一の vsan vmk...

iDRACの仮想コンソールにJavaで接続できない

イメージ
※本投稿は2020年に別のブログサービス(現在アクセス不可)に投稿した記事の再掲です 情報的に古い内容となっております。   VxRailなど、PowerEdge上にESXiをInstallしている場合、トラブルシューティングや初期構築などでiDRACの仮想コンソールに接続することはしばしばあると思います。 先日、ESXiのInstall用途で、iDRACの仮想コンソールにJavaで接続しようとしたら、エラーになって接続できないことがありました。   結論からいうと、iDRACのFWをUpdateするか、Javaのセキュリティファイルの設定を書き換えることで解決できました。 その時のトラブルシューティングを記します。     事象 キャプチャをとればよかったのですが、残念ながら取り損ねてしまいました。 英語でのキャプチャが欲しかったので後で事象を再現させて取ればよい、と楽観していたところ再現しなくなってしまったので取れずじまいです。   事象としては、idracの仮想コンソールにJavaで接続しようとした際に、Javaのアプレット(?)が起動した直後に「ビューワが切断された~」みたいなメッセージがでて接続できないという事象でした。   トラブルシューティング Javaのコンソールやトレースを有効化する Javaのエラーを見れば何かわかる、と思ったのでJavaのコンソールやロギングを有効化しました。 有効化は、コンパネからJavaのコントロールパネルを開き、AdvancedタブからConsoleやLoggingやTracingのチェックを入れればいいだけです。   事象を再現してログをみる コンソールとロギング・トレーシングの設定をしたら、もう一度事象を再現させて、ログを見ればよいです。 実際に記録されていたログは以下です。 2020年2月19日 4:07     Java Web Start 11.241.2.07 Using JRE version 1.8.0_241-b07 Java HotSpot(TM) Client VM JRE expiration date: 20/05/17 0:00 console.user.home = C:\Users\Administrat...