変奏現実

TeraTermで接続したら

Activate the web console with: systemctl enable –now cockpit.socket

っとメッセージが気になったのでググってみると

どうやらCockpitというWebコンソールパッケージを使おう！と云う提案らしい。

まぁ、TeraTermをインストしなくて済むならCockpitもアリかな？と思いCockpitをインスト。

# dnf install cockpit
# systemctl enable --now cockpit.socket
# firewall-cmd --permanent --zone=public --add-service=cockpit
# firewall-cmd --reload

これでCockpitが

https:/192.168.xxx.xxx:9090/

で、使えるようになった。

ブラウザに「保護されていない通信」と表示されるのは仕方が無い。（笑

メニューの一番下に「端末」機能もあるので、これでTeraTermともオサラバ？かと思ったけど

「端末」から接続してみると、「概要」でのCPU負荷が95%に上がってしまう様だ。

でも、TeraTermからも接続してtopコマンドで確認すると「端末」を開くとCPU負荷が60％まで上がりその後１％未満になるので、そう悪くない。

この「端末」でtopコマンドを実行すると反応が鈍いが、これもCPUのせいか？

ホストOS側にもインストしてDashboardやVirtual Machinesのアドオンを載せると楽そう。ゲストOSのコンソールまで付いているので行方不明になった時に便利そう。

ポートも

systemctl edit cockpit.socket

で、/etc/systemd/system/cockpit.socket.d/override.confを作成し適当なポートを割り当てればいいみたいなので、何かのWebサーバー管理とダブっても対応できそう。

ホストOS側で「ネットワーク」がNetworkManagerサービスを起動してもうまく認識できないかったので、anaconda-nm-config.serviceを起動しNetworkManagerを再設定し再ログインしたところ、表示するようになった。VM用のブリッジのせいかな？

ま、なんとなく使いそうなものは揃っている様だ。

唯一の難点は「最初の最初はTeraTermでログインしなければならない」ので、WindowsにTeraTermは必要そう。

しかし、これもゲストOSをコンテナ化しておけば多少面倒が減りそうな気もする。

ps.2023/08/10

程なく、動かなくなっていた。（大汗

原因は皆目見当が付かなかったので、ホストOS側のブリッジを作り直したり

何気にゲストOS側からIPアドレスを取得させてみると・・・

# ifconfig ens2　
ens2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether **:**:**:**:**:**  txqueuelen 1000  (Ethernet)
        RX packets 109  bytes 23789 (23.2 KiB)
        RX errors 0  dropped 4  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# dhclient  enp0s2 ※または ens2　でIPアドレス割当要求
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet 192.168.***.***/24 brd 192.168.***.255 scope global dynamic ens2
       valid_lft 14295sec preferred_lft 14295sec

と繋がるものの再起動すると繋がらない。

そう。

ゲストOSのcockpitで、ネットワークのens2（環境によりマチマチな名）を見ると

なぜか「全般」の「自動的に接続」のチェックボックスが外れていた。

あと、

この辺はcockpitと云うよりも既存のifconfigやdhclient自体の設定の反映が超遅いので仕方が無いけど

ネットワークでシクジると、己を信じつつ、じっくり時間をかけて少しづつ進めるしかないようだ。

※ああ、メンドクサイ。

尚、途中でホスト側すらLANから繋がらなくなったので、やはりモバイルモニターと非常用のキーボードは必須の様だ。でも、最後には面倒になって本体を棚から引っ張り出して普通のモニターに繋ぎ、

設定を変えては ip a で状況を観察していたけどね。（笑

試しにUbuntuの仮想マシンも作ってみると、cockpitの仮想マシンのコンソールにVPNやX windowの選択が出てくるので、TeraTerm接続で最小インストールから頑張るより楽だと思う。

注意点としては、仮想マシン作成時にISOイメージファイルを指定すると、CD-ROMデバイスとしてマウントしてくれて便利だけど、インスト後は不要とcockpitの画面からCD-ROMを削除して仮想マシンを起動するとkernel-panicになってしまうので「OSをダウンロードします」の方がいいかも。

但し、しょぼいCPU(J1900とか)ではOSのグラフィカルなインストーラの反応がさっぱり動かない時もあるので気長に。

後、rootディスクの空きが少なかったので、仮想マシンの「ストレージプール」で新規に追加してみた。/home/vmdiskとファイルの所有者設定の都合上、/homeにした。

これを使って、既存の仮想マシンにディスクを追加するとコンソールにログが出るから

# [  190.474791] pci 0000:00:03.0: [1af4:1001] type 00 class 0x010000
[  190.480984] pci 0000:00:03.0: reg 0x10: [io  0x0000-0x003f]
[  190.484985] pci 0000:00:03.0: reg 0x14: [mem 0x00000000-0x00000fff]
[  190.493296] pci 0000:00:03.0: BAR 1: assigned [mem 0xc0000000-0xc0000fff]
[  190.498379] pci 0000:00:03.0: BAR 0: assigned [io  0x1000-0x103f]
[  190.503135] virtio-pci 0000:00:03.0: enabling device (0000 -> 0003)
[  190.570240] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
[  190.579224] virtio_blk virtio5: [vdb] 62914560 512-byte logical blocks (32.2 GB/30.0 GiB)
[  190.585383] vdb: detected capacity change from 0 to 32212254720

ゲストOS側でmounttabにvdbデバイスをmounttabに追記すればいいのかなぁ？とか悩んでいるウチに仮想マシンがクラッシュしたので、追加したディスクを削除して実行。

仕方が無いから、WindowsのHyper-Vでディスク後付けの手順を確認してからやり直そう。

新規仮想マシン作成時で「ストレージプール」を指定する時も作成済みのボリュームファイルを指定する様なUIなので、指定の確認漏れ（≒ミス）＝指定してしまった既存ファイルの破壊に繋がるから要注意だ。

1. 事前にダミーファイルを作りUIを回避
2. 【作成して編集する】ボタンで即実行を回避
3. 正しいファイル名でディスクを追加
4. ダミーファイルのディスク設定を削除
5. 【実行】

こんな手順になるけど、こっちはちゃんとインストできた。