Amazon Linux 2向け、CentOS向け、およびRHEL向けLinux Virtual Delivery Agentの手動インストール

重要：

新規インストールの場合は、簡単インストールを使用して簡易インストールを行うことをお勧めします。簡単インストールは時間と労力を節約するだけでなく、本記事に記載されている手動インストールよりもエラーを減らすことができます。

手順1：VDAインストール用のLinuxディストリビューションの準備

手順1a：ネットワーク構成の確認

ネットワークが正しく接続および構成されていることを確認してください。たとえば、DNSサーバーはLinux VDAで構成する必要があります。

手順1b：ホスト名の設定

マシンのホスト名が確実に正しく報告されるようにするには、/etc/hostnameファイルを変更してマシンのホスト名のみを記述します。

hostname

手順1c：ホスト名へのループバックアドレスの割り当て

マシンのDNSドメイン名と完全修飾ドメイン名（FQDN）が確実に正しく報告されるようにするには、/etc/hostsファイルの以下の行を変更し、最初の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）ではなく、そのホスト名のみが返されます。

次のコマンドで、完全修飾ドメイン名が正しく設定されていることを確認します：

hostname -f
<!--NeedCopy-->

このコマンドにより、そのマシンの完全修飾ドメイン名が返されます。

手順1e：名前解決とサービス到達可能性の確認

次のコマンドで、完全修飾ドメイン名が解決できることと、ドメインコントローラーとDelivery Controllerからpingに応答があることを確認します：

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn
<!--NeedCopy-->

完全修飾ドメイン名を解決できない、またはこれらのマシンのいずれかからpingに応答がない場合は、手順を確認してから次に進んでください。

手順1f：時刻同期の構成

VDA、Delivery Controller、ドメインコントローラーの間で正確な時刻同期を維持することは重要です。仮想マシンとしてLinux VDAをホストすると、時刻が不正確になる問題が発生する可能性があります。したがって、リモートのタイムサービスを使用して時刻を維持することをお勧めします。

RHEL 8/RHEL 7のデフォルト環境では、時刻同期にChronyデーモン（chronyd）を使用します。

Chronyサービスの構成

ルートユーザーとして /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エントリなど、一覧にあるその他のserverエントリを削除します。

変更を保存してから、次のコマンドでChronyデーモンを再起動します：

sudo /sbin/service chronyd restart
<!--NeedCopy-->

手順1g：OpenJDK 11のインストール

Linux VDAには、OpenJDK 11が必要です。

• CentOSまたはRHELを使用している場合は、Linux VDAをインストールすると、依存関係としてOpenJDK 11が自動的にインストールされます。

• 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-->

手順1h：PostgreSQLのインストール

Linux VDAにはPostgreSQLが必要です。次のコマンドにより、Linux VDAパッケージからPostgreSQLをインストールします（Amazon Linux 2、RHEL 7、CentOS 7の場合はPostgreSQL 9、RHEL 8の場合はPostgreSQL 10）。

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc
<!--NeedCopy-->

データベースを初期化し、マシンの起動時にサービスが確実に開始されるようにするには、次に示すインストール後の手順が必要です。この操作により、/var/lib/pgsql/data にデータベースファイルが作成されます。

sudo postgresql-setup initdb
<!--NeedCopy-->

手順1i：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-->

手順2：ハイパーバイザーの準備

サポートされるハイパーバイザー上で仮想マシンとしてLinux VDAを実行する場合、いくつかの変更が必要です。使用するハイパーバイザーのプラットフォームに合わせて、次の変更を行います。ベアメタルハードウェアでLinuxマシンを実行する場合、変更は必要ありません。

Citrix Hypervisorでの時刻同期の修正

Citrix Hypervisorの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとCitrix Hypervisorで問題が発生します。これは、NTPとCitrix Hypervisorの両方がシステムの時間を管理しようとすることが原因です。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは、変更は必要ありません。

Citrix VM Toolsがインストールされた準仮想化Linuxカーネルを実行している場合、Citrix Hypervisorの時刻同期機能が存在するかどうかと、Linux仮想マシン内で有効になっているかどうかを確認できます：

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統合サービスがインストールされたLinux仮想ホストでは、Hyper-Vの時刻同期機能を適用してホストオペレーティングシステムの時間を利用できます。システムの時間を正確な状態で維持するには、NTPサービスとともにこの機能を有効にする必要があります。

管理オペレーティングシステムで、次の操作を行います。

1. Hyper-Vマネージャーを開きます。
2. Linux仮想マシンの設定で、［統合サービス］ を選択します。
3. ［時刻の同期］ が選択されていることを確認します。

注：

この方法はVMwareおよびCitrix Hypervisorの場合とは異なります。VMwareおよびCitrix Hypervisorでは、NTPとの競合を避けるためにホストの時刻同期を無効にします。Hyper-Vの時刻同期は、NTPと共存し、NTPの時刻同期を補完することができます。

ESXおよびESXiでの時刻同期の修正

VMwareの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとハイパーバイザーで問題が発生します。これは、NTPとハイパーバイザーの両方がシステムの時間を同期しようとすることが原因です。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。

VMware Toolsをインストールした状態で準仮想化Linuxカーネルを実行している場合は、次の操作を行います。

1. vSphere Clientを開きます。
2. Linux仮想マシンの設定を編集します。
3. ［仮想マシンのプロパティ］ ダイアログボックスで、［オプション］ タブをクリックします。
4. ［VMware Tools］ を選択します。
5. ［詳細］ ボックスで、［ホストとゲスト時刻を同期］ チェックボックスをオフにします。

手順3：Linux仮想マシン（VM）をWindowsドメインに追加

Linux VDAは、LinuxマシンをActive Directory（AD）ドメインに追加するさまざまな方法をサポートします。

• Samba Winbind
• Quest Authentication Services
• Centrify DirectControl
• SSSD
• PBIS

選択した方法の手順に従います。

注：

Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗することがあります。

Samba Winbind

次のようにして、必要なパッケージをインストールまたは更新します：

RHEL 8の場合：

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認証用にマシンを構成します：

1. 次のコマンドを実行します：。

   RHEL 8の場合：

   sudo authselect select winbind with-mkhomedir --force
   <!--NeedCopy-->
   

   Amazon Linux 2および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 --enablekrb5realmdns

   authconfigコマンドから返される、開始に失敗したwinbindサービスに関するエラーは無視します。これらのエラーは、マシンがドメインにまだ参加していない状態でauthconfigがwinbindサービスを開始しようとすると発生することがあります。

2. /etc/samba/smb.confを開いて、［Global］ セクションに次のエントリを追加します。ただし、追加するのは、authconfigツールによって生成されたセクションの後です：

   kerberos method = secrets and keytab
winbind refresh tickets = true
winbind offline logon = no

3. （RHEL 8のみ）/etc/krb5.confを開いて、[libdefaults]、[realms]、[domain_realm]セクションにエントリを追加します：

   [libdefaults]セクション：

   default_ccache_name = FILE:/tmp/krb5cc_%{uid}
default_realm = REALM
dns_lookup_kdc = true

   [realms]セクション：

   REALM = {
kdc = fqdn-of-domain-controller
}

   [domain_realm]セクション：

   realm = REALM
.realm = REALM

Delivery Controllerに対する認証と登録には、Linux VDAにシステムのkeytabファイル/etc/krb5.keytabが必要です。前述のkerberosを使用した設定により、マシンが初めてドメインに参加するときに、Winbindによってシステムのkeytabファイルが強制的に作成されます。

Windowsドメインへの参加

ドメインコントローラーがアクセス可能で、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です：

RHEL 8の場合：

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}

ドメインメンバーシップの確認

Delivery Controllerを使用するには、すべてのVDAマシン（WindowsとLinux VDA）でActive Directoryにコンピューターオブジェクトが必要です。

次のように、Sambaのnet adsコマンドを実行して、マシンがドメインに参加していることを確認します：

sudo net ads testjoin
<!--NeedCopy-->

追加のドメインおよびコンピューターオブジェクト情報を検証するには、次のコマンドを実行します：

sudo net ads info
<!--NeedCopy-->

Kerberos構成の確認

Linux VDAで使用できるようにKerberosが正しく構成されていることを確認するには、次のコマンドにより、システムのkeytabファイルが作成済みでkeytabファイルに有効なキーが含まれていることを確認します：

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シェルの場合、バックスラッシュ文字（\）は、もう1つバックスラッシュ文字を指定してエスケープする必要があります。このコマンドにより、成功または失敗を示すメッセージが返されます。

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の構成

次の操作は、QuestソフトウェアをActive Directoryドメインコントローラーにインストールし、構成していることと、管理者特権が付与され、Active Directoryにコンピューターオブジェクトを作成できることを前提としています。

Linux VDAマシンにドメインユーザーがログオンできるようにする

Linux VDAマシンでHDXセッションを確立する必要がある各ドメインユーザーに対して、次の操作を行います。

1. ［Active Directoryユーザーとコンピューター］管理コンソールで、目的のユーザーアカウントのActive Directoryユーザーのプロパティを開きます。
2. ［Unixアカウント］ タブを選択します。
3. ［Unix対応］ チェックボックスをオンにします。
4. ［プライマリGID番号］ を、実際のドメインユーザーグループのグループIDに設定します。

注：

この手順は、ドメインユーザーがコンソール、RDP、SSH、またはその他のリモート処理プロトコルを使用してログオンできるように設定する場合も同じです。

Linux VDAでのQuestの構成

SELinuxポリシー適用の回避策

デフォルトのRHEL環境では、SELinuxが完全に適用されています。この適用により、Questが使用するUnixドメインソケットのIPCのメカニズムに干渉し、ドメインユーザーのログオンを妨げます。

この問題を回避するための便利な方法は、SELinuxの無効化です。ルートユーザーとして、/etc/selinux/config を編集し、SELinux設定を次のとおりに変更します：

SELINUX=permissive

この変更にはマシンの再起動が必要です：

reboot
<!--NeedCopy-->

重要：

この設定は注意して使用してください。SELinuxポリシーの適用を無効にした後に再度有効にすると、ルートユーザーやその他のローカルユーザーであっても、完全にロックアウトされてしまう可能性があります。

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-->

userは、コンピューターを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

ユーザー認証の確認

PAMを使用したQuestのドメインユーザーの認証が可能かどうかを確認するには、以前に使用したことがないドメインユーザーアカウントを使用して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 Agentがインストールされている場合、次のようにCentrifyのadjoinコマンドを使用して、LinuxマシンをActive Directoryドメインに追加します：

su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->

userパラメーターは、コンピューターをActive Directoryドメインに追加する権限を持つ任意のActive Directoryドメインユーザーです。domain-name は、Linuxマシンを追加するドメインの名前です。

ドメインメンバーシップの確認

Delivery Controllerを使用するには、すべてのVDAマシン（WindowsとLinux VDA）でActive Directoryにコンピューターオブジェクトが必要です。Centrifyにより追加されたLinuxマシンがドメインに存在することを確認するには、次のコマンドを実行します：

su –
adinfo
<!--NeedCopy-->

Joined to domain値が有効であることと、CentrifyDC modeでconnectedが返されることを確認します。CentrifyDC modeがstartingのまま変化しない場合は、Centrifyクライアントにサーバーとの接続の問題、または認証の問題が発生しています。

次を使用すると、より包括的なシステム情報と診断情報を取得できます。

adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->

さまざまなActive DirectoryおよびKerberosサービスとの接続をテストします。

adinfo --test
<!--NeedCopy-->

ドメイン参加の確認後、「手順6：Linux VDAのインストール」に進みます。

SSSD

SSSDを使用している場合は、このセクションの指示に従ってください。このセクションでは、Linux VDAマシンのWindowsドメインへの参加手順、およびKerberos認証の構成について説明します。

SSSDをRHELおよびCentOSでセットアップするには、次の作業を行います。

1. ドメインに参加してホストのkeytabを作成
2. SSSDのセットアップ
3. SSSDの有効化
4. Kerberos構成の確認
5. ユーザー認証の確認

ドメインに参加してホストのkeytabを作成

SSSDでは、ドメイン参加とシステムのkeytabファイルの管理に関する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名です。

  注：

  この記事の設定は、単一ドメイン、単一フォレストモデルを対象としています。ADインフラストラクチャに基づいてKerberosを構成します。

  KDCサーバーおよび領域名をDNSベースで参照する必要がある場合は、次の2つのオプションを前述のコマンドに追加します：

  --enablekrb5kdcdns --enablekrb5realmdns

  /etc/samba/smb.confを開いて、［Global］ セクションに次のエントリを追加します。ただし、追加するのは、authconfigツールによって生成されたセクションの後です：

  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）：

  次のようにして、必要なパッケージをインストールまたは更新します：

   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 = REALM

  Windowsドメインに参加します。ドメインコントローラーに到達できることと、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントがあることを確認します：

   sudo realm join REALM -U user
   <!--NeedCopy-->
  

  REALMは大文字のKerberos領域名で、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。

SSSDのセットアップ

SSSDのセットアップは、以下の手順で構成されています：

• sudo yum -y install sssdコマンドを実行して、Linux VDAにsssd-adパッケージをインストールします。
• さまざまなファイルに対して構成の変更を行います（sssd.confなど）。
• sssdサービスを開始します。

RHEL 7のsssd.confの設定例（必要に応じて追加の設定を行うことができます）：

ad.example.com と server.ad.example.com を対応する値で置き換えます。詳しくは、「sssd-ad(5) - Linux man page」を参照してください。

（RHEL 8のみ） /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の場合：

SSSDを有効にするには、次のコマンドを実行します：

sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->

Amazon Linux 2、CentOS 7、RHEL 7の場合：

authconfigを使用してSSSDを有効にします。oddjob-mkhomedir をインストールして、このホームディレクトリの作成機能がSELinuxに対応していることを確認します：

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-->

PBISインストールスクリプトを実行可能にする

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は、ドメインのDNS名（example.comなど）です。

注： Bashをデフォルトのシェルとして設定するには、/opt/pbis/bin/configLoginShellTemplate/bin/bashコマンドを実行します。

ドメインメンバーシップの確認

Delivery Controllerを使用するには、すべてのVDAマシン（WindowsとLinux VDA）でActive Directoryにコンピューターオブジェクトが必要です。PBISによって追加されたLinuxマシンがドメインに存在することを確認するには、次のコマンドを実行します：

/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->

マシンがドメインに参加している場合、このコマンドは現在のADドメインとOUの情報を返します。参加していない場合は、ホスト名だけが表示されます。

ユーザー認証の確認

PAMを使用したPBISのドメインユーザーの認証が可能かどうかを確認するには、以前に使用したことがないドメインユーザーアカウントを使用してLinux VDAにログオンします。

ssh localhost -l domain\user

id -u
<!--NeedCopy-->

次のコマンドで、id -uコマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します：

ls /tmp/krb5cc_uid
<!--NeedCopy-->

次のコマンドで、セッションを終了します。

exit
<!--NeedCopy-->

ドメイン参加の確認後、「手順6：Linux VDAのインストール」に進みます。

手順4：前提条件として.NETランタイム6.0をインストール

Linux VDAのインストール前に、https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managersの手順に従って.NETランタイム6.0をインストールします。

.NETランタイム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パッケージをダウンロードします。

手順6：Linux VDAのインストール

新規にインストールするか、最新の2バージョンとLTSRリリースから既存のインストールをアップグレードできます。

新規インストール手順

1. （オプション）古いバージョンのアンインストール

   最新の2バージョンおよびLTSRリリース以外の古いバージョンのLinux VDAがインストールされている場合は、それをアンインストールしてから新しいバージョンをインストールする必要があります。

   1. 次のコマンドで、Linux VDAサービスを停止します：

      sudo /sbin/service ctxvda stop  
      
      sudo /sbin/service ctxhdx stop
      <!--NeedCopy-->
      

      注：

      ctxvdaおよびctxhdxサービスを停止する前に、service ctxmonitorservice stopコマンドを実行して監視サービスデーモンを停止します。これを実行しない場合、監視サービスデーモンは停止したサービスを再起動します。

   2. 次のコマンドで、パッケージをアンインストールします：

      sudo rpm -e XenDesktopVDA
      <!--NeedCopy-->
      

   注：

   コマンドを実行するには、フルパスが必要です。代わりに、システムパスに/opt/Citrix/VDA/sbinおよび/opt/Citrix/VDA/binを追加することもできます。

2. Linux VDAパッケージのダウンロード

   Citrix Virtual Apps and Desktopsのダウンロードページにアクセスします。適切なバージョンのCitrix Virtual Apps and Desktopsを展開し、Componentsをクリックして、使用中のLinuxディストリビューションに対応するLinux VDAパッケージをダウンロードします。

3. Linux VDAのインストール

   注：

   RHELおよびCentOSの場合、Linux VDAを正常にインストールする前に、EPELリポジトリをインストールします。EPELのインストール方法については、https://docs.fedoraproject.org/en-US/epel/の説明を参照してください。

   • Yumを使用してLinux VDAソフトウェアをインストールします：

     Amazon Linux 2の場合：

      sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
      <!--NeedCopy-->
     

     RHEL 8の場合：

      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 Package Managerを使用して、Linux VDAソフトウェアをインストールします。その前に、次の依存関係を解決する必要があります。

     Amazon Linux 2の場合：

      sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm
      <!--NeedCopy-->
     

     RHEL 8の場合：

      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-->
     

     RPM依存関係一覧（RHEL 8の場合）：

      qt5-qtbase >= 5.5~
     
      ibus >= 1.5
     
      nss-tools >= 3.44.0
     
      gperftools-libs >= 2.4
     
      cyrus-sasl-gssapi >= 2.1
     
      python2 >= 2.7~
     
      postgresql-jdbc >= 42.2.3
     
      postgresql-server >= 10.6
     
      java-11-openjdk >= 11
     
      icoutils >= 0.32
     
      firewalld >= 0.8.0
     
      policycoreutils-python-utils >= 2.9
     
      python3-policycoreutils >= 2.9
     
      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
     
      motif >= 2.3.4
     
      pam >= 1.3.1
     
      util-linux >= 2.32.1
     
      util-linux-user >= 2.32.1
     
      xorg-x11-utils >= 7.5
     
      bash >= 4.4
     
      findutils >= 4.6
     
      gawk >= 4.2
     
      sed >= 4.5
     
      cups >= 2.2
     
      foomatic-filters >= 4.0.9
     
      cups-filters >= 1.20.0
     
      ghostscript >= 9.25
     
      libxml2 >= 2.9
     
      libmspack >= 0.7
      <!--NeedCopy-->
     

     RPM依存関係一覧（Amazon Linux 2、CentOS 7、およびRHEL 7の場合）：

      qt5-qtbase >= 5.5~
     
      libmspack >= 0.5
     
      ibus >= 1.5
     
      cyrus-sasl-gssapi >= 2.1
     
      gperftools-libs >= 2.4
     
      nss-tools >= 3.44.0
     
      postgresql-server >= 9.2
     
      postgresql-jdbc >= 9.2
     
      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
     
      motif >= 2.3.4
     
      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
     
      openldap >= 2.4
     
      cyrus-sasl >= 2.1
     
      cyrus-sasl-gssapi >= 2.1
     
      libxml2 >= 2.9
     
      python-requests >= 2.6.0
     
      gperftools-libs >= 2.4
     
      rpmlib(FileDigests) <= 4.6.0-1
     
      rpmlib(PayloadFilesHavePrefix) <= 4.0-1
     
      pmlib(CompressedFileNames) <= 3.0.4-1
     
      rpmlib(PayloadIsXz) <= 5.2-1
      <!--NeedCopy-->
     

   注：

   このバージョンのLinux VDAでサポートされているLinuxディストリビューションとXorgのバージョンについては、「システム要件」を参照してください。

   RHEL 7.xにLinux VDAをインストールした後、sudo yum install -y python-websockify x11vncコマンドを実行します。これは、セッションのシャドウ機能を使用するために、python-websockifyとx11vncを手動でインストールすることが目的です。詳しくは、「セッションのシャドウ」を参照してください。

既存のインストールのアップグレード手順

最新の2バージョンとLTSRリリースから既存のインストールをアップグレードできます。

注：

既存のインストールをアップグレードすると、/etc/xdlの下にある構成ファイルが上書きされます。アップグレードを実行する前に、必ずファイルをバックアップしてください。

• Yumを使用してアップグレードするには：

  Amazon Linux 2の場合：

   sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
   <!--NeedCopy-->
  

  RHEL 8の場合：

   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 Package Managerを使用してアップグレードするには：

  Amazon Linux 2の場合：

   sudo rpm -U XenDesktopVDA-<version>.amzn2.x86_64.rpm
   <!--NeedCopy-->
  

  RHEL 8の場合：

   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を使用している場合は、前述のアップグレードコマンドを実行した後、必ず次の手順を実行してください：

1. /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ランタイムパスを設定します。
2. 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（ホストドライバー）をインストールして構成するには、次のガイドを参照してください：

• Citrix Hypervisor
• VMware ESX
• Nutanix AHV

NVIDIA GRIDゲストVMドライバーをインストールして構成するには、次の手順を実行します：

1. ゲストVMがシャットダウンされていることを確認します。
2. XenCenterで、GPUをVMに割り当てます。
3. 仮想マシンを起動します。

4. NVIDIA GRIDドライバー用にVMを準備します：

   yum install gcc
   
   yum install "kernel-devel-$(uname -r)"
   
   systemctl set-default multi-user.target
   <!--NeedCopy-->
   

5. Red Hat Enterprise Linuxのドキュメントの手順に従って、NVIDIA GRIDドライバーをインストールします。

注：

GPUドライバーのインストール時は、すべての質問でデフォルト（「いいえ」）を選択してください。

重要：

GPUパススルーを有効にすると、XenCenterを利用してLinux仮想マシンにアクセスできなくなります。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つまたは複数の完全修飾ドメイン名または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 Service
  • 3 - Centrify DirectControl
  • 4 - SSSD
  • 5 - PBIS
• CTX_XDL_HDX_3D_PRO=Y | N - Linux VDAでは、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は、DNSを照会してLDAPサーバーを検出します。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ランタイム6.0をインストールするパス。デフォルトのパスは/usr/binです。

• CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate - セッションで使用するGNOME、GNOMEクラシック、またはMATEデスクトップ環境を指定します。変数を指定しないままにすると、現在VDAにインストールされているデスクトップが使用されます。ただし、現在インストールされているデスクトップがMATEの場合は、変数値をmateに設定する必要があります。

  次の手順を実行して、ターゲットセッションユーザーのデスクトップ環境を変更することもできます：

  1. VDAの $HOME/<username> ディレクトリに.xsessionまたは.Xclientsファイルを作成します。ここで、usernameはユーザー名です。Amazon Linux 2を使用している場合は、.Xclientsファイルを作成します。他のディストリビューションを使用している場合は、.xsessionファイルを作成します。

  2. .xsessionまたは.Xclientsファイルを編集して、ディストリビューションに基づいてデスクトップ環境を指定します。

     • Amazon Linux 2、およびRHEL 8上のMATEデスクトップの場合

        MSESSION="$(type -p mate-session)"  
        if [ -n "$MSESSION" ]; then  
          exec mate-session  
        fi  
       

     • Amazon Linux 2、CentOS、およびRHEL上のGNOMEクラシックデスクトップの場合

        GSESSION="$(type -p gnome-session)"  
        if [ -n "$GSESSION" ]; then  
        export GNOME_SHELL_SESSION_MODE=classic  
        exec gnome-session --session=gnome-classic  
        fi  
       

     • Amazon Linux 2、CentOS、およびRHEL上のGNOMEデスクトップの場合

        GSESSION="$(type -p gnome-session)"  
        if [ -n "$GSESSION" ]; then  
        exec gnome-session  
        fi  
       

  3. ターゲットセッションユーザーと700ファイルのアクセス権限を共有します。
• 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 を記述し、前述のコマンドからなるシェルスクリプトファイルを作成することをお勧めします。

または、次のようにして、1つのコマンドですべてのパラメーターを指定することができます：

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：Citrix Virtual AppsまたはCitrix Virtual Desktopsでのマシンカタログの作成

マシンカタログを作成し、Linux VDAマシンを追加する手順は、従来のWindows VDAでの方法と似ています。このタスクを完了する方法の説明について詳しくは、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。

次のように、Linux VDAマシンを含むマシンカタログの作成にはいくつかの制約があるため、Windows VDAマシンのマシンカタログの作成手順と異なる点があります：

• オペレーティングシステムには、次を選択します：
  • ホストされる共有デスクトップ配信モデルの場合、マルチセッションOSオプション
  • VDI専用デスクトップ配信モデルの場合、シングルセッションOSオプション
• 同じマシンカタログで、Linux VDAマシンとWindows VDAマシンを混在させないでください。

注：

Citrix Studioの以前のバージョンは、「Linux OS」という概念をサポートしていませんでした。ただし、［WindowsサーバーOS］ オプションまたは ［サーバーOS］ オプションを選択すると、同等のホストされる共有デスクトップ配信モデルが暗黙的に選択されます。［WindowsデスクトップOS］ オプションまたは ［デスクトップOS］ オプションを選択すると、マシンごとに単一ユーザーの配信モデルが暗黙的に選択されます。

ヒント：

マシンがActive Directoryドメインから削除された後に再度追加された場合は、そのマシンをマシンカタログから削除してから再度追加する必要があります。

手順12：Citrix Virtual AppsまたはCitrix Virtual Desktopsでのデリバリーグループの作成

デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加する手順は、Windows VDAマシンの場合とほとんど同じです。このタスクを完了する方法の説明について詳しくは、「デリバリーグループの作成」を参照してください。

Linux VDAマシンカタログを含むデリバリーグループを作成する場合は、次の制約があります：

• 選択するADユーザーおよびグループを、Linux VDAマシンにログオンするように適切に構成しておきます。
• 認証されていない（匿名）ユーザーのログオンを許可しないでください。
• Windowsマシンを含むマシンカタログをデリバリーグループで混在させないでください。

重要：

アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、同一マシンへのデスクトップおよびアプリの配信は、Linux VDAでサポートされていません。

マシンカタログおよびデリバリーグループの作成方法について詳しくは、「Citrix Virtual Apps and Desktops 7 2206」を参照してください。