Amazon Linux 2、CentOS、RHEL、Rocky Linux への Linux VDA の手動インストール
重要:
新規インストールの場合、迅速なインストールには 簡易インストール の使用をお勧めします。簡易インストールは時間と労力を節約し、この記事で詳述されている手動インストールよりもエラーが発生しにくいです。
ステップ 1: 構成情報と Linux マシンの準備
ステップ 1a: ネットワーク構成の確認
ネットワークが正しく接続され、構成されていることを確認してください。たとえば、Linux VDA で DNS サーバーを構成する必要があります。
ステップ 1b: ホスト名の設定
マシンのホスト名が正しく報告されるように、/etc/hostname ファイルをマシンのホスト名のみを含むように変更します。
hostname
ステップ 1c: ホスト名へのループバックアドレスの割り当て
マシンの DNS ドメイン名と完全修飾ドメイン名 (FQDN) が正しく報告されるように、/etc/hosts ファイルの次の行を、FQDN とホスト名を最初の 2 つのエントリとして含むように変更します。
127.0.0.1 hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4
例:
127.0.0.1 vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4
ファイル内の他のエントリから、hostname-fqdn または hostname への他の参照をすべて削除します。
注:
Linux VDA は現在、NetBIOS 名の切り捨てをサポートしていません。ホスト名は 15 文字を超えてはなりません。
ヒント:
a~z、A~Z、0~9、およびハイフン (-) 文字のみを使用してください。アンダーバー (_)、スペース、およびその他の記号は避けてください。ホスト名を数字で始めたり、ハイフンで終わらせたりしないでください。このルールは、Delivery Controller のホスト名にも適用されます。
ステップ 1d: ホスト名の確認
ホスト名が正しく設定されていることを確認します。
hostname
<!--NeedCopy-->
このコマンドは、マシンのホスト名のみを返し、完全修飾ドメイン名 (FQDN) は返しません。
FQDN が正しく設定されていることを確認します。
hostname -f
<!--NeedCopy-->
このコマンドは、マシンの FQDN を返します。
ステップ 1e: 名前解決とサービス到達可能性の確認
FQDN を解決し、ドメインコントローラーと Delivery Controller™ に ping を実行できることを確認します。
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
- FQDN を解決できない場合、またはこれらのマシンのいずれかに ping を実行できない場合は、続行する前に手順を確認してください。
ステップ 1f: クロック同期の構成
VDA、Delivery Controller、およびドメインコントローラー間の正確なクロック同期を維持することは非常に重要です。Linux VDA を仮想マシン (VM) としてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモートタイムサービスとの時刻同期が推奨されます。
RHEL のデフォルト環境では、クロック同期に Chrony デーモン (chronyd) を使用します。
Chrony サービスの構成
root ユーザーとして、/etc/chrony.conf を編集し、各リモートタイムサーバーのサーバーエントリを追加します。
server peer1-fqdn-or-ip-address iburst
server peer2-fqdn-or-ip-address iburst
<!--NeedCopy-->
通常の展開では、パブリック NTP プールサーバーから直接ではなく、ローカルのドメインコントローラーから時刻を同期します。ドメイン内の各 Active Directory ドメインコントローラーのサーバーエントリを追加します。
-
ループバック IP アドレス、localhost、およびパブリックサーバー *.pool.ntp.org のエントリを含む、リストされている他のサーバーエントリをすべて削除します。
-
変更を保存し、Chrony デーモンを再起動します。
sudo /sbin/service chronyd restart
<!--NeedCopy-->
ステップ 1g: PulseAudio のインストール (RHEL 9.0 および Rocky Linux 9.0 のみ)
pulseaudio をインストールするには、次のコマンドを実行します。
sudo yum -y install pulseaudio --allowerasing
<!--NeedCopy-->
/etc/pulse/client.conf を開き、次のエントリを追加します。
autospawn = yes
<!--NeedCopy-->
ステップ 1h: OpenJDK 11 のインストール
Linux VDA には OpenJDK 11 が必要です。
- CentOS、RHEL、または Rocky Linux を使用している場合、OpenJDK 11 は Linux VDA のインストール時に依存関係として自動的にインストールされます。
-
Amazon Linux 2 を使用している場合は、OpenJDK 11 を有効にしてインストールするために次のコマンドを実行します。
amazon-linux-extras install java-openjdk11 <!--NeedCopy-->
正しいバージョンを確認します。
sudo yum info java-11-openjdk
<!--NeedCopy-->
プリパッケージされた OpenJDK は以前のバージョンである可能性があります。OpenJDK 11 に更新します。
sudo yum -y update java-11-openjdk
<!--NeedCopy-->
ステップ 1i: 使用するデータベースのインストールと指定
実験的な機能として、PostgreSQL に加えて SQLite を使用できます。Linux VDA パッケージのインストール後に /etc/xdl/db.conf を編集することで、SQLite と PostgreSQL を切り替えることもできます。手動インストールの場合、SQLite と PostgreSQL を切り替えるには、それらを事前に手動でインストールする必要があります。
このセクションでは、PostgreSQL および SQLite データベースのインストール方法と、使用するデータベースの指定方法について説明します。
注:
VDI モードでのみ SQLite を使用することをお勧めします。
PostgreSQL のインストール
Linux VDA には PostgreSQL が必要です。
- Amazon Linux 2、RHEL 7、CentOS 7 用 PostgreSQL 9
- RHEL 8.x および Rocky Linux 8.x 用 PostgreSQL 10
- RHEL 9.0 および Rocky Linux 9.0 用 PostgreSQL 13
PostgreSQL をインストールするには、次のコマンドを実行します。
sudo yum -y install postgresql-server
sudo yum -y install postgresql-jdbc
<!--NeedCopy-->
RHEL 8.x および RHEL 9.0 の場合は、次のコマンドを実行して PostgreSQL 用の libpq をインストールします。
sudo yum -y install libpq
<!--NeedCopy-->
データベースを初期化するには、次のコマンドを実行します。この操作により、データベースファイルが /var/lib/pgsql/data の下に作成されます。
sudo postgresql-setup initdb
<!--NeedCopy-->
マシンの起動時、またはすぐに PostgreSQL を起動するには、それぞれ次のコマンドを実行します。
- sudo systemctl enable postgresql
- sudo systemctl start postgresql
<!--NeedCopy-->
次のコマンドを使用して PostgreSQL のバージョンを確認します。
psql --version
<!--NeedCopy-->
(RHEL 7 のみ)psql コマンドラインユーティリティを使用して、データディレクトリが設定されていることを確認します。
sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->
SQLite のインストール
SQLite をインストールするには、次のコマンドを実行します。
sudo yum -y install sqlite
<!--NeedCopy-->
使用するデータベースの指定
SQLite、PostgreSQL、またはその両方をインストールした後、Linux VDA パッケージのインストール後に /etc/xdl/db.conf を編集して、使用するデータベースを指定できます。これを行うには、次の手順を完了します。
-
/opt/Citrix/VDA/sbin/ctxcleanup.shを実行します。新規インストールの場合、この手順は省略します。 -
/etc/xdl/db.confを編集して、使用するデータベースを指定します。 -
ctxsetup.shを実行します。
注:
/etc/xdl/db.conf を使用して、PostgreSQL のポート番号を構成することもできます。
手順 2:ハイパーバイザーの準備
サポートされているハイパーバイザー上で Linux VDA を VM として実行する場合、いくつかの変更が必要です。使用中のハイパーバイザープラットフォームに基づいて、次の変更を行います。Linux マシンをベアメタルハードウェアで実行している場合、変更は不要です。
Citrix Hypervisor™ での時刻同期の修正
Citrix Hypervisor の時刻同期機能が有効になっている場合、各準仮想化 Linux VM 内で NTP と Citrix Hypervisor の両方がシステムクロックを管理しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各 Linux ゲスト内のシステムクロックが NTP と同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。HVM モードでは変更は不要です。
Citrix VM Tools がインストールされた準仮想化 Linux カーネルを実行している場合、Linux VM 内から Citrix Hypervisor の時刻同期機能が存在し、有効になっているかどうかを確認できます。
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは 0 または 1 を返します。
- 0 - 時刻同期機能が有効になっており、無効にする必要があります。
- 1 - 時刻同期機能が無効になっており、それ以上の操作は不要です。
/proc/sys/xen/independent_wallclock ファイルが存在しない場合、以下の手順は不要です。
有効になっている場合、ファイルに 1 を書き込むことで時刻同期機能を無効にします。
sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
この変更を再起動後も永続的にするには、/etc/sysctl.conf ファイルを編集し、次の行を追加します。
xen.independent_wallclock = 1
これらの変更を確認するには、システムを再起動します。
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは値 1 を返します。
Microsoft Hyper-V での時刻同期の修正
Hyper-V Linux Integration Services がインストールされている Linux VM は、Hyper-V の時刻同期機能を使用してホストオペレーティングシステムの時刻を使用できます。システムクロックが正確であることを保証するには、NTP サービスと並行してこの機能を有効にする必要があります。
管理オペレーティングシステムから:
- Hyper-V マネージャーコンソールを開きます。
- Linux VM の設定で、Integration Services を選択します。
- Time synchronization が選択されていることを確認します。
注:
このアプローチは、NTP との競合を避けるためにホストの時刻同期が無効になっている VMware および Citrix Hypervisor とは異なります。Hyper-V の時刻同期は、NTP の時刻同期と共存し、補完することができます。
ESX および ESXi での時刻同期の修正
VMware の時刻同期機能が有効になっている場合、各準仮想化 Linux VM 内で NTP とハイパーバイザーの両方がシステムクロックを同期しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各 Linux ゲスト内のシステムクロックが NTP と同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。
VMware Tools がインストールされた準仮想化 Linux カーネルを実行している場合:
- vSphere Client を開きます。
- Linux VM の設定を編集します。
- Virtual Machine Properties ダイアログで、Options タブを開きます。
- VMware Tools を選択します。
- Advanced ボックスで、Synchronize guest time with host のチェックを外します。
手順 3:Linux VM を Windows ドメインに追加
Linux マシンを Active Directory (AD) ドメインに追加するには、次の方法が利用できます。
- [Samba Winbind](/ja-jp/linux-virtual-delivery-agent/2301/installation-overview/manual-installation-overview/redhat.html#samba-winbind)
選択した方法に基づいて指示に従ってください。
注:
Linux VDA のローカルアカウントと AD のアカウントで同じユーザー名を使用すると、セッションの起動に失敗する可能性があります。
Samba Winbind
必要なパッケージをインストールまたは更新します。
RHEL 8.x/9.0 および Rocky Linux 8.x/9.0 の場合:
sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->
Amazon Linux 2、CentOS 7、およびRHEL 7の場合:
sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir
<!--NeedCopy-->
Winbindデーモンのマシン起動時開始設定
Winbindデーモンは、マシンの起動時に開始するように構成する必要があります。
sudo /sbin/chkconfig winbind on
<!--NeedCopy-->
Winbind認証の構成
Winbindを使用してKerberos認証用にマシンを構成します。
-
次のコマンドを実行します。
RHEL 8.x/9.0およびRocky Linux 8.x/9.0の場合:
sudo authselect select winbind with-mkhomedir --force <!--NeedCopy-->Amazon Linux 2、CentOS 7、およびRHEL 7の場合:
sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall <!--NeedCopy-->ここで、REALMはKerberosレルム名(大文字)、domainはドメインのNetBIOS名です。
KDCサーバーとレルム名のDNSベースのルックアップが必要な場合は、前のコマンドに次の2つのオプションを追加します。
--enablekrb5kdcdns --enablekrb5realmdnsauthconfigコマンドから返される、winbindサービスが起動に失敗したというエラーは無視してください。これらのエラーは、マシンがまだドメインに参加していない状態でauthconfigがwinbindサービスの起動を試みたときに発生する可能性があります。 -
/etc/samba/smb.confを開き、
[Global]セクションのauthconfigツールによって生成されたセクションの後に、次のエントリを追加します。kerberos method = secrets and keytabwinbind refresh tickets = truewinbind offline logon = no -
(RHEL 8.x/9.0およびRocky Linux 8.x/9.0のみ)/etc/krb5.confを開き、
[libdefaults]、[realms]、および[domain_realm]セクションにエントリを追加します。[libdefaults]セクションの下:default_ccache_name = FILE:/tmp/krb5cc_%{uid}default_realm = REALMdns_lookup_kdc = true[realms]セクションの下:REALM = {kdc = fqdn-of-domain-controller}[domain_realm]セクションの下:realm = REALM.realm = REALM
Linux VDAは、Delivery Controllerで認証および登録するために、システムキータブファイル/etc/krb5.keytabを必要とします。以前のKerberosメソッド設定により、マシンが最初にドメインに参加したときにWinbindがシステムキータブファイルを作成するよう強制されます。
Windowsドメインへの参加
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
RHEL 8.x/9.0およびRocky Linux 8.x/9.0の場合:
sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->
Amazon Linux 2およびRHEL 7の場合:
sudo net ads join REALM -U user
<!--NeedCopy-->
REALMはKerberosレルム名(大文字)、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。
Winbind用PAMの構成
デフォルトでは、Winbind PAMモジュール(pam_winbind)の構成では、Kerberosチケットキャッシュとホームディレクトリの作成が有効になっていません。/etc/security/pam_winbind.confを開き、[Global]セクションに次のエントリを追加または変更します。
krb5_auth = yes
krb5_ccache_type = FILE
mkhomedir = yes
各設定の先頭にあるセミコロンが削除されていることを確認してください。これらの変更には、Winbindデーモンの再起動が必要です。
sudo /sbin/service winbind restart
<!--NeedCopy-->
ヒント:
winbindデーモンは、マシンがドメインに参加している場合にのみ実行を継続します。
/etc/krb5.confを開き、[libdefaults]セクションの次の設定をKEYRINGからFILEタイプに変更します。
default_ccache_name = FILE:/tmp/krb5cc_%{uid}
RHEL 9.0およびRocky Linux 9.0の場合、pam_winbindがルートディレクトリの所有権を変更するのを防ぎ、WinbindのSELinuxの問題を解決するために、次のコマンドを実行します。
- usermod -d /nonexistent nobody
ausearch -c 'winbindd' --raw | audit2allow -M my-winbindd -p /etc/selinux/targeted/policy/policy.*
semodule -X 300 -i my-winbindd.pp
<!--NeedCopy-->
- #### ドメインメンバーシップの確認
Delivery Controllerは、すべてのVDAマシン(WindowsおよびLinux VDA)がActive Directoryにコンピューターオブジェクトを持っていることを要求します。
Sambaのnet adsコマンドを実行して、マシンがドメインに参加していることを確認します。
sudo net ads testjoin
<!--NeedCopy-->
追加のドメインおよびコンピューターオブジェクト情報を確認するには、次のコマンドを実行します。
sudo net ads info
<!--NeedCopy-->
Kerberos構成の確認
KerberosがLinux VDAで使用するために正しく構成されていることを確認するには、システムキータブファイルが作成され、有効なキーが含まれていることを確認します。
sudo klist -ke
<!--NeedCopy-->
このコマンドは、プリンシパル名と暗号スイートのさまざまな組み合わせで利用可能なキーのリストを表示します。Kerberos kinitコマンドを実行して、これらのキーを使用してマシンをドメインコントローラーで認証します。
sudo kinit -k MACHINE\$@REALM
<!--NeedCopy-->
マシン名とレルム名は大文字で指定する必要があります。シェルによる置換を防ぐため、ドル記号 ($) はバックスラッシュ (\) でエスケープする必要があります。一部の環境では、DNS ドメイン名が Kerberos レルム名と異なる場合があります。レルム名が使用されていることを確認してください。このコマンドが成功した場合、出力は表示されません。
マシンアカウントの TGT チケットがキャッシュされていることを、以下を使用して確認します。
sudo klist
<!--NeedCopy-->
以下を使用して、マシンのアカウントの詳細を調べます。
sudo net ads status
<!--NeedCopy-->
wbinfo ツールを使用して、ドメインユーザーがドメインで認証できることを確認します。
wbinfo --krb5auth=domain\\username%password
<!--NeedCopy-->
ここで指定するドメインは AD ドメイン名であり、Kerberos レルム名ではありません。bash シェルの場合、バックスラッシュ (\) 文字は別のバックスラッシュでエスケープする必要があります。このコマンドは、成功または失敗を示すメッセージを返します。
Winbind PAM モジュールが正しく構成されていることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用して Linux VDA にログオンします。
ssh localhost -l domain\\username
id -u
<!--NeedCopy-->
Kerberos 資格情報キャッシュ内のチケットが有効で、期限切れになっていないことを確認します。
klist
<!--NeedCopy-->
セッションを終了します。
exit
<!--NeedCopy-->
同様のテストは、Gnome または KDE コンソールに直接ログオンすることで実行できます。ドメイン参加の確認後、手順 6:Linux VDA のインストールに進みます。
Quest Authentication Services
ドメインコントローラーでの Quest の構成
Active Directory ドメインコントローラーに Quest ソフトウェアをインストールして構成済みであり、Active Directory でコンピューターオブジェクトを作成するための管理者権限が付与されているものとします。
ドメインユーザーの Linux VDA マシンへのログオンを有効にする
ドメインユーザーが Linux VDA マシンで HDX™ セッションを確立できるようにするには:
- Active Directory ユーザーとコンピューター管理コンソールで、そのユーザーアカウントの Active Directory ユーザープロパティを開きます。
- [Unix Account] タブを選択します。
- [Unix-enabled] をオンにします。
- [Primary GID Number] を実際のドメインユーザーグループのグループ ID に設定します。
注:
これらの手順は、コンソール、RDP、SSH、またはその他のリモートプロトコルを使用してログオンするドメインユーザーを設定する場合にも同様に適用されます。
Linux VDA での Quest の構成
SELinux ポリシー強制の回避策
- デフォルトの RHEL 環境では、SELinux が完全に強制されます。この強制は、Quest が使用する Unix ドメインソケット IPC メカニズムと干渉し、ドメインユーザーのログオンを妨げます。
この問題を回避する便利な方法は、SELinux を無効にすることです。root ユーザーとして、/etc/selinux/config を編集し、SELinux の設定を変更します。
SELINUX=permissive
この変更にはマシンの再起動が必要です。
reboot
<!--NeedCopy-->
重要:
この設定は慎重に使用してください。無効にした後に SELinux ポリシー強制を再度有効にすると、root ユーザーや他のローカルユーザーであっても、完全にロックアウトされる可能性があります。
VAS デーモンの構成
Kerberos チケットの自動更新は有効にして切断する必要があります。認証(オフラインログオン)は無効にする必要があります。
sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400
sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->
このコマンドは、更新間隔を 9 時間(32,400 秒)に設定します。これは、デフォルトの 10 時間のチケット有効期間より 1 時間短いです。チケット有効期間が短いシステムでは、このパラメーターをより低い値に設定してください。
PAM と NSS の構成
HDX および su、ssh、RDP などの他のサービスを介したドメインユーザーログオンを有効にするには、次のコマンドを実行して PAM と NSS を手動で構成します。
sudo /opt/quest/bin/vastool configure pam
sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->
Windows ドメインへの参加
Quest の vastool コマンドを使用して、Linux マシンを Active Directory ドメインに参加させます。
sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->
ユーザーは、コンピューターを Active Directory ドメインに参加させる権限を持つ任意のドメインユーザーです。domain-name は、ドメインの DNS 名です(例:example.com)。
ドメインメンバーシップの確認
Delivery Controller では、すべての VDA マシン(Windows および Linux VDA)が Active Directory にコンピューターオブジェクトを持っている必要があります。Quest に参加している Linux マシンがドメイン上にあることを確認するには:
sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->
マシンがドメインに参加している場合、このコマンドはドメイン名を返します。マシンがどのドメインにも参加していない場合、次のエラーが表示されます。
ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain
ユーザー認証の確認
Quest が PAM を介してドメインユーザーを認証できることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用して Linux VDA にログオンします。
ssh localhost -l domain\\username
id -u
<!--NeedCopy-->
id -u コマンドによって返された UID に対応する Kerberos 資格情報キャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Kerberos 資格情報キャッシュ内のチケットが有効で、期限切れになっていないことを確認します。
/opt/quest/bin/vastool klist
<!--NeedCopy-->
セッションを終了します。
exit
<!--NeedCopy-->
同様のテストは、GnomeまたはKDEコンソールに直接ログオンして実行できます。ドメイン参加の検証後、手順6:Linux VDAのインストールに進みます。
Centrify DirectControl
Windowsドメインへの参加
Centrify DirectControlエージェントがインストールされている場合、Centrifyのadjoinコマンドを使用してLinuxマシンをActive Directoryドメインに参加させます。
- su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->
ユーザーパラメーターは、コンピューターをActive Directoryドメインに参加させる権限を持つActive Directoryドメインユーザーです。domain-nameは、Linuxマシンを参加させるドメインの名前です。
ドメインメンバーシップの確認
Delivery Controllerは、すべてのVDAマシン(WindowsおよびLinux VDA)がActive Directory内にコンピューターオブジェクトを持つことを要求します。Centrifyに参加しているLinuxマシンがドメイン上にあることを確認するには:
su –
adinfo
<!--NeedCopy-->
「Joined to domain」の値が有効であり、CentrifyDCモードが「connected」を返すことを確認します。モードが「starting」状態のままになっている場合、Centrifyクライアントはサーバー接続または認証の問題を抱えています。
- より包括的なシステムおよび診断情報は、以下を使用して利用できます。
adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->
さまざまなActive DirectoryおよびKerberosサービスへの接続をテストします。
adinfo --test
<!--NeedCopy-->
ドメイン参加の検証後、手順6:Linux VDAのインストールに進みます。
SSSD
SSSDを使用している場合は、このセクションの手順に従ってください。このセクションには、Linux VDAマシンをWindowsドメインに参加させるための手順と、Kerberos認証を構成するためのガイダンスが含まれています。
RHELおよびCentOSでSSSDをセットアップするには、次の手順を実行します。
- ドメインへの参加とホストキータブの作成
- SSSDのセットアップ
- SSSDの有効化
- Kerberos構成の確認
- ユーザー認証の確認
ドメインへの参加とホストキータブの作成
SSSDは、ドメインへの参加やシステムキータブファイルの管理のためのActive Directoryクライアント機能を提供しません。代わりに、adcli、realmd、またはSambaを使用できます。
このセクションでは、Amazon Linux 2およびRHEL 7向けのSambaアプローチと、RHEL 8向けのadcliアプローチについて説明します。realmdについては、RHELまたはCentOSのドキュメントを参照してください。これらの手順は、SSSDを構成する前に実行する必要があります。
- **Samba (Amazon Linux 2およびRHEL 7):**
必要なパッケージのインストールまたは更新:
```
sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
<!--NeedCopy--> ```
適切に構成されたファイルを持つLinuxクライアントで:
- /etc/krb5.conf
- /etc/samba/smb.conf:
**Samba**およびKerberos認証用にマシンを構成します。
```
sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy--> ```
ここで、**REALM**はKerberosレルム名の大文字表記であり、**domain**はActive Directoryドメインの短いNetBIOS名です。
>**注:**
>
> この記事の設定は、単一ドメイン、単一フォレストモデルを対象としています。Kerberosは、ADインフラストラクチャに基づいて構成してください。
KDCサーバーとレルム名のDNSベースのルックアップが必要な場合は、上記のコマンドに次の2つのオプションを追加します。
`--enablekrb5kdcdns --enablekrb5realmdns`
**/etc/samba/smb.conf**を開き、**authconfig**ツールによって生成されたセクションの後に、**[Global]**セクションの下に次のエントリを追加します。
`kerberos method = secrets and keytab`
`winbind offline logon = no`
Windowsドメインに参加します。ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントがあることを確認してください。
```
sudo net ads join REALM -U user
<!--NeedCopy--> ```
**REALM**はKerberosレルム名の大文字表記であり、**user**はコンピューターをドメインに追加する権限を持つドメインユーザーです。
-
Adcli (RHEL 8.x/9.0およびRocky Linux 8.x/9.0):
必要なパッケージのインストールまたは更新:
sudo yum -y install samba-common samba-common-tools krb5-workstation authconfig oddjob-mkhomedir realmd oddjob authselect <!--NeedCopy-->SambaおよびKerberos認証用にマシンを構成します。
sudo authselect select sssd with-mkhomedir --force <!--NeedCopy-->/etc/krb5.confを開き、[realms]セクションと[domain_realm]セクションの下にエントリを追加します。
[realms]セクションの下:
REALM = {kdc = fqdn-of-domain-controller}[domain_realm]セクションの下:
realm = REALM.realm = REALMWindowsドメインに参加します。ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントがあることを確認してください。
sudo realm join REALM -U user <!--NeedCopy-->REALMはKerberosレルム名の大文字表記であり、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。
SSSD のセットアップ
SSSD のセットアップは、次の手順で構成されます。
- Linux VDA に sssd-ad パッケージをインストールします。これには、
sudo yum -y install sssdコマンドを実行します。 - さまざまなファイル(例: sssd.conf)に構成変更を加えます。
- sssd サービスを開始します。
RHEL 7 の sssd.conf 構成例(必要に応じて追加オプションを追加できます)。

ad.example.com、server.ad.example.com を対応する値に置き換えます。詳細については、sssd-ad(5) - Linux man page を参照してください。
(RHEL 8.x/9.0 および Rocky Linux 8.x/9.0 のみ) /etc/sssd/sssd.conf を開き、[domain/ad.example.com] セクションの下に次のエントリを追加します。
ad_gpo_access_control = permissive
full_name_format = %2$s\%1$s
fallback_homedir = /home/%d/%u
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
sssd.conf のファイル所有権とアクセス許可を設定します。
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
SSSD の有効化
RHEL 8.x/9.0 および Rocky Linux 8.x/9.0 の場合:
SSSD を有効にするには、次のコマンドを実行します。
sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->
Amazon Linux 2、CentOS 7、および RHEL 7 の場合:
authconfig を使用して SSSD を有効にします。ホームディレクトリの作成が SELinux と互換性があることを確認するために、oddjob-mkhomedir をインストールします。
authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
sudo service sssd start
sudo chkconfig sssd on
<!--NeedCopy-->
Kerberos 構成の検証
システム keytab ファイルが作成され、有効なキーが含まれていることを確認します。
sudo klist -ke
<!--NeedCopy-->
このコマンドは、プリンシパル名と暗号スイートのさまざまな組み合わせで利用可能なキーのリストを表示します。これらのキーを使用して、Kerberos の kinit コマンドを実行し、ドメインコントローラーでマシンを認証します。
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
マシン名とレルム名は大文字で指定する必要があります。ドル記号($)は、シェルによる置換を防ぐためにバックスラッシュ(\)でエスケープする必要があります。一部の環境では、DNS ドメイン名が Kerberos レルム名と異なる場合があります。レルム名が使用されていることを確認してください。このコマンドが成功した場合、出力は表示されません。
マシンアカウントの TGT チケットがキャッシュされていることを、次のコマンドを使用して確認します。
sudo klist
<!--NeedCopy-->
ユーザー認証の検証
getent コマンドを使用して、ログオン形式がサポートされており、NSS が機能していることを確認します。
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
DOMAIN パラメーターは、短いバージョンのドメイン名を示します。別のログオン形式が必要な場合は、まず getent コマンドを使用して確認します。
サポートされているログオン形式は次のとおりです。
- ダウンレベルログオン名:
DOMAIN\username - UPN:
username@domain.com - NetBIOS サフィックス形式:
username@DOMAIN
SSSD PAM モジュールが正しく構成されていることを確認するには、これまで使用されていないドメインユーザーアカウントを使用して Linux VDA にログオンします。
sudo ssh localhost –l DOMAIN\\username
id -u
<!--NeedCopy-->
コマンドによって返された uid に対応する Kerberos 資格情報キャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
ユーザーの Kerberos 資格情報キャッシュ内のチケットが有効で、期限切れになっていないことを確認します。
klist
<!--NeedCopy-->
ドメイン参加の検証後、手順 6: Linux VDA のインストール に進みます。
PBIS
必要な PBIS パッケージのダウンロード
wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
PBIS インストールスクリプトの実行
sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Windows ドメインへの参加
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つ Active Directory ユーザーアカウントが必要です。
/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
user は、コンピューターを Active Directory ドメインに追加する権限を持つドメインユーザーです。domain-name は、たとえば example.com のようなドメインの DNS 名です。
注: Bash をデフォルトシェルとして設定するには、/opt/pbis/bin/config LoginShellTemplate/bin/bash コマンドを実行します。
ドメインメンバーシップの検証
Delivery Controller は、すべての VDA マシン(Windows および Linux VDA)が Active Directory にコンピューターオブジェクトを持つことを要求します。PBIS に参加している Linux マシンがドメイン上にあることを確認するには、次のようにします。
/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->
マシンがドメインに参加している場合、このコマンドは現在参加している AD ドメインと OU に関する情報を返します。そうでない場合は、ホスト名のみが表示されます。
ユーザー認証の確認
PBIS が PAM を介してドメインユーザーを認証できることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用して Linux VDA にログオンします。
- ssh localhost -l domain\\user
- id -u
<!--NeedCopy-->
- **id -u** コマンドによって返された UID に対応する Kerberos 資格情報キャッシュファイルが作成されたことを確認します。
- ls /tmp/krb5cc_uid
<!--NeedCopy-->
- セッションを終了します。
- exit
<!--NeedCopy-->
- ドメイン参加の検証後、[ステップ 6: Linux VDA のインストール](/ja-jp/linux-virtual-delivery-agent/2301/installation-overview/manual-installation-overview/redhat.html#step-6-install-the-linux-vda)に進みます。
ステップ 4: .NET Runtime 6.0 のインストール
- Linux VDA をインストールする前に、<https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers> の手順に従って .NET Runtime 6.0 をインストールします。
.NET Runtime 6.0 のインストール後、which dotnet コマンドを実行してランタイムパスを見つけます。
コマンド出力に基づいて、.NET ランタイムバイナリパスを設定します。たとえば、コマンド出力が /aa/bb/dotnet の場合、/aa/bb を .NET バイナリパスとして使用します。
ステップ 5: Linux VDA パッケージのダウンロード
- Citrix Virtual Apps and Desktops ダウンロードページにアクセスします
- Citrix Virtual Apps and Desktops の適切なバージョンを展開します
-
Components をクリックして、お使いの Linux ディストリビューションに一致する Linux VDA パッケージと、Linux VDA パッケージの整合性を検証するために使用できる GPG 公開鍵をダウンロードします
Linux VDA パッケージの整合性を検証するには、公開鍵を RPM データベースにインポートし、次のコマンドを実行します。
``` rpmkeys --import <path to the public key> rpm --checksig --verbose <path to the Linux VDA package> <!--NeedCopy--> ```
-
ステップ 6: Linux VDA のインストール
新規インストールを行うか、以前の 2 つのバージョンおよび LTSR リリースから既存のインストールをアップグレードできます。
ステップ 6a: 新規インストールを行う
-
(オプション)古いバージョンのアンインストール
以前の 2 つのバージョンおよび LTSR リリース以外の以前のバージョンをインストールしている場合は、新しいバージョンをインストールする前にアンインストールします。
-
Linux VDA サービスを停止します。
sudo /sbin/service ctxvda stop sudo /sbin/service ctxhdx stop <!--NeedCopy-->注:
ctxvdaおよびctxhdxサービスを停止する前に、service ctxmonitorservice stop コマンドを実行してモニターサービスデーモンを停止します。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。 -
パッケージをアンインストールします。
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
注:
コマンドを実行するには、フルパスが必要です。または、/opt/Citrix/VDA/sbin および /opt/Citrix/VDA/bin をシステムパスに追加することもできます。
-
-
Linux VDA パッケージのダウンロード
Citrix Virtual Apps and Desktops ダウンロードページにアクセスします。Citrix Virtual Apps and Desktops の適切なバージョンを展開し、Components をクリックして、お使いの Linux ディストリビューションに一致する Linux VDA パッケージをダウンロードします。
-
Linux VDA のインストール
注:
-
CentOS、RHEL、および Rocky Linux の場合、Linux VDA を正常にインストールする前に EPEL リポジトリをインストールします。EPEL のインストール方法については、https://docs.fedoraproject.org/en-US/epel/ の手順を参照してください。
-
RHEL 9.0 および Rocky Linux 9.0 に Linux VDA をインストールする前に、libsepol パッケージをバージョン 3.4 以降に更新してください。
-
Yumを使用して Linux VDA ソフトウェアをインストールします。Amazon Linux 2 の場合:
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm <!--NeedCopy-->RHEL 9.0 および Rocky Linux 9.0 の場合:
sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm <!--NeedCopy-->RHEL 8.x および Rocky Linux 8.x の場合:
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm <!--NeedCopy-->CentOS 7 および RHEL 7 の場合:
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm <!--NeedCopy--> -
RPM パッケージマネージャーを使用して Linux VDA ソフトウェアをインストールします。これを行う前に、次の依存関係を解決する必要があります。
Amazon Linux 2 の場合:
sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm <!--NeedCopy-->RHEL 9.0 および Rocky Linux 9.0 の場合:
sudo rpm -i XenDesktopVDA-<version>.el9_x.x86_64.rpm <!--NeedCopy-->RHEL 8.x および Rocky Linux 8.x の場合:
sudo rpm -i XenDesktopVDA-<version>.el8_x.x86_64.rpm <!--NeedCopy-->CentOS 7 および RHEL 7 の場合:
sudo rpm -i XenDesktopVDA-<version>.el7_x.x86_64.rpm <!--NeedCopy-->
-
-
RHEL 9.0 および Rocky Linux 9.0 の RPM 依存関係リスト:
``` - java-11-openjdk >= 11 icoutils >= 0.32 firewalld >= 0.6.3 policycoreutils-python >= 2.8.9 policycoreutils-python-utils >= 2.8 python3-policycoreutils >= 2.8 - dbus >= 1.12.8 dbus-common >= 1.12.8 dbus-daemon >= 1.12.8 dbus-tools >= 1.12.8 dbus-x11 >= 1.12.8 xorg-x11-server-utils >= 7.7 xorg-x11-xinit >= 1.3.4 libXpm >= 3.5.12 libXrandr >= 1.5.1 libXtst >= 1.2.3 pam >= 1.3.1 util-linux >= 2.32.1 util-linux-user >= 2.32.1 xorg-x11-utils >= 7.5 bash >= 4.3 findutils >= 4.6 gawk >= 4.2 sed >= 4.5 cups >= 1.6.0 foomatic-filters >= 4.0.9 cups-filters >= 1.20.0 ghostscript >= 9.25 libxml2 >= 2.9 libmspack >= 0.7 krb5-workstation >= 1.13 ibus >= 1.5 nss-tools >= 3.44.0 gperftools-libs >= 2.4 cyrus-sasl-gssapi >= 2.1 python3 >= 3.6~ qt5-qtbase >= 5.5~ qt5-qtbase-gui >= 5.5~ qrencode-libs >= 3.4.4 imlib2 >= 1.4.9 <!--NeedCopy--> ``` **RHEL 8.x および Rocky Linux 8.x の RPM 依存関係リスト:** ``` java-11-openjdk >= 11 icoutils >= 0.32 firewalld >= 0.6.3 policycoreutils-python >= 2.8.9 policycoreutils-python-utils >= 2.8 python3-policycoreutils >= 2.8 dbus >= 1.12.8 dbus-common >= 1.12.8 dbus-daemon >= 1.12.8 dbus-tools >= 1.12.8 dbus-x11 >= 1.12.8 xorg-x11-server-utils >= 7.7 xorg-x11-xinit >= 1.3.4 libXpm >= 3.5.12 libXrandr >= 1.5.1 libXtst >= 1.2.3 pam >= 1.3.1 util-linux >= 2.32.1 util-linux-user >= 2.32.1 xorg-x11-utils >= 7.5 bash >= 4.3 findutils >= 4.6 gawk >= 4.2 sed >= 4.5 cups >= 1.6.0 foomatic-filters >= 4.0.9 cups-filters >= 1.20.0 ghostscript >= 9.25 libxml2 >= 2.9 libmspack >= 0.7 krb5-workstation >= 1.13 ibus >= 1.5 nss-tools >= 3.44.0 gperftools-libs >= 2.4 cyrus-sasl-gssapi >= 2.1 python3 >= 3.6~ qt5-qtbase >= 5.5~ qt5-qtbase-gui >= 5.5~ qrencode-libs >= 3.4.4 imlib2 >= 1.4.9 <!--NeedCopy--> ``` **CentOS 7 および RHEL 7 の RPM 依存関係リスト:** ``` java-11-openjdk >= 11 ImageMagick >= 6.7.8.9 firewalld >= 0.3.9 policycoreutils-python >= 2.0.83 dbus >= 1.6.12 dbus-x11 >= 1.6.12 xorg-x11-server-utils >= 7.7 xorg-x11-xinit >= 1.3.2 xorg-x11-server-Xorg >= 1.20.4 libXpm >= 3.5.10 libXrandr >= 1.4.1 libXtst >= 1.2.2 pam >= 1.1.8 util-linux >= 2.23.2 bash >= 4.2 findutils >= 4.5 gawk >= 4.0 sed >= 4.2 cups >= 1.6.0 foomatic-filters >= 4.0.9 libxml2 >= 2.9 libmspack >= 0.5 ibus >= 1.5 cyrus-sasl-gssapi >= 2.1 python3 >= 3.6~ gperftools-libs >= 2.4 nss-tools >= 3.44.0 qt5-qtbase >= 5.5~ qt5-qtbase >= 5.5~ imlib2 >= 1.4.5 <!--NeedCopy--> ``` **Amazon Linux 2 の RPM 依存関係リスト:** ``` java-11-openjdk >= 11 ImageMagick >= 6.7.8.9 firewalld >= 0.3.9 policycoreutils-python >= 2.0.83 dbus >= 1.6.12 dbus-x11 >= 1.6.12 xorg-x11-server-utils >= 7.7 xorg-x11-xinit >= 1.3.2 xorg-x11-server-Xorg >= 1.20.4 libXpm >= 3.5.10 libXrandr >= 1.4.1 libXtst >= 1.2.2 pam >= 1.1.8 util-linux >= 2.23.2 bash >= 4.2 findutils >= 4.5 gawk >= 4.0 sed >= 4.2 cups >= 1.6.0 foomatic-filters >= 4.0.9 libxml2 >= 2.9 libmspack >= 0.5 ibus >= 1.5 cyrus-sasl-gssapi >= 2.1 gperftools-libs >= 2.4 nss-tools >= 3.44.0 qt5-qtbase >= 5.5~ qrencode-libs >= 3.4.1 imlib2 >= 1.4.5 <!--NeedCopy--> ```注:
このバージョンの Linux VDA がサポートする Linux ディストリビューションと Xorg バージョンのマトリックスについては、「システム要件」を参照してください。
RHEL 7.x に Linux VDA をインストールした後、
sudo yum install -y python-websockify x11vncコマンドを実行します。これは、セッションシャドウイング機能を使用するためにpython-websockifyとx11vncを手動でインストールすることを目的としています。詳しくは、「セッションシャドウ」を参照してください。
手順 6b:既存のインストールをアップグレード(オプション)
既存のインストールは、以前の2つのバージョンおよびLTSRリリースからアップグレードできます。
注:
- 既存のインストールをアップグレードすると、/etc/xdl の下の構成ファイルが上書きされます。アップグレードを実行する前に、ファイルをバックアップしてください。 - RHEL 9.0 および Rocky Linux 9.0 で Linux VDA をアップグレードする前に、**libsepol** パッケージをバージョン 3.4 以降に更新してください。
- `Yum` を使用してソフトウェアをアップグレードするには:
**Amazon Linux 2 の場合:**
```
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy--> ```
**RHEL 9.0 および Rocky Linux 9.0 の場合:**
```
sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm
<!--NeedCopy--> ```
**RHEL 8.x および Rocky Linux 8.x の場合:**
```
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy--> ```
**CentOS 7 および RHEL 7 の場合:**
```
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy--> ```
-
RPM パッケージマネージャーを使用してソフトウェアをアップグレードするには:
Amazon Linux 2 の場合:
sudo rpm -U XenDesktopVDA-<version>.amzn2.x86_64.rpm <!--NeedCopy-->RHEL 9.0 および Rocky Linux 9.0 の場合:
sudo rpm -U XenDesktopVDA-<version>.el9_x.x86_64.rpm <!--NeedCopy-->RHEL 8.x および Rocky Linux 8.x の場合:
sudo rpm -U XenDesktopVDA-<version>.el8_x.x86_64.rpm <!--NeedCopy-->CentOS 7 および RHEL 7 の場合:
sudo rpm -U XenDesktopVDA-<version>.el7_x.x86_64.rpm <!--NeedCopy-->
注:
RHEL 7 を使用している場合は、上記のアップグレードコマンドを実行した後、以下の手順を完了してください。
/opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "DotNetRuntimePath" -d "/opt/rh/rh-dotnet31/root/usr/bin/" --forceを実行して、正しい .NET ランタイムパスを設定します。
ctxvdaサービスを再起動します。重要:
ソフトウェアのアップグレード後、Linux VDA マシンを再起動してください。
手順 7:NVIDIA GRID ドライバーのインストール
HDX 3D Pro を有効にするには、ハイパーバイザーと VDA マシンに NVIDIA GRID ドライバーをインストールする必要があります。
注:
Amazon Linux 2 で HDX 3D Pro を使用するには、NVIDIA ドライバー 470 をインストールすることをお勧めします。詳しくは、「システム要件」を参照してください。
特定のハイパーバイザーに NVIDIA GRID Virtual GPU Manager(ホストドライバー)をインストールおよび構成するには、以下のガイドを参照してください。
NVIDIA GRID ゲスト VM ドライバーをインストールおよび構成するには、以下の手順を実行します。
- ゲスト VM がシャットダウンされていることを確認します。
- XenCenter® で、VM に GPU を割り当てます。
- VM を起動します。
-
NVIDIA GRID ドライバー用に VM を準備します。
yum install gcc yum install "kernel-devel-$(uname -r)" systemctl set-default multi-user.target <!--NeedCopy--> - Red Hat Enterprise Linux ドキュメントの手順に従って、NVIDIA GRID ドライバーをインストールします。
注:
GPU ドライバーのインストール中、各質問に対してデフォルト(「no」)を選択してください。
重要:
GPU パススルーが有効になった後、Linux VM は XenCenter を介してアクセスできなくなります。SSH を使用して接続してください。

カードの正しい構成を設定します。
etc/X11/ctx-nvidia.sh
大解像度およびマルチモニター機能を利用するには、有効な NVIDIA ライセンスが必要です。ライセンスを申請するには、「GRID Licensing Guide.pdf - DU-07757-001 September 2015」の製品ドキュメントに従ってください。
手順 8:Linux VDA の構成
パッケージをインストールした後、ctxsetup.sh スクリプトを実行して Linux VDA を構成する必要があります。変更を行う前に、スクリプトは環境を検証し、すべての依存関係がインストールされていることを確認します。必要に応じて、いつでもスクリプトを再実行して設定を変更できます。
スクリプトは、プロンプトに従って手動で実行することも、事前設定された応答で自動的に実行することもできます。続行する前に、スクリプトに関するヘルプを確認してください。
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help
<!--NeedCopy-->
プロンプトによる構成
プロンプトによる質問で手動構成を実行します。
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
自動構成
自動インストールの場合、セットアップスクリプトで必要なオプションを環境変数で指定します。必要なすべての変数が存在する場合、スクリプトは情報を要求しません。
サポートされている環境変数には以下が含まれます。
- **CTX\_XDL\_SUPPORT\_DDC\_AS\_CNAME=Y \| N** – Linux VDA は、DNS CNAME レコードを使用して Delivery Controller 名を指定することをサポートしています。デフォルトでは N に設定されています。
- **CTX\_XDL\_DDC\_LIST='list-ddc-fqdns'** – Linux VDA は、Delivery Controller に登録するために使用する Delivery Controller の完全修飾ドメイン名(FQDN)のスペース区切りリストを必要とします。少なくとも1つの FQDN または CNAME エイリアスを指定する必要があります。
- CTX_XDL_VDA_PORT=port-number – Linux VDA は、TCP/IP ポート(デフォルトではポート 80)を介して Delivery Controller と通信します。
- CTX_XDL_REGISTER_SERVICE=Y | N - Linux VDA サービスは、マシンの起動後に開始されます。デフォルトでは Y に設定されています。
- CTX_XDL_ADD_FIREWALL_RULES=Y | N – Linux VDA サービスは、システムファイアウォールを介した受信ネットワーク接続を許可する必要があります。Linux Virtual Desktop のシステムファイアウォールで、必要なポート(デフォルトではポート 80 および 1494)を自動的に開くことができます。デフォルトでは Y に設定されています。
-
CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 | 5 – Linux VDA は、Delivery Controller と認証するために Kerberos 構成設定を必要とします。Kerberos 構成は、システムにインストールおよび構成されている Active Directory 統合ツールから決定されます。使用するサポートされている Active Directory 統合方法を指定します。
- 1 – Samba Winbind
- 2 – Quest Authentication Services
- 3 – Centrify DirectControl
- 4 – SSSD
- 5 – PBIS
- CTX_XDL_HDX_3D_PRO=Y | N – Linux VDA は、グラフィックを多用するアプリケーションの仮想化を最適化するために設計された GPU アクセラレーション技術のセットである HDX 3D Pro をサポートしています。HDX 3D Pro が選択されている場合、VDA は VDI デスクトップ(シングルセッション)モード(つまり、CTX_XDL_VDI_MODE=Y)用に構成されます。
- CTX_XDL_VDI_MODE=Y | N – マシンを専用デスクトップ配信モデル(VDI)として構成するか、ホスト型共有デスクトップ配信モデルとして構成するかを決定します。HDX 3D Pro 環境の場合、この変数を Y に設定します。この変数はデフォルトで N に設定されています。
-
CTX_XDL_SITE_NAME=dns-name – Linux VDA は、DNS を介して LDAP サーバーを検出します。DNS 検索結果をローカルサイトに制限するには、DNS サイト名を指定します。この変数はデフォルトで <none> に設定されています。
- CTX_XDL_LDAP_LIST=’list-ldap-servers’ – Linux VDAは、LDAPサーバーを検出するためにDNSをクエリします。DNSがLDAPサービスレコードを提供できない場合、LDAP FQDNとLDAPポートのスペース区切りリストを指定できます。例: ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268。LDAPポート番号を389として指定した場合、Linux VDAは指定されたドメイン内の各LDAPサーバーをポーリングモードでクエリします。ポリシーがx個、LDAPサーバーがy個ある場合、Linux VDAはXにYを乗じた合計クエリを実行します。ポーリング時間がしきい値を超えると、セッションログオンが失敗する可能性があります。より高速なLDAPクエリを有効にするには、ドメインコントローラーでグローバルカタログを有効にし、関連するLDAPポート番号を3268として指定します。この変数は、デフォルトで<none>に設定されています。
- CTX_XDL_SEARCH_BASE=search-base-set – Linux VDAは、Active Directoryドメインのルートに設定された検索ベース(例: DC=mycompany,DC=com)を介してLDAPをクエリします。検索パフォーマンスを向上させるには、検索ベース(例: OU=VDI,DC=mycompany,DC=com)を指定できます。この変数は、デフォルトで<none>に設定されています。
- CTX_XDL_FAS_LIST=’list-fas-servers’ – フェデレーテッド認証サービス(FAS)サーバーは、ADグループポリシーを介して構成されます。Linux VDAはADグループポリシーをサポートしていませんが、代わりにセミコロン区切りのFASサーバーリストを提供できます。シーケンスは、ADグループポリシーで構成されているものと同じである必要があります。サーバーアドレスが削除された場合は、その空白を<none>というテキスト文字列で埋め、サーバーアドレスの順序を変更しないでください。FASサーバーと適切に通信するには、FASサーバーで指定されたポート番号と一致するポート番号を付加してください。例: CTX_XDL_FAS_LIST=’fas_server_1_url:port_number; fas_server_2_url: port_number; fas_server_3_url: port_number’。
-
CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – 新しいブローカーエージェントサービス(
ctxvda)をサポートするための.NET Runtime 6.0をインストールするパス。デフォルトのパスは/usr/binです。 -
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate – セッションで使用するGNOME、GNOME Classic、またはMATEデスクトップ環境を指定します。変数を指定しない場合、VDAに現在インストールされているデスクトップが使用されます。ただし、現在インストールされているデスクトップがMATEである場合は、変数値をmateに設定する必要があります。
ターゲットセッションユーザーのデスクトップ環境は、以下の手順で変更することもできます。
- VDA上の$HOME/<username>ディレクトリの下に、
.xsessionまたは.Xclientsファイルを作成します。Amazon Linux 2を使用している場合は、.Xclientsファイルを作成します。その他のディストリビューションを使用している場合は、.xsessionファイルを作成します。 -
.xsessionまたは.Xclientsファイルを編集して、デスクトップ環境を指定します。-
MATEデスクトップの場合
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi -
GNOME Classic デスクトップの場合
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi -
GNOME デスクトップの場合
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi
-
- ターゲットセッションユーザーと700のファイル権限を共有します。
バージョン2209以降、セッションユーザーはデスクトップ環境をカスタマイズできます。この機能を有効にするには、VDAに切り替え可能なデスクトップ環境を事前にインストールする必要があります。詳しくは、「セッションユーザーによるカスタムデスクトップ環境」を参照してください。
- VDA上の$HOME/<username>ディレクトリの下に、
- CTX_XDL_START_SERVICE=Y | N – Linux VDAの構成が完了したときにLinux VDAサービスを開始するかどうかを決定します。デフォルト値はYです。
- CTX_XDL_TELEMETRY_SOCKET_PORT – Citrix Scoutのリッスンに使用するソケットポートです。デフォルトポートは7503です。
- CTX_XDL_TELEMETRY_PORT – Citrix Scoutとの通信に使用するポートです。デフォルトポートは7502です。
環境変数を設定し、構成スクリプトを実行します。
export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N
export CTX_XDL_DDC_LIST='list-ddc-fqdns'
export CTX_XDL_VDA_PORT=port-number
export CTX_XDL_REGISTER_SERVICE=Y|N
export CTX_XDL_ADD_FIREWALL_RULES=Y|N
export CTX_XDL_AD_INTEGRATION=1|2|3|4|5
export CTX_XDL_HDX_3D_PRO=Y|N
export CTX_XDL_VDI_MODE=Y|N
export CTX_XDL_SITE_NAME=dns-site-name | '<none>'
export CTX_XDL_LDAP_LIST='list-ldap-servers' | '<none>'
export CTX_XDL_SEARCH_BASE=search-base-set | '<none>'
export CTX_XDL_FAS_LIST='list-fas-servers' | '<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime
export CTX_XDL_DESKTOP_ENVIRONMENT= gnome | gnome-classic | mate | '<none>'
export CTX_XDL_TELEMETRY_SOCKET_PORT=port-number
export CTX_XDL_TELEMETRY_PORT=port-number
export CTX_XDL_START_SERVICE=Y|N
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
sudoコマンドを実行するときは、既存の環境変数を新しく作成されるシェルに渡すために、-Eオプションを入力します。前述のコマンドから、最初の行に#!/bin/bashを含むシェルスクリプトファイルを作成することをお勧めします。
または、単一のコマンドを使用してすべてのパラメーターを指定することもできます。
sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \
CTX_XDL_DDC_LIST='list-ddc-fqdns' \
CTX_XDL_VDA_PORT=port-number \
CTX_XDL_REGISTER_SERVICE=Y|N \
CTX_XDL_ADD_FIREWALL_RULES=Y|N \
CTX_XDL_AD_INTEGRATION=1|2|3|4|5 \
CTX_XDL_HDX_3D_PRO=Y|N \
CTX_XDL_VDI_MODE=Y|N \
CTX_XDL_SITE_NAME=dns-name \
CTX_XDL_LDAP_LIST='list-ldap-servers' \
CTX_XDL_SEARCH_BASE=search-base-set \
CTX_XDL_FAS_LIST='list-fas-servers' \
CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \
CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|mate \
CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \
CTX_XDL_TELEMETRY_PORT=port-number \
CTX_XDL_START_SERVICE=Y|N \
/opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
構成変更の削除
シナリオによっては、Linux VDAパッケージをアンインストールせずに、ctxsetup.shスクリプトによって行われた構成変更を削除する必要がある場合があります。
続行する前に、このスクリプトに関するヘルプを確認してください。
sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->
構成変更を削除するには:
sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->
重要:
このスクリプトは、データベースからすべての構成データを削除し、Linux VDAを動作不能にします。
構成ログ
ctxsetup.shおよびctxcleanup.shスクリプトは、コンソールにエラーを表示し、追加情報は構成ログファイル/tmp/xdl.configure.logに書き込まれます。
変更を有効にするには、Linux VDAサービスを再起動します。
手順9:XDPingの実行
sudo /opt/Citrix/VDA/bin/xdpingを実行して、Linux VDA環境における一般的な構成の問題を確認します。詳しくは、「XDPing」を参照してください。
手順10:Linux VDAの実行
ctxsetup.shスクリプトを使用してLinux VDAを構成した後、次のコマンドを実行してLinux VDAを制御できます。
Linux VDAの開始:
Linux VDAサービスを開始するには:
sudo /sbin/service ctxhdx start
sudo /sbin/service ctxvda start
<!--NeedCopy-->
Linux VDAの停止:
Linux VDAサービスを停止するには:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx stop
<!--NeedCopy-->
注:
ctxvdaおよびctxhdxサービスを停止する前に、service ctxmonitorservice stopコマンドを実行してモニターサービスデーモンを停止してください。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
Linux VDAの再起動:
Linux VDAサービスを再起動するには:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx restart
sudo /sbin/service ctxvda start
<!--NeedCopy-->
Linux VDAのステータス確認:
Linux VDAサービスの実行ステータスを確認するには:
sudo /sbin/service ctxvda status
sudo /sbin/service ctxhdx status
<!--NeedCopy-->
手順11:マシンカタログの作成
マシンカタログを作成し、Linux VDAマシンを追加するプロセスは、従来のWindows VDAのアプローチと似ています。これらのタスクを完了する方法の詳細については、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
Linux VDAマシンを含むマシンカタログを作成する場合、Windows VDAマシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。
- オペレーティングシステムでは、以下を選択します。
- ホスト型共有デスクトップ配信モデルの場合は、Multi-session OSオプション
- VDI専用デスクトップ配信モデルの場合は、Single-session OSオプション
- 同じマシンカタログ内でLinux VDAマシンとWindows VDAマシンを混在させないでください。
注:
Citrix Studioの初期バージョンでは、「Linux OS」という概念はサポートされていませんでした。ただし、Windows Server OSまたはServer OSオプションを選択すると、同等のホスト型共有デスクトップ配信モデルが意味されます。Windows Desktop OSまたはDesktop OSオプションを選択すると、マシンごとに単一ユーザーの配信モデルが意味されます。
ヒント:
削除されたマシンをActive Directoryドメインに再参加させる場合は、そのマシンをマシンカタログから削除し、再度追加してください。
手順12:デリバリーグループの作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加するプロセスは、Windows VDAマシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。
- 選択したADユーザーとグループが、Linux VDAマシンにログオンするように適切に構成されていることを確認します。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- デリバリーグループとWindowsマシンを含むマシンカタログを混在させないでください。
重要:
アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、Linux VDAは、同じマシンへのデスクトップとアプリの配信をサポートしていません。
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2212」を参照してください。