最小インストールの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 を使っているようだ。

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

Ubuntu18.04で信頼できないレポジトリを使う


DELLのOpenManageをUbuntu 18.04にインストールしようとした。

Dell EMC OpenManage Ubuntu and Debian Repositories」にある手順にしたがって、/etc/apt/sources.list.d/linux.dell.com.sources.listファイルを作って、gpgコマンドでキーを取得・・・としようとしたところ、環境のfirwall設定の問題で pool.sks-keyservers.net にアクセスができず、「W: GPG error ~: The following singnatures couldn’t be verified because the public key is not available: NO_PUBKEY 1285491434D8786F」「E: The repository ~ is not signed」と言われる。

署名が確認できない場合でも動作するようにならないのか確認した。

bionic (5) sources.list.5.gz」より、「deb」と「url」の間に「[ オプション=値 ]」という形で設定すればよいことが分かった。

deb [ allow-insecure=yes trusted=yes ] http://linux.dell.com/repo/community/openmanage/920/bionic bionic main

上記を設定した後「apt-get update –allow-insecure-repositories」で情報を取得する。

そうすると、いままで「E: The repository ~ is not signed 」と言われていたところが「W: The repository ~ is not signed 」に変化する。

これにより「apt install srvadmin-base」などでインストールできるようになる。

DELL PowerEdgeサーバにLinuxを入れる際の追加ソフト


DELL PowerEdgeサーバにRedHat Enterprise Linux (RHEL)やCentOSをインストールする場合、OSインストール後に、DELL用の管理ソフトウェア OMSAとシステムアップデートツール DSUをインストールする。

「Dell EMC System Update (DSU)」用のYUMレポジトリを登録し、その後、「OpenManage Server Administrator」をインストールする形となるので、以下の様な流れとなる。

  1. レポジトリ登録
  2. DSUインストール
  3. OSMAインストール
  4. DTKをインストール
  5. dsuを使ってfirmware類をアップデート

実行するコマンドは以下の様な形となる。

# curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash
#  yum install dell-system-update 
# yum install srvadmin-all
# yum install syscfg raidcfg
# dsu --apply-upgrades --non-interactive

上記はオンラインで行う場合の手順。

オフラインで行いたい場合は「tarballをダウンロードしてインストール」「rsyncでミラーレポジトリを作る」と「ISOを作る」から選択する。

tarballは「Dell EMC OpenManage Server Administrator 9.1.0」から入手することができる・・・ただ、2019/01/09時点ではDSUレポジトリからインストールすると9.2.0になるので若干遅れている。

rsyncの場合は「rsync -avHz linux.dell.com::repo/hardware .」でコピーしてくる。

ISOをつくる場合は「dsucreateiso」をダウンロードして実行する。事前に「yum install mkisofs」でmkisofsをインストールしておく必要はある。

また、標準状態だと/tmpにダウンロードしてきたファイル群を置いた上で、そこで展開も行うので十分な容量を確保しておく必要がある。もしくは「–workspace=/ディレクトリ」で作業領域を指定する

[root@rhelserver7 dsu]# mkdir tmp
[root@rhelserver7 dsu]# ./dsucreateiso  --workspace=`pwd`/tmp
Log file:/var/log/dsucreateiso.log
Downloading: ftp://ftp.dell.com/sysman/DSUPlugins.tar
Invalid dellbootplugin location: ftp://downloads.dell.com/FOLDER05328537M/1/dellbootplugin.tar.gz
Downloading: https://downloads.dell.com/FOLDER05328537M/1/dellbootplugin.tar.gz
Extracting dellbootplugin: dellbootplugin.tar.gz
Downloading: https://downloads.dell.com/catalog/Catalog.gz
Extracting catalog: Catalog.gz
Parsing Catalog File...

Hyper-V統合サービスのバージョン確認


Hyper-V上でWindowsを使う場合、Hyper-V統合サービスをインストールする必要がある・・・というのが昔の設定。

いまは・・・というかWindows Server 2016以降はWindows Updateによる提供に代わりました。

これにより、古い資料では、ゲスト上にHyper-V統合サービスがインストールされているかどうかをPowerShell上で「Get-VM | Select Name, IntegrationServicesVersion」を実行し、バージョンを確認する、とかなっていたものが使えなくなっています。

Windows Server 2016環境では「
IntegrationServicesVersion」は「0.0」になります。

では、いまは、どうやってIntegration Sevices Versionを確認するのかと言えば、ゲストOS上で「REG QUERY “HKLM\Software\Microsoft\Virtual Machine\Auto” /v IntegrationServicesVersion」を実行することで確認します。いままでと異なり、ホストOS側では確認できないという点に注意が必要です。

参考資料 「クラスターの検証を実行した際に、Hyper-V 統合サービスのバージョン検証で警告が発生する」 「Manage Hyper-V Integration Services