vCenter Converter のダウンロードは停止している

vCenter Converterのダウンロード情報を求めて検索すると当BlogもHITするようで、
過去に書いた下記の記事がHITする模様。
shobon.hatenablog.com



が、残念ながら、今年の2月に次のようなアナウンスがされており、ダウンロードが停止しています。
blogs.vmware.com


最後の一文を見ると、タイムラインは決まっていないものの、新しいバージョンに取り組んでいるようなので、暫く待つしかなさそう。

エラーページでJettyのバージョンを非表示にする

【環境】
・Jetty 9.4/10.0
ソースコード版(dnf 等でインストールするものではない)
Apacheのmod_proxyでJettyと連携


Jettyを扱う機会があった際、エラーページのバージョン表示が気になった。

404なページへアクセスした際、次のような画面が表示される。

下部に「Powered By」でバージョンが表示されるので、これを非表示にする方法を調べた。

Jetty 9.4の場合

${JETTY_HOME}/etc/jetty.xml を次のように修正する。

<Set name="sendServerVersion"><Property name="jetty.httpConfig.sendServerVersion" deprecated="jetty.send.server.version" default="true" /></Set>
   ↓
<Set name="sendServerVersion"><Property name="jetty.httpConfig.sendServerVersion" deprecated="jetty.send.server.version" default="false" /></Set>

Jetty 10.0の場合

${JETTY_HOME}/etc/jetty.xml を次のように修正する。

<Set name="sendServerVersion" property="jetty.httpConfig.sendServerVersion"/>
   ↓
<Set name="sendServerVersion"><Property name="jetty.httpConfig.sendServerVersion" default="false"/></Set>

10.0の場合は、9.4より設定が面倒。
近くにある 「jetty.httpConfig.sendDateHeader」の設定を参考に、「Property」を追加する。


いずれの場合も、設定変更後はサービスを再起動する。
(※systemctl で制御できる場合のコマンド例)

# systemctl restart jetty.service


なお、上記を変更すると、HTMLタグに表示されていたバージョンのほか、httpdヘッダに出力されていた

Server: Jetty(10.0.11)

の情報も出力されなくなる。


Jettyのバージョンは消えるが、標準では以下のようなヘッダが出力される(AlmaLinux、httpsの場合)。

Server: Apache/2.4.37 (AlmaLinux) OpenSSL/1.1.1k

こちらは、httpdの設定で「ServerTokens Prod」を指定すれば、バージョン情報等は削除され、

Server: Apache

となる。

SourceTreeでGitを更新したらエラーになった

Windows版のSourceTreeでGitのバージョンを更新したら、Gitのエラーが出た。


'git log' がコード128で終了しました: fatal; unsafe repository
(xxxxxxxxx is owned by someone else)

To add an exception for this directory, call:

git config --global --add safe.directory

エラーの最後の部分には、NASのパスが書いてあった。

これは、git 2.35.2から実装されたセキュリティ対策が影響しているらしく、
NAS上のGitリポジトリは「unsafe repository」ということらしい。

LANにある自分専用のNASなので、許可ディレクトリに追加して対処。

WindowsのSourceTreeなので、%UserProfile%\.gitconfig へ以下を追記した。

[safe]
        directory = 許可したいpath

Firefox98以降でPDF等をダウンロードせず開いた場合の挙動を従来に戻す

少し前の話になるけど、Firefox98でファイル(PDF等)を開いた場合の挙動が変わっていた話。
PDFをFirefoxの内部ビューワではなく、Acrobatなどで開いていると影響を受ける。


Firefox 97までは、
ファイルを開く場合はテンポラリフォルダに保存され、Firefoxを終了したらファイルが削除されていた。

Firefox 98からは、
ファイルを開く場合もダウンロードフォルダにファイルが保存されるようになった。


動作が変わった事を知らず、FirefoxでPDFへアクセスしてダウンロードではなく「開く」を選択していると、ダウンロードフォルダに大量のPDFが発生する。

従来の挙動に戻すには、about:config にて

browser.download.improvements_to_download_panel=false

に設定する。


参考
Firefox バージョン 98 におけるダウンロード処理方法の変更 | Firefox ヘルプ

AlmaLinux/RockyLinux 8 で古いカーネルを削除する方法

以前に、次のような記事を書いたが、使えないパターンがあった。

shobon.hatenablog.com

エラーになるパターン

こんな感じにカーネルがインストールされた状態で、最も古いカーネルで起動中。

# rpm -qa | grep kernel | sort
kernel-4.18.0-348.2.1.el8_5.x86_64
kernel-4.18.0-348.20.1.el8_5.x86_64
kernel-4.18.0-348.23.1.el8_5.x86_64
・・・略

# uname -r
4.18.0-348.2.1.el8_5.x86_64

以前のコマンドでは、次のようなエラーになる。

# dnf remove $(dnf repoquery --installonly --latest-limit=-2)
エラー:
 問題: 操作は結果的に以下の保護されたパッケージを削除します: kernel-core
(インストール不可のパッケージをスキップするには、'--skip-broken' を追加してみてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)

古いカーネルを削除する方法・改良版

代わりに、次のようなコマンドで削除する。

# dnf remove --oldinstallonly --setopt installonly_limit=2 kernel
依存関係が解決しました。
===========================================================================================
 パッケージ          アーキテクチャー    バージョン                リポジトリー    サイズ
===========================================================================================
削除中:
 kernel              x86_64              4.18.0-348.20.1.el8_5     @baseos         0
 kernel-core         x86_64              4.18.0-348.20.1.el8_5     @baseos         68 M
 kernel-modules      x86_64              4.18.0-348.20.1.el8_5     @baseos         22 M

トランザクションの概要
===========================================================================================
削除  3 パッケージ

解放された容量: 90 M
これでよろしいですか? [y/N]: 


これならエラーは出ない。
削除対象になるのは、起動中を除いた最も古いカーネルからカウントして決定される。

指定されたdnfのオプションの意味は以下の通り。

  • remove --oldinstallonly:古いinstallonlyパッケージを削除
  • --setopt:/etc/dnf/dnf.confのデフォルト値を変更(installonly_limitの値を2にした)

dnf で jasper-libs が 競合エラーになる

環境

# cat /etc/redhat-release
AlmaLinux release 8.4 (Electric Cheetah)

CentOS 8からの移行環境ではなく、クリーンインストールしたAlmaLinux。

現象

次のようなエラーになる。

# dnf upgrade
メタデータの期限切れの最終確認: 1:53:30 時間前の 20211113211516秒 に実施しました。
エラー:
 問題: cannot install both jasper-libs-2.0.14-5.el8.x86_64 and jasper-libs-2.0.14-4.el8.x86_64
  - package jasper-devel-2.0.14-4.el8.x86_64 requires jasper-libs(x86-64) = 2.0.14-4.el8, but none of the providers can be installed
  - cannot install the best update candidate for package jasper-libs-2.0.14-4.el8.x86_64
  - problem with installed package jasper-devel-2.0.14-4.el8.x86_64
(競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)

# dnf clean all
してもダメ。

# dnf upgrade jasper-libs
のように個別で指定してもダメ。


まずは、現在のインストール済みバージョンを確認

# rpm -qa | grep jasper
jasper-libs-2.0.14-4.el8.x86_64
jasper-devel-2.0.14-4.el8.x86_64

次に、upgrade対象のバージョンを確認

# dnf info jasper-libs
・
・省略
・
名前         : jasper-libs
バージョン   : 2.0.14
リリース     : 5.el8
Arch         : x86_64
サイズ       : 166 k
ソース       : jasper-2.0.14-5.el8.src.rpm
リポジトリー : appstream
概要         : Runtime libraries for jasper
URL          : http://www.ece.uvic.ca/~frodo/jasper/
ライセンス   : JasPer
説明         : Runtime libraries for jasper.


最初に示したエラーメッセージの通り、
 現在 :jasper-libs-2.0.14-4.el8.x86_64
 更新先:jasper-libs-2.0.14-5.el8.x86_64
で競合しているらしい。
エラーメッセージの最後に、
- problem with installed package jasper-devel-2.0.14-4.el8.x86_64
と書いてあるが、インストール済みパッケージに何らかの問題が発生している模様。

エラーメッセージのヒントで、
 (競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください
 または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください
 または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)
とあったので、これらを試してみる。


「--allowerasing」の指定を試す

# dnf upgrade jasper-libs --allowerasing
メタデータの期限切れの最終確認: 0:05:42 時間前の 20211113211537秒 に実施しました。
依存関係が解決しました。
===============================================================================================
 パッケージ                Arch           バージョン                 リポジトリー        サイズ
===============================================================================================
アップグレード:
 jasper-libs               x86_64         2.0.14-5.el8               appstream           166 k
依存関係パッケージの削除:
 ImageMagick-devel         x86_64         6.9.10.86-1.el8            @epel               501 k
 jasper-devel              x86_64         2.0.14-4.el8               @powertools         2.8 M

トランザクションの概要
===============================================================================================
アップグレード  1 パッケージ
削除            2 パッケージ

ダウンロードサイズの合計: 166 k
これでよろしいですか? [y/N]:

「jasper-devel」が削除されるらしい。
「jasper-devel」だけ個別にremoveしてからupgradeしても良かったかもしれない。

mariadb のlogrotateでgzipエラーが出る

環境

AlmaLinux 8.4~8.5

$ rpm -qa | grep mariadb
mariadb-connector-c-config-3.1.11-2.el8_3.noarch
mariadb-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64
mariadb-server-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64
mariadb-errmsg-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64
mariadb-connector-c-3.1.11-2.el8_3.x86_64
mariadb-gssapi-server-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64
mariadb-common-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64
mariadb-backup-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64
mariadb-server-utils-10.3.28-1.module_el8.3.0+2177+7adc332a.x86_64

現象

mariadb のlogrotateで次のようなエラーが出た。

/etc/cron.daily/logrotate:

error: Compressing program wrote following message to stderr when compressing log /var/log/mariadb/mariadb.log-xxxxxxxx:
gzip: stdin: file size changed while zipping


以下が該当すると思われる。
bugzilla.redhat.com


上記のリンク先を見ると、修正済みとしてリリースされている模様。
access.redhat.com


修正された更新パッケージのバージョン部分を見ると、「mariadb-10.5.9-1」とある。

自分の環境でインストールされたMariDBは10.3 で、上記の修正版とはバージョンが異なる。

パッケージ更新があったのは10.5系だったが、10.3系で修正された情報を得られなかったので、
Bugzilla にあるよう/etc/logrotate.d/mariadb へ delaycompress を追記して対応。

10.3から10.5への移行を考えるなら、以下を参考に。
9.2.6. MariaDB 10.3 から MariaDB 10.5 へのアップグレード Red Hat Enterprise Linux 8 | Red Hat Customer Portal

9.2.6.2. RHEL 8 バージョンの MariaDB 10.3 から MariaDB 10.5 へのアップグレード Red Hat Enterprise Linux 8 | Red Hat Customer Portal