Oracle Autonomous Linuxでwordpressサーバを建ててみた

2021/04/25追記: この手順はOracle Autonomouse Linuxが通常のOracle Linuxとは異なるレポジトリで運用されていた2020年12月以前のものです。

2020年12月にOracle Autonomous Linuxでレポジトリ仕様の変更があった がありましたので、現状は普通のOracle Linux環境として設定できますので「CentOS 7 / Oracle Linux 7でWordPressサーバを建てる」を参照ください。

WebサーバをApacheではなくnginxで構成したい、という場合はこの記事を参照してもいいかもしれません。

2023/09/07追記: 2022年ごろ以降のOracle CloudではFree TierでOracle Autonomouse Linuxを使う事ができなくなっています。


Oracle CloudのTOKYOリージョンでFree tierのOracle Autonomouse Linux 7.8環境の作成が出来た。

できたんだけど、標準で提供されているレポジトリの範囲が狭く、通常のOracle Linux 7.8の標準レポジトリにも足りていない。

このため、wordpressサーバを建ててみるかと思っても、要求されるphpおよびmariadbのバージョンに足りていない。

Oracle Autonomous Linuxとしてのマニュアルがなく、ソフトウェア追加に関する制限事項等が分からないが、他に使い道も無いので、通常のOracle Linux 7.8で設定されているレポジトリとかを追加してみることにした。

注意:普通のOracle Linux 7.8やCentOS7にWordpressをインストールする場合は「CentOS 7 / Oracle Linux 7でWordPressサーバを建てる」を参照してください。

php 7.4追加編

いろいろある中、Oracle自身が出していてOracle Linux 7.8でも追加できるPHP Packages for Oracle Linuxかな、と追加してみる。

Oracle Linuxのレポジトリ設定の中からphp7.4部分を抜き出して /etc/yum.repos.d/oracle-php.repo というファイルを作成。

[ol7_developer_php74]
name=Oracle Linux $releasever PHP 7.4 Packages for Development and test ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL7/developer/php74/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

そしてphpをインストール

# yum install php
<略>
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch       Version               Repository               Size
================================================================================
Installing:
 php             x86_64     7.4.7-1.0.1.el7       ol7_developer_php74     3.4 M
Installing for dependencies:
 apr             x86_64     1.4.8-5.el7           al7                     103 k
 apr-util        x86_64     1.5.2-6.0.1.el7       al7                      91 k
 httpd           x86_64     2.4.6-93.0.1.el7      al7                     1.2 M
 httpd-tools     x86_64     2.4.6-93.0.1.el7      al7                      92 k
 mailcap         noarch     2.1.41-2.el7          al7                      30 k
 php-cli         x86_64     7.4.7-1.0.1.el7       ol7_developer_php74     5.1 M
 php-common      x86_64     7.4.7-1.0.1.el7       ol7_developer_php74     1.1 M

Transaction Summary
================================================================================
Install  1 Package (+7 Dependent packages)

Total download size: 11 M
Installed size: 47 M
Is this ok [y/d/N]: y
<略>
Installed:
  php.x86_64 0:7.4.7-1.0.1.el7

Dependency Installed:
  apr.x86_64 0:1.4.8-5.el7              apr-util.x86_64 0:1.5.2-6.0.1.el7
  httpd.x86_64 0:2.4.6-93.0.1.el7       httpd-tools.x86_64 0:2.4.6-93.0.1.el7
  mailcap.noarch 0:2.1.41-2.el7         php-cli.x86_64 0:7.4.7-1.0.1.el7
  php-common.x86_64 0:7.4.7-1.0.1.el7

Complete!
#

httpdも一緒にインストールされました。

また、wp-cliで使うphp-jsonとサイトヘルスで表示されるエラー対応としてphp-bcmath を追加します。

# yum install php-json php-bcmath
<略>
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package        Arch       Version                Repository               Size
================================================================================
Installing:
 php-bcmath     x86_64     7.4.7-1.0.1.el7        ol7_developer_php74      56 k
 php-json       x86_64     7.4.7-1.0.1.el7        ol7_developer_php74      58 k

Transaction Summary
================================================================================
Install  2 Packages

Total download size: 114 k
Installed size: 160 k
Is this ok [y/d/N]: y
<略>
#

しかし、AMP pluginで使うphp-pear-Net-Curlとサイトヘルスのphp-pecl-imagick はepel系パッケージ、サイトヘルスのphp-gd は依存パッケージのlibvpx(Oracle Linuxでは標準パッケージに含まれる)がなくインストールできなかった。

MariaDB追加編

SQLサーバのmariadb-serverパッケージについては、MariaDB Foundationからmariadb 10.5を導入することにした。

「/etc/yum.repos.d/mariadb.repo」というファイルを作り、以下の内容を入力

# MariaDB 10.5 RedHat repository list - created 2020-06-26 04:54 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.5/rhel7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
#

そののち「yum install MariaDB-server MariaDB-client」を実行してmariadb-serverをインストール

# yum install MariaDB-server MariaDB-client
<中略>
---> Package perl-Compress-Raw-Zlib.x86_64 1:2.061-4.el7 will be installed
--> Finished Dependency Resolution
Error: Package: MariaDB-client-10.5.4-1.el7.centos.x86_64 (mariadb)
           Requires: libpcre2-8.so.0()(64bit)
Error: Package: galera-4-26.4.5-1.el7.centos.x86_64 (mariadb)
           Requires: socat
Error: Package: MariaDB-server-10.5.4-1.el7.centos.x86_64 (mariadb)
           Requires: libpcre2-8.so.0()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
#

どうやら「pcre2」と「socat」がOracle Autonomous Linuxでは提供されていないパッケージであるようだ。(標準のOralce Linux 7.8ではol7_latestレポジトリに含まれている)

先ほど指定したmariadbレポジトリはRedHat Enterprise Linux 7用だったので、CentOS7用(baseurl=http://yum.mariadb.org/10.5/centos7-amd64 )に変更しても状況は変わらず。

では、とバージョンを10.4に下げてみると成功。成功時のmariadb.repoは以下

# MariaDB 10.4 RedHat repository list - created 2020-06-26 06:01 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/rhel7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
# yum install MariaDB-server MariaDB-client
<略>
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                   Arch     Version                     Repository
                                                                           Size
================================================================================
Installing:
 MariaDB-client            x86_64   10.4.13-1.el7.centos        mariadb    12 M
 MariaDB-compat            x86_64   10.4.13-1.el7.centos        mariadb   2.2 M
     replacing  mariadb-libs.x86_64 1:5.5.65-1.el7
 MariaDB-server            x86_64   10.4.13-1.el7.centos        mariadb    26 M
Installing for dependencies:
 MariaDB-common            x86_64   10.4.13-1.el7.centos        mariadb    81 k
 boost-program-options     x86_64   1.53.0-28.el7               al7       156 k
 galera-4                  x86_64   26.4.4-1.rhel7.el7.centos   mariadb   9.5 M
 perl-Compress-Raw-Bzip2   x86_64   2.061-3.el7                 al7        32 k
 perl-Compress-Raw-Zlib    x86_64   1:2.061-4.el7               al7        57 k
 perl-DBI                  x86_64   1.627-4.el7                 al7       801 k
 perl-Data-Dumper          x86_64   2.145-3.el7                 al7        47 k
 perl-IO-Compress          noarch   2.061-2.el7                 al7       259 k
 perl-Net-Daemon           noarch   0.48-5.el7                  al7        50 k
 perl-PlRPC                noarch   0.2020-14.el7               al7        35 k

Transaction Summary
================================================================================
Install  3 Packages (+10 Dependent packages)

Total download size: 51 M
Is this ok [y/d/N]: y
<略>

Installed:
  MariaDB-client.x86_64 0:10.4.13-1.el7.centos
  MariaDB-compat.x86_64 0:10.4.13-1.el7.centos
  MariaDB-server.x86_64 0:10.4.13-1.el7.centos

Dependency Installed:
  MariaDB-common.x86_64 0:10.4.13-1.el7.centos
  boost-program-options.x86_64 0:1.53.0-28.el7
  galera-4.x86_64 0:26.4.4-1.rhel7.el7.centos
  perl-Compress-Raw-Bzip2.x86_64 0:2.061-3.el7
  perl-Compress-Raw-Zlib.x86_64 1:2.061-4.el7
  perl-DBI.x86_64 0:1.627-4.el7
  perl-Data-Dumper.x86_64 0:2.145-3.el7
  perl-IO-Compress.noarch 0:2.061-2.el7
  perl-Net-Daemon.noarch 0:0.48-5.el7
  perl-PlRPC.noarch 0:0.2020-14.el7

Replaced:
  mariadb-libs.x86_64 1:5.5.65-1.el7

Complete!
#

MariaDB設定編

まず、現在のMariaDBサーバの自動起動設定を確認。

# systemctl list-unit-files|grep mariadb
mariadb.service                               disabled
mariadb@.service                              disabled
#

自動起動しない設定になっているので、自動起動するように変更する

# systemctl enable mariadb.service
Created symlink from /etc/systemd/system/mysql.service to /usr/lib/systemd/system/mariadb.service.
Created symlink from /etc/systemd/system/mysqld.service to /usr/lib/systemd/system/mariadb.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/mariadb.service to /usr/lib/systemd/system/mariadb.service.
#

続いてMariaDBの起動状況を確認

# systemctl status mariadb
● mariadb.service - MariaDB 10.4.13 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           mqmigrated-from-my.cnf-settings.conf
   Active: inactive (dead)
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
#

「Active: inactive (dead)」なので起動していないので「systemctl start mariadb」で起動する。

# systemctl start mariadb
# systemctl status mariadb -l
● mariadb.service - MariaDB 10.4.13 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           mqmigrated-from-my.cnf-settings.conf
   Active: active (running) since Fri 2020-06-26 15:08:58 JST; 37s ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 9464 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 9419 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 9417 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 Main PID: 9430 (mysqld)
   Status: "Taking your SQL requests now..."
   CGroup: /system.slice/mariadb.service
           mq9430 /usr/sbin/mysqld

Jun 26 15:08:57 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:57 0 [Note] InnoDB: 10.4.13 started; log sequence number 60972; transaction id 21
Jun 26 15:08:57 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:57 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Jun 26 15:08:57 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:57 0 [Note] InnoDB: Buffer pool(s) load completed at 200626 15:08:57
Jun 26 15:08:57 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:57 0 [Note] Plugin 'FEEDBACK' is disabled.
Jun 26 15:08:57 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:57 0 [Note] Server socket created on IP: '::'.
Jun 26 15:08:58 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:58 0 [Note] Reading of all Master_info entries succeeded
Jun 26 15:08:58 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:58 0 [Note] Added new Master_info '' to hash table
Jun 26 15:08:58 oci.adosakana.local mysqld[9430]: 2020-06-26 15:08:58 0 [Note] /usr/sbin/mysqld: ready for connections.
Jun 26 15:08:58 oci.adosakana.local mysqld[9430]: Version: '10.4.13-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
Jun 26 15:08:58 oci.adosakana.local systemd[1]: Started MariaDB 10.4.13 database server.
#

MariaDB上にWordpress用のデータベースを作成する。

# mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.4.13-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 DB名 character set utf8;
Query OK, 1 row affected (0.000 sec)

MariaDB [(none)]> grant all on DB名.* to wordpress@localhost identified by 'w@rdpress';
Query OK, 0 rows affected (0.002 sec)

MariaDB [(none)]> quit
Bye
#

firewall設定

まずfirewallを開ける。

現状のポート開放状況を確認するため「firewall-cmd –list-all」を実行

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
#

httpとhttpsを追加して、設定を再読込して反映

# firewall-cmd --permanent --zone=public --add-service=http
success
# firewall-cmd --permanent --zone=public --add-service=https
success
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client http https ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
#

Webサーバ設定

nginxへの切り替え

最初はApacheを使おうとしたのですが、Mozilla SSL Configuration Generators推奨設定を行うにはmod_rewriteやmod_headersが含まれていませんでした。

Apache関連の追加レポジトリを探すよりはWebサーバをnginxに切り替えてnginx公式レポジトリを使った方が良いのでは?ということで「nginx: Linux packages」を元に追加

/etc/yum.repos.d/nginx.repo に下記を記載

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
# yum install nginx
<略>
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package      Arch          Version                   Repository           Size
================================================================================
Installing:
 nginx        x86_64        1:1.18.0-1.el7.ngx        nginx-stable        772 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 772 k
Installed size: 2.7 M
Is this ok [y/d/N]: y
<略>
#

また、あとで確認したところphp-fpmも必要だったのでインストールします。これはサービスとしても起動します。

# yum install php-fpm
Loaded plugins: langpacks
Resolving Dependencies
--> Running transaction check
---> Package php-fpm.x86_64 0:7.4.7-1.0.1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package      Arch        Version                Repository                Size
================================================================================
Installing:
 php-fpm      x86_64      7.4.7-1.0.1.el7        ol7_developer_php74      1.7 M

Transaction Summary
================================================================================
Install  1 Package

Total download size: 1.7 M
Installed size: 6.1 M
Is this ok [y/d/N]: y
<略>
# systemctl list-unit-files|grep php
php-fpm.service                               disabled
# systemctl enable php-fpm.service
Created symlink from /etc/systemd/system/multi-user.target.wants/php-fpm.service to /usr/lib/systemd/system/php-fpm.service.
# systemctl start php-fpm.service
#

現在のApacheとnginxの自動起動設定を確認するため「systemctl list-unit-files|grep -e http -e nginx」を実行

# systemctl list-unit-files|grep -e http -e nginx
httpd.service                                 disabled
nginx-debug.service                           disabled
nginx.service                                 disabled
#

どちらも起動状態にないことを確認。

nginxを自動起動にしてから起動

# ystemctl enable nginx.service
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.
# systemctl start nginx.service
# systemctl status nginx.service -l
● nginx.service - nginx - high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2020-06-26 15:58:01 JST; 5s ago
     Docs: http://nginx.org/en/docs/
  Process: 10409 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
 Main PID: 10410 (nginx)
   CGroup: /system.slice/nginx.service
           tq10410 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
           mq10411 nginx: worker process

Jun 26 15:58:01 oci.adosakana.local systemd[1]: Starting nginx - high performance web server...
Jun 26 15:58:01 oci.adosakana.local systemd[1]: Can't open PID file /var/run/nginx.pid (yet?) after start: No such file or directory
Jun 26 15:58:01 oci.adosakana.local systemd[1]: Started nginx - high performance web server.
#

ブラウザからアクセスできるか確認

Let’s encryptを利用したSSLアクセス有効化

Oracle Autonomous Linuxにはcertbotもdehydratedもありません。

certbotはpython環境を使い大がかりになってしまうので、dehydratedの方を使用します。

githubのdehydratedからダウンロードします。

# wget https://github.com/dehydrated-io/dehydrated/archive/master.tar.gz
# tar xfz master.tar.gz
# ls -l
total 88
drwxrwxr-x. 4 root root  4096 Apr 29 04:36 dehydrated-master
-rw-r--r--. 1 root root 82951 Jun 26 16:32 master.tar.gz 
# 

dehydrated と config を配置します。

# cp dehydrated-master/dehydrated /usr/local/sbin/
# ls -l /usr/local/sbin/dehydrated
-rwxr-xr-x. 1 root root 69787 Jun 26 16:35 /usr/local/sbin/dehydrated
# mkdir /usr/local/etc/dehydrated
# cp dehydrated-master/docs/examples/config /usr/local/etc/dehydrated
# ls -l /usr/local/etc/dehydrated
total 8
-rw-r--r--. 1 root root 4656 Jun 26 16:36 config
#

/usr/local/etc/dehydrated/domains.txt にSSL証明書を取得するドメイン名を列挙します。

dehydratedがSSL証明書取得の際に使用する作業用Web公開ディレクトリ /var/www/dehydrated に関する設定をnginxに行います。

まず、ディレクトリを作成

# mkdir /var/www/dehydrated
#

次にnginx側の設定 を /etc/nginx/conf.d/default.conf のlisten 80に関するlocaltionに下記を追加。

location ^~ /.well-known/acme-challenge {
        alias /var/www/dehydrated;
        break;
}

そして、nginx再起動

# systemctl restart nginx
#

準備が出来たのでdehydratedで登録を開始。

# dehydrated --register
# INFO: Using main config file /usr/local/etc/dehydrated/config

To use dehydrated with this certificate authority you have to agree to their terms of service which you can find here: https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf

To accept these terms of service run `/usr/local/sbin/dehydrated --register --accept-terms`.
#  /usr/local/sbin/dehydrated --register --accept-terms
# INFO: Using main config file /usr/local/etc/dehydrated/config
+ Generating account key...
+ Registering account key with ACME server...
+ Fetching account URL...
+ Done!
# 

前処理が完了したので、実際のSSL証明書発行処理を実施。

# /usr/local/sbin/dehydrated --cron
# INFO: Using main config file /usr/local/etc/dehydrated/config
Processing oci.adosakana.local
 + Creating new directory /usr/local/etc/dehydrated/certs/oci.adosakana.local ...
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for oci.adosakana.local
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for oci.adosakana.local authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
#

SSL証明書は /usr/local/etc/dehydrated/certs/FQDN名ディレクトリ に作成されます。

nginx側の設定はMozilla SSL Configuration Generator を元に /etc/nginx/conf.d/default.conf を書き換えます。

# generated 2020-06-26, Mozilla Guideline v5.4, nginx 1.17.7, OpenSSL 1.0.1e, intermediate configuration, no OCSP
# https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.0.1e&ocsp=false&guideline=5.4
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location ^~ /.well-known/acme-challenge {
        alias /var/www/dehydrated;
    }
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /usr/local/etc/dehydrated/certs/FQDN名ディレクトリ/fullchain.pem;
    ssl_certificate_key /usr/local/etc/dehydrated/certs/FQDN名ディレクトリ/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
    ssl_dhparam /usr/local/etc/dehydrated/certs/dhparam;

    # intermediate configuration
    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS (ngx_http_headers_module is required) (63072000 seconds)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

Mozilla的にはffdhe2048.txtの配置を推奨するようなので、下記でダウンロードして配置します。

# curl https://ssl-config.mozilla.org/ffdhe2048.txt > /usr/local/etc/dehydrated/certs/dhparam
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   423  100   423    0     0    680      0 --:--:-- --:--:-- --:--:--   681
#

そして、nginxを再起動します。

# systemctl restart nginx
#

ブラウザからhttpアクセスすると、httpsアクセスに変換された上で404 Not Found表示となることを確認します。

Let’s のSSL証明書は定期的に更新処理を実行する必要があります。

/etc/cron.d/dehydrated に下記の内容のファイルを作成します。(EPEL収録のdehydratedパッケージの内容を参考にした)

45 1 * * 4 root test -s /usr/local/etc/dehydrated/domains.txt && /usr/local/sbin/dehydrated --cron

WordPress設定

/var/www/html/wordpress にtar.gzの中身を展開

# tar xfz latest.tar.gz
# ls -l
total 11956
-rw-r--r--. 1 root   root      12238031 Jun 11 06:49 latest.tar.gz
drwxr-xr-x. 5 nobody nfsnobody     4096 Jun 11 06:48 wordpress
# chown -R apache:apache wordpress/
# ls -l
total 11956
-rw-r--r--. 1 root   root   12238031 Jun 11 06:49 latest.tar.gz
drwxr-xr-x. 5 apache apache     4096 Jun 11 06:48 wordpress
#

WordPress用のnginx設定は「nginx WordPress recipe」 を参考に作成した。元はphp-cgiを使用していたが、php-cgiパッケージはないためphp-fpm使用に切り替えている。

# Upstream to abstract backend connection(s) for php
upstream php {
    server unix:/tmp/php-fpm.socket;
    server 127.0.0.1:9000;
}

# generated 2020-06-26, Mozilla Guideline v5.4, nginx 1.17.7, OpenSSL 1.0.1e, intermediate configuration, no OCSP
# https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.0.1e&ocsp=false&guideline=5.4
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location ^~ /.well-known/acme-challenge {
        alias /var/www/dehydrated;
    }
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /usr/local/etc/dehydrated/certs/FQDN名ディレクトリ/fullchain.pem;
    ssl_certificate_key /usr/local/etc/dehydrated/certs/FQDN名ディレクトリ/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
    ssl_dhparam /usr/local/etc/dehydrated/certs/dhparam;

    # intermediate configuration
    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS (ngx_http_headers_module is required) (63072000 seconds)
    add_header Strict-Transport-Security "max-age=63072000" always;

    root /var/www/html/wordpress;

    index index.php;
    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
        include fastcgi_params;
        fastcgi_intercept_errors on;
        fastcgi_pass php;
        #The following parameter can be also included in fastcgi_params file
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        log_not_found off;
    }
}

phpにMySQLアクセス用パッケージを入れていなかった・・・

またphpの日本語処理に必要なやつもなかったので「yum install php-mysql php-mbstring」でインストールして、php-fpmを再起動

# yum install php-mysql php-mbstring
<略>
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package          Arch       Version              Repository               Size
================================================================================
Installing:
 php-mbstring     x86_64     7.4.7-1.0.1.el7      ol7_developer_php74     497 k
 php-mysqlnd      x86_64     7.4.7-1.0.1.el7      ol7_developer_php74     228 k
Installing for dependencies:
 php-pdo          x86_64     7.4.7-1.0.1.el7      ol7_developer_php74     121 k

Transaction Summary
================================================================================
Install  2 Packages (+1 Dependent package)

Total download size: 845 k
Installed size: 3.2 M
Is this ok [y/d/N]: y
<略>
# systemctl restart php-fpm.service
#

成功

wp-config.php については手動で/var/www/html/wordpress/wp-config.php に作成する必要があったが、それ以外は問題無く実行された。

また、Wordpress上のプラグインインストールや更新についても特に問題なく実行できた。


2020/06/30追記

WordPressのAMPプラグインを動かそうとしたら「dom」が有効にできない、と言われた。

これはphp-xmlに含まれるので「yum install php-xml」で追加したあと「systemctl restart php-fpm.service」を実行した。


2020/07/14追記

wordpressのインポートを行おうとしたらファイルが大きくて「413 Request Entity Too Large」とエラーになった。

まず、 /etc/php.ini の「post_max_size」と「upload_max_filesize」の値を変更して、「systemctl restart php-fpm」を実行

; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
;post_max_size = 8M
post_max_size = 10M
; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
;upload_max_filesize = 2M
upload_max_filesize = 20M

また、「/etc/nginx/conf.d/default.conf」のポート443に関するserver定義内で「client_max_body_size」の設定を追加し、「systemctl restart nginx」で再起動します。

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    client_max_body_size 20M;
<略>
}

これでアップロードが成功するようになりました。

RHEL7でVcXsrv経由とvSphereコンソール経由のglxinfoの出力差を調べた

vSphere 6.7環境に構築しているRHEL7環境で、X-Windowによるアプリ表示を行う際、アクセス環境によって使えるX-Windowの機能が違うようなので差を調べようと思った。

とりあえず「glxinfo」を実行すればいいのかな、と「vSphere 6.7のVMware Remote Console 11.0.0上でstartxした環境」と「Windows10上でVcXsrvを起動した環境」とで差を調べて見た。

有意な差がでたところを重点的にピックアップしていく。

VcXsrv環境
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
vSphere環境
direct rendering: Yes

直接コンソールに出力しているので「direct renderring:yes」になってますね。

次に「server glx」部分で共通している箇所

server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context,
    GLX_ARB_create_context_profile,
    GLX_ARB_fbconfig_float,
    GLX_ARB_framebuffer_sRGB,
    GLX_ARB_multisample,
    GLX_EXT_create_context_es2_profile,
    GLX_EXT_fbconfig_packed_float,
    GLX_EXT_framebuffer_sRGB,
    GLX_EXT_import_context,
    GLX_EXT_visual_info,
    GLX_EXT_visual_rating,
    GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method,
    GLX_SGIS_multisample,
    GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group,
    GLX_SGI_make_current_read,

server glxでVcXsrvのみある項目

    GLX_ARB_create_context_robustness,
    GLX_SGI_swap_control

逆にvSphereのみある項目

    GLX_EXT_create_context_es_profile,
    GLX_EXT_libglvnd,
    GLX_EXT_texture_from_pixmap,

次の「client glx」はどちらも共通で、差はなかった。

client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample,
    GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
    GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float,
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync

「GLX」について。まずは共通部分

GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context,
    GLX_ARB_create_context_profile,
    GLX_ARB_fbconfig_float,
    GLX_ARB_framebuffer_sRGB,
    GLX_ARB_get_proc_address,
    GLX_ARB_multisample,
    GLX_EXT_create_context_es2_profile,
    GLX_EXT_fbconfig_packed_float,
    GLX_EXT_framebuffer_sRGB,
    GLX_EXT_import_context,
    GLX_EXT_visual_info,
    GLX_EXT_visual_rating,
    GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent,
    GLX_OML_swap_method,
    GLX_SGIS_multisample,
    GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group,
    GLX_SGI_make_current_read,

VcXsrvにのみあるもの

    GLX_ARB_create_context_robustness,
    GLX_SGI_swap_control

vSphereにのみあるもの

    GLX_EXT_create_context_es_profile,
    GLX_EXT_texture_from_pixmap,
    GLX_MESA_query_renderer,

Open GLのバージョンについてはそれぞれ違う。まずはVcXsrv

OpenGL vendor string: Intel
OpenGL renderer string: Intel(R) HD Graphics 530
OpenGL version string: 1.4 (4.6.0 - Build 26.20.100.7263)

次にvSphere

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)
OpenGL version string: 2.1 Mesa 17.0.1
OpenGL shading language version string: 1.30

vSphere環境の方はOpenGLシェーダも搭載されているようだ。

「OpenGL extentions」の違いはかなり大きい。まず共通部分

OpenGL extensions:
    GL_3DFX_texture_compression_FXT1,
    GL_ARB_depth_texture,
    GL_ARB_draw_buffers,
    GL_ARB_fragment_program,
    GL_ARB_fragment_program_shadow,
    GL_ARB_multisample,
    GL_ARB_multitexture,
    GL_ARB_occlusion_query,
    GL_ARB_point_parameters,
    GL_ARB_point_sprite,
    GL_ARB_shadow,
    GL_ARB_texture_border_clamp,
    GL_ARB_texture_compression,
    GL_ARB_texture_cube_map,
    GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine,
    GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3,
    GL_ARB_texture_mirrored_repeat,
    GL_ARB_texture_non_power_of_two,
    GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix,
    GL_ARB_vertex_program,
    GL_ARB_window_pos,
    GL_ATI_draw_buffers,
    GL_EXT_abgr,
    GL_EXT_bgra,
    GL_EXT_blend_color,
    GL_EXT_blend_equation_separate,
    GL_EXT_blend_func_separate,
    GL_EXT_blend_minmax,
    GL_EXT_blend_subtract,
    GL_EXT_draw_range_elements,
    GL_EXT_fog_coord,
    GL_EXT_framebuffer_object,
    GL_EXT_multi_draw_arrays,
    GL_EXT_packed_pixels,
    GL_EXT_point_parameters,
    GL_EXT_rescale_normal,
    GL_EXT_secondary_color,
    GL_EXT_separate_specular_color,
    GL_EXT_shadow_funcs,
    GL_EXT_stencil_two_side,
    GL_EXT_stencil_wrap,
    GL_EXT_texture3D,
    GL_EXT_texture_edge_clamp,
    GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine,
    GL_EXT_texture_lod_bias,
    GL_EXT_texture_rectangle,
    GL_IBM_texture_mirrored_repeat,
    GL_INGR_blend_func_separate,
    GL_NV_blend_square,
    GL_NV_texgen_reflection,
    GL_NV_texture_rectangle,
    GL_SGIS_generate_mipmap,
    GL_SGIS_texture_border_clamp,
    GL_SGIS_texture_edge_clamp,
    GL_SGIS_texture_lod,
    GL_SUN_multi_draw_arrays

VcXsrvのみあるもの

    GL_EXT_clip_volume_hint,
    GL_EXT_texture_compression_s3tc,
    GL_EXT_texture_filter_anisotropic,

vSphereのみあるものはかなり多く以下

    GL_AMD_conservative_depth,
    GL_AMD_draw_buffers_blend,
    GL_AMD_seamless_cubemap_per_texture,
    GL_AMD_shader_stencil_export,
    GL_AMD_shader_trinary_minmax,
    GL_APPLE_packed_pixels,
    GL_APPLE_vertex_array_object,
    GL_ARB_ES2_compatibility,
    GL_ARB_ES3_compatibility,
    GL_ARB_arrays_of_arrays,
    GL_ARB_base_instance,
    GL_ARB_blend_func_extended,
    GL_ARB_buffer_storage,
    GL_ARB_clear_buffer_object,
    GL_ARB_clip_control,
    GL_ARB_color_buffer_float,
    GL_ARB_compressed_texture_pixel_storage,
    GL_ARB_conditional_render_inverted,
    GL_ARB_conservative_depth,
    GL_ARB_copy_buffer,
    GL_ARB_copy_image,
    GL_ARB_cull_distance,
    GL_ARB_debug_output,
    GL_ARB_depth_buffer_float,
    GL_ARB_depth_clamp,
    GL_ARB_draw_buffers_blend,
    GL_ARB_draw_elements_base_vertex,
    GL_ARB_draw_instanced,
    GL_ARB_explicit_attrib_location,
    GL_ARB_explicit_uniform_location,
    GL_ARB_fragment_coord_conventions,
    GL_ARB_fragment_shader,
    GL_ARB_framebuffer_object,
    GL_ARB_framebuffer_sRGB,
    GL_ARB_get_program_binary,
    GL_ARB_get_texture_sub_image,
    GL_ARB_half_float_pixel,
    GL_ARB_half_float_vertex,
    GL_ARB_instanced_arrays,
    GL_ARB_internalformat_query,
    GL_ARB_internalformat_query2,
    GL_ARB_invalidate_subdata,
    GL_ARB_map_buffer_alignment,
    GL_ARB_map_buffer_range,
    GL_ARB_multi_bind,
    GL_ARB_occlusion_query2,
    GL_ARB_pixel_buffer_object,
    GL_ARB_program_interface_query,
    GL_ARB_provoking_vertex,
    GL_ARB_robustness,
    GL_ARB_sampler_objects,
    GL_ARB_seamless_cube_map,
    GL_ARB_seamless_cubemap_per_texture,
    GL_ARB_separate_shader_objects,
    GL_ARB_shader_bit_encoding,
    GL_ARB_shader_objects,
    GL_ARB_shader_stencil_export,
    GL_ARB_shader_texture_lod,
    GL_ARB_shading_language_100,
    GL_ARB_shading_language_420pack,
    GL_ARB_shading_language_packing,
    GL_ARB_stencil_texturing,
    GL_ARB_sync,
    GL_ARB_texture_compression_rgtc,
    GL_ARB_texture_cube_map_array,
    GL_ARB_texture_gather,
    GL_ARB_texture_mirror_clamp_to_edge,
    GL_ARB_texture_multisample,
    GL_ARB_texture_query_levels,
    GL_ARB_texture_rg,
    GL_ARB_texture_rgb10_a2ui,
    GL_ARB_texture_stencil8,
    GL_ARB_texture_storage,
    GL_ARB_texture_storage_multisample,
    GL_ARB_texture_swizzle,
    GL_ARB_texture_view,
    GL_ARB_timer_query,
    GL_ARB_transform_feedback2,
    GL_ARB_transform_feedback3,
    GL_ARB_transform_feedback_instanced,
    GL_ARB_uniform_buffer_object,
    GL_ARB_vertex_array_bgra,
    GL_ARB_vertex_array_object,
    GL_ARB_vertex_attrib_binding,
    GL_ARB_vertex_buffer_object,
    GL_ARB_vertex_shader,
    GL_ARB_vertex_type_10f_11f_11f_rev,
    GL_ARB_vertex_type_2_10_10_10_rev,
    GL_ATI_blend_equation_separate,
    GL_ATI_fragment_shader,
    GL_ATI_separate_stencil,
    GL_ATI_texture_compression_3dc,
    GL_ATI_texture_env_combine3,
    GL_ATI_texture_mirror_once,
    GL_EXT_copy_texture,
    GL_EXT_draw_buffers2,
    GL_EXT_draw_instanced,
    GL_EXT_framebuffer_blit,
    GL_EXT_framebuffer_multisample,
    GL_EXT_framebuffer_multisample_blit_scaled,
    GL_EXT_framebuffer_sRGB,
    GL_EXT_gpu_program_parameters,
    GL_EXT_packed_depth_stencil,
    GL_EXT_packed_float,
    GL_EXT_pixel_buffer_object,
    GL_EXT_polygon_offset,
    GL_EXT_polygon_offset_clamp,
    GL_EXT_provoking_vertex,
    GL_EXT_shader_integer_mix,
    GL_EXT_subtexture,
    GL_EXT_texture,
    GL_EXT_texture_array,
    GL_EXT_texture_compression_latc,
    GL_EXT_texture_compression_rgtc,
    GL_EXT_texture_cube_map,
    GL_EXT_texture_env_dot3,
    GL_EXT_texture_integer,
    GL_EXT_texture_mirror_clamp,
    GL_EXT_texture_object,
    GL_EXT_texture_sRGB,
    GL_EXT_texture_sRGB_decode,
    GL_EXT_texture_shared_exponent,
    GL_EXT_texture_snorm,
    GL_EXT_texture_swizzle,
    GL_EXT_timer_query,
    GL_EXT_transform_feedback,
    GL_EXT_vertex_array,
    GL_EXT_vertex_array_bgra,
    GL_IBM_multimode_draw_arrays,
    GL_IBM_rasterpos_clip,
    GL_KHR_context_flush_control,
    GL_KHR_debug,
    GL_MESA_pack_invert,
    GL_MESA_shader_integer_functions,
    GL_MESA_texture_signed_rgba,
    GL_MESA_window_pos,
    GL_MESA_ycbcr_texture,
    GL_NV_conditional_render,
    GL_NV_depth_clamp,
    GL_NV_fog_distance,
    GL_NV_light_max_exponent,
    GL_NV_packed_depth_stencil,
    GL_NV_primitive_restart,
    GL_NV_texture_env_combine4,
    GL_OES_EGL_image,
    GL_OES_read_format,

また、vSphere環境側にのみ「OpenGL ES profile」も存在してた。

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 17.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:
    GL_APPLE_texture_max_level,
    GL_EXT_blend_func_extended,
    GL_EXT_blend_minmax,
    GL_EXT_discard_framebuffer,
    GL_EXT_draw_buffers,
    GL_EXT_draw_elements_base_vertex,
    GL_EXT_map_buffer_range,
    GL_EXT_multi_draw_arrays,
    GL_EXT_polygon_offset_clamp,
    GL_EXT_read_format_bgra,
    GL_EXT_separate_shader_objects,
    GL_EXT_texture_border_clamp,
    GL_EXT_texture_format_BGRA8888,
    GL_EXT_texture_rg,
    GL_EXT_texture_type_2_10_10_10_REV,
    GL_EXT_unpack_subimage,
    GL_KHR_context_flush_control,
    GL_KHR_debug,
    GL_NV_draw_buffers,
    GL_NV_fbo_color_attachments,
    GL_NV_read_buffer,
    GL_NV_read_depth,
    GL_NV_read_depth_stencil,
    GL_NV_read_stencil,
    GL_OES_EGL_image,
    GL_OES_EGL_image_external,
    GL_OES_EGL_sync,
    GL_OES_compressed_ETC1_RGB8_texture,
    GL_OES_depth24,
    GL_OES_depth_texture,
    GL_OES_depth_texture_cube_map,
    GL_OES_draw_elements_base_vertex,
    GL_OES_element_index_uint,
    GL_OES_fbo_render_mipmap,
    GL_OES_get_program_binary,
    GL_OES_mapbuffer,
    GL_OES_packed_depth_stencil,
    GL_OES_rgb8_rgba8,
    GL_OES_standard_derivatives,
    GL_OES_stencil8,
    GL_OES_surfaceless_context,
    GL_OES_texture_3D,
    GL_OES_texture_border_clamp,
    GL_OES_texture_float_linear,
    GL_OES_texture_half_float_linear,
    GL_OES_texture_npot,
    GL_OES_vertex_array_object,
    GL_OES_vertex_half_float

この下に「GLX Visuals」というのもありますが、細かすぎるので、省略します。

Oracle CloundのAlways Freeインスタンスが死んだ

Oracleさんから「Production Event Notification: Oracle Cloud Infrastructure Compute – Terminated Instance for Tenant:~」というお手紙が3通来た。

障害でインスタンスを止めた。データは失われてないから新しくインスタンス作ってね。

え・・・?

というわけでログインして確認。

ない・・・

ブートボリュームは?

ちゃんとあった。

お知らせは何かあるかな?と確認

書いてある内容はメールとだいたい一緒。

しかたがないので作り直し。ブートボリュームで作り直すボリュームを選択し、「インスタンスの作成」を選択。

ん?可用性ドメインが「ロード中」のまま動かないのですが・・・

詳細を開くとあるので大丈夫かな?sshキーも指定して「作成」

無事作成完了です。

教訓としては常用するのであればパブリックIPアドレスは予約済みで取得しておかないとダメというところですね。

あと、出先でもインスタンス再作成ができるよう、sshキーのメモをどこかに用意しておかないと・・・

ESXiで使用できるUPS連動シャットダウンソフトの情報 2023/11/24修正

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

ESXi6.7以降は動かなくなってしまったので、代替を探す必要がある。
(APC PowerChute Bussiness EditionはvMAのみ対応)

APC PowerChute Network Shutdown 5.0

2023年6月にPowerChute Network Shutdown 5.0が出ていた

シュナイダーエレクトリック、電源管理ソフトウェアの最新版「PowerChute Network Shutdown v5.0」を発売

上記リリース内の「これまでスクリプトによるコマンド設定が必要だったシャットダウンシーケンスを、画面上から簡単に制御できる機能を備えました」の意味は、ssh連動がWeb UIから設定できる、と読んだのだが、Install Guide/User Guide見てみたのだがssh周りは従来通りに見え、releasenoteを読むとvSANクラスタや、vSphere vCLS、VMware HA周りの処理が組み込まれた、という意味の模様

PowerChute Network Shutdown v5.0製品pdf資料

ライセンスとしては、「Windows &Linux用」「特定機種(UNIX/MacOS)用」「仮想化環境用」と「VxRail用」がある

v5.0としてのリリースノートやインストールガイド、ユーザガイドのpdfが製品リンクから直接はられておらず「PowerChuteシリーズ 各種マニュアル」からアクセスできるのだが、2023/11/24時点ではいくつかのファイルについては権限がないとして読むことが出来ない。

英語版ドキュメント
PowerChute Network Shutdown v5.0 – Release Notes
PowerChute Network Shutdown v5.0 – Installation Guide
PowerChute Network Shutdown v5.0 – Standard User Guide
PowerChute Network Shutdown v5.0 – VMware User Guide
PowerChute Network Shutdown v5.0 – Hyper-V and SCVMM User Guide
PowerChute Network Shutdown v5.0 – Nutanix User Guide

Webページとして公開されている手順など

PowerChute Network Shutdown v5.0 既知の問題 [最新バージョン]
PowerChute Network Shutdown v5.x 初期セットアップ手順 – シングル構成 Windows, Linux

PowerChute Network Shutdown v5.0 for Windows & Linux 対応OS表
PowerChute Network Shutdown v5.0.1 for Specialized OS 対応OS表
PowerChute Network Shutdown v5.0 for Virtualization 対応OS表
JavaはSolaris以外はAdoptOpenJDKを使用(SolarisはOracle純正ライセンスを別途調達とのこと)

PowerChute Network Shutdown v5.0ではNetwork Management Card 2(NMC2)のサポートが終了。またNMC3についてもfirmware v2.2.1.1以降がサポートとなる。

vCenterが存在しない単体ESXi環境で連動させるためにAPC純正仮想アプライアンスを展開した場合、vCenterがないと設定出来ない項目があるため、エラーとなる。その場合は「PowerChute Network Shutdown v4.4.3, v5.x スタンドアロンESXi ホストに仮想アプライアンスをデプロイした際にアクセスできない」の手順で設定する(この手順自体は、PCNS v4.3~v5.0共通)

APC電源管理ソフトウェア PowerChuteの選択方法
PowerChuteシリーズ 対応OS表

APC PowerChute Network Shutdown 4.5

2022年9月に「PowerChute Network Shutdown v4.5」が発売されたことが発表された。(当時のURL APC PowerChute Network Shutdown 4.5 for DELL VxRail )

海外では2022年7月ぐらいにはDELL VxRail向け PCNS v4.5としてOVAファイルとしてリリースされていました。それ以外の環境向けには引き続き PCNS v4.4が提供されています(対応表)。

v4.4はVxRail専用なのかと思っていたのですが、v5.0リリースの比較表にはv4.5も他で動くヤツがある的な記述に・・・

APC PowerChute Network Shutdown 4.4

2020年10月登場の新バージョン:シュナイダーエレクトリック、電源管理ソフトウェアの最新版「PowerChute Network Shutdown v4.4」を発売

PowerChute Network Shutdown v4.4 ご紹介(最新版)」「PowerChute Network Shutdown v4.4 for Windows & Linux 対応OS表」「PowerChute Network Shutdown v4.4 for Virtualization 対応OS表」「PowerChute Network Shutdown v4.4 既知の問題PCNSユーザーズガイド」「PCNSの各種設定例

PowerChute Network Shutdown Operating System, Processor, JRE and Browser Compatibility Chart

PowerChute Network Shutdown ドキュメント」「PowerChuteシリーズ 各種マニュアル

PCNS v4.4でもJavaを使うという点には変更はない(今回はOpenJRE 14.0.2)。OpenJREのアップデートツールも添付されているとのこと。

今回のトピックは、VMware vSAN、Nutanix AOS、Microsoft Azure Stack HCI、Cisco HyperFlex、HPE Simplivityの自動シャットダウンをPCNS管理インタフェース上から設定できるようになった、ということ。

また、sshでアクセスし連動シャットダウンを仕掛けることが可能になったため、NetApp ONTAP 9.xとの連動シャットダウンなどもサポートした、とのこと。

Windows版は日本語インタフェース用インストーラと英語インタフェース用インストーラが別になっているので注意

Schneider Electric (APC) PowerChute Network Shutdown

2022/03/31追記:この項目にあるv4.1~v4.3に関するリンクはAPCサイトの更新に伴い動かないリンクばかりになっている。

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

PowerChute Network Shutdown v4.3 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスイメージが提供されているのでそれを使う。vSphere 7/ESXi 7.0サポートに関しても記載されている。
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仮想環境) – 構成例1
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構成とシャットダウンシュナイダー出口様

富士通のWebにある「PowerChute Network Shutdown for Virtualization v4.3」(PDF版)でvSphere, Hyper-V, Nutanix AHV環境でどういう風に機器を配置すればいいのか分かりやすい絵付きで解説されている。

HPE Power Protector

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

ソフトのダウンロードはなかなか見つけにくい。以前は「HPE swdepot Power Protector UPS Management Software」だったが2020年10月ぐらいから死んでいる。2021年10月/2022年3月の段階ではドキュメント上で「Download updates from HPE Software Depot」というリンクがあるが、リンク先が動作していない。なんとかして後述の個別ダウンロードリンクを発見する必要がある。

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を入れろ、ということになる。

2023/11/24時点2023/02/03時点での最新ドキュメントはhttp://www.hpe.com/support/PowerProtector_Manuals」もしくはHPE Power Protector User Guide」で英語は2021年2月版、日本語は2020年4月版のようだ。

2019/12/06リリース版のダウンロードリンク
HPE Power Protector Windows版 v2.02.087 (HPE Power Protector (HPEPP) Clientのインストール方法 (Windows))
HPE Power Protector Linux版 v2.02.087 (HP UPS – HP Power Protector (HPPP) Client のインストール方法 (Linux))

2020/10/23リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.02.089
HPE Power Protector – Linux版 v2.02.089

2021/08/12リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.03.091
HPE Power Protector – Linux版 v2.03.091

2022/02/09リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.04.094
HPE Power Protector – Linux版 v2.04.094

2022/11/21リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.05.096
HPE Power Protector – Linux x86版 v2.05.096
HPE Power Protector – Linux x64版 v2.05.096

2023/09/20リリース版のダウンロードリンク
HPE Power Protector – Microsoft Windows v2.06.098
HPE Power Protector – Linux x64 v2.06.098
HPE Power Protector – Linux x86 v2.06.098

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

日本代理店ダイトロンの製品ページ「Intellignent Power Protector」「Intelligent Power Manager(旧バージョン)」「Intelligent Power Manager 2

メーカページ「Eaton Intelligent Power Manager

2020年からIPMのライセンス体系が変更になり、また海外ではIPM2も登場した。IPM1とIPM2が互換性がなく、日本国内向けではIPM2は非サポートとなっているようだ(2023年時点ではサポートされた)。

連動シャットダウンについてはWindows仮想マシンにIPMを入れる方向性のようだ IPM2では仮想アプライアンスを使用して行う形となる。

IPM Optimize/(旧名)IPM Silver/ (旧名) IPM Goldを使うライセンスを買うとVMware HAとvSANを含んだシャットダウンにも対応。

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

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

2023/06/08追記:日本でも2023年月ごろから「Intelligent Power Manager 2」の取り扱いが開始されていた。IPM2ではvSphere仮想環境向けアプライアンスイメージファイルでの提供となっている。(Hyper-V,VirtualBox向けファイルもある)

IPM2を使った場合「【IPM2】IPM2 on VMwareのダウンロードから起動まで」「【IPM2】VMware HAのシャットダウン」「【IPM2】VMware HA+共有ストレージのシャットダウン

その他、IPM2関連記事群

オムロン VirtuAttendant

無償のUPS管理ソフト「PowerAct Pro」はvMA利用のためESXi 6.5までになっている(PowerAct Pro Slave Agent VMware版 ダウンロード)

有償のUPS管理ソフト「VirtuAttendant」はESXi 7.0対応版が出ていて、手順説明はリンク先に掲載されている。なお、ライセンス料金は1つのvCenter Server環境につき192500円。

また「構成事例/設定ガイド」の「Nutanix / vSAN / 3Tier の構成事例〈ネットワークカード〉」にESXi6.7に対応したVSAN構成時の設定ガイドvSphere+RAID構成時の設定ガイドが掲載されている。

2023/06/08追記

通常のサーバ向けはUPS管理マスタサーバにWebサーバを建てる「PowerAct Pro」と建てない「PowerAttendant Lite」とオープンソース版「Simple Shutdown Software(オープンソース版)

仮想環境向けは、VirtuAttendant と UPS本体に追加するSNMP管理モジュールSC21 の2製品となっている。

その他参考資料

NEC編

ESMPRO/AutomaticRunningController ダウンロードページ」にある「VMware ESXi 環境における電源管理ソフトウェアの導入(第37版 2020/01/31)(第41 版 2021.11.30)にNECのESMPRO/AutomaticRunningControllerと連携させる場合の詳細解説が書かれている。

富士通編

PRIMERGY 技術情報の「仮想システムでのUPS利用ガイド」にて、PowerChute Network Shutdown Enterprise Editionを使用する場合の説明がある。

また、富士通サーバ ISV/IHV技術情報の「APC PowerChute Network Shutdown」と「APC PowerChute Network Shutdown(過去事例)」とにてAPC UPSを使って行われた各種検証内容に関するレポートが公開されている。

VMware編

VMwareのKnowledgeに「VMware ESXi ホストへの APC Powerchute Network Shutdown ソフトウェアのインストール (1007036)」というのが掲載されたが、2020年2月掲載なのにvMAを利用するバージョンでRelated ProductsもESXi 5.5.xが最新という古い記述になっている。

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では相変わらずな動作をして記号や日本語変換が行えませんでした。