最小インストールのRHEL7環境で文字化けせずにNetBackup管理画面を表示するために必要なパッケージ


最小インストールのRHEL7環境で文字化けせずにNetBackup管理画面を表示するために必要なパッケージを確認した。

なお、表示させるのはLinuxサーバローカルのディスプレイではなく、同一ネットワーク上にあるWindows10にインストールされた「VcXSrv

# yum install libXext libXrender libXtst xorg-x11-fonts-Type1 vlgothic-fonts vlgothic-p-fonts

なお、「vlgothic-p-fonts」は入れなくても表示はされるが、文字がゴツゴツした感じとなる。

・vlgothic-fonts vlgothic-p-fontsの両方をインストールした場合


vlgothic-fonts vlgothic-p-fontsの両方をインストールした場合

・vlgothic-fontsのみインストールした場合


vlgothic-fontsのみインストールした場合

NetBackup GUIはJavaを使って表示している。

フォントに関する指定はJREのlibにfontconfig~.srcというファイルで保存されている。

# ls /usr/openv/java/jre/lib/fontconfig*.src
/usr/openv/java/jre/lib/fontconfig.RedHat.5.properties.src
/usr/openv/java/jre/lib/fontconfig.RedHat.6.properties.src
/usr/openv/java/jre/lib/fontconfig.SuSE.10.properties.src
/usr/openv/java/jre/lib/fontconfig.SuSE.11.properties.src
/usr/openv/java/jre/lib/fontconfig.Turbo.properties.src
/usr/openv/java/jre/lib/fontconfig.properties.src
#

「fontconfig.RedHat.6.properties.src」の中を見てみると、関係しそうな記述として以下を発見

# Font File Names
filename.-misc-kochi_gothic-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf
filename.-misc-kochi_mincho-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/ipa-mincho/ipam.ttf
filename.-misc-zysong18030-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/cjkuni-uming/uming.ttc


# AWT X11 font paths
awtfontpath.chinese-tw-iso10646=/usr/share/fonts/cjkuni-uming
awtfontpath.chinese-cn-iso10646=/usr/share/fonts/cjkuni-uming
awtfontpath.japanese-iso10646=/usr/share/fonts/vlgothic
awtfontpath.korean-iso10646=/usr/share/fonts/un-core

どうやら明朝体は「ipa-mincho-fonts.noarch 」 に含まれる /usr/share/fonts/ipa-mincho/ipam.ttf、ゴシック体は「vlgothic-fonts」 に含まれる /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf を使っているようだ。


2022/07/10追記

最小インストールのOracle Linux 8でブラウザを動かす場合FirefoxとChromeのどっちが容量少ないか」 で検証した結果を踏まえると、RHEL8の標準状態で使えるフォントは「google-noto-cjk-fonts-common google-noto-sans-cjk-ttc-fonts google-noto-serif-cjk-ttc-fonts」になるんじゃないかと思われる。

もしくはEPELレポジトリを追加して、「vlgothic-fonts vlgothic-p-fonts」

無償系アンチウイルスソフト


2020/04/14に調査した内容を「無償系アンチウイルスソフト 2020/04/14」にて公開中


Windows10だと標準のままでいっかぁ、という感じも強いですが、いまも生きてる無償系アンチウイルスソフトって何があるのかな、と見てみた。

AVAST!とAVG

2016年7月にAvastがAVGを買収(「無償ウイルス対策のAvastがAVGを買収へ。買収額は13億米ドル」)したのですが、2019年3月になってもプロダクトが並行稼働しています。

Avast Free Antivirus」と「AVG 2019 Free

Comodo

Comodo Free Internet Security Suite 2019」と「Comodo Antivirus for Windows 10 Free」と「Comodo Cloud Antivirus」の3種類がある。

Comodo Cloud Antivirus」だと 検査する処理はComodoクラウドに行わせるというものらしいが、3プロダクトの違いがよく分からない・・・

Comodo Antivirus for Linux」が同じくFreeでもリリースされており、Debian/Ubuntu/Mint,RHEL/CentOS/Fedora,SuSEなどで使用できる。

ただ、2019年3月時点のサポートLinuxは「Ubuntu 12.04 / Red Hat Enterprise Linux Server 5.9, 6.3 / Fedora 17 / SUSE Linux Enterprise Server 11 / OpenSUSE Linux 12.1 / Debian 6.0 / CentOS 5.9, 6.2 / Mint 13 / CentOS 5.8, 6.2」と、古い目である。

サポートメールシステムとして「Sendmail 8.14.4 / qmail 1.06 / Postfix 2.5.x or higher / Exim 4.x / Amavis 2.6.4」とあるので、メールサーバで使ってもよいらしい?

Avira

Avira Free Antivirus 2019

panda

クラウド型をうたう「panda antivirus

一時期日本の代理店があったようだけど、いまは無い?

Rising Antivirus

日本ではウイルスキラーという名前で販売されたこともある商品。

ウイルスキラーは2013年1月に終了し、英語版も2013年9月に終了したが、中国版の「瑞星杀毒软件」は2019年3月も稼働中

Immunet Protect

Immunet」は元々ClamAVを元に独自エンジンも搭載したものとして開発されたもの。ClamAVごと2011年にSourcefireという会社に買収。2014年にSourcefireがCiscoに買収されたため、現在はCisco傘下のプロダクトになっている。

gredアンチウイルスとして日本語版が公開されていたがこちらは2017年に提供は終了。

adaware

adaware antivirus 12 free

Bitdefender

Bitdefender Antivirus Free Edition

Bitdefenderの日本語ページからはアクセスできない場所にあるようで、検索しないとたどり着けなかった。

NetBackupクライアントの接続エラーに関して調査


Veritas NetBackupにおいて、NetBackupクライアントとの接続に問題があった場合の調査手法についてメモ書き

1.1 マスタサーバ/メディアサーバ上での名前解決確認

マスタサーバ/メディアサーバ上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

ここで予期しないIPアドレスが出てきてしまうのであれば、ホスト名/IPアドレス/DNS設定を見直すこと。

続いて問題が発生しているクライアントについての名前解決状況を確認する。

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

クライアントホスト名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にクライアントホスト名のエントリを追加すること。

追加後は、再度bpclntcmdを実行して、状況が変化したことを確認する。

1.2. クライアント上での名前解決確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

通常はクライアント自身については正常に情報が取得できるはずです。

続いてマスタサーバ/メディアサーバについての名前解決状況を確認

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

マスタサーバ上で実行した結果と異なる場合は、名前解決情報のキャッシュが残存している可能性があるため、「bpclntcmd -clear_host_cache」を実行してキャッシュ削除した上で、再度、名前解決状況を確認する。

マスタサーバ/メディアサーバ名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にマスタサーバ/メディアサーバ 名のエントリを追加すること。

1.3. クライアント上でマスタサーバが認識している情報の確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、NetBackupが認識しているホスト名情報を確認する。

# bpclntcmd -pn -verbose

2.1. 接続テストを実施

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd/bptestbpcd もしくは C:\Program Files\Veritas\NetBacku\bin\admin\bptestbpcd を実行して、 マスターサーバからクライアントへの接続テストを実施します。

# bptestbpcd -client クライアントホスト名 -verbose -debug

(Veritas KB: How to test client connections using the bptestbpcd command)

2.2 接続テスト2

マスタサーバ上で /usr/openv/netbackup/bin/bptestnetconn もしくは C:\Program Files\Veritas\NetBacku\bin\bptestnetconn.exe を実行して、接続を確認

# bptestnetconn -asp -H クライアントホスト名

(Veritas KB: Best Practices for bptestnetconn including arguments and outputs by NetBackup version )
(Veritas KB: Using bptestnetconn to test connectivity between NetBackup hosts )


おまけ: クライアントの情報が取得できるか確認

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd か C:\Program Files\Veritas\NetBacku\bin\admin にある bpgetconfig を実行して、マスタサーバからクライアント上のNetBackup Agentのインストール情報を確認します。

# bpgetconfig -g クライアントホスト名 -L

出力内に、Agentのインストール先やバージョンが表示されれば接続できています。

(Veritas KB: Command line option to get client NetBackup version, OS, and hardware type)


おまけ2: 複数NICがある場合の設定に関する資料

How to follow best practices when using Preferred Network entries
 調査時に使うbplocaladdrsコマンド, bptestnetconnコマンド, bptestbpcdコマンドの出力サンプルあり

Best Practices when assigning an IP address to the appliance management interface
 bp.confにPREFERRED_NETWORK=~というエントリを追加する、という話

Required Interface or Preferred Network settings seem to cause connections between non-routed networks on weakhost platforms
 bp.confにPREFERRED_NETWORKかREQUIRED_INTERFACE設定をする
 (PREFERRED_NETWORKはNBU7.xで追加された設定項目)

How to force backups over multiple specific networks interfaces instead of all those available.


NetBackup 8.xでの証明書関連エラー対応

クライアントインストール時にサーバとの通信がうまくいかなかったけど、無視してインストールを完了した場合、サーバの証明書が、クライアント側に保存されておらず、バックアップを行うとエラーになる。

1: (7660) ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません 

2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Connecting host:  NBUサーバ
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] ConnectionId: {149DAA97-CA51-4AC8-8E38-F4F253D9B113}:OUTBOUND
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] pid: 2556
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Received status: 7660 with message 証明書のマッピングファイルを読み込めません。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) ホスト ( NBUクライアント) 上のピアプロキシで使用可能な証明書が見つかりませんでした。 証明書が正常に配備されていない可能性があります。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] 処理中 (CertProtocol) にエラーが発生しました (CERT_PROTOCOL_SELECT_COMMON_CA_ROOT)。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956)  NBUクライアント の bpcd が状態 7660 で終了しました: ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Connecting host:  NBUサーバ
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] ConnectionId: {84C7C072-EC87-4247-AE80-9066320C5EA5}:OUTBOUND
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] pid: 2556
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Received status: 7660 with message 証明書のマッピングファイルを読み込めません。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) ホスト ( NBUクライアント) 上のピアプロキシで使用可能な証明書が見つかりませんでした。 証明書が正常に配備されていない可能性があります。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] 処理中 (CertProtocol) にエラーが発生しました (CERT_PROTOCOL_SELECT_COMMON_CA_ROOT)。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956)  NBUクライアント の BPCD が状態 61 で終了したため、メールを送信できません: VNETD プロキシでエラーが発生しました
2022/10/24 10:28:10 - 情報 bpbkar32 (pid=0) done. status: 7660: ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません
2022/10/24 10:28:10 - 推定で 0 KB 必要です
2022/10/24 10:28:10 - 情報 nbjm (pid=4240) started backup (backupid= NBUクライアント_1666574889) job for client  NBUクライアント, policy  NBUクライアント, schedule Full on storage unit diskstorage
2022/10/24 10:28:10 - 開始されたプロセス bpbrm (pid=1956)
2022/10/24 10:28:10 - 書き込みの終了
ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません  (7660)

このエラーに関するKB 「How to resolve communication problems due to certificate errors after upgrading to 8.1 from a previously re-installed 8.0 host」「How to manually obtain a host ID Certificate.」「How to re-issue a token on a NetBackup 8.1.x client that has been reinstalled

上記からNetBackupクライアントから証明書取得のコマンドを実行してみる

# /usr/openv/netbackup/bin/nbcertcmd  -getCertificate -host  NBUクライアント -server NBUサーバ
nbcertcmd: The -getCertificate operation failed for server NBUサーバ
EXIT STATUS 8500: Connection with the web service was not established.
#

これはNetBackupサーバ側でポートが正しく空いていないためだった(Status Code:8500 Error when trying to install agent on new server)

今回はWindows Server上だったので、Windows FIrewallに対して、ポート1556とポート13724を開けた。(NetBackup master server portsをみるともポート 13782 もあった方がよさそう)

再実行すると下記となる

# /usr/openv/netbackup/bin/nbcertcmd  -getCertificate -host  NBUクライアント -server NBUサーバ
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

これは証明書管理にホストが登録されていないために発生しています

新規トークンを発行します

ここで表示されるトークン値を使います

# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token QWRNKOHALAKDPAGF
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

なんだろと調査をいろいろしてみるとnbcertcmd -displayCACertDetailの実行結果で問題が・・・

# /usr/openv/netbackup/bin/nbcertcmd -displayCACertDetail -server NBUサーバ

CA Certificate received successfully from server NBUサーバ.

         Subject Name : /CN=nbatd/OU=root@NBUサーバ/O=vx
           Start Date : 10月 20 04:36:48 2022 GMT
          Expiry Date : 10月 15 05:51:48 2042 GMT
     SHA1 Fingerprint : E4:3C:2E:12:4C:66:DF:62:28:98:C1:D3:EB:5A:E0:44:4F:52:64:62
 CA Certificate State : Not Trusted

# /usr/openv/netbackup/bin/nbcertcmd -displayCACertDetail -server NBUサーバ.adosakana.local
The target server NBUサーバ.adosakana.local could not be authenticated.
The server name does not match any of the host names listed in the server's certificate.
Names listed in the server's certificate are:
DNS:NBUサーバ
Failed to display CA certificate details

nbcertcmd: The -displayCACertDetail operation failed.
EXIT STATUS 8509: The specified server name was not found in the web service certificate
#

NetBackupサーバ上の証明書がドメイン無しで発行されているのにたいして、NetBackupクライアント側からはドメイン有りで接続しようとしているのでエラーとなっていた模様。

NetBackupサーバ側の証明書変更手法が分からないのでNetBackupクライアント側のbp.confのSERVER記述をドメイン無しに書き換えて再実行

# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token QWRNKOHALAKDPAGF -force
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

これだけではなかった模様

「nbcertcmd -getCACertificate」を実行して取り込みした上で「nbcertcmd -getCertificate -token」で成功

# /usr/openv/netbackup/bin/nbcertcmd -getCACertificate
Authenticity of root certificate cannot be established.
The SHA1 fingerprint of root certificate is E4:3C:2E:12:4C:66:DF:62:28:98:C1:D3:EB:5A:E0:44:4F:52:64:62.
Are you sure you want to continue using this certificate ? (y/n): y
The validation of root certificate fingerprint is successful.
CA certificate stored successfully from server NBUサーバ.
# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token
QWRNKOHALAKDPAGF -force
Host certificate and certificate revocation list received successfully from server NBUサーバ
#

GUI上にも登録できた