SSブログ
前の10件 | -

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 の設定値を変更する。
・停止処理でのタイムアウトまでの時間が変更される。



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

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



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

Debian 11のカーネルのバージョンアップ [Debian]

Debian 10.10 からアップグレードを行った Debian 11.0 において、カーネルのバージョンアップを行った。
(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


nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

Debian 11への追加対応 [Debian]

先日 Debian 11.0 へのアップグレードを行った環境に、追加の対応を行った。
これで、アップグレード前の 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)



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

Debian 11へのアップグレード後の不要パッケージの削除 [Debian]

Debian 11 へのアップグレードにより、不要なパッケージが多数発生した。

・'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 パッケージを再インストール



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

Debian 11へのアップグレード後の問題点への対応 [Debian]

先日、Debian 10.10 から Debian 11.0 へのアップグレードを行った。
致命的なエラーは発生しなかったが、数個のパッケージで問題が発生した。
以下は、上記の発生事象と対処方法をまとめたものである。

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



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

Debian 11へのアップグレード [Debian]

Debian 10.10 (buster) から Debian 11.0 (bullseye) へのアップグレードを行った。
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 … 一部の機能が正常に機能しない

(備考)
対応方法について、現在調査中。



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

Rocky Linux 8.4の最小インストール [Linux]

Rocky Linux 8.4 について、KVM 上の VM へのインストールを行った。
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


nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

GmailのPOPサーバーにおいて、メールの存在を認識できないことがある [Linux]

1. 発生事象


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 回目の確認時まで保持する。



nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

CentOS 8でのネットワークの自動起動 [CentOS]

CentOS 8 に久しぶりにログインしたところ、ネットワークが有効にならなかった。
原因は、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


nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット
前の10件 | -