samba 4.10.x環境で出てたsamba_dnsupdateのエラー対処


samba 4.10.7へアップデートしたあと、「systemctl status samba-ad-dc.service」で出力されるログを見てみたら、微妙な感じのエラーがあった。

 8月 29 08:54:02 adserver samba[107156]: [2019/08/29 08:54:02.287210,  0] ../../lib/util/util_runcmd.c:327(samba_runcmd_io_handler)
 8月 29 08:54:02 adserver samba[107156]:   /usr/local/samba/sbin/samba_dnsupdate: ImportError: No module named dns.resolver
 8月 29 08:54:02 adserver samba[107156]: [2019/08/29 08:54:02.295161,  0] ../../source4/dsdb/dns/dns_update.c:331(dnsupdate_nameupdate_done)
 8月 29 08:54:02 adserver samba[107156]:   dnsupdate_nameupdate_done: Failed DNS update with exit code 1
 8月 29 08:54:03 adserver winbindd[107159]: [2019/08/29 08:54:03.430795,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
 8月 29 08:54:03 adserver winbindd[107159]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
 8月 29 08:54:03 adserver smbd[107151]: [2019/08/29 08:54:03.438943,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 08:54:03 adserver smbd[107151]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
 8月 29 08:54:03 adserver winbindd[107159]: [2019/08/29 08:54:03.454411,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 08:54:03 adserver winbindd[107159]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections

「samba_dnsupdate: ImportError: No module named dns.resolver」の対応

現状の確認方法

[root@adserver ~]# samba_dnsupdate --verbose
Traceback (most recent call last):
  File "/usr/local/samba/sbin/samba_dnsupdate", line 57, in <module>
    import dns.resolver
ImportError: No module named dns.resolver
[root@adserver ~]#

原因はpythonのDNS toolkitがインストールされていないこと。

CentOS7環境で対処するには「yum search dnspython」を実行してモジュール名を確認

[root@adserver ~]# yum search dnspython
読み込んだプラグイン:fastestmirror
Determining fastest mirrors
 * base: ftp.riken.jp
 * epel: ftp.riken.jp
 * extras: ftp.riken.jp
 * updates: ftp.riken.jp
=============================== 一致: dnspython ================================
python-dns.noarch : DNS toolkit for Python
python36-dns.noarch : DNS toolkit for Python 3
[root@adserver ~]#

今回使っている環境はpython 2環境なので、「yum install python-dns」でインストール。

[root@adserver ~]# yum install python-dns.noarch
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
epel/x86_64/metalink                                     | 7.3 kB     00:00
 * base: ftp.riken.jp
 * epel: ftp.riken.jp
 * extras: ftp.riken.jp
 * updates: ftp.riken.jp
base                                                     | 3.6 kB     00:00
epel                                                     | 5.4 kB     00:00
extras                                                   | 3.4 kB     00:00
packages-microsoft-com-prod                              | 2.9 kB     00:00
updates                                                  | 3.4 kB     00:00
(1/3): epel/x86_64/updateinfo                              | 998 kB   00:02
(2/3): packages-microsoft-com-prod/primary_db              | 200 kB   00:00
(3/3): epel/x86_64/primary_db                              | 6.8 MB   00:03
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ python-dns.noarch 0:1.12.0-4.20150617git465785f.el7 を インスト ール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package        アーキテクチャー
                           バージョン                            リポジトリー
                                                                           容量
================================================================================
インストール中:
 python-dns     noarch     1.12.0-4.20150617git465785f.el7       base     233 k

トランザクションの要約
================================================================================
インストール  1 パッケージ

総ダウンロード容量: 233 k
インストール容量: 1.0 M
Is this ok [y/d/N]: y
Downloading packages:
python-dns-1.12.0-4.20150617git465785f.el7.noarch.rpm      | 233 kB   00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : python-dns-1.12.0-4.20150617git465785f.el7.no   1/1
  検証中                  : python-dns-1.12.0-4.20150617git465785f.el7.no   1/1

インストール:
  python-dns.noarch 0:1.12.0-4.20150617git465785f.el7

完了しました!
[root@adserver ~]#

動作確認・・・

[root@adserver ~]# samba_dnsupdate --verbose
IPs: ['172.17.44.49']
Looking for DNS entry A adserver.adosakana.local 172.17.44.49 as adserver.adosakana.local.
Looking for DNS entry NS adosakana.local adserver.adosakana.local as adosakana.local
<略>
Checking 0 100 389 adserver.adosakana.local. against SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.adosakana.local adserver.adosakana.local 389
No DNS updates needed
[root@adserver ~]#

それ以外のログについて

samba_dnsupdateに関するエラーについて対処した後、sambaを再起動してログを見てみると、下記の様な感じになっていた。

 8月 29 09:06:46 adserver samba[107294]: [2019/08/29 09:06:46.991243,  0] ../../source4/smbd/server.c:773(binary_smbd_main)
 8月 29 09:06:46 adserver samba[107294]:   binary_smbd_main: samba: using 'standard' process model
 8月 29 09:06:47 adserver samba[107294]: [2019/08/29 09:06:47.021548,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 09:06:47 adserver samba[107294]:   daemon_ready: daemon 'samba' finished starting up and ready to serve connections
 8月 29 09:06:49 adserver winbindd[107312]: [2019/08/29 09:06:49.157089,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
 8月 29 09:06:49 adserver winbindd[107312]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
 8月 29 09:06:49 adserver winbindd[107312]: [2019/08/29 09:06:49.266323,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 09:06:49 adserver winbindd[107312]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections
 8月 29 09:06:50 adserver smbd[107311]: [2019/08/29 09:06:50.436561,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 09:06:50 adserver smbd[107311]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections

RHEL7だと上記出力を赤文字で出力してるけど、内容を見る限りではinformation的なものであるので、特に対処する必要はなさそうである。

NetBackupの操作をコマンドで行う


NetBackupのJava GUI(jnbSA)上で行う操作をCLIコマンドで行うためのメモ書き。

トラブル調査用コマンドについては→「NetBackupのトラブル調査とログ取り

アクティビティモニター

アクティビティモニターの一覧表示:bpdbjobs

アクティビティモニターの一覧は「bpdbjobs」をオプション無しで実行すると得られる。

フルパスは「/usr/openv/netbackup/bin/admincmd/bpdbjobs」

アクティビティモニターで各ジョブの詳細ログ確認:bpdbjobs -report -jobid 番号 -all_columns

各ジョブの詳細ログを確認する場合は「bpdbjobs -report -jobid 番号 -all_columns」となるのだが、これだと「,」区切りで1行に全てを出力してしまう。

人の目だと見にくいので「bpdbjobs -report -jobid 番号 -all_columns | sed s/,/,\n/ig」と実行すると、改行が入り多少見やすくなる。

テープドライブの操作

デバイスモニターの一覧表示:tpconfig -l か tpconfig -d

デバイスモニターで確認出来る各テープドライブのステータスは「tpconfig -l」か「tpconfig -d」で確認出来る。

「tpconfig -d」だとテープドライブのみの確認で、「tpconfig -l」だとロボット番号を含めて確認しやすい形となるので「tpconfig -l」の方を実行することをお勧めする。

フルパスは「/usr/openv/volmgr/bin/tpconfig」

ドライブステータスの変更:vmoprcmd -up ドライブ番号

状態が「DOWN(停止)」となっているテープドライブを「UP(有効)」にするには「vmoprcmd -up ドライブ番号」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
デバイスロボットドライブ       ロボット                    Drive                Device     Second
形式     番号 インデックス  形式 ドライブ番号 状態  Comment    Name                 Path       Device Path
ロボット      0    -    TLD    -       -  -          -                    /dev/sg3
  ドライブ    -    0 hcart2    1  停止  -          IBM.ULT3580-TD5.000  /dev/nst1
ロボット      1    -    TLD    -       -  -          -                    /dev/sg2
  ドライブ    -    1    dlt    1  停止  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]# /usr/openv/volmgr/bin/vmoprcmd -up 0
[root@nbuserver ~]# /usr/openv/volmgr/bin/vmoprcmd -up 1
[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
デバイスロボットドライブ       ロボット                    Drive                Device     Second
形式     番号 インデックス  形式 ドライブ番号 状態  Comment    Name                 Path       Device Path
ロボット      0    -    TLD    -       -  -          -                    /dev/sg3
  ドライブ    -    0 hcart2    1  有効  -          IBM.ULT3580-TD5.000  /dev/nst1
ロボット      1    -    TLD    -       -  -          -                    /dev/sg2
  ドライブ    -    1    dlt    1  有効  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]#

フルパスは「/usr/openv/volmgr/bin/vmoprcmd」

ロボットのインベントリ実行:vmupdate -rt tld -rn ロボット番号

ロボットに対してインベントリを実行するには「vmupdate -rt tld -rn ロボット番号」を実行します。

ロボット番号については「tpconfig -l」で確認します。

「-recommend」オプションをつけて実行すると「インベントリ操作-内容とボリュームの構成の比較」となります。

-recommendなしが「 インベントリ操作 -ボリューム構成の更新」になります。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
推奨された変更のリストを生成しています...

次のように、ボリュームの構成を更新します。
=====================================================
ボリュームの構成は、ロボット内と同じ最新の状態です。
[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
推奨された変更のリストを生成しています...

次のように、ボリュームの構成を更新します。
=====================================================
ボリュームの構成は、ロボット内と同じ最新の状態です。
[root@nbuserver ~]#

ロボットの中のテープ一覧を表示:vmquery -b -rn ロボット番号

ロボット上で認識されているテープメディアを確認するには「vmquery -b -rn ロボット番号」を実行します。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rn 0
メディメディロボッ  ロボッロボット 側面/ 光         # マウント/  最終
アID   ア形式 ト形式  ト#    スロット 断面  パートナークリーニングマウント時間
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          23     2019/06/03 16:59
O501L5  HCART2 TLD      0       2     -       -           5     2019/06/03 17:10
O502L5  HCART2 TLD      0       3     -       -           6     2019/06/03 15:26
O503L5  HCART2 TLD      0       4     -       -           1     2019/05/21 17:51
O504L5  HCART2 TLD      0       5     -       -          13     2019/06/03 11:24
[root@nbuserver ~]#

テープのQuick Erase:bplabel

NetBackupで記録したテープメディア内の登録を削除する場合「bplabel」コマンドを実行します。

ただ、有効期限が切れていないメディアに対しては実行できません。

その場合は「bpexpdate -d 0 -m メディアID」コマンドを実行して有効期限を切ってから、bplabelを実行する形となります。

[root@nbuserver logs]# /usr/openv/netbackup/bin/admincmd/bplabel -m O501L5 -d hcart2 -erase
メディアが割り当てられていますが、ラベルが付けられません
[root@nbuserver logs]# /usr/openv/netbackup/bin/admincmd/bpexpdate -d 0 -m O501L5
メディア O501L5 が 2019/06/04 17:47:09 で期限切れになります
このメディアのデータは本当に業務に必要ではありませんか
、 O501L5 を本当に削除しますか y/n(n)? y
[root@nbuserver logs]# /usr/openv/netbackup/bin/admincmd/bplabel -m O501L5 -d hcart2 -erase
メディアはすでに NetBackup 形式です。メディア ID = O501L5。消去 を実行しますか? y/n (n) y
消去が完了しました。
[root@nbuserver logs]#

なお、「-erase」がQuick Eraseで「-erase -l」がLong Eraseとなります。

リストア操作を手動で実施する場合

その1:使用可能なバックアップの捜索

「bpimmedia -client クライアント名」もしくは「bpimmedia -client クライアント名 -U」で指定したクライアントに関するバックアップIDを一覧化する。

-Uオプションの方が人が見やすい形となるが、sort/grepで抜き出す場合は-Uなしで実行した方が良い。

その2:リストアしたいバックアップデータを含む「バックアップ時刻」を確認

「bpimagelist -backupid バックアップID -U」を実行し、該当するバックアップIDの「バックアップ時刻」を取得。

この「バックアップ時刻」の文字列をこの後で使う。

その3:該当するバックアップに含まれるファイルを確認

UNIX系(Standard形式)クライアントの場合は「-t 0」なので「bplist -C クライアント名 -t 0 -s バックアップ時刻 -l -R /」

Windows(MS-Windows形式)クライアントの場合は「-t 13」なので 「bplist -C クライアント名 -t 13 -s バックアップ時刻 -l -R /」

なお、選択したバックアップ時刻が最新のバックアップでない場合は「-e バックアップ時刻」を追加し、データを限定する。

[root@nbuserver ~]#  /usr/openv/netbackup/bin/bplist -C nbuwindows -t 13 -s 2019/04/24 09:11 -l /C/Users/Administrator/Documents/test.txt
-rwx------ root;Admi root;None          32  4月 10日 19:47 /C/Users/Administrator/Documents/test.txt
[root@nbuserver ~]#

その4:リストアしたいファイルを選択

リストアしたいファイルの選択は、テキストファイル内にフルパスを記載することで行う。

先ほどのbplistの出力結果に記載されているパスを使用する。

Windowsの場合、「\」は使用できず「/」で代替するため「C:\Users\」が「/C/Users/」という風になる。

[root@nbuserver ~]# cat /tmp/list.txt
/C/Users/Administrator/Documents/test.txt
[root@nbuserver ~]#

その5:リストア先を変更する場合は、変更する規則を記載

リストア先のディレクトリを変更したい場合、変更する規則をテキストファイル内に記載します。

たとえば「C:\Users\Administrator\Documents\」を「C:\tmp\」に変えたい場合は下記の様に記載します。

[root@nbuserver ~]# cat /tmp/change.txt
change /C/Users/Administrator/Documents/ to /C/tmp/
[root@nbuserver ~]#

「change 元パス to 変更後パス」という書式で、複数の変更がある場合は、それぞれ列挙します。

その6:リストアを実行

bprestoreコマンドでリストアを実行します。

バックアップを取得したクライアントとは別のクライアントにリストアしたい場合は「-D 宛先クライアント」を指定します。

Windows(MS-Windows形式)の場合、「/usr/openv/netbackup/bin/bprestore -C クライアント名 -t 13 -s <バックアップ時刻> -D 宛先クライアント -R 変更規則ファイル -f リストア対象ファイル 」といったように実行します。

NetBackupで他のNetBackupサーバから持ってきたテープメディア内のデータをリストアする


NetBackupサーバでバックアップに使用していたテープメディアを他のNetBackup環境に持ってきて、その中のデータをリストアしようとした場合に必要となるコマンドライン操作(CLI操作)について。

なお、インベントリとリストア以外のGUI操作はあるのかどうか知らない。

その1 現状のメディア認識状況などの確認

いまのメディア認識状態を確認するために現在のメディア認識状況確認「/usr/openv/volmgr/bin/vmquery -b -a」を実行してメディアがどういう認識状態か確認

[root@nbuserver ~]#  /usr/openv/volmgr/bin/vmquery -b -a
メディメディロボッ  ロボッロボット 側面/ 光         # マウント/  最終
アID   ア形式 ト形式  ト#    スロット 断面  パートナークリーニングマウント時間
-------------------------------------------------------------------------------
O500L5  HCART2 NONE     -      -     -       -          15     2019/04/19 00:00
O501L5  HCART2 NONE     -      -     -       -           2     2019/05/21 17:47
O502L5  HCART2 NONE     -      -     -       -           1     2019/05/21 17:48
O503L5  HCART2 NONE     -      -     -       -           1     2019/05/21 17:51
O504L5  HCART2 NONE     -      -     -       -          11     2019/05/21 17:54
[root@nbuserver ~]#

また、今回持ってくるテープは「O500L5」なのだが、その中に登録されている情報があるのかを「/usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U」を実行して確認する。

[root@nbuserver ~]# /usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U
エンティティが見つかりませんでした
[root@nbuserver ~]#

上記の様に「エンティティが見つかりませんでした」と出力される場合は、そのメディアの既存の登録がない状態。

その2 インベントリ実施

「/usr/openv/volmgr/bin/vmupdate -rt ロボットタイプ -rn ロボット番号」(/usr/openv/volmgr/bin/vmupdate -rt tld -rn 0)を実行して、インベントリ更新を行う。

実行後、vmqueryコマンドで該当するテープメディアについてロボット番号とスロット番号が認識されたことを確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
推奨された変更のリストを生成しています...

次のように、ボリュームの構成を更新します。
=====================================================
メディア ID O500L5 (バーコード LTO500L5) を、スタンドアロンからスロット 1 に論理的に移動します。
メディア ID O501L5 (バーコード LTO501L5) を、スタンドアロンからスロット 2 に論理的に移動します。
メディア ID O502L5 (バーコード LTO502L5) を、スタンドアロンからスロット 3 に論理的に移動します。
メディア ID O503L5 (バーコード LTO503L5) を、スタンドアロンからスロット 4 に論理的に移動します。
メディア ID O504L5 (バーコード LTO504L5) を、スタンドアロンからスロット 5 に論理的に移動します。
ボリュームの構成を更新しています...

次のとおり論理的にメディアを移動することによって、ロボットライブラリに追加、
またはロボットライブラリ内で移動された既存のメディアを処理しています...
        メディア ID     スロット
        ==========      =======
         O500L5            1
         O501L5            2
         O502L5            3
         O503L5            4
         O504L5            5


ボリュームの構成が正常に更新されました。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -a
メディメディロボッ  ロボッロボット 側面/ 光         # マウント/  最終
アID   ア形式 ト形式  ト#    スロット 断面  パートナークリーニングマウント時間
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/04/19 00:00
O501L5  HCART2 TLD      0       2     -       -           2     2019/05/21 17:47
O502L5  HCART2 TLD      0       3     -       -           1     2019/05/21 17:48
O503L5  HCART2 TLD      0       4     -       -           1     2019/05/21 17:51
O504L5  HCART2 TLD      0       5     -       -          11     2019/05/21 17:54
[root@nbuserver ~]#

その3 該当するメディアのメディアDB作成

該当するメディアについて、メディアDBを作成します。

「/usr/openv/netbackup/bin/admincmd/bpimport -create_db_info -id O500L5 -v」と実行します。

[root@nbuserver ~]# /usr/openv/netbackup/bin/admincmd/bpimport -create_db_info -id O500L5 -v
インポートフェーズ 1 を開始しました: 2019/05/21 18:43:30
INF - メディア ID O500L5 のデータベース情報を作成してください。
INF - メディア ID O500L5 のフェーズ 1 インポートを実行する bptm プロセスを正常に開始しました。
[root@nbuserver ~]#

その4 メディアの読み込みを実施

指定したメディアをテープドライブで読み込み、中身をスキャンします。

コマンドはその3から-create_db_infoを抜いた「/usr/openv/netbackup/bin/admincmd/bpimport -id O500L5 -v」となります。

[root@nbuserver ~]# /usr/openv/netbackup/bin/admincmd/bpimport -id O500L5 -v
インポートフェーズ 2 を開始しました: 2019/05/21 18:43:58
INF - ポリシー localbackup、スケジュール Full (oldserver_1554890341)、メディア ID O500L5、作成日時 2019/04/10 18:59:01 をインポートしています。
INF - INDEX ファイル情報のみを読み込んでインポートしています。
INF - クライアント oldserver、バックアップ ID oldserver_1554890341 のイメージを検証しています。

INF - ポリシー localbackup、スケジュール Full (oldserver_1554890341) のインポートは正常に完了しました。

INF - ポリシー localbackup、スケジュール Full (oldserver_1554890468)、メディア ID O500L5、作成日時 2019/04/10 19:01:08 をインポートしています。
INF - ポリシー localbackup、スケジュール Full (oldserver_1554890468) のインポートは正常に完了しました。

<略>


INF - ポリシー localbackup、スケジュール Full (oldserver_1558430463)、メディア ID O500L5、作成日時 2019/05/21 18:21:03 をインポートしています。
INF - ポリシー localbackup、スケジュール Full (oldserver_1558430463) のインポートは正常に完了しました。

INF - 20 イメージ (20 イメージ中) をインポートしました。インポートは成功しました。

[root@nbuserver ~]#

その5 スキャンした内容が登録されていることを確認

先ほどは「エンティティが見つかりませんでした」となった「/usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U」を再度実行します。

以下の様にbpimportで表示されたバックアップIDが出力されます。

[root@nbuserver ~]#  /usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U
--------------------------------------------------------------------------------
バックアップ ID: oldserver_1558430463
 ポリシー:        localbackup
 スケジュール形式: FULL
 保持レベル      1
 ファイルの数:  4788
 圧縮:              N
 暗号化:           N
 イメージ形式:  インポート済
 ー・チー﨣芦ミール・ 1
 有効期限:        2019年06月04日 18時44分39秒
 保留中のイメージ: 0

  コピー数:       1
  フラグメント数: 1
  フラグメントサイズ (KB): 263680
  メディア形式: リムーバブル
  コ・クO             hcart2
  ファイル数:    22
  オフセット:    5382
  ホスト:          nbuserver
  書き込みに使用されたデバイス: -1
  MPX:                N
  有効期限:       2019年06月04日 18時44分39秒
  保持レベル:                                 1
  メディア ID:    O500L5
  保留中のコピー: 0
--------------------------------------------------------------------------------

<略>

--------------------------------------------------------------------------------
バックアップ ID: oldserver_1558430463
 ポリシー:        localbackup
 スケジュール形式: FULL
 保持レベル      1
 ファイルの数:  4788
 圧縮:              N
 暗号化:           N
 イメージ形式:  インポート済
 ー・チー﨣芦ミール・ 1
 有効期限:        2019年06月04日 18時44分39秒
 保留中のイメージ: 0

  コピー数:       1
  フラグメント数: 1
  フラグメントサイズ (KB): 263680
  メディア形式: リムーバブル
  コ・クO             hcart2
  ファイル数:    22
  オフセット:    5382
  ホスト:          nbuserver
  書き込みに使用されたデバイス: -1
  MPX:                N
  有効期限:       2019年06月04日 18時44分39秒
  保持レベル:                                 1
  メディア ID:    O500L5
  保留中のコピー: 0
[root@nbuserver ~]#


その6 リストアする

NetBackupの通常のリストア手法でリストアします。

Commvault バックアップのWindowsクライアントをPUSHインストールする時のWindows Firewall 設定


Commvaultバックアップは、CommServeからPUSH操作によりWindowsクライアントへのCommvault エージェントのインストールを実施することができる。

その場合に必要なWindows Firewallの除外設定についてのメモ

公式のドキュメント「Prerequisites for Installations Using the CommCell Console」に記載されているが、実際のWindows Firewallテンプレートの記述とあわせていないのでわかりにくい。

試した限りでは「受信の規則」にある下記の3つの既存設定を「規則の有効化」するでいけた

・Windows Management Instrumentaion (DCOM受信)

・ Windows Management Instrumentaion (WMI受信)

・ファイルとプリンターの共有 (SMB 受信)

なお、ping応答もできるようにしたい場合は追加で「ファイルとプリンターの共有 (エコー要求 – ICMPv4 受信)」も有効化する(CommvaultのPUSHインストールにとっては不要)

インストールできるかの確認には、CommServeから「wmic /node:ホスト名 process get」と実行して対象ホストのプロセス一覧が取得出来れば、WMI動作としては問題ない感じです。

なお、CommVaultエージェントインストールにより、「CommVault_Process_1_????」といったルールが大量に登録される。

これは C:\Program Files\CommVault\Simpana\Base\AddFWExclusions.bat にて設定されたルールとなる。

— 2019/08/26追記 —

なんかこの設定だけだとうまくいかない

Visual C++ 2015-2019再頒布可能パッケージがインストールされていない場合に、リモートインストールが失敗することもある模様。


2021/09/03追記

Windows Server 2022でリモートインストールを試したところ、今回も同様に「Windows Management Instrumentaion (DCOM受信)」「Windows Management Instrumentaion (WMI受信)」「ファイルとプリンターの共有 (SMB 受信)」の3つの有効化でリモートインストールが可能になりました。

NetBackupでインベントリ操作をコマンドで実行する方法


NetBackupのテープ関連操作は基本GUIから行うことで解説されている場合が多い。

CLIから行う場合の手順について確認した。

NetBackupで管理しているテープチェンジャーの確認「tpconfig -l」

NetBackupでテープチェンジャーに対する操作を行う場合、テープチェンジャーが持つ操作装置(ロボット)の番号を指定して行う。
このため、管理下にあるロボットの番号をtpconfig -lコマンドで確認する必要がある。
なお、このコマンドでは同時にそのロボット内にあるドライブについても確認出来る。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
Device Robot Drive       Robot                    Drive                Device     Second
Type     Num Index  Type DrNum Status  Comment    Name                 Path       Device Path
robot      0    -    TLD    -       -  -          -                    /dev/sg2
  drive    -    1 hcart2    1      UP  -          IBM.ULT3580-TD5.000  /dev/nst1
robot      1    -    TLD    -       -  -          -                    /dev/sg4
  drive    -    0    dlt    1  DISABL  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]#

上記結果サンプルはrobot:1として認識されているSDLT600ドライブがあるロボットはNetBackup側で設定を行っていないためStatusが「DISABLE」となっている。

NetBackupで管理しているテープドライブの確認「tpconfig -d」

テープ装置単独で確認したい場合は「tpconfig -d」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -d
Id  DriveName           Type   Residence
      Drive Path                                                       Status
****************************************************************************
0   QUANTUM.SDLT600.000  dlt    TLD(1)  DRIVE=1
      /dev/nst0                                                        DISABLED
1   IBM.ULT3580-TD5.000  hcart2 TLD(0)  DRIVE=1
      /dev/nst1                                                        UP

Currently defined robotics are:
  TLD(0)     robotic path = /dev/sg2
  TLD(1)     robotic path = /dev/sg4

EMM Server = nbuserver

[root@nbuserver ~]#

上記結果サンプルはSDLT600ドライブについてはNetBackup側で設定を行っていないためStatusが「DISABLE」となっている。

テープ装置のインベントリ実行確認「vmupdate -rt tld -rn ロボット番号 -recommend」

GUI操作でいうところの[Inventory Robot]-[Preview volume configuration changes]に相当するものは「vmupdate -rt tld -rn ロボット番号 -recommend」となる。
ロボットのタイプが「TLD」以外の場合は適切に変更すること。

変更がある場合は以下の様に表示される。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Logically move media ID O502L5 (barcode LTO502L5) from standalone to slot 3.
[root@nbuserver ~]#

変更がない場合は以下のようになる。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Volume configuration is up-to-date with robot contents.
[root@nbuserver ~]#

テープ装置のインベントリ実行「vmupdate -rt tld -rn ロボット番号」

GUI操作でいうところの[Inventory Robot]-[Update volume configuration]に相当するものは「vmupdate -rt tld -rn ロボット番号」となる。
ロボットのタイプが「TLD」以外の場合は適切に変更すること。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Logically move media ID O502L5 (barcode LTO502L5) from standalone to slot 3.
Updating volume configuration ...

Processing existing media added to or moved within the robotic library by
logically moving media as follows...
        Media ID        Slot
        ========        ====
         O502L5            3


Volume configuration successfully updated.

[root@nbuserver ~]#

NetBackupに登録されているテープメディア一覧確認「vmquery -b -a」

NetBackupの管理下にあるテープメディアを確認するには「vmquery -b -a」となる。
テープ装置外にあるメディアについては「robot type:NONE」となる。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -a
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

ロボット内のテープメディア一覧確認「vmquery -b -rn ロボット番号」

指定したロボット内にあるメディアを確認するには「vmquery -b -rn ロボット番号」で確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rn 0
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

テープ装置外で保管されているテープメディア一覧「vmquery -b -rt NONE」

テープ装置外で保管されているテープメディアだけを確認するには「vmquery -b -rt NONE」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rt NONE
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
[root@nbuserver ~]#

現在存在しないテープ装置内にテープメディアが残存してしまっている場合の処理

現在存在しないテープ装置内にテープメディアが残存してしまっている場合、データベース上の登録をvmchangeコマンドで修正する必要がある。

テープメディアの置き場所を「-new_rt」オプションで「NONE」にすることで、テープ装置外であるという認識になる。
なお、Media Typeも指定する必要があるためvmqueryコマンドで現状のMedia Typeを確認すること。

Media IDが「O502L5」のステータスを変更する場合は、以下の様に実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmchange -m O502L5 -new_rt NONE -mt HCART2
[root@nbuserver ~]#

設定変更後は「vmquery -b -a」もしくは「vmquery -b -rt NONE」を実行し、robot typeが「NONE」に変わったことを確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery  -b -a
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#