11月 042023
 

ずいぶんと久しぶりに iPhone を買い替えました。 そもそも iPhone は高いモノなので、ここのところ何回か Android 端末を購入していたのですが、今まで利用していた iPhone8 はいよいよ最新の iOSが動作しなくなる。とのことなので一番新しい iPhone15 を購入することにした。

ちなみに iPhone8 を購入したのは 2017 年 10 月とかになってます。途中、二年ほど使用したあと、一回リコールで本体を交換しています。その後更にバッテリー交換を一回。いやぁ。ずいぶんと iPhone8 を使い続けたものでした;-)。

 
今回は iPhone15 を購入しました。一番安い端末ですが、以下の点が購入の決め手でした。

  • 価格が安い
  • ダイナミックアイランド搭載
  • USB-C が利用可
  • そもそも iPhone8 は iOS17 に対応していない
  • iPhone8 のバッテリがだいぶヘタってきた

まぁ、フツーに誰もが新しい iPhone に買い換える要因と言えるでしょうか・・。あ。写真は macOS を介した iPhone8 のデータ移行中。

購入履歴的エントリな意味合いが濃いのでネタに特化した記事内容などは特にないです。と、いうか、iPhone とか iOS についてはそこいら中にネタがゴマンとあるのであえて書かなくても良いかぁ。みたいな雰囲気;-)。
カメラがどうとか、ロック解除とかとかいまさら書くことも無いでしょみたいな。

 
あ。チタンのこと、書いておきましょうか。実は、僕はもうかなり前からチタン信者で、 iPhone15 Pro で『チタンボディ』と言われて「あぁ。なるほどねぇ♪」的な状態です。無理して iPhone にチタン無くとも・・。みたいな、半分負け惜しみ的な・・。;-P。

まず、腕時計。左側がステンレス、右側がチタン。いやぁ。二つを比べるともう、持った段階で全然違う。

実は、右側のシチズンの腕時計はもう 10 年くらい前に買っているんだけど、購入時に同じモデルでもステンレス製とチタン製の両方があって・・。チタン製を持った瞬間「あ。こっちください。」となりました。それくらい軽さにインパクトがあった。

 
もう一個チタンで一式揃えているのはキャンプ道具。コッヘル・マグ・スプーン・フォークはチタンは当たり前で、ペグまでチタンで揃えています。これはザック背負って山行きの時などは本領発揮する(のではないか)と、思っています;-)。

と、いうことで、別なところで軽さが必要な部分にはもう、チタンを導入しているので iPhone には無理にチタンは必要ねぇだろう。と、いうのが今回頭のスミのほうにありました;-)。

 
さてと。ネタ的に、もうひとつ書くとしたら USB-C でしょうか。

まず、iPhone15 の USB-C は USB2.0 の速度と、言われています。まぁ、写真や楽曲の転送くらいなので USB3.0 の転送速度でなくとも良い感じ。

充電速度は速くないかなぁ。どちらかというと遅い感じ。これは接続している USB ポート側の電力供給力の問題でもあるのかもしれない。

 
ただ、USB-C は偉大です。

実はテレワークのために会社支給の NotePC を自宅で使うために USB-C の HUB を購入しました。

この USB-C な HUB は USB ポートにキーボードとマウスを接続し HDMI も接続して、画面転送できるというしろモノ。写真的にはこんな感じ。あ。USB-C なので、当然電源供給もできています。

もともと NotePC の USB-C ポートに接続するために購入して、テレワークのために利用するのでケーブル類はずっと付けっぱなし。これを iPhone15 に接続したところ・・。

おやおや。iPhone の画面が HDMI で接続したディスプレーに表示されました。 iPhone15 を横にして U-NEXT アプリでアニメを鑑賞してみるとディスプレーにはフル画面で、横表示で再生してくれます。すげっ。

これについては Android 端末も脱帽でしょう。ただ、僕が普段、エントリーレベルの Android 端末を利用しているために『default で画面を HDMI 表示』してくれるモノを購入していないののかもしれないですが・・。

画面の他にキーボードはフツーに文字入力できます。マウスもフツーに使えてクリックしてアプリが起動します。

USB-C な iPad 持ってないんだけど、それと似たような感じなのかな? USB-C はやっぱり良いっ!! てのは確認できました。いやぁ。 iPhone15 が出るまで待って(と、いうか USB-C 対応の iPhone が出るまで待って)いて良かった。

 
しかし、iPhone15 の画面をディスプレーに映す機会がどれだけあるのか微妙です。例えば U-NEXT は PC でも閲覧可能なので無理して iPhone15 の画面を HDMI 接続してディスプレーで見る必要ないし・・。既に mac mimi 持っているので iPhone15 にキーボードやマウス付ける必要ないし・・。

あ、そー言えば、 mac mini から外部カメラとして利用でけた。この機能も iPhone8 には無かった機能だ;-)。

 
とまぁ、こんな感じで普段使いで既に利用している感じ。今回は Apple ストアで購入しました。今まで利用していた iPhone8 は 9,000yen で Apple に引き取ってもらいました。
iPhone15 は 9 月中頃に注文して、届いたのが 10 月 03 日でした。約一ヶ月ほど使い込んでのエントリ記載。と、いう感じです。

 
最後にですが、 iPhone8 から iPhon15 にしたら『ギガ』の減り方が早いですな。まぁ、iPhone15 が目新しくて使い続けてしまった。と、いうのもあるかもしれませんが、 5G に接続するようになったから。と、いうのも起因しているかもしれません。 Y!mobile の 3 ギガのプランでは『ギガ』が足りないかも・・。

5 ギガプランを契約している IIJmio や、ギガ活でほぼ無料で利用している povo2.0 にオフロードしないとやっていけない雰囲気・・。

上手に SIM を使うようにして行こう。と、思う今日この頃。

9月 282023
 

いやぁ。まいった。 FreeBSD 14-RELEASE/amd64 になったら if_iwlwifi.ko が正常動作するようになって FreeBSD でいよいよ待ちに待った WiFi6 が利用できるようになるのかと思いきや・・。
ぜーんぜんそんなことはなくて FreeBSD 14.0-BETA3 で bhyve から Intel AX200 を試してみたけど、やっぱり 802.11a 止まりですな。 802.11ac さえも相変わらず利用できない。一体いつまで待てば FreeBSD で高速な WiFi が利用できることになるのやら・・。

ちなみに FreeBSD 13.2-RELEASE/amd64 では一応 if_iwlwifi.ko は 802.11a では利用可能になりました。しかし、これが suspend/resume に対応していない。 resume すると利用不可になるデバイスなのでまるで利用する気にならない・・。orz。
なので、僕はずっと USB な if_rtwn_usb.ko を利用しています。一応 802.11a での通信になってしまうのだけど supend/resume には対応しているので、そこはかとなく使い続けている状態です。

 
今回は、今 FreeBSD をインストールして利用している ThinkPad X13 で Intel Wi-Fi 6 AX200 を 802.11ac or ax で利用するために bhyve を利用して ubuntu をインストールします。
そして ubuntu 側で Wi-Fi 6 AX200 を利用するのですが、一応、前提条件を書いておきます。

  • 今回 ubuntu はルータとして利用しません。IPv4/IPv6 のデアルスタクにすると設定むづかしくてしょーがない・・。
  • 母艦の FreeBSD はネットワーク的にはフツーに通信できる状態として、それとは別にブリッジ経由で bhyve の ubuntu と通信します。
  • データのやり取りは bhyve な ubuntu 側の wlp0s6 を利用し、母艦の ThunPad X13 上の FreeBSD に橋渡しします。
  • 母艦の FreeBSD の /home/takachan を bhyve な ubuntu に NFS マウントするとこでデータ転送の手間を省きます。

 
上記を図にするとこんな感じ。

 
母艦側の FreeBSD の default gateway を bhybe の ubuntu の 172.16.1.11 にすると母艦側の通信は ubuntu の wlp0s6 を抜けて WiFi6 な通信が可能になるのだけど、戻りパケットの設定などを上位のルータに設定して上げる必要があったりとか、IPv4/IPv6 デアルスタクにすると色々ややこしくなるのでやめました。

 
では、母艦の FreeBSD に必用な設定と bhyve 側 ubuntu のインストールと設定を見ていきましょう。

 
1. FreeBSD 母艦側の設定
まず、 FreeBSD の母艦側の設定を行います。

今回、 bhyve を動作させるために、まず packages をインストールします。今回はこれだけインストールしました。

$ pkg info | grep bhyve
bhyve-firmware-1.0_1           Collection of Firmware for bhyve
edk2-bhyve-g202308_3           EDK2 Firmware for bhyve
uefi-edk2-bhyve-csm-0.2_4,1    UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
vm-bhyve-1.5.0                 Management system for bhyve virtual machines

 
続いて起動時の設定を行います。

 
o./boot/loader.conf

# bhyve
vmm_load="YES"
hw.vmm.amdvi.enable=1
pptdevs="2/0/0"

 
bhyve を利用するには vmm.ko を kldload する必要があります。そして hw.vmm.amdvi.enable=1 にします。
しかし、 vmm.ko は仮想環境で排他利用となります。以前のエントリで書いていますが VirtualBox を利用する場合は vmm.ko を kldunload する必要があります。

pptdevs=”2/0/0″ は pciconf -lv で確認した PCI デバイスを bhyve で利用するための設定です。以下は pciconf -lv の例です。

$ pciconf -lv | grep -A 3 iwl
iwlwifi0@pci0:2:0:0:        class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x8086 subdevice=0x0080
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6 AX200'
    class      = network

 
if_iwlwifi.ko を利用したデバイス iwlwifi0 は PCI バスの 2:0:0 に割り当てられているので、/boot/loader.conf で上記のように割り当ててあげます。

次に bhyve の起動設定です。

 
o. /etc/rc.conf

vm_enable="YES"
vm_dir="/opt/bhyve"

 
vm_enable=”YES” と vm_dir=”hoge” を設定しました。他に zfs のオプションとかなんか色々あるみたいですが、ひとまず不要なので省き、一番簡単な設定のみとしました。

これで一旦再起動します。

 
2. bhyve の準備と OS のインストール

o.ネットワーク設定
bhyve では仮想スイッチを利用します。まぁ『仮想スイッチ』と、言ってもただ単にブリッジインターフェースを作成するのみです。

母艦側 FreeBSD のネットワークの状態は lo0 と wlan0 があるのみです。 wlan0 は if_rtwn_usb.ko を利用した 802.11a で 5G の周波数に接続するフツーの NIC です。

ここに bhyve の ubuntu と通信するための『仮想スイッチ』を準備してしてあげます。

# service vm start
# ifconfig tap0 create
# sysctl net.link.tap.up_on_open=1
# vm switch create -a 172.16.1.1/24 public
# vm switch add public tap0
#
# ifconfig -a
lo0: flags=8049 metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
<一部略>
wlan0: flags=8843 metric 0 mtu 1500
        inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::20f:ff:fe8d:2c72%wlan0 prefixlen 64 scopeid 0x2
        inet6 2001:470:fe36:5678::32:1 prefixlen 64
<一部略>
vm-public: flags=8843 metric 0 mtu 1500
        ether 3e:ce:d6:69:ff:84
        inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap0 flags=143
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
        groups: bridge vm-switch viid-4c918@
        nd6 options=9
tap0: flags=8943 metric 0 mtu 1500
        options=80000
        ether 58:9c:fc:10:fc:0e
        groups: tap
        media: Ethernet autoselect
        status: no carrier
        nd6 options=21
        Opened by PID 2627

 
bhyve で利用する tap0 を作成します。次の sysctl はまぁ、おまじない。次に『仮想スイッチ』を public という名で vm switch create します。ついでに IP アドレスを付加します。

ifconfig -a で確認すると vm-public と tap0 が作成されました。
vm-public は bridge インターフェースで vm switch add public tap0 コマンドにより tap0 を内包しています。かつ vm-public には 172.16.1.1/24 の IPv4 アドレスが付きました。 bhyve 側の ubuntu は FreeBSD 側から見ると tap0 ですが ubuntu 側では enp0s2 として認識してそこに 172.16.1.11/24 のアドレスを付加すると母艦と bhyve 側の ubuntu で通信が可能になります。

母艦側の wlan0 は全く触ることはありません。

 
ネットワークの設定ができたので、bhyve の ubuntu をインストールしていきましょう。

まず、原型を作成します。

# service vm start
# vm create -t ubuntu ubuntu
# cd /opt/bhyve
# ls -aCF
.config/    .img/       .iso/       .templates/ ubuntu/
#
# vm install ubuntu .iso/ubuntu-23.04-live-server-amd64.iso
<以下略>

 
/etc/rc.conf に記載した vm_dir の /opt/bhyve の下に色々できています。 /opt/bhyve/.templates/ の下にファイルを一個作成します。

o./opt/bhyve/.templates/ubuntu.conf

loader="uefi"
cpu=2
memory=2G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
graphics="yes"
graphics_port="5900"

 
このファイルを作成して、iso イメージを /opt/bhyve/.iso/ に設置してから vm install ubuntu を実行しましょう。そして、インストールします。あ。なんか、 ubuntu23 はメモリが 512MB ではインストーラが起動しないようです。1GB とか 2GB のメモリ量にしてあげましょう。

インストール中はネットワークは利用できないので利用する iso イメージは最低限インストールできるものをチョイスします。

これでイントールは完了しましたかねぇ。

o. bhyve の ubuntu の起動スクリプト

#!/bin/sh

case $1 in
'start' )
    bhyve -c 2 -m 1G -w -H -S \
          -s 0,hostbridge \
          -s 1,virtio-blk,/opt/bhyve/ubuntu/disk0.img \
          -s 2,virtio-net,tap0 \
          -s 3,fbuf,tcp=0.0.0.0:5900 \
          -s 4,xhci,tablet \
          -s 5,lpc -l com1,stdio \
          -s 6,passthru,2/0/0 \
          -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
          ubuntu
    ;;
'tm' )
    tmux new-session -d -s mugi-ubuntu 'sudo /opt/bhyve/bin/vm_ubuntu.sh start'
    sleep 3
    ifconfig tap0 | grep status
    ;;
'stop' )
    bhyvectl --force-poweroff --vm=ubuntu
    ;;
'ls' )
    bhyvectl --get-stats --vm=ubuntu
    echo;echo
    echo "tmux list-sessions"
    echo "tmux attach -t ubuntu"
    ;;
'*' )
    echo vm_ubuntu.sh { start | stop | ls | tm }
    ;;

esac

exit 1;

 
bhyve でゲスト OS を起動するにはずいぶんと難儀です。上記のスクリプトは /opt/bhyve/bin/vm_ubuntu.sh という名で準備しました。
ちと、説明が必要ですかね。

まず、 start オプションのパラメータですが、-s は PCI BUS を想定してください。ディスク・ネットワーク・コンソール・USB、そして pptdevs で渡された Intel Wi-Fi 6 AX200 になります。このパラメータでまず、ubuntu が起動できるかと思います。

しかし、ここまでたどり着くまでにはずいぶんと色々苦労したので bhyve の起動オプションは本当に難儀したぞぉ。簡単に bhyve の ubuntu とか FreeBSD が起動するとは思わないほうが良い。色々検索して情報を探してくだされ。 BIOS でのブートとか UEFI でのブートとか、google に聞くと古い情報とかごまんとあって、最新の情報を拾ってくるのは中々悩ましい・・。

 
次の tm オプションですが、これは tmux を介してバックグラウンドで動作させます。 tmux については個別に勉強してください。コマンドのサワリだけ書いておきます。

# tmux list-sessions
ubuntu: 1 windows (created Wed Sep 27 12:31:41 2023)
# tmux attach -t -ubuntu
<以下略>

 
tmux list-sessions で tmux のセッションを確認して、そのセッションに tmux attach -t -ubuntu でアタッチするとコンソールが表示されます。コンソールから抜けるには tmux のコマンド C-b d を打ちます。

もしかしら ubuntu では tmux 使えないかも・・。
もうひとつのコンソールへのアクセス方法があります。 ports から net/tigervnc-viewer をインストールします。そして、以下のコマンドを打ちます。

$ vncviewer localhost:5900
<以下略>

 
上のほうで /opt/bhyve/.templates/ubuntu.conf というファイルを作成しましたが、そのとき graphics_port=”5900″ を指定していると思います。また bhyve 起動時にも -s 3,fbuf,tcp=0.0.0.0:5900 というオプションを指定しています。これが vncviewer でアクセスするポートになります。

コンソールに接続できたので ubuntu の設定を色々していくことにします。まぁ、僕は ubuntu はあまり得意ではありませんので、このあとはサワリだけ説明することにします。

そして、次に行きます。

 
3. 母艦と bhyve の ubuntu との通信
bhyve の ubuntu 側で ip addr をたたくと以下のインターフェースが確認できると思います。

$ ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp0s2:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
3: wlp0s6:  mtu 1500 qdisc noqueue state UP group default qlen 1000

 
enp0s2 が 母艦側との通信インターフェースで wlp0s6 が WiFi6 です。

まず、母艦の 172.16.1.1 と通信する enp0s2 設定からです。

o./etc/netplan/99-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s2:
      dhcp4: false
      addresses: 
        - 172.16.1.11/24
#     gateway4: 172.16.1.1
      nameservers:
        addresses: [192.168.1.34]
        addresses: [192.168.22.251]

 
さーっ!! yaml の設定に悩んでくだされーっ!! なんでまともに設定できんのだ?! とウンザリすることでしょう・・。orz
設定完了後 sudo netplan apply のコマンドを打って、で設定を反映して、そしてうんと怒られてください;-P。

無事に設定が完了すると、FreeBSD 母艦と bhyve との間の 172.16.1.0/.24 のセグメントで通信ができるようになります。

ここまでできたら母艦側から ssh 接続できるようになるので、作業が格段にしやすくなります。

 
続いて wlp0s6 側の設定を見ていきます。 enp0s2 は母艦との接続のためだけのインターフェースですが wlp0s6 は外部との通信を行います。 ubuntu は WiFi6 に対応しているので Intel Wi-Fi 6 AX200 を利用する通信はむちゃくちゃ速いです。

o./etc/netplan/50-cloud-init.yaml

network:
    wifis:
        wlp0s6:
            optional: true
            access-points:
                "AP80211AX":
                    hidden: true
                    password: "PASSWORD"
            dhcp4: false
            addresses:
              - 192.168.1.48/24
              - 2001:470:fe36:abcd::48:1
            gateway4: 192.168.1.1
            nameservers:
              addresses: [192.168.1.34]
              addresses: [2001:470:fe36::ffff:34]

 
WiFi の SSID は AP80211AX で パスフレーズは PASSWORD です。この AP はステルス機能を有効化しているので hidden: true を設定しています。
IP アドレスについては IPv4/IPv6 デアルスタクです。 IPv4 gateway は設定していますが IPv6 gateway は ra で降ってきます。ネームサーバも IPv4/IPv6 両方のアドレスを指定しました。

これまた書き方にうんと悩んだあと sudo netplan apply のコマンドを打って設定を反映して、そしてうんと怒られてください;-P。

これで ubuntu 側の設定は完了です。

 
4. bhyve の ubuntu の設定と実際に利用してみる
ubuntu では設定というか、dep を apt-get install で色々好きなものをインストールしてください。
ここでは特には書かないです。

唯一必要だったのが NFS クライアント側の設定でしょうか。母艦の FreeBSD 側で NFS Server を有効にして /etc/exports を書きます。 /home/takachan を NFS のマウントポイントとして 172.16.1.0/24 から許可します。
ubuntu 側では /etc/fstab に母艦の FreeBSD の /home/takachan を /home/takachan/takachan 辺りにマウントするようにします。

NFS の設定が完了したら、試しに iso イメージをダウンロードしてみましょう。

まずは母艦の FreeBSD で wget を実施し、次に ssh で bhyve の ubuntu にログインしたあとに wget してみました。

$ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 1%[                    ]   7.35M  1.84MB/s   残り3m 49s  
^C
$ ssh 172.16.1.11
ubuntu $ cd takachan
ubuntu $ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 4%[>                   ]  20.66M  10.2MB/s   eta 38s
^C
ubunru $

 
母艦側の FreeBSD のホームディレクトリで wget で iso イメージを取得すると大体 16Mbps の速度が出るか出ないか。これは USB の if_rtwn_usb.ko を利用して 802.11a で通信する FreeBSD で一番速い WiFi の速度です。
次に bhyve の ubuntu に ssh して NFS マウント先で wget すると FreeBSD側 の $HOME で wget するのと同じ状態になります。ただ、ubuntu 側で wget すると速度が全然違い 80Mbps 出ています。これは Linux での iwlwifi ドライバが正常に動作していることを示しています。そして、この速度はうちの外部接続ネットワークの限界です。

 
宅内の他の PC やサーバとデータをやりとりするときは ubuntu 側の 192.168.1.48 側のアドレスでデータをやり取りすることにより高速に転送することが可能です。

 
こんな感じで、いつまで待っても FreeBSD で WiFi の 802.11ac or ax が利用できないのを bhyve の ubuntu で通信速度を稼ぐ。と、いうちょっと荒業を、今回は使ってみました。

おかげで bhyve にずいぶんと詳しくなったぞぉーっ!! みたいな f(^^;;。

一点だけ注意点があるかも。母艦の FreeBSD は suspend/resume に対応していても bhyve で動作する OS が動作しないかな? FreeBSD の resume 後 vm lsit で Running 状態だったゲスト OS は動作がおかしくなる傾向が見受けられました。
が、これは当然でしょうかねぇ・・。考えてみると FreeBSD 側で Intel Wi-Fi 6 AX200 は supend/resume に対応してないので、たとえ pptdevs で ubuntu に渡していても resume 後は利用出来ない状態に陥ります・・。orz。

FreeBSD 14-R で if_iwlwifi.ko が suspend/resume に対応してくれるとともっと幸せになれるのだけれど、それはリリースされてみたいと解らないかなぁ。

 
と、いうことで、皆さんもせっかく持っている内臓の、 FreeBSD では中々利用できない Intel 系の WiFi チップ。 bhyve の ubuntu で有効利用するのもありなのかなぁ。と、いうのが今回のネタだったのでありました。

bhyve のこと、今後、ネタとして書く機会あるかな?

7月 012023
 

「リコリス・リコイル」をアニメ好きの人に教えてもらって見たら、確かに面白い。会社への往復で、スマートフォンで U-NEXT で見てたらなんとっ!! 『ギガ』が 4 ギガくらい消えて無くなった。 DVD で見るようにしたんだけど、画質が違うのねぇ。 U-NEXT などはテレビに対抗しないとならないので、画質がずいぶんと綺麗で驚いた次第・・。今更、 DVD もねーぞー。みたいな。

 
と、いうことでいきなりアニメの話ですが・・。

「リコリス・リコイル」の中に登場する『喫茶リコリコ』の風景。

コレ見るとさぁ・・。どうみても座布団が CPU に見えてしまうのよ。僕・・。

日本全国探しても、喫茶リコリコの座布団が CPU に見えてしまうのは僕だけだろうなぁ。

二枚の座布団は千束とたきなで使っているので、実質 6Socket なマザーボードなのだろうなぁ。みたいな;-)。あ。けど、実質 4Socket で千束はどこからか一枚持ってきたのかな?

 
と、いうことで座布団と CPU の比較。これがなくてただキャプチャ上げただけだと、著作権法にひっかかる。

とりあえず、手持ちの CPU で土台がムラサキでコア部分が金色の CPU を 6 枚並べてみた。

おーーっ!! 喫茶リコリコだぁっ!!

『本当に、座布団が CPU に見えるんですね。』 (たきな風に読んで;-)
『そーよっ!! すごいだろぉ。 ウォールナットもロボ太も持ってねーぞ。』(千束風に読んで;-)

あ。第 5 話の最後の部分ね;-P。

 
今度は P54C を並べてみた。あ。486 も混ざっているけど;-)。

ふむー。これはちょっと違うか。やっぱりコア部分がゴールドに輝いていたほうが座布団に見える。

せっかくなので Athlon も並べてみた。

土台がセラミックなのは 4 個しか持ってなかった・・。

で、このままでは Intel がかわいそうなので、Socket370 も並べてみた。

こちらは黒土台にシルバー。Celeron Dual な CPU。ピンのマークがあるけど、座布団に見えなくも無い。数が足りなかったので緑のヤツも並べました。

 
と、いうことで、非常にバカなことをしているようだが、見えてしまったものはしょーがない。実際に並べてみて『あぁ。やっぱり座布団は CPU に見えるよねぇ。』と、実感するのであります。

皆さんはどう思います? ;-P。

 
このサイトでは「リコリス・リコイル」の画像を著作権法第 32 条に定める比較研究を目的として引用しました。
「リコリス・リコイル」は Spider Lily/アニプレックス・ABCアニメーション・BS11 の著作物です。

6月 282023
 

自分でも、強引な手法だなぁ。と、思ってしまいます。

まず、 Windows11 Pro 上で動作している Hyper-V サーバがあります。その下で FreeBSD/amd64 13.2-RELEASE が動作しております。

Hyper-V の母艦である Windows11 Pro は NotePC なので WiFi 使ったり RJ45 使ったり VPN 使ったりするので Hyper-V のサーバとクライアントの間の「仮想スイッチ」はブリッジ、それはつまりは仮想スイッチマネージャの「接続の種類」で[外部ネットワーク]を選択することはほぼ不可能(利用する物理ネットワークによって毎回変更する必要がある)なのであります。

母艦側で複数のネットワークアダプタを利用する場合は、どうしても NAT、それはつまりは[内部ネットワーク]をチョイスするしかないのであります。

Hyper-V の仮想スイッチが NAT になると、色々と制約を受けます。まず、 DHCP を克服する必要があります。これについてはウェブ上に、設定方法について、色々書かれたドキュメントがあるのでそちらを参考にしてください。

いろいろ設定すると Hyper-V のクライアント (俗に『仮想マシン』と、言いますな) は NAT 配下で、固定 IPv4 アドレスで動作させることが可能になりました。

Hyper-V の母艦からは仮想マシンに対して ssh などのアクセスができるようになります。が、当然リモートのマシンからは Hyper-V 管理下の仮想マシンへはアクセスできません。

あと、仮想マシンのネットワークは NAT が入るのでこれまた色々と制約受けます。上に書いた、外部からのアクセスができません。他に NFS マウントできません。 gif トンネル張れません。とか・・。

 
そもそも、 Hyper-V の母艦の外部のネットワークに IPv6 がない場合、仮想マシンは IPv6 を利用することができません。あれ? Hyper-V の NAT 仮想スイッチで IPv6 喋れるのか?

どうして仮想マシン側に IPv6 が欲しいのだ? -> だって、IPv4 は NAT なので上記の制約受けるじゃん。それなら、トンネルでも良いから IPv6 でどっかーんっ!! と抜けていきたいじゃん。

と、いうのが発想の原点にあります。

と、いうことで図を書いてみました。

簡単に説明します。

  • 真ん中に Windows11 Pro の Hyper-V サーバがいます
  • Windows11 Pro の Hyper-V サーバは上位のネットワークとは IPv4 アドレスのみが降ってくるネットワークに接続しています
  • Hyper-V 配下の仮想マシンは FreeBSD/amd64 13.2-RELEASE です
  • Hyper-V サーバと仮想マシンの間には NAT の仮想スイッチが入っています
  • NAT の仮想スイッチは仮想マシンが固定 IPv4 アドレスを利用できるようにしています

 
これが現状、フツーにできる Hyper-V 環境です。この状態で、仮想マシン側に IPv6 グローバルアドレスを付加して、IPv4 の NAT 超えをあきらめ、IPv6 で外部との通信をできるようにして色々楽しめる状態にします。

  • 仮想マシンの FreeBSD は wireguard で外部に接続します
  • wireguard で作成した VPN トンネルの中に gif トンネルを通します
  • 仮想マシンに IPv6 が通ったので様々通信ができるようになります

 
トンネルの多段ですね。
図の左側は VyOS と wireguard のサーバは別々に描かれていますが、最近の VyOS を使うと一個にまとめられると思います。僕の環境では未だに VyOS-1.1.8 を利用していますので wireguard は別サーバに構築しました。

 
wireguard と VyOS の置き場所によって仮想マシンの IPv6 の通信速度は圧倒的に変わります。色々考えてみてください;-)。

と、いうことで、次に設定を見ていきましょうか。

 
1. 仮想マシン側の wireguard の設定
今回、仮想マシンは FreeBSD/amd64 13.2-RELEASE なので wireguard は ports から簡単に入ります。 net/wireguard をインストールしましょう。もしかしたら wireguard-kmod-0.0.20220615_1 がインストールされるかもしれませんが、実際には利用しません。

wireguard-kmod-0.0.20220615_1 をインストールした場合には /boot/modules/if_wg.ko がインストールされますが 13.2-RELEASE からは OS 標準で /boot/kernel/if_wg.ko が用意されています。フツーに wireguard_enable=”YES” すると /boot/kernel/if_wg.ko が利用されます。

僕の環境では wireguard-2,1 、wireguard-kmod-0.0.20220615_1 、 wireguard-tools-1.0.20210914_1 がインストールされました。

次に設定です。

が、その前に、まず最初に wireguard では鍵のペアを作成する必要があります。

# cd /usr/local/etc/wireguard/
# wg genkey > server.key
# wg pubkey < server.key > server.pub
#
# wg genkey > client.key
# wg pubkey < client.key > client.pub
# 
# chmod 600 *.key 
#

 
サーバ側とクライアント側のキーの両方を作成しましたが、これを利用します。

続いて設定を見ていきます。今回は wireguard のトンネルを一個作成するだけですので wg0.conf のみです。複数に接続する場合は wg1.conf wg2.conf などと設定フアイルを複数書きます。

・/usr/local/etc/wireguard/wg0.conf

[Interface]
PrivateKey = 8LJDuAU9Ste2ySHRmgHnOAyk+E4ZMbw+vCBbMHXMbZU=
Address = 192.168.254.11/32

[Peer]
PublicKey = 17CucZLVbS1Jt/8LXREvrDGEnYunIA2RYYjlJhxftlk=
AllowedIPs = 192.168.254.1/32, 10.20.65.201/32
Endpoint = 10.20.65.15:51820

 
[Interface] の 設定は自分側の設定を記載します。

  • PrivateKey は作成した鍵ファイルの client.key の内容を記載します。
  • Address は wg0 インターフェイスに付加する IPv4 アドレスです。 wireguard で接続するためだけに利用するので /32 で指定します。ただ、サーバ側と同じレンジが良いでしょう。

続いて [Peer] の設定で、これは wireguard のサーバ側に関する設定になります。

  • PublicKey は server.pub の内容を記載します。
  • AllowedIPs は wireguard サーバの wg0 インターフェイスの IPv4 アドレスを記載します。
  • AllowedIPs にはもう一個 IPv4 アドレスを記載します。 gif トンネルの接続先 IPv4 アドレスを “,” で区切って記載します。詳細についてはあとで書きます。
  • Endpoint は wireguard が動作しているサーバの IPv4 アドレスと Port 番号を記載します。

 
だいたいこんな感じで良いと思います。非常に簡単な設定ですね。ただ、一点。 [Peer] 側の設定の AllowedIPs の設定がクセモノです。
AllowedIPs に wireguard サーバ側の wg0 インターフェースの IP アドレスを書いただけでは wireguard サーバとしか通信ができません。

『wireguard サーバ側で NAT の設定を入れてないから他のネットワークと通信できんのか?』と思い、wireguard サーバ側の設定を色々いじってしまうのですが、そうではなく、クライアント側がどこと通信したいのか、AllowedIPs に記載することにより通信が可能となります。

今回は wireguard トンネルを抜けいてったあと gif トンネルを張りたいので VyOS の IPv4 アドレスを AllowedIPs に追加しました。 10.20.65.0/24 と通信したい場合は AllowedIPs には wireguard サーバの wg0 インターフェースの IPv4 アドレスと 10.20.65.0/24 を追加で書けば良いです。

で、自動起動するように設定を書きます。 /boot/loader.conf に明示的に if_wg_load=”YES” と書かずともカーネルモジュールがロードされます。

・/etc/rc.conf

wireguard_enable="YES"
wireguard_interfaces="wg0"

 
これでクライアント側の設定は完了です。

次にサーバ側の設定を見ていきましょう。

 
2. wireguard のサーバ側の設定
上のほうでも書きましたが、 wireguard のサーバは自前で用意せずとも VyOS で利用可能です。 VyOS-1.3 以降から wireguard に対応したんだったかな? 詳細なバージョンは覚えていませんが・・。

今回、僕は wireguard サーバも FreeBSD 側で作成しました。インストールは ports からですが、クライアント側のと同様のモノをインストールしました。

鍵は既に作成したので、それを使いまわしましょう。すると、サーバ側で用意するのは設定フアイル一個のみです。

・/usr/local/etc/wireguard/wg0.conf

[Interface]
PrivateKey = aJbypbTUy5LB+EIPd6FHf25D2rbTw9l+x5o7fBLL+Ec=
Address = 192.168.254.1/24
ListenPort = 51820

[Peer]
PublicKey = F8kvub6jdPnl99rISnffYtilNVEswDUo+sqGWzc7FRY=
AllowedIPs = 192.168.254.11/32

 
[Interface] の 設定は自分側の設定を記載します。

  • PrivateKey は server.key の内容を記載します。
  • Address は wg0 インターフェイスに付加する IPv4 アドレスです。

続いて [Peer] の設定で、これは wireguard のサーバ側に関する設定になります。

  • PublicKey は client.pub の内容を記載します。
  • AllowedIPs は wireguard クライアントの wg0 インターフェイスの IPv4 アドレスを記載します。

 
以上で設定は完了です。 /etc/rc.conf にクライアントのと同じ設定を追加して wireguard を起動します。サーバ側とクライアント側の両方で service wireguard start を実行すると wg0 インターフェースが生えてきます。

双方の wg0 の IPv4 アドレスに ping を打ち、到達性を確認します。この時点で ping が当たらない場合は設定情報が間違っています。なおしてください。そもそも wireguard のサーバとクライアントの物理インターフェース間で通信できることを確認します。

 
双方の wg0 に付加された IPv4 アドレスに ping が当たるようになったら OK。クライアント側の [Peer] 設定の AllowedIPs に記載した VyOS の IPv4 アドレスに ping が当たることを確認します。
上にも書いた通り 10.2.65.201 だけでなく、もっと他のマシンにも接続したい場合はクライアント側で設定してみてください。

 
最後に wireguard の wg0 トンネルをぬけて gif トンネルを掘ります。 gif トンネルが掘れると Hyper-V の仮想マシンにはグローバルな IPv6 アドレスが付加されます。 IPv6 を利用することにより IPv4 で受けていた NAT の制約から開放されることになります。パチパチパチっ!!

と、いうことで IPv6 gif トンネルの設定については以前書いているのでそつらを参考にしてください。

IPv6 Over IPv4 トンネルを dtcp から VyOSへ。

 
移動する PC 上で Hyper-V を動かしたとき、その下で動作する仮想マシンはネットワーク的に色々な制約を受けるモノです。今回は多段トンネルでその問題を解決してみました。

  • 仮想マシンは NAT ネットワークで gif トンネルが利用できないので wireguard なトンネルを掘る
  • wg0 を抜けて gif トンネルを掘る
  • IPv4 は NAT ネットワークなので IPv6 の直アクセスで NAT 問題を回避
  • 仮想マシンに IPv6 アドレスが付加されたので仮想マシンのネットワークはもーサイコーっ!!

 
こんな感じの手順で今回の構成を構築しましたが、フツーここまでやる?

ってか、まあ、Hyper-V が動作するのは WindowsOS なので、ネットワーク的に色々な制約が多すぎてやりたいことができない。
ネットワークはトンネルで抜けて色々やりましょう。と、いう雰囲気ですが・・。

一点だけ。まだ検証してないし、計算が必要だと思うのですが・・。 MTU って、一体いくつになるの? f(^^;;。

6月 042023
 

最近はテレワークから会社に出社するように変更したので、週に 3 回ほど会社に行くようになりました。会社に行く日は 05:30 起きです。

と、いうことで前ふりはここまで。

この間 05:30 に起きて部屋の中をうろちょろしていたらなんか臭うんですな・・。『なんだろ?この焦げ臭さ??』などと思っていたのですが、朝、近所で火事でもあったのか?と思ったけど消防車のサイレンとか特にない・・。

と、いうことで、夜中に何かしら動いていて怪しいのと思ったのは・・。まずはスマートフォンを確認。で、iPhone8 を触ってみたら熱い・・。『ふむー。夜中の充電中に熱が出たか?』と、思ったのだけど、なんか、ミョーに臭う・・。

ちなみに僕のスマートフォンの充電風景はこんな感じ。

都合 5 台のスマートフォンを充電しております。充電専用の台だったりしますが、この写真は今回の事件のあとに撮りました。iPhone の下のテーブルの黒いシミに注目。詳細はここからです;-)。

で、こちらは AC アダプタを接続するタップ。

コンセント単位にスイッチが付いているものをチョイスしています。少しでも安心・安全・電気を使わないように心がけての気持ちから。

 
で、今日は会社に行く日なので、チンタラチンタラできないません。とりあえず、充電器が接続されているタップのスイッチをオフにして出社。

出勤途中や会社で iPhone8 を使うと、やはり、ミョーに焦げ臭い・・。

と、いうことで家に帰って再度確認。

iPhone8 はケーブルではなく Qi 充電しているのですが、その充電器をひっくり返してみました・・。

あらぁ・・。(@_o)。

あぶねーっ!! 見事に焦げ付いていますっ!!

5V 2.4A の AC アダプタからケーブルを経由して Qi 充電器 (800yen くらいで購入した、どこにでも売っているツヤ) を接続し、その上に iPhone8 を載せて充電していたのですが・・。

木製のテーブルは Qi 充電器直下が炭になっております。

Qi 充電器が熱を帯びて、テーブルが焦げた雰囲気です。 (@_o)
異臭の原因は Qi 充電器が熱で熱くなり、プラスチック側が溶けだし、そのまま木製のテーブルを焦がした可能性があります。

もし、電源タップ側のスイッチをオフにせず、そのまま会社に行っていたら・・。Qi 充電器の上に iPhone がないとはいえ、Qi 充電器が通電していたとしたら、木製のテーブルが燃えだしていたかもしれません・・。『火事』ですな・・。orz

 
バッテリーが爆発するとかはよくある話ですが、 Qi 充電器も木のテーブルを焦がすほどのパワーがあるとは思いませんでした・・。

今回の教訓。

  • 触ってみて熱くなっているモノは壊れる前兆? 火が出る前兆?
  • スマートフォンを充電する場合は木製テーブルの上ではなく、鉄や石の上のほうが安全

皆様もお気をつけくだされ・・。

4月 292023
 

以前のエントリで「Dockerを利用してWordPressを動作させます。それもブリッジを用いて。」や「AlmaLinux8 の VRF。」なんてのを書いていますが、それの改訂版です。

 
なんか、色々調べてみると Linux 方面では bridge を有効にするには全部で三つの方法があるのだそうな。

  • bridge-utils を使う
  • nmcli を使う
  • ip link set dev を使う

 
以前の経験から、古いアーキテクチャである bridge-utils は既に rpm にもなっていない。かつ、IPv6 通信ができない。と、いうことでもう利用してはいけないのであります。IPv6 通信ができない。と、いうのは上記のリンクにも書いています。

nmcli を利用すると、設定情報は Almalinux8 の場合は /etc/sysconfig/network-scripts/ 配下にファイルとして保存してくれるんだけど、これが Almalinux9 になると、保存先が変わって記載方法も変わるのであまり使いたくない・・。

直感的に『あぁ。設定しているなぁ。』と感じるのは ip link set dev なコマンド達でしょうか。今回はこれをメインで bridge 設定をしていきたいと思います。

 
がっ!!

まず、 VRF の設定をしてルーティングテーブルを複数持つ環境を構築し、Docker コンテナを NAT なしで起動するための bridge 化。そしてっ!! 以前利用していた bridge-utils を捨てたのは Docker コンテナで IPv6 を利用するため。

と、いう、これはまさしく地獄絵図;-P。

 
どんな状態になっているか?と、いうと・・。

$ nmcli dev status
DEVICE           TYPE      STATE            CONNECTION      
eth0             ethernet  接続済み         eth0            
eth1             ethernet  接続済み         eth1            
eth2             ethernet  接続済み         eth2            
eth3             ethernet  接続済み         eth3            
eth4             ethernet  接続済み         eth4            
br0              bridge    接続済み (外部)  br0             
br1              bridge    接続済み (外部)  br1             
br4              bridge    接続済み (外部)  br4             
mgmt0            vrf       接続済み (外部)  mgmt0           
lb0              vrf       管理無し         --              
docker0          bridge    接続済み (外部)  docker0         
docker_gwbridge  bridge    接続済み (外部)  docker_gwbridge 
veth32347c8      ethernet  管理無し         --              
lo               loopback  管理無し         --              

 
多少並び直していますが、インターフェースはこれだけあります。結構多いほうだと思います;-)。

一応、表にしてみました。今回は絵はナシで・・。

物理 IF VRF bridge IPv4 IPv6 説明
eth0 br0 192.168.22.0/24 2001:470:fe36:face::/64 外部からのアクセス用で Docker ホストとコンテナで同一セグメント
eth1 br1 192.168.52.0/24 2001:470:fe36:cafe::/64 DB アクセスなどのバックヤード用で Docker ホストとコンテナで同一セグメント
eth2 192.168.111.0/24 2001:470:fe36:111::/64 同一ネットワーク上の NFS サーバへのアクセス用
eth3 mgmt0 192.168.1.0/24 2001:470:fe36:1::/64 外部からの ssh などのメンテナンス用
eth4 lb0 br4 192.168.202.0/24 ロードバランサ配下のためなし ロードバランサ用閉域セグメントで Docker ホストとコンテナで同一セグメント

 
セグメントはそれぞれ記載しましたが、インターフェースにつける実際のアドレスは 218 です。 IPv4/IPv6 共に 218 を設定しています。

 
Docker ホストにはインターフェースが全部で 5 個。
VRF を設定するルーティングテーブルは全部で 3 個。 eth0,eth1,eth2 が所属する default のルーティングテーブル。 eth3 はメンテナンス用なので mgmt0。 eth4 はロードバランサセグメントなので lb0。

5 個のインターフェースの内、Docker コンテナでも同一セグメントを利用するために bridge が存在していますが、それは 3 個。
Docker コンテナのネットワーク接続は色々なパータンを想定。

  • Service-Segment への接続みのウェブサーバ
  • Service-Segment と Access-Segment への接続する WordPress 用サーバ
  • LB-Segment への接続のみの負荷分散を考慮したウェブサーバ
  • LB-Segment と Access-Segment への接続するウェブアプリケーションサーバ

 
Service-Segment は外部からの直接アクセスを想定。 Access-Segmen はバックヤードで DB 接続や tomcat への接続を想定。 LB-Segment はロードバランサ配下の閉域セグメント。

ロードバランサは上位に apache を用意しましたが、上位のロードバランサからの閉域セグメントとして VRF を設定して、かつ、それを bridge して Docker コンテナに直接アクセスするように設定しました。

それにしても、フツー、ここまでするかねぇ?! みたいな;-)。

 
では、実際に設定を見てい行きましょう。

まず、 /etc/sysconfig/network-scripts/ 配下の ifcfg-eth* のファイルですが、フツーの設定で問題ありません。ルーティングテーブルが存在するインターフェースの設定ファイルのみに GATEWAY= や IPV6_DEFAULTGW= を指定してあげてください。
rule-eth* や route-eth* は今回は用意しませんでした。

 
1. VRF の設定
VRF の設定は /etc/rc.local 内に記載します。

ip link add dev mgmt0 type vrf table 10
ip link set dev mgmt0 up
ip link set dev eth3 master mgmt0
ip link set dev eth3 up
ip route add default via 192.168.1.1 table 10
ip route add ::/0 via 2001:470:fe36:1::1 table 10

ip link add dev lb0 type vrf table 4
ip link set dev lb0 up
ip link set dev eth4 master lb0
ip link set dev eth4 up
ip route add default via 192.168.202.1 table 4

route delete default
route delete default
route delete default
route add default gw 192.168.22.1

route delete -host 192.168.1.1
route delete -host 192.168.202.1

ip route del ::/0 via 2001:470:fe36:1::1
ip route del ::/0 via 2001:470:fe36:face::1
ip route del 2001:470:fe36:1::1/64
route -6 add default gw 2001:470:fe36:face::1

sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1

 
こんな感じでしょうか。/etc/iproute2/rt_tables に table 4 とか 10 の名前を書いても良いですが、数値で管理する場合は不要です。

ルーティング設定を色々いじっているのは、ルーティングテーブルが美しくならないのでコマンドで正しいルーティング情報にしているためです。

こうなっているのが美しいかなぁ・・。と、思っています。

$ ip route show
default via 192.168.22.1 dev eth0 
192.168.22.0/24 dev eth0 proto kernel scope link src 192.168.22.218 metric 100 
192.168.52.0/24 dev eth1 proto kernel scope link src 192.168.52.218 metric 101 
192.168.111.0/24 dev eth2 proto kernel scope link src 192.168.111.218 metric 102

$ ip route show table 10
default via 192.168.1.1 dev eth3 
broadcast 192.168.1.0 dev eth3 proto kernel scope link src 192.168.1.218 
local 192.168.1.218 dev eth3 proto kernel scope host src 192.168.1.218 
broadcast 192.168.1.255 dev eth3 proto kernel scope link src 192.168.1.218 
 
$ ip route show table 4
default via 192.168.202.1 dev eth4
broadcast 192.168.202.0 dev eth4 proto kernel scope link src 192.168.202.218 
local 192.168.202.218 dev eth4 proto kernel scope host src 192.168.202.218 
broadcast 192.168.202.255 dev eth4 proto kernel scope link src 192.168.202.218 

$ ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:470:fe36:111::/64 dev eth2 proto kernel metric 102 pref medium
2001:470:fe36:cafe::/64 dev eth1 proto kernel metric 101 pref medium
2001:470:fe36:face::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 1024 pref medium
fe80::/64 dev eth1 proto kernel metric 1024 pref medium
fe80::/64 dev eth2 proto kernel metric 1024 pref medium
fe80::/64 dev eth3 proto kernel metric 1024 pref medium
default via 2001:470:fe36:face::1 dev eth0 metric 1 pref medium

$ ip -6 route show table 10
anycast 2001:470:fe36:1:: dev eth3 proto kernel metric 0 pref medium
local 2001:470:fe36:1::218:1 dev eth3 proto kernel metric 0 pref medium
anycast fe80:: dev eth3 proto kernel metric 0 pref medium
local fe80::8785:99b6:f03b:cf5e dev eth3 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth3 proto kernel metric 256 pref medium
default via 2001:470:fe36:1::1 dev eth3 metric 1024 pref medium

$ ip -d link show type vrf
7: mgmt0:  mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 56:64:d2:f2:ee:55 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 10 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
8: lb0:  mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2e:68:9e:22:5f:0e brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 4 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

 
VRF しているインターフェースのルーティング情報が乗っていると削除して、正しいルーティング情報に直すので roure del したり route add しています。上記になっているのが、僕は一番美しいルーティングテーブルだと思っているのであります。
この辺り、nmcli だとちゃんとやってくれるのかなぁ?

 
VRF は eth0,eth1,eth2 の default テーブルと、eth3 の mgmt0 なテーブル、そして、eth4 のロードバランサ用テーブルと、合計三つのデーブルを作成しました。外部からアクセスすると、おのおののインターフェースから入って、入ってきたところから出ていきます。

 
さてと。 VRF で複数のルーティングテーブルがあると、例えば自分のサーバから外部のサーバに ssh したい場合、default のルーティングテーブルから出ていってしまいます。

本来、メンテナンス用の eth3 のインターフェースがあるのですが、VRF しているのでフツーに ssh するとへんなことになります。そんなときはインターフェース指定でコマンドを実行するのが良いですね。 そんなときに利用するのが if vrf exec コマンドです。

$ traceroute -n 192.168.1.217
traceroute to 192.168.1.217 (192.168.1.217), 30 hops max, 60 byte packets
 1  192.168.22.1  0.416 ms  0.460 ms  0.456 ms
 2  192.168.1.217  0.659 ms  0.654 ms *
$ ip vrf exec mgmt0 traceroute -n 192.168.1.217
traceroute to 192.168.1.217 (192.168.1.217), 30 hops max, 60 byte packets
 1  192.168.1.1  0.405 ms  0.323 ms  0.324 ms
 2  192.168.1.217  0.665 ms  0.668 ms  0.687 ms
$ ip vrf exec mgmt0 ssh 192.168.1.217
>

 
上のは default のルーティングテーブルの gateway である 192.168.22.1 経由で出ていきますが、 ip vrf exec “VRF インターフェース名” を付加してコマンドを打つと eth3 の VRF mgmt0 の gateway を経由して通信できます。 FreeBSD 的には setfib コマンドがありますが、それと同等機能ですね。

VRF の設定はこれにて完了。これは以前書いたものとほぼ一緒かな。

 
2. bridge の設定
次に Docker ホストと Docker コンテナの間で同一のセグメントを利用できるようにする bridge の設定をします。一番上に書きましたが「Dockerを利用してWordPressを動作させます。それもブリッジを用いて。」のエントリの改訂版になります。

bridge-utils はもう捨てて ip link set dev コマンドを利用して設定します。

まず、bridge インターフェースを生成するための docker network create コマンドの実行から。

# docker network create Service-Segment \
     -o "com.docker.network.bridge.name"="br0" \
     --driver=bridge \
     --subnet 192.168.22.0/24 \
     --gateway 192.168.22.218 \
     --ipv6 \
     --subnet 2001:470:fe36:face::/64 \
     --gateway 2001:470:fe36:face::218:1

# ifconfig br0 inet6 del fe80::1/64

 
もう bridge-utils を捨てたので docker network create で生成するネットワークは IPv4/IPv6 のデアルスタクに対応にします。コンテナも IPv4/IPv6 のデアルスタク対応です;-)。

docker network create で –ipv6 を指定するとリンクローカルアドレスに fe80::1 が自動的に付加されます。fe80::1 はコンテナが IPv6 を利用したときの gateway になるんだそうな。強引に付加されます。

bridge なネットワークなので複数の Docker ホストがあった場合、全ての Docker ホストがリンクローカルアドレスに fe80::1 を利用すると IPv6 duplicate address fe80::1 てな感じになり、同一セグメント上のサーバ間の通信ができなくなります。なので、ifconfig br0 inet6 del して削除します。そもそも既に由緒正しいリンクローカルアドレスが付加されているので fe80::1 はまるっきり不要です。

次に br0 と物理インターフェース eth0 を bridge します。

# ip link set dev br0 up
# ip link set dev eth0 promisc on
# ip link set dev eth0 up
# ip link set dev eth0 master br0
# ifconfig eth0 0.0.0.0 up
# ifconfig eth0 inet6 del 2001:470:fe36:face::218:1/64 up

# route add default gw 192.168.22.1 dev br0
# ip route del ::/0 via 2001:470:fe36:face::1
# route -6 add default gw 2001:470:fe36:face::1 dev br0

 
上から順に説明すると、

  • docker network create で生成した br0 を UP します
  • eth0 のプロミスキャス・モードを有効化します
  • eth0 を UP します
  • eth0 と br0 をブリッジ化します
  • br0 に IPv4/IPv6 アドレスが付加されるので eth0 側から削除します
  • 最後にルーティング情報を設定します

こんな感じでしょうか。

ロードバランサセグメント用の設定も書いておきます。

# docker network create LB-Segment \
    -o "com.docker.network.bridge.name"="br4" \
    --driver=bridge \
    --subnet 192.168.202.0/24 \
    --gateway 192.168.202.218

# ip link set dev br4 up
# ip link set dev eth4 promisc on
# ip link set dev eth4 up
# ip link set dev eth4 master br4
# ifconfig eth4 0.0.0.0 up

# ip link set dev lb0 up
# ip link set dev br4 master lb0
# ip link set dev br4 up
# ip route add default via 192.168.202.1 table 4

 
こちらは閉域ネットワークです。でもって IPv6 がないのでシンプルです。外部からロードバランサ経由でアクセスがあったものは default gateway に戻っていきます。
ちなみに eth4, br4 の brige インターフェースは lb0 という VRF でもあるわけですが、bridge 生成時に VRF を意識する必要は全くありません。すげ;-)。

ちなみに eth1, br1 の組み合わせも bridge して docker network で Access-Segment として create しますが、今回は割愛します。

 
bridge を終了するコマンドも記載しておきます。

# ip link set eth0 promisc off
# ip link set eth0 down
# ip link set dev eth0 nomaster
# ip link delete br0 type bridge

# docker network rm Service-Segment

# ifconfig eth0 192.168.22.218/24
# ifconfig eth0 inet6 add 2001:470:fe36:face::218:1/64

# route add default gw 192.168.22.1 dev eth0
# ip route del ::/0 via 2001:470:fe36:face::1
# route -6 add default gw 2001:470:fe36:face::1 dev eth0

# ping -q -c 3 192.168.22.1 > /dev/null 2>&1

 
こちらも一応、説明しておきます。

  • eth0 のプロミスキャス・モードをオフにします
  • eth0 を DOWN してから eth0 と br0 の bridge を削除します
  • br0 を削除するので docker network rm を実行します
  • eth0 に IPv4/IPv6 アドレスを付加します
  • ルーティング情報を更新します
  • 最後に ping を打つのは上位のルータが保持している古い MAC アドレスを書き換えるため

こんな感じでしょうか。

これで VRF でルーティングテーブルが個別なネットワークを bridge して Docker コンテナが利用できる環境が整いました。

 
3. IPv4/IPv6 デアルスタク対応コンテナの起動
最後に Docker コンテナの使い方について書いておきます。何回も書いている通り bridge-utils を捨てて ip link set dev コマンドに移行したので Docker コンテナは IPv4/IPv6 のデアルスタクで動作させられます。

起動はこんな感じで。もっと複雑な起動方法については「Dockerを利用してWordPressを動作させます。それもブリッジを用いて。」を参照してください。

$ docker run -d \
 --net=Service-Segment --ip=192.168.22.246 --ip6=2001:470:fe36:face::218:246 \
 -v /opt/docker/contents/web-service01/html:/var/www/html \
 -v /opt/docker/contents/web-service01/conf.d:/etc/httpd/conf.d \
 -v /opt/docker/contents/web-service01/logs:/var/log/httpd \
 --log-driver=syslog --log-opt syslog-facility=local3 --log-opt tag=docker/{{.Name}}/{{.ID}} \
 --name web-service01 \
 web-service01:1 /usr/sbin/httpd -DFOREGROUND
$
$ docker exec -it web-service01 /bin/bash
[root@3383ac655b6b /]# ifconfig eth0
eth0: flags=4163  mtu 1500
        inet 192.168.22.246  netmask 255.255.255.0  broadcast 192.168.22.255
        inet6 2001:470:fe36:face::217:246  prefixlen 64  scopeid 0x0
        inet6 fe80::42:c0ff:fea8:16f6  prefixlen 64  scopeid 0x20
        ether 02:42:c0:a8:16:f6  txqueuelen 0  (Ethernet)
        RX packets 43  bytes 4322 (4.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 806 (806.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[root@3383ac655b6b /]# exit
$

 
Docker ホストと Docker コンテナの間に NAT が入ってない (それはつまりは docker0 インターフェースを利用していない) 純粋な IPv4/IPv6 アドレスを利用したコンテナへのアクセスができるようになりました。 docker0 インターフェースを利用してないので /etc/docker/daemon.json への ipv6 true や fixed-cidr-v6 の設定も不要です。

思う存分 IPv4/IPv6 デアルスタクな Docker コンテナを楽しめる環境が整いました;-)。

IPv4 は NAT だけど IPv6 は腐るほど持っているので、Docker コンテナでも IPv6 が利用できるほうが良いですよねぇ;-)。

ちなみにですが、拾ってきた Docker イメージのうち portainer, registry, docker-registry-frontend などは、根こそぎ IPv6 でのアクセスが可能です;-)。

 
さてと。今回のお題目。

ポリシールーティングではなく VRF してルーティングテーブルをわけてから bridge して Docker ホストと Docker コンテナで同一ネットワークを利用し、更に IPv4/IPv6 のデアルスタクで Docker コンテナを運用する。

と、いうのができました。僕としてはもう、ほぼほぼこれで満足です。最終目的かもしれないです。ふぅ。

まぁ、実装するのは簡単で、これを実運用に持っていくには対障害対応とか色々必要となってくるのですが、色々と設定が必要そうです。

あと、Swarm を利用を利用して、当該 の Docker ホストがダウンしたときはコンテナは移動し、ダウンした Docker ホストのネットワーク環境などを整え終わったら再度サービスに復活させるとかの対応も必要かも。

 
ひとまずこれでヨシとしよう。

ふぅ。楽しかった;-)。

3月 282023
 

三ヶ月に一回 Let’s Encrypt の証明書の更新があるわけだけど、今回はハマった・・。なのでちょっと書いておきます。

Let’s Encrypt の SSL 証明書更新後はちゃんと openssl コマンドを利用して確認するんだけど・・。

 
・https の確認

$ openssl s_client -connect running-dog.net:443 | openssl x509 -enddate | grep notAfter

 
・sendmail の確認

$ openssl s_client -connect mail.running-dog.net:587 -starttls smtp | openssl x509 -noout -dates

 
・imaps の確認

$ openssl s_client -connect mail.running-dog.net:993 | openssl x509 -noout -dates

 
まぁ、これらのコマンドを打って確認できるのは証明書の日付くらいか・・。サービスが実際に正常動作しているかは、やはり、ログを見ないと解らないか・・。

 
今回の Let’s Encryp の SSL 証明書更新後のハマりポイント。

 
1. Apple のメールアプリが imaps サーバに接続できなくなった
macOS や iOS などのメールアプリが根こそぎ imaps サーバに接続できなくなった。 macOS に Thunderbird をインストールしてそこから imaps サーバにアクセスすると特に問題なくアクセスできる・・。

macOS のメールアプリからアクセスすると、ログには以下のように残っていました。
あぁ・・。 moacOS 側のアプリのキャプチャ無くてすみません・・。

imapd-ssl[39496]: ip=[<略>], couriertls: connect: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

 
なんか、おかしい・・。macOS 上の SSL 証明書を「キーチェーンアクセス」から削除してもダメ・・。

まぁ、ログを見ると cipher が足りない風な感じはしているのよねぇ・・。

と、いうことで Apple 製品の SSL 系 cipher についての記載を調べてみると以下の URL が見つかりました。

https://support.apple.com/ja-jp/guide/security/sec100a75d12/web

上記を読むと『 ECDHE_ECDSA_AES および ECDHE_RSA_AES』が必要なようです。僕は imap サーバに courier-imap を利用している(この記事の執筆時点にインストールされているバージョンは courier-imap-5.2.2 です)のだけど、この二つの cipher を /usr/local/etc/courier-imap/imapd-ssl の設定に追加しました。

こんな感じになりました。

TLS_CIPHER_LIST="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA:ECDHE_ECDSA_AES:ECDHE_RSA_AES"

 
随分と長くなりました。で Apple 製品のメールクライアントからアクセスすると無事に接続できるようになったのでありました。ふぅ・・。

 
2. sendmail が他のメールサーバから Relay を受け付けなくなった
imapd に接続できないのはまぁ、良いんだけど、こっちはダメージでかいですね。届くはずのメールが届かないのでおかしいなぁ・・。と、思っていたら sakura インターネットからのメールがエラーになっていて・・。

ログを確認すると、こんな感じ。

sm-mta[76876]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=<略>.sakura.ne.jp [<略>]

 
なんか、こちらも cipher が足りない感じ。orz

しょうがないので /etc/mail/sendmail.cf の O CipherList をちょっと変更。

#O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:
O CipherList=ALL
#O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:

 
当初設定したていたのはコメントアウトしてある一番上の行。どの cipher が足りないのか解らないので真ん中の O CipherList=ALL 行を有効にして全ての cipher で対応できるようにして、ログを確認。そーすると、ちらほらメールを受信し始めました。ふぅ。
で、更にログを眺めいてたら以下のログを発見。

sm-mta[33084]: STARTTLS=server, relay=<略>.sakura.ne.jp [<略>], version=TLSv1.2, verify=NO, cipher=ECDHE-ECDSA-AES256-GCM-SHA384, bits=256/256

 
なるほど。新たに ECDHE-ECDSA-AES256-GCM-SHA384 を追加する必要があるのね。と、いうことで O CipherList の設定は一番下の行にして、sendmail を再起動したら無事に復活したのでありました。

 
ふぅ。それにしても Let’s Encrypt の SSL 証明書を更新しただけで、メールの送受信ができなくなるとは恐ろしいことだぁ・・。

https は全然問題なかったのだが・・。

それにしも証明書の更新後の確認は日付だけでなく、ログの確認であるとか、実際にポートに接続して確認する必要があるかなぁ・・。今後の課題ですな。

 
と、いいつつ Let’s Encrypt だけでなく google や Apple は SSL 証明書の期限をさんが月にしよう。キャンペーンをしているけど・・。大変になる頻度が増えるかな。

3月 062023
 

最近、スマートフォンは以下を利用しております。

画面が一番大きいのは moto g52j 5G ですが、やはりもっと大画面が欲しい。と、なったのであります。
僕は Y!mobile ユーザで PayPay も利用しているので「ヤフープレミアム会員」です。そうすると、雑誌読み放題な特典が付いてきて、スマートフォンで色々な雑誌を見ることが可能です。
例えば競馬新聞である『馬サブロー』なんかも閲覧可能なので、競馬の予想もできます。と、いうことは・・。やはっぱりタブレットが欲しい。大画面が魅力的に感じるのであります。

と、いうことで今回は ALLDOCUBE iPlay50 という Android タブレットを購入してみました。これを購入した決め手は画面サイズですね。解像度が 2000×1200 の 2K ディスプレー、俗に WUXGA とでも言うのでしょうか。
価格的には 17,000yen 弱でした。こいつにケースを追加で購入。これで僕もすっかりとタブレット人生を歩むことになりそうです。

写真はこんな感じです。
壁紙はあんまり気にしないでくださいf(^^;;。

で、購入後 10 日ほど利用してみたので ALLDOCUBE iPlay50 の気がついた点をダラダラと書いてみます。

 
1.Android12
Android のバージョンは 12 でした。今僕が利用している moto g52j 5G や Xperia 10 II XQ-AU52 (こいつは SIM ナシで Wi-Fi で一応、利用中) なんかも Android12 です。 Android12 の機能は多分一通り利用できると思われます。画面分割とか一応利用可能です。

 
OS が一緒なのでスマートホンと機能的には本当に変わらないですね。ただ単に画面が大きくなった感じでしょうか。 iOS と iPadOS は大きな違いがあるのかな?

 
ロック画面の解除は指紋・顔認証どちらも非搭載です。なので、数値を入力することでロックを解除する必要があります。まぁ、これは値段相応なのかな・・。
顔認証は OS の標準機能ではないのかな?他にオプション的な機能が何か必要なのかな?

 
2.ステルス Wi-Fi に接続できない。
おかしいのよねぇ・・。 Android12 ならステルスな Wi-Fi に接続できると思うんだけど、このタブレットはステルス機能を有効にした Wi-Fi AP をみつけることができません。かぁなり驚きっ!!

 
3.LTE 接続できます
一つのスロットに SIM カードと MicroSD を乗せることができます。もしくは SIM カード二枚乗せることができます。

なので、LTE 通信が可能です。対応バンドは以下のようです。

LTE: 1 / 2 / 3 / 5 / 7 / 8 / 20 / 28 / 34 / 38 / 39 / 40 / 41

SoftBank のバンドにしっかりとマッチしているので、利用するなら SoftBank SIM を入れることですね。

 
と、いうことで実際に入れてみました。

Y!mobile には「シェアプラン」というのがあります。「シンプルプラン M」の場合は 15GB の “ギガ” がありますが、全部使い切れない場合、繰り越されます。そして、更に余って消えてしまうのももったいないですね。と、いうことで SIM カードを何枚か調達できて、スマートホンとかタブレットで “ギガ” を分け合えることができます。

例えば、僕が「シンプルプラン S」を契約した親回線。奥さんが「シンプルプラン M」を契約した子回線。奥さんの契約に家族割が適用され、奥さんの「シンプルプラン M」は通常価格 3,278yen から 2,090yen になります。
奥さんの「シンプルプラン M」で「シェアプラン」を契約すると月々 539yen ほどの料金が発生しますが、既に家族割が効いているので、それでも基本料金より安くなります。

そして「シェアプラン」は 539yen で最大 3 枚の SIM カードがもらえます。でもって SIM カード発行手数料は 0yen っ!! 「シンプルプラン M」で “ギガ” が余っている人は「シェアプラン」を利用するのも一つの手かもしれません。

ちなみに「シェアプラン」の SIM カード、通話はできません。MMS は Softbank から届くだけ。という SIM カードです。

 
前置きが長くなりました。「シェアプラン」の SIM カードを ALLDOCUBE iPlay50 に入れてみます。が、素直に LTE の電波を拾ってくれません。最初の段階では LTE での通信できません。
それはそーですね。 ALLDOCUBE iPlay50 には Y!mobile の APN が入っていません。手動で設定する必要があります。


https://www.ymobile.jp/yservice/howto/simfree_android/apn/

こちらに記載されていますね。

名前:       Y!mobile APN (任意の文字列)
APN:        plus.acs.jp
ユーザー名: ym
パスワード: ym
認証タイプ: CHAP

 
まぁ、あとのは省略可です。とりあえず上記を指定します。

そして、しばらく待っていると 4G で接続できるようになります。

 
4.Androidマルチユーザ環境で利用
タブレットを購入したのは僕ですが、奥さんは LTE 回線を提供してくれました。と、いうことで、Android で初めてマルチユーザ環境を整えてみました。

「設定」->「システム」->「複数ユーザ」で有効化できます。

サブのアカウントを作成して、ロック画面からアクセスするときにユーザをチョイスしてパスワードを利用。

 
ユーザ単位で google アカウントが必要です。二つのアカウントは「Google ファミリー リンク」しても良いかと思います。

二つのアカウントで同じアプリを利用する場合、個別にダウンロードしてインストールする必用があります。ストレージが圧迫されるかな?と、いう気がします。
あと、パックグラウンドで色々動作していると CPU が食われるような気がします。なので、両方のアカウントでこまめにバックグラウンドアプリを停止するとか、メモリ開放するとかしないと、突如として遅くなる場合があったりします。

ALLDOCUBE iPlay50 の CPU は UNISOC T618 なので MediaTek のよりは処理速度が高いので、まぁ、なんとかマルチユーザ環境にも耐えられるかもです。

 
5.画面が大きいことは良いことだ
画面が大きいので色々できます。
ConnectBot をインストールして ssh 接続してメンテナンスとか行える。
Remote Desktop もあっても良いかもですねぇ。

 
Bluetooth キーボードを接続して上記アプリを利用すれば もうフツーの PC 感覚。あ。キーボード配列が日本語配列だとちと大変。そんなときは 物理キーボード配列変更 (+親指Ctrl) [日本語配列] をインストールすると日本語刻印の通りに文字入力できます。 Ctrl と CAPS キーのスワップ設定も入っているのでチョーご機嫌。 ssh で入った先で emacs とかフツーに利用できます。

 
そして、タブレット購入とタイミングがバッチリの非常に良い記事を発見。

https://pc.watch.impress.co.jp/docs/column/yajiuma-mini-review/1481098.html
https://www.spacedesk.net/

spacedesk というのを利用すると PC のサブディスプレイとしてタブレットを利用できます。 Windows PC にディスプレードライバインストールしてタブレット側に探査・転送アプリをインストールすると、確かにディスプレーとして機能します。すげー。

けど、今は無料で利用できるみたいですが、そのうちに有料化されるかな?と、いう雰囲気か。

 
とまぁ、今回はダラダラと書いてみました。やっぱり画面は大きいほうが良いっ!! と思うのは、もうスッカリとローガンになってきているから。なのでしょうかねぇ。

今回、初めて『タブレット』というモノを購入してみましたが、僕の人生の中でタブレット端末は効果的に機能してくれるのか、今後の動向を検証してみたいと思います;-)。

2月 042023
 

ちょっと前のエントリで「今年はキーボード色々。」というのを書きました。このエントリでは新たに「上海問屋 日本語 73 キー配列コンパクトメカニカルキーボード (TTC静音赤軸Ver.) DN-916082」を購入した。と、書いています。

で、このキーボード、カナ刻印ナシなんですよ。しかし、実際に利用してみると、僕ってすごいなっ!!カナ刻印なしでも日本語カナ入力で利用する文字が、ブラインドタッチで打ててしまっている自分がここにいる。と、いうことに気づかされました。

ヲレってすげーっ!! みたいな;-)。

が、しかし、時々つまずくこともあるですな。普段はあまり利用しないと思われる『ま』であったり、『や』『ゆ』『よ』などもちょっと悩む。これらのキーは右 Shift キーと同時押しの場合もある(つまり、ちっちゃい『や』『ゆ』『よ』を打ち込む場合ですな)。

やっぱりカナ刻印はあったほうが良いかもー。と、いうので、実はもう一個、ちっこいキーボードを購入購入してしまいました。

今度は赤軸ではなく、 NotePC みたいに薄い感じのキーボードです。俗にパンタグラフキーボード。などと呼ばれていたりするでしょうか。

とりあえず写真を。

上の写真は、もう 10 年くらい前に購入した Apple の USB の有線のキーボードです。で、下のが今回購入したキーボード。

「Arteck 2.4Gワイヤレスキーボード 無線」と、いうヤツで Amazon で 1,699yen で購入しました。雰囲気的には似てますな。打刻感もまぁ、NotePC に打ち込んでいるような雰囲気です。しかし、値段は上下の差が約 8 倍くらいか。でもって、1,699yen で購入したキーボードは USB の無線接続。 2.4GHz 帯を利用するので OS を選ばずに利用できます。

軽いので NotePC と一緒に持ち歩いても良いかもですね。まぁ、値段が値段だったので、そんな感じで購入しました。

 
が、やはり、慣れてしまうと赤軸なキーボードは捨てがたいですなぁ・・。と、いうことで、上海問屋の DN-916082 なキーボードにカナ刻印を・・。まずは手持ちのキーボードのキーを交換してみようと思いましたが、キーの裏の十字部分が合わずにあえなく玉砕。

 
そんなこんなで、『どうにかかならないもんか?ひらがな。』とか思い情報を集めたところ、なんとっ!! 100yen 均一なお店に、子供の勉強用にひらがなのシールが売っている。と、いう情報を見つけましたっ!!

シール的にはこんな感じっ!! これは行ける?!

で、実際にそのシールを貼ったキーボードがこちら。

おーー。すっかりとカナ刻印付きのキーボードになっているではないですかーっ!!

このワザ利用すると、どんなカナ刻印のないキーボードでも全然問題ないですっ!! すげーっ!!

HHKB がカナ刻印ナシの製品を出すようになって、色々なメーカがカナ刻印ナシキーボードを出すようになって、カナ入力な人は随分と肩身狭い思い、はたまた、選択枝が限られてきた世の中になりつつあったのに、これで一件落着ーっ!! って、感じです;-)。

 
今回はピンクのシールで丸ゴシックちっくなフォントのシールを貼りましたが、色々な 100yen ショップを回ると色々なフォントのひらがなシールが売っているので、自分のセンスやキーボードに合うのをチョイスするのが良いかと思われます;-)。

今の時代、ゲーミングキーボードとか鮮やかに光ったりするので、ピンクの丸ゴシックなフォントを利用しているシールを貼っても全然違和感のないモノに仕上がっている。と、自分自身思っている。それはつまりはただ単に『自己満足の世界』と、いう感じですけども。

 
カナ入力の人で、カナ刻印のないキーボードを使いたいっ!! HHKB でカナ入力したいっ!! という人は是一度試してみることをお勧めします;-)。

1月 292023
 

タイトルが大げさですなぁ;-)。

前回のエントリで構築した VRF が動作する AlmaLinux 8.7 ですが、その AlmaLinux8 は実は Docker ホストとしても動作しています。

 
これも、以前のエントリで「Docker Registry を作る。」というのを書いていますが、このホストと同一となります。

 
今回はこの Docker ホストに Docker コンテナを複数起動して、外部からアクセスできる環境を構築します。
Docker コンテナに対して外部からアクセスするためのポート番号は 80 番 (別に 443 でも良いのだけど、証明書関係が面倒だったので、Port:80 で許してちょんまげ;-) とします。しかし、複数の Docker コンテナが全て Port:80 番で待ち受けるためには NAT 環境では無理です。

今回は Docker ホストとコンテナ間をブリッジで接続して、Docker ホストで利用している外部接続ネットワークをコンテナでもそのまま利用するようにします。

 
図はこんな感じ。

 
VMware ESXi に二つの仮想マシンが動作しています。一個は Docker ホストで、もう一個は FreeBSD が動作して MySQL のサービスを他の仮想マシンに提供しています。

 
で、せっかくなので Docker コンテナがただ HTML なコンテンツを垂れ流す環境を構築してもつまらいないので WordPress が動作する環境を構築したいと思います。
ネタが二つ分の量だけど、大丈夫かなぁ・・。

と、いうことで、まずは Docker ホストの準備から。

とはいいつつ、以前、Docker Registry を作った環境をそのまま利用しています。ただ、 dnf update しているので多少バージョンが上がっているかも;-)。

$ cat /etc/os-release 
NAME="AlmaLinux"
VERSION="8.7 (Stone Smilodon)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.7 (Stone Smilodon)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.7"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"

$ rpm -qa | grep docker
docker-ce-20.10.22-3.el8.x86_64
docker-ce-rootless-extras-20.10.22-3.el8.x86_64
docker-scan-plugin-0.23.0-3.el8.x86_64
docker-ce-cli-20.10.22-3.el8.x86_64

 
いろいろ端折って、既に dockerd が起動しているものとして話を進めていきます。Docker のインストールと起動については他のサイトを参考にしてください。

 
1. Docker イメージの作成

$ docker search almaLinux
NAME                       DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
almalinux                  The official build of AlmaLinux OS.             102       [OK]       
<以下略>

$ docker pull almaLinux
Using default tag: latest
latest: Pulling from library/almalinux
<略>

$ docker image ls
REPOSITORY	TAG       IMAGE ID       CREATED        SIZE
almalinux       latest    acaca326f3b3   6 weeks ago    190MB

$ docker tag almalinux:latest almalinux8:1
$ docker image rm almalinux:latest

$ docker image ls
REPOSITORY	TAG       IMAGE ID       CREATED        SIZE
almalinux8      1         acaca326f3b3   6 weeks ago    190MB

$ docker run -it --name almalinux8 almalinux:1 /bin/bash
[root@b2db6f534790 /]# 

 
docker search で AlmaLinux を探して、オフィシャルサイトから pull して、 almalinux8:1 としてタグ付けしました。
このあと、docker run してコンテナの中に入って dnf update して、必要な rpm をインストールして httpd や php もインストールして、もとの Docker イメージを大幅に更新して tag 付けして Docker イメージを完成させます。

この辺り割愛しますが、各自で頑張って Docker イメージを作成してください;-)。

$ docker stop almalinux8
$ docker container commit almalinux8 almalinux8_wordpress:1
$ docker rm almalinux8

 
apache や php をインストールした新しい almalinux8_wordpress:1 という Docker イメージができました。このイメージをベースに色々やっていきましょう。

 
2. Docker コンテナで利用するネットワークの準備
次にネットワークの設定を行います。今回は複数の Docker コンテナに Dokcer ホストと同じセグメントを割り当てます。
僕の環境の AlmaLinux 8.7 は VMware ESXi 上で動作しています。そして、ネットワーク構成は前回の「AlmaLinux8 の VRF。」に記載してある以下の構成をそのまま利用します。

 
つまり、Service-segment 側はウェブアクセスのために利用し Access-Segment は MySQL アクセスで利用します。あ。MySQL サーバは 192.168.52.204 の FreeBSD 上で動作しています。

箇条書きにするとこんな感じ。

  • WordPress が動作する予定の Docker コンテナは外部からのアクセスは Port:80 で eth0 側に到達するように構築します。
  • その Docker コンテナは外部の MySQL サーバにアクセスするために eth1 のインターフェースを利用します。
  • Docker コンテナは二つのインターフェースを持ち、それぞれが Docker ホストからのブリッジで動作します。
  • 上記の図では、Server1 が Docker ホストで、Server3 が FreeBSD で MySQL サーバが動作しています。

 
と、いうような状況ですな。

その VMware ESXi が Docker ホストに接続するポートグループは「セキュリティ」において「無差別モード」「MACアドレレス変換」「偽装転送」の全てを『承諾』に設定します。eth0 と eth1 の二つのポートグループはブリッジインターフェースを利用するので無差別モード(俗に『プロミスキャスモード』と、言いますな)を有効にする必要があります。
VMware ESXi のネットワークの設定もちゃんとしましょう。

 
3. Docker network でネットワークの作成
と、いうことで Docker コンテナが利用する二つのネットワークを docker network コマンドで作成します。

$ docker network create Service-Segment \
     -o "com.docker.network.bridge.name"="br0" \
     --driver=bridge \
     --subnet 192.168.22.0/24 \
     --gateway 192.168.22.217

# brctl addif br0 eth0
# ifconfig eth0 0.0.0.0 up
# ip link set up dev br0
# route add default gw 192.168.22.1

$ docker network create Access-Segment \
     -o "com.docker.network.bridge.name"="br1" \
     --driver=bridge \
     --subnet 192.168.52.0/24 \
     --gateway 192.168.52.217

# brctl addif br1 eth1
# ifconfig eth1 0.0.0.0 up
# ip link set up dev br1

 
Docker ホストの eth0 の IP アドレスは 192.168.22.217 で、eth1 側は 192.168.52.217 です。

こちらも説明は箇条書きで。

  • eth0 の Service-Segment と eth1 の Access-Segment の Docker ネットワークを作成します。
  • このとき Docker ホストには docker0 というインターフェースが存在していますが、利用しないのでそのまま存在しつつ、無視して問題はありません。
  • NetworkManager でブリッジインターフェースの設定はしません。 /etc/sysconfig/network-scripts/ 配下に ifcfg-br0 などのファイルを置いてもなんの意味もありません。 docker network create コマンドを実行したときに付加するオプションである -o “com.docker.network.bridge.name”=”br0” があるので、既に br0 が存在しているとエラーになります。
  • –gateway オプションに指定する IP アドレスは Docker ホストの IP アドレスになります。
  • AlmaLinux 8.7 に bridge-utils の rpm はないようなのでソースからコンパイルしてインストールします。
  • brctl addif コマンドの実行や eth0 からアドレスを消して br0 にアドレスを付加するなどは全てコマンドで行います。
$ docker network ls
NETWORK ID     NAME              DRIVER    SCOPE
039e8158c77b   Access-Segment    bridge    local
622593f73c12   Service-Segment   bridge    local
9eb6f5610d75   bridge            bridge    local
d30c681a9f92   host              host      local
afbbadaba67f   none              null      local

 
無事に作成できるとこんな感じでしょうか。
ifconfig -a したときには br0 と br1 に IP アドレスが付いていて、eth0 と eth1 には IP アドレスはついていない状態が正解です。

これで Docker ホストとコンテナで同一セグメントを利用する環境が整いました。次にコンテナを run してみましょうかねぇ;-)。

 
4. Docker コンテナの起動
まず、いきなり WordPress を動かすコンテナを起動するのではなく Docker ネットワークに接続するために docker run してみましょう。

$ docker run -d --restart always \
 --net Service-Segment --ip 192.168.22.222 \
 -v /var/www/html/wordpress:/var/www/html \
 -v /etc/httpd/wordpress/conf.d:/etc/httpd/conf.d \
 -v /var/logs/httpd/wordpress/logs:/var/log/httpd \
 --log-driver=syslog --log-opt syslog-facility=local3 --log-opt tag=docker/{{.Name}}/{{.ID}} \
 --name almalinux8_wordpress \
 -d almalinux8:2 /usr/sbin/httpd -DFOREGROUND

 
今回は箇条書きではなく、ベタガキで・・f(^^;;。
-p 0.0.0.0:80:80 というオプションは指定しません。これ付けると一個の Docker コンテナが Docker ホストの Port:80 を掴んでしまいます。
–net で接続する Docker ネットワークと –ip でDocker コンテナが使用する IP アドレスを指定します。今回は固定 IP アドレスで 192.168.22.222 を利用します。docker network のオプションではレンジとか CIDR を指定することができて DHCP みたいな利用形態もできますが、ここでは割愛します。自分で調べてください。
-v で Docker ホスト側のディレクトリをコンテナ側にマウントしています。 Docker イメージを色々なサービスで使い回すならこれらは外出しした方が良いかなぁ。と、僕は思ったので Docker イメージには組み込んでいません。自分・環境のお好みで設定してみてください;-)。
–log-driver=syslog は syslog 出力するための設定です。 /etc/rsyslog.conf には以下を記載してください。

local3.*      /var/log/docker/container.log

 
書いたあと rsyslogd を再起動して、ついでに mkdir /var/log/docker してください。

 
と、いうことで、ここまでは Docker コンテナをブリッジインターフェース経由で外部公開するための起動方法になります。
ただ、これだと MySQL サーバにアクセスできないので、起動した almalinux8_wordpress コンテナに eth1 を生やしてあげるコマンドを投入します。

$ docker network connect Access-Segment --ip 192.168.52.222 almalinux8_wordpress

$ docker exec -it almalinux8_wordpress /bin/bash
[root@64583900cb33 /]# ifconfig -a
eth0: flags=4163  mtu 1500
        inet 192.168.22.222  netmask 255.255.255.0  broadcast 192.168.22.255
        ether 02:42:c0:a8:16:de  txqueuelen 0  (Ethernet)
        RX packets 27884  bytes 2705253 (2.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 257  bytes 754283 (736.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163  mtu 1500
        inet 192.168.52.222  netmask 255.255.255.0  broadcast 192.168.52.255
        ether 02:42:c0:a8:34:de  txqueuelen 0  (Ethernet)
        RX packets 36681  bytes 4887852 (4.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 586  bytes 113982 (111.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
<以下略>
[root@64583900cb33 /]# exit

 
と、いう感じで docker network connect コマンドを実行したので Docker コンテナには二つのインターフェースができました。

eth0 側は Dockerホスト外部から httpd に対してアクセスができていると思います。コンテナ起動時に指定した -v /var/www/html/wordpress:/var/www/html のオプションがありますが、 Docker ホスト側の /var/www/html/wordpress/ ディレクトリ配下に WordPress のコンテンツ一式が既にインストールされていると想定しています。

裏を返すと /var/www/html/wordpress/ 配下のコンテンツを何個かの Docker コンテナに -v でマウントさせると Docker コンテナのみで冗長構成を組むことができるのですな。 eth0 側のインターフェースは docker run 時に –ip で指定する IP アドレスを変えつつ起動したあと DNS ラウンドロビンでも良いし、ロードバランサ配下のネットワークに置いても良い。今まで複数の物理や仮想マシンが担当していた部分を Docker コンテナでマカナエル。と、いうことですな。

あ。ちなみに、僕の場合は WordPress の初期環境一式は FreeBSD の ports からインストールして、 FreeBSD 上の /usr/local/www/wordpress/ ディレクトリごと tar でかためて持ってきました;-)。簡単に初期の環境が整うです。で、 IP アドレスにアクセスすると「さぁ。わーどぷれすをいんすとーるしましょうっ!!」みたいな画面がいきなりでます;-)。
あ。実はエラーになってそう簡単には出ないか・・f(^^;;。

 
そーそー。注意点が一個。 NetworkManager を利用しないでブリッジインターフェースの設定をしているので、サーバに再起動が入ると設定が全て飛んでしまいます。 Docker ネットワークの設定は Docker が覚えていてくれるんだけど、ブリッジを設定するためのコマンド brctl addif の設定は再起動で消えてしまうので /etc/rc.local などでリカバリーする必要があるです。

 
5. Docker コンテナ の WordPress 対応
僕は普段 FreeBSD 上で WordPress を動作させているので Linux 上で動作させるには随分難儀なことでして・・。

まずは Docker イメージを作成するとこでイメージに対して httpd とか php をインストールします。そのあと、AlmaLinux8 の rpm の httpd は mod_mpm_event.so で動作しているようで、これをひとまず mod_mpm_prefork.so に変更します。
Docker イメージ内の /etc/httpd/conf.modules.d/00-mpm.conf の設定ファイルの中で LoadModule mpm_event_module modules/mod_mpm_event.so の行をコメントアウトし LoadModule mpm_prefork_module modules/mod_mpm_prefork.so の行を有効化します。
これの変更で一回 docker container commit する必要がありますな。

次に Linux で WordPress を動作させるためには php-fpm というのを起動する必要があるのだそうな。と、いうことで、これも Docker イメージ内でちょっと細工をします。

mkdir /run/php-fpm と chown 48:48 /run/php-fpm ですね。一応、この二つのコマンドを Docker コンテナ内で実行し、docker container commit して環境を整えます。

ふぅ。これで準備整ったかな?と、いうことで、 WordPress が動作する Docker コンテナを起動するスクリプトのまとめとしましょう。

#!/bin/sh

docker run -d --restart always \
 --net Service-Segment --ip 192.168.22.222 \
 -v /var/www/html/wordpress:/var/www/html \
 -v /etc/httpd/conf.d/wordpress:/etc/httpd/conf.d \
 -v /var/logs/httpd/wordpress/logs:/var/log/httpd \
 --log-driver=syslog --log-opt syslog-facility=local3 --log-opt tag=docker/{{.Name}}/{{.ID}} \
 --name almalinux8_wordpress \
 -d almalinux8:2 /usr/sbin/httpd -DFOREGROUND

docker network connect Access-Segment --ip 192.168.52.222 almalinux8_wordpress

export CONTAINER_ID=`docker ps -a | grep " almalinux8_wordpress" | awk '{print $1}'`
export DOCKER_PID=`docker inspect --format '{{.State.Pid}}' $CONTAINER_ID`

sudo nsenter -t $DOCKER_PID -n route delete default
sudo nsenter -t $DOCKER_PID -n route add default gw 192.168.22.217 eth0
sudo nsenter -t $DOCKER_PID -n ping -c 3 192.168.22.217

sudo nsenter -t $DOCKER_PID -m -u -i -n -p -- /usr/sbin/php-fpm --nodaemonize &

 
こんな感じでしょうか。

ちょっと説明を。

  • docker run で Service-Segment の Docker ネットワークに接続し、固定 IP アドレスを利用します。
  • -v で Docker ホスト側に用意したコンテンツや設定ファイルを参照するようにします。
  • コンテナの syslog を Docker ホスト側に出力します。 docker run の説明はここまで。
  • 次に、起動した almalinux8_wordpress に対して、もう一個の Docker ネットワークを接続します。
  • その次は nsenter コマンド連発です;-)。 nsenter コマンドは docker exec しなくとも Docker ホスト側から Docker コンテナに対してコマンドを投入できるコマンドです。そのためには当該の Docker コンテナのプロセス番号が必要になるのでそれを取得します。
  • コンテナ内に eth0 と eth1 が存在するので default gateway を設定してあげます。一旦削除してから再度設定。みたいな感じです。
  • コンテナ内から Docker ホストに対して ping を打つのは、コンテナ起動ごとに MAC アドレスが書き換わるので、上位のルータに対して MAC アドレスの更新をする必要があるためです。ルータ側の MAC アドレス書き換えタイムアウトまで待っても良いですねぇ。根が短気な性分なものでして・・f(^^;;。
  • そして、最後の nsenter コマンドは Linux で WordPress を動かすための php のおまじない。 /usr/sbin/php-fpm を nsenter コマンドで起動してあげます。Docker コンテナ内に入って ps -ax すると httpd と php-fpm の二種類のプロセスが一個のコンテナ内で起動する状態となります。つまり、 php-fpm 専用コンテナは不要である。と、いうことです。
    例えば、(本来、動かす必要はないのだけど) zabbix_agent なども nsenter で動かすことができます。コンテナ自体が固定 IP を利用しているので Zabbix Agent のポートにもアクセスできるようになります。

 
これで Service-Segment 側に指定した IP アドレスにウェブブラウザからアクセスすると、WordPress の初期設定画面が表示できると思います。

データベースは MySQL ですが 192.168.52.204 で動作している MySQL サーバへのアクセスは eth1 側を抜けていくので WordPress の初期設定画面で IP アドレス・ユーザ名・パスワードを設定するとアクセスできると思います。
あ。当然、 MySQL 側ではデータベースとアクセス用のアカウントを作成しておいてください。ここでは割愛しています。

 
さてと。ここまで来てファイアーウォールの設定が一回も登場していません。Docker にはファイアーウォールは必須なので、Docker ホスト側で systemctl start firewalld は必須です。僕の場合は /etc/firewalld/direct.xml で設定していますが、 -i で指定するインターフェース名は eth0 と br0 、 eth1 と br1 の両方を記述する必要があるので、その点は注意してください。

 
あとは・・。

これで多分大丈夫だと思います。

起動する Docker コンテナは、コンテンツと設定ファイル、そして、ログ出力を -v で Docker ホスト側の情報をマウントしているので docker run 時に違うディレクトリを指定し、他にネットワーク、IP アドレスの設定を変えるだけで一個の Docker イメージで複数の、用途の違う Docker コンテナを起動して同じ仕事をしてくれるようにすることも可能です。んー。 Docker らしい使い方ぁ;-)。

 
Docker って、基本 NAT が当たり前で、ブリッジインターフェースを利用した環境で『コンテナに対して直接アクセス』。っての、google で検索してもネタ的に今のところはあまり多くないかな。
しかし、実際にコンテナ使い込むとコンテナごとにポート番号変えるのって、なんか納得いかなくて、その先に『こんなんじゃ実際のサービスに提供できないじゃん。』と、いうところからブリッジインターフェースでコンテナに直接アクセス、ロードバランサから見ると仮想マシンもコンテナも同一の扱いのほうが楽じゃん。と、いう発想があります。そのためにはやっぱりブリッジだよねぇ。みたいな。

 
それにしても、実際に調べてみると Linux の bridge-utils ツール群はヘボいですな。今回、実は IPv6 のことについて全く書いてないんですよ。 bridge-utils は IPv6 側の作りが甘いっ!!
Docker ホストの br0 から出ていく TCP パケットには eth0 の MAC アドレスとか Link Local アドレスが記載されていて、受け取った PC のほうは戻りパケットを送信側 (Docker ホストのこと) の eth0 の MAC アドレスとか Link Local アドレスに投げようとするので、Dockerホスト側の br0 の情報がないために宛先がなくて、実質的に通信できない。と、いう非常にお粗末な状態です。
Docker 自体は IPv6 が使えるかもしれないけど、Linux でブリッジを利用する場合には IPv6 は利用しないほうが良いですな。パケットキャプチャしないと原因が特定できない。ハマる前に IPv6 の利用は諦めたほうが良いかと。

 
と、いうことで、今回、 Docker コンテナをブリッジインターフェースで、Docker ホストと同一のネットワークで動作させる。と、いうことにチャレンジしてました。 VMware ESXi 上で複数の仮想マシンを起動するがごとく、Docker ホスト上で Docker コンテナをドドドと立ち上げることが可能になったので、サーバ資源がますますギューギュー使える状態になったでしょうかねぇ;-)。

 
このあと、docker swarm がまだ待っております。が、オーバーレイネットワークがちゃんと動いてくれてないのよ。とほほ・・。orz