ESXiで使用できるUPS連動シャットダウンソフトの情報


ESXi 6.7からvMAというVMware提供の仮想アプライアンスが使えなくなった。
LinuxベースなのだがvCenter/ESXiをCLIから操作するためのツールが導入済みなので、UPS連動シャットダウンする際によく使われていた。

ESXi6.7以降は動かなくなってしまったので、代替を探す必要がある。

Schneider Electric (APC) PowerChute Network Shutdown

APC PowerChute Network Shutdownに関する情報は「PowerChute Network Shutdownプロダクトセンター | よくあるお問い合わせ」と「PowerChuteシリーズ 対応OS表」を起点に捜索する。

PowerChute Network Shutdown v4.3 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスイメージが提供されているのでそれを使う。
PowerChute Network Shutdown v4.2 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスか、vMAにPowerShuteインストールか、を選択できる。

PowerChute Network Shutdown v4.0以降のバージョンでVMware環境を保護する場合のPowerChuteインストール先について

PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例2
PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例3

VMware HA利用時やvSAN利用時は、VMware側がユーザ操作なしに停止することを全く考慮していないため、ESXiサーバのみの環境ではうまくシャットダウンを行うことができない。

別に物理のWindowsサーバを用意し、そこからシャットダウン命令を送る必要がある。また、復電後の起動についてはもっと考えられていないため、その処理も自前でどうにかする必要がある。

PowerChute Network Shutdown for Virtualization v4.x VMware HA環境でのサポート構成」(VMware HA環境では仮想マシン停止をサポートしていない)

20180222_VxRailccトラブルシューティングセミナーvSAN環境におけるUPS構成とシャットダウンシュナイダー出口様

HPE Power Protector

HPEブランドで販売されているUPSは、HPE Power Protector(HPEPP)を使用してシャットダウンを行う。

ソフトのダウンロードは「HPE swdepot Power Protector UPS Management Software」から行える。

ESXi 6.7以降の対応について「アドバイザリ: HPE Power Protector – VMware vSphere Management Assistantのサポートが終了したため、VMware ESXi 6.7 (またはそれ以降) を実行しているHPEサーバーでHPE Power Protectorが正しく機能しない」「Advisory: HPE Power Protector – HPE Power Protector Does Not Function Correctly On HPE Servers Running VMware ESXi 6.7 (Or Later) Due to The Discontinued Support For VMware vSphere Management Assistant」に記載している。

vMA使えないから、無料で使えるdebian使って仮想マシン作って、それにHPEPPを入れろ、ということになる。

EATON Intelligent Power Protector (IPP)とIntelligent Power Manager(IPM)

日本代理店ダイトロンの製品ページ「Intellignent Power Protector」「Intelligent Power Manager

メーカページ「Eaton Intelligent Power Manager

連動シャットダウンについてはWindows仮想マシンにIPMを入れる方向性のようだ

IPM SilverかIPM Goldを使うとVMware HAとvSANを含んだシャットダウンにも対応。

VMware HAはWindows仮想マシンにIPMを入れることで対応可能。復電も対応→「シャットダウン for vCSA on vSphere HA by IPM 1.62

vSANはvSANを使っていないESXi上にvCSAとWindows仮想マシン+IPMを置くことで対応可能。復電も対応→「シャットダウン for VMware vSAN 6.6.1 by IPM 1.60

10ドルの45W USB PDアダプタMAD GIGA PD Adapterを買ってみた


aliexpressで約10ドルという怪しげなUSB PDアダプタが売っているのを発見。

20V対応で45Wまで行けるらしいので買ってみた・・・

発注から2週間ちょいで到着。

・・・「公式ページ」があるのか

しかし、2019/10/04時点ではこのUSB PDアダプタは掲載されていなかった。

箱の中身は、USB PDアダプタ本体と説明書のみ

サイズ感の比較として、RAVPower 36Wと並べて見る。

裏面

USB端子側

AC側

そして、スペック表記。これは上がMAD GIGA

MODEL: PD45W+BC5V2.1A
INPUT: AC100-240V 50/60Hz 0.8A Max
OUTPUT USB-C: 5V3A / 9V3A / 15V3A / 20V2.2A
OUTPUT USB-A: 5V2.1A
MADE IN CHINA shanzhen hexinyu technology co,Ltd

で・・・こいつ、ACプラグの折りたたみ機構がちゃんと考えられていないようで、プラグを引き起こすために指を入れるスペースが確保されておらず、爪を差し込んで引き起こす的な感じになっています。

それ以外はぱっと見問題なさそうです。

次に電源を入れてみます。

手元にあるTC66Cで検査・・・

5V3A / 9V3A / 12V3A / 15V3A / 20V3A

・・・え?ほんとに販売ページに書いてあった「Type-C: 5V/3A, 9V/3A, 12V/3A, 15V/3A, 20V/3A 」ってマジなん?

いや、筐体に書いてあるスペックには載ってないけど12V3A隠し仕様で存在してる、ってのはよくあるけど、20V3Aって60W使えるって??いや、間違いかもしれないからPower-Zでも調べて見よう

5V3A / 9V3A / 12V3A / 15V3A / 20V3A

・・・どうやら間違い無いようですね(ちなみに本編とは関係ないですがRAVPower 36Wは5V3A/9V3A/15V3A/20V2.25Aと45W使えると出ました・・・)

自宅には20Vを使うUSB PD機器がないので、先日買ったUSB PD 20Vを丸形ノートパソコン電源に変換するアダプタを使ってテスト

うちにあるDynabookだと最大で20V2Aぐらいまでの使用に留まり、45W以上いくのかは確認出来ませんでした。

まぁ、約40W使用でそこそこ熱い感じだったので超えると危険そうですけどね

EC-CUBE 4.0をSELinux有効状態のOracle Linux 7上に構築する手順(仮


EC-CUBE 4.0のテスト環境が必要になったので、Oracle Cloud上のOracle Linux 7インスタンスを立てて、その上に作成した。

が・・・公式ドキュメントはSELinux関連の設定とか触れてないし、かなり面倒だった。
厳密にやろうとするとかなりキツイので、SELinux有効の中でも簡単な対処としている。

環境初期準備

タイムゾーンを日本に設定

# timedatectl set-timezone Japan

fail2ban設定

sshアタックがあった場合にとっととIPバンするためにfail2banをインストール。
・・・いや、ターゲットにされるとホント、すごい勢いでsshアクセスの試行がありますよ。

# yum install -y fail2ban fail2ban-hostsdeny fail2ban-systemd
# systemctl enable fail2ban.service
# cat <<EOF > /etc/fail2ban/jail.local
[DEFAULT]
# 24時間以内に3回不審なアクセスがあったら24時間BAN
#bantime  = 86400
#findtime  = 86400
bantime  = 259200
findtime  = 259200
maxretry = 5

#CentOS7なのでsystemd
#backend = systemd # jail.d/00-systemd.conf で設定されてた

# 除外IP
ignoreip = 127.0.0.1 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 <除外したいIPを追加>
[sshd]
enabled = true
banaction = firewallcmd-ipset
EOF
# systemctl start fail2ban.service
#

webサーバとphp設定

phpはOracleが用意しているphp 7.2を使用するため、「oracle-php-release-el7」をインストール。現状の標準設定だとphp 7.2が標準選択されている。なお、php 7.1かphp 7.0を使うこともできるが、いまさら利点は無いので使用しない方がよい。

# yum install oracle-php-release-el7
# 

phpパッケージとhttpdをインストールして、firewall開け設定実施

# yum install -y httpd mod_ssl php php-json php-mbstring php-pdo php-xml php-zip php-mysqlnd php-intl 
# systemctl enable httpd
# systemctl start httpd
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-service=https
# firewall-cmd --reload

APCU(php-pecl-apcu)のインストールを推奨されたが、パッケージのコンフリクトが発生していたのでインストールしなかった。

SQLサーバ設定

今回はmariadbをSQLサーバとして使用した。

# yum install -y mariadb-server
# systemctl enable mariadb
# systemctl start mariadb
#

SQL起動後、ECCUBE用のデータベースを作成した。

# mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.64-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database eccube character set utf8;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all on eccube.* to cubesql@localhost identified by 'dbsqlp@ss';
Query OK, 0 rows affected (0.08 sec)

MariaDB [(none)]> exit
Bye
#

ECCUBEファイル展開

/var/www/html/eccube にEC-CUBE 4.0.3を展開した。

展開した中に.htaccessファイルが含まれていますが、標準設定では読み込まないのでApacheに設定追加を行います。 (もっとセキュリティを強化してもいいとは思いますが、面倒だったので・・・)

# cat <<EOF> /etc/httpd/conf.d/eccube.conf
<Directory "/var/www/html/eccube">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>
EOF
# systemctl restart httpd
#

で・・・SELinuxがらみがどうなるかですが、おもいっきり引っかかりまくりました。

とりあえず該当するコンテンツに対して「httpd_sys_rw_content_t」を割り当てることで対処しました。

最初は個別に対処していこうとしたのですが、インストールプロセスを進めていくと、/var/www/html/eccube全体に対して権限を要求されたため、最終的には下記となりました。

# chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube
#

とりあえず、これでEC-CUBE 4.0の初期セットアップ完了までできるようになりました。

エラーコレクション

SELinux設定をしていく中で出てきたエラー群です。

まず、 http://IPアドレス/eccube/ にアクセスすると以下が現れました。

(2/2) ContextErrorException
Warning: file_put_contents(/var/www/html/eccube/var/cache/install/EccubeInstallDebugProjectContainerDeprecations.log): failed to open stream: No such file or directory

(1/2) RuntimeException
Unable to create the cache directory (/var/www/html/eccube/var/cache/install)

このときに表示された /var/www/html/eccube/var に対して「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/var」を実行しました。

次にでたエラーは下記です。

Filesystem->copy('/var/www/html/eccube/html/template/default/assets/img/common/favicon.ico', '/var/www/html/eccube/html/user_data/assets/img/common/favicon.ico')

/var/www/html/eccube/html/user_data以下に書き込む権限がないというもの。
eccubeディレクトリ内を探すと他にも「user_data」というディレクトリがあったため、「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/html/user_data」と「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/app/template/user_data」を実行した。

最後に「権限チェック」で引っかかった。

以下のファイルまたはディレクトリに書き込み権限を付与してください。
>>☓:/var/www/html/eccube
>>☓:/var/www/html/eccube/app/Plugin
>>☓:/var/www/html/eccube/app/PluginData
>>☓:/var/www/html/eccube/app/proxy
>>☓:/var/www/html/eccube/app/template
>>☓:/var/www/html/eccube/html
>>☓:/var/www/html/eccube/vendor
<略>
>>☓:/var/www/html/eccube/vendor/ocramius/proxy-manager/README.md
>>☓:/var/www/html/eccube/vendor/ocramius/proxy-manager/composer.json
>>☓:/var/www/html/eccube/composer.json
>>☓:/var/www/html/eccube/composer.lock

ようはここまでで「httpd_sys_rw_content_t」を設定しなかった全ファイル。

「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube」を実行して再チェック・・・

>>○:アクセス権限は正常です

これでセットアップを進めることができました。

Oracle Cloud上にWindows Server 2016インスタンスを作ったら記号が入らずパスワード入力ができなかった件


Oracle Cloudの登録特典でもらえる30日有効の33000円分のクレジットがまだまだ余ってるので、Windows Server 2016インスタンスを作ってみた。

画像

初期パスワードはシステム側で自動生成される・・・と

画像

ありますね。

初回ログインはコンソール画面から行う必要があるので、上記の画面をスクロールして「リソース」の「コンソール接続」から「コンソール接続の作成」を選択

sshの公開鍵を指定して・・・

コンソール接続が「アクティブ」となったら、右側のメニューから「VNCを使用して接続」を選択

「プラットフォーム:WINDOWS」を選択して、文字列を「コピー」

Windows上でPowerShellを開いて、コピーしたものを貼り付けて実行

で・・・VNC Viewerを起動して「localhost:5900」に接続を実行すると下記の様にログイン画面が出てくる。

画像

で・・・ココで問題が発生。

パスワードを入力しようとしても 「:→;」「@→2」「^→6」「`→~」「=→+」 という感じで期待通りの入力が行えない。

Windows 10の日本語キーボード環境で「;キー」と「:キー」のどちらを押しても「;」が入力される事態。UltraVNCにあるSend Custom Keyを使用して「85」「86」を送っても、同じく「;」が入力されてしまう。

UltraVNCには「Japanese keyboard」という設定項目があるのでそれを設定しても状況は変わらず。

画像

UltraVNC
RealVNC
TigerVNC
この3つを試したところ、TigerVNCでは、Windows上のキーボード認識がUSキーボードになってるけど、実際につながっているのは日本語キーボード、という場合に相当する動きをしてくれた。

この動きであれば、日本語キーボードを英語配列だと思い込んで操作することによってなんとか記号を入力することができる(一部入力できないものもあるが、UltraVNC/RealVNCよりはずっとマシ)

TigerVNC Viewerでログインに成功し、デバイスマネージャー(Device Manager)から「Standard PS/2 Keyboard」を「Japanese PS/2 Keyboard (106/109 key)」に変更することで、日本語キーボードであっても期待通りに入力出来る環境を用意することができた。

(下記の画像はWindows Server 2012R2のだけど、Windows Server 2016もほぼ同じ)

「Standard PS/2 Keyboard」の「Properies」を開き、「Driver」タブを選択する。

「Update Driver」を選択し、下記では「Browse my computer from driver software」を選択

下記は「Let me pick from a list of device drivers on my computer」を選択

「Show compatible hardware」に入っているチェックを外す

チェックを外すと下記の様に選択肢がたくさん現れる。

下記の様に「(standard keyboards)」内の「Japanese PS/2 Keyboard (106/109 Key)」を選択し、「Next」

警告は「Yes」

変更完了

再起動して、変更を反映させます。

また、コントロールパネルの「Language」にて

「Add an input method」を選択し、リストから「QWERY Japanese」を選択し、「Add」

「Save」します。

Save実行とともに時計の横に「ENG US」が表示されますので、それをクリックすると「ENG JA」が選択できます。

これにより日本語キーボードをつかって正常に入力することが可能となります。

なお、この設定を行ってもUltraVNC,UltraVNC(Japanese Keyboard設定あり),RealVNCでは相変わらずな動作をして記号や日本語変換が行えませんでした。

Oracle Cloudでは使用状況レポートを有効にしないとVM内にアクセスエラーログがたまりまくるので注意


東京リージョンでOracle Cloud Always Freeインスタンスを作れないので、US West(Phoenix)リージョンでアカウントを作り直してOracle Linux 7インスタンスを作ってみたところ /var/log/oracle-cloud-agent/agent.log にスクリプトの実行エラーが毎秒出ている。

画像

作り直し前の方ではagent.logは正常なのに何故?と思ったら、Oracle Cloudコンソールの「アカウント管理」の「使用状況レポート」が未設定なためだった。

画像

上記にある様に「アイデンティティ」の「ポリシー」にて「ポリシーの作成」をクリックし、上記ページに書かれている「ステートメント1」「ステートメント2」を下記画面の「ポリシーステートメント」に貼り付ければOK。(名前と説明は適当につける)

なお、ステートメント2にある「<group>」は「Administrators」に置き換える必要がある。(「アイデンティティ」の「グループ」に登録済みのグループ名に置き換える)

この設定を行ったあと、agent.logへエラーを吐き出していたインスタンス上で「 systemctrl restart oracle-cloud-agent.service 」を実行することでエラーは収まりました。

画像