Linux Virtual Delivery Agent for RHEL/CentOSのインストール
この記事の手順に従って手動でインストールするか、簡単インストールを使用して自動でインストールして構成するかを選択できます。簡単インストールは時間と労力を節約するだけでなく、手動のインストールよりもエラーを減らすことができます。
注
：新規のインストールでは、簡単インストールのみを使用します。既存インストールの更新には、簡単インストールを使用しないでください。
手順1：VDAをインストールするRHEL 7/CentOS 7、RHEL 6/CentOS 6の準備
手順1a：ネットワーク構成の確認
Citrixは、続行前にネットワークを接続し、適切に構成することをお勧めします。
手順1b：ホスト名の設定
注：
Linux VDAは現在、NetBIOS名の切り捨てをサポートしていません。したがって、ホスト名は15文字以内である必要があります。
マシンのホスト名が確実に正しく報告されるようにするには、/etc/hostname ファイルを変更してマシンのホスト名のみを記述します。
HOSTNAME=hostname
手順1c：ホスト名へのループバックアドレスの割り当て
注：
Linux VDAは現在、NetBIOS名の切り捨てをサポートしていません。したがって、ホスト名は15文字以内である必要があります。
マシンの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に対するその他の参照を削除します。
ヒント：
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 6.x以前のリリースでは、時刻同期にNTPデーモン（ntpd）を使用しています。一方、RHEL 7.xのデフォルト環境では、新しいChronyデーモン（chronyd）を代わりに使用しています。この2つのサービスの構成と操作手順は類似しています。
NTPサービスの構成（RHEL 6/CentOS 6のみ）
ルートユーザーとして /etc/ntp.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エントリを削除します。
変更を保存してから、次のコマンドでNTPデーモンを再起動します：
sudo /sbin/service ntpd restart
<!--NeedCopy-->
Chronyサービスの構成（RHEL 7/CentOS 7のみ）
ルートユーザーとして /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のインストール
Linux VDAはOpenJDKに依存しています。通常、Runtime Environmentは、オペレーティングシステムの一部としてインストールされています。
正しいバージョンを確認します。
- RHEL 7/CentOS 7：
sudo yum info java-1.8.0-openjdk
<!--NeedCopy-->
- RHEL 6/CentOS 6：
sudo yum info java-1.7.0-openjdk
<!--NeedCopy-->
事前にパッケージされたOpenJDKは、以前のバージョンである可能性があります。必要に応じて、次のコマンドで最新バージョンに更新します：
- RHEL 7/CentOS 7：
sudo yum -y update java-1.8.0-openjdk
<!--NeedCopy-->
- RHEL 6/CentOS 6：
sudo yum -y update java-1.7.0-openjdk
<!--NeedCopy-->
次の行を ~/.bashrc ファイルに追加して、JAVA_HOME 環境変数を設定します：
export JAVA\_HOME=/usr/lib/jvm/java
新しいシェルを開き、次のコマンドでJavaのバージョンを確認します：
java -version
<!--NeedCopy-->
ヒント：
問題を回避するために、RHEL 6/CentOS 6の場合はOpenJDKバージョン1.7.0または1.8.0、RHEL 7/CentOS 7の場合はOpenJDKバージョン1.8.0をインストールするようにしてください。その他のバージョンのJavaは、システムからすべて削除します。
手順1h：PostgreSQLのインストール
Linux VDAには、PostgreSQL 8.4以降（RHEL 6の場合）またはPostgreSQL 9.2以降（RHEL 7の場合）のいずれかが必要です。
次のパッケージをインストールします：
sudo yum -y install postgresql-server
sudo yum -y install postgresql-jdbc
<!--NeedCopy-->
データベースを初期化し、マシンの起動時にサービスが確実に開始されるようにするには、次に示すインストール後の手順が必要です。この操作により、/var/lib/pgsql/data にデータベースファイルが作成されます。このコマンドは、PostgreSQL 8とPostgreSQL 9では異なります：
- RHEL 7のみ：PostgreSQL 9
sudo postgresql-setup initdb
<!--NeedCopy-->
- RHEL 6のみ：PostgreSQL 8
sudo /sbin/service postgresql initdb
<!--NeedCopy-->
手順1i：PostgreSQLの起動
マシンの起動時にサービスを開始し、直ちにサービスを開始します：
- RHEL 7のみ：PostgreSQL 9
sudo systemctl enable postgresql
sudo systemctl start postgresql
<!--NeedCopy-->
- RHEL 6のみ：PostgreSQL 8
sudo /sbin/chkconfig postgresql on
sudo /sbin/service postgresql start
<!--NeedCopy-->
次のコマンドを使用して、PostgreSQLのバージョンを確認します。
psql --version
<!--NeedCopy-->
次のようにpsqlコマンドラインユーティリティを使用して、データディレクトリが設定されていることを確認します：
sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->
重要：
このリリースでは、gperftools-libsに新しい依存関係が追加されていますが、この依存関係は元のリポジトリには存在していません。
sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpmコマンドを使用して、新しいリポジトリを追加します。
RHEL 6/CentOS 6のみが影響を受けます。Linux VDAパッケージをインストールする前に、このコマンドを実行します。
手順2：ハイパーバイザーの準備
サポートされるハイパーバイザー上で仮想マシンとしてLinux VDAを実行する場合、いくつかの変更が必要です。使用するハイパーバイザーのプラットフォームに合わせて、次の変更を行います。ベアメタルハードウェアでLinuxマシンを実行する場合、変更は必要ありません。
Citrix XenServerでの時刻同期の修正
XenServerの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとXenServerの両方がシステムの時間を管理しようとすることが原因となり問題が発生します。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは、変更は必要ありません。
一部のLinuxディストリビューションでは、XenServer Toolsがインストールされた準仮想化Linuxカーネルを実行している場合、XenServerの時刻同期機能が存在するかどうかと、Linux仮想マシン内で有効になっているかどうかを確認できます：
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは0または1を返します：
- 0 - 時刻同期機能が有効になっているため、無効にする必要があります。
- 1 - 時刻同期機能が無効になっています。これ以上の操作は必要ありません。
/proc/sys/xen/indepent_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サービスとともにこの機能を有効にする必要があります。
管理オペレーティングシステムで、次の操作を行います。
- Hyper-Vマネージャーを開きます。
- Linux仮想マシンの設定で、［統合サービス］ を選択します。
- ［時刻の同期］ が選択されていることを確認します。
注：
この方法はVMwareおよびXenServerの場合とは異なります。VMwareおよびXenServerでは、NTPとの競合を避けるためにホストの時刻同期を無効にします。Hyper-Vの時刻同期は、NTPと共存し、NTPの時刻同期を補完することができます。
ESXおよびESXiでの時刻同期の修正
VMwareの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとハイパーバイザーの両方がシステムの時間を同期しようとすることが原因となり問題が発生します。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsをインストールした状態で準仮想化Linuxカーネルを実行している場合は、次の操作を行います。
- vSphere Clientを開きます。
- Linux仮想マシンの設定を編集します。
- ［仮想マシンのプロパティ］ ダイアログボックスで、［オプション］ タブをクリックします。
- ［VMware Tools］ を選択します。
- ［詳細］ ボックスで、［ホストとゲスト時刻を同期］ チェックボックスをオフにします。
手順3：Linux仮想マシン（VM）をWindowsドメインに追加
Linux VDAは、LinuxマシンをActive Directory（AD）ドメインに追加するさまざまな方法をサポートします。
- Samba Winbind
- Quest Authentication Service
- Centrify DirectControl
- SSSD
選択した方法の手順に従います。
注：
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗することがあります。
Samba Winbind
次のようにして、必要なパッケージをインストールまたは更新します：
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認証用にマシンを構成します：
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サービスを開始しようとすると発生することがあります。
/etc/samba/smb.confを開いて、［Global］ セクションに次のエントリを追加します。ただし、追加するのは、authconfigツールによって生成されたセクションの後です：
kerberos method = secrets and keytab
winbind refresh tickets = true
Delivery Controllerに対する認証と登録には、Linux VDAにシステムのkeytabファイル/etc/krb5.keytabが必要です。前述のkerberosを使用した設定により、マシンが初めてドメインに参加するときに、Winbindによってシステムのkeytabファイルが強制的に作成されます。
Windowsドメインへの参加
ドメインコントローラーがアクセス可能で、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です：
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コンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順4：Linux VDAのインストール」に進みます。
Quest Authentication Service
ドメインコントローラーでのQuestの構成
次の操作は、QuestソフトウェアをActive Directoryドメインコントローラーにインストールし、構成していることと、管理者特権が付与され、Active Directoryにコンピューターオブジェクトを作成できることを前提としています。
Linux VDAマシンにドメインユーザーがログオンできるようにする
Linux VDAマシンでHDXセッションを確立する必要がある各ドメインユーザーに対して、次の操作を行います。
- ［Active Directoryユーザーとコンピューター］管理コンソールで、目的のユーザーアカウントのActive Directoryユーザーのプロパティを開きます。
- ［Unixアカウント］ タブを選択します。
- ［Unix対応］ チェックボックスをオンにします。
- ［プライマリ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コンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順4：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サービスとの接続をテストします。ドメイン参加の確認後、「手順4：Linux VDAのインストール」に進みます。
adinfo --test
<!--NeedCopy-->
SSSD
SSSDを使用している場合は、このセクションの指示に従ってください。このセクションでは、Linux VDAマシンのWindowsドメインへの参加手順、およびKerberos認証の構成について説明します。
SSSDをRHELおよびCentOSでセットアップするには、次の作業を行います：
- ドメインに参加し、Sambaを使用してホストのkeytabを作成する
- SSSDのセットアップ
- NSS/PAMの構成
- Kerberos構成の確認
- ユーザー認証の確認
必要なソフトウェア
Active Directoryプロバイダーは、SSSD Version 1.9.0で初めて導入されました。古いバージョンを使用している場合は、Configuring the LDAP provider with Active Directoryの指示に従ってください。
次の環境については、このドキュメントに記載した指示を使用したテストおよび検証を行っています。
- RHEL 7.3以降/CentOS 7.3以降
- Linux VDA Version 1.3以降
ドメインに参加し、Sambaを使用してホストのkeytabを作成する
SSSDでは、ドメイン参加とシステムのkeytabファイルの管理に関するActive Directoryのクライアント機能が提供されていません。代わりにadcli、realmd、WinbindまたはSambaを使用できます。
このセクションでは、Sambaによるアプローチについてのみ説明します。realmdに関しては、RHELまたはCentOSのドキュメントを参照してください。SSSDを構成する前に、以下の手順に従う必要があります。
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名です。
KDCサーバーおよび領域名をDNSベースで参照する必要がある場合は、次の2つのオプションを前述のコマンドに追加します：
--enablekrb5kdcdns --enablekrb5realmdns
/etc/samba/smb.confを開いて、［Global］ セクションに次のエントリを追加します。ただし、追加するのは、authconfigツールによって生成されたセクションの後です：
kerberos method = secrets and keytab
Windowsドメインに参加します。ドメインコントローラーに到達できることと、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントがあることを確認します：
sudo net ads join REALM -U user
<!--NeedCopy-->
REALMは大文字のKerberos領域名で、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。
SSSDのセットアップ
SSSDのセットアップは、以下の手順で構成されています：
- Linux VDAに sssd-ad パッケージをインストールします。
- さまざまなファイルに構成の変更を行う（sssd.confなど）。
- sssdサービスを開始します。
sssd.confの設定の例（必要に応じて追加の設定を行うことができます）：
[sssd]
config_file_version = 2
domains = ad.example.com
services = nss, pam
[domain/ad.example.com]
# Uncomment if you need offline logins
# cache_credentials = true
id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = ad
# Should be specified as the lower-case version of the long version of the Active Directory domain.
ad_domain = ad.example.com
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# Uncomment if service discovery is not working
# ad_server = server.ad.example.com
# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
<!--NeedCopy-->
ad.example.com と server.ad.example.com を対応する値で置き換えます。詳しくは、「sssd-ad(5) - Linux man page」を参照してください。
ファイルの所有権およびアクセス権をsssd.confで設定します：
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
NSS/PAMの構成
RHEL/CentOS：
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資格情報キャッシュのチケットが有効で、期限切れではないことを確認します。ドメイン参加の確認後、「手順4：Linux VDAのインストール」に進みます。
klist
<!--NeedCopy-->
手順4：Linux VDAのインストール
手順4a：古いバージョンのアンインストール
以前のバージョンのLinux VDAがインストールされている場合は、それをアンインストールしてから新しいバージョンをインストールする必要があります。
-
次のコマンドで、Linux VDAサービスを停止します：
sudo /sbin/service ctxvda stop sudo /sbin/service ctxhdx stop <!--NeedCopy--> -
次のコマンドで、パッケージをアンインストールします：
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
注：
最新の2バージョンからのアップグレードがサポートされます。
注：
バージョン1.3以降、インストールパスが変更されます。以前のリリースでは、インストールコンポーネントは /usr/local/ に配置されていました。新しい場所は /opt/Citrix/VDA/ です。
コマンドを実行するには、フルパスが必要です。代わりに、システムパスに/opt/Citrix/VDA/sbinおよび/opt/Citrix/VDA/binを追加することもできます。
手順4b：Linux VDAパッケージのダウンロード
Citrix Webサイトにアクセスし、使用しているLinuxディストリビューションに応じた適切なLinux VDAパッケージをダウンロードします。
手順4c：Linux VDAのインストール
Yumを使用してLinux VDAソフトウェアをインストールします：
RHEL 7/CentOS 7の場合：
sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->
RHEL 6.9の場合：
sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->
RHEL 6.6/CentOS 6.6の場合：
sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->
RPM Package Managerを使用して、Linux VDAソフトウェアをインストールします。その前に、次の依存関係を解決する必要があります。
RHEL 7/CentOS 7の場合：
sudo rpm -i XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->
RHEL 6.9の場合：
sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->
RHEL 6.6/CentOS 6.6の場合：
sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->
RPM依存関係一覧（RHEL 7の場合）：
postgresql-server >= 9.2
postgresql-jdbc >= 9.2
java-1.8.0-openjdk >= 1.8.0
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
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
xorg-x11-server-Xorg >= 1.17
xorg-x11-server-Xorg < 1.18
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->
RPM依存関係一覧（RHEL 6.9の場合）：
postgresql-jdbc >= 8.4
postgresql-server >= 8.4
java-1.7.0-openjdk >= 1.7.0
ImageMagick >= 6.5.4.7
GConf2 >= 2.28.0
system-config-firewall-base >= 1.2.27
policycoreutils-python >= 2.0.83
xorg-x11-server-utils >= 7.7
xorg-x11-xinit >= 1.0.9
ConsoleKit >= 0.4.1
dbus >= 1.2.24
dbus-x11 >= 1.2.24
libXpm >= 3.5.10
libXrandr >= 1.4.1
libXtst >= 1.2.2
openmotif >= 2.3.3
pam >= 1.1.1
util-linux-ng >= 2.17.2
bash >= 4.1
findutils >= 4.4
gawk >= 3.1
sed >= 4.2
cups >= 1.4.0
foomatic >= 4.0.0
openldap >= 2.4
cyrus-sasl >= 2.1
cyrus-sasl-gssapi >= 2.1
libxml2 >= 2.7
python-requests >= 2.6.0
gperftools-libs >= 2.0
xorg-x11-server-Xorg >= 1.17
xorg-x11-server-Xorg < 1.18
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->
RPM依存関係一覧（RHEL 6.6/CentOS 6.6の場合）：
postgresql-jdbc >= 8.4
postgresql-server >= 8.4
java-1.7.0-openjdk >= 1.7.0
ImageMagick >= 6.5.4.7
GConf2 >= 2.28.0
system-config-firewall-base >= 1.2.27
policycoreutils-python >= 2.0.83
xorg-x11-server-utils >= 7.7
xorg-x11-xinit >= 1.0.9
ConsoleKit >= 0.4.1
dbus >= 1.2.24
dbus-x11 >= 1.2.24
libXpm >= 3.5.10
libXrandr >= 1.4.1
libXtst >= 1.2.2
openmotif >= 2.3.3
pam >= 1.1.1
util-linux-ng >= 2.17.2
bash >= 4.1
findutils >= 4.4
gawk >= 3.1
sed >= 4.2
cups >= 1.4.0
foomatic >= 4.0.0
openldap >= 2.4
cyrus-sasl >= 2.1
cyrus-sasl-gssapi >= 2.1
libxml2 >= 2.7
python-requests >= 2.6.0
gperftools-libs >= 2.0
xorg-x11-server-Xorg >= 1.15
xorg-x11-server-Xorg < 1.16
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->
手順4d：Linux VDAのアップグレード（オプション）
YumコマンドでLinux VDAソフトウェアをバージョン7.14や7.13にアップグレードできます：
RHEL 7/CentOS 7の場合：
sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->
RHEL 6.9の場合：
sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->
RHEL 6.6/CentOS 6.6の場合：
sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->
次のように、RPM Package Managerを使用して、Linux VDAソフトウェアをアップグレードします：
RHEL 7/CentOS 7の場合：
sudo rpm -U XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->
RHEL 6.9の場合：
sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->
RHEL 6.6/CentOS 6.6の場合：
sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->
重要：
ソフトウェアをアップグレードした後、Linux VDAマシンを再起動してください。
手順5：NVIDIA GRIDドライバーのインストール
HDX 3D Proを有効にするには、ハイパーバイザーとVDAマシンに必要なグラフィックドライバーをインストールするために、追加のインストール手順が必要です。
次のオプションを構成します：
- Citrix XenServer
- VMware ESX
選択したハイパーバイザーに対応する手順に従います。
Citrix XenServer：
この詳しいセクションでは、Citrix XenServer上でのNVIDIA GRIDドライバーのインストールおよび構成の概略について説明します。
VMware ESX：
このガイドに掲載されている情報に従って、VMware ESX用のNVIDIA GRIDドライバーをインストールし、構成します。
VDAマシン：
以下の手順に従って、Linux仮想マシンゲストのそれぞれに対してドライバーをインストールし、構成します：
- 開始する前に、Linux仮想マシンがシャットダウンされていることを確認します。
- XenCenterで、GPUパススルーモードのGPUを仮想マシンに追加します。
- RHEL仮想マシンを起動します。
NVIDIA GRIDドライバー用にマシンを準備するには、次のコマンドを実行します：
yum install gcc
yum install "kernel-devel-$(uname -r)"
systemctl set-default multi-user.target
<!--NeedCopy-->
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』の製品ドキュメントの指示に従ってください。
手順6：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 Virtual Desktopサービスは、マシンの起動後に開始します。デフォルトでは値はYに設定されています。
- CTX_XDL_ADD_FIREWALL_RULES = Y | N – Linux Virtual Desktopサービスでは、ネットワーク受信接続がシステムのファイアウォールの通過を許可されている必要があります。Linux Virtual Desktop用に、システムのファイアウォールの必要なポート（デフォルトではポート80およびポート1494）を自動で開放できます。デフォルトではYに設定されています。
-
CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 – Linux VDAには、Delivery Controllerに対して認証するためにKerberos構成設定が必要です。Kerberos構成は、システムにインストールおよび構成済みのActive Directory統合ツールから指定します。次に示す、サポートされているActive Directory統合方法のうち、使用するものを指定します：
- 1 - Samba Winbind
- 2 - Quest Authentication Service
- 3 - Centrify DirectControl
- 4 - SSSD
- CTX_XDL_HDX_3D_PRO = Y | N – Linux VDAでは、HDX 3D Proがサポートされます。これは、強力なグラフィックアプリケーションの仮想化を最適にするための一連のGPUアクセラレーションテクノロジです。HDX 3D Proを選択した場合、Virtual Delivery Agentは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となります。この変数は、デフォルトでは <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_START_SERVICE = Y | N – Linux VDA構成の完了時にLinux VDAサービスが開始されるようにするかどうかを指定します。デフォルトではYに設定されています。
次のようにして、環境変数を設定し、構成スクリプトを実行します：
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
export CTX_XDL_HDX_3D_PRO=Y|N
export CTX_XDL_VDI_MODE=Y|N
export CTX_XDL_SITE_NAME=dns-name
export CTX_XDL_LDAP_LIST=list-ldap-servers
export CTX_XDL_SEARCH_BASE=search-base-set
export CTX_XDL_START_SERVICE=Y|N
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
sudoコマンドに-Eオプションを指定して実行し、作成する新しいシェルに既存の環境変数を渡します。最初の行として #!/bin/bash を記述し、前述のコマンドからなるシェルスクリプトファイルを作成することをCitrixではお勧めします。
または、次のようにして、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 \
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_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サービスを再起動し、変更を反映させます。
手順7：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-->
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-->
手順8：XenAppまたはXenDesktopでマシンカタログを作成
マシンカタログを作成し、Linux VDAマシンを追加する手順は、従来のWindows VDAでの方法と似ています。このタスクを完了する方法の説明について詳しくは、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
次のように、Linux VDAマシンを含むマシンカタログの作成にはいくつかの制約があるため、Windows VDAマシンのマシンカタログの作成手順と異なる点があります：
- オペレーティングシステムには、次を選択します：
- ホストされる共有デスクトップ配信モデルの場合、［サーバーOS］オプション
- VDI専用デスクトップ配信モデルの場合、［デスクトップOS］オプション
- マシンが電源管理を行わない設定になっていることを確認します。
- MCSはLinux VDAではサポートされないため、PVSまたは他のサービスまたはテクノロジ（既存のイメージ）の展開方法を選択してください。
- 同じマシンカタログで、Linux VDAマシンとWindows VDAマシンを混在させないでください。
注：
Citrix Studioの以前のバージョンは、「Linux OS」という概念をサポートしていませんでした。ただし、［WindowsサーバーOS］ オプションまたは ［サーバーOS］ オプションを選択すると、同等のホストされる共有デスクトップ配信モデルが暗黙的に選択されます。［WindowsデスクトップOS］ オプションまたは ［デスクトップOS］ オプションを選択すると、マシンごとに単一ユーザーの配信モデルが暗黙的に選択されます。
ヒント：
マシンがActive Directoryドメインから削除された後に再度追加された場合は、そのマシンをマシンカタログから削除してから再度追加する必要があります。
手順9：XenAppまたはXenDesktopでデリバリーグループを作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加する手順は、Windows VDAマシンの場合とほとんど同じです。このタスクを完了する方法の説明について詳しくは、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合は、次の制約があります：
- 配信の種類には、［デスクトップ］または［アプリケーション］を選択します。
- 選択するADユーザーおよびグループを、Linux VDAマシンにログオンするように適切に構成しておきます。
- 認証されていない（匿名）ユーザーのログオンを許可しないでください。
- Windowsマシンを含むマシンカタログをデリバリーグループで混在させないでください。
重要：
アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、同一マシンへのデスクトップおよびアプリの配信は、Linux VDAでサポートされていません。