2020年12月31日木曜日

QNAPとOpenVPNを使って自宅にVPN接続する方法

インターネット経由で自宅のネットワークにアクセスできると何かと便利ではあるが、外からRDPやSSHで接続できるようポートを開けてしまうと、外部からの攻撃や乗っ取りのリスクが高まるため望ましくない。実際に身近でも、外からRDPで接続できるようポートを開けていたら、PCが乗っ取られてしまったというケースを聞いたことがある。

というわけで外部から自宅内ネットワークに安全にアクセスするために、VPNによるアクセスを実施することにした。具体的には、QNAPのNASをVPNサーバーとして設定し、WindowsやAndroidからVPNでリモート接続できるようにしてみた

QNAPのOpenVPNサーバの設定

本記事で掲載する画面キャプチャは、QTSバージョン:4.5.1のものとなるが、他バージョンでも、ほぼ同様の画面となっているはずだ。

1. QVPN Serviceのインストール

まず、QNAPのWeb管理画面にログインしたのちApp Centerを開き、「QVPN Service」をインストールする。

2. OpenVPNの設定

インストール後、QVPN Serviceを開く。VPNの方式として、「QBelt」、「PPTP」、「L2TP/IPsec (PSK)」、「OpenVPN」の4種類が選択可能だが、今回は「OpenVPN」を有効化するため、左メニューより「OpenVPN」を選択し、「OpenVPNサーバーを有効にする」にチェックを入れる。

その他の設定はデフォルトのままで問題ないため、「適用」ボタンを押して設定反映を行う。

3. OpenVPNのプロファイルファイルをダウンロード

次に、「設定ファイルのダウンロード (for QVPN v1.1 or newer)」ボタンをクリックし、<QNAPのホスト名>.ovpnというファイル名のファイルをダウンロードする。このファイルはOpenVPNの接続情報が記載されたテキストファイル (プロファイルファイル) となっており、接続に必要な証明書情報も含まれている。

ダウンロードしたプロファイルファイルをテキストエディタで開くと接続先情報がIPアドレス表記になっているので、DDNSなどで自宅のグローバルIPアドレスを名前解決できる場合は、FQDNの表記に修正しておく。これによって、プロバイダから割り当てられるIPアドレスが変更となった場合にも接続することができる。

remote 100.10.20.30 1194
   ↓
remote example.myqnapcloud.com 1194

4. OpenVPN接続ユーザの設定

左メニュー→「権限設定」にて、接続可能とするVPN接続ユーザを追加し、OpenVPNの項目にチェックを付ける。

ブロードバンドルータの設定

OpenVPNはUDPの1194ポートを使うため、ブロードバンドルータでポート開放を行う必要がある。設定方法は各社のルーターのマニュアルを確認すること。通常は「ポートマッピング」といった呼ばれ方の設定項目があるはずで、外部からの特定ポートのアクセスをLAN側の特定のサーバに転送する設定を行えばよい。

OpenVPNは1194/UDPで接続を行うため、以下のようなマッピング設定を行う。

  • LAN側ホスト:QNAPのIPアドレスを設定
  • LAN側ポート番号:1194/UDP
  • WAN側ポート番号:1194/UDP

Windows OSからの接続

1. OpenVPNクライアントをダウンロード

Windows OSの場合、まずは以下URLからOpenVPNクライアントをダウンロードする。自身の使っているWindows OSに合わせて、「Windowsインストーラ」の64bitまたは32bitのどちらかをダウンロードすればよい。

※なお、ダウンロードURLの注意書きに「vpnux Clientがお勧めです」との記載もあるので、そちらを利用してもよい。私はvpnux Clientは使ったことがないので、今回はOpenVPNを使って接続する。

2. OpenVPNクライアントをインストール

インストーラーを実行して、「Install Now」を押すだけでインストールは完了する。なお、途中でデバイスのインストールの警告が表示される場合は、「OK」を押してインストールを継続すればよい。

インストール後、「No readable connection profiles (config files) found.」という内容のポップアップが表示されるが、プロファイルファイルを配置していないことによるものであり、ファイル配置前となることから問題がないメッセージとなるため、「OK」を選択しておく。

3. プロファイルファイルの配置

インストール後、先ほどQNAPからダウロードした<QNAPのホスト名>.ovpnを以下パスに配置する。

C:\Program Files\OpenVPN\config

4. OpenVPNで接続

タスクトレイの「OpenVPN GUI」のアイコンを右クリック→「接続」を選択する。
※タスクトレイに表示されていない場合は、デスクトップの「OpenVPN GUI」のショートカットをダブルクリックし起動すること。

リモート接続を許可しているユーザとパスワードを入力することでOpenVPNによるVPN接続ができる。

なお、接続時に赤字で以下のような警告メッセージが表示されるが、これはAES-128-CBCが非推奨 (DEPRECATED) である旨のメッセージとなる。現時点のQNAPは残念ながら、AES-128-CBCまたはAES-256-CBCの2種類しか設定できないため、この警告は無視して接続するしか対処方法はない状況となる。

Thu Dec 31 08:04:10 2020 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Thu Dec 31 08:04:10 2020 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
Thu Dec 31 08:04:10 2020 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
Thu Dec 31 08:04:10 2020 Windows version 10.0 (Windows 10 or greater) 64bit
Thu Dec 31 08:04:10 2020 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10

Androidからの接続

1. OpenVPNクライアントをインストール

Androidの場合は、Google Play Storeから「OpenVPN Connect」を検索して、インストールをする。

2. プロファイルファイルのインポート

OpenVPN Connectを起動すると「Import Profile」画面が表示されるので、「File」タブ→QNAPからダウロードした<QNAPのホスト名>.ovpnを指定→「Import」ボタンを選択する。

リモート接続を許可しているユーザとパスワードを入力し、右上の「ADD」を選択する。

3. OpenVPNで接続

作成したプロファイルの選択し有効化することで接続が開始される。

「Connection request」のポップアップが表示された場合は「OK」を選択する。

「Select Certificate」が表示される場合は、「CONTINUE」と「SELECT CERTIFICATE」どちらを選択しても接続は成功するが、毎回接続時に確認されるのが面倒な場合は、「SELECT CERTIFICATE」を選択してデフォルトの証明書を選択しておけばよい。

正常に接続されれば、以下の通り「CONNECTED」と表示される。

まとめ

以上で、QNAPをVPNサーバーとして、外部からVPNすることに成功した。外出先から自宅環境のファイルを見たり、検証サーバーにアクセスしたり、非常に便利になった。

更新履歴

  • 2017/08/01 新規作成
  • 2020/12/31 最新の情報に合わせて、全体的に内容を更新
2020年12月26日土曜日

商用OSのEOSを調べてみた!2020年末版

 昨年以下記事でまとめた主要な商用OSのEOSについて、今年も調べてアップデートしてみた。結論を先に言うと、2021年中に完全にサポート終了となる製品はなかった。2021年はバージョンアップ対応をすることなく、比較的平和に過ごすことができそうだ。


・商用OSのEOSを調べてみた!2018年末版
https://tech-mmmm.blogspot.com/2018/12/oseos2018.html

・商用OSのEOSを調べてみた!2019年末版
https://tech-mmmm.blogspot.com/2019/12/oseos2019.html

2021年にサポート期限を迎える製品については、赤字で強調表示した。

なお、本記事で「EOS」と表現する場合は、製品として完全にすべてのサポートが終了する期限を指すことにする。例えば、通常サポートが終了しても延長サポートが存在するような場合は、EOSとは表現しない。

Windows (PC用)

2020年1月でWindows 7のサポートも終了したため、現時点でサポートが残っているWindows OSは、Windows 8.1とWindows 10の2つのみとなる。

・製品およびサービスのライフサイクル情報の検索
https://docs.microsoft.com/ja-jp/lifecycle/products/

・Windows 8.1
延長サポート:2023/01/10

・Windows 10
Windows 10は、今までのWindows OSとサポートポリシーが異なり、モダンライフサイクルポリシーが適用される。なお、今までの単純なメインストリームサポートと延長サポートの構成を「固定ライフサイクルポリシー」と呼ぶ。

・ライフサイクルに関する FAQ - Windows
https://docs.microsoft.com/ja-jp/lifecycle/faq/windows

モダンライフサイクルポリシーについて簡単に説明すると、Windows 10では3月と9月の年2回、機能更新プログラムのリリースが予定されており、この機能更新プログラムのリリースから18ヶ月(EnterpriseとEducationのみ9月更新は30ヶ月)が、その機能更新プログラムを適用したWindows 10のサポート期間となる。

機能更新プログラムは2020年4月まではYYMMの形式で表現されていたが、最新の2020年10月のアップデートからは20H2という名称になっている。2021年は21H1、21H2といった名称でリリースされることになる。

以下に現時点におけるサポート中のバージョンを以下に記載する。

・Windows 10, version 1909 サポート終了:2021/05/11
・Windows 10, version 2004 サポート終了:2021/12/14
・Windows 10, version 20H2 サポート終了:2022/05/10

Windows Server

Windows Serverは現時点で、Windows Server 2012、2012 R2、2016、2019の4つのバージョンがサポート中の状況となっている。2023年までサポート終了はないため、しばらくは平和に過ごすことができそうだ。

・製品およびサービスのライフサイクル情報の検索
https://docs.microsoft.com/ja-jp/lifecycle/products/

・Windows Server 2012 / Windows Server 2012 R2
延長サポート:2023/10/10

・Windows Server 2016
メインストリームサポート:2022/01/11
延長サポート:2027/01/11

・Windows Server 2019
メインストリームサポート:2024/01/09
延長サポート:2029/01/09

VMware vSphere

今年は新しいvSphereのバージョンはリリースされることなく過ぎてしまった。今回確認したところ、ESXi 6.7 / vCenter Server 6.7のGENERAL SUPPORTが1年後ろ倒しになっていた。また、2020年はvSphere 7がリリースされた年となった。

・Product Lifecycle Matrix
https://lifecycle.vmware.com/#/

・ESXi 6.0 / vCenter Server 6.0
END OF TECHNICAL GUIDANCE:2022/03/12

・ESXi 6.5 / vCenter Server 6.5
END OF GENERAL SUPPORT:2021/11/15
END OF TECHNICAL GUIDANCE:2023/11/15

・ESXi 6.7 / vCenter Server 6.7
END OF GENERAL SUPPORT:2021/11/15 → 2022/10/15
END OF TECHNICAL GUIDANCE:2023/11/15

・ESXi 7.0 / vCenter Server 7.0
END OF GENERAL SUPPORT:2025/04/02
END OF TECHNICAL GUIDANCE:2027/04/02

Red Hat Enterprise Linux

現在、RHEL 6は延長サポートフェーズのみとなっている。RHEL 7及び8の延長サポートフェーズ期限は現時点でも未発表となっていた。

・Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata

・Red Hat Enterprise Linux 6
End of Extended Life-cycle Support:2024/06/30

・Red Hat Enterprise Linux 7
End of Maintenance Support:2024/06/30
End of Extended Life-cycle Support:未発表

・Red Hat Enterprise Linux 8
End of Maintenance Support:2029/05/31
End of Extended Life-cycle Support:未発表

AIX

AIXはTL (Technology Level)毎にサポート期限が異なる。本記事では各メジャーバージョンの最新TLのEOSを記載する。なお、2020年11月にAIX 7.2 TL5がリリースされており、結果的にサポート期限が1年延長している。

・AIX support lifecycle information
https://www.ibm.com/support/pages/node/670775

・AIX 7.1 TL5
End of Service Pack Support :2023/04/30 (予想)

・AIX 7.2 TL5
End of Service Pack Support :2023/11/30 (予想)

HP-UX

HP-UXはあまり頻繁なバージョンアップはなく、2007年4月に発表されたHP-UX 11i v3が未だに最新という状況となっている。HP-UX 11i v2のサポート期限が1年延長したようだ。

・HP-UXのサポートポリシー | HPE 日本
https://www.hpe.com/jp/ja/servers/hp-ux/support-policy.html

・HP-UX 11i v2
延長サポート(開発元支援なし) 終了:2021/12月 → 2022/12月

・HP-UX 11i v3
標準サポート終了:未発表

参考

・End Of Support (EOS) の調べ方
https://tech-mmmm.blogspot.jp/2015/04/end-of-support-eos.html
2020年12月22日火曜日

ESXiの仮想ネットワークアダプタ「E1000e」は、1Gbps以上の速度が出る

ESXi 6.7の仮想環境において、主に使用される仮想ネットワークアダプタ (以下、仮想NIC) は以下となっている。
※()内は、各NICのリンクスピードを示す。

  • E1000e (1Gbps)
  • VMXNET 3 (10Gbps)

近年の仮想環境では、10Gbps以上の物理ネットワーク接続が主流になっているので、仮想マシンのおいても1Gbps以上の通信を必要とする場合は、リンクスピードが10GbpsとなっているVMXNET 3を利用する必要があると思っていた。

しかし、実際にはそうではなく、E1000eのような1Gbpsの仮想NICであっても、それ以上の通信速度が出る。今回、それを確かめるため、速度測定を実施してみた。

測定環境

測定環境は①VMXNET 3と②E1000eの2種類のNICを持つNFSサーバを用意し、それぞれのNICに対してNFSマウントを行った際のファイル転送速度を計測する。

ファイル転送はNFSクライアント側にてddコマンドにて5GBのファイル作成を行う。NFSサーバ側では、dstatコマンドにて受信時の転送速度を計測する。

測定結果

① VMXNET 3の場合

まずはVMXNET 3の測定を行う。ethtoolコマンドでNICのリンクスピードを確認すると、10000Mb/s = 10Gbpsのリンクスピードとなっている。

# ethtool ens256 | grep Speed
        Speed: 10000Mb/s

VMXNET 3のNICに付与されているIPアドレスに対してNFSマウントを行い、ddコマンドで5GBのファイルを作成した際の転送速度を計測する。

まず、ファイル送信側のddコマンドの結果は、1.0 GB/sとなった。

# dd bs=100M count=50 if=/dev/zero of=/nfs/testfile
50+0 レコード入力
50+0 レコード出力
5242880000 バイト (5.2 GB) コピーされました、 5.21289 秒、 1.0 GB/秒

受信側となるNFSサーバでdstatにて計測した結果も以下の通り、ネットワーク受信速度を表す「recv」の値が約1GB/sとなっている。これはVMXNET 3が10Gbpsの仮想NICであるため、なんら不思議なことではない。

usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  0  45  44   6   0   4|   0   785M| 793M 1010k|   0     0 |  20k   11k
  0  46  42   7   0   5|   0   899M|1010M 1282k|   0     0 |  19k   21k
  0  43  46   8   0   3|   0   952M| 875M 1071k|   0     0 |  15k   16k
  0  53  39   4   0   5|   0   983M|1040M 1298k|   0     0 |  16k   14k
  0  40  48   8   0   5|   0   863M| 822M  986k|   0     0 |  15k   18k
  0  26  68   4   0   2|   0   518M| 470M  581k|   0     0 |8190  7893

② E1000eの場合

次に、E1000eの測定を行う。NICのリンクスピードを確認すると、1000Mb/s = 1Gbpsとなっていることがわかる。

# ethtool ens224 | grep Speed
        Speed: 1000Mb/s

E1000eのNICに付与されているIPアドレスに対してNFSマウントを行い、ddコマンドで5GBのファイルを作成した際の転送速度を計測する。

まず、ファイル送信側のddコマンドの結果は、1.0 GB/sとなった。

# dd bs=100M count=50 if=/dev/zero of=/nfs/testfile
50+0 レコード入力
50+0 レコード出力
5242880000 バイト (5.2 GB) コピーされました、 5.22793 秒、 1.0 GB/秒

受信側となるNFSサーバでdstatにて計測した結果も、recvの値が約1GB/sとなっている。

usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  0  43  48   5   0   4|   0   897M| 929M 1195k|   0     0 |  22k   15k
  0  32  56   9   0   4|   0   825M| 833M 1060k|   0     0 |  19k   22k
  0  40  46  11   0   4|   0   968M| 947M 1198k|   0     0 |  22k   33k
  0  39  49  10   0   3|   0   918M| 912M 1148k|   0     0 |  18k   30k
  0  45  43   7   0   4|   0  1059M|1061M 1369k|   0     0 |  22k   29k
  0  14  82   4   0   1|   0   333M| 327M  437k|   0     0 |6957    11k

結果、リンクスピードが1GbpsとなっているE1000eを選択したとしても、VMXNET 3と同様に1Gbps以上で通信できることが確認できた

まとめ

以上より、ESXiの仮想環境の仮想NICは、リンクスピードが通信速度の上限となるわけではなく、それ以上の通信速度が出せることがわかった。

ESXiでは仮想マシン作成時に、選択したOSに合わせて適切な仮想NICがデフォルトで選ばれるようになっているので、特に理由がなければ変更せずに使っても問題なく動作する。しかし、一般的にはE1000eよりもVMXNET 3を選択する方がパフォーマンスが向上すると言われているため、ネットワークのパフォーマンスがシビアな環境ではVMXNET 3に変えることも考慮した方がよいだろう。

参考

2020年12月20日日曜日

Zabbix Agent2を使ってDockerコンテナを監視する

Zabbix 5.0以降から正式サポートされるようになったZabbix Agent2では、DockerホストにインストールすることでDockerコンテナを監視することができる。本記事では、その手順を記載する。

手順

1. DockerホストにZabbix Agent2をインストール

Zabbix Agent2は、zabbix-releaseのrpmパッケージをインストールしたのち、dnfを使うことでインストールできる。

# rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm
# dnf install zabbix-agent2 -y

2. Zabbix Agent2の設定ファイルを修正

設定ファイルは「/etc/zabbix/zabbix_agent2.conf」となる。以下3行を環境に合わせて修正する。

# vi /etc/zabbix/zabbix_agent2.conf
Server=<Zabbix ServerのIPアドレス>
ServerActive=<Zabbix ServerのIPアドレス>
Hostname=<ホスト名>

sedで修正する場合は、以下のように実行する。

# sed -i.org \
-e 's/^\(Server.*=\).*$/\1<Zabbix ServerのIPアドレス>/g' \
-e 's/^\(Hostname=\).*$/\1<ホスト名>/g' \
/etc/zabbix/zabbix_agent2.conf

3. dockerグループにzabbixユーザを追加

Zabbix Agent2はDockerコンテナの情報を取得する際に、「/var/run/docker.sock」にアクセスする。このファイルは以下の通りrootまたはdockerグループに所属するユーザでなければアクセスすることができない

# ls -l /var/run/docker.sock
srw-rw----. 1 root docker 0 12月  6 15:53 /var/run/docker.sock

Zabbix Agent2はzabbixユーザ権限で実行されるため、そのままでは「/var/run/docker.sock」のアクセスに失敗する。そこで、zabbixユーザをdockerグループに所属させることで対処する。

# usermod -aG docker zabbix
# cat /etc/group | grep docker
docker:x:990:zabbix

上記設定を実施しなかった場合、「Cannot fetch data.」というエラーがZabbix上に表示される。トラブルシュート時の参考情報を後述しているので、必要であれば確認いただきたい。

4. Zabbix Agent2のサービスを起動

設定ファイルを修正後、Zabbix Agent2を起動させる。

# systemctl start zabbix-agent2
# systemctl enable zabbix-agent2
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-agent2.service → /usr/lib/systemd/system/zabbix-agent2.service.

5. Dockerホストに「Template App Docker」のテンプレートを適用

Zabbix 5.0に「Template App Docker」というテンプレートが存在するので、Dockerホストとなるホストにテンプレートを適用する。

6. コンテナの情報がディスカバリされるのを待つ

ディスカバリは15分間隔で実行されるので待機する。

15分経過したのち「監視データ」→「最新のデータ」にてDockerホストのデータを確認し、コンテナの情報が取得できていれば問題ない。

以下の図では、「centos-squid」という名前のコンテナのCPUやメモリ使用率が取得できていることが確認できる。

【参考1】「Cannot fetch data.」のエラーでコンテナの情報取得に失敗する

zabbixユーザの権限不足によりDockerコンテナの情報取得に失敗した場合、以下のエラーがZabbixのGUI上に表示される。

Cannot fetch data.

zabbix_getコマンドを使うことで、接続確認をすることができるが、同様に「Cannot fetch data.」のエラーで失敗する。

# zabbix_get -s 192.168.33.28 -k docker.info
ZBX_NOTSUPPORTED: Cannot fetch data.

手順に記載した通り、zabbixユーザをdockerグループに所属させることで解消できる。ただし、権限の設定を行ってもzabbix_getコマンドの結果は同じエラーとなり改善しなかったので、権限設定後に必ずZabbix Agent2のサービス再起動をすること

# usermod -aG docker zabbix
# cat /etc/group | grep docker
docker:x:990:zabbix
# systemctl restart zabbix-agent2

再度、zabbix_getコマンドで確認すると、以下の通り情報取得ができるようになったことが確認できた。

# zabbix_get -s 192.168.33.28 -k docker.info | jq
{
  "Id": "TYHR:QZBY:IUDW:3SAK:MXV3:FXPW:A3U3:CS5M:WKUC:5NMO:CAJ3:6ZVV",
  "Containers": 3,
  "ContainersRunning": 3,

~(中略)~

  "InitBinary": "docker-init",
  "SecurityOptions": [
    "name=seccomp,profile=default"
  ],
  "Warnings": null
}

【参考2】Zabbix 5.0より前のバージョンにおけるDockerコンテナの監視方法

Zabbix 5.0より前のバージョンでは、「Zabbix Docker Monitoring」と呼ばれるコンテナ監視用のコンテナを起動させて監視するという方法で実現していたようだ。こちらの手法については、以下URLを参照いただきたい。

参考

2020年12月19日土曜日

TrueNAS CORE 12.0にopen-vm-toolsをインストールする

2020年12月現在、FreeNASは11.3が最新バージョンとなるが、次期バージョンからはTrueNASに統合されることが発表されている。

TrueNASはFreeNASとインストール手順や操作手順はほぼ同一となるよう構成されているので、FreeNASを使っていればTrueNASの構築は特に苦労することなく実施できるだろう。

ただし、ひとつ違いがあり、FreeNASにはデフォルトでインストールされていたopen-vm-toolsが、TrueNASには導入されていない。ESXi上の仮想マシンとしてTrueNASをインストールする場合は不便なので、手動でインストールする手順を確認してみた。

環境

  • ESXi 6.7
  • TrueNAS 12.0

手順

1. pkgのリポジトリ設定を修正

TrueNASはFreeBSDベースのストレージOSとなる。FreeBSDではyumでもaptでもなくpkgによるパッケージ管理を行う。

しかし、TrueNASではpkgの外部リポジトリの設定がデフォルトで無効化されているため、pkgコマンドを実行してもエラーになる。そこで、外部リポジトリの設定を有効化させるため、「/usr/local/etc/pkg/repos/」配下の以下2つの設定ファイルをsedにて修正する

# sed -ie 's/enabled: yes/enabled: no/g' /usr/local/etc/pkg/repos/local.conf
# sed -ie 's/enabled: no/enabled: yes/g' /usr/local/etc/pkg/repos/FreeBSD.conf

念のため、修正後のファイルを確認しておく。「FreeBSD.conf」の設定がenabled: yesになっていることを確認する。

# cat /usr/local/etc/pkg/repos/local.conf
local: {
    url: "file:///usr/ports/packages",
    enabled: no
}
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
    enabled: yes
}

2. pkgにてopen-vm-toolsをインストール

pkg updateを実行し、リポジトリへアクセスできることを確認しておく。

# pkg update
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   6.7MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 31973 packages processed.
All repositories are up to date.

問題なければ、pkg install open-vm-tools-nox11でインストールを行う。

# pkg install open-vm-tools-nox11
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.14.6 -> 1.15.10 [FreeBSD]

Number of packages to be upgraded: 1

The operation will free 31 MiB.
7 MiB to be downloaded.

Proceed with this action? [y/N]: y ←★yを入力
[1/1] Fetching pkg-1.15.10.txz: 100%    7 MiB   6.9MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.14.6 to 1.15.10...
[1/1] Extracting pkg-1.15.10: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        open-vm-tools-nox11: 11.0.1_3,2 -> 11.1.5,2 [FreeBSD]

Number of packages to be upgraded: 1

The process will require 2 MiB more space.
1 MiB to be downloaded.

Proceed with this action? [y/N]: y ←★yを入力
[1/1] Fetching open-vm-tools-nox11-11.1.5,2.txz: 100%    1 MiB   1.3MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading open-vm-tools-nox11 from 11.0.1_3,2 to 11.1.5,2...
[1/1] Extracting open-vm-tools-nox11-11.1.5,2: 100%

3. TrueNASを再起動

最後にTrueNASを再起動して完了となる。

# reboot

4. ESXiでVMware Toolsの動作を確認

最後にTrueNASをインストールしたESXiにて仮想マシンの情報を確認し、VMware Toolsとしてopen-vm-toolsを認識していればOKとなる。


参考

人気の投稿