RHEL/CentOS 用 Linux Virtual Delivery Agent のインストール
この記事の手順に従って手動でインストールするか、簡易インストールを使用して自動インストールと構成を行うことができます。簡易インストールは、時間と労力を節約し、手動インストールよりもエラーが発生しにくいです。
注:
簡易インストールは、新規インストールの場合にのみ使用してください。既存のインストールを更新するために簡易インストールを使用しないでください。
手順 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 ファイルの次の行を、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 への他の参照を削除します。
ヒント:
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 を仮想マシンとしてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモート時刻サービスとの時刻同期が推奨されます。
RHEL 6.x およびそれ以前のリリースでは、クロック同期に NTP デーモン(ntpd)を使用します。一方、RHEL 7.x のデフォルト環境では、代わりに新しい Chrony デーモン(chronyd)を使用します。2 つのサービス間の構成および運用プロセスは似ています。
NTP サービスの構成(RHEL 6/CentOS 6 のみ)
root ユーザーとして、/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 のみ)
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 エントリを含む、リストされている他のすべての server エントリを削除します。
変更を保存し、Chrony デーモンを再起動します。
sudo /sbin/service chronyd restart
<!--NeedCopy-->
手順 1g:OpenJDK のインストール
Linux VDA は OpenJDK に依存します。通常、ランタイム環境はオペレーティングシステムのインストールの一部としてインストールされます。
正しいバージョンを確認します。
- 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-->
**JAVA_HOME** 環境変数を設定するには、次の行を **~/.bashrc** ファイルに追加します。
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 には、RHEL 6 では PostgreSQL 8.4 以降、RHEL 7 では PostgreSQL 9.2 以降が必要です。
次のパッケージをインストールします。
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 VM 内で NTP と XenServer の両方がシステムクロックを管理しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各 Linux ゲスト内のシステムクロックが NTP と同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。HVM モードでは変更は不要です。
一部の Linux ディストリビューションでは、XenServer Tools がインストールされた準仮想化 Linux カーネルを実行している場合、Linux VM 内から XenServer の時刻同期機能が存在し、有効になっているかどうかを確認できます。
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 Integration Services がインストールされている Linux VM は、Hyper-V の時刻同期機能を使用してホストオペレーティングシステムの時刻を使用できます。システムクロックの精度を維持するには、NTP サービスと並行してこの機能を有効にする必要があります。
管理オペレーティングシステムから:
- Hyper-V マネージャーコンソールを開きます。
- Linux VM の設定で、
**統合サービス**を選択します。 -
**時刻の同期**が選択されていることを確認します。
注:
このアプローチは、NTP との競合を避けるためにホストの時刻同期が無効になっている VMware や XenServer とは異なります。Hyper-V の時刻同期は、NTP の時刻同期と共存し、補完することができます。
ESX および ESXi での時刻同期の修正
VMware の時刻同期機能が有効になっている場合、各準仮想化 Linux VM 内で NTP とハイパーバイザーの両方がシステムクロックを同期しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各 Linux ゲスト内のシステムクロックが NTP と同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。
VMware Tools がインストールされた準仮想化 Linux カーネルを実行している場合:
- vSphere Client を開きます。
- Linux VM の設定を編集します。
-
**仮想マシンのプロパティ**ダイアログで、**オプション**タブを開きます。 -
**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
Linux VDAは、Delivery Controllerで認証および登録するためにシステムキータブファイル/etc/krb5.keytabを必要とします。以前のkerberos method設定により、マシンが最初にドメインに参加したときにWinbindがシステムキータブファイルを作成するよう強制されます。
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構成の確認
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コンソールに直接ログオンすることによって実行できます。ドメイン参加の検証後、手順4:Linux VDAのインストールに進みます。
Quest認証サービス
ドメインコントローラーでのQuestの構成
Active DirectoryドメインコントローラーにQuestソフトウェアをインストールおよび構成済みであり、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を無効にすることです。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は、たとえばexample.comのようなドメインのDNS名です。
ドメインメンバーシップの確認
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コンソールに直接ログオンすることでも実行できます。ドメイン参加の確認後、手順4:Linux VDAのインストールに進みます。
Centrify DirectControl
Windowsドメインへの参加
Centrify DirectControl Agentがインストールされている状態で、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」を返すことを確認します。モードが開始状態のままになっている場合、Centrifyクライアントはサーバー接続または認証の問題を抱えています。
より包括的なシステムおよび診断情報は、以下を使用して利用できます。
adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->
さまざまなActive DirectoryおよびKerberosサービスへの接続をテストします。ドメイン参加の確認後、手順4:Linux VDAのインストールに進みます。
adinfo --test
<!--NeedCopy-->
SSSD
SSSDを使用している場合は、このセクションの指示に従ってください。このセクションには、Linux VDAマシンをWindowsドメインに参加させるための手順と、Kerberos認証を構成するためのガイダンスが含まれています。
RHELおよびCentOSでSSSDをセットアップするには、次の手順を実行します。
- ドメインに参加し、Sambaでホストキータブを作成する
- SSSDをセットアップする
- NSS/PAMを構成する
- Kerberos構成を確認する
- ユーザー認証を確認する
必要なソフトウェア
Active Directoryプロバイダーは、SSSDバージョン1.9.0で初めて導入されました。それ以前のバージョンを使用している場合は、Active DirectoryでLDAPプロバイダーを構成するで提供されている指示に従ってください。
この記事に含まれる手順を使用する際に、以下の環境がテストおよび検証されています。
- RHEL 7.3以降/CentOS 7.3以降
- Linux VDAバージョン1.3以降
ドメインへの参加とSambaによるホストキーテーブルの作成
SSSDは、ドメインへの参加やシステムキーテーブルファイルの管理のための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を開き、authconfigツールによって生成されたセクションの後に、[Global]セクションの下に次のエントリを追加します:
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を有効にします。ホームディレクトリの作成が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資格情報キャッシュ内のチケットが有効であり、期限切れになっていないことを確認します。ドメイン参加の検証後、手順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パッケージマネージャーを使用して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-->
RHEL 7のRPM依存関係リスト:
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-->
RHEL 6.9のRPM依存関係リスト:
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-->
RHEL 6.6/CentOS 6.6のRPM依存関係リスト:
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パッケージマネージャーを使用して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 VMゲストのドライバーをインストールおよび構成します。
- 開始する前に、Linux VMがシャットダウンされていることを確認します。
- XenCenter®で、GPUパススルーモードでGPUをVMに追加します。
- RHEL VMを起動します。
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ドライバーのインストール中、各質問に対してデフォルトの「no」を選択してください。
重要:
GPUパススルーが有効になると、Linux VMはXenCenter経由でアクセスできなくなります。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つのFQDNまたはCNAMEエイリアスを指定する必要があります。
- CTX_XDL_VDA_PORT = port-number – Linux VDAは、TCP/IPポートを介してDelivery Controllerと通信します。デフォルトではポート80です。
- 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は、リッチグラフィックアプリケーションの仮想化を最適化するように設計されたGPUアクセラレーション技術のセットであるHDX 3D Proをサポートしています。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は、LDAPサーバーを検出するためにDNSを照会します。DNSがLDAPサービスレコードを提供できない場合、LDAPポートを含むLDAP FQDNのスペース区切りリストを提供できます。例: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オプションを入力します。Citrixは、最初の行に#!/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 \
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マシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。
- オペレーティングシステムには、以下を選択します。
- ホスト型共有デスクトップ配信モデルの場合は、Server OSオプション。
- VDI専用デスクトップ配信モデルの場合は、Desktop OSオプション。
- マシンが電源管理されていないことを確認します。
- MCSはLinux VDAではサポートされていないため、PVSまたは別のサービスまたはテクノロジー(既存のイメージ)の展開方法を選択します。
- 同じマシンカタログにLinux VDAマシンとWindows VDAマシンを混在させないでください。
注:
Citrix Studioの初期バージョンは、「Linux OS」の概念をサポートしていませんでした。ただし、Windows Server OSまたはServer OSオプションを選択することは、同等のホスト型共有デスクトップ配信モデルを意味します。Windows Desktop OSまたはDesktop OSオプションを選択することは、マシンごとに単一ユーザーの配信モデルを意味します。
ヒント:
マシンをActive Directoryドメインから削除して再参加させる場合、マシンをマシンカタログから削除して再度追加する必要があります。
ステップ 9: XenApp®またはXenDesktopでのデリバリーグループの作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加するプロセスは、Windows VDAマシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。
- 配信タイプには、デスクトップまたはアプリケーションを選択します。
- 選択したADユーザーとグループが、Linux VDAマシンにログオンできるように適切に構成されていることを確認してください。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- デリバリーグループと、Windowsマシンを含むマシンカタログを混在させないでください。
重要:
アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、Linux VDAは、デスクトップとアプリを同じマシンに配信することをサポートしていません。