変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

Linux

[シェルスクリプト]思い込みが強すぎるとバグる

if cp from to; then
  echo "コピーに成功しました"
else
  echo "コピーに失敗しました"
fi

という記事を見つけた。

cpのExit Statusは0は成功、0以外はエラーなので、上のコードで大正解なのだが、気に入らないらしい。

わざわざgrepを持ち出して、grep ‘[‘なら文法エラーで$?に2が入るから

if echo test | grep '['; then
  echo "文字列が見つかりました"
else
  case $? in
    1) echo "文字列が見つかりません" ;;
    2) echo "エラーが発生しました(終了ステータス: $?)" ;;
  esac
fi

うううん。素晴らしい。(だそうだ

だが、そうだろうか?

2) の後の$?は必ず 2 になるハズだから、

この組み合わせには不整合の臭いがする。

ちなみに

grepのExit Statusは

grepのステータス意味
0一致が見つかりました。
1一致が見つかりませんでした。
>1構文エラーが見つかったか、(一致が見つかったとしても) ファイルにアクセスできませんでした。

らしいので、明日にでも、>2が実装されれば、その事象が発生すると先のコードでは何も表示しないのだ。

よって・・・

if echo test | grep '['; then
  echo "文字列が見つかりました"
else
  case $? in
    1) echo "文字列が見つかりません" ;;
    2) echo "grepのオプションの構文エラーな気がする" ;;
    *) echo "ボクの知らないエラーが発生しました(終了ステータス: $?)" ;;
  esac
fi

が良い様な気がする。

今は想定外である( 3とか4など )な結果に対して、デグレードしているのは良くない。(と思う。

とかく、

  • ソースコードの書き方がよろしくない!
  • ソースコードが美しくない!
  • カバレッジテストで通らないコードがある!

な記事の多くには、バグ(あるいはデグレード)が含まれている。

主に経験不足なんだろうけど、そう云う香り(臭いではない)を楽しむのも風流かもしれない。

そもそもシェルファイル内で検索したい文字列をべた書きする事は稀で

WORD= "9999"
TEXT= "9999"
if echo $TEXT | grep $WORD ; then
  echo "$WORDが見つかりました"
else
  case $? in
    1) echo "'$WORD'が見つかりません" ;;
    2) echo "'$WORD'検索中にgrepのオプションの構文エラーが起きた気がする" ;;
    *) echo "'$WORD'検索中に不明なエラー($?)が発生しました" ;;
  esac
fi

の様に書く事が多い。

だって!

上のコードで云えば、grep 9999 と書けば

マジックナンバー扱いになるじゃないですかねぇ~(笑

それにechoの出力に検索したいテキストを埋め込むことも考えに入っていない。

そもそも・・・・・・・・

最初のコードに(終了ステータス: $?)を追記して

if cp from to; then
  echo "コピーに成功しました"
else
  echo "コピーに失敗しました(終了ステータス: $?)"
fi

とするだけでデメリット?らしいとこも無くなる。

やはり、

経験がかなり不足していると思える

て云うか、WindowsのBATファイルより少しマシな程度のものだから

デバッグのしやすさの方が優先するならソースデバッガが使えるpythonやnode.jsで書いた方が楽。

話がそれるけど・・・

man コマンド名でExit statusが見つけにくい

様に思う。

オプション多すぎ。



[Linux]cockpit が「保護されていない通信」扱い

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ホストを登録してソコから接続することにした。

ま、この方法だとブログのサーバを止める時に困るけどね。普段は使えるからヨシとしよう。



[AlmaLinux]DNF update失敗

AlmaLinux 8.9 (Midnight Oncilla)はcockpitでアップデートに失敗したけど

dnfコマンドで無事アップデートできたが

AlmaLinux 8.8 (Sapphire Caracal)はダメだった。

# dnf update
メタデータの期限切れの最終確認: 2:35:57 前の 2024年01月24日 23時23分56秒 に実施しました。
エラー:
 問題: libgs-9.27-11.el8.x86_64 と libgs-9.27-6.el8.x86_64 どちらもインストールできません
  - パッケージ libgs-devel-9.27-6.el8.x86_64 には libgs(x86-64) = 9.27-6.el8 が必要ですが、どのプロバイダーからもインストールできません
  - パッケージの最良アップデート候補をインストールできません libgs-9.27-6.el8.x86_64
  - インストール済パッケージの問題 libgs-devel-9.27-6.el8.x86_64
(競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)

パッケージの依存関係が解消できなかった様だ。

あーメンドクサイ。

とりあえず、指示通りに

–allowerasingをコマンドに付ける事により依存関係で競合してるパッケージを削除を削除してみる。

$ dnf -y update --allowerasing
(・・・中略・・・)
依存関係のインストール:
 perl-Digest                                      noarch      1.17-395.el8                                                     baseos          27 k
 perl-Digest-MD5                                  x86_64      2.55-396.el8                                                     baseos          37 k
 perl-IO-Socket-SSL                               noarch      2.066-4.module_el8.6.0+2811+fe6c84b0                             appstream      297 k
 perl-Net-SSLeay                                  x86_64      1.88-2.module_el8.6.0+2811+fe6c84b0                              appstream      378 k
 perl-URI                                         noarch      1.73-3.el8                                                       baseos         116 k
 perl-libnet                                      noarch      3.11-3.el8                                                       baseos         121 k
削除中:
 kernel                                           x86_64      4.18.0-477.21.1.el8_8                                            @baseos          0
 kernel-core                                      x86_64      4.18.0-477.21.1.el8_8                                            @baseos         70 M
 kernel-modules                                   x86_64      4.18.0-477.21.1.el8_8                                            @baseos         25 M
 kernel-modules-extra                             x86_64      4.18.0-477.21.1.el8_8                                            @baseos        677 k
依存関係パッケージの削除:
 libgs-devel                                      x86_64      9.27-6.el8                                                       @System         39 k

トランザクションの概要
====================================================================================================================================================
インストール     10 パッケージ
アップグレード  499 パッケージ
削除              5 パッケージ

ダウンロードサイズの合計: 1.0 G
パッケージのダウンロード
(1/509): kernel-4.18.0-513.11.1.el8_9.x86_64.rpm                                                                    6.3 MB/s |  10 MB     00:01
(・・・中略・・・)
(509/509): webkit2gtk3-2.40.5-1.el8_9.1.alma.1.x86_64.rpm                                                           5.5 MB/s |  24 MB     00:04
----------------------------------------------------------------------------------------------------------------------------------------------------
合計                                                                                                                 15 MB/s | 1.0 GB     01:11
AlmaLinux 8 - BaseOS                                                                                                4.9 MB/s | 5.0 kB     00:00
GPG 鍵 0xC21AD6EA をインポート中:
 Userid     : "AlmaLinux <packager@almalinux.org>"
 Fingerprint: E53C F5EF 91CE B0AD 1812 ECB8 51D6 647E C21A D6EA
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux
鍵のインポートに成功しました
GPG 鍵 0xCED7258B をインポート中:
 Userid     : "AlmaLinux OS 8 <packager@almalinux.org>"
 Fingerprint: BC5E DDCA DF50 2C07 7F15 8288 2AE8 1E8A CED7 258B
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux
鍵のインポートに成功しました
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
  scriptletの実行中: kmod-kvdo-6.2.8.7-92.el8.x86_64                                                                                            1/1
  scriptletの実行中: java-1.8.0-openjdk-headless-1:1.8.0.402.b06-2.el8.x86_64                                                                   1/1
  準備             :                                                                                                                            1/1
  scriptletの実行中: libgcc-8.5.0-20.el8.alma.x86_64                                                                                            1/1
  アップグレード中 : libgcc-8.5.0-20.el8.alma.x86_64                                                                                         1/1013
(・・・中略・・・)
  アップグレード中 : pam-1.3.1-27.el8.x86_64                                                                                                24/1013
警告: /etc/pam.d/smartcard-auth は /etc/pam.d/smartcard-auth.rpmnew として作成されました。
(・・・中略・・・)
  scriptletの実行中: python36-3.6.8-38.module_el8.9.0+3700+efebe9fd.x86_64                                                                 182/1013
シンボリックリンク /usr/bin/pip3 -> /etc/alternatives/pip3 の作成に失敗しました。 /usr/bin/pip3 がすでに存在しており、シンボリックリンクファイルではありません。
(・・・中略・・・)
  scriptletの実行中: python3-wheel-1:0.31.1-3.module_el8.9.0+3700+efebe9fd.noarch                                                          429/1013
シンボリックリンク /usr/bin/pip3 -> /etc/alternatives/pip3 の作成に失敗しました。 /usr/bin/pip3 がすでに存在しており、シンボリックリンクファイルではありません。
(・・・中略・・・)
  整理             : libwbclient-4.17.5-3.el8_8.alma.x86_64                                                                                804/1013
警告: ファイル /usr/lib64/samba/wbclient/libwbclient.so.0.15: 削除に失敗しました: No such file or directory
警告: ファイル /usr/lib64/samba/wbclient/libwbclient.so.0: 削除に失敗しました: No such file or directory

と、沢山のパッケージがアップデート!

php3系でパイプの処理がちょっと怪しい。

libwbclient系で何か削除に失敗してる。

大丈夫かな・・・

  整理             : libgcc-8.5.0-18.el8.alma.x86_64                                                                                      1013/1013
  scriptletの実行中: libgcc-8.5.0-18.el8.alma.x86_64                                                                                      1013/1013
  scriptletの実行中: glibc-all-langpacks-2.28-236.el8.7.x86_64                                                                            1013/1013
  scriptletの実行中: ipa-selinux-4.9.12-9.module_el8.9.0+3688+465b6369.alma.1.noarch                                                      1013/1013
  scriptletの実行中: crypto-policies-scripts-20230731-1.git3177e06.el8.noarch                                                             1013/1013
  scriptletの実行中: nss-3.90.0-4.el8_9.x86_64                                                                                            1013/1013
  scriptletの実行中: gnome-session-3.28.1-21.el8.x86_64                                                                                   1013/1013
  scriptletの実行中: grub2-efi-x64-1:2.02-150.el8.alma.1.x86_64                                                                           1013/1013
  scriptletの実行中: kernel-core-4.18.0-513.11.1.el8_9.x86_64                                                                             1013/1013
  scriptletの実行中: kernel-modules-4.18.0-513.11.1.el8_9.x86_64                                                                          1013/1013
  scriptletの実行中: kmod-kvdo-6.2.8.7-92.el8.x86_64                                                                                      1013/1013
  scriptletの実行中: java-1.8.0-openjdk-headless-1:1.8.0.402.b06-2.el8.x86_64                                                             1013/1013
  scriptletの実行中: authselect-libs-1.2.6-2.el8.x86_64                                                                                   1013/1013
  scriptletの実行中: httpd-2.4.37-62.module_el8.9.0+3646+acd210d0.x86_64                                                                  1013/1013
  scriptletの実行中: libvirt-daemon-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                                          1013/1013
  scriptletの実行中: libvirt-daemon-driver-network-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                           1013/1013
  scriptletの実行中: libvirt-daemon-driver-interface-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                         1013/1013
  scriptletの実行中: libvirt-daemon-driver-nodedev-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                           1013/1013
  scriptletの実行中: libvirt-daemon-driver-nwfilter-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                          1013/1013
  scriptletの実行中: libvirt-daemon-driver-qemu-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                              1013/1013
  scriptletの実行中: libvirt-daemon-config-network-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                           1013/1013
  scriptletの実行中: libvirt-daemon-driver-secret-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                            1013/1013
  scriptletの実行中: libvirt-daemon-config-nwfilter-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                          1013/1013
  scriptletの実行中: libvirt-daemon-driver-storage-8.0.0-22.module_el8.9.0+3714+46544554.x86_64                                           1013/1013
  scriptletの実行中: sssd-common-2.9.1-4.el8_9.alma.1.x86_64                                                                              1013/1013
  scriptletの実行中: authselect-compat-1.2.6-2.el8.x86_64                                                                                 1013/1013
  scriptletの実行中: tuned-2.21.0-1.el8_9.noarch                                                                                          1013/1013
  scriptletの実行中: java-1.8.0-openjdk-1:1.8.0.402.b06-2.el8.x86_64                                                                      1013/1013
  scriptletの実行中: firefox-115.6.0-1.el8_9.alma.x86_64                                                                                  1013/1013
  scriptletの実行中: microcode_ctl-4:20230808-2.20231009.1.el8_9.x86_64                                                                   1013/1013
  scriptletの実行中: libgcc-8.5.0-18.el8.alma.x86_64                                                                                      1013/1013
  scriptletの実行中: glibc-common-2.28-236.el8.7.x86_64                                                                                   1013/1013
  scriptletの実行中: systemd-239-78.el8.x86_64                                                                                            1013/1013
  scriptletの実行中: systemd-udev-239-78.el8.x86_64                                                                                       1013/1013
  
  検証             : kernel-4.18.0-513.11.1.el8_9.x86_64                                                                                     1/1013  
...
  検証             : libgs-devel-9.27-6.el8.x86_64                                                                                        1013/1013

アップグレード済み:
  NetworkManager-1:1.40.16-13.el8_9.alma.1.x86_64
...
  zlib-devel-1.2.11-25.el8.x86_64
インストール済み:
  kernel-4.18.0-513.11.1.el8_9.x86_64                                        kernel-core-4.18.0-513.11.1.el8_9.x86_64
  kernel-modules-4.18.0-513.11.1.el8_9.x86_64                                kernel-modules-extra-4.18.0-513.11.1.el8_9.x86_64
  perl-Digest-1.17-395.el8.noarch                                            perl-Digest-MD5-2.55-396.el8.x86_64
  perl-IO-Socket-SSL-2.066-4.module_el8.6.0+2811+fe6c84b0.noarch             perl-Net-SSLeay-1.88-2.module_el8.6.0+2811+fe6c84b0.x86_64
  perl-URI-1.73-3.el8.noarch                                                 perl-libnet-3.11-3.el8.noarch
削除しました:
  kernel-4.18.0-477.21.1.el8_8.x86_64                   kernel-core-4.18.0-477.21.1.el8_8.x86_64     kernel-modules-4.18.0-477.21.1.el8_8.x86_64
  kernel-modules-extra-4.18.0-477.21.1.el8_8.x86_64     libgs-devel-9.27-6.el8.x86_64

完了しました!

リブートできたし、AlmaLinux 8.9 (Midnight Oncilla)にアップグレードできてるし、結果オーライ。



[Linux]Cockpit コンソールから他のコンソールに繋ぐ

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 のパスワードを変更しますのチェックし、新しいパスワードを設定する。



[AlumaLinux]WARNING: AllowZoneDrifting is enabled.

# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2023-10-11 17:03:59 JST; 1 day 12h ago
     Docs: man:firewalld(1)
 Main PID: 793 (firewalld)
    Tasks: 2 (limit: 23014)
   Memory: 33.7M
   CGroup: /system.slice/firewalld.service
           mq793 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid

10月 11 17:03:55 *******.*******.********** systemd[1]: Starting firewalld - dynamic firewall daemon...
10月 11 17:03:59 *******.*******.********** systemd[1]: Started firewalld - dynamic firewall daemon.
10月 11 17:03:59 *******.*******.********** firewalld[793]: WARNING: AllowZoneDrifting is enabled. This is considered an insecure configuration option. It will...

firewalldでエラっていた。

AllowZoneDriftingは将来のリリースでは削除される予定です。今すぐ無効を検討してください。

だそうで、設定ファイルを修正。

# AllowZoneDrifting=yes
AllowZoneDrifting=no

結果

# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2023-10-13 06:03:36 JST; 3s ago
     Docs: man:firewalld(1)
 Main PID: 29104 (firewalld)
    Tasks: 2 (limit: 23014)
   Memory: 23.9M
   CGroup: /system.slice/firewalld.service
           mq29104 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid

10月 13 06:03:35 *******.*******.********** systemd[1]: firewalld.service: Succeeded.
10月 13 06:03:35 *******.*******.********** systemd[1]: Stopped firewalld - dynamic firewall daemon.
10月 13 06:03:35 *******.*******.********** systemd[1]: Starting firewalld - dynamic firewall daemon...
10月 13 06:03:36 *******.*******.********** systemd[1]: Started firewalld - dynamic firewall daemon.


[TrueNAS]インスト

Windows11のHyper-Vにインストしてみた。

第2世代の仮想マシンでも動くけど、

  • 仮想マシンのセキュアブートOFFは必須。
    • ONでは起動できないようだ。
  • 仮想マシンのネットワークアダプターの高度な設定で、MACアドレスは「静的」に変える。
    • 動的のままでは、起動の度にIPアドレスが変わってしまう。
  • 仮想マシンの統合サービスでゲストサービスも使えるらしいのでチェックを入れる。
  • データ用のディスクが別途必要。

設定を終えて起動してみると、

自動的にダウンロードしたOSイメージからインスト。

完了したら、

再起動、

コンソールの最後にブラウザからアクセスするURLが表示される。

「システム」⇒「全般」で、ブラウザからアクセスする際のポートを変更できるのが地味に便利。

※WordPressとかWeb系アプリを入れるとか色々。

ただ、プラグインを色々インストしてみようとしたが、NATにしないとインストでエラってしまう。

難しいなぁ。



[Linux]noVNC

cockpitのコンソールがnoVNCで、できているらしい。

ブログサーバは非力過ぎて固まりかけていたので、Hyper-VにインストしたAlmaLinux9があるからインストしてみた。

コチラを参考に固有情報以外はそのまんまインストしてみた。

最初は電子証明書がうまく機能せずエラってダメだった。

systemctl enable --now vncserver@:1 vncserver@:2

だけでは無理なのかな?

systemctl start --now vncserver@:1 vncserver@:2

も追加したけどダメ。

なぜ記事にはsystemctl start コマンドが無かったのか?再起動するなら不要だけど・・・!

AlmaLinux9を再起動してnovnc_proxy を実行すると、何事もなかったかの様に接続できた。

今のvncは一度再起動後しないと都合が悪いのかな?

さて、実際にAlmaLinux9のデスクトップ画面で色々操作してみると反応はとても良い。

古いとは云えCPUはINTEL i9-9900だし32GBメモリあるし同じパソコン同士なんだから当然として

AlmaLinux9でyoutobeで動画が普通に観れるのはスゴいなぁ。

音は出ないけどね。

難点を云えば、VNCクライアントなので、

  • サーバでVNCサービスが動作していることが前提
    • 接続するサーバのユーザ毎にVNC用のパスワードを設定
    • 接続するサーバのユーザ毎にVNC用のポートを割り当てる

また、novnc_proxyもユーザ毎にポートを割り当てる必要があるから、ユーザ数分ファイアーウォールに穴をあけないといけないから、サーバー側は「ユーザ数×2倍」のポートを占有されてしまう。

その辺はxrdpの方が優しい。インストも楽だし。

あ、novnc_proxy をサービス化しないと、ラズパイ用の記事を発見。

先のnovnc_proxyをオプション付きでファイル化。

#!/bin/bash


sudo novnc_proxy --listen 6080 --cert /root/novnc.pem --vnc localhost:5901 --ssl-only

パーミッションは777。

これを呼び出すサービスの設定ファイルを作る。

[Unit]
Description=Run vnc and novnc

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/フルパス名でnovnc.sh
ExecStop=sudo vncserver -kill :1 && killall websockify
Restart=always
RestartSec=10
SELinuxContext=system_u:system_r:novnc_session_t:s0

[Install]
WantedBy=multi-user.target

パーミッションは777。

他のサービスは皆リンクファイルなので、

/usr/lib/systemd/system/novnc@.service

として作成した方がいいのかもしれない。

でもとりあえずstartできるけど

SE Linuxが有効だとダメ。

# chcon -t usr_t novnc.sh

やってみると一瞬動いたものの、再び起動しようとすると失敗。

ポリシーを変更してnovns.shを実行できるようにすればいいのだろうけど、メンドクサイのでパス!



[Linux]Cockpit Web コンソール

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%まで上がりその後1%未満になるので、そう悪くない。

この「端末」で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側のブリッジを作り直したり

ポートは、enp系のみチェックする。vnetxxは仮想マシン起動すると自動的にチェックが入るので不要。

何気にゲスト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(環境によりマチマチな名)を見ると

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

あと、

br0ばかり使えば良いけど、br1とか作ってもなかなか出てこないのは不便

この辺は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. 【実行】

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



[blog]激重

データベースエラーが出ていた。

原因はブログ用のゲストOSがヘタれ、コマンドプロンプトでコマンドを打つと10秒くらい応答が無かったので、タイムアウトチェックに引っかかるものは全てエラってるっぽい。

rebootやpoweroffコマンドは通るもののシャットダウンする気配が無い。

ホスト側は特に異常は見当たらない。

virt-topでゲストOSの負荷を見ても、CPU:0.5%しかない。

仕方なくホスト側を再起動。

apacheの設定を見直してみると前のDDNSのドメインのままになっている箇所を発見。

コレのせいかな?

てか何で普通に観れてたんだろう???

とりあえず、バックアップを取っておこう。圧縮しても4GB越え。

WinSCPでコピると6分以上かかる。

とても古い圧縮方式arcfourの優先度を最上位にしてもほとんど差が無かった。

サーバ側が古すぎなのは未サポートになってた様な気もする。

当然、同時接続数をq2から9に上げても変わらず。

やっぱりCPUか。J1900だもんなぁ。



[Hyper-V]The unsigned image’s hash is not allowed

Hyper-Vで第2世代を選択するとUEFIが使えるし、Hyper-VマネージャからのシャットダウンもOK

LinuxのVMを作成して起動すると

暫くまたされた後にUEFIで

The unsigned image’s hash is not allowed

と出て起動に失敗する。

要はセキュアブートの初期設定がWindow用だったダケだった。

セキュアブートを変更

とすると、無事起動できた。

VMを作る時に設定できれば困らないのに・・・




top