この画面は、簡易表示です
httpsを使わないとChromeの機嫌が悪い。
でも、そのままhttpsにしておくと、「怪しい電子証明書」として扱われるので、
ブログのためにLet’s Encryptで取得した電子証明書を流用してみる。
Let’s Encryptでの電子証明書は、/etc/letsencrypt/live/の{コモンネーム}のフォルダの中の fullchain.pem(証明書)とprivkey.pem(秘密鍵)を使用する。
cockitでは電子証明書を、/etc/cockpit/ws-certs.d/ フォルダの中に格納することになっているので、先の証明書と秘密鍵のファイルを、{コモンネーム}.crtと{コモンネーム}.keyとしてシンボリックリンクを貼り、cockpitを再起動。
しかし、ブログのkvmホストは非公開だからChromeが安心する様な電子証明書は作りにくいので、ブログサーバのcockpitのホストリストにkvmホストを登録してソコから接続することにした。
ま、この方法だとブログのサーバを止める時に困るけどね。普段は使えるからヨシとしよう。
KVMサーバーのCockpitのページから直接ブログサーバのCockpitに繋いでみた。
まずはSSH接続用の公開鍵を作る。
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): [passphraseを入力] ※passphraseはログイン時に使用
Enter same passphrase again: [passphraseを入力]
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Fyfc0Do9Wux/6uZgjLvM9nCq4mYVaOphgip9bx8I1eE root@xxxxxxxx.xxxxxxxx.local
The key's randomart image is:
+---[RSA 3072]----+
| . .. |
| o o o. |
| ..E ++o |
| .o . o+= |
| . .o S..= . |
|. . +. ....o. |
|.. + .... o =. |
|o . o = +.* .o .|
|. . *oooo*o.++o |
+----[SHA256]-----+次にブログサーバのSSHの設定内容を取得
# ssh-keyscan -H 192.168.xxx.xxx >> ~/.ssh/known_hosts
# 192.168.xxx.xxx:22 SSH-2.0-OpenSSH_8.0
# 192.168.xxx.xxx:22 SSH-2.0-OpenSSH_8.0
# 192.168.xxx.xxx:22 SSH-2.0-OpenSSH_8.0最後にブログサーバに公開鍵を送信
# ssh-copy-id root@192.168.xxx.xxx
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.xxx.xxx's password: [passwordを入力]
Number of key(s) added: 1
Cockpitの画面を開き、左上のサーバー名の右の▲をクリックして▼に変え、【新規ホストの追加】ボタンを押す。
ダイアログからIPアドレス、ユーザ名、パスフェーズを入力。
認証でSSHキーを選択、キーパスワードは先のパスフェーズを入力。
自動ログインは、/root/.ssh/id_rsa のパスワードを変更しますのチェックし、新しいパスワードを設定する。
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なので、指定の確認漏れ（≒ミス）＝指定してしまった既存ファイルの破壊に繋がるから要注意だ。
こんな手順になるけど、こっちはちゃんとインストできた。