2018年2月17日土曜日

CyberPowerのUPS「CPJ500」を導入してQNAPのNASに接続した話

冬になると電子レンジなどの調理器具だけでなく、エアコンや電気ヒーターも同時に使用するようになるため、ブレーカーを落としてしまうことが何度かあった。自宅ではNASや検証用途に利用している常時稼働のPCがあり、復旧対応の負荷が結構大きいことから、UPS (無停電電源装置)を導入することにした。

製品選定

さっそくUPSをAmazonで調べ、以下理由からCyberPowerの「CPJ500」を選定した。

・安価であること
・USBで制御が可能なこと
・コンセントが4口ではなく6口あること



同価格帯ではオムロンのUPSもあり候補に挙がったが、こちらはコンセントが4口となっていることがネックとなる。自宅環境では4口では不足することから、CyberPowerのUPSを購入することになった。

QNAPのNASとUSB接続してみる

本UPSをQNAPのNASとUSB接続すると、NAS側からUPSの状態を確認することができ、万が一停電時になった際は、自動でNASをパワーオンすることが可能になる。

設定方法は簡単で、UPSに付属するUSBケーブルを使ってUPSとNASを接続すれと、自動でNAS側でUPSを認識する。
※NASにて「USB UPS device plugged in」のメッセージが表示される


NSAにログインし、「コントロールパネル」→「外部デバイス」を選択し、UPSタブを開けば、「UPS情報」欄にUPSのバッテリー情報や、バッテリーを利用した際の推定稼働時間が表示される。


UPS異常時の動作確認

ためしにUPSの電源を抜き、バッテリーでの電源供給に切り替えてみたところ、NAS側でUPSを「異常」として認識した。


UPS異常となった際と、UPSが正常に復旧した際には、NASにて警告メッセージが表示される。

・異常時:Power loss detected on UPS. System would be shutdown after 5 minute(s).
・復旧時:Power has returned to UPS. Canceling shutdown.


NASにてSNMP Trapの設定をしておけば、監視装置にUPS異常のTrapを飛ばすことも可能である。以下は、UPS異常時のTrapをZabbixで検知した際のメール通知の内容となる。

【異常時】
------------------------------
2018.02.12 06:42:01

Trigger: SNMP Trap
Trigger status: PROBLEM
Trigger severity: High
Trigger URL:

Item values:

1. SNMP Trap log (t3013qnap:snmptrap[]): 06:41:58 2018/02/12 .1.3.6.1.4.1.24681.1.10.0.2 Normal "Status Events" 192.168.33.13 - Power loss detected on UPS. System would be shutdown after 5 minute(s).
------------------------------

【復旧時】
------------------------------
2018.02.12 06:44:01

Trigger: SNMP Trap
Trigger status: PROBLEM
Trigger severity: High
Trigger URL:

Item values:

1. SNMP Trap log (t3013qnap:snmptrap[]): 06:43:55 2018/02/12 .1.3.6.1.4.1.24681.1.10.0.2 Normal "Status Events" 192.168.33.13 - Power has returned to UPS. Canceling shutdown.
------------------------------

これでブレーカーが落ちた際にも、いちいちNASやサーバーの起動が不要となり、安心して冬を過ごすことができるようになった。特にNASに関しては、様々なデータが保管されており、停止に伴うデータ破損の影響が大きいため、データ保護の観点からも安心材料を得ることができた。

2018年2月13日火曜日

Amazon EchoがWi-Fiに接続できない場合の対処手順

先日、Amazon Echoの招待メールを受け取ったので、さっそく購入してみた。

Andoroid端末にAmazon Alexaアプリをインストールして初期セットアップを進めていたのだが、Wi-Fiの設定箇所で、いくら正しいパスワードを入れても接続に失敗する事象が発生した。

失敗時のメッセージは以下となるが、Wi-Fiに接続できなかったと表示されているだけで、原因については記載されていない。何度か接続をリトライしても同じ事象が発生したため、再現性はあるようだ。

------------------------------
Your device was unable to connect to your Wi-Fi network. Please exit setup and try again. Visit Help for troubleshooting tips.
------------------------------


Webでもは類似事象が多数報告されている。失敗した端末とは別の端末を使ったら接続できたとか、何度も接続作業を繰り返したら成功したとか、そのような内容が多いように見える。

結果的に私の環境では、Androidのアプリではなく、PCを使ってAlexaのWeb画面でWi-Fi接続設定をすることで成功したが、簡単には成功しなかったので、本記事で手順をまとめておく。

環境

・Wi-Fiルーター:NEC Aterm WG1800HP2
・無線方式  : IEEE802.11ac (5GHz)
・暗号化方式 :WPA2-PSA(AES)

Amazon Echo Wi-Fi接続手順

1. Amazon AlexaのWebサイトにログイン

まず、以下URLにアクセスする。ログインIDとパスワードの入力を求められるので、Amazonと同じものを入力してログインする。

https://alexa.amazon.co.jp/

2. 新しいデバイスを追加

左メニューの「設定」を選択し、「新しいデバイスをセットアップ」を選択する。


3. セットアップするデバイスを選択

セットアップ対象の機器を選択する。今回は「Echo」を選択した。


4. 言語を選択

「日本語」を選択する。


5. Wi-Fi接続設定の開始

「まずWi-Fiに接続しましょう」と言われるので、「Wi-Fiに接続」ボタンを選択する。


「computerとEchoを接続」の画面が表示される。このタイミングより、Amazon Echo本体がWi-Fiのアクセスポイントとして動作するようになる。


PCのWi-Fi選択画面を開くと、「Amazon-XXX」という名前のアクセスポイントが見えてくるはずなので、それを選択することで、PCとAmazon EchoがWi-Fiで直接接続される。


問題なければ画面は自動的に遷移し、「Echoに接続しました」と表示される。


6. Wi-Fiネットワークを選択 (1回目)

次の画面ではAmazon Echoから見えるWi-Fiアクセスポイントが表示されるので、接続先を選択する。




選択するとパスワード入力画面に遷移するので、正しいパスワードを入力して「接続」を選択する。


数分接続待ちが発生したのち、Wi-Fi接続に失敗する。これは、Androidで表示されたエラーと(英語と日本語の違いはあるが)全く同じである。

------------------------------
デバイスを登録中にエラーが発生しました。トラブルシューティングの方法についてはヘルプをご覧ください。
エラー1
------------------------------


7. Wi-Fiネットワークを選択 (2回目)

ここでめげずに、再度同じパスワードを入力して「接続」を選択すると、今度は別メッセージで失敗する。

------------------------------
認証の期限が切れました。computerをインターネットに接続し、アプリからログアウトして、もう一度試してください。
------------------------------


どうやらWi-Fi接続時に発生した待ち時間の間に、Amazon Echoの設定可能時間を超過してしまったようだ。

8. 同じ作業を繰り返す

念のため、Amazon AlexaのWeb画面からサインアウトし、再度手順「1」~「5」を繰り返して、「Wi-Fiネットワークを選択」の画面まで遷移する。

9. Wi-Fiネットワークを選択 (3回目)

ここでうまくいっていれば、先ほど接続に失敗したアクセスポイントが「接続済み」になっているはずである。


「接続済み」の状態で該当のアクセスポイントを選択すると、パスワード入力が不要の状態となっている。ここで、「接続」ボタンを押下する。


10. 接続に成功

「EchoがWi-Fiに接続されました」と表示され、ようやく接続に成功する。


まとめ

どうにかAmazon EchoをWi-Fiに接続することができたが、Amazon EchoのWi-Fi接続手順は煩雑となっており、ITリテラシーが高くないユーザーにおいては、敷居が高いと感じた。実際、WebではAmazon EchoのWi-Fi接続作業で苦労している情報を多数見つけることができる状況であり、今後改善していかなければ、Amazon Echoの普及の足枷になると感じた。

2018年2月5日月曜日

Postfixで"Permission denied"でファイル送信が失敗する

Postfixでメール送信を行う際に、以下のようなエラーで失敗することがある。

# postqueue -p
------------------------------
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
782A818BD67B      429 Sat Jan 13 21:05:10  ex-1@example.com
(maildir delivery failed: create maildir file /var/spool/virtual/example1.com/ex1-1/Maildir/tmp/1515845435.P3212.t1110rh72: Permission denied)
                                         ex1-1@example1.com

-- 0 Kbytes in 1 Request.
------------------------------

これはSELinuxが動いていることが原因となるので、以下の通り無効化してしまえばよい。
※SELinuxを無効化したくない場合は、適切にSELinuxを設定するしかないが、本記事の範囲外とする。

# getenforce
------------------------------
Enforcing
------------------------------
# setenforce 0
# getenforce
------------------------------
Permissive
------------------------------

上記はOS再起動をするともとに戻ってしまうので、以下設定ファイルを修正して完全にSELinuxを無効化しておく。

# cat /etc/selinux/config
------------------------------
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted
------------------------------

2018年1月30日火曜日

Postfixで"unable to create lock file"でファイル送信が失敗する

Postfixでメールサーバー構築を行っていた際に、以下のようなメッセージが表示されて、メール配送に失敗する事象が発生した。

# postqueue -p
------------------------------
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
E632018BD679      429 Sat Jan 13 20:36:21  ex-1@example.com
(delivery failed to mailbox /var/spool/virtual/example1.com/ex1-1/Maildir: unable to create lock file /var/spool/virtual/example1.com/ex1-1/Maildir.lock: No such file or directory)
                                         ex1-1@example1.com

-- 0 Kbytes in 1 Request.
------------------------------

上記エラーをWebで調べても、なかなか同一事象が記載されたサイトがなく、解決に苦労したため、本記事にてエラーの原因と解決方法について記載する。

原因と解決方法

1つのメールサーバーで複数ドメインを扱う必要があったため、バーチャルメールボックスにてPostfixを設定していた。ユーザーとメールボックス紐づけは、/etc/postfix/vmailboxのファイルに以下のように記載をしていた。

# cat /etc/postfix/vmailbox
------------------------------
ex-1@example.com      example.com/ex-1/Maildir
ex-2@example.com      example.com/ex-2/Maildir
ex1-1@example1.com    example1.com/ex1-1/Maildir
ex2-1@example2.com    example2.com/ex2-1/Maildir
------------------------------

当初、上記記載に誤りはないものと考えていたが、結果としては前述したメール配送の失敗が発生した。

いろいろ切り分けた結果、以下のように記載を修正することで解決した。ユーザーのメールボックスの指定する際には、最後に「/」が必要だった。解決した後だから言えるが、たいしたことのない問題だった。

------------------------------
ex-1@example.com      example.com/ex-1/Maildir/
ex-2@example.com      example.com/ex-2/Maildir/
ex1-1@example1.com    example1.com/ex1-1/Maildir/
ex2-1@example2.com    example2.com/ex2-1/Maildir/
------------------------------

2018年1月22日月曜日

ESXiの仮想ネットワークアダプタ「E1000」は、1Gbps以上の速度が出る

ESXi 6.0の仮想環境において、主に使用される仮想ネットワークアダプタ (以下、仮想NIC)は以下となっている。
※()内は、各NICのリンクスピードを示す。
  • E1000 (1Gbps)
  • E1000E (1Gbps)
  • VMXNET 3 (10Gbps)
近年の仮想環境では、10Gbps以上の物理ネットワーク接続が主流になっているので、仮想マシンのNICにおいても1Gbps以上の通信を必要とする場合は、リンクスピードが10GbpsとなっているVMXNET 3を利用する必要があると思っていた。

しかし、実際にはそうではなく、E1000のような1Gbpsの仮想NICであっても、それ以上の通信速度が出るらしい。今回、それを確かめるため、速度測定を実施してみた。

測定環境

測定環境は以下の通り。下図の①②の2パターンの仮想NICの組み合わせにて測定を行う。送信側のサーバーに巨大ファイルを配置し、sftpを使ってそのファイルをgetする際の通信速度をdstatコマンドで確認する。


通信プロトコルにsftpを使っているが、Linuxですぐに試せるファイルコピーの方法がこれしか思いつかなかったというだけの理由で選択した。sftpは通信暗号化のオーバーヘッドがありそうなので、ネットワーク計測を正確に行いたい場合は、ちょっと微妙な選択かもしれない。今回はざっくり通信速度を確認することが目的なので、問題ないものとする。

測定結果

①VMXNET 3の場合

まずはVMXNET 3の測定を行う。ethtoolコマンドでNICのリンクスピードを確認すると、10Gbpsのリンクスピードとなっていることがわかる。

# ethtool eth0
------------------------------
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        MDI-X: Unknown
        Supports Wake-on: uag
        Wake-on: d
        Link detected: yes
------------------------------

sftpでファイル転送中のdstatの結果は以下の通り。黄色箇所で1Gbpsを超えていることがわかる。これはVMXNET 3が10Gbpsの仮想NICであるため、なんら不思議なことではない。

# dstat
------------------------------
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
 14  21  61   0   0   4|   0   104k| 376k   46M|   0     0 |9400  6232
 52  39   1   0   0   8|   0     0 |1027k  134M|   0     0 |  10k   18k
 58  30   6   0   0   6|   0     0 | 959k  159M|   0     0 |5653    22k
 56  29  11   0   0   4|   0    16k|1000k  151M|   0     0 |5149    21k
  5   4  91   0   0   0|   0     0 |  99k   16M|   0     0 | 636  2342
 38  33  23   0   0   6|   0     0 | 753k   98M|   0     0 |  19k   13k
 59  34   2   0   0   5|   0    28k|1175k  167M|   0     0 |7417    22k
 55  26  13   0   0   6|   0     0 | 973k  154M|   0     0 |4695    21k
 33  16  47   0   0   4|   0     0 | 548k   87M|   0     0 |2901    12k
  0   0 100   0   0   0|   0    16k|  60B  390B|   0     0 | 151   289
------------------------------

②E1000の場合

次に、E1000の測定を行う。NICのリンクスピードを確認すると、1Gbpsとなっていることがわかる。

# ethtool eth1
------------------------------
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
------------------------------

sftpでファイル転送中のdstatの結果は以下の通り。黄色箇所で1Gbpsを超えていることがわかる。VMXNET 3と比べても、遜色のない速度が出ている。

# dstat
------------------------------
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
 54  35   0   0   1  10|   0    28k|1047k  155M|   0     0 |6759    20k
 54  24  17   0   1   4|   0     0 | 910k  148M|   0     0 |5158    19k
 34  21  41   0   0   3|   0     0 | 625k  101M|   0     0 |3490    14k
  0   0 100   0   0   0|   0    16k|  60B  390B|   0     0 | 168   297
 17  11  68   3   0   1|3720k  140k| 148k   23M|   0     0 |3283  3515
 55  27   4   0   4  10|   0     0 |1146k  154M|   0     0 |  15k   21k
 61  29   1   0   1   8|   0    36k|1131k  177M|   0     0 |6189    23k
 53  25  12   0   1   9|   0     0 | 907k  153M|   0     0 |5137    20k
  7   4  87   0   1   1|   0     0 | 108k   18M|   0     0 | 861  2613
 ------------------------------

以上より、ESXiの仮想環境の仮想NICは、リンクスピードが通信速度の上限となるわけではなく、それ以上の通信速度が出せることがわかった。

ESXiでは仮想マシン作成時に、選択したOSに合わせて適切な仮想NICがデフォルトで選ばれるようになっているので、特に理由がなければ変更せずに使っても問題はなさそうだ。ただし、一般的にはE1000よりもVMXNET 3の方がパフォーマンスが上であると言われているため、ネットワークのパフォーマンスがシビアな環境ではVMXNET 3に変えることも考慮した方がよいだろう。

参考

・仮想マシンのネットワーク アダプタを選択する (1036627)
https://kb.vmware.com/s/article/1036627

2018年1月16日火曜日

Windows Server 2012以降で.Net Framework 3.5をインストールする方法 (代替ソースパスの設定)

Windows Server 2012以降のOSでは、「サーバーマネージャー」の「役割と機能の追加」にて、.Net Framework 3.5を単純にインストールしようとすると失敗する。


この場合、「代替ソースパス」を指定することで解消するが、代替ソースパスを知らないと、どこを指定してよいものかわからないので、本手順にて代替ソースパスの設定手順について記載する。

手順

1. 予め、Windows Serverのインストールメディアをマウントしておく。今回はDドライブにマウントした想定で手順を記載する。

2. 「サーバーマネージャー」の「役割と機能の追加」を開き、「機能」の項目にて、「.Net Framework 3.5 Features」にチェックを付ける。


3. 確認画面で、「代替ソースパスを指定する必要がありますか?」という警告が表示されることを確認する。


4. ダイアログボックス下部の「代替ソースパスの指定」の文字をクリックする。


5. 代替ソースパスの指定にて、以下を指定する。今回はDドライブにWindows Serverのインストールメディアがマウントされている想定なので、環境に合わせてドライブレターは変更すること。また、この指定パスは、Windows Server 2012以降のインストールメディアで、すべて共通となっている。

 D:\sources\sxs


6. 「インストール」ボタンを押してしばらくすると、インストールが正常に完了するはずである。



2018年1月11日木曜日

Windows Server 2016で定期的にAdvapiがログイン失敗 (イベントID 4625)する問題

Windows Server 2016の評価版をインストールし使い始めたのだが、ログオンプロセスがAdvapiという名前のログイン失敗(イベントID 4625)が、1日に1、2回程度の間隔で定期的に発生するということがわかった。

この事象には、以下記事で述べたログイン失敗検知をZabbixで実装しているため気付くことができた。

・Zabbixを使ってWindowsとLinuxのログイン失敗を監視する
https://tech-mmmm.blogspot.jp/2017/06/zabbixwindowslinux.html

特にログイン失敗を監視していないような環境では特に気にしなくてもよいかもしれないが、発生条件と対策について調べてみた。しかし、本件に関する対策は、2018年1月時点では存在しないようである。本記事では、本事象の発生条件と、実施した対策について記載する。

事象

以下がイベントログ セキュリティの失敗の監査のメッセージとして表示される。セキュリティIDが「NULL SID」でログオンプロセスが「Advapi」となっており、通常ユーザーのログイン失敗ではないと想定される。

------------------------------
ログの名前:         Security
ソース:           Microsoft-Windows-Security-Auditing
日付:            2018/01/06 7:48:39
イベント ID:       4625
タスクのカテゴリ:      ログオン
レベル:           情報
キーワード:         失敗の監査
ユーザー:          N/A
コンピューター:       t1082w216.intrat.local
説明:
アカウントがログオンに失敗しました。

サブジェクト:
セキュリティ ID: SYSTEM
アカウント名: T1082W216$
アカウント ドメイン: INTRAT
ログオン ID: 0x3E7

ログオン タイプ: 5

ログオンを失敗したアカウント:
セキュリティ ID: NULL SID
アカウント名: -
アカウント ドメイン: -

エラー情報:
失敗の原因: ログオン中にエラーが発生しました。
状態: 0xC0000073
サブ ステータス: 0xC0000073

プロセス情報:
呼び出し側プロセス ID: 0x138
呼び出し側プロセス名: C:\Windows\System32\svchost.exe

ネットワーク情報:
ワークステーション名: -
ソース ネットワーク アドレス: -
ソース ポート: -

詳細な認証情報:
ログオン プロセス: Advapi  
認証パッケージ: Negotiate
移行されたサービス: -
パッケージ名 (NTLM のみ): -
キーの長さ: 0

~(以下略)~
------------------------------

発生条件

以下URLに同様の事象について記載されていた。

・KB3213986 Causes Logon Failures When Starting BITS Service - Please fix
https://windowsserver.uservoice.com/forums/304618-installation-and-patching/suggestions/18475483-kb3213986-causes-logon-failures-when-starting-bits

発生条件は、以下2つであることが記載されている。
  1. KB3213986がインストールされている
  2. BITS (Background Intelligent Transfer Service)が起動時
実際にイベントログを見ると、BITS起動のログとログイン失敗のタイミングは、秒数まで含めて、同一タイミングとなっていた。



また、先ほど記載したURLでは、この問題を修正するようMicrosoftに提言する内容となっているが、コメント欄を見る限りでは、残念ながら修正したという内容は記載されていない。

実施した対策 (効果なし)

①パッチのアンインストールを試みる

原因となっているOSパッチ「KB321396」は、Windows Server 2016に最初からインストールされており、アンインストールも不可となっていた。
※アンインストール可能な場合は、以下画面の「整理」の欄に「アンインストール」が表示される。


②OSパッチを最新化する

Windows Updateを行い、OSパッチを最新化してみたが、事象は改善しなかった。

③BITSを停止させる

BITSを停止することで解消するか確認してみた。「サービス」を開き、「Background Intelligent Transfer Service」を確認すると、「スタートアップの種類」が「手動」になっているはず。こちらを「無効」変更した。


しかし、無効にしてもOSが定期的に手動に変更してしまうようで、BITSを停止しても事象は改善しなかった。

上記3点の対応を実施しても事象は改善しないことがわかった。特に影響はなさそうな事象ではあるので、監視で検知しないよう監視マネージャー側で抑止するしかなさそうだ。