24inchもあってモバイルモニタ?という感想を持たれがちだとは思うが、まあ一応そういう触れ込みのモニタ。

そもそも今のワークスペースにも24inchのモニタは壁付けしておいてあるが、解像度がHDなので、拡張ディスプレイとして繋いでもだいぶ見劣りがするので、早晩もっと解像度の高いモニタが欲しいと思っていた。

現在のモニタにかかわらず、一般に液晶ディスプレイ、液晶テレビというのは本体はそれなりに薄型でも結局据えつけるとスタンドだったり、大袈裟な壁掛け装置だったりして設置してみると壁からはそれなりに距離があるものである。このディスプレイに使っているのは「壁美人」という石膏ボードにステープラーで固定器具を据えつけるものだが、壁に据えつけるプレートは薄型でも、ディスプレイのVESAにつける器具はチルトさせる機能がついていることもあって結構分厚いものである。壁につけた後でも上にダイソーの液晶ディスプレイ上部棚見たいのをおいてスピーカを置けるほどの厚みがある。

そんなわけで、モバイルモニタがいいのではないかと目論みつつあった。この頃のは結構薄くなっており、うまくすれば絵画くらいの厚みで壁につけられるのではないかと思っていた。ただ、一般にモバイルモニタはモバイルというだけあって可搬して使うのが前提になっているので、大型化しつつあるとはいえ、大体15.6inch、17inchくらいあるとおお結構でかいなどという感じだったが、Amazonを見ているとなんと23.8inchで4Kなんてものがあってびっくり。

23.8inch 4Kというのはコロナ禍の時に当時の勤め先から在宅勤務用に借りてきたモニタと同じスペック。もちろんこれは通常の液晶ディスプレイなので、サイズ感はだいぶ違うものの、この時に普通の人はちょっと小さくね？と思うサイズが近眼で老眼で比較的ディスプレイに近づいて見る自分にはちょうどいい大きさだった。その後あまり通常のディスプレイでこのサイズでこの解像度のものはなかったの(4Kだと大体下限は27inch)だが、モバイルディスプレイで出てきてくれたことはありがたい。

AmazonではおそらくOEM元は一箇所だと思うのだが、別ブランド3社から発売されている。最初に見つけたInnoViewのものをしばらくカートに入れておいたのだが、今回はその中の一つUPerfectのものが39999円という価格をつけていたので、買ってしまった。前記の通常ディスプレイ23.8inch 4KはLGのものが一番安くて3.1万円だった頃もあったが、この頃はそういうものもすっかり消えてしまった。それと比べると39999円は安いとはいえないものの、同スペックのものがほぼ消えIT機器も値上がりが激しい今日この頃では結構妥当な方であろう。

UPERFECT 23.8インチ 4K モバイルモニター

実物は期待通り薄くて綺麗に映った。一応MBA本体からUSB-C一本で映るには映るが、やはり電力が足りないせいかバックライトが最低限になって暗い。付属のUSB電源アダプタ利用が必須のようだ。

ただやはり壁に固定する方法が今ひとつ思い浮かばない。ディスプレイにはスタンドにもなるハンドルがついているが、今はそれを上側に畳んだ状態で壁美人のプレートに引っ掛けている。それなりの重量もあるので一見固定はされている様だが、ちょっと大きめの地震があると容易に落ちてしまうことは想像に難くない。なんとかしないと。ただ、やはり自身の重量が3kgあるので百均からホームセンターまでいろんなところを探しているが、それを支えられる器具がなかなかないというのが目下の最大の悩み。

さて最初は十分綺麗な映像に満足はしていたのだが、会社支給macでzoom会議をしていると時々電源が切れたように画面が消えることがあった。不思議なことに自分macで繋いでnetflixで映画などを見ていると切れることはなかったので、amazon経由で版元に問い合わせるとまずはその症状をビデオに撮って送れとか言われた。でもこういうのはいつ起こるかわからんのでその旨を伝えるとでは交換するので現物をこちらに送れと言われた。大抵の中華製機器は現物は送り返さずにすぐ代替品を送ってくるのだが、これだけ高価だとそういうわけにもいかないのだろう。幸いまだ箱はとっておいたのでそれを使って送り返した。

ものが送られてきた時はすでに年末に入っていてあまりzoomを使う機会もなくてすぐには確認できなかったが、使うようになるとやはりブラックアウト現象は観測された。のみならず、背景が真っ白だと第４象限のあたりが少し暗くなるムラが観測された。これは意外と気になるので、やはり不具合ではないかと写真付きでサポートに連絡。今回もビデオに撮って送れとか言われたので撮って送り返す。

新しく来たものは今までと微妙にバージョン(ロット？)が違う感じ。USBC電源も違うし、ケーブルも電源用は少し違うタイプで「電源用」というタグが付いている。本体も見た目はあまりわからないが中は違うのかもしれない。今回は色ムラもほぼなく(全くないかというと全体的にあるような気もするが、24inch 4K mobile monitorというチャレンジングな商品ならこんなもんだろうという許容範囲)現在までブラックアウトは起こっていない。

少し不具合があると報告するとすかさず新品に交換してくれるフットワークの軽さはさすが中国企業という感じはするが、それ以前に出荷時の品質管理をしっかりしてほしいと思ってしまうのもまた事実である。

このblogをホストしているubuntuにloginしたら色々updateが溜まっていたようなので、気楽にupdateしてみた。するとここのwordpressが動かなくなった。どうも無理やりroutedで動かしていたのが動かなくなっていた。

今まではNATをしないためにiptablesをdisableにして、host側にrouting設定を入れておけばcontainerに対してもL3 routingしてくれてたのだが、どう設定してもそれがうまくいかなくなっていた。NATしない時はiptableやめちゃえって書いてあったはずの公式ドキュメントもない。いつの頃からかよく見るとiptablesのchain項目に’DOCKER xxx’というのが増えている。ここに設定している内容はiptables -Fとかでは全部消えないようで、iptables=falseとかしてもうまく動かない。chatgptが

どうやら新たに独自にrouted typeのbridge(network)を作ると、iptables他の設定はいじらずに通常のL3 networkはしてくれるっぽい。ただ、現在動いているコンテナのネットワーク設定は変えられないので、改めてcontainerを作るところから始めなきゃ行けないようだ。

とりあえず現在稼働中のやつのimageをとっておかねばというところで、mysql、wordpressのimageをcommitしておく

$ sudo docker commit momose-wordpress miscmemo-wordpress-latest:20240818
sha256:495adc56fa9dbd1cda8c969f7ab82d6f474d2871698e1d426f99523dd25efa04
$ sudo docker commit wp-mysql mysql:5.7.21-my20240818
sha256:4fb2a23c3b0016c3087e39be1453c01ce81a18df897a517a253d54a7f6f87bca

routedになるnetworkを作る。v6 prefixも指定し、gateway_mode_ipv4をroutedにし enable_ip_masqueradeをfalseにするのがポイント。

$ sudo docker network create --driver bridge --subnet 172.18.0.0/16 --ipv6 --subnet 2001:2c0:cc17:c302::/64  --opt com.docker.network.bridge.gateway_mode_ipv4=routed   --opt com.docker.network.bridge.enable_ip_masquerade=false   routed-net
e8df9d66c9e9b68d22eddd0464451b1e955f14df0d51fc14d24bfee383c1a30b

退避させた(というかcommitした)imageを使ってこのnetwork上にcontainerを作る。前のやつは止めたままにしておく。今までアドレスはhost起動直後に各コンテナを手動で起動させることでIP address固定にするという原始的とも言えないほど原始的なことをしていたが、今回からは専用bridgeを作ってそこでIPアドレスを固定にする。

$ sudo docker run -d --name miscmemo-wp-mysql --network routed-net --ip 172.18.0.2 -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306   mysql:5.7.21-my20240818
3abb3d2c34be91cbf8f0d48bee9491d84117713efaef12b371376e8502c02893
sudo docker run --network routed-net --ip 172.18.0.3 -v /var/www/html/:/var/www/html --name miscmemo-wordpress -d miscmemo-wordpress-latest:20240818
31ee2c1176cc7258b09fdf82b3c61d95e4762b6040c32b62c3c309ff743b4c17

ごちゃごちゃいじりすぎたので、docker本体をrestart。miscmemo-wordpress (wordpress本体; 172.18.0.3からmiscmemo-wp-mysql (wordpress用のmysql; 172.18.0.2)へのpingは通る。が、外(10.0.0.1とか)からは通らない。もちろん10.0.0.1には172.16.0.0/14宛のrouteはこのubuntu本体がnexthopになるようなrouteを設定してある。

これは例によってiptablesの設定が足りていなかろうということで、miscmemo-wordpress tcp:80宛は通るようにしておく。port限定しなくてもip全部通せばいいんじゃないかとも思うが、どうせ80以外は空いていないからとりあえずこれで。

$ sudo iptables -L
[sudo] momose のパスワード: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:mysql
ACCEPT     icmp --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
RETURN     all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
momose@peso:~$ sudo iptables -I DOCKER 1 -d 172.18.0.3 -p tcp --dport 80 -j ACCEPT
momose@peso:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.3           tcp dpt:http
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:mysql
ACCEPT     icmp --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
RETURN     all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         

この状態でもmiscmemo.momose.orgまたは172.18.0.3にwebで繋いでも’Error establishing database connection’になる。DBにloginできないということか?

db containerを作るときは-p 3306:3306してあるので、localhostに繋げばいけるはずだが、やはりいけない(これは謎)ので、172.18.0.2にmysql clientで繋いでみる。

docker runしたときにMYSQL_USERとかMYSQL_PASSWORD設定したせいか、それらのユーザは設定されているが、databaseとしてwordpressは定義されていない。

mysql> select User from mysql.user;
+---------------+
| User          |
+---------------+
| root          |
| wordpress     |
| mysql.session |
| mysql.sys     |
| root          |
+---------------+
5 rows in set (0.01 sec)
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
+--------------------+
2 rows in set (0.00 sec)

結論から言えば、これはvolumeの設定の仕方(-v option)の設定の仕方が悪い。上記例では ‘-v /var/lib/mysql’としてしか設定していないが、これはcontainer内部の/var/lib/mysqlをホスト側の匿名ボリュームを使え、ということしか指定していない。今回は新たに匿名ボリュームを作ってそれを内部で使おうとしているのに過ぎないので、今までのmysqlのデータは見れなくなっている。

今まで使っていたmysqlコンテナはdocker inspectすると

        "Mounts": [
            {
                "Type": "volume",
                "Name": "437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2",
                "Source": "/var/lib/docker/volumes/437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2/_data",
                 "Destination": "/var/lib/mysql",

で、hostの437…というvolumeを使っていたが、新しい方だと

        "Mounts": [
            {
                "Type": "volume",
                "Name": "ffbcf68f7e10fe79b6252f374094d4fd9ed61e0ac884ece61966cbdb7595b7cb",
                "Source": "/var/lib/docker/volumes/ffbcf68f7e10fe79b6252f374094d4fd9ed61e0ac884ece61966cbdb7595b7cb/_data",
                "Destination": "/var/lib/mysql",
 

となっていて、全く別のffbcという匿名ボリュームを指している。なので、旧データが復活できていない。

というわけで、mysqlデータが入っているはずの匿名ボリュームを指してコンテナを作り直す。

$ sudo docker run -d --name miscmemo-wp-mysql --network routed-net --ip 172.18.0.2 -v 437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306   mysql:5.7.21
434a61c30c7b967c440adbd8c3b518825da99e9b1be1b7e7463eb6f867a71c7f

一応これで旧mysqlデータも読み込めて、接続できるようになった。

が、なんかのはずみですぐこのmysqlコンテナが落ちる。通常の閲覧画面は見えるが、admin画面にアクセスしたら落ちる(画面的にはしばらく待たせられる状態になる。その後切れる)、loginしようとしたら落ちる、などなど。

原因はよくわからないので、この際旧データを吸い上げて新しいコンテナを設置の上、そのデータを読み込ませて復旧させることにした。

$ mysqldump -h 127.0.0.1 -u root --ssl-mode=DISABLED -p wordpress > miscmemo-wp.sql
Enter password: 
-- Warning: column statistics not supported by the server.

ここで読み込んだファイルの先頭に、CREATE DATABASE wordpress;USE wordpress;を入れる。

$ mysql -h 172.18.0.2 -P 3306 -u root -p < miscmemo-wp.sql
$ mysql -h 172.18.0.2 -P 3306 -u root -p 
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 19
Server version: 9.4.0 MySQL Community Server - GPL

Copyright (c) 2000, 2025, Oracle and/or its affiliates.

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> show databases
    -> ;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| wordpress          |
+--------------------+
5 rows in set (0.01 sec)

mysql> use wordpress;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-----------------------+
| Tables_in_wordpress   |
+-----------------------+
| wp_aal_products       |
| wp_aal_request_cache  |
| wp_aal_tasks          |
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_pz_linkcard        |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
16 rows in set (0.01 sec)

mysql> ^DBye

rootユーザでセットアップしてしまったためか、wordpress dbにアクセスできるのがwordpressユーザではなくrootユーザになってしまったので、wordpressコンテナの/var/www/wp-config.phpのUSERとPASSWORDをroot用のに変更、起動し直すと今度はうまくいった。adminアクセスとかも問題なさそう。

ただ、adminダッシュボード画面ではwordpress.orgにアクセスできないとか言っている。どうも外にうまく繋がっていないようだ。iptableで外向きもいけるように設定。

$ sudo iptables -I DOCKER 1 -s 172.18.0.3 -p tcp -j ACCEPT

実は外向けルータでnatのルールに172.18.0.3が入っていないことがわかったので、そっちも設定。FreeBSDの/etc/ipnat.rules、172.16.0.0/16だったのを172.16..0.0/14に。今までも172.17.x.xだったからいけなかったはずなんだがいけていたのはちょっと不思議ではある。

map ng0 172.16.0.0/14 -> 0.0.0.0/32 portmap tcp/udp 60000:65000
#map ng0 172.16.0.0/46 -> 0.0.0.0/32 icmpidmap icmp
map ng0 172.16.0.0/14 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map ng0 172.16.0.0/14 -> 0.0.0.0/32
#

これで一通り復活はできた。途中作りまくった匿名ボリュームとか今後使わないだろうimageとかは決しておく。今のところこのエントリをかける程度までは安定して動いている。

iptablesを次のreboot前までには安定させないといけない。

ipv6を復活させよう。

結局ホスト機のマザーとかの不調というよりも、どうもmiscmemo blogを運用していた何でもubuntu VMの一部コンテナであるこのblogのコンテナのどれかが触られると固まるような気がしてきた。他のVM動かしても止まらないし。

そんなこんなでストレージも取り替え、ようやくこのblogをホストしているwordpress containerが復活したのでその顛末。

ESXi機不調

昨年(2024年)末ごろ、ESXi機に不調になり、突然反応がなくなる、突然リブートしてたり(ESXiコントロール画面で見ると、全VMが落ちている)といった事象が頻発していた。

熱暴走かな？と思ってある日本体を開けてみると、CPUファン近辺にホコリがみっしり。辛うじてファンは回っていたもののあまりの驚きに写真を撮るさえ忘れてしまった。これはエアダスターなどを駆使して除去し、一安心。

しかしその後も同じような不具合は頻発する。

• ACアダプタにはおそらく通電時には光るであろうLEDがついているが、全く光っていない。が、通常通り通電はしているように見える。もし不具合があるのだとしたら、出力が足りないのかもしれない
• ハードウェアの不具合だとすると、メモリが壊れている可能性もある。memtest86という世間でよく使われているらしいメモリテストソフトを使ってみた。これは特定のOSの上で動くアプリではなくこれごとbootしてメモリテストだけを行う。64GBに対して8時間ほどかかった。が、特に異常なし。
• 負荷がかかったに落ちるのかと、FreeBSD VMでyesをbackgroundで実行。このHWでこんなにファンが回るのかというくらいまで周り、消費電力も増えていることを確認したが、落ちなかった。

これらをやってもやはり数日で落ちる。

しばらくして分かったことは、しばらく落ちてなくても、どうやらubuntuを立ち上げて、この日記用コンテナをあげると、翌日くらいには落ちてるパターンが多かった、ということだ。

特定のVMがストレージの特定の場所(ここはきっとこの特定のVMに占有されているだろう)にアクセスするとハードウェア的に不安定になって落ちたりリセットがかかるのかもしれない。通常ストレージの一部が読めなくなったとしても、動いているVMにはエラーで読めなかったというステータスが返ってきてそのVMが不安定になるだけだが、今回の場合は何かハードウェア的な秘孔を突いた、ということなのかもしれぬ。

その傍証として、ホストハードウェアの交換も視野に入れてVMのイメージを別の場所にコピーしていた時、他のVMのイメージは時間はかかったとしても比較的リーズナブルな時間でコピーまたは移動は完了するのだが、ubuntu imageだけはなかなか終わらず、最後にはホストのUIも反応しなくなったということがあった。

このホスト機を導入した経緯はESXi機アップデートにあり。

Ununtuの必要データをサルベージ

ubuntuをはじめとするいくつかのVMは本体内のM.2 SSDに入っていたのだが、ubuntu以外は正常に外部のストレージに引越できた。

ubuntuはセッション繋ぎっぱなし用デスクトップとして使ったり、何も入っていないgitlabやkernel build専用のコンテナをホストしたりしていたが、これらはともかく、このブログは個人的に有用かもしれないメモとかあるので、何とかして救いたかった。救うべきものは三つ

• wordpress コンテナ
• wordpressコンテナが永続化ファイルとしてマウントしているwordpress用の各種ファイル
• mysqlコンテナ
• mysqlが持っている永続化されたデータ

コンテナ系はdocker saveで保存。復帰後にdocker loadでイメージを戻す。

永続ファイルとしてあるホストにあるファイルは、wordpressの方は単純にtarで固める。mysqlはデータファイルを復活できるかが自信なかったので、mysql dumpで全データをmysqlのコマンドとして吐き出す。

$ mysqldump -h localhost -u root --ssl-mode=DISABLE -p<password> wordpress > mysql-backup.sql

これらの過程でシステム不安定化させている秘孔をつかないとも限らないが、今回は何とか乗り切ったようだった。

VMホスト機再構築へ

ストレージ調達

とりあえずストレージが怪しいということで、新しいのを調達することとした。今使っているのはCrucialのやつだが、結構安めのものを選んでいた。もしかしてTBWの値も小さかったのかもしれない。

この反省を生かして、もっとよさそうなデータセンタークオリティということになっているWestern DigitalのWD Redにすることとした。(あれ、データセンタークオリティを謳っているのはWD Red Proだったかな)

買ったのはこれ。WDS100T1R0C [WD Red SN700 NVMe SSD（1TB M.2(2280) PCIe Gen3 x4 NVMe 2000TBW 5年保証）] [Amazon]

OS選定とインストール

何とか掬い上げたVM達を何とかそのまま使いたいということで、できればESXiを使いたいところだが、ESXiは去年のbroadcomの方針により無料バージョンがなくなった。

今使っていたESXi7のインストールメディアを探し出してそれを使うかと思っていたがそういえば一時期の不用品大パージのおりに使わないCD-ROMとか纏めて捨てたんだった。せめてイメージだけでも残っていないかとそれっぽいところも探したが、intel NIC対応インストールメディアを作る時の残骸があっただけだった。これでESXiの目はなくなった。Proxmoxにするかなあと思っていたところへESXi8.0u3が派手なアナウンスもなく、さらっと無料化復活へ、という情報が。

これはbroadcomで会員アカウントを作ればあとは無料でDLできるらしい。しかもIntel 226vドライバも対応。早速インストールしてみる。ちゃんとNICも認識した。webのデザインもだいぶフラット化というのかそんな感じだ。外部NASのiscsiも認識した。iscsiまたはNFSに置いたVMもあらかた復活できた。

ただ、今回も突然ホストごと固まるという事象が何回か散見された。ディスプレイが繋がっていないため、固まるとどうにもわからないので、ディスプレイは繋ぎっぱなしにしておく。

何回かはESXiの待機画面のまま固まっていた。後はいわゆるPSOD(Purple Screen Of Damage)の画面。

これをよくみると、PCPU 11: no heartbeatとある。何だかよくわからないが、PCPU(Performance CPU?)11が死んでるということのようにもみえる。もしかしたらC-StateとかでCPUが一旦寝てしまうと起きてこないのかもしれない。

BIOS設定画面でP-StateとかC-Stateっぽい設定があったので、それらをdisableしてみる。ただ同じ筐体のデフォルト設定でESXi7は何年も動いていたのに？

ただ、これらの設定で、とりあえずは今はまだ理不尽なリセットは起きていない。

最悪この理不尽リセットが続くようであれば、機種移行も検討しなければならない。今考えているのがhttps://amzn.to/4dF8tTO 8C16T AMD Ryzen 7 PRO 6850H。amazonでは度々セールをしていて5万円弱。AliExpressだとベアボーンでもっと安く売っている。

ubuntu復活

前述のように他のVMはvmx右クリックですぐ復活できたが、ubuntu imageはサルベージできなかったので、OSインストールからやり直す必要がある。

desktopの設定、dockerのインストールは通常通り。

その先の設定、実はこのblogの最初の記事に書いてあるので、このblogを復活させないと設定方法がわからないという実に缶切りは缶詰の中状態。サルベージしたsqlファイルの中身を見たり、何とか思い出して設定を行なった。

ここのdockerホストはcontainer networkに対してNATではなくL3 networkを提供するようにしているので、このdockerdに対してはiptablesを無効化し、提供するIPv6のprefixを指定する。

ExecStart=/usr/bin/dockerd --iptables=FALSE --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" -H fd://

各コンテナはまずバックアップしたファイルからimageをrestoreする。

sudo docker load < mysql5.7.21.tar.gz
sudo docker load < miscmemo-wordpress-latest.tar.gz

これでimageは入った。

$ sudo docker images
[sudo] momose のパスワード:
REPOSITORY                  TAG       IMAGE ID       CREATED        SIZE
miscmemo-wordpress-latest   latest    40af751e8d84   2 months ago   725MB
hello-world                 latest    74cc54e27dc4   4 months ago   10.1kB
mysql                       5.7.21    5195076672a7   7 years ago    371MB

mysql containerを作成、DBを復旧させる。

sudo docker run -d --name wp-mysql -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306 mysql:5.7.21
mysql -h 127.0.0.1 -P 3306 -u root -p --ssl-mode=DISABLED < miscmemo-wordpress.backup/mysql-backup.sql

WordPressの永続化部分を展開。いろいろわかってなくて変なところに展開する

cd /var/www/html
tar xfz <somewhere>/wordpress-data.tar.gz
cd wp-content/wp-uploads
tar xfz <somewhere>/wordpresss-uploads.tar.gv

しかたないので、そこ(/var/www/html)を永続化のvolumeとしてマウントすることにする。でもその前に、どうやらWordpressに登録してあるDBの接続情報が違っていたようなのでwp_config.php内のdefine( ‘DB_NAME’, ‘wordpress’ ), define( ‘DB_USER’, ‘root’ ), define( ‘DB_PASSWORD’, ‘root’ ); define( ‘DB_HOST’, ‘172.17.0.1’ ); を修正する。

で、wordpress containerを立ち上げる。

sudo docker run -v /var/www/html/:/var/www/html --name momose-wordpress -d miscmemo-wordpress-latest

ここにhttp://172.17.0.3/で繋げられればめでたしめでたし。

今後

• ここらへんのcontainerをdocker compose対応にする
• 定期的に止めて、中の埃を掃除する

最初のmomose.orgブログ開設-とその顛末_エントリにもあるように、 このblogのwordpressは公式のdocker imageを使っている。この公式のimageはphpのsourceをこのコンテナ内にDLしてきてそれをbuildしてインストールするようなことをしているので、コンテナ内でapt upgradeとかするわけにもいかない。したところでいろいろ公式イメージとは齟齬が生じそうだ。

ここはやはりdockerっぽく、imageをアップグレードしてコンテナを作り直すのが正しそうである。

ただ、wordpressは写真などのメディアファイルをアップロードすると、wordpressコンテナ内の/var/www/html/wp-content/uploads以下に置くので、コンテナを移行する前にこれをレスキューする必要がある。また、これらはblogのコンテンツ同様ずっと持っておくものなので、どこかホストのディレクトリにおいておいて、コンテナ起動時に-vでマッピングするのがよさそうである。

まずはメディアファイルディレクトリをレスキュー。momose-wordpressとすべきところがタイプミスで今日までmomose-worpressになっているのはご愛嬌。このおかげで新旧がくべつしやすくなって移行が少しやりやすくなった。次からどうしよう。

(host)$ docker cp momose-worpress:/var/www/html/wp-content/uploads wordpress-content-uploads

最新イメージの取得、旧コンテナの停止、新コンテナの起動

(host)$ docker pull wordpress
(host)$ docker stop momose-worpress
(host)$ sudo docker run --name momose-wordpress --link wp-mysql5:mysql -d -p 8080:80 -v /home/momose/wordpress-content-uploads:/var/www/html/wp-content/uploads wordpress

どうやらwp-config.phpはauthenticateのハッシュ値などが異なるようで、そのままでは使えなさそうな雰囲気。ここはブラウザから新しいコンテナに直接つないで設定し直したほうがよさそう。

あと使っていたプラグイン(Enlighter Inline CodeとPz-Link Card)を追加。こういうのも後で引き継げるような方策を考えたほうがいいかもしれない。

これで一応移行は出来たはず。本当はhttps化とかしておきたいところだが、どうにもうまくいかないので、これはまた後日。(ここに書き足すかもしれない)

追記(2023.06.15): https化成功

Apacheで、miscmemo用のSSL設定を書き、https://miscmemo. …の時は内部ネットワークのwordpressコンテナにreverse proxyするような設定をしていたのだが、今までうまく行っていなかった

• 本文はhttpsで通信しているっぽいが、呼び出している.js, .cssなどがhttpでリンクされているので、昨今のブラウザはそこら辺は読んでくれないっぽい。なので本文は表示されるが、cssとかが読まれないので表示が乱れまくる。
• URLに/loginを追加してログイン後に管理画面に入ろうとしても変なところに繋ごうとしてうまくログイン画面が出てこない
• とりあえずhttpでlogin画面に入り、「設定」→「一般」で”WordPressアドレス(URL)”をhttps://〜に変えて、httpでもhttpsでもloginしようとするとリダイレクトループが発生してにっちもさっちも行かなくなる。
  • この症状が最初に出た時は設定画面に二度と入れなくなるので、mysqlコンテナに入って、直接この設定が入っているレコードを修正。その手順については秘密のノートで。

「wordpress https リダイレクトループ」でググると、以下の設定をwp-config.phpに入れると良いみたいなことが書いてあってほんまかいなと思いながらやってみるとうまく行った。ログインはもちろん、ページ全体のhttps化も。

define('WP_HOME', 'https://miscmemo.momose.org');
define('WP_SITEURL', 'https://miscmemo.momose.org');
$_SERVER['HTTPS'] = 'on';

本ブログ創設以来4年ほど経ってようやく懸案事項解決。か?

追記の追記(2023.06.18)

新container上のwordpressはv6ではlistenしているようだが、sslではlistenしていないので、v6ではsslではつながらないことになる。実際、http://[v6 address]は繋がるが、https://[v6 address]ではつながらない。が、v6共存networkにいても繋がっているのはsafariのhappy eyeballのおかげなんだろうか。

追記の追記の追記(2023.07.03) – IPv6 SSL化の件

前記の通り、当初の「IPv6は直にWordPressコンテナへ、IPv4は仕方がないので入り口でReverse Proxy」というのが、SSL化した場合にうまくいっていない感があったのだが、とりあえずWordPressコンテナもSSL化してみた。

1. Let‘s Encryptでmiscmemo.momose.orgの証明書を取得
   • certbotはmomose.org本体で動かしているので、証明書本体は momose.org:/usr/local/etc/letsencrypt に格納される
2. WordPressコンテナからもこれを参照できるようにする
   • momose.orgからはNFS exportし、Wordpressコンテナはこれをマウントできるようにする。
   • が、これがどうやってもうまくいかない。ただでさえNFSは難しくて俺も苦手だというのを差し置いてもうまくいく気がしない。
   • もう仕方がないので今回は丸ごとletsencryptディレクトリを固めて持ってきた。
3. WordPressコンテナのSSL有効化
   • WordPressコンテナではWeb serverとしてApacheが使われているのだが、configの書き方がいつものFreeBSDでやっているのと相当勝手が違う。いつものserverではhttpd.confはSSLも何も一個のファイルにしてしまって、秘伝のタレ状態になっているのだが、WordpressコンテナのbaseであるDebianでは/etc/apach2/以下に整然と分けられていて、サイトでサポートされているconfigがsite-available/に、有効にされているものがsite-enable/にあって、コマンドで有効無効を切り分けたりする。SSLの場合はsite-available/default-ssl.confなんてものがあるのだが、そんなことは知らんので、default-ssl.confをsite-enable/にコピーしてきてしまった。
4. configの中のSSLCertificateFileは/etc/ssl/certs/ssl-cert-snakeoil.pem、SSLCertificateKeyfileが/etc/ssl/private/ssl-cert-snakeoil.keyを参照しているので、それぞれletsencryptのfullchain.pem, privkey.pemを指すようなシンボリックリンクを作る

あとはWordpressコンテナをrestart。再びコンテナのシェルでapt install iproute2をしてss -aで443をlistenしているかをチェック。

https://miscmemo.momose.org/ にアクセスして、コンテナのss -aでIPv6 SSLのセッションがあったかを確認する。

あとはconfigの設定を綺麗にしたり、ペンディングしているコンテナからFreeBSD NFS serverのマウント、接続した時にIPv6ならkameが踊る(でなくともなんかIPv6で繋がったよマーク)ような仕組みを作り込んでおきたい。

ところがどっこい、Let’s encrypt証明書のアップデートに失敗 (2023.09.09)

miscmemo.momose.orgの証明書がアップデートできないよ、あと一週間で切れちゃうよ、という警告メールが来た。certbotによる証明書の更新は、そのドメイン直下の.well-known/acme-challengeディレクトリにサインされたファイル名をtouchしておいて、Let’s encryptからそこのURL(この場合はhttps://miscmemo.momose.org/.well-known/acme-challenge/<signed file name>)にアクセスすることで確認するのだが、これはcertbotからfilesystem的に見えるところにないといけない。

今回https://miscmemo.momose.org/に来るときに、IPv6でまず来てしまうので、Containerの方に行ってしまうが、そこのDocumentRootのディレクトリはこのcertbotからは見えないので、結局認証に失敗してしまう。

なんとかアクセスをIPv4に強制できれば、momose.org内で完結するのだが、その方法はどうやらない。ので、一時的にDNS serverからmiscmemo.momose.orgのIPv6アドレスを外す。

momoseorg.dbの$TTLとSOAのMinimumと念のためにRefreshをそれぞれ3600から360(6分)にしてnamed再起動。1時間経った頃にmiscmemo.momose.orgからAAAAを外し、named再起動。6分後にcertbot renew。成功したら各パラメータを元に戻し、/usr/local/etc/letsencryptをtar.gzし、Dockerホストにscp、DockerホストからWordpress Containerの/tmpにdocker cp。/tmp/letsencrypt.tar.gzを/etcに展開、コンテナ再起動。古い/etc/letsencryptは消す。

これを3ヶ月ごとにやらなければいけないというのはなかなか辛い。

更に追記(2023.07.05) – 接続時にIPv4かIPv6かを表示

「ダッシュボード」→「外観」→「テーマファイルエディター」のfunctions.phpに以下を追加。add_shortcode()しておくと後で本文中で’[v4orv6]‘とか書いておくと、IPv4かIPv6かが表示できる。が、本文でそんなことする使いでがあるかどうかはわからない。

function v4orv6() {
  $ip = $_SERVER['REMOTE_ADDR'];
  if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
      // IPv4
      return "IPv4[" . $ip . "]";
  } else {
      // IPv6
      return "IPv6[" . $ip . "]";
  }
}
add_shortcode('v4orv6', 'v4orv6');

template-parts → header → site-branding.php で、

			$description = get_bloginfo( 'description', 'display' );

を

			$description = get_bloginfo( 'description', 'display' ) . ' ' . v4orv6();

に変更。

これでblogのキャッチフレーズ欄のところにv4 or v6、および接続元アドレスが表示される。イマイチ格好はよくない。

こんなにテーマファイル弄り回ったら次バージョンアップがしにくいんじゃないか。

以前よりワークスペースで使っていたPoEパススルースイッチUbiquitiのSwitch-8が通電しなくなる、という問題が起きて以来、ワークスペースでは有線の接続性がなくなっており、代替機を長いことを探していた。

爾来数ヶ月、ようやく要求を満たすスイッチNetgearのGS105PEを導入することができた。

このワークスペースには根元のPoE++ PSEに繋がったEtherの口はひとつしかなく、かつPoEで動かすための我が家の2nd WiFi APがそばにあるために、他の機器への有線接続を提供するスイッチにはPoEパススルーが必須となる。(このスイッチにローカルで電源供給すれば？というのはまあそうなんだけど、折角根本からPoE++が来ているからそれを生かしたいというか)

今まではUbiquiti(というかUniFiというブランド名?)のSwitch-8というやや設定UIには癖があるスイッチをまだ日本で売ってない頃にUS Amazonで買って使っていたが、これが突然通電しなくなる(しかもここに繋いで使っていたはずのMacは勝手に無線にフォールバックしていたため通電しなくなっていたことにしばらく気づかなかった)という故障が発生した。

突然通電しなくなったというより、根元のswitchのログを見るとこのスイッチがつながっていたポートのステータスのログは上がったり落ちたりというのを繰り返していたようだったので、調子が悪いことに変わりはないようだった。そういえば突然VPNが切れる、という事象も起きていたような気はする。

しばらくはWiFi APには壁のEther口から直接繋いでWifiの運用には支障はないものの、やはりWiFiにPoE提供しつつACコンセントは塞がずに手元に有線接続環境を用意したい、あわよくばもう一ポートくらいPoE口を出してPoEサポートのRaspberry Piも時々運用したい、ということで新たなスイッチを探していた。

ところがきょうびPoEパススルーをサポートしたスイッチというのはググっても、このUnifi Switch-8とNetgear GS105PEしか出てこない。びっくり。しかもUnifiの方はメーカーの製品一覧にも一応あるものの、いつでもどこでも在庫なし、となっていてほぼディスコン状態。

一方のGS105PEは探し始めた当初はAmazonで売っていたもののタイミングを逸して買わずにいたら一度品切れになった後はどこでも見当たらなくなった。これが昨今の半導体不足の影響かどうかはよくわからない。以来適正価格で探しまくっていたのだが、ようやくこの度アマゾンのマーケットプレイスに妥協できる価格で現れたのでようやく買えた。

セットアップそのものはそれほど難しくはないはず。自宅ネットワークの都合上、壁EtherからのリンクとWifi APへはいくつかのVLANをtrunkポートに設定すればいいのだが、このスイッチではマネージメント用のIPアドレスのVLANを設定する項目がない。このためにマネージメントIPアドレスをDHCPのままにしておくと各VlanごとにDHCPのrequestを出してしまって、うちの場合は一つのサーバーで全vlanのDHCP serverになっているために、同一MACから複数のDHCP requestが来てしまっているからかそれらが拒否されて結局アドレスがアサインされないという問題が発生してしまった。この時は結局工場出荷設定に戻して先にアドレスを固定してからVLANを設定し直すということになった。

さて、PoEパススルーしてWifi APに電源供給しつつ有線WifiもMacで使えるようになった。が、いくつかの問題も。

SNMPがサポートされていない。

Netgear的分類ではこれは「アンマネージドスイッチ」なのでSNMPはサポートしないという仕様らしい。

PoEのステータスもよくわからん

今PSEとして各ポートにどれくらい給電しているのかという情報が全く把握できない。

実はRaspberry PIと併用できない!

Port1でWifi APが動いている状態でさらにPort2にPoE対応のRaspberry PI4を繋いでも無反応。WifiAPを切ってから先にRaspberry PIを繋ぐと起動。その後にWifi APを繋ぐとこちらも起動。Raspberry PIのPoEは起動時に最大限のPoEバジェットを要求するのかもしれない。

今まで、自宅ではCiscoのWAP-150というのを使っていた。Wifi的には802.11ac対応だが、vlanを食ってそれぞれに別SSIDをつけられたので結構気には入っていた。

が、導入してあまり年月は経たなないのに、もういろいろ古さが目立ってきたので、遂にアップデートと相成った。

WAP-150の問題点

• WPA2までしかサポートされていないので、iOS14以降で繋ぐと「安全性の低いネットワーク」と表示されてしまう
• webの制御画面、遅い。
• まれに不安定。特に2.4GHzの通信が止まってしまうことがある。

特に一番目のは我が家のユーザーたちにも不安を与えてしまうので、機材を交換することにした。

New Wifi APの条件

• Wifi6対応
• WPA3以上対応
• PoEで動くこと
• 壁掛けできること
• 将来に備えて2.5Gbps以上で繋がること
• vlan毎に別SSIDが付けられること

Wifi6対応は特にルータ機能があるものだと結構あるし、PoEサポートもそれなりにある。が、VLAN対応で複数SSIDということになると、途端に家庭用ではなく商店/小規模オフィス用途ということになってしまう。

結局買ったのは、NetgearのWAX218ってやつ

この頃のNetgearの機器にはInsightとかいうサブスクベースのクラウドマネージメント機構があるが、たかだかマネジメントに月々課金はできないので、普通にローカルなIPアドレスで設定。

初期設定時には、設定用のSSIDがあるので、それ経由でアクセスする。設定後このSSIDは一定時間経過後に見えなくなるようだ。まあそれすらも必要ないので、マネジメント用の固定IPアドレス設定後はそちらを使う。が、その固定IPアドレスにlogical nameをDNSで設定して、そのFQDNでアクセスすると、insight用(?)のNetgearのサイトに飛ばされるので、ホスト名ではアクセスできない。IPアドレス直打ちならOKなのでしばらくはIPアドレス直打ちで設定することとする。

あと買ってから気づいた点

• 仕様的には一応電源供給はPoE+(IEEE802.11at)以上となっているようだが、PoE(IEEE802.af)でも問題なく使用できた。PSE側switchのステータスを見ても10Wも使っていないように見えるが。
• 確かに複数SSIDの設定はできるが、実は4つまで。先代のCisco WAP150だと2.5GHzと5GHzでそれぞれ4つづつとなっていたが、今回のは周波数関係なく4つ。生活に必要なのを割り当てていったらもうキャパオーバー。これは今回の最大の誤算。

一応懸案のWPA3/Wifi6は対応できたので、この件は一応close

この度ようやく新しいハードウェアを調達し、どうにか無事復旧できたので、その顛末を記録として残しておく。

今回調達したハードウェアは以下の通り。メーカーから発表直後に今買えば一万円引き、ということでamazonで予約

スペック

• ベアボーン: MinisForum HX90 (AMD Ryzen 5900 8core/16thread) 2.5Gbps(intel 225-V)
• memory: 64GB memory (32GB DDR4-3200 x 2)
• Storage: 1TB NVMe Crucial

会社で開発に使っているサーバーより性能がいいかもしれない。

問題は、このハードウェアで使われているNICのチップ、intel 225-VがESXiの正式サポートでないこと。なので、自分でカスタマイズインストーラを作らなければならない。

ESXiのカスタマイズインストーラを作るためには、PowerShell上でVMWareの用意した各種ユーティリティコマンドを使ってオフィシャルなインストーラからサードパーティ(あるいはコミュニティ)で用意されたドライバを組み込んで作成するが、これは相当大変なので、ESXi-Customizer-PSというものを使う。

まずドライバは以下のところから落とす。確かにI225-Vが入っている。

flings.vmware.com

https://flings.vmware.com/community-networking-driver-for-esxi#requirements

https://flings.vmware.com/community-networking-driver-for-esxi#requirements

続いてESXi-Customizer-PS

www.v-front.de

ESXi-Customizer-PS

https://www.v-front.de/p/esxi-customizer-ps.html

Taking Server virtualization down from the clouds to real life experience ...

まず現時点(2021/12)でこのページからリンクされているESX-Customizer-PSは6.xまで。7.0はさらにここから貼られた先のGithubからDLしてこなければならなかった。

が、結局これでは途中エラーが発生してうまくいかず。

結局、

vhoge.hateblo.jp

https://vhoge.hateblo.jp/entry/2019/03/17/013008

https://vhoge.hateblo.jp/entry/2019/03/17/013008

ここのサイトの通りにWindows上で実行して、ようやくインストールiso完成。ここは一つ一つstep by stepで説明してくれるので、一箇所ベースプロファイルを配列で指定するときの添字がPowerShellでは0オリジンか1オリジンかがよくわからずに別途ググった(ちなみにPowerShellのarrayは0オリジン)こと以外は、ほぼここの指示通りでうまくいった。

完成した.isoはそのままCD-ROMに焼いて、HX90でブートさせると、通常ネットワークデバイスが見つからないと途中で停止するが、特に止まることもなく順調にディスクのパーティション設定まで行き、インストール完了。

もともとESXi機を繋いでいたswitchのポートはトランク設定してあるので、そのままでは通常のネットワークには繋がらないが、ESXiのネットワーク設定画面でVLANを指定することで、特に問題なくネットワークにもつながる。

これでwebの管理画面にも入れることを確認し、今までのストレージに使っていたNASのiSCSIのクライアント設定すると、以前使っていたVMも見える。

ちなみにiSCSIの設定は、

• 「ストレージ」から「アダプタ」「ソフトウェアSCSI」
• 「動的ターゲット」でNASのIPアドレスを設定
• 「固定ターゲット」にNASのiSCSIが現れる

で設定できるはず。

認識されたデータストアから、以前のVMの.vmxを登録。これでVMは復旧。

現住所に入居以来100Mbpsのフレッツ光マンションタイプとかいうのを使っていて、特にアップグレードしなかった理由はなかったんだが、どうもフレッツは色々な諸々の手続きをすぐ電話に誘導するところがあり電話するのが面倒くさいというのがあって、しかもいまひとつそのコールセンターとは話が通じないところがある、と言う偏見もあってそのままになっていた。

あとは下手にアップグレードして問題が起きたときにトラブルシューティングするのが面倒くせえなとか、フレッツはNGNの網終端装置が混みすぎていて、アップグレードしてもそれほど速くならんだろう、という期待のなさとかもあり、そもそも別に今遅くて困っているわけでもない、というのも何もしなかった理由であると言える。まあ実はこれらの懸念は当たらず共遠からずといった感じだったんだが。

9/5 申し込み

申し込み自体はwebから。

程なくして、NTT東から電話がかかってくる。何としても電話で話さなければならないらしい。申し込み内容(変更コース、開通日時)の確認の他、ひかり電話にするかとか二年割りを申し込むかとか。二年割りにすると中途解約時にはペナルティがかかるが月々-200円になるらしい．ギガライン化で+200円なので、都合+100円。

工事日を確認。特に誰もこないそうな。かと言って何をしろと言う指示は特になかった。

会話中にONUを小型ONUにしたいと言ったら、イマイチ通じない。しばらくお待ちくださいと言った後に言われたことによると、ギガラインじゃなくてギガスマートにしなければならない、その上でHome Gatewayを置き換えるイメージ、と言われた。全く意味不明だが、そう言うことなら今回はいい、と引き下がったのだが、後でwebを色々見てみるとギガスマートにしなければならないと言うことは全くないらしい。コールセンターは話が通じねえだろうと言う懸念は早速当たった。

もっとも同時に二つのもの(ギガライン化とONU置き換え)を同時にするとトラシュー時に困るなとも思い直したので、小型ONU化はまた後日ということにしよう。

9/12 開通当日

さて開通当日、夜中の0時を回った1時ごろ、ONUと繋がっているスイッチのポートを見てみても、インジケータは100Mbpsを示すオレンジのまま。抜いたり挿したりしても変わらない。多分日が変わったくらいじゃアップグレードはされないんだろうと言うことで寝る。

翌朝９時ごろ、スイッチのポートのインジケータを見ると1Gbpsを示す緑色になってる。これはpppセッションを張り直さなければいけないか、と思ったがふとログを見ると、朝方の5時過ぎに一度リンクが落ちて15分後に再接続した跡があった。

↓切れた時のログ

Sep 12 05:06:09 doller mpd: [L1v6] PPPoE: connection closed
Sep 12 05:06:09 doller mpd: [L1v6] Link: DOWN event
Sep 12 05:06:09 doller mpd: [L1v6] LCP: Down event
Sep 12 05:06:09 doller mpd: [L1v6] LCP: state change Opened --> Starting
Sep 12 05:06:09 doller mpd: [L1v6] Link: Leave bundle "B1v6"
Sep 12 05:06:09 doller mpd: [B1v6] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: Close event
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: state change Opened --> Closing
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: SendTerminateReq #4
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: LayerDown
Sep 12 05:06:09 doller mpd: [B1v6] IFACE: Down event
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: Down event
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: LayerFinish
Sep 12 05:06:09 doller mpd: [B1v6] Bundle: No NCPs left. Closing links...
Sep 12 05:06:09 doller mpd: [B1v6] IPV6CP: state change Closing --> Initial
Sep 12 05:06:09 doller mpd: [L1v6] LCP: LayerDown
Sep 12 05:06:09 doller mpd: [L1v6] Link: reconnection attempt 1 in 2 seconds
Sep 12 05:06:09 doller mpd: [L1] PPPoE: connection closed
Sep 12 05:06:09 doller mpd: [L1] Link: DOWN event
Sep 12 05:06:09 doller mpd: [L1] LCP: Down event
Sep 12 05:06:09 doller mpd: [L1] LCP: state change Opened --> Starting
Sep 12 05:06:09 doller mpd: [L1] Link: Leave bundle "B1"
Sep 12 05:06:09 doller mpd: [B1] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Sep 12 05:06:09 doller mpd: [B1] IPCP: Close event
Sep 12 05:06:09 doller mpd: [B1] IPCP: state change Opened --> Closing
Sep 12 05:06:09 doller mpd: [B1] IPCP: SendTerminateReq #8
Sep 12 05:06:09 doller mpd: [B1] IPCP: LayerDown
Sep 12 05:06:09 doller mpd: [B1] IFACE: Down event
Sep 12 05:06:09 doller mpd: [B1] IPCP: Down event
Sep 12 05:06:09 doller mpd: [B1] IPCP: LayerFinish
Sep 12 05:06:09 doller mpd: [B1] Bundle: No NCPs left. Closing links...
Sep 12 05:06:09 doller mpd: [B1] IPCP: state change Closing --> Initial
Sep 12 05:06:09 doller mpd: [L1] LCP: LayerDown
Sep 12 05:06:09 doller mpd: [L1] Link: reconnection attempt 1 in 1 seconds
Sep 12 05:06:09 doller named[935]: no longer listening on 219.117.212.46#53

IPv6が再接続した時のログ

Sep 12 05:21:12 doller mpd: [L1v6] PPPoE: connection successful
Sep 12 05:21:12 doller mpd: [L1v6] Link: UP event
Sep 12 05:21:12 doller mpd: [L1v6] LCP: Up event
Sep 12 05:21:12 doller mpd: [L1v6] LCP: state change Starting --> Req-Sent
Sep 12 05:21:12 doller mpd: [L1v6] LCP: SendConfigReq #5
Sep 12 05:21:12 doller mpd: [L1v6]   PROTOCOMP
Sep 12 05:21:12 doller mpd: [L1v6]   MRU 1492
Sep 12 05:21:12 doller mpd: [L1v6]   MAGICNUM 0x981f8d2c
Sep 12 05:21:12 doller mpd: [L1v6] LCP: rec'd Configure Request #1 (Req-Sent)
Sep 12 05:21:12 doller mpd: [L1v6]   MRU 1454
Sep 12 05:21:12 doller mpd: [L1v6]   AUTHPROTO CHAP MD5
Sep 12 05:21:12 doller mpd: [L1v6]   MAGICNUM 0x39083fa3
Sep 12 05:21:12 doller mpd: [L1v6] LCP: SendConfigAck #1
Sep 12 05:21:12 doller mpd: [L1v6]   MRU 1454
Sep 12 05:21:12 doller mpd: [L1v6]   AUTHPROTO CHAP MD5
Sep 12 05:21:12 doller mpd: [L1v6]   MAGICNUM 0x39083fa3
Sep 12 05:21:12 doller mpd: [L1v6] LCP: state change Req-Sent --> Ack-Sent
Sep 12 05:21:12 doller mpd: [L1v6] LCP: rec'd Configure Ack #5 (Ack-Sent)
Sep 12 05:21:12 doller mpd: [L1v6]   PROTOCOMP
Sep 12 05:21:12 doller mpd: [L1v6]   MRU 1492
Sep 12 05:21:12 doller mpd: [L1v6]   MAGICNUM 0x981f8d2c
Sep 12 05:21:12 doller mpd: [L1v6] LCP: state change Ack-Sent --> Opened
Sep 12 05:21:12 doller mpd: [L1v6] LCP: auth: peer wants CHAP, I want nothing
Sep 12 05:21:12 doller mpd: [L1v6] LCP: LayerUp
Sep 12 05:21:12 doller mpd: [L1v6] CHAP: rec'd CHALLENGE #1 len: 41
Sep 12 05:21:12 doller mpd: [L1v6]   Name: "xxxxxxxxxx-xxxxxxxxx"
Sep 12 05:21:12 doller mpd: [L1v6] CHAP: Using authname "zb037293@e6.il24.net"
Sep 12 05:21:12 doller mpd: [L1v6] CHAP: sending RESPONSE #1 len: 41

IPv4が再接続した時のログ。4秒差だが何故かv4の方が後。

Sep 12 05:21:16 doller mpd: [L1] Link: reconnection attempt 80
Sep 12 05:21:16 doller mpd: [L1] PPPoE: Connecting to 'whatsever'
Sep 12 05:21:16 doller mpd: PPPoE: rec'd ACNAME "xxxxxxxx-xxxxxxxx"
Sep 12 05:21:16 doller mpd: [L1] PPPoE: connection successful
Sep 12 05:21:16 doller mpd: [L1] Link: UP event
Sep 12 05:21:16 doller mpd: [L1] LCP: Up event
Sep 12 05:21:16 doller mpd: [L1] LCP: state change Starting --> Req-Sent
Sep 12 05:21:16 doller mpd: [L1] LCP: SendConfigReq #5
Sep 12 05:21:16 doller mpd: [L1]   PROTOCOMP
Sep 12 05:21:16 doller mpd: [L1]   MRU 1454
Sep 12 05:21:16 doller mpd: [L1]   MAGICNUM 0x983b6de4
Sep 12 05:21:16 doller mpd: [L1] LCP: rec'd Configure Request #1 (Req-Sent)
Sep 12 05:21:16 doller mpd: [L1]   MRU 1454
Sep 12 05:21:16 doller mpd: [L1]   AUTHPROTO CHAP MD5
Sep 12 05:21:16 doller mpd: [L1]   MAGICNUM 0x39084fb2
Sep 12 05:21:16 doller mpd: [L1] LCP: SendConfigAck #1
Sep 12 05:21:16 doller mpd: [L1]   MRU 1454
Sep 12 05:21:16 doller mpd: [L1]   AUTHPROTO CHAP MD5
Sep 12 05:21:16 doller mpd: [L1]   MAGICNUM 0x39084fb2
Sep 12 05:21:16 doller mpd: [L1] LCP: state change Req-Sent --> Ack-Sent
Sep 12 05:21:16 doller mpd: [L1] LCP: rec'd Configure Ack #5 (Ack-Sent)
Sep 12 05:21:16 doller mpd: [L1]   PROTOCOMP
Sep 12 05:21:16 doller mpd: [L1]   MRU 1454
Sep 12 05:21:16 doller mpd: [L1]   MAGICNUM 0x983b6de4
Sep 12 05:21:16 doller mpd: [L1] LCP: state change Ack-Sent --> Opened
Sep 12 05:21:16 doller mpd: [L1] LCP: auth: peer wants CHAP, I want nothing
Sep 12 05:21:16 doller mpd: [L1] LCP: LayerUp
Sep 12 05:21:16 doller mpd: [L1] CHAP: rec'd CHALLENGE #1 len: 41
Sep 12 05:21:16 doller mpd: [L1]   Name: "xxxxxxxx-xxxxxxxx"
Sep 12 05:21:16 doller mpd: [L1] CHAP: Using authname "zb037293@rb.il24.net"
Sep 12 05:21:16 doller mpd: [L1] CHAP: sending RESPONSE #1 len: 41
Sep 12 05:21:16 doller mpd: [L1] CHAP: rec'd SUCCESS #1 len: 4
Sep 12 05:21:16 doller mpd: [L1] LCP: authorization successful
Sep 12 05:21:16 doller mpd: [L1] Link: Matched action 'bundle "B1" ""'
Sep 12 05:21:16 doller mpd: [L1] Link: Join bundle "B1"
Sep 12 05:21:16 doller mpd: [B1] Bundle: Status update: up 1 link, total bandwidth 64000 bps
Sep 12 05:21:16 doller mpd: [B1] IPCP: Open event
Sep 12 05:21:16 doller mpd: [B1] IPCP: state change Initial --> Starting
Sep 12 05:21:16 doller mpd: [B1] IPCP: LayerStart
Sep 12 05:21:16 doller mpd: [B1] IPCP: Up event
Sep 12 05:21:16 doller mpd: [B1] IPCP: state change Starting --> Req-Sent
Sep 12 05:21:16 doller mpd: [B1] IPCP: SendConfigReq #9
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 0.0.0.0
Sep 12 05:21:16 doller mpd: [B1]   COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Sep 12 05:21:16 doller mpd: [B1] IPCP: rec'd Configure Request #1 (Req-Sent)
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 210.153.255.81
Sep 12 05:21:16 doller mpd: [B1]     210.153.255.81 is OK
Sep 12 05:21:16 doller mpd: [B1] IPCP: SendConfigAck #1
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 210.153.255.81
Sep 12 05:21:16 doller mpd: [B1] IPCP: state change Req-Sent --> Ack-Sent
Sep 12 05:21:16 doller mpd: [B1] IPCP: rec'd Configure Reject #9 (Ack-Sent)
Sep 12 05:21:16 doller mpd: [B1]   COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Sep 12 05:21:16 doller mpd: [B1] IPCP: SendConfigReq #10
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 0.0.0.0
Sep 12 05:21:16 doller mpd: [B1] IPCP: rec'd Configure Nak #10 (Ack-Sent)
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 219.117.212.46
Sep 12 05:21:16 doller mpd: [B1]     219.117.212.46 is OK
Sep 12 05:21:16 doller mpd: [B1] IPCP: SendConfigReq #11
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 219.117.212.46
Sep 12 05:21:16 doller mpd: [B1] IPCP: rec'd Configure Ack #11 (Ack-Sent)
Sep 12 05:21:16 doller mpd: [B1]   IPADDR 219.117.212.46
Sep 12 05:21:16 doller mpd: [B1] IPCP: state change Ack-Sent --> Opened
Sep 12 05:21:16 doller mpd: [B1] IPCP: LayerUp
Sep 12 05:21:16 doller mpd: [B1]   219.117.212.46 -> 210.153.255.81
Sep 12 05:21:16 doller mpd: [B1] IFACE: Up event

と言うわけで、起きてきたら自動的にGbpsでつながっていたと言う結論だったが、はてどれくらい速くなったんだろうとfast.comでスピードテストしてみる。

ギガ化した割には実に寂しい値しか出ていないが、少なくとも100Mbpsは超えているのでまあ確かにギガ化(非100M化と言うべきか)はしているのだろうとは思う。

自宅内ネットワークの貧弱さ、すなわち壁の中のEthernet Cableが多分Cat5とか、そもそもルータがただのFreeBSDとか、Wifi APから外に行くまでにCat5かもしれないケーブルを一往復半しなければいけないとか色々要因はあるんだろうが、それでもアップロードは430Mbps出ているのだとするとNGNの網終端装置あたりが大きなボトルネックになっているんだろうなぁああと言う気もする。

実感としてもあまり速くなった感じはしない。家族に聞いても、言われてみれば速くなったのかな、と言うレベルのようだ。

別にギガ化なんてする必要はなかったんだ…。サーバーを公開していて、多くの写真ビデオをホストしているので、それらを見ている方向けには少し良かったのかもと思うことにしよう。