カテゴリー: Linux

投稿日:

Beijing LINXというLinuxを入れてみた

NetBackupのOSコンパチガイドに登場した 「Beijing Linx Software Corp Linx」 が気になったので、仮想環境上にインストールしてみた。

調べて見ると「北京凝思科技有限公司(LINX-TECH)」という会社で作っているようで「服务与支持 > 软件下载 > 操作系统」で凝思安全操作系统V6.0.42、凝思安全操作系统V6.0.60、凝思安全操作系统V6.0.80のISOがダウンロードできるようだ。

とりあえず「V6.0.80」のISOファイル Linx-6.0.80-20180821-amd64-DVD.iso をダウンロードして、vSphere環境に突っ込んだ。

とりあえず、最初にLINXの初期インストール状況を軽く書いておくと

・ISOイメージのラベル名は「Debian 6.0.80-20180821 amd64 1」
・Linux kernel 4.9.0-0.bpo.1-linx-security-amd64 4.9.2-2~bpo8+1linx4 (2018-08-17)
・/etc/apt/sources.list にはオンラインリソースの登録は何もない
・Debian 8 Jessieベース(Debianとしてのサポートが終了)

日本時間にあわせる操作はできたものの、日本語キーボードやロケールをCやJP系に変えることは関連するパッケージがインストールされていないため出来なかった。

# timedatectl set-timezone Asia/Tokyo

ここからインストールプロセスの画像です

なかなか力強い感じのブートロゴ

この後細かいあたりは飛ばしますが、こんな感じのプロセスが進みます。

そしてインストール終了

ログイン画面はこんな感じです。

投稿日:

最小インストールの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」の３種類がある。

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

「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上にも登録できた

投稿日:

QUADSTOR VLTを使ってみた

2024/11/12追記

2024年10月上旬頃よりquadstorにあったDownloadページがなくなった。

その前ぐらいから、quadstor vtlで新規にVTLを作成する場合に使用していたテープライブラリ定義が含まれなくなっていた。変更記録に特になにも書いてないから、ミスなのかな？とか思ってたが、ずっとその状態。

フリーで提供するのを止めた、ということなんだろうか・・・

以前「オープンソース版もあるVTLソフトウェアQUADSTOR」という記事を作成したが、使ってはいなかった。

よく見てみたら、ローカルのテープ装置/テープライブラリとしてエミュレートしてくれる機能もあったので、NetBackup Linuxでテープライブラリを使う案件が来たついでに、練習のためQUADSTORを使ってみた。

QUADSTORの注意点

  • CGIを使うWebインタフェースのプログラム(標準はポート80使用)
  • Webインタフェースに認証機能がないので要注意（アクセスすれば誰でも消せます)
  • SELinux環境下で使う場合、後述のSELinuxコマンドを実行すること
  • 仮想テープのデータを保存する領域はRAWデバイスディスクが必要(OSからマウントされない)
  • QUADSTORの起動に時間がかかる（うちの環境では10分かかった)

セットアップ実施

セットアップは簡単で、「Installation/Upgrading on RHEL/CentOS 6/7, SLES 12 SP2 and Debian 7/8」に書いてあるものをそのまま実行した形である。

# yum install httpd gcc perl kernel-devel sg3_utils
# rpm -ivh quadstor-vtl-ext-3.0.31.1-rhel.x86_64.rpm

プログラムの自動起動で以下を実行

# systemctl enable httpd.service
# systemctl enable quadstorvtl.service

SELinux環境で動作するように下記の設定を実行

# setsebool -P httpd_enable_cgi 1
# semanage permissive -a httpd_t

なお「semanage」は標準ではインストールされていないので「yum install policycoreutils-python」を実行して、追加インストールする必要がある。

Webインタフェースにアクセスする為に、firewallに穴を開けます。

# firewall-cmd --permanent --zone=public --add-service=http

iSCSIデバイスとして動作するので、iSCSIで使用するポートについても設定します。

# firewall-cmd --permanent --zone=public --add-service=iscsi-target

また、Webインタフェースには認証機能がなく、誰でも使用できる状態であるため「Accessing the Web Management Interface」の「SECURING ACCESS TO THE WEB INTERFACE」に記載されているように.htpasswdを使ってアクセス制限をかけましょう。

QUADstorとhttpdを起動します。

# systemctl start quadstorvtl
# systemctl start httpd

起動後、Webインタフェースにアクセスすると、以下の様な感じの画面がでてきます。

「Server Status: Server initialized and running」となっていればQUADstorの起動が完了しています。

まず「Physical Storage」タブにアクセスすると、いまマウントされているなローカルディスクが表示されます。

[Add]をクリックし、下記画面からQUADstor管理下に設定します。

指定したディスクの初期化が始まります。

なお、初期化中にさらなる追加を行おうとすると「ERROR: Reply from server is “Cannot add a disk when another is being configured “」とエラーになります。

初期化が終わると、下記の様になります。(なお、表示は自動更新されるますので、ブラウザの手動更新は不要です)

もう片側のディスクも同様に登録し、完了するのを待ちます。

次に「Virtual Libraries」から「Add VTL」よりテープチェンジャーを作成します。

[Add VTL]をクリックし、作成するテープチェンジャの設定を指定します。

登録したテープチェンジャーは下記の様に見えます。

作成した状態では中にテープメディアが入っていない状態です。

テープメディアは「VCartridge Information」にある[Add VCartridge]から行います。

テープメディアの種類はLTOドライブの選択に従って自動的に行われています。

指定するのは、作成する本数(Number of VCartridges)と、メディアにつけるバーコードラベルの書式指定です。

バーコード書式は英数6文字で、例えばLTO1カートリッジを10本、ラベル:BK0000と指定した場合「BK0000L1」～「BK0009L1」のテープメディアが登録されることになります。

iSCSIのテープ装置としては作成されましたので、Linuxサーバから接続してみます。

CentOS7だったら、まずは「yum install iscsi-initiator-utils」で接続に必要なソフトウェアをインストールします。

続いて、iSCSI接続を永続化するため「systemctl enable iscsid」を実行します。

「iscsiadm -m discovery -t sendtargets -p ＜IPアドレス＞」を実行し、検出したあと、「iscsiadm -m node –login -p ＜IPアドレス＞」でログインします。

# iscsiadm -m discovery -t sendtargets -p ＜IPアドレス＞
# iscsiadm -m node --login -p ＜IPアドレス＞

接続するとLinux上からは下記の様に見えるようになります。

# cat /proc/scsi/scsi
＜略＞
Host: scsi34 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: ULT3580-TD1      Rev: D711
  Type:   Sequential-Access                ANSI  SCSI revision: 06
Host: scsi33 Channel: 00 Id: 00 Lun: 00
  Vendor: ADIC     Model: Scalar 24        Rev: 6.24
  Type:   Medium Changer                   ANSI  SCSI revision: 03
#

NetBackupのコマンドで確認してみると、下記の様にみえました。

# /usr/openv/volmgr/bin/tpautoconf -t
TPAC60 IBM     ULT3580-TD1     D711 2688700001 -1 -1 -1 -1 /dev/nst0 - -
# /usr/openv/volmgr/bin/tpautoconf -r
TPAC60 ADIC    Scalar 24       6.24 26887167A2DC4D54B8910000 -1 -1 -1 -1 /dev/sg4 - -
# /usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/sg4"
Passthru Name: "/dev/sg4"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "ADIC    Scalar 24       6.24"
Vendor ID  : "ADIC    "
Product ID : "Scalar 24       "
Product Rev: "6.24"
Serial Number: "26887167A2DC4D54B8910000"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "ADIC    26887167A2DC4D54B8910000"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-3
Number of Drives : 1
Number of Slots  : 20
Number of Media Access Ports: 1
Drive 1 Serial Number      : "2688700001"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst0"
Passthru Name: "/dev/sg3"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULT3580-TD1     D711"
Vendor ID  : "IBM     "
Product ID : "ULT3580-TD1     "
Product Rev: "D711"
Serial Number: "2688700001"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULT3580-TD1     2688700001"
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
#

ドキュメントを確認すると、「Data deduplication best practices」というのがあり、重複排除が行われた状態でRAWストレージに格納されている模様。

2019/11/01追記

QUADstorをアップデートする場合の注意点。

「rpm -Uvh quadstor*.rpm」といったアップデートはできない。

一度、アンインストールした上で、再インストールする必要がある。

ここまでは「Installation or Upgrading the VTL software」にも書かれているのだが、実際にやろうとするとスクリプトの実行に失敗する場合がある。

アンインストール時、quadstorによりinitrd imageに組み込まれたモジュールを削除するために、quadstorの停止とモジュールのアンロードが実施されるのだが、モジュールの使用状況によってはアンロードが失敗する場合がある。

その場合は、一度OSを再起動して、モジュールがロードされていない状態にしないとアンインストールができなかった。

CentOS7の場合、以下の手順で行った。

(1) 「systemctl mask quadstorvtl」で再起動時にQUADstorが起動しない様に設定(maskしなくでも大丈夫な場合もある)
(2) OS再起動
(3) 「rpm -ev quadstor-vtl-ext-3.0.36-rhel.x86_64」といった感じでパッケージ削除
(4) 「rpm -ivh quadstor-vtl-ext-3.0.37-rhel.x86_64.rpm」といった感じでパッケージインストール
(5) 「 systemctl unmask quadstorvtl」 「systemctl enable quadstorvtl」で有効化
(6) OS再起動

2021/10/21追記

QUADStorVTLではなくて普通のiSCSIストレージに接続するために、Oracle Linux 8環境で「iscsiadm -m discovery -t sendtarget -p IPアドレス」を実行したら何も見つからなかった。

RHEL6ドキュメントを見直してみると「-t sendtarget」ではなく「-t st」だったのでこちらでやってみたら通った。というメモ書き

[root@oraclelinux ~]# iscsiadm -m discovery -t sendtarget -p 172.17.73.21 -o new
iscsiadm: Discovery record [172.17.73.21,3260] not found!
[root@oraclelinux ~]# iscsiadm -m discovery -t sendtarget -p 172.17.73.21 -d 5
iscsiadm: Max file limits 1024 262144
iscsiadm: Could not open /var/lib/iscsi/send_targets/172.17.73.21,3260: No such file or directory
iscsiadm: Discovery record [172.17.73.21,3260] not found!
[root@oraclelinux ~]# iscsiadm -m discovery -t st -p 172.17.73.21 -o new
172.17.73.21:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.1.200:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.11.3:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.12.1:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
172.17.73.21:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.1.200:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.11.3:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.12.1:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
[root@oraclelinux ~]#