clamav-daemon.service の停止処理に想定外の時間を要する [Debian]
・clamav-daemon 0.103.3+dfsg-0+deb11u1 (on Debian 11)
1. 発生事象
clamav-daemon.service の停止処理に想定外の時間を要する。
・shutdown 時に、度々発生する。
・90 秒(systemd のタイムアウトのデフォルト値) の待ち時間が発生する。
・clamdscan が実行中か否かに関係なく発生する。
(補足)
・Debian 10 (clamav-daemon 0.103.3+dfsg-0+deb10u1) でも同様の問題が発生する。
・CentOS 7 (clamd-0.103.3-5.el7.x86_64) では発生しない。
2. 対処方法
clamav-daemon.service の停止時のタイムアウト時間を短縮する。
このため、/lib/systemd/system/clamav-daemon.service を編集する。
# diff clamav-daemon.service clamav-daemon.service.org 14d13 < TimeoutStopSec=30
・[Service] 欄の TimeoutStopSec の設定値を変更する。
・停止処理でのタイムアウトまでの時間が変更される。
Windows 10の更新プログラムの構成に失敗することへの対応 [Windows]
・Linux と Windows のマルチブートを行っている。
・Linux の GRUB から Windows 10 (20H2) を起動している。
MBR に インストールした GRUB からチェインロードを行っている。
・普段は、Windows 10 の Windows Update を無効化している。
Windows Update Blocker をいうソフトを使用し、有効/無効を選択している。
・必要時に応じて、Windows Update を有効化し、更新プログラムを適用している。
1. 発生事象
Windows 10 20H2 への KB5005565 の適用で、更新プログラムの構成に失敗する。
[エラー・メッセージ] 更新プログラムの構成に失敗しました
・トラブルシューティング・ツールを実行しても、状況は変わらない。
・クリーン・ブート後に Windows Update を実行しても、状況は変わらない。
2. 対処方法
一時的に、MBR に Windows のブートローダーをインストールすることで改善される。
(1) Windows のブートローダーのインストール
今回は、手近にあった Windows 7 のインストール・ディスクを使用した。
(a) Windows 7 のインストール・ディスクでブートする。
(b) [Windows のインストール] で [次へ] を選択する。
(c) [コンピューターを修復する] を選択する。
(d) [システム回復オプション] 画面で、[次へ] を選択する。
・[Windows の起動に伴う問題の回復用の回復ツールを使用...] の方を選択
・[次へ] を選択
・[コマンド・プロンプト] を選択し、下記のコマンドを実行する。
X:\Sources> diskpart DISKPART> list disk DISKPART> select disk 0 DISKPART> list part DISKPART> select part 1 DISKPART> active DISKPART> exit bootrec /fixmbr exit
(e) ブート用 DVD を取り出し、リブートする。
(2) Windows Update の実行
更新プログラムの構成に失敗しなくなる。
(3) GRUB の再インストール
・GRUB shell 等から Linux を起動する。
・MBR へ GRUB をインストールする。
3. 備考
Windows 10 21H1 への更新についても、同様と思われる。
・更新アシスタントで Windows 10 21H1 への更新を行ったところ、エラーが発生した。
対象とする環境かどうかの判断ができない旨のメッセージが表示された。
・上記の対応後に実施すると、特に問題は発生しなかった。
Windows のブートローダーがイストールされている状態で実施したためと思われる。
また、Windows 7 から Windows 10 (20H2) へのアップグレードでも同様と思われる。
・当初、対象とする環境かどうかの判断ができない旨のメッセージが表示された。
・Windows 10 の評価版のインストールおよび削除後に、再実行すると正常終了した。
cf. https://dan-project.blog.ss-blog.jp/2021-05-29-1
Debian 11のカーネルのバージョンアップ [Debian]
(3.16.0-4-686-pae → 5.10.0-8-686-pae)
1. 実施した理由
カーネルのバージョンが Debian 10.10 と同じことに気付き、確認してみると、カーネルのバージョンアップが行われていなかった。
更新パッケージの適用を定期的に行っているが、何故かカーネルは古いバージョンのままであった。
・Debian 10.10 において、このような状況であった。
・以前は、カーネルのバージョンアップも問題なくできていた。
2. 得られた効果
今回のカーネルのバージョンアップにより、下記の問題が解決できた。
・iptables 1.8.7-1 の起動エラー … (注1)
・apache2 2.4.48 の起動エラー … (注1)
・e2scrub_reap.service (e2fsprogs 1.46.2-2) の起動エラー … (注2)
(注1)
cf. https://dan-project.blog.ss-blog.jp/2021-09-08
(注2)
cf. https://dan-project.blog.ss-blog.jp/2021-09-10
3. 実施手順
今回実施した手順は、以下の通りである。
(1) カーネルのバージョンアップ
[パッケージの更新] # apt-get install linux-image-5.10.0-8-686-pae-unsigned [システムの再起動] # shutdown -r now
(2) apahce のバージョンアップ
# apt-get install libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap # apt-get install apache2 apache2-bin apache2-data apache2-utils
(3) iptables のバージョンアップ
# apt-get install iptables libiptc0 libxtables12
(4) 古いカーネル、不要なパッケージの削除
# dpkg --purge linux-image-3.16.0-4-686-pae # apt-get clean # apt-get autoclean # apt-get autoremove
(5) apparmor の無効化
[サービスの停止] # systemctl stop apparmor # systemctl disable apparmor [システムの再起動] # shutdown -r now [パッケージの削除] … パッケージを削除する場合 # dpkg --purge apparmor
Debian 11への追加対応 [Debian]
これで、アップグレード前の Debian 10.10 と同程度に使用できる状態となったと思われる。
1. 追加対応
1-1. ブート時の e2scrub_reap.service のエラー
(1) 発生事象
(a) エラーメッセージ
Failed to Start Remove Stale Online ext4 Metadata Check Snapshots. see 'systemctl status e2scrub_reap.service' for details.
(b) ブート後の当該サービスの状態
# systemctl status e2scrub_reap.service
* e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; \
vendor preset: enabled)
Active: failed (Result: exit-code) ...
Docs: man:e2scrub_all(8)
Process: 833 ExecStart=/sbin/e2scrub_all -A -r (code=exited, \
status=218/CAPABILITIES)
Main PID: 833 (code=exited, status=218/CAPABILITIES)
...
# systemctl is-enabled e2scrub_reap.service
enabled
(c) ブート後のサービスの再起動の結果
# systemctl restart e2scrub_reap.service Job for e2scrub_reap.service failed because the control process exited \ with error code. See "systemctl status e2scrub_reap.service" and "journalctl -xe" for \ details.
(2) 対処方法
取り敢えず、当該サービスの自動起動を無効化する。
# systemctl stop e2scrub_reap.service # systemctl disable e2scrub_reap.service
1-2. journald の永続的なジャーナル機能の有効化
(1) 発生事象
journald の永続的なジャーナル機能が有効となる。
(ディスク上の /var/log/journal/ への出力となる。)
(2) 対処方法
無効化するには、下記の手順により、/var/log/journal/ を削除する。
(a) サービスの停止
# systemctl stop systemd-journald.service # systemctl stop systemd-journald.socket
(b) ディレクトリの削除
# rm -fr /var/log/journal
(c) サービスの開始
# systemctl start systemd-journald.socket # systemctl start systemd-journald.service
(補足)
原因は、/var/log/journal/ が存在するためである。
・Debian 11.0 へのアップグレード時に作成されたものと思われる。
・journald の初期設定では、/var/log/journal/ の有無により出力先が変わる。
存在する場合: ディスク(/var/log/jounal/)へ出力
存在しない場合: RAM ディスク(/run/log/journal/)へ出力
1-3. Wireshark の起動エラー
(1) 発生事象
[エラーメッセージ] wireshark: error while loading shared libraries: libQt5Core.so.5: \ cannot open shared object file: No such file or directory
・Wireshark のバージョン: wireshark-qt 3.4.4-1
・該当するライブラリは存在する。
# find /usr/lib -name libQt5Core.so\* /usr/lib/i386-linux-gnu/libQt5Core.so.5.15.2 /usr/lib/i386-linux-gnu/libQt5Core.so.5 … libQt5Core.so.5.15.2 へのリンク /usr/lib/i386-linux-gnu/libQt5Core.so.5.15 … libQt5Core.so.5.15.2 へのリンク
(2) 対処方法
該当するライブラリから、余分な情報を削除する。
# /usr/lib/i386-linux-gnu # cp -p libQt5Core.so.5.15.2 libQt5Core.so.5.15.2.org # strip --remove-section=.note.ABI-tag libQt5Core.so.5.15.2
'for GNU/Linux 3.17.0' という部分が問題の原因とのこと。
(cf. https://myn.meganecco.org/1562249040.html)
# file libQt5Core.so.5.15.2.org libQt5Core.so.5.15.2.org: ELF 32-bit LSB shared object, Intel 80386, \ version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, \ BuildID[sha1]=b682831b8118e8378863be17f9e45a8cd6c66e31, \ for GNU/Linux 3.17.0, stripped # file libQt5Core.so.5.15.2 libQt5Core.so.5.15.2: ELF 32-bit LSB shared object, Intel 80386, \ version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, \ BuildID[sha1]=b682831b8118e8378863be17f9e45a8cd6c66e31, stripped
2. 備考
(1) インストール済のパッケージ数の増減
・Debian 10.10: 1579
・Debian 11.0: 1603 (+24)
(2) ディスクの使用量の増減
・Debian 10.10: 約 3.6GB を使用
・Debian 11.0: 約 3.8GB を使用 (+200MB)
Debian 11へのアップグレード後の不要パッケージの削除 [Debian]
・'apt-get autoremove' で、多数のパッケージが削除対象となる。
・必要なパッケージが削除対象に含まれている。
・対象とする環境は、これまでにアップグレードを繰り返してきた環境である。
このため、この機会に、パッケージ毎に削除の有無を検討し、対応することにした。
1. 手順
(1) 'apt-get autoremove' で削除対象のパッケージの一覧を取得
削除開始時の確認に対して、No を回答し、パッケージを削除しない。
(2) 該当するパッケージについての削除の有無を検討
(3) パッケージの削除には、'dpkg --purge <package name>' を使用
2. 手順の実施
(1) 1 回目
bsdmainutils * cpp-8 ... cpp-10 が存在する distro-info-data javascript-common * libapt-inst2.0 ... libapt-pkg5.0 の被依存パッケージ * libapt-pkg5.0 ... libapt-pkg6.0:i386 が存在 * libasan5 ... libasan6:i386 が存在 libayatana-appindicator3-1 libayatana-ido3-0.4-0 libayatana-indicator3-7 libbind9-161 libboost-python1.67.0 * libcdio18 ... libcdio19:i386 が存在 * libcodec2-0.8.1 ... libcodec2-0.9:i386 が存在 libcroco3 libcrystalhd3 libcupsfilters1 libcupsimage2 libdbusmenu-glib4 libdbusmenu-gtk3-4 * libdns1104 ... libdns1110:i386 が存在 libdns1110 * libevent-2.1-6 ... libevent-2.1-7:i386 が存在 * libexiv2-14 ... libexiv2-27:i386 が存在 * libfluidsynth1 ... libfluidsynth2:i386 が存在 * libgssdp-1.0-3 ... libgssdp-1.2-0:i386 が存在 * libgupnp-1.0-4 ... libgupnp-1.2-0:i386 が存在 * libhogweed4 ... libnettle6 の被依存パッケージ * libicu63 ... libicu67:i386 が存在 * libilmbase23 ... libilmbase25:i386 が存在 * libip4tc0 ... libip4tc2:i386 が存在 * libip6tc0 ... libip6tc2:i386 が存在 libiptc0 libirs161 * libisc1100 ... libisc1105:i386 が存在 libisc1105 libisccc161 libisccfg163 * libisl19 ... libisl23:i386 が存在 libjs-jquery libjs-sphinxdoc libjs-underscore * libjson-c3 ... libjson-c5:i386 が存在 * libjte1 ... libjte2:i386 が存在 libkyotocabinet16v5 * libllvm7 ... libllvm11:i386 が存在 liblwres161 * libmpdec2 ... libmpdec3:i386 が存在 libmpx2 * libmysofa0 ... libmysofa1:i386 が存在 * libnettle6 ... libnettle8:i386 が存在 * libnfs12 ... libnfs13:i386 が存在 * libnftables0 ... libnftables1:i386 が存在 liboauth0 * libopenexr23 ... libopenexr25:i386 が存在 * libperl5.28 ... libperl5.32:i386 が存在 * libpgm-5.2-0 ... libpgm-5.3-0:i386 が存在 * libpoppler82 ... libpoppler102:i386 が存在 * libprocps7 ... libprocps8:i386 が存在 * libpython2.7 ... libpython3.9:i386 が存在 * libpython3.7-minimal ... libpython3.9-minimal:i386 が存在 * libpython3.7-stdlib ... libpython3.9-stdlib:i386 が存在 * librpm8 ... librpm9 が存在 * librpmbuild8 ... librpmbuild9 が存在 * librpmio8 ... librpmio9 が存在 * librpmsign8 ... librpmsign9 が存在 * libsnmp30 ... libsnmp40:i386 が存在 * libssl1.0.2 ... libssl1.1:i386 が存在 libtagc0 * libusbmuxd4 ... libusbmuxd6:i386 が存在 * libvpx5 ... libvpx6:i386 が存在 * libwireshark11 ... libwireshark14:i386 が存在 * libwiretap8 ... libwiretap11:i386 が存在 * libwscodecs2 ... libwsutil9 の被依存パッケージ * libwsutil9 ... libwsutil12:i386 が存在 * libx264-155 ... libx264-160:i386 が存在 * libx265-165 ... libx265-192:i386 が存在 libxapian30 * libxcb-util0 ... libxcb-util1:i386 が存在 libxcb-xf86dri0 lsb-release * perl-modules-5.28 ... perl-modules-5.32 が存在 python-six * python3.7-minimal ... python3.9-minimal が存在 sgml-base x11proto-input-dev x11proto-kb-dev
・'apt-get autoremove' で削除対象となるパッケージの数: 87
・行頭に * を付けたパッケージを削除する。
(2) 2 回目
bsdmainutils distro-info-data javascript-common libayatana-appindicator3-1 libayatana-ido3-0.4-0 libayatana-indicator3-7 libbind9-161 libboost-python1.67.0 libcroco3 libcrystalhd3 libcupsfilters1 ... printing libcupsimage2 ... printing libdbusmenu-glib4 libdbusmenu-gtk3-4 libdns1110 libiptc0 libirs161 libisc1105 libisccc161 libisccfg163 libjs-jquery libjs-sphinxdoc libjs-underscore libkyotocabinet16v5 liblwres161 libmpx2 liboauth0 libtagc0 libxapian30 libxcb-xf86dri0 ! lsb-release python-six sgml-base x11proto-input-dev ... dummy package (only doc) x11proto-kb-dev ... dummy package (only doc)
・apt-get autoremove で削除対象となるパッケージの数: 35
・'apt-get autoremove' を実行する(削除対象のパッケージが削除される)。
・行頭に ! を付けたパッケージについては、後で再インストールする。
3. 実施結果の検証
今回は、下記の手順を実施した場合と同じ結果となった。
・'apt-get autoremove' の実行
・アンインストールされた lsb-release パッケージを再インストール
Debian 11へのアップグレード後の問題点への対応 [Debian]
致命的なエラーは発生しなかったが、数個のパッケージで問題が発生した。
以下は、上記の発生事象と対処方法をまとめたものである。
1. Emacs 27.1 の起動エラー
(1) 発生事象
Emacs 27.1 の起動時にエラが発生する。
このため、~/.emacs に設定している '(shell)' が実行されない。
[エラーメッセージ] Symbol's function definition is void: process-kill-without-query To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the '--debug-init' option to view a complete error backtrace.
(2) 対処方法
~/.emacs に、下記の設定を追加する。
;; add function (Emacs-27 or later)
(when (>= emacs-major-version 27)
(defun process-kill-without-query (process &optional flag)
(set-process-query-on-exit-flag process nil)
t))
(補足)
obsolete になっていた関数が、本バージョンで削除されたとのこと。
(cf. https://twitter.com/shg/status/1295166707594452993)
2. iptables 1.8.7-1 の起動エラー
(1) 発生事象
iptables の起動時にエラーが発生する。
[エラーメッセージ] iptables v1.8.7 (nf_tables): Could not fetch rule set generation id: \ Invalid argument
(2) 対処方法
Debian 10 の iptables 1.8.2 にバージョンダウンする。
(a) パッケージのダウンロード
iptables_1.8.2-4_i386.deb libip4tc0_1.8.2-4_i386.deb libip6tc0_1.8.2-4_i386.deb libiptc0_1.8.2-4_i386.deb libxtables12_1.8.2-4_i386.deb
・https://packages.debian.org/ja/ にアクセス
・[パッケージディレクトリを検索] の Distribution: で buster を選択
・キーワードにパッケージ名を入力し、検索を実行
・検索されたパッケージをダウンロードし、/tmp/iptables-1.8.2/ に保存
(b) パッケージのバージョンダウン
# cd /tmp/iptables-1.8.2 # dpkg -i *.deb
3. Apache 2.4.48 の起動エラー
(1) 発生事象
Apache の起動時にエラーが発生する。
[エラーメッセージ] Function not implemented: AH00141: Could not initialize random number \ generator
(2) 対処方法
Debian 10 の Apache 2.4.38 にバージョンダウンする。
(a) パッケージのダウンロード
apache2-bin_2.4.38-3+deb10u5_i386.deb apache2-data_2.4.38-3+deb10u5_all.deb apache2-utils_2.4.38-3+deb10u5_i386.deb apache2_2.4.38-3+deb10u5_i386.deb libapr1_1.6.5-1+b1_i386.deb libaprutil1-dbd-sqlite3_1.6.1-4_i386.deb libaprutil1-ldap_1.6.1-4_i386.deb libaprutil1_1.6.1-4_i386.deb
・http://packages.debian.org/ja/ の [パッケージディレクトリを検索] を使用
・検索されたパッケージをダウンロードし、/tmp/apache-2.4.38/ に保存
(b) パッケージのバージョンダウン
# cd /tmp/apache-2.4.38 # dpkg -i *.deb
4. halt-local.service が機能しない
(1) 発生事象
/lib/systemd/system/halt-local.service が機能しない。
このため、shutdown 時に /usr/sbin/halt.local が実行されない。
(補足)
・パッケージのバージョン: systemd 247.3-6
・halt-local.service の状態には問題はない。
# systemctl status halt-local.service
* halt-local.service - /usr/sbin/halt.local Compatibility
Loaded: loaded (/lib/systemd/system/halt-local.service; static)
Active: inactive (dead)
・同じ Unit ファイルを使用している Debian 10、CentOS 7 では、正常に機能する。
(2) 対処方法
取り敢えずは、下記の手順を実施する。
(a) /lib/systemd/system/halt-local.service の編集
# diff halt-local.service halt-local.service.org 21,23d20 < < [Install] < WantedBy=shutdown.target
(b) 変更内容の反映
# systemctl enable halt-local.service
・/etc/systemd/system/shutdown.target.wants/halt-local.server が作成される。
(/lib/systemd/system/halt-local.service へのシンボリック・リンク)
・systemctl is-enabled halt-local の実行結果が変わる。
(新) enabled
(旧) static
Debian 11へのアップグレード [Debian]
3 個のパッケージで実行時のエラーが発生したが、致命的なエラーは発生しなかった。
詳細は、以下の通りである。
・参考資料
https://www.debian.org/releases/bullseye/i386/release-notes/ch-upgrading.ja.html
1. アップグレードの前処理
(1) buster の最新パッケージへのアップデート
インストールされているパッケージを最新版にアップデートする。
(2) エラー状態にあるパッケージの確認
(a) 状態確認
# dpkg --audit
下記の状態のパッケージに関する情報が出力される。
・インストールが未完了のパッケージ (Half-Installed)
・設定に失敗したパッケージ (Failed-Config)
・何らかのエラー状態にあるパッケージ
(b) 対応
可能な限り問題の解決を行う。
問題が解決できない場合には、アンインストールを検討する。
(3) hold 状態にあるパッケージの確認
(a) 状態確認
# apt-mark showhold
該当するパッケージに関する情報が出力される。
(b) 対応
アップデートしたいパッケージは、hold 状態を解除する。
アップデートから除外したいパッケージは、hold 状態にする。
(hold の設定の場合) # apt-mark hold <pkg_name> (hold の解除の場合) # apt-mark unhold <pkg_name>
(4) apt のキャッシュの削除
# apt-get clean # apt-get autoclean
(5) システムのバックアップ
アップグレードが失敗した場合のために、システム・バックアップを行う。
2. アップグレード
2-1. リポジトリの変更
(1) /etc/apt/sources.list の編集
(a) buster を bullseye に変更する。
# cp -p sources.list sources.list.sav # sed 's/buster/bullseye/g' sources.list.sav > sources.list
(b) securiry update の設定方法が変更されてため、これに対応する。
(変更前) deb http://security.debian.org/ buster/updates main contrib non-free deb-src http://security.debian.org/ buster/updates \ main contrib non-free (変更後) deb http://security.debian.org/debian-security bullseye-security \ main contrib non-free deb-src http://security.debian.org/debian-security bullseye-security \ main contrib non-free
cf. https://www.debian.org/releases/stable/errata
(2) /etc/apt/sources.list の編集内容の反映
# apt-get update
2-2. 最小アップグレード
(1) 必要なディスク容量の確認
# apt-get -o APT::Get::Trivial-Only=true dist-upgrade
・/var/cache/apt/archives/ に必要なディスク容量が出力される。
・必要な領域がない場合には、その旨のメッセージが出力される。
(2) インストールされているパッケージの最小アップデート
# apt-get upgrade | tee /work/upgrade.log または # apt upgrade --without-new-pkgs | tee /work/upgrade.log
・他のパッケージのインストール/削除が不要なパッケージのみが対象となる。
・設定変更の可否の確認に対しては、現在の設定を使用する方を回答する。
2-3. 完全アップグレード
# apt-get dist-upgrade | tee /work/dist-upgrade.log または # apt full-upgrade | tee /work/dist-upgrade.log
・システムの完全なアップグレードが行われる。
・設定変更の可否の確認に対しては、現在の設定を使用する方を回答する。
3. アップグレード後の処理
(1) apt のキャッシュの削除
# apt-get clean # apt-get autoclean
(2) システムのバックアップ
アップグレード直後のシステム・バックアップを行う。
(3) 不要となったパッケージの削除
下記の理由から、ここでは 'apt-get autoremove' を実行しない。
・'apt-get autoremove' で削除対象となるパッケージが多数ある。
・削除対象には、必要と思われるパッケージが含まれている。
削除対象となるパッケージの一覧のみを取得し、削除の有無は後程検討する。
(4) 設定ファイルの更新
# find /etc -name \*-dist # find /etc -name \*-new # find /etc -name \*-old
・/etc 以下の *-{dist,new,old} ファイルで必要なもの採用する。
・/etc/logrotate.d/ では、上記ファイルの存在が問題となる。
(5) apt のキャッシュの削除
# apt-get clean # apt-get autoclean
(6) 再起動
# shutdown -r now
4. 備考
(1) インストール済のパッケージ数の増減
・Debian 10.10: 1579
・Debian 11.0: 1690 (+111)
(2) 実行時にエラーを発生するパッケージ
・Apache 2.4.48 … 異常終了
・iptables 1.8.7 … 異常終了
・Emacs 27.1 … 一部の機能が正常に機能しない
(備考)
対応方法について、現在調査中。
Rocky Linux 8.4の最小インストール [Linux]
CentOS から Rocky Linux へ移行するための準備である。
当初は boot.iso を使用する予定であったが、メタデータのダウンロードがなかなか終了しない状態となってしまい、取り敢えずは minimal.iso を使用してインストールを行った。
その後、状況が改善したため、boot.iso でのインストールを行った。
このため、2 種類の iso を使用したインストールで構築される環境についての比較を行った。
詳細は、以下の通りである。
(手順的には、CentOS 8.3 の場合と同じである。)
1. インストールで使用する iso ファイルのダウンロード
Rocky-8.4-x86_64-boot.iso
または
Rocky-8.4-x86_64-minimal.iso
2. インストーラーの起動
KVM の機能を使用して、インストーラーを起動する。
(1) ディスク・イメージの作成
(例) # qemu-img create -f qcow2 /var/lib/libvirt/images/rocky-8_1.qcow2 6.0G
(2) VM の作成とインストーラーの起動
(例) # virt-install --virt-type kvm \ --name rocky-8_1 --vcpus 1 --memory 1024 \ --disk path=/var/lib/libvirt/images/rocky-8_1.qcow2 \ --cdrom /shared_tmp/iso/rocky-linux/Rocky-8.4-x86_64-boot.iso
下記のメッセージが出力されるまで待ち、virt-manager を起動する。
Starting install... Domain installation still in progress. Waiting for installation to \ complete.
(3) virt-manager の起動
# virt-manager
(4) 作成された VM への接続
該当する VM を右クリックし、[Open] を選択する。
3. インストールの実施
3-1. 言語の選択
・[日本語] を選択する。
・[続行] を選択する。
3-2. インストール方法の選択とインストールの開始
(1) ネットワークとホスト名の設定
・[全般] タブで、[優先的に自動接続する] を選択する。
・[IPv6] タブで、[無効] の選択、または適当な設定を行う。
・[IPv4] タブで、IPアドレス、GW、DNS サーバー、ホスト名を設定する。
・[IPv4] タブで、右側上部の [オン] を選択し、[接続済み] 状態にする。
(補足)
boot.iso の場合、メタデータのダウンロードが開始される。
(2) 時刻と日付の設定
・[アジア/東京] を選択する。
・右側上部の [ネットワーク時刻] で [オン] を選択する。
(補足)
boot.iso の場合、初期値でのメタデータのダウンロードがエラー終了する。
これにより、インストールソースの設定変更が可能となる。
(3) root パスワードの設定
(4) インストールソースの設定
boot.iso の場合、下記の内容でインストールソースを設定する。
・[ネットワーク上] を選択
・[ftp://ftp.riken.jp/Linux/rocky/8.4/BaseOS/x86_64/os/] を指定
(5) KDUMP の無効化
[kdump を有効にする] を選択しない。
(6) インストール先の設定
ストレージの設定で [自動構成] が選択されていることを確認する。
(7) ソフトウェアの選択
[最小限のインストール] を選択する。
(8) インストールの開始
・右下の [インストールの開始] を選択する。
・インストールの終了後、右下の [システムの再起動] を選択する。
4. 備考
(1) 使用する iso ファイルによるインストール・パッケージの違い
・Rocky-8.4-x86_64-boot.iso (720MB)
・Rocky-8.4-x86_64-minimal.iso (1.9GB)
minimal.log の場合、logrotate、rsyslog がインストールされない。
上記パッケージの追加とパッケージの更新後の比較結果は、以下の通りである。
# diff pkg_list_mininal.log pkg_list_boot.log > geolite2-city-20180605-1.el8.noarch > geolite2-country-20180605-1.el8.noarch < glibc-all-langpacks-2.28-151.el8.x86_64 > glibc-langpack-ja-2.28-151.el8.x86_64 > langpacks-ja-1.0-12.el8.noarch > libestr-0.1.10-1.el8.x86_64 > libevent-2.1.8-5.el8.x86_64 > libfastjson-0.99.8-2.el8.x86_64 > libmaxminddb-1.2.0-10.el8.x86_64 > libsecret-0.18.6-1.el8.x86_64 > libxkbcommon-0.9.1-1.el8.x86_64 > pinentry-1.1.0-2.el8.x86_64 > plymouth-0.9.4-9.20200615git1e36e30.el8.x86_64 > plymouth-core-libs-0.9.4-9.20200615git1e36e30.el8.x86_64 > plymouth-scripts-0.9.4-9.20200615git1e36e30.el8.x86_64 > python3-unbound-1.7.3-15.el8.x86_64
GmailのPOPサーバーにおいて、メールの存在を認識できないことがある [Linux]
Gmail の POP サーバーにおいて、メールの存在を正しく認識できないことがある。
このため、クライアント側での既読情報の管理には工夫が必要である。
(例) (1) 時刻 X + 0 分の確認結果: 3 通のメールが存在 この時点でのクライアントの管理情報を下記のようにする。 ・未読のメール数/メールの総数: 3/3 その後、すべてのメールを参照し、クライアントの管理情報を下記のようにする。 ・未読のメール数/メールの総数: 0/3 (2) 時刻 X + 10 分の確認結果: メールなし ← 実際には 3 通のメールが存在 メールが存在しないため、既読メールに関する情報が初期化される。 よって、クライアントの管理情報は下記のようになる。 ・未読のメール数/メールの総数: 0/0 ← 正しくは 0/3 (3) 時刻 X + 20 分の確認結果: 3 通のメールが存在 3 通を新規メールと判断し、クライアントの管理情報は下記のようになる ・未読のメール数/メールの総数: 3/3 ← 正しくは 0/3 (4) メールの存在が認識される場合には、メールの UID は正しい値が得られる。
・メールが存在する場合に、メールなしと回答されることがある。
・発生頻度は低い。
2021-08 の上旬に数回発生した。
・少し時間をあけ再実行すると、正しい結果が得られる。
現在、10 分毎に確認を行っている。
・現時点では、Gmail 以外の POP サーバーでは発生していない。
・存在確認には、Perl の Mail::POP3Client.pm を使用したスクリプトを使用している。
2. 対処方法
上記のスクリプトに、下記の機能を追加する。
(1) クライアント側で既読情報を一定の期間保持する。
(変更前)
サーバー上で存在が確認されたメールの既読情報しか保持しない。
(変更後)
一度作成した既読情報は、メールなしと判断された後も一定期間保持する。
・例えば、メールなしと判断された後の 3 回目の確認時まで保持する。
CentOS 8でのネットワークの自動起動 [CentOS]
原因は、Network Manager の自動起動を無効化していたためである。
(環境構築の最後に、Network Manager の自動起動を無効化していた。)
CentOS 8 では、Network Manager を起動しないと、ネットワークが有効にならない。 (CentOS 7 では、このようなことは発生しない。)
Network Manager は余分なことをしようするため、個人的には使用したくない機能である。
以下は、CentOS 8 において、Network Manager を使用しない場合の設定に関する情報である。
1. 発生事象
CentOS 8 では、Network Manager を起動しないと、ネットワークが有効にならない。
2. 対処方法
下記のいずれかの手順を実施する。
(1) Network Manager を使用しない場合
(a) 下記のパッケージの追加を行う。
・network-scripts.x86_64 ・net-tools.x86_64 … ifconfig 等のコマンドを使用する場合
パッケージの依存関係により、下記のパッケージがインストールされる。
・network-scripts-team.x86_64
・bc.x86_64
(b) network.service を起動する。
# systemctl enable network # systamctl start network
(2) Network Manager を使用する場合
(a) Network Manager による /etc/resolv.conf の更新を無効化する。
/etc/NetworkManager/NetworkManager.conf に下記の設定を追加する。
[main] dns=none
(b) Network Manager を起動する。
# systemctl enable NetworkManager # systemctl start NetworkManager
dandy さん
-
nice! 240
記事 385
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
