Quantcast
Channel: OSAKANA TAROのメモ帳
Viewing all 1106 articles
Browse latest View live

Oracle Cloudですでに作成済みのネットワークに対してIPv6を有効にする方法

$
0
0

Oracle CloudはこれまでIPv6が提供されてなかったのですが、4/15に「IPv6 on Oracle Cloud Infrastructure」でIPv6提供が全体に開始されたとのことなので試してみた。

既存のOracle CloudインスタンスをIPv6対応にするための設定を開始。

まずは「仮想クラウドネットワーク(VNC)」一覧を開く

画像

最初はIPv6 CIDRブロックが割り当てられていない。

画像

「IPv6 CIDRブロックの追加」を選択

画像

すると、IPv6アドレスが追加される

画像

次に、VNC配下にあるサブネットに対してIPv6アドレスを割り当て・・・

画像
画像
画像

「NotAuthorizedOrNotFound」というエラーになる。

最初にためしたのは4/28に、PhoenixリージョンとTokyoリージョンで、どちらも同じエラーになっていた。

で・・・5/12になって検索すると、コマンドでなら成功するらしい、という情報を発見した。

Oracle Cloud 甲骨文云启用原生 IPv6 地址详细教程 – 简单、通用、免费、双栈更香
Oracle Cloud 支持 IPv6 了

これをTokyoリージョンで試してうまくいったので、Phoenixリージョンでも実施しようとしてみたところ、こちらでは、そのそも↑で失敗していたはずの操作が成功・・・

どうやら修正されつつあるようです。

というわけで、両方の手順をまとめました。

GUI操作が成功する場合

サブネットの編集でIPv6 CIDRブロックを行ってみて、成功するのであれば問題ありません。

kここnこのこ

このあと、後半にある仮想マシンインスタンスに対する設定を行います。

サブネットへのIPv6アドレス設定が失敗する場合

GUI操作で失敗する場合は、コマンド操作を行います。

Oracle CloudのWeb UIにログインして、Cloud Shellを開いてコマンドを実行

まず、コンパートメントのIDを確認

username@cloudshell:~ (ap-tokyo-1)$ oci iam compartment list
{
  "data": [
    {
      "compartment-id": "ocid1.tenancy.oc1..<略>",
      "defined-tags": {},
      "description": "IPv6\u7528\u30cd\u30c3\u30c8\u30ef\u30fc\u30af",
      "freeform-tags": {},
      "id": "ocid1.compartment.oc1..<略>",
      "inactive-status": null,
      "is-accessible": null,
      "lifecycle-state": "ACTIVE",
      "name": "IPv6_network",
      "time-created": "2021-04-28T07:09:50.554000+00:00"
    },
    {
      "compartment-id": "ocid1.tenancy.oc1..<略>",
      "defined-tags": {},
      "description": "idcs-e97e3212f2c9483ca8b9d1f0efa22062|22560888|OSAKANA OSAKANA NET 504302",
      "freeform-tags": {},
      "id": "ocid1.compartment.oc1..<略>",
      "inactive-status": null,
      "is-accessible": null,
      "lifecycle-state": "ACTIVE",
      "name": "ManagedCompartmentForPaaS",
      "time-created": "2019-09-19T10:16:44.796000+00:00"
    }
  ]
}
username@cloudshell:~ (ap-tokyo-1)$ 

上記出力の「compartment-id」にある「ocid1.tenancy.oc1~」が必要な値です。

これで、サブネットにつけられているIDを確認します。

username@cloudshell:~ (ap-tokyo-1)$ oci network subnet list --compartment-id ocid1.tenancy.oc1..<略>
{
  "data": [
    {
      "availability-domain": null,
      "cidr-block": "10.0.1.0/24",
      "compartment-id": "ocid1.tenancy.oc1..<略>",
      "defined-tags": {},
      "dhcp-options-id": "ocid1.dhcpoptions.oc1.ap-tokyo-1.<略>",
      "display-name": "IPv6 \u30c6\u30b9\u30c8",
      "dns-label": null,
      "freeform-tags": {},
      "id": "ocid1.subnet.oc1.ap-tokyo-1.<略>",
      "ipv6-cidr-block": "xxxx:xxxx:8000:f501::/64",
      "ipv6-virtual-router-ip": "fe80::200:17ff:fec9:f071",
      "lifecycle-state": "AVAILABLE",
      "prohibit-internet-ingress": false,
      "prohibit-public-ip-on-vnic": false,
      "route-table-id": "ocid1.routetable.oc1.ap-tokyo-1.<略>",
      "security-list-ids": [
        "ocid1.securitylist.oc1.ap-tokyo-1.<略>"
      ],
      "subnet-domain-name": null,
      "time-created": "2021-04-28T04:44:55.872000+00:00",
      "vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.<略>",
      "virtual-router-ip": "10.0.1.1",
      "virtual-router-mac": "00:00:17:C9:F0:71"
    },
    {
      "availability-domain": "xkXd:AP-TOKYO-1-AD-1",
      "cidr-block": "10.0.0.0/24",
      "compartment-id": "ocid1.tenancy.oc1..<略>",
      "defined-tags": {},
      "dhcp-options-id": "ocid1.dhcpoptions.oc1.ap-tokyo-1.<略>",
      "display-name": "\u30d1\u30d6\u30ea\u30c3\u30af\u30fb\u30b5\u30d6\u30cd\u30c3\u30c8xkXd:AP-TOKYO-1-AD-1",
      "dns-label": null,
      "freeform-tags": {},
      "id": "ocid1.subnet.oc1.ap-tokyo-1.<略>",
      "ipv6-cidr-block": null,
      "ipv6-virtual-router-ip": null,
      "lifecycle-state": "AVAILABLE",
      "prohibit-internet-ingress": false,
      "prohibit-public-ip-on-vnic": false,
      "route-table-id": "ocid1.routetable.oc1.ap-tokyo-1.<略>",
      "security-list-ids": [
        "ocid1.securitylist.oc1.ap-tokyo-1.<略>"
      ],
      "subnet-domain-name": null,
      "time-created": "2019-09-19T10:20:05.710000+00:00",
      "vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.<略>",
      "virtual-router-ip": "10.0.0.1",
      "virtual-router-mac": "00:00:17:C9:F0:71"
    }
  ]
}
username@cloudshell:~ (ap-tokyo-1)$ 

最初のブロックは新規で作ったIPv6が有効になっているもので「IPv6 テスト」という名前になっています。コマンド出力上では日本語が有効になっていないようです。

後ろのブロックがデフォルトで作成された「パブリック・サブネットxkXd:AP-TOKYO-1-AD-1」です。これに対してIPv6アドレスを付与する設定を行います。

どんなIPv6アドレスがつけられるかは、サブネット/VNC設定画面の「IPv6 CIDRブロック」を参照します。

「xxxx:xxxx:8000:f500::/56」となっています。

Oracle Cloudでは各サブネットに対して「xxxx:xxxx:8000:f5??::/64」を割り当てることになっているため下記の様に実行します。

username@cloudshell:~ (ap-tokyo-1)$ oci network subnet update --subnet-id ocid1.subnet.oc1.ap-tokyo-1.<略> --ipv6-cidr-block xxxx:xxxx:8000:f502::/64
{
  "data": {
    "availability-domain": "xkXd:AP-TOKYO-1-AD-1",
    "cidr-block": "10.0.0.0/24",
    "compartment-id": "ocid1.tenancy.oc1..<略>",
    "defined-tags": {},
    "dhcp-options-id": "ocid1.dhcpoptions.oc1.ap-tokyo-1.<略>",
    "display-name": "\u30d1\u30d6\u30ea\u30c3\u30af\u30fb\u30b5\u30d6\u30cd\u30c3\u30c8xkXd:AP-TOKYO-1-AD-1",
    "dns-label": null,
    "freeform-tags": {},
    "id": "ocid1.subnet.oc1.ap-tokyo-1.<略>",
    "ipv6-cidr-block": "xxxx:xxxx:8000:f502::/64",
    "ipv6-virtual-router-ip": "fe80::200:17ff:fec9:f071",
    "lifecycle-state": "UPDATING",
    "prohibit-internet-ingress": false,
    "prohibit-public-ip-on-vnic": false,
    "route-table-id": "ocid1.routetable.oc1.ap-tokyo-1.<略>",
    "security-list-ids": [
      "ocid1.securitylist.oc1.ap-tokyo-1.<略>"
    ],
    "subnet-domain-name": null,
    "time-created": "2019-09-19T10:20:05.710000+00:00",
    "vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.<略>",
    "virtual-router-ip": "10.0.0.1",
    "virtual-router-mac": "00:00:17:C9:F0:71"
  },
  "etag": "e457a894"
}
username@cloudshell:~ (ap-tokyo-1)$ 

設定が反映されたかを確認します。

username@cloudshell:~ (ap-tokyo-1)$ oci network subnet list --compartment-id ocid1.tenancy.oc1..<略>
{
  "data": [
    {
      "availability-domain": null,
      "cidr-block": "10.0.1.0/24",
      "compartment-id": "ocid1.tenancy.oc1..<略>",
      "defined-tags": {},
      "dhcp-options-id": "ocid1.dhcpoptions.oc1.ap-tokyo-1.<略>",
      "display-name": "IPv6 \u30c6\u30b9\u30c8",
      "dns-label": null,
      "freeform-tags": {},
      "id": "ocid1.subnet.oc1.ap-tokyo-1.<略>",
      "ipv6-cidr-block": "xxxx:xxxx:8000:f501::/64",
      "ipv6-virtual-router-ip": "fe80::200:17ff:fec9:f071",
      "lifecycle-state": "AVAILABLE",
      "prohibit-internet-ingress": false,
      "prohibit-public-ip-on-vnic": false,
      "route-table-id": "ocid1.routetable.oc1.ap-tokyo-1.<略>",
      "security-list-ids": [
        "ocid1.securitylist.oc1.ap-tokyo-1.<略>"
      ],
      "subnet-domain-name": null,
      "time-created": "2021-04-28T04:44:55.872000+00:00",
      "vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.<略>",
      "virtual-router-ip": "10.0.1.1",
      "virtual-router-mac": "00:00:17:C9:F0:71"
    },
    {
      "availability-domain": "xkXd:AP-TOKYO-1-AD-1",
      "cidr-block": "10.0.0.0/24",
      "compartment-id": "ocid1.tenancy.oc1..<略>",
      "defined-tags": {},
      "dhcp-options-id": "ocid1.dhcpoptions.oc1.ap-tokyo-1.<略>",
      "display-name": "\u30d1\u30d6\u30ea\u30c3\u30af\u30fb\u30b5\u30d6\u30cd\u30c3\u30c8xkXd:AP-TOKYO-1-AD-1",
      "dns-label": null,
      "freeform-tags": {},
      "id": "ocid1.subnet.oc1.ap-tokyo-1.<略>",
      "ipv6-cidr-block": "xxxx:xxxx:8000:f502::/64",
      "ipv6-virtual-router-ip": "fe80::200:17ff:fec9:f071",
      "lifecycle-state": "AVAILABLE",
      "prohibit-internet-ingress": false,
      "prohibit-public-ip-on-vnic": false,
      "route-table-id": "ocid1.routetable.oc1.ap-tokyo-1.<略>",
      "security-list-ids": [
        "ocid1.securitylist.oc1.ap-tokyo-1.<略>"
      ],
      "subnet-domain-name": null,
      "time-created": "2019-09-19T10:20:05.710000+00:00",
      "vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.<略>",
      "virtual-router-ip": "10.0.0.1",
      "virtual-router-mac": "00:00:17:C9:F0:71"
    }
  ]
}
username@cloudshell:~ (ap-tokyo-1)$ 

両方のサブネットにIPv6アドレスが入ったことがわかります。

仮想マシンインスタンスに対する設定(管理側)

Oracle Cloudの管理GUI側で、仮想マシンインスタンスに対してIPv6アドレスを割り振る必要があります。

[インスタンスの詳細]-[アタッチされたVNIC]-[VNICの詳細]にて下のほうにある「リソース」の「IPv6アドレス」を選択します。

最初は下記の様に割り当てられていません

「IPv6アドレスの割当て」をクリック

とくになにも数値入力する必要は無く、「割当て」をクリック

これで、IPv6アドレスが割り当てられました。

仮想マシン内のIPv6アドレス設定

Oracle Cloud上のインスタンスはcloud-initなどの影響化にあるため、一般的な設定手法でネットワーク設定を行っても再起動すると初期化されてしまいます。

今回の場合、IPv6未サポート時代に作られたインスタンスはIPv6が無効化されているため、有効にしなければならないのだが、正しいやりかたが不明。

公式ドキュメントの「IPv6 Addresses」には、コマンドで実行する場合のやり方が書かれていた。

しかし、これは仮想インスタンスの元となるイメージの作成時期によって動作が異なっている場合があった。

古いものではIPv6アドレス設定が無効化されており、ここ半年ぐらいのものはIPv6アドレスが有効化されていた。

有効化されている場合はドキュメント記載の「sudo dhclient -6」でIPv6アドレスが割り当てられた。

無効化されている場合は、下記の様に「sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0」実行してIPv6有効化を行った後に、「sudo dhclient -6」でDHCPv6によりIPv6アドレスが割り当てられ、通信が正常に行えることを確認できた。

[root@oraclelinux7 ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.22/24 brd 10.0.0.255 scope global dynamic ens3
       valid_lft 86336sec preferred_lft 86336sec
[root@oraclelinux7 ~]#

[root@oraclelinux7 ~]# sysctl  -a|grep disable_ip
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.ens3.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.ens3.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
[root@oraclelinux7 ~]#

[root@oraclelinux7 ~]# sysctl  -w net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.all.disable_ipv6 = 0
[root@oraclelinux7 ~]#

[root@oraclelinux7 ~]# sysctl  -a|grep disable_ip
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.ens3.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.ens3.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
[root@oraclelinux7 ~]#

[root@oraclelinux7 ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.22/24 brd 10.0.0.255 scope global dynamic ens3
       valid_lft 86257sec preferred_lft 86257sec
    inet6 fe80::17ff:fe00:a543/64 scope link
       valid_lft forever preferred_lft forever
[root@oraclelinux7 ~]#

[root@oraclelinux7 ~]# dhclient -6
[root@oraclelinux7 ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.22/24 brd 10.0.0.255 scope global dynamic ens3
       valid_lft 86240sec preferred_lft 86240sec
    inet6 xxxx:xxxx:8000:f502:7f3d:7046:6c88:13a1/128 scope global dynamic
       valid_lft 7495sec preferred_lft 7195sec
    inet6 fe80::17ff:fe00:a543/64 scope link
       valid_lft forever preferred_lft forever
[root@oraclelinux7 ~]#

問題は、これを起動時に自動的に行う設定である。

とりあえず公式ドキュメントは発見できなかった。

IPv6有効化設定の方法

まずIPv6無効化の「net.ipv6.conf.all.disable_ipv6=1」はどこで設定されているのかを調べたところ、/usr/lib/sysctl.d/disable-ipv6.conf で設定されていた。

このファイルはOSパッケージにより管理されているため書き換えてはいけない。ユーザが値を変更したい場合は /etc/sysctl.d/ ディレクトリに同じファイル名でファイルを置いて変更する必要がある。

今回の場合は /etc/sysctl.d/disable-ipv6.conf というファイルを作成して、以下の内容で配置した。

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0

これにより、起動時にIPv6が有効化された状態とすることは可能になった。

DHCPv6によるIPアドレス取得の方法

/etc/sysconfig/network-scripts/ifcfg-ens3 に 「IPV6INIT=yes」とか追加してもIPv6アドレスを割り当ててくれない。それどころか、入れたIPV6INIT記述は削除されている。

動作を調べるとcloud-initにより、起動時に毎回 /etc/sysconfig/network-scripts/ifcfg-ens3 が生成されているので、このファイルを書きかえても意味がないことが分かった。

毎起動時に起動させる手法を探したところ、cloud-initの中でper-boot という設定があることがわかった。

「/var/lib/cloud/scripts/per-boot/01_ipv6」というファイルを作り、下記を書き、実行権限を与えたところ、とりあえず希望通りの動作にはなった。

#/bin/bash
dhclient -6

とりあえず、これでOracle Cloud上に作ったインスタンスをIPv6環境に対応させることができた。

ルーティングの設定

上記だけではOracle Cloud内でのIPv6通信しかできない。

仮想クラウドネットワーク(VNC)の設定内にある「ルート・ルール」に「宛先」を「::/0」、ターゲットタイプ「インターネット・ゲートウェイ」でルールを1個追加する。

また、「セキュリティ・リスト」の「イングレス・ルール」に、ソース「::/0」、プロトコルTCP、宛先ポート範囲で「22,80,443」を追加してssh,http,httpsアクセスが可能な設定を行う。

また、出ていくパケットについての「エグレス・ルール」の方に、宛先「::/0」で全てのプロトコルを設定。

これで、外部からのIPv6アクセスも可能になったはずである。


NanoPi R2S+openWRT 21.02.0RCでBIGLOBEのMAP-E接続

$
0
0

GL.iNET GL-MV1000を使っていたわけですが2020年8月以降IPv6が無効化、そのまま放置され、2021年4月になって再度有効化されたものの、GL.iNETが提供する機能以外の部分はほぼ切り捨てられてしまいました。

GL.iNET firmwareの駄目なところ
・GL.iNET UIで提供されている機能はGL.iNET側で有効化しないとluci側で行った設定が有効にならない(DynamicDNSやIPv6など)
・追加したパッケージはfirmwareバージョンアップ時に削除される(GUI上はパッケージを追加する、とか表示されるけど追加されたことはない)
・GL.iNet ver 3.201だとluci パッケージがインストールされていないため詳細設定が出来ない
・パッケージを追加するにはネットワーク接続が必須だがGL.iNET UIだと詳細設定ができないのでネットワーク接続ができない場合がある

そんな状況が約1年続いたわけなので、さすがに諦めました。

代替としてRockchip RK3328のNanoPi R2S と Rockchip RK3399のNanoPi R4S を候補にあげた。

Amazon日本の倉庫に在庫があるというのと、openWRTのページに「FriendlyARM NanoPi R2S」とデバイスに関する個別ページが作成されており、snapshotの提供がされていたので、NanoPi R2Sを買って設定を行った。

画像
画像

ちなみに置き換え対象となったGL-MV1000とのサイズ比較はこんな感じ

画像
画像

さて、openWRTの設定を行ったタイミングではopenWRT 21.02.0 rc1の提供が開始されていたのでそちらを使用した。

friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz を展開したものをmicroSDに書き込んでNanoPi R2Sを起動した。

設定手順1:パッケージの追加

mapパッケージと日本語UIパッケージ(luci-i18n-base-ja)をインストール

CLIでインストールする場合は以下を実行

# opkg update
# opkg install luci-i18n-base-ja
# opkg install map

インストール後は再起動を行うこと。

再起動しないとluciのネットワーク設定で「プロトコル:MAP / LW4over6」が選択肢に現れません。

設定手順2:WAN6インタフェースの作成

WAN6インタフェースがなければ「プロトコル: DHCPv6クライアント」で作成する

最初はそのまま設定して、有効化し、WAN6インタフェースに割り当てられるIPv6アドレスを確認すること。

↑の画像は使い回しなので、この段階では無いはずの「MAP」インタフェースが入ってます

上記のように「IPv6」アドレスが確認できたら、そのアドレスをコピーして、[詳細設定]の「委任されたカスタムIPv6プレフィックス」に貼り付け「/56」とかつけます。

設定手順3:WAN6インタフェースにDHCPv6関連設定

openWRT 21.02の段階でもWAN6インタフェースではDHCPv6関連設定がGUIできない状態であるため、/etc/config/dhcpファイルを直接書き換えます。

必要な設定は「option dhcpv6 ‘relay」「option ra ‘relay’」「option ndp ‘relay’」「option master ‘1’」です。

変更したあとは、以下の様な感じになるかと思います。

config dhcp 'wan6'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master '1'
        option interface 'wan6'
        option start '100'
        option limit '150'
        option leasetime '12h'

ファイル変更後は下記を実行して変更を反映します。

# uci commit dhcp
# /etc/init.d/odhcpd restart
# /etc/init.d/network restart

設定手順4:LANインタフェースにDHCPv6関連設定

LANインタフェースの[DHCPサーバー]-[IPv6設定]で以下の設定を行います。

RA-Service:リレーモード
DHCPv6-サービス: リレーモード
NDP-Proxy: リレーモード

(マスターにチェックは入れません)

設定手順5: MAP-E接続設定

インタフェースの新規作成で「プロトコル:AP / LW4over6」を作成して、必要な値を入れていきます。

[一般設定]では下記の様にしました。

プロトコル:MAP/LW4over6
タイプ:MAP-E
以後は環境に合わせた値

[詳細設定]では下記の2つを設定します。

「トンネルリンク: WAN6」
「従来のMAPを使用」にチェックを入れる

設定完了

ひとまずこれで設定完了です。

うまく接続が始まらない場合は、再起動してみてください。

設定:ニチバン対策

2chの「v6プラス関連 Part21」に下記のような書き込みがある。

757名無しさんに接続中… (ブーイモ MM0e-wDGU)2020/09/27(日) 12:54:30.84ID:cYRzN3kgM>>758
openwrtでMAP-Eされてる方で、
https://gist.github.com/anonymous/0fdec75fa20a7f1ce4806391d6b0429b
このgitのコメントにあるように、
json_add_boolean connlimit_ports 1を
json_add_string connlimit_ports “1”
に変えるor最新のfirewallパッケージを入れるで安定して通信出来てる人いますか?

これをする事でopenwrtで当たり前となってるmap.sh編集してMARKターゲット作ってstatisticで分散してって事をせずとも、
connlimitでポートセット使い切ったら次のポートセット移ってってfirewallがちゃんと出来上がるようになるけど、
ルール通りロールアウトしてる気配が全く無い。
ロールアウトせずパケ詰まりしてしまう。

795 757 (ブーイモ MMe7-PIvK)2020/09/30(水) 20:53:39.27ID:1mR0IohpM>>802
最終的にこのようなcunstom rulesになりました。
https://pastebin.pl/view/raw/06212cd8
多分ですが、map.shで自動生成されるiptablesだと、
–connlimit-maskの指定がなく32になるので、
それだとdestinationが0.0.0.0/0なのでマッチせずロールアウトされないんだと思います。
0にしてあげたらロールアウトしました。(間違ってたらご指摘下さい。)
TCPもnf_conntrack調整したらconnlimitでも大丈夫な感じでしたが、
statisticでかなり安定してるのでTCPのみstatisticにしました。
map.shはlegacy=1をコメントアウトするか、snapshotsから最新のmapをインストールした場合は、
option legacymap ‘1’をnetworkのmapインターフェイスに追記するだけで動くと思います。
markターゲット追加する改変は不要です。
custom rulesに書いただけだと、リブート時、custom rulesの後にmap.shがiptablesを書いてしまうので、
local startupに
sleep 30
sh /etc/firewall.ser
を書けばmap.shで自動生成されたNATテーブルを削除して改めて書いてくれます。

これで、ニチバンベンチ回してもTCPは詰まらないですし、
MAP-EでUDP hole puch使うアプリケーションが使えるので、PS系ゲーム機でNATタイプ2になりましたし、
SoftEtherでUDP高速化機能が使るようになりました。

アドバイス下さった>>758様や、スクリプト考案の先駆者様等、
有難うございます。

GL-MV1000時代にも試した「OpenWrt map-e (JPNE v6plus) において、割当ポート240個をちゃんと使わせるための設定。」はここでもうまく動作していなかった模様。

代替としてhttps://pastebin.pl/view/raw/06212cd8にある設定に置き換えるとある。

units=63

IP4='IPV4アドレス'
PSID='MAP-E_PSID'
LANDEV='LANインターフェイス'
WAN6DEV='WANインターフェイス'
TUNDEV='MAP-Eインターフェイス'

iptables -t nat -F PREROUTING
iptables -t nat -F OUTPOUT
iptables -t nat -F POSTROUTING

rule=1
while [ $rule -le $units  ] ; do
  mark=`expr $rule + 16`
  pn=`expr $rule - 1`
  portl=`expr $rule \* 1024 + $PSID \* 16`
  portr=`expr $portl + 15`

  iptables -t nat -A PREROUTING -p tcp -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark
  iptables -t nat -A OUTPUT -p tcp -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark

  iptables -t nat -A POSTROUTING -p icmp -m connlimit --connlimit-daddr --connlimit-upto 16 --connlimit-mask 0 -o $TUNDEV -j SNAT --to $IP4:$portl-$portr
  iptables -t nat -A POSTROUTING -p tcp -o $TUNDEV -m mark --mark $mark -j SNAT --to $IP4:$portl-$portr
  iptables -t nat -A POSTROUTING -p udp -m connlimit --connlimit-daddr --connlimit-upto 16 --connlimit-mask 0 -o $TUNDEV -j SNAT --to $IP4:$portl-$portr

  rule=`expr $rule + 1`
done

sleep 5

iptables -t nat -A PREROUTING -i $LANDEV -j zone_lan_prerouting
iptables -t nat -A PREROUTING -i $WAN6DEV -j zone_wan_prerouting
iptables -t nat -A PREROUTING -i $TUNDEV -j zone_wan_prerouting

iptables -t nat -A POSTROUTING -o $LANDEV -j zone_lan_postrouting
iptables -t nat -A POSTROUTING -o $WAN6DEV -j zone_wan_postrouting
iptables -t nat -A POSTROUTING -o $TUNDEV -j zone_wan_postrouting

ただ、上記を使用としたところ、statisticのエラーがでてうまく設定できなかった。

調べたらiptablesのstatisticモジュールはiptables-mod-ipoptに入っているが、標準では導入されていないためエラーになっている、という状況だった。まずは下記のようにインストール。

root@nanopi:~# opkg install iptables-mod-ipopt
Installing iptables-mod-ipopt (1.8.7-1) to root...
Downloading https://downloads.openwrt.org/releases/21.02.0-rc1/targets/rockchip/armv8/packages/iptables-mod-ipopt_1.8.7-1_aarch64_generic.ipk
Installing kmod-ipt-ipopt (5.4.111-1) to root...
Downloading https://downloads.openwrt.org/releases/21.02.0-rc1/targets/rockchip/armv8/packages/kmod-ipt-ipopt_5.4.111-1_aarch64_generic.ipk
Configuring kmod-ipt-ipopt.
Configuring iptables-mod-ipopt.
root@nanopi:~#

ただ、うちの環境ではこれを実行してみたところ、どうさが怪しかったのでとりあえず未使用です。


失敗例コレクション

「プロトコル:MAP / LW4over6」が選択肢にない

画像

mapパッケージインストール後、openWRTを再起動するまで、このプロトコル一覧は更新されませんでした。

再起動すると表示されるようになりました。

「MAP rule is invalidError: MAP rule is invalid」になる

「MAP rule is invalidError: MAP rule is invalid」はWAN6インタフェースの詳細設定で「委任されたカスタムIPv6プレフィックス」(ip6prefix)を設定していない場合に出力されました。

invalidと表示された時のWAN6インタフェースの「IPv6-PD」に表示されている値を突っ込んだら、invalidが解消されました。

設定ファイル的には/etc/config/networkのWAN6に関する記述に「list ip6prefix」を追加する感じです。

LAN内にDHCPv6アドレスが配布されない

nanoPi上は特に問題無くIPv6アドレスが割り当てられており動作もしているが、LAN内のクライアントにDHCPv6アドレスが配布されていないという状態になった。

これは、LANインタフェースの[DHCPサーバ]-[IPv6設定]にある「マスター」にチェックを一度でも入れてしまうと発生する事象だった。

一度チェックを入れて保存すると、/etc/config/dhcp に以下の様な設定が行われる。

<略>
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ra_maxinterval '600'
        option ra_mininterval '200'
        option ra_lifetime '1800'
        option ra_mtu '0'
        option ra_hoplimit '0'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
        option master '1'
<略>

この後、マスターのチェックを外すと、以下の様になる

<略>
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ra_maxinterval '600'
        option ra_mininterval '200'
        option ra_lifetime '1800'
        option ra_mtu '0'
        option ra_hoplimit '0'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
<略>

ここで問題となったのは以下の値でした。

        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ra_maxinterval '600'
        option ra_mininterval '200'
        option ra_lifetime '1800'
        option ra_mtu '0'
        option ra_hoplimit '0'

これらの値が存在しているとDHCPv6アドレスのLAN内への配布がうまくいきませんでした。

/etc/config/networkを編集したあと、下記で反映することで動作するようになりました。

# uci commit dhcp
# /etc/init.d/odhcpd restart
# /etc/init.d/network restart

参考: IPv6 working on router but not on clients

MAP-E接続が開始されない

GL-MV1000からnanoPi R2Sに置き換えてすぐは、IPv6接続はできているが、MAP-E接続が開始されない、という状態になった。

ONUの電源を切り、5分ぐらいしてから電源を入れnanoPiも起動するとMAP-E接続が可能となった。

おそらく、接続先でのセッション認識が消えないと別のデバイスでの接続が行うことができないようだ。(エラーにもならないので詳細は不明)


参考資料

/etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd23:66f8:d98f::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.1.1'
        option ip6assign '60'

config device 'lan_eth1_dev'
        option name 'eth1'
        option macaddr '1a:e4:a4:xx:xx:xx'

config interface 'wan'
        option ifname 'eth0'
        option proto 'dhcp'
        option auto '0'

config device 'wan_eth0_dev'
        option name 'eth0'
        option macaddr '1a:e4:a4:xx:xx:xx'

config interface 'wan6'
        option ifname 'eth0'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        list ip6prefix 'xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/56'

config interface 'MAP'
        option proto 'map'
        option maptype 'map-e'
        option peeraddr 'xxxx:xxxx:xxxx:xxxx::64'
        option ipaddr 'xxx.xxx.xxx.xxx'
        option ip4prefixlen '15'
        option ip6prefix '240b:10::'
        option ip6prefixlen '31'
        option ealen '25'
        option psidlen '8'
        option offset '4'
        option tunlink 'wan6'
        option legacymap '1'

/etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config dhcp 'wan6'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master '1'
        option interface 'wan6'
        option start '100'
        option limit '150'
        option leasetime '12h'

Commvault バックアップのLinuxクライアントをインストールする場合の設定

$
0
0

CommvaultバックアップのLinuxクライアントをインストールする際にうまく行かずに悩んだ点が発生したのでメモ書き。

Linux File System Agent: System Requirements」には下記のような記述があるが、実際にはRHEL/CentOS 7.1以外でも発生する問題である。

Net-tools Package
On Red Hat Enterprise Linux/CentOS 7.1 computers, make sure to install the net-tools package.

それどころか、RHEL8/CentOS8などでは、tarパッケージが最小インストールではインストールされなくなっているため、インストールに失敗する。(vSphere環境上にインストールする場合、open-vm-toolsの必須パッケージとしてtarがインストールされるため気がつきにくい)

今回、RHEL8.3, AlmaLinux 8.3, Rocky Linux 8.3, openEuler 21.03, CentOS 7, Ubuntu 18.04にインストールした結果、必要だったものは以下であった。

・必須のコマンド
tar, netstat, gzip コマンド
・上記が含まれるパッケージ(RHEL系の場合)
tar net-tools

また、firewalld/iptablesによる通信制限がかけられている場合、下記を実行してポートをあけた方が良い。

ただ、あけなくてもバックアップできる場合もある。

現状を確認「firewall-cmd –list-all」

[root@centos8 ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@centos8 ~]#

Commvault用にポート8400をあける設定

[root@centos8 ~]# firewall-cmd --permanent --zone=public --add-port=8400/tcp
success
[root@centos8 ~]#

設定の反映

[root@centos8 ~]# firewall-cmd --reload
success
[root@centos8 ~]#

反映されたことを確認

[root@centos8 ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports: 8400/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@centos8 ~]#

また、rootユーザでのログインが禁止されている場合は、以下の4つの手段のどれかを使う

その1) 予め各Linuxサーバの/etc/sudoers ファイルにインストール用ユーザを設定してリモートインストールを行う「Adding sudo Users with Root Privileges on a UNIX Client

その2) 各LinuxサーバにLinuxクライアントパッケージを転送してrootユーザでインストールを行う「Installing Commvault Locally on UNIX, Linux, and Macintosh Computers Using the Installation Package

その3) 各LinuxサーバにLinuxクライアントパッケージを転送して一般ユーザ+sudoでインストールを行う「Installation of UNIX Agents by a Non-Root User

その4) 各Linuxサーバでrootログインを許可する

Oracle CloudでARMインスタンスが開始された

$
0
0

Oracle CloudでARMインスタンスの提供が開始された。

Arm-based cloud computing is the next big thing: Introducing Arm on Oracle Cloud Infrastructure

Ampere A1を使用したものらしい。

今日から使える、といってるけど、さすがに東京リージョンには来てないだろうと思いつつコンソールを開いてみる。

画像

え!?東京でも作成できんじゃん!と作成開始

まず、Always Freeアカウントではどういうスペックが作れるのか?を確認→「Always Free Resources

画像

なんとCPU 4個/RAM 24GBまでいけるらしい。

すでに、これまでのAlways Freeアカウントの上限である、VM.Standard.E2.1.Micro インスタンスで2個作っていても、それとは別カウントでARMのVM.Standard.A1.Flexが作れるようだ。

画像
画像
画像

標準ではOracle Linux 7.9が選択されている。他の選択肢を見てみる。

画像

「イメージビルド」に記載がないものは選べないようだ。このため、Oracle AUtonomous Linux は選択できなかった。

Oracle Linux 8 にすることはできるようだ。

インスタンスのshapreは変更可能

その他の項目はいままでのインスタンス作成となんら変わらず。

完成するとこんな感じ

画像

「Always Free」というマークがついてない・・・

不安になったのでいろいろ試行錯誤

画像

既存のVM.Standard.E2.1.Microインスタンスを1個けして作り直してもA1.FlexインスタンスにAlways Freeマークがつくわけではないようだ。

かといって、VM.Standard.E2.1.Microインスタンスが2個ある状態で3個目をつくろうとすると、有料アカウントへのアップグレードが必要と表示されるので、有料になっているわけではない模様。

画像

じゃあ、ARMインスタンスを複数個立てられるのかな?と実行してみると、作成は可能なものの直ちに終了して使えないという状態

既存インスタンスのシェイプの変更を選び

変更することは可能

変更が反映されました。

ほんとにこれで大丈夫なのかなぁ???と悩むところではありますが、ドキュメント通り、「VM.Standard.E2.1.Micro インスタンスを2個」と「ARMのVM.Standard.A1.Flexインスタンスを4CPU/メモリ24GBの範囲内」で作成することができる、ということのようです。

また、ARMインスタンスについては、作成後、CPU/メモリスペックを変更する事が可能でした。

2021/05/27訂正

ドキュメント上は「All tenancies get two public IPv4 addresses for Always Free compute instances」となっていますが、動作検証をしてみたところ、パブリックIPアドレスの上限個数が3となっているようです。

パブリックIPアドレスの割り当てをやめてみたところARMインスタンス(VM.Standard.A1.Flex)を4つ作ることができました。

画像

IPv6設定メモ

4月から使える様になったIPv6ですが「Oracle Cloudですでに作成済みのネットワークに対してIPv6を有効にする方法」に示した手順で有効化したところ、DHCPv6でのIPv6アドレス取得が失敗しました。

手動であれば設定できたので、ARMインスタンスが存在するネットワークへのDHCPv6が正常に動作していない模様です。

設定としては、Oracle Cloudコンソールの[インスタンスの詳細]-[アタッチされたVNIC]-[VNICの詳細]にある[リソース]-[IPv6アドレス]にて、インスタンスにIPv6アドレスを割り当てる。

また、2021/05/26時点でのOracle Linux 7提供イメージでは、IPv6アドレスが有効化されていないため、インスタンス内のOS設定を変更する必要があり、DHCPv6アドレス取得ができなかったので、disable-ipv6.confと01_ipv6を作成した。
Oracle Linux 8だとIPv6有効化されていたがDHCPv6アドレス取得ができなかったので01_ipv6を作成したfirewalldにdhcpv6-clientの設定がされていないのでDHCPv6アドレス取得に失敗していたので設定を変更した。
Ubuntu 20.04ではIPv6有効化されておりDHCPv6アドレス取得はできたものの起動時に自動取得はしなかったので01_ipv6を作成しdhclient -6の方を有効にした。

disable-ipv6.confの手順

/etc/sysctl.d/disable-ipv6.conf を作成し、下記を記載

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0

01_ipv6の手順

/var/lib/cloud/scripts/per-boot/01_ipv6 を作成し、下記を記載

#/bin/bash
#dhclient -6
ip -6 addr add xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 dev enp0s3

DHCPv6が使える様になった場合は、ip行の先頭に#を入れ、dhclientの前の#を外すこと。

また/var/lib/cloud/scripts/per-boot/01_ipv6には下記の様に実行権限を与えること

# chmod a+x /var/lib/cloud/scripts/per-boot/01_ipv6 

firewalldにdhcpv6-clientを追加する手順

serviceとしてdhcpv6-clientを追加する、という手順。Oracle Linux 7だと標準で設定されていたが、2021/05/27時点でのOracle Linux 8 ARM環境だと設定されていなかった。

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

簡易的なセキュリティ対策

インスタンスを稼働させておくとsshへのアタックが凄い数来ます。

標準設定では秘密鍵持ってないとログインできないので影響は少ないですが、アクセスができる状態だといつまでもリトライを繰り返してきます。このため、fail2banを使って拒否することで、アタック側のブラックリストに載せて攻撃者数を減らしてみよう、という試みです。

$ sudo yum install fail2ban
$ sudo vi /etc/fail2ban/jail.local
$ sudo cat /etc/fail2ban/jail.local
[DEFAULT]
# 86400秒=24時間以内に5回不審なアクセスがあったら24時間BAN
bantime  = 86400
findtime  = 86400
maxretry = 5
# 259200秒=3日以内に5回不審なアクセスがあったら3日間BAN
#bantime  = 259200
#findtime  = 259200
#maxretry = 5

# 除外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

[sshd]
enabled = true
banaction = firewallcmd-ipset

$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
$

おまけ情報

インスタンス内でlscpuを実行した結果

Oracle Linux 7の場合

$ sudo lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Model:                 1
BogoMIPS:              50.00
NUMA node0 CPU(s):     0
Flags:                 fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Oracle Linux 8 (Oracle-Linux-8.3-aarch64-2021.05.12-0) 初期状態の場合

$ lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           1
NUMA node(s):        1
Vendor ID:           ARM
Model:               1
Stepping:            r3p1
BogoMIPS:            50.00
NUMA node0 CPU(s):   0
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Oracle Linux 8 (Oracle-Linux-8.3-aarch64-2021.05.12-0) でdnf updateした後の場合

$ sudo lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per cluster: 1
Socket(s):           1
Cluster(s):          1
NUMA node(s):        1
Vendor ID:           ARM
BIOS Vendor ID:      QEMU
Model:               1
Model name:          Neoverse-N1
BIOS Model name:     virt-4.2
Stepping:            r3p1
BogoMIPS:            50.00
NUMA node0 CPU(s):   0
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Oracle Linux 8で4CPU/24GBにした場合

$ sudo lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per cluster: 4
Socket(s):           1
Cluster(s):          1
NUMA node(s):        1
Vendor ID:           ARM
BIOS Vendor ID:      QEMU
Model:               1
Model name:          Neoverse-N1
BIOS Model name:     virt-4.2
Stepping:            r3p1
BogoMIPS:            50.00
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Ubuntu 20.04の場合

$ sudo lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          1
On-line CPU(s) list:             0
Thread(s) per core:              1
Core(s) per socket:              1
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       ARM
Model:                           1
Model name:                      Neoverse-N1
Stepping:                        r3p1
BogoMIPS:                        50.00
NUMA node0 CPU(s):               0
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled v
                                 ia prctl
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atom
                                 ics fphp asimdhp cpuid asimdrdm lrcpc dcpop asi
                                 mddp ssbs
$

Oracle Linux 8でWordPressサーバを立てる

$
0
0

Oracle CloudのAlways Freeで作れるインスタンスにARMベースのインスタンスが追加された。

従来のCPU1個/メモリ1GBに対して、CPU1~4個/メモリ6GB~24GBと破格のスペックなので、Wordpressサーバでも移行してみるかな、と思って、「CentOS 7 / Oracle Linux 7でWordPressサーバを建てる」の手順でつくろうとしてみたところ、Oracle Linux 7 ARMではPHP Packages for Oracle Linuxが提供されていなかった。

Oracle Linux 8であれば標準状態でphp 7.4が利用できるようなので、Oracle Linux 8で作成する手順を策定した。

準備1: Oracle Cloud用手順

準備1-1: IPv6アドレス割り当て:Oracle Cloudコンソール側

Oracle Cloudのコンソールを開いて、インスタンスにIPv6アドレスを割り当てます。

また、割り当てられたIPv6アドレスを確認します。

準備1-2: インスタンス側操作

2021年5月27日現在のOracle Cloud環境で提供されるOracle Linux 8では、IPv6アドレスの自動割り当てが動作していません。

firewalldの設定でdhcpv6-clientが許可されていないために発生していましたので、許可します。

まず初期状態を確認

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

dhcpv6-clientの許可設定と設定読み込みと確認

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

準備2: 一般的な前準備

準備2-1: 日本時間にする

日本に住んでいる場合、日本時間表記の方が使いやすいので、OSも日本時間表示に設定する。

$ sudo timedatectl set-timezone Japan
$ 

準備2-2: パッケージを最新にアップデートする

現時点でインストール済みパッケージを最新にします。

Oracle Linux 8ではyum updateではなくdnf updateとなります。アップデート後は再起動します。

$ sudo dnf update -y
<略>
$ sudo reboot

手順3: EPELレポジトリの追加

EPELレポジトリを使うので、使用できるようにします。

Oracle Cloud上のOracle Linux 8環境ではレポジトリパッケージのインストールはされているので、有効化を行います。

まず、現状のレポジトリ設定状況を「dnf repolist –all」を実行して確認します。

$ dnf repolist --all
repo id                          repo name                              status
ol8_MySQL80                      MySQL 8.0 for Oracle Linux 8 (aarch64) enabled
ol8_MySQL80_connectors_community MySQL 8.0 Connectors Community for Ora enabled
ol8_MySQL80_tools_community      MySQL 8.0 Tools Community for Oracle L enabled
ol8_aarch64_userspace_ksplice    Ksplice aware userspace packages for O disabled
ol8_appstream                    Oracle Linux 8 Application Stream (aar enabled
ol8_baseos_latest                Oracle Linux 8 BaseOS Latest (aarch64) enabled
ol8_codeready_builder            Oracle Linux 8 CodeReady Builder (aarc disabled
ol8_developer                    Oracle Linux 8 Development Packages (a disabled
ol8_developer_EPEL               Oracle Linux 8 EPEL Packages for Devel disabled
ol8_developer_UEKR6              Developer Preview of UEK Release 6 (aa disabled
ol8_distro_builder               Oracle Linux 8 Distro Builder (aarch64 disabled
ol8_ksplice                      Ksplice for Oracle Linux 8 (aarch64)   enabled
ol8_oci_included                 Oracle Software for OCI users on Oracl enabled
ol8_u2_baseos_base               Oracle Linux 8.2 BaseOS (aarch64)      disabled
ol8_u3_baseos_base               Oracle Linux 8.3 BaseOS (aarch64)      disabled
ol8_u4_baseos_base               Oracle Linux 8.4 BaseOS (aarch64)      disabled
$ 

ol8_developer_EPELがdisabledになっています。

「sudo dnf config-manager –set-enabled ol8_developer_EPEL」を実行し、enabledに変更されたことを確認します。

$ sudo dnf config-manager --set-enabled ol8_developer_EPEL
$ dnf repolist --all
repo id                          repo name                              status
ol8_MySQL80                      MySQL 8.0 for Oracle Linux 8 (aarch64) enabled
ol8_MySQL80_connectors_community MySQL 8.0 Connectors Community for Ora enabled
ol8_MySQL80_tools_community      MySQL 8.0 Tools Community for Oracle L enabled
ol8_aarch64_userspace_ksplice    Ksplice aware userspace packages for O disabled
ol8_appstream                    Oracle Linux 8 Application Stream (aar enabled
ol8_baseos_latest                Oracle Linux 8 BaseOS Latest (aarch64) enabled
ol8_codeready_builder            Oracle Linux 8 CodeReady Builder (aarc disabled
ol8_developer                    Oracle Linux 8 Development Packages (a disabled
ol8_developer_EPEL               Oracle Linux 8 EPEL Packages for Devel enabled
ol8_developer_UEKR6              Developer Preview of UEK Release 6 (aa disabled
ol8_distro_builder               Oracle Linux 8 Distro Builder (aarch64 disabled
ol8_ksplice                      Ksplice for Oracle Linux 8 (aarch64)   enabled
ol8_oci_included                 Oracle Software for OCI users on Oracl enabled
ol8_u2_baseos_base               Oracle Linux 8.2 BaseOS (aarch64)      disabled
ol8_u3_baseos_base               Oracle Linux 8.3 BaseOS (aarch64)      disabled
ol8_u4_baseos_base               Oracle Linux 8.4 BaseOS (aarch64)      disabled
$

手順4: インターネット公開用設定

手順4-1: fail2ban導入

公開サーバは各種のアタックにさらされます。管理用sshポートにもやってきます。

多少なりとも軽減するためにEPELレポジトリ収録のfail2banを使用します。

$ sudo dnf install fail2ban -y
$ 

カスタム設定は/etc/fail2ban/jail.localに行います。

$ sudo vi /etc/fail2ban/jail.local
$ cat /etc/fail2ban/jail.local
[DEFAULT]
# 86400秒=24時間以内に5回不審なアクセスがあったら24時間BAN
bantime  = 86400
findtime  = 86400
maxretry = 5
# 259200秒=3日以内に5回不審なアクセスがあったら3日間BAN
#bantime  = 259200
#findtime  = 259200
#maxretry = 5

# 除外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

[sshd]
enabled = true
banaction = firewallcmd-ipset
$ 

fail2banをOS起動時に実行する設定と、今すぐfail2banを起動するコマンドを実行します。

$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
$

手順4-2: Webサーバ用ポート公開設定

この段階では、dhcpv6-clientとsshのみが許可されています。

Webサーバ公開用にhttp(ポート80)とhttps(ポート443)を追加します。

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

手順5: php 7.4追加

Oracle Linux 8環境では、moduleという形で複数バージョンのソフトウェアが提供されています。

phpに関してどのようなものがあるのかを「dnf module list | grep php」を実行して確認します。

$ dnf module list | grep php
php                  7.2 [d]         common [d], devel, minimal               PHP scripting language                                                                                                                                                                                
php                  7.3             common [d], devel, minimal               PHP scripting language                                                                                                                                                                                
php                  7.4             common [d], devel, minimal               PHP scripting language                                                                                                                                                                                
$

php 7.2が標準選択で、他にphp 7.3とphp 7.4が選べることがわかります。

php7.4を指定してパッケージを追加します。

$ sudo dnf install @php:7.4 -y
Last metadata expiration check: 0:07:11 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
==========================================================================================================================================
 Package                     Architecture       Version                                                Repository                    Size
==========================================================================================================================================
Installing group/module packages:
 php-cli                     aarch64            7.4.6-4.module+el8.3.0+7685+72d70b58                   ol8_appstream                2.8 M
 php-common                  aarch64            7.4.6-4.module+el8.3.0+7685+72d70b58                   ol8_appstream                675 k
 php-fpm                     aarch64            7.4.6-4.module+el8.3.0+7685+72d70b58                   ol8_appstream                1.5 M
 php-json                    aarch64            7.4.6-4.module+el8.3.0+7685+72d70b58                   ol8_appstream                 73 k
 php-mbstring                aarch64            7.4.6-4.module+el8.3.0+7685+72d70b58                   ol8_appstream                474 k
 php-xml                     aarch64            7.4.6-4.module+el8.3.0+7685+72d70b58                   ol8_appstream                166 k
Installing dependencies:
 httpd-filesystem            noarch             2.4.37-39.0.1.module+el8.4.0+20024+b87b2deb            ol8_appstream                 39 k
 libxslt                     aarch64            1.1.32-6.0.1.el8                                       ol8_baseos_latest            239 k
 nginx-filesystem            noarch             1:1.14.1-9.0.1.module+el8.0.0+5347+9282027e            ol8_appstream                 25 k
Installing module profiles:
 php/common
Enabling module streams:
 httpd                                          2.4
 nginx                                          1.14
 php                                            7.4

Transaction Summary
==========================================================================================================================================
Install  9 Packages

Total download size: 5.9 M
Installed size: 23 M
Downloading Packages:
<略>
$

手順6: MySQL設定編

Oralce Linux 8ではわざわざ「MySQL 8.0 for Oracle Linux 8 (aarch64)」を用意していますが、よく見るとそこにmysql-serverはなく、メインのol8_appstream に含まれているという理由はよくわかりませんが、せっかくなのでそのまま使用します。

$ sudo dnf install mysql-server -y
Last metadata expiration check: 0:56:46 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
================================================================================
 Package      Arch    Version                               Repository     Size
================================================================================
Installing:
 mysql-server aarch64 8.0.21-1.module+el8.2.0+7793+cfe2b687 ol8_appstream  28 M
Installing dependencies:
 mariadb-connector-c-config
              noarch  3.1.11-2.el8_3                        ol8_appstream  15 k
 mecab        aarch64 0.996-1.module+el8.0.0+5253+1dce7bb2.9
                                                            ol8_appstream 367 k
 mysql        aarch64 8.0.21-1.module+el8.2.0+7793+cfe2b687 ol8_appstream  13 M
 mysql-common aarch64 8.0.21-1.module+el8.2.0+7793+cfe2b687 ol8_appstream 147 k
 mysql-errmsg aarch64 8.0.21-1.module+el8.2.0+7793+cfe2b687 ol8_appstream 581 k
 protobuf-lite
              aarch64 3.5.0-13.el8                          ol8_appstream 129 k
Enabling module streams:
 mysql                8.0

Transaction Summary
================================================================================
Install  7 Packages

Total download size: 42 M
Installed size: 228 M
Downloading Packages:
<略>
$

mysqldを自動起動する設定とします。

$ sudo systemctl enable mysqld
Created symlink /etc/systemd/system/multi-user.target.wants/mysqld.service → /usr/lib/systemd/system/mysqld.service.
$

mysqldを起動します。

$ sudo systemctl start mysqld
$

WordPress用データベースを作成します。

MySQL 8におけるデータベースユーザ作成と権限の割り当てが従来の「grant all on DB名.* to wordpress@localhost identified by ‘パスワード’;」という一文から、「create user ~」と「grant ~」の2つに分かれている点に注意が必要です。

$ sudo mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.21 Source distribution

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

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

mysql> create database DB名 character set utf8;
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> create user wordpress@localhost  identified by 'パスワード';
Query OK, 0 rows affected (0.01 sec)

mysql> grant all privileges on DB名.* to wordpress@localhost;
Query OK, 0 rows affected (0.00 sec)

mysql> quit
Bye
$

手順7: Webサーバ設定

手順7-1: httpdインストール

httpdをインストールします。

$ sudo dnf install httpd -y
Last metadata expiration check: 0:08:49 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
==========================================================================================================================================
 Package                      Architecture      Version                                                 Repository                   Size
==========================================================================================================================================
Installing:
 httpd                        aarch64           2.4.37-39.0.1.module+el8.4.0+20024+b87b2deb             ol8_appstream               1.4 M
Installing dependencies:
 apr                          aarch64           1.6.3-11.el8                                            ol8_appstream               119 k
 apr-util                     aarch64           1.6.1-6.el8                                             ol8_appstream               104 k
 httpd-tools                  aarch64           2.4.37-39.0.1.module+el8.4.0+20024+b87b2deb             ol8_appstream               104 k
 mod_http2                    aarch64           1.15.7-3.module+el8.4.0+20024+b87b2deb                  ol8_appstream               146 k
 oracle-logos-httpd           noarch            84.3-1.0.1.el8                                          ol8_baseos_latest            29 k

Transaction Summary
==========================================================================================================================================
Install  6 Packages

Total download size: 1.8 M
Installed size: 10 M
Downloading Packages:
<略>
$

次で設定変更をするので、この段階ではhttpdを起動しません。

OS起動時に自動起動する設定だけを行います。

$ sudo systemctl enable httpd
$

手順7-2: dehydratedによるLet’s Encrypt導入

Let’s EncryptによるSSL証明書導入はcertbotを使うのが一般的ではあるのだが、python環境とあわせてパッケージサイズが大きいので、コンパクトでEPELにも収録されているdehydratedを使用する。

$ sudo dnf install dehydrated -y
Last metadata expiration check: 1:07:45 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
================================================================================
 Package          Architecture Version           Repository                Size
================================================================================
Installing:
 dehydrated       noarch       0.6.5-1.el8       ol8_developer_EPEL        90 k

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

Total download size: 90 k
Installed size: 164 k
Downloading Packages:
<略>
$

dehydratedによるSSL証明書取得処理には /var/www/dehydrated が使用されるためディレクトリを作成します。

$ sudo mkdir  /var/www/dehydrated
$

http://~/.well-known/acme-challenge でアクセスした時に上記ディレクトリが開くようApacheの設定を /etc/httpd/conf.d/dehydrated.conf として作成します。(sudo vi /etc/httpd/conf.d/dehydrated.conf )

$ sudo  vi /etc/httpd/conf.d/dehydrated.conf
$ cat /etc/httpd/conf.d/dehydrated.conf
Alias /.well-known/acme-challenge /var/www/dehydrated
<Directory /var/www/dehydrated/>
</Directory>
$

httpdを起動します

$ sudo systemctl start httpd
$

SSL証明書を発行するホスト名を /etc/dehydrated/domains.txt に記載する。(sudo vi /etc/dehydrated/domains.txt)

1行に複数のホスト名を記載するとaliasになります。

$ sudo vi /etc/dehydrated/domains.txt
$ sudo cat /etc/dehydrated/domains.txt
ホスト1名.ドメイン名 ホスト2名.ドメイン名
$

登録操作を開始します。

$ sudo dehydrated --register
# INFO: Using main config file /etc/dehydrated/config
# INFO: Using additional config file /etc/dehydrated/conf.d/local.sh

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 `/bin/dehydrated --register --accept-terms`.
$ sudo /bin/dehydrated --register --accept-terms
# INFO: Using main config file /etc/dehydrated/config
# INFO: Using additional config file /etc/dehydrated/conf.d/local.sh
+ Generating account key...
+ Registering account key with ACME server...
+ Fetching account ID...
+ Done!
$

初回のSSL証明書発行処理を実行します。

$ sudo dehydrated --cron
# INFO: Using main config file /etc/dehydrated/config
# INFO: Using additional config file /etc/dehydrated/conf.d/local.sh
Processing ホスト1名.ドメイン名 with alternative names: ホスト2名.ドメイン名
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for ホスト1名.ドメイン名
 + Handling authorization for ホスト2名.ドメイン名
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for ホスト1名.ドメイン名 authorization...
 + Challenge is valid!
 + Responding to challenge for ホスト2名.ドメイン名 authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
$

手順7-3: WebサーバへのSSL証明書設定

まず、httpdにmod_sslを追加します。

$ sudo dnf install mod_ssl -y
Last metadata expiration check: 1:36:21 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
================================================================================
 Package
      Arch    Version                                       Repository     Size
================================================================================
Installing:
 mod_ssl
      aarch64 1:2.4.37-39.0.1.module+el8.4.0+20024+b87b2deb ol8_appstream 126 k

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

Total download size: 126 k
Installed size: 274 k
Downloading Packages:
<略>
$

標準の /etc/httpd/conf.d/ssl.conf は使わず、Mozilla SSL Configuration Generatorベースの設定を /etc/httpd/conf.d/ssl-mozilla.conf として作成します。(なお、ssl.conf には”Listen 443 https”設定もあるので、そのままにしています)

$ sudo vi /etc/httpd/conf.d/ssl-mozilla.conf
$ cat /etc/httpd/conf.d/ssl-mozilla.conf
# generated 2021-05-27, Mozilla Guideline v5.6, Apache 2.4.37, OpenSSL 1.1.1g, intermediate configuration
# https://ssl-config.mozilla.org/#server=apache&version=2.4.37&config=intermediate&openssl=1.1.1g&guideline=5.6

# this configuration requires mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt >> /path/to/signed_cert_and_intermediate_certs_and_dhparams
    SSLCertificateFile      /etc/dehydrated/certs/<ホスト名>/cert.pem
    SSLCertificateKeyFile   /etc/dehydrated/certs/<ホスト名>/privkey.pem

    # enable HTTP/2, if available
    Protocols h2 http/1.1

    # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

# intermediate configuration
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          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
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
$

httpdを再起動します。

$ sudo systemctl restart httpd
$

手順8: WordPress導入

WordPressのWebから最新版をダウンロードして、/var/www/html以下に展開します。

$ cd /var/www/html/
$ ls
$ sudo curl -O https://wordpress.org/latest.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 15.0M  100 15.0M    0     0  6978k      0  0:00:02  0:00:02 --:--:-- 6978k
$ ls
latest.tar.gz
$ sudo tar xfz latest.tar.gz
$ ls -l
total 15388
-rw-r--r--. 1 root   root   15750424 May 27 14:54 latest.tar.gz
drwxr-xr-x. 5 nobody nobody     4096 May 13 08:49 wordpress
$ sudo rm latest.tar.gz
$

WordPressディレクトリの所有者をWebサービスのユーザである「apache」に変更します。

$ ps -ef|grep http
root        7619       1  0 14:52 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      7621    7619  0 14:52 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      7622    7619  0 14:52 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      7623    7619  0 14:52 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      7624    7619  0 14:52 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      7836    7619  0 14:52 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
opc         7943    2643  0 14:55 pts/0    00:00:00 grep --color=auto http
$ sudo chown -R apache:apache wordpress/
$ ls -l
total 4
drwxr-xr-x. 5 apache apache 4096 May 13 08:49 wordpress
$

/var/www/html/wordpress をDocumentRootとするように ssl-mozilla.conf に追加して、httpdを再起動します。

$ sudo vi /etc/httpd/conf.d/ssl-mozilla.conf
$ cat /etc/httpd/conf.d/ssl-mozilla.conf
# generated 2021-05-27, Mozilla Guideline v5.6, Apache 2.4.37, OpenSSL 1.1.1g, intermediate configuration
# https://ssl-config.mozilla.org/#server=apache&version=2.4.37&config=intermediate&openssl=1.1.1g&guideline=5.6

# this configuration requires mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    DocumentRoot /var/www/html/wordpress
    SSLEngine on

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt >> /path/to/signed_cert_and_intermediate_certs_and_dhparams
    SSLCertificateFile      /etc/dehydrated/certs/<ホスト名>/cert.pem
    SSLCertificateKeyFile   /etc/dehydrated/certs/<ホスト名>/privkey.pem

    # enable HTTP/2, if available
    Protocols h2 http/1.1

    # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

# intermediate configuration
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          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
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
$ sudo systemctl restart httpd
$

ブラウザからアクセスすると、下記の表示になります。

これはphpからMySQLにアクセスするためのパッケージがインストールされていないためなので、php-mysqlndを追加して、httpdを再起動します。

$ sudo dnf install php-mysqlnd -y
Last metadata expiration check: 1:56:37 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
================================================================================
 Package     Arch    Version                                Repository     Size
================================================================================
Installing:
 php-mysqlnd aarch64 7.4.6-4.module+el8.3.0+7685+72d70b58   ol8_appstream 182 k
Installing dependencies:
 php-pdo     aarch64 7.4.6-4.module+el8.3.0+7685+72d70b58   ol8_appstream 118 k

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

Total download size: 300 k
Installed size: 806 k
Downloading Packages:
<略>
$ sudo systemctl restart httpd
$

WordPressの設定手順を進めると wp-config.php に書き込めない、と出ますので、「sudo vi /var/www/html/wordpress/wp-config.php」を実行し、指定された内容を記載します。

手順8: SELinux設定

手順8-1: httpdのネットワーク接続問題

一見するとここまででうまく動いているように見えます。

しかし、プラグインをインストールしようとするとエラーになります。

/var/log/audit/audit.logを確認すると下記のようなログが出ています。

type=AVC msg=audit(1622095859.957:2064): avc:  denied  { name_connect } for  pid=8908 comm="php-fpm" dest=443 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
type=AVC msg=audit(1622095868.397:2065): avc:  denied  { name_connect } for  pid=8313 comm="php-fpm" dest=443 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
type=AVC msg=audit(1622095868.401:2066): avc:  denied  { name_connect } for  pid=8313 comm="php-fpm" dest=80 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0

これはhttpd_can_network_connect という値で制御されている

現在の設定値を「do getsebool -a |grep httpd_can_network」で確認し、「sudo setsebool -P httpd_can_network_connect on」で有効にする

$ sudo getsebool -a |grep httpd_can_network
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
$ sudo setsebool -P httpd_can_network_connect on
$ sudo getsebool -a |grep httpd_can_network
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
$

この変更ではhttpdの再起動は不要。

手順8-2: php-fpmの書き込み権限問題

プラグインやテーマのインストールについては問題なくても、WordPressのアップデートが出来ない。

このときの/var/log/audit/audit.logは下記

type=AVC msg=audit(1622101524.977:177): avc:  denied  { write } for  pid=2964 comm="php-fpm" name="wordpress" dev="dm-0" ino=101235463 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir permissive=0

こちらは/var/www/html/wordpress に対して httpdから書き込みが行えるような SELinuxのコンテキストをつけることで解決する。

「sudo chcon -R -t httpd_sys_script_rw_t /var/www/html/wordpress」

$ ls -lZ /var/www/html/
total 4
drwxr-xr-x. 5 apache apache unconfined_u:object_r:httpd_sys_content_t:s0 4096 May 27 15:02 wordpress
$ sudo chcon -R -t httpd_sys_script_rw_t /var/www/html/wordpress
$ ls -lZ /var/www/html/
total 4
drwxr-xr-x. 5 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 4096 May 27 15:02 wordpress
$

手順9: WordPressで取り扱えるファイルサイズの拡大

WordPressで取り扱えるファイルは標準状態だと2MBになっている。

これはphpの設定ファイル /etc/php.ini による制限となっている。

<略>
post_max_size = 8M
<略>
upload_max_filesize = 2M
<略>

で・・・よくある手順だと軽率に /etc/php.ini を書き換えていますが、 /etc/php.d/ 以下にファイルを追加することで、そちらの設定項目を優先させることができる機能があるため、 /etc/php.d/90-wordpress.ini に変更したい2行だけを記載したファイルを作成します。

$ sudo vi /etc/php.d/90-wordpress.ini
$ cat /etc/php.d/90-wordpress.ini
post_max_size = 100M
upload_max_filesize = 100M
$

phpの設定変更を反映させるために「sudo systemctl restart php-fpm」を実行します。

手順10: WordPressのSIte Health Status対応

WordPressのサイトステータスを見てみると、いくつかパッケージを要求されている。

ImageMagickに関するphpモジュールは含まれていない

$ dnf search magick
Last metadata expiration check: 2:56:09 ago on Thu 27 May 2021 01:10:22 PM JST.
======================== Name & Summary Matched: magick ========================
GraphicsMagick.aarch64 : An ImageMagick fork, offering faster image generation
                       : and better quality
GraphicsMagick.src : An ImageMagick fork, offering faster image generation and
                   : better quality
GraphicsMagick-c++.aarch64 : GraphicsMagick Magick++ library (C++ bindings)
GraphicsMagick-c++-devel.aarch64 : C++ bindings for the GraphicsMagick library
GraphicsMagick-debugsource.aarch64 : Debug sources for package GraphicsMagick
GraphicsMagick-devel.aarch64 : Libraries and header files for GraphicsMagick app
                             : development
GraphicsMagick-doc.noarch : GraphicsMagick documentation
GraphicsMagick-perl.aarch64 : GraphicsMagick perl bindings
ImageMagick-c++.aarch64 : ImageMagick Magick++ library (C++ bindings)
ImageMagick-c++-devel.aarch64 : C++ bindings for the ImageMagick library
ImageMagick-devel.aarch64 : Library links and header files for ImageMagick app
                          : development
ImageMagick-doc.aarch64 : ImageMagick html documentation
ImageMagick-libs.aarch64 : ImageMagick libraries to link with
ImageMagick-perl.aarch64 : ImageMagick perl bindings
============================= Name Matched: magick =============================
ImageMagick.aarch64 : An X application for displaying and manipulating images
ImageMagick.src : An X application for displaying and manipulating images
=========================== Summary Matched: magick ============================
converseen.aarch64 : A batch image conversion tool written in C++ with Qt5 and
                   : Magick++
converseen.src : A batch image conversion tool written in C++ with Qt5 and
               : Magick++
$

zipとgdはそれっぽいものがあるので「sudo dnf install php-pecl-zip php-gd -y」で追加

$ sudo dnf install php-pecl-zip php-gd -y
Last metadata expiration check: 3:04:44 ago on Thu 27 May 2021 01:04:16 PM JST.
Dependencies resolved.
================================================================================
 Package      Arch    Version                               Repository     Size
================================================================================
Installing:
 php-gd       aarch64 7.4.6-4.module+el8.3.0+7685+72d70b58  ol8_appstream  83 k
 php-pecl-zip aarch64 1.18.2-1.module+el8.3.0+7685+72d70b58 ol8_appstream  53 k
Installing dependencies:
 gd           aarch64 2.2.5-7.el8                           ol8_appstream 134 k
 jbigkit-libs aarch64 2.1-14.el8                            ol8_appstream  54 k
 libXpm       aarch64 3.5.12-8.el8                          ol8_appstream  56 k
 libjpeg-turbo
              aarch64 1.5.3-10.el8                          ol8_appstream 145 k
 libtiff      aarch64 4.0.9-18.el8                          ol8_appstream 178 k
 libwebp      aarch64 1.0.0-1.el8                           ol8_appstream 246 k
 libzip       aarch64 1.6.1-1.module+el8.3.0+7685+72d70b58  ol8_appstream  62 k

Transaction Summary
================================================================================
Install  9 Packages

Total download size: 1.0 M
Installed size: 3.0 M
Downloading Packages:
<略>
$

こちらは再起動は不要なようで、すぐにSite Healthの状態に反映され、imagickモジュールに関するメッセージのみになった。

バッファローWSR-1800AX4をEasyMesh対応にしてみた

$
0
0

うちの環境ではバッファローのWSR-1800AX4を2台使用している。

1台は無線AP(物理スイッチ:AP設定)として、もう1台は離れた場所にある有線LANを無線接続するためのブリッジ(物理スイッチ:WB設定)として使っている。(ルーターは別にある)

そんなWSR-1800AX4にfirmware version 1.02が提供された。

今回の売りは「EasyMesh機能追加」

画像

よし、アップデートするか!と思いつつ、ver 1.02の変更点にある「IPアドレスを手動設定していてもDHCPになる」に心当たりが・・・

WB設定側のWSR-1800AX4は確かにWiFi接続されるまでは固定IPアドレスで動いているけど、WiFi接続されたあとはアクセスできなくなってたんですよね・・・

画像

まさか、こんなバグだったとは・・・

まあ、それはさておき両方をアップデートしてみました。

AP側はこんな感じ

画像

WB側はこんな感じです。

画像

この状態で、AP側「プッシュボタンによるWPSを開始する」WB側「WiFiルーターとのWPSを開始する」をクリックすると接続処理が開始されます。

このとき、WB側の2.4GHz/5GHz WiFi設定で無線機能を無効に設定していると、EasyMeshではなく通常のブリッジ(WB)接続としてつながってしまいます。

EasyMeshはWB側もAPとして動く必要があるので無線機能を有効にしておく必要があります。(SSID名の指定などはWPSボタンによる自働EasyMesh設定により行われます)

EasyMeshの接続処理が終わると、AP側ではこんな表示になります。

コントローラが「AP」で、エージェントが「WB」です。

WB側はこんな感じです。

画像

ここで表示されている「SSID」は「Backhaul SSID」というもので、これを使ってWSR-1800AX4間を結んでいる感じになっています。

さて、EasyMeshを使うと、端末に近い方にあるWSR-1800AX4に接続されるようになります。

どちらに接続されているかは、コントローラ(AP)になっている方の接続機器一覧を開いて確認します。

画像

デバイスの「接続先」の数字が、コントローラ/エージェントにあるアクセスポイントのNoになります。

上記の場合、赤枠で囲った2台がエージェントのアクセスポイント(WB)につながっている、ということになります。

というわけで、WSR-1800AX4をEasyMesh対応にできる、というのは非常に有用なアップデートでした。

CentOS8/RHEL8でNVIDIA GPUドライバをレポジトリで適用する手法

$
0
0

Linux OSでNVIDIA GPUドライバを導入するには「Linux, FreeBSD, and Solarisドライバ」のページから「NVIDIA-Linux-x86_64-460.84.run」という実行形式のドライバを入手してインストール、というのが通例になっている。

しかし、同じNVDIA GPUを利用するCUDAの方の「CUDA Toolkitインストール」を見ると、下記の様にレポジトリを追加してのインストールを行っている。

Installation Instructions:
$ sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/cuda-rhel8.repo
$ sudo dnf clean all
$ sudo dnf -y module install nvidia-driver:latest-dkms
$ sudo dnf -y install cuda

上記で使用している https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/ を確認すると nvidia-driver-460.73.01-1.el8.x86_64.rpm などもあり、なんか使えそうな雰囲気が・・・

調べて見るとNVIDIA DEVELOPER BLOGに「Streamlining NVIDIA Driver Deployment on RHEL 8 with Modularity Streams」という記事を発見。

RHEL8の場合、レポジトリを3つ購読設定した上で

$ subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms
$ subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
$ subscription-manager repos --enable=codeready-builder-for-rhel-8-x86_64-rpms
$

NVIDIAのCUDAレポジトリを追加して

$ sudo dnf config-manager --add-repo=https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/cuda-rhel8.repo

最新版のnvidia-driverを選択してインストールする、となっている。

$ sudo dnf module install nvidia-driver:latest

また、dnfのモジュールシステムにより、複数バージョンのnvidia-driverが提供されているので、たとえば「460.xx」のドライバを使い続けたい、という指定も可能になっている模様。

おそらく「dnf module list | grep nvidia」で検索すると、指定できるバージョンが確認できるはずです。

RHEL8/CentOS8のdnf automaticのemitters設定を調べた

$
0
0

RHEL8/CetnOS8/Oracle Linux 8でのパッケージ自動アップデートはdnf-automaticで提供されることになった。

[RHEL8基本的なシステム設定の構成]-[第12章 ソフトウェアパッケージの管理]の「12.1. Red Hat Enterprise Linux 8 におけるソフトウェア管理ツール」にある説明と「DNF Automaticドキュメント」を見てみたが、いまいち分からない点があった。

それは[emitters]セクションのemit_viaで指定する文字列と、[email]セクション、[command]セクション、[command_mail]セクションの関係性である。

/etc/dnf/automatic.conf のRHEL8インストール時点でのemit_viaは「emit_via = stdio」となっている。
その上に「Default is email,stdio」なんて書いてあるけど、stdioで設定されている。

emit_via=stdioの場合

「emit_via=stdio」の場合、標準出力にdnf automaticでの実行結果が出力される。

出力された先はシステムログになっているので journalctlコマンドで確認できる。設定によっては /var/log/messages にも出力されることになる。

emit_via=emailの場合

「emit_via=email」の場合、[email]セクションに行われている設定が使用される。

メール送信は pythonのsmtplibを使用したSMTPプロトコルによって行われるため、適切に設定されていない場合は下記の様なエラーになる。

emit_via=commandの場合

「emit_via=command」の場合、[command]セクションにある設定が使用される。

command_formatとstdin_formatを調整して、コマンド実行オプションとそのコマンドに対する標準入力設定を調整する必要がある。

emit_via=command_emailの場合

「emit_via=command_email」の場合、[command_email]セクションにある設定が使用される。

やってること自体は[command]の場合とほぼ同じで、追加設定としてemail_fromとemail_toが指定できるようになっている感じである。

わざわざcommandとcommand_emailを分けている理由がわからない・・・

emit_via=motdの場合

「emit_via=motd」の場合、/etc/motdファイルに結果を出力することが出来る。

どう設定すればいいのか?

動作確認にしやすさとしては、「emit_via=stdio,command_email」として、[command_email]セクションでメールを送る設定が良いでしょう。

メールが送れない場合、command_formatに書かれている「”mail -Ssendwait -s {subject} -r {email_from} {email_to}”」を元に、例えば下記の様な形で実行して確認をすることが出来ます。

$ cat /etc/hosts | mail -Ssendwait -s testmail -r root@localhost root
-bash: mail: command not found
$

あ・・・最小インストールだとmailコマンドが入ってないですね・・・

command_emailを使用する場合は「sudo dnf install mailx」でmailxパッケージを追加インストールしてください。


Oracle CloudのOracle Linux 8で標準選択されているesmtpでメールを送信する

$
0
0

Oracle Cloud上のOralce Linux 8インスタンスでは、postfixやsendmailではなく、esmtpがインストールされている。

esmtpはRHEL8やCentOS8でも用意されているが、実際に使用している情報があまりない。

esmtp公式ページを見ると「THIS PROJECT IS NO LONGER BEING MAINTAINED. IF IT DOESN’T WORK FOR YOU SEE THESE LINKS.」と書いてあり、本来は利用推奨ではないようだ。

ざっと見たところ日本語情報としてまとまっているのは2010年に書かれた 本を読む の「軽量MTA「esmtp」を試してみた」だった。

esmtpはデーモンではなく、ポート25での待受もせず、/usr/lib/sendmailや/usr/bin/mail を実行する形でのメール送信が実行できるようにするためのソフトウェアです。

ローカルのUNIXユーザ宛にメールを届けたい場合は別途 procmailパッケージをインストールする必要があります。

他のサーバ宛にメールを送りたい場合は、外部のSMTPサーバのアカウント情報を登録し、SMTP AUTHを利用したメール送信が可能です。

難点は、メール送信に関するログがどこにも保存されない、ということ。

設定に失敗してメールが送信できなかった場合でもどう調べればいいのか分からない、という問題点も・・・

また、SMTP AUTHに使うパスワードを平文で設定ファイルに書く必要があるというのも、なかなかな問題点です。

とはいえ、期待通りに動けば簡単に外部SMTPを使用してメール送信ができるし、各サーバに同じ設定を入れておくとシステム系メールの送信元メールアドレスを全て同じにする、ということも容易な感じです。

設定

esmtpの設定は、システム全体に適用される /etc/esmtprc と、各UNIXユーザごとの~/.esmtprc で行います。

とりあえずシステム系メールを送りたいだけであれば /etc/esmtprc を設定しておけばいい感じです。

/etc/esmtprc は用意されていないので /usr/share/doc/esmtp/sample.esmtprc にあるサンプルをコピーして使うか、全部を書きます。

sample.esmtprcの内容

# Sample configuration file for ESMTP.
#
#       Jose Fonseca

# Set SMTP host and service (port)
#
hostname = localhost:25

# Set the user name
#
username = "USERNAME"

# Set the password
password = "PASSWORD"

# Use the Starttls
#
#starttls = disabled
#
# It can be one of "enabled", "disabled" or "required". It defaults to
# disabled.

# Set the certificate passphrase
#
#certificate_passphrase = "CERTIFICATE_PASSPHRASE"

# Command to run before contacting the SMTP server
#
#preconnect = "ssh -f -L 2025:mail.isp.com:25 user@shell.isp.com 'sleep 5'"


# Same as above but for a different identity which can be selected with the
# '-f' flag. You can have as many you like.
#
identity = myself@somewhere.com
        hostname = smtp.somewhere.com:25
        username = "myself"
        password = "secret"
        #starttls = disabled
#
# NOTE: the default indentity settings aren't shared by the other identities.
# Everything (username, password, etc.) must be specified for every identity
# even if they don't differ from the default identity.


# Set the Mail Delivery Agent (MDA)
#
mda = "/usr/bin/procmail -d %T"
#
# Some possible MDAs are "/usr/bin/procmail -d %T", "/usr/bin/deliver" or
# "/usr/lib/mail.local %T".

これを使ってもいいのですが、全部書いた方が簡単ですね。

外部のSMTPサーバを使って送信する設定例

Net@ddressというかれこれ20年以上使っているメールサービスのアカウントを使用してメール送信する設定です。

hostname=smtp.postoffice.net:25
username="ユーザ名@usa.net"
password="パスワード"

mda "/usr/bin/procmail -d %T"

これを /etc/esmtprc に書いたサーバから mailコマンドを使って送信したメールは全て「ユーザ名@usa.net」が発信元となって送られることになります。

また、「mda “/usr/bin/procmail -d %T”」という設定を入れているので、ローカルユーザ宛のメールであれば /var/spool/mail/ に配送されるようにしています。

SMTP送信時にstarttlsが必要な場合は「starttls=enabled」を追加すればいいようなのですが、下記の手順でやったのですが、送信されませんでした。

$ mkdir ~/.authenticate
$ chmod 0700 ~/.authenticate
$ wget http://curl.haxx.se/ca/cacert.pem
$ mv cacert.pem ~/.authenticate/ca.pem
$ chmod 0600 ~/.authenticate/ca.pem
$ mailx メール送り先@ドメイン名
Subject: test mail 5
test mail 5
.
EOT
$ 0 (null)
メール送り先@ドメイン名: 0 (null)
0 (null)
メール送り先@ドメイン名: 0 (null)
メール送り先@ドメイン名: 0 (null)
procmail: Unknown user "-r"
0 (null)
メール送り先@ドメイン名: 0 (null)
メール送り先@ドメイン名: 0 (null)
procmail: Unknown user "-r"

とりあえずstarttls対応は保留ですね。

なお、 /etc/esmtprcでは、下記の様な書式を使うこともできます。

identity ユーザ名@usa.net
        hostname smtp.postoffice.net:25
        username "ユーザ名@usa.net"
        password "パスワード"
        default

mda "/usr/bin/procmail -d %T"

ユーザによってアカウントを変える場合はこれを使うようです。

Oracle Cloud上のインスタンスから管理メールを送信する手法

$
0
0

Oracle Cloud上に作成したインスタンスのうち、Oracle Autonomouse Linux 7インスタンスだと適切に設定している場合、yum-cronなどが実行された際に 送信者 noreply@notification.~.oci.oraclecloud.com でメールを送信する設定になっている。

Oralce Linux 8インスタンスだとそのような設定にはなっていない。

似たような形でインスタンスのrootから送信されるメールを noreply@notification.~.oci.oraclecloud.com で発信する方法があるかを確認した。

参考ドキュメント
Oracle Cloud Infrastructureドキュメント「電子メール配信の開始
Oracle Cloud Infrastructureドキュメント「Postfixと電子メール配信の統合

しかし、「電子メール配信」については有料アカウントが必要になるようだ。

Oracle Autonomouse Linux 7インスタンスが利用しているのは「通知」の方になっている

このサブスクリプション設定が流用できればいいんですけど・・・

Oracle Cloud : 通知サービスとoci-cliを使って一時間ごとにDBCSの状態を通知する

この情報が使えそうです。

今回の環境ではすでに[開発者サービス]-[アプリケーション統合]-[通知]に

すでにAutonomouse Linux用で作成したトピックが作成されているため、それを流用します。

上記の「AL_notification」のトピックOCIDを使用してコマンドを実行・・・

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.<略> --title "test mail" --body "test mail"
-bash: oci: command not found
$

oci-utilsのパッケージがアップデートされていないとエラーになります。その場合はアップデートします。

$ sudo dnf update oci-utils -y
Last metadata expiration check: 4:26:16 ago on Tue 08 Jun 2021 01:30:06 PM JST.
Dependencies resolved.
================================================================================
 Package                  Arch     Version            Repository           Size
================================================================================
Upgrading:
 oci-utils                noarch   0.12.4-1.el8       ol8_oci_included    245 k
Installing dependencies:
 python3-arrow            noarch   0.17.0-1.0.1.el8   ol8_oci_included    101 k
 python3-click            noarch   6.7-8.el8          ol8_appstream       131 k
 python3-convertdate      noarch   2.3.0-1.0.1.el8    ol8_oci_included     83 k
 python3-dateparser       noarch   1.0.0-1.0.1.el8    ol8_oci_included    392 k
 python3-hijri-converter  noarch   2.1.1-1.0.1.el8    ol8_oci_included     30 k
 python3-jmespath         noarch   0.10.0-1.el8       ol8_oci_included     48 k
 python3-pymeeus          noarch   0.3.6-2.0.1.el8    ol8_oci_included    1.1 M
 python3-regex            aarch64  2021.4.4-1.el8     ol8_developer_EPEL  328 k
 python3-retrying         noarch   1.3.3-1.0.1.el8    ol8_oci_included     22 k
 python3-terminaltables   noarch   3.1.0-1.0.1.el8    ol8_oci_included     31 k
 python3-tzlocal          noarch   2.0.0-4.el8        ol8_oci_included     37 k
 python36-oci-cli         noarch   2.22.1-1.el8       ol8_oci_included    6.4 M

Transaction Summary
================================================================================
Install  12 Packages
Upgrade   1 Package

Total download size: 8.9 M
<略>
$

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.<略> --title "test mail" --body "test mail"
ERROR: Could not find config file at /home/opc/.oci/config, please follow the instructions in the link to setup the config file https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/sdkconfig.htm
$

ociコマンドに必要な諸設定を行っていないのでエラーになりました。

まず、キーを作成します。なお、passphraseは何も入力せずエンターキーのみにします(そうしないとスクリプト実行の時にpassphraseを要求される)

$ oci setup keys
Enter a passphrase for your private key (empty for no passphrase):
Public key written to: /home/opc/.oci/oci_api_key_public.pem
Private key written to: /home/opc/.oci/oci_api_key.pem
Public key fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx


    If you haven't already uploaded your API Signing public key through the
    console, follow the instructions on the page linked below in the section
    'How to upload the public key':

        https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#How2

$  ls -al ~/.oci
total 8
drwx------. 2 opc opc   59 Jun  7 17:32 .
drwx------. 5 opc opc  138 Jun  7 17:32 ..
-rw-------. 1 opc opc 1679 Jun  7 17:32 oci_api_key.pem
-rw-------. 1 opc opc  451 Jun  7 17:32 oci_api_key_public.pem
$

作成された oci_api_key_public.pem の内容を[アイデンティティとセキュリティ]-[アイデンティティ]-[ユーザー]に登録されている各ユーザから、使用するユーザを選択し[リソース]-[APIキー]に登録します。

つぎに~/.oci/config ファイル作成のために

[ガバナンスと管理]-[アカウント管理]-[テナンシ詳細]にて、テナントのOCIDを取得

また、ユーザのOCIDと先ほど登録したAPIキーのフィンガープリントを configファイルに記載する。

$ cat ~/.oci/config
[DEFAULT]
key_file=/home/opc/.oci/oci_api_key.pem
region=ap-tokyo-1
tenancy=ocid1.tenancy.oc1..aaaaaaaa7lml<略>
user=ocid1.user.oc1..aaaaaaaamenibh4iny<略>
fingerprint=<略>
$

記載してociコマンドを再実行

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.aa<略> --title "test mail" --body "test mail"
WARNING: Permissions on /home/opc/.oci/config are too open.
To fix this please try executing the following command:
oci setup repair-file-permissions --file /home/opc/.oci/config
Alternatively to hide this warning, you may set the environment variable, OCI_CLI_SUPPRESS_FILE_PERMISSIONS_WARNING:
export OCI_CLI_SUPPRESS_FILE_PERMISSIONS_WARNING=True

{
  "data": {
    "message-id": "56ca7636-1605-7a19-5344-<略>",
    "time-stamp": null
  }
}
$

まず、「WARNING: Permissions on /home/opc/.oci/config are too open.」についてはパーミッション問題なので、書いてある通りに対処する。

$ ls -l /home/opc/.oci/config
-rw-rw-rw-. 1 opc opc 299 Jun  7 17:43 /home/opc/.oci/config
$ oci setup repair-file-permissions --file /home/opc/.oci/config
$ ls -l /home/opc/.oci/config
-rw-------. 1 opc opc 299 Jun  7 17:43 /home/opc/.oci/config
$

再実行

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.aaaaaaaacesi5<略> --title "test mail" --body "test mail"
{
  "data": {
    "message-id": "c491e672-9401-beb3-16f5-<略>",
    "time-stamp": null
  }
}
$

成功か失敗か分かりづらいですが、成功していました。(WARNING: Permissions の時のやつもメール送信は出来ていました)

というわけで、ociコマンドを使用することで、Oracle Cloudの通知を使ってシステムメールを送信することができそうなことがわかりました。

ociコマンドは https://github.com/oracle/oci-cli にソースがある

つぎに dnf automaticでそれを実行するにはどういう手法が最適化の検討です。

DNF Automatic」には「[command] section」と「[command_email] section」があり、利用できそうです。

違いの詳細については「RHEL8/CentOS8のdnf automaticのemitters設定を調べた」に書きましたが、今回の場合は[command_email]sectionを使うことにします。

dnf automaticではメール本文を標準入力で指定することになっていて、そのままではociコマンドのbodyオプションとして渡すことができません。

なので、Oracle Cloud Infrastructure Document Notifications Publish Messages(日本語版) を起点に調べていったところOracle Cloud Infrastructure Documentation / API Reference and Endpoints の「PublishMessage」にて、REST API/Java SDK/Python SDK/Go SDK/TypeScript SDK/.NET SDK/Ruby SDKを使った場合のコードサンプルを発見。

ociコマンドはpyhonを使っているので、Python SDKのサンプルコードを利用した /usr/local/bin/oci-notification-mail を作って使用します。

topic_id=のところは自分の環境に合わせてください。

$ sudo vi /usr/local/bin/oci-notification-mail
$ cat /usr/local/bin/oci-notification-mail
#!/usr/bin/python3
# This is an automatically generated code sample.
# To make this code sample work in your Oracle Cloud tenancy,
# please replace the values for any parameters whose current values do not fit
# your use case (such as resource IDs, strings containing ‘EXAMPLE’ or ‘unique_id’, and
# boolean, number, and enum parameters with values not fitting your use case).

import oci
import sys

argvs=sys.argv
argc = len(argvs)
subject=argvs[1]
textbody="".join(sys.stdin.readlines())

# Create a default config using DEFAULT profile in default location
# Refer to
# https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/sdkconfig.htm#SDK_and_CLI_Configuration_File
# for more info
config = oci.config.from_file()


# Initialize service client with default config file
ons_client = oci.ons.NotificationDataPlaneClient(config)

# Send the request to service, some parameters are not required, see API
# doc for more info
publish_message_response = ons_client.publish_message(
    topic_id="ocid1.onstopic.oc1.ap-tokyo-1.<略>",
    message_details=oci.ons.models.MessageDetails(
        body=textbody,
        title=subject),
    message_type="RAW_TEXT")

# Get the data from response
print(publish_message_response.data)
$ sudo chmod a+x /usr/local/bin/oci-notification-mail
$

まずこれを作成したあと、送信テストをします。

$ cat /etc/hosts | /usr/local/bin/oci-notification-mail testmail
{
  "message_id": "ef1aa15b-98d0-1824-68ef-<略>",
  "time_stamp": null
}
$

これを実行してしばらく待つと、「Subject:testmail」 で、本文が/etc/hostsの中身になっているメールが届きます。

スクリプトが正常に動作することを確認できたら、次はdnf automaticの設定を変更します。

変更する場所は2つ

「[emitters] セクション」のemit_via を「emit_via=command_email」に変更

「[command_email]セクション」のcommand_formatを「command_format = “/usr/local/bin/oci-notification-mail {subject}”」、「#stdin_format = “{body}”」を「stdin_format = “{body}”」に変更します。

これにより、dnf automaticでパッチが適用された場合に下記の様なメールが届くようになりました。

おまけ

ちなみに、Oracle Linux 8の標準インスタンスではpostfixやsendmailではなく、esmtp というパッケージでメール送信が行われるようです。

$ ls -l /usr/sbin/sendmail
lrwxrwxrwx. 1 root root 21 May 27 13:04 /usr/sbin/sendmail -> /etc/alternatives/mta
$ ls -l /etc/alternatives/mta
lrwxrwxrwx. 1 root root 22 May 27 13:04 /etc/alternatives/mta -> /usr/bin/esmtp-wrapper
$ ls -l /usr/bin/esmtp-wrapper
-rwxr-xr-x. 1 root root 3374 Jul  2  2020 /usr/bin/esmtp-wrapper
$  rpm -qa|grep smtp
esmtp-1.2-15.el8.aarch64
libesmtp-1.0.6-18.el8.aarch64
$ alternatives --display mta
mta - status is auto.
 link currently points to /usr/bin/esmtp-wrapper
/usr/bin/esmtp-wrapper - priority 30
 slave mta-sendmail: /usr/bin/esmtp-wrapper
 slave mta-sendmailman: /usr/share/man/man1/esmtp.1.gz
 slave mta-mailq: /usr/bin/esmtp-wrapper
 slave mta-mailqman: /usr/share/man/man1/esmtp.1.gz
Current `best' version is /usr/bin/esmtp-wrapper.
$

公式ページに「THIS PROJECT IS NO LONGER BEING MAINTAINED. IF IT DOESN’T WORK FOR YOU SEE THESE LINKS.」って書いてあるのにRHEL/CentOS/Oracle Linux 8で使っているのか・・・

ESXi 7.0 Update 1からSDカード/USBメモリ起動の場合に書き込み回数性能が重要になった件について

$
0
0

VMware vSphere / ESXi 7.0 から ESXiのブートディスクの構造が変更になった。

VMware vSphere Blog「vSphere 7 – ESXi System Storage Changes
「ESXi のシステム ストレージの概要」の「ESXi 7.0 のシステム ストレージの変更

ESXi 6.0時代 /scratch となっているパーテーションとかあるが、基本的に起動したあとデータ書き込みはあまりないかたちで運用されていた。

ところがESXi 7.0からは細かく分かれていたパーテーションがESX-OSDataパーテーションに統合されている。しかも、ここに書き込みが行われるようになった。

そして、ESXi 7.0 Update 1 / Update 2においてSDカード / USBメモリへの書き込み手法が変更され、起動ディスクに対して従来と比較すると多量の書き込み操作が実行されることになった。

これにより、ESXi 7.0 Update 1 / Update 2において、SDカード/USBメモリ起動にしている場合に、書き換え回数超過によるSDカード/USBメモリのアクセス不可事例が発生しやすくなっているようだ。

VMware KB VMFS-L Locker partition corruption on SD cards in ESXi 7.0 (83376)
VMware Technolopy Network「SD Boot issue Solution in 7.x

上記KB83376を見ると、ESXi 7.0(初期)ではI/O抑制機能があったが、ESXi 7.0 Update 1ではなくなったことが発生しやすくなった要因の1つであるようだ。

しかも、VMware的には「ESXi のシステム ストレージの概要」で、「ESX-OSData は 高耐久性ストレージ デバイス上に作成する必要があります。」と書いてあるから、書き換え回数上限が低いものを使わないのは当然でしょ、というスタンスな模様。

OEMメーカが選定したSDカードなどが死んだとしても、それはその部材を選んだOEMメーカ側の責任だということらしい。

実際、DELLの「VMware vSphere 7.x on Dell EMC PowerEdge Servers Getting Started Guide」の「Getting started with VMware vSphere」をみると、ESXi 7.0ではSDカードは推奨しない、と書いてある。

NOTE: If you had ordered VMware ESXi with your Dell EMC PowerEdge server, it is preinstalled on your server. The ESXi installer media is required for reinstallation. The Boot Optimized Storage Solution (BOSS) card is the preferred non-HDD or SSD device for VMware ESXi 7.0 installation. The Dell Internal Dual SD Module (IDSDM) install is no longer recommended due to write endurance issues with the SD flash media. For more information, see the Storage Requirements for ESXi 7.0 Installation or Upgrade section on the VMware ESXi Installation and Setup Guide or see VMware Knowledge Base article 2145210.

さて、この問題について、とることができる方策は下記の5つが考えられる。

その1) 高耐久性のものに変更する(USB接続のSSDや、MLCチップのSDカードなど)
その2) 普通のSSDやHDD起動に変更する
その3) ESXi 7.0 Update 2用の現象低減パッチが7月中にリリース予定(ただし、低減、である)
その4) メインメモリを消費してRamdiskを作成し、そこに書き込ませる
その5) あきらめて、壊れたら交換&ESXi再セットアップ

その4の手法はVMware KB83376 内にリンクがあり「High frequency of read operations on VMware Tools image may cause SD card corruption (2149257)」で説明されている。

ドキュメント的にはESXi 6.0 と ESXi 6.5用になっているが、ESXi 7.0でも適用できるようだ。

ESXi 7.0のshellに入って、現在の /UserVars/ToolsRamdisk の設定を確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 0
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 0」ということなので、現在は「0」となっている。

これを1に変更するため、以下を実行する

# esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1
#

変更が反映されたか確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 1
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 1」となっていたら変更されている。

この後、ESXi を再起動して、RAMディスクを実際に稼働させる。

ESXi設定のバックアップ&リストア

SDカード/USBメモリが壊れることを許容する場合、ESXiの設定ファイルをバックアップしておき、再セットアップ時にリストアする、という手法が考えられる。

手法はVMware KB「ESXi ホストの構成のバックアップ方法 (2042141)

リストアの際、ESXiにIPアドレスを割り当てておく必要がある。

Oracle Cloud上Linuxインスタンスでol-consolebaud.serviceの起動に失敗している

$
0
0

2020年にOracle Cloud上に作ったLinuxインスタンスの状態を「systemctl status」で確認してみたら、ol-consolebaud.serviceの起動に失敗していた。

画像
ol-consolebaud.service: main process exited, code=exited, status=1/FAILURE
Failed to start Check console baud rate.
Unit ol-consolebaud.service entered failed state.
ol-consolebaud.service failed.

検索してみるとRogerio Eguchi Blog の「OCI – ol-consolebaud.service」を発見。

/etc/default/grub に書かれているシリアルコンソール設定の速度が9600から115200に変更になったことが原因のようである。

Oracle Cloud Infrastructure ドキュメントを確認すると「インポートされたLinuxイメージでのシリアル・コンソール・アクセスの有効化」のブートローダの構成で設定している速度が115200になっている。そして、”シリアルコンソールアクセスの検証”では9600になっていてドキュメントの整合性がとれていない・・・というわけで、途中で変更されたようなのだが、All Oracle Linux 7.x Images の履歴をみたけど、それっぽい変更が見当たらない・・・うーん?

まあ、ともかく原因は判明したのでGRUB_CMDLINE_LINUX行の「console=ttyS0,9600」を「console=ttyS0,115200」に変更。

そして、 「grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」でgrubブートローダに変更を反映して、再起動。

これでol-consolebaudが正常に起動するようになった。

Oracle Cloud上のLinuxインスタンスでiscsistartというサービスが起動失敗している

$
0
0

Oracle Cloud上Linuxインスタンスでol-consolebaud.serviceの起動に失敗している」の件で、これまでに作ったインスタンスの状態を確認していったところ、一番古いLinuxインスタンスでは「iscsistart_169.254.0.2:::1:iqn.2015\http://x2d02.oracle.boot:uefi.service」というサービスの起動に失敗していた。

ぐぐるとOracleサポートの「OCI: iscsistart attempts to connect iscsi target when the network link is not ready (Doc ID 2610486.1)」が出てくるがサポートがないので内容がわからない。

とりあえず、起動失敗しているものと起動成功しているものの/etc/default/grubを比較してみたところ、起動成功しているもののGRUB_CMDLINE_LINUX行には「rd.iscsi.bypass」が追加されていた。

GRUB_CMDLINE_LINUX行に追加して「grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」を実行してgrub設定を更新、再起動して、問題無く起動するようになった。


確認したOracle Linuxインスタンスの /etc/default/grub設定の比較

Oracle-Linux-7.7-2019.08.28-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 loglevel=4"

CentOS-7-2020.06.16-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 transparent_hugepage=never console=tty0 console=ttyS0,9600 libiscsi.debug_libiscsi_eh=1 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 ip=dhcp netroot=iscsi:169.254.0.2::::iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 rd.iscsi.bypass"

Oracle-Autonomous-Linux-7.8-2020.05-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 rd.iscsi.bypass=1 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 loglevel=4"

Oracle-Linux-8.3-2021.05.12-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.md=0 rd.dm=0 rd.lvm.vg=ocivolume rd.lvm.lv=ocivolume/root rd.net.timeout.carrier=5 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 libiscsi.debug_libiscsi_eh=1 loglevel=4 ip=single-dhcp crash_kexec_post_notifiers"

Oracle-Linux-8.3-aarch64-2021.05.12-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=ttyAMA1 console=ttyAMA0,115200 rd.luks=0 rd.md=0 rd.dm=0 rd.lvm.vg=ocivolume rd.lvm.lv=ocivolume/root rd.net.timeout.carrier=5 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 libiscsi.debug_libiscsi_eh=1 loglevel=4 ip=single-dhcp crash_kexec_post_notifiers"

Oracle Cloud上の古いOracle Linux 7インスタンスのyum設定を更新する

$
0
0

「Notices: General Notices for Oracle Linux Images」というページに「2021.03 – Yum Update for Oracle Linux 7 and Oracle Linux 8 Instances」というのを発見した。

たしかに2021年3月より前に作成したインスタンス Oracle-Linux-7.7-2019.08.28-0, Oracle-Autonomous-Linux-7.8-2020.05-0 には oci-linux-config というパッケージはインストールされていなかった。

$ rpm -qa|grep oci-linux-config
$

とりあえず、ここに書いてある手順通りに進めていく

$ curl -H "Authorization:Bearer Oracle" -sfm 25 http://169.254.169.254/opc/v2/instance/ 2>/dev/null | jq -r '.regionInfo.realmKey'
oc1
$

上記では「oc1」という結果が出力されているが、「oc1」~「oc4」ならOKとのこと。

oci-linux-config パッケージをインストール

$ sudo yum -y install oci-linux-config
読み込んだプラグイン:langpacks, ulninfo
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ oci-linux-config.noarch 0:1.0-3.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package               アーキテクチャー
                                   バージョン      リポジトリー            容量
================================================================================
インストール中:
 oci-linux-config      noarch      1.0-3.el7       ol7_ociyum_config       13 k

トランザクションの要約
================================================================================
インストール  1 パッケージ

総ダウンロード容量: 13 k
インストール容量: 29 k
Downloading packages:
oci-linux-config-1.0-3.el7.noarch.rpm                      |  13 kB   00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : oci-linux-config-1.0-3.el7.noarch               1/1
IMPORTANT: PLEASE NOTE!!  Oracle Linux yum repository configurations have been updated. New repository configuration files have been installed but are disabled.  To complete the transition, run this script as root user:

/usr/lib/oci-linux-config/oci_yum_configure.sh

  検証中                  : oci-linux-config-1.0-3.el7.noarch               1/1

インストール:
  oci-linux-config.noarch 0:1.0-3.el7

完了しました!
$

/usr/lib/oci-linux-config/oci_yum_configure.sh を実行して /etc/yum.repos.d/ のレポジトリファイルを作成

$ ls -l /etc/yum.repos.d/
合計 84
-rw-r--r--. 1 root root  488  2月 17 06:40 ksplice-ol7.repo
-rw-r--r--. 1 root root  273  5月 13 15:39 oracle-epel-ol7.repo
-rw-r--r--. 1 root root  242  8月 15  2019 oracle-epel-ol7.repo.20190815
-rw-r--r--. 1 root root  252  5月 13 15:38 oracle-epel-ol7.repo.20210217
-rw-r--r--. 1 root root 4322  6月 11 04:12 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 3825  7月 10  2020 oracle-linux-ol7.repo.20200710
-rw-r--r--. 1 root root 4586  6月  9 12:57 oracle-linux-ol7.repo.rpmnew
-rw-r--r--. 1 root root 1067  2月 26 04:35 oracle-php-ol7.repo
-rw-r--r--. 1 root root  797  4月  6  2020 oracle-php-ol7.repo.20200406
-rw-r--r--. 1 root root  275  8月 15  2019 oracle-softwarecollection-ol7.repo
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo.rpmnew
-rw-r--r--. 1 root root 1041  2月  5 04:15 oraclelinux-developer-ol7.repo
-rw-r--r--. 1 root root  802 12月 27  2019 oraclelinux-developer-ol7.repo.20200406
-rw-r--r--. 1 root root 3117  9月 30  2019 public-yum-ol7.repo.sav
-rw-r--r--. 1 root root 2577  5月 28  2020 uek-ol7.repo
-rw-r--r--. 1 root root 2108  4月  6  2020 uek-ol7.repo.20200406
-rw-r--r--. 1 root root 2587  2月 17 06:42 uek-ol7.repo.rpmnew
-rw-r--r--. 1 root root  225  5月 28  2020 virt-ol7.repo
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo.rpmnew
$ sudo /usr/lib/oci-linux-config/oci_yum_configure.sh
読み込んだプラグイン:langpacks, ulninfo
No packages marked for update
Disabling Repository ol7_UEKR6
Repository ol7_developer already enabled
Repository ol7_developer_EPEL already enabled
Repository ol7_developer_php74 already enabled
Repository ol7_ksplice already enabled
Repository ol7_latest already enabled
Repository ol7_software_collections already enabled
Enabling Repository ol7_UEKR5
Enabling Repository ol7_addons
Repository ol7_developer already enabled
Repository ol7_developer_EPEL already enabled
Repository ol7_developer_php74 already enabled
Repository ol7_ksplice already enabled
Repository ol7_latest already enabled
Enabling Repository ol7_ociyum_config
Enabling Repository ol7_optional_latest
Repository ol7_software_collections already enabled
$ ls -l /etc/yum.repos.d/
合計 104
-rw-r--r--. 1 root root  488  2月 17 06:40 ksplice-ol7.repo
-rw-r--r--. 1 root root  273  5月 13 15:39 oracle-epel-ol7.repo
-rw-r--r--. 1 root root  242  8月 15  2019 oracle-epel-ol7.repo.20190815
-rw-r--r--. 1 root root  252  5月 13 15:38 oracle-epel-ol7.repo.20210217
-rw-r--r--. 1 root root 4586  6月 16 10:15 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 3825  7月 10  2020 oracle-linux-ol7.repo.20200710
-rw-r--r--. 1 root root 4322  6月 11 04:12 oracle-linux-ol7.repo.bkp
-rw-r--r--. 1 root root 4586  6月  9 12:57 oracle-linux-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root 1067  2月 26 04:35 oracle-php-ol7.repo
-rw-r--r--. 1 root root  797  4月  6  2020 oracle-php-ol7.repo.20200406
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo
-rw-r--r--. 1 root root  275  8月 15  2019 oracle-softwarecollection-ol7.repo.bkp
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root 1041  2月  5 04:15 oraclelinux-developer-ol7.repo
-rw-r--r--. 1 root root  802 12月 27  2019 oraclelinux-developer-ol7.repo.20200406
-rw-r--r--. 1 root root 3117  9月 30  2019 public-yum-ol7.repo.sav
-rw-r--r--. 1 root root 2587  6月 16 10:15 uek-ol7.repo
-rw-r--r--. 1 root root 2108  4月  6  2020 uek-ol7.repo.20200406
-rw-r--r--. 1 root root 2577  5月 28  2020 uek-ol7.repo.bkp
-rw-r--r--. 1 root root 2587  2月 17 06:42 uek-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo
-rw-r--r--. 1 root root  225  5月 28  2020 virt-ol7.repo.bkp
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo.rpmnew.bkp
$

以前のrepoファイルは全て bkpという名前にリネームされて置き換わった感じですね。

各レポジトリファイルの変更点は「baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/」という記載だったものが「baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/」というように「oracle.com」以外のドメインが設定される可能性に配慮したものに変更されていた。

この$ociregionや$ocidomainはどこで設定されているかというと /etc/yum/vars/ にあるファイルで定義されています。

$ ls -l /etc/yum/vars/
合計 12
-rw-r--r--. 1 root root 11  6月 16 10:15 ocidomain
-rw-r--r--. 1 root root 14  6月 16 10:15 ociregion
-rw-r--r--. 1 root root 13  6月 16 10:15 region
$ cat /etc/yum/vars/ocidomain
oracle.com
$ cat /etc/yum/vars/ociregion
-us-phoenix-1
$ cat /etc/yum/vars/region
us-phoenix-1
$

grubで止まったEFI機のLinuxを起動させる

$
0
0

Oracle Cloud上のCentOS 7インスタンスをOracle Linux 7にコンバートさせたら、一部のパッケージがうまくインストールできず、centos2ol.sh が途中で失敗した。

yum distro-syncを実行したらうまくいったので、大丈夫かな?と思ったら、grub関連が更新できずに起動に失敗した模様。

Oracle Cloudの場合、Web管理コンソールから該当インスタンスのディスプレイをVNC接続で表示するための設定ができるので、それでつなげてみたところ下記の様にgrubで停止していた。

まず、ディスクとパーテーションがどう認識されているが分からないので「ls」を実行します。

そうすると、「(ディスク名)」と「(ディスク名),(パーテーション名)」の一覧が表示されます。

grub> ls
(hd0)  (hd0,gpt3)  (hd0,gpt2)  (hd0,gpt1)  (fd0)  (fd1)
grub> 

上記の場合、hd0の中にパーテーションが3つある、ということになります。

各パーテーションのファイルシステムがなんなのかを「ls (hd0,gpt0)」と実行すると表示されます。

grub> ls (hd0,gpt2)
(hd0,gpt2): Filesystem is unknown.
grub> ls (hd0,gpt3)
(hd0,gpt3): Filesystem is xfs.
grub> ls (hd0,gpt1)
(hd0,gpt1): Filesystem is fat.
grub>

上記の結果により、パーテーション1:FAT、パーテーション3:XFS、パーテーション2:不明となります。

「ls (hd0,gpt1)/」と最後に/をつけると中にどんなファイル/ディレクトリがあるかを確認出来ます。

grub> ls (hd0,gpt1)/
efi/
grub> ls (hd0,gpt3)/
./ ../ boot/ dev/ proc/ run/ sys/ etc/ var/ root/ tmp/ usr/ bin sbin lib lib64
home/ media/ mnt/ opt/ srv/
grub>

上記により efi/があるパーテーション1は、/boot/efi があるパーテーション
パーテーション3は / があるパーテーションとなり
消去法的にパーテーション2は、ファイルシステムがないのでswapパーテーションとなる。

起動するにあたっては、linuxefi でvmlinuzファイルと、root=で/パーテーション指定を行い、initrdedi でinitramfsファイルを指定する形となる。

下記の様に入力して起動を行う。

grub> linuxefi (hd0,gpt3)/boot/vmlinuz-5.4.17-2102.202.5.el7uek.x86_64 root=/dev/sda3
grub> initrdefi (hd0,gpt3)/boot/initramfs-5.4.17-2102.202.5.el7uek.x86_64.img
grub> boot

なお、vzlinuzやinitramfsのファイル名は分からないと思うが、その場合は下記の様に「initrdefi (hd0,gpt3)/boot/initra」まで入力してからタブキーを押すと候補が表示されるので、それを利用すると良い。

画像

bootが開始されると、クラウド上でも普通のLinux環境と同じように起動表示がある。

で、ログインが出来るようになった。

Oracle Cloud上のインスタンスは、ssh keyでログインしているのでパスワードがわからないので、ssh経由で接続して続きを行う。

まず、起動できなかった原因は /etc/grub2-efi.cfg (/boot/efi/EFI/redhat/grub.cfg)が存在しないということだった。

「sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」を実行して、grub.cfgを再作成することで対応できる。

参照:CentOS8からOracle Linux 8への移行1

再作成して再起動するときちんと下記の様にkernel選択画面が表示され、自動起動することが確認出来た。


CentOS代替のVzLinux(VirtuozzoLinux)をインストールしてみた

$
0
0

このblogのOracle Linux関連記事にこんな広告が表示された。

画像

VzLinux」なんてものがあるのかと別途ググってアクセスしてみた。(直接リンク飛ぶと規約上微妙なので)

画像

VzLinuxは、Linuxベースの仮想コンテナのVirtuozzo とそのオープンソース版OpenVZ の作っているLinux ディストリビューションで、この仮想コンテナを動かすにはRHEL/CentOSやUbuntuのデフォルトカーネル設定ではダメなので、稼働できる形でコンパイルしたものを提供していたものをディストリビューションとしても提供し始めたような感じである。

これに関連してか「Virtuozzo Linux 8 Quick Start Guide」の「3.3. Updating the Kernel」には、カーネルのアップデートのために「yum update vzkernel vzkernel-devel」を実行する、とあるが、実際のVzLinux 8上しても、vzkernelというパッケージは存在せず実行できない。

おそらくは、仮想コンテナVirtuozzo/OpenVZ用に提供されているバージョンであればvzkernelを使う、という話なんだろう、と思われる。

それはさておき、仮想環境にインストールしてみた。

VzLinux 8.3の時点ではセキュアブート非対応であるため、仮想マシンもそのように設定して起動。

画像

言語の選択で「日本語」を選ぶことができるが、インストール完了後、X-Windowアプリの一部でアプリ起動に失敗するので、基本的には「English」で進めた方が良いようだ。

(画像は日本語で進めた時のもの)

画像

基本的にはRHEL8/CentOS8そのままの表示である

画像

選択が終わったらインストール開始

Server with GUIでインストールした場合は下記の様になる。

画像

「日本語」を選択した場合、「端末」を選択すると、こんな感じでぐるぐる表示がされるものの端末は開かない。

/var/log/messagesを開くと「failback ‘C’ locale」という表示が出ているので「localectl list-locales」で確認すると、日本語に関するlocaleがインストールされていない。

というわけで、日本語に設定している場合は「dnf install glibc-langpack-ja」で日本語localeを追加するか、「localectl set-locale en_US.utf8」を実行して英語設定にする必要がある。

英語環境であれば下記の様に端末が正常に開く。

日本語localeを追加した場合も正常に端末が開くようになる。

画面を比較してみると、日本語locale追加以前は時刻表記が英語のまま、などの動作していましたね・・・


さて、kernel 4.18.0-305.vl8.x86_64 で起動してきている。

また、2021/06/16時点ではISOは8.3であったものの、updateすると8.4になった。

VzLinux 8のデフォルトレポジトリはこんな感じで、理由がよく分からないが「BaseOS」や「AppStream」などが無効化されており、「VirtuozzoLinux Base」と「VirtuozzoLinux Updates」のみが有効となっている。

ちなみにbaseos,appstream,plus,powertoolsを有効にしてみたが、vzkernelというパッケージは存在しませんでした。

とりあえずは、セキュアブート不要であれば使えるCentOS8代替としては使えそうです。


vzkernelはやはりOpenVZ対応カーネルな模様で https://src.openvz.org/projects/OVZ/repos/vzkernel/browse で開発されていました。(ブランチの選択肢に branch-rh8-4.18.0-240.1.1.vz8.6.x-ovz なんてものが見える。

また、 https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/ で openvz-iso-7.0.16-552.iso という形でOpenVZ用カーネルで起動するRHEL7互換のものが配布されている。

Windows 11 Insider Preview環境でWSLg経由で起動したUbuntu 20.04のfirefoxが日本語文字化けする

$
0
0

Windows 11 Insider Previewにした環境で、WSLgを使ったLinux GUIのテストをしてみようと、Ubuntu 20.04を設定して、firefoxを起動してみた。(別途 sudo apt install firefox でインストール済み)

まぁ、文字化けした。

どうせ、いつもの(Zentyalを日本語で使う場合の設定手順)だろう、と「sudo apt install fonts-arphic-uming fonts-takao-gothic」でフォントをインストールして

firefoxを起動したところ、問題なく表示されました。

富士通のNetApp型番メモ 2021/07/07版

$
0
0

富士通はETERNUS NRシリーズとしてNetApp FASシリーズを取り扱っていた。

2020年に「ETERNUS AX/HXシリーズ」に改名したが、元のNetApp型番と違う番号がついており、よくわからなくなってしまった。

(これまではFAS 2720A→NR F2720という感じで分かりやすかった)

ETERNUS AX/ETERNUS HX series 製品変遷FUJITSU Storage ETERNUS AX series, HX series 製品比較表NetApp Fusionで「New ASA, AFF and FAS Manual Design」で出てくるプロダクトを比較しつつこんな感じかな、というのが下記

正しいかどうかは未確認

ETERNUX AX1100
 拡張Shelf不許可の廉価版AX2100?
 CPU/メモリスペックは2CPU8コア/64GB

ETERNUS AX2100 = AFF A220A? AFF A250A?
 CPU/メモリスペックはAX2100/HX2100/2200で同じ2CPU12コア/64GB
ETERNUS AX2200 = FAS500fA
 NVMe/FCにも対応
 拡張Shelf NS224とあわせてNVMe SSD SED専用
 220V電源専用
 CPU/メモリスペックは2CPU12コア/128GB
ETERNUS AX4100 = AFF A400A
 NVMe/FCにも対応
 CPU/メモリスペックは2CPU10コア/256GB

ETERNUS HX2100 = FAS2720A
 コントローラ内蔵が3.5インチHDD
 CPU/メモリスペックはAX2100/HX2100/2200で同じ2CPU12コア/64GB
ETERNUS HX2200 = FAS2750A
 コントローラ内蔵が2.5インチHDD
 CPU/メモリスペックはAX2100/HX2100/2200で同じ2CPU12コア/64GB
ETERNUS HX6100 = FAS8300A?
 CPU/メモリスペックは2CPU10コア/256GB

vSphere 7.0 Update 1以降 vCLSという仮想マシンが勝手に起動してUPS連動シャットダウンに失敗する

$
0
0

vSphere 7.0 Update 1にアップデートして以降、UPS連動シャットダウンに失敗するようになった。

ログを確認していくと、仮想マシンがシャットダウンできない模様。

しかし、vCenter Serverから確認しても動いている仮想マシンは見えない。

そこでESXi のHost Clientに接続して確認すると、vCLSという作った覚えない仮想マシンが起動している。
そして、vCLSを手動で停止しても勝手に起動してくる。

確認してみると、vSphere 7.0 Update 1以降、vSphere DRS/vSphere HAなどのクラスタについて、起動するまでに時間がかかり重いvCenterサーバ仮想マシンではなく、クラスタの可用性のみを面倒見る仮想マシンとして vSphere Cluster Services を提供するようになったようである。

vSphere 7.0 Update 1 の vSphere Cluster Services (vCLS) (80472)
vSphere 7.0 documentation 「vSphere Cluster Services (vCLS)

これをUPS連動シャットダウンと組み合わせる場合の資料を探したところ、下記があった。

APC「PowerChute Network Shutdown v4.3/v4.4によるvSphere 7.0 Update 1でのvCLSの制御について
DELL「もう迷わない!HCI環境のUPS選定 シャットダウンについて

vSphereのクラスタをのvCLSをRetreatモードに変更することでvCLS仮想マシンが停止/削除することができる、というもの。

PowerShellでvCenterに接続して下記の様なスクリプトを実行して無効化を実行(APCのサンプルスクリプト disable_HA.ps1)

#!/usr/bin/pwsh

$server = "10.179.232.198" #"provide Vcenter server IP/hostname"
$username = "pcnsadmin" #"provide username to access vCenter"
$password = "APCapc@123" #"Provide Password to access vCenter server"
$cluster = "C" #"provide Name of the Cluster where Retreat mode needs to be enabled"

$env:HOME = '/root'
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Connect-VIServer $server -Protocol https -User $username -password $password
$clid = (Get-Cluster $cluster).ID
Write-Host $clid
$myclid = $clid -replace 'ClusterComputeResource-',''
Write-Host $myclid
Get-AdvancedSetting -Entity $server -Name config.vcls.clusters.${myclid}.enabled | Set-AdvancedSetting -Value False -Confirm:$false

##Additional step for VSAN to turn off HA on the cluster
Get-Cluster -Name $cluster | Set-Cluster -HAEnabled:$false -Confirm:$false

Disconnect-VIServer -Force -Confirm:$false

PowerShellでvCenterに接続して下記の様なスクリプトを実行して有効化を実行(APCのサンプルスクリプト enable_HA.ps1)

#!/usr/bin/pwsh

$server = "10.179.232.198" #"provide Vcenter server IP/hostname"
$username = "pcnsadmin" #"provide username to access vCenter"
$password = "APCapc@123" #"Provide Password to access vCenter server"
$cluster = "C" #"provide Name of the Cluster where Retreat mode needs to be disabled"

$env:HOME = '/root'
Connect-VIServer $server -Protocol https -User $username -password $password
$clid = (Get-Cluster $cluster).ID
$myclid = $clid -replace 'ClusterComputeResource-',''
Write-Host $myclid
Get-AdvancedSetting -Entity $server -Name config.vcls.clusters.${myclid}.enabled | Set-AdvancedSetting -Value True  -Confirm:$false

##Additional step for VSAN to turn off HA on the cluster
Get-Cluster -Name $cluster | Set-Cluster -HAEnabled:$true -Confirm:$false

Disconnect-VIServer -Force -Confirm:$false

もう1つはAPCの資料および「PowerChute(TM) Network Shutdown v4.3 for Virtualization 補足説明書 日立編」には設定フローと共に掲載されている手法。

PowerChute Network Shutdownで「VM優先度付け」設定を有効にした上でvCLS仮想マシンを「優先度 高」で設定。vCenterサーバ仮想マシンを「優先度 中」、それ以外を優先度 低などに入れる。

「VMシャットダウン所要時間設定」と「VM起動所要時間設定」で「高」と「中」に対して0秒以上の値を設定

仮想化設定にある”仮想マシンと仮想装置、シャットダウンと起動”設定の「仮想マシンvApp 起動」にチェックを入れる

“ホストメンテナンスモード”の「タイムアウト」を「60秒」に設定

というもの。

綺麗に実行するのであればPowerShellを使った手法のほうが良さそうだ。

RHEL8/Oracle Linux8のmariadbでバイナリログを有効にする方法

$
0
0

RHEL8/Oracle Linux 8のmariadbをバックアップソフトでオンラインバックアップする場合、バイナリログを有効にする必要がある。

MySQL MySQL 5.7 Reference Manual「2.5.10 Managing MySQL Server with systemd
Oracle MySQL 8.0 リファレンスマニュアル「2.5.9 systemd を使用した MySQL Server の管理
RHEL8 さまざまな種類のサーバーのデプロイメント第9章 データベースサーバー「9.2. MariaDB の使用
MariaDB Administration「Starting and Stopping MariaDB » systemd

設定ファイルを書かずに、いまだけバイナリログで有効にして起動させる場合は以下となる。

# systemctl show-environment 
# systemctl set-environment MYSQLD_OPTS="--log-bin"
# systemctl restart mariadb
#

起動時から有効にする手法について確認すると /lib/systemd/system/mariadb@.service に /etc/systemd/system/mariadb@.service.d/MY_SPECIAL.conf に書くという記述があったので設定してみたものの読み込まれる気配がない。

いろいろ試した結果、/etc/systemd/system/mariadb.service.d/ファイル名.conf でファイルを置いた場合に動作するということが分かった。

# vi /etc/systemd/system/mariadb.service.d/override.conf
# cat /etc/systemd/system/mariadb.service.d/override.conf
[Service]
Environment="MYSQLD_OPTS=--log-bin"
# systemctl daemon-reload
# systemctl restart mariadb
#

ファイルを編集したあとは、daemon-reloadを実行する必要があった。

なお、 /etc/default/mysql, /etc/default/mysqld, /etc/sysconfig/mysql にて「MYSQLD_OPTS=”–log-bin”」を設定する、という手法も実験してみたが、これらは動作しなかった。

Viewing all 1106 articles
Browse latest View live