SUSEへのLinux VDAの手動インストール
重要:
新規インストールの場合は、簡単インストールを使用して簡易インストールを行うことをお勧めします。簡単インストールは時間と労力を節約するだけでなく、本記事に記載されている手動インストールよりもエラーを減らすことができます。
手順1: 構成ファイル情報およびLinuxマシンの準備
手順1a:YaSTツールの起動
SUSE Linux Enterprise YaSTツールを使用して、オペレーティングシステムのすべての要素を構成します。
テキストベースのYaSTツールを起動する方法
su -
yast
<!--NeedCopy-->
UIベースのYaSTツールを起動する方法:
su -
yast2 &
<!--NeedCopy-->
手順1b:ネットワークの構成
以降のセクションでは、Linux VDAで使用するさまざまなネットワーク設定およびサービスの構成方法に関する情報について説明します。ネットワークの構成は、Network Managerなどの他の方法ではなく、YaSTツールで実行する必要があります。次の手順は、UIベースのYaSTツールを使用することが前提となっています。テキストベースのYaSTツールも使用できますが、ナビゲーション方法が異なり、ここでは説明していません。
ホスト名とドメインネームシステム(DNS)の構成
- UIベースのYaSTツールを起動します。
- [システム] 、[ネットワーク設定]の順に選択します。
- [ホスト名/DNS] タブを開きます。
- [DHCPでホスト名を設定する] オプションでいいえを選択します。
- [DNS構成の変更] で [カスタムポリシーを使用する] オプションをオンにします。
-
以下を編集してネットワーク設定に反映させます。
- 静的ホスト名 – マシンのDNSホスト名を追加します。
- ネームサーバー – DNSサーバーのIPアドレスを追加します。通常はADドメインコントローラーのIPアドレスです。
- [ドメイン検索]一覧 – DNSドメイン名を追加します。
-
/etc/hosts
ファイルの次の行の最初の2つのエントリにFQDNとホスト名が含まれるように編集します:127.0.0.1 <FQDN of the VDA> <hostname of the VDA> localhost
注:
Linux VDAは現在、NetBIOS名の切り捨てをサポートしていません。したがって、ホスト名は15文字以内である必要があります。 ヒント:
a~z、A~Z、0~9、およびハイフン(-)の文字のみ使用してください。アンダースコア(_)、スペース、およびその他の記号は使用しないでください。ホスト名を数字で開始したり、ハイフンで終了したりしないでください。このルールは、Delivery Controllerのホスト名にも適用されます。
ホスト名の確認
次のコマンドで、ホスト名が正しく設定されていることを確認します:
hostname
<!--NeedCopy-->
このコマンドにより、そのマシンの完全修飾ドメイン名(FQDN)ではなく、そのホスト名のみが返されます。
次のコマンドで、完全修飾ドメイン名が正しく設定されていることを確認します:
hostname -f
<!--NeedCopy-->
このコマンドにより、そのマシンの完全修飾ドメイン名が返されます。
名前解決とサービス到達可能性の確認
次のコマンドで、完全修飾ドメイン名が解決できることと、ドメインコントローラーとDelivery Controllerからpingに応答があることを確認します:
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
完全修飾ドメイン名を解決できない、またはこれらのマシンのいずれかからpingに応答がない場合は、手順を確認してから次に進んでください。
手順1c:NTPサービスの構成
VDA、Delivery Controller、ドメインコントローラーの間で正確な時刻同期を維持することが重要です。仮想マシン(VM)としてLinux VDAをホストすると、時刻が不正確になる問題が発生する可能性があります。したがって、リモートNTPサービスを使用して時刻を維持することをお勧めします。次のように、デフォルトNTP設定にいくつかの変更が必要な場合があります。
SUSE 15.4の場合:
- UIベースのYaSTツールを起動します。
- [ネットワークサービス] 、[NTP設定] の順に選択します。
- [NTPデーモンを起動する] セクションで、[今すぐ開始し、システム起動時に開始するよう設定] を選択します。
- [設定元] で [動的] を選択します。
- 必要に応じてNTPサーバーを追加します。このNTPサービスは、通常Active Directoryドメインコントローラーでホストされます。
-
/etc/chrony.confに次の行があれば、削除するかコメントを付けます。
include /etc/chrony.d/*.conf
chrony.confを編集した後、
chronyd
サービスを再起動します。sudo systemctl restart chronyd.service <!--NeedCopy-->
手順1d:Linux VDAに依存するパッケージのインストール
SUSE Linux Enterprise用のLinux VDAソフトウェアは、次のパッケージに依存しています:
- OpenJDK 11
- Open Motif Runtime Environment 2.3.1以降
- Cups 1.6.0以降
- ImageMagick 6.8以降
リポジトリの追加
ImageMagickを除くほとんどの必要なパッケージは、公式リポジトリから入手できます。ImageMagickパッケージを入手するには、YaSTまたは次のコマンドを使用してsle-module-desktop-applications
リポジトリを有効にします:
SUSEConnect -p sle-module-desktop-applications/<version number>/x86_64
Kerberosクライアントのインストール
次のコマンドで、Linux VDAとDelivery Controller間の相互認証用にKerberosクライアントをインストールします。
sudo zypper install krb5-client
<!--NeedCopy-->
Kerberosクライアントの構成は、使用するActive Directory統合の方法によって異なります。以下の説明を参照してください。
OpenJDK 11のインストール
Linux VDAには、OpenJDK 11が必要です。
OpenJDK 11をインストールするには、次のコマンドを実行します:
sudo zypper install java-11-openjdk
<!--NeedCopy-->
使用するデータベースのインストールと指定
Linux VDAパッケージのインストール後、/etc/xdl/db.confを編集して使用するSQLiteまたはPostgreSQLを指定できます。手動インストールの場合、SQLiteとPostgreSQLを事前に手動でインストールしていないとこれを指定することができません。
このセクションでは、PostgreSQLとSQLiteのデータベースをインストールする方法と、使用するデータベースを指定する方法について説明します。
注:
SQLiteはVDIモードにのみ使用することをお勧めします。
PostgreSQLのインストール
Postgresql
をインストールするには、次のコマンドを実行します:
sudo zypper install postgresql-server
sudo zypper install postgresql-jdbc
<!--NeedCopy-->
マシンの起動時または即時でPostgreSQL起動するには、それぞれ次のコマンドを実行します:
sudo systemctl enable postgresql
sudo systemctl restart postgresql
<!--NeedCopy-->
SQLiteをインストールする
SUSEの場合、次のコマンドを実行してSQLiteをインストールします:
sudo zypper install sqlite3
<!--NeedCopy-->
使用するデータベースを指定する
SQLite、PostgreSQL、またはその両方をインストールした後、Linux VDAパッケージをインストールしてから/etc/xdl/db.confを編集すると、使用するデータベースを指定できます。このためには、次の手順を実行します:
- /opt/Citrix/VDA/sbin/ctxcleanup.shを実行します。新規インストールの場合、この手順は省きます。
- /etc/xdl/db.confを編集して、使用するデータベースを指定します。
- ctxsetup.shを実行します。
注:
/etc/xdl/db.conf を使用してPostgreSQLのポート番号を構成することもできます。
手順2:ハイパーバイザーの準備
サポートされるハイパーバイザー上でVMとして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
これらの変更を確認するため、次のようにしてシステムを再起動します:
reboot
<!--NeedCopy-->
再起動後、設定が正しいことを確認します:
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは1を返します。
Microsoft Hyper-Vでの時刻同期の修正
Hyper-V Linux統合サービスがインストールされたLinux仮想マシンでは、Hyper-Vの時刻同期機能を適用してホストオペレーティングシステムの時間を利用できます。システムの時間を正確な状態で維持するには、NTPサービスとともにこの機能を有効にします。
管理オペレーティングシステムで、次の操作を行います。
- Hyper-Vマネージャーを開きます。
- Linux仮想マシンの設定で、[統合サービス] を選択します。
- [時刻の同期] が選択されていることを確認します。
注:
この方法はVMwareおよびCitrix Hypervisorの場合とは異なります。VMwareおよびCitrix Hypervisorでは、NTPとの競合を避けるためにホストの時刻同期を無効にします。Hyper-Vの時刻同期は、NTPと共存し、NTPの時刻同期を補完することができます。
ESXおよびESXiでの時刻同期の修正
VMwareの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとハイパーバイザーで問題が発生します。これは、NTPとハイパーバイザーの両方がシステムの時間を同期しようとすることが原因です。システムの時刻と他のサーバーの時刻との同期が失われるのを防ぐには、各Linuxゲストのシステムの時刻をNTPと同期させます。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsをインストールした状態で準仮想化Linuxカーネルを実行している場合は、次の操作を行います。
- vSphere Clientを開きます。
- Linux仮想マシンの設定を編集します。
- [仮想マシンのプロパティ] ダイアログボックスで、[オプション] タブをクリックします。
- [VMware Tools] を選択します。
- [詳細] ボックスで、[ホストとゲスト時刻を同期] チェックボックスをオフにします。
手順3:Linux VMをWindowsドメインに追加
以下は、LinuxマシンをActive Directory(AD)ドメインに追加する方法です:
選択した方法の手順に従います。
注:
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗することがあります。
Samba Winbind
Windowsドメインへの参加
ドメインコントローラーがアクセス可能で、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
-
YaSTを起動し、[ネットワークサービス]、[Windowsドメインメンバーシップ] の順に選択します。
-
以下の変更を行います。
- [ドメイン/ワークグループ] にActive Directoryドメインの名前またはドメインコントローラーのIPアドレスを設定します。ドメイン名は必ず大文字にします。
-
[Linuxの認証にSMBの情報を使用する] チェックボックスをオンにします。
- [Create Home Directory on Login] チェックボックスをオンにします。
- [SSH向けのシングルサインオン] チェックボックスをオンにします。
- [オフライン認証] チェックボックスがオフになっていることを確認します。Linux VDAは、このオプションに対応していません。
-
[OK] をクリックします。いくつかのパッケージのインストールを促すメッセージが表示された場合は、[インストール]をクリックします。
-
ドメインコントローラーが見つかると、ドメインに参加するかどうかを確認するメッセージが表示されます。[はい] をクリックします。
-
メッセージが表示されたら、マシンをドメインに追加する権限を持つドメインユーザーの資格情報を入力し、[OK]をクリックします。
-
サービスを手動で再起動するか、マシンを再起動してください。マシンを再起動することをお勧めします:
su - reboot <!--NeedCopy-->
ドメインメンバーシップの確認
Delivery Controllerを使用するには、すべてのVDAマシン(WindowsとLinux VDA)でActive Directoryにコンピューターオブジェクトが必要です。
次のように、Sambaのnet adsコマンドを実行して、マシンがドメインに参加していることを確認します:
sudo net ads testjoin
<!--NeedCopy-->
追加のドメインおよびコンピューターオブジェクト情報を検証するには、次のコマンドを実行します:
sudo net ads info
<!--NeedCopy-->
Kerberos構成の確認
システムの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-->
次のコマンドで、id -uコマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
次のコマンドで、ユーザーのKerberos資格情報キャッシュのチケットが有効で、期限切れではないことを確認します:
klist
<!--NeedCopy-->
次のコマンドで、セッションを終了します。
exit
<!--NeedCopy-->
GnomeコンソールまたはKDEコンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順6:Linux VDAのインストール」に進みます。
Quest Authentication Service
ドメインコントローラーでのQuestの構成
次の操作は、Questソフトウェアをドメインコントローラーにインストールし、構成していることと、管理者特権が付与され、Active Directory
にコンピューターオブジェクトを作成できることを前提としています。
Linux VDAマシンにドメインユーザーがログオンできるようにする
Linux VDAマシンでHDXセッションを確立する必要がある各ドメインユーザーに対して、次の操作を行います。
- [Active Directoryユーザーとコンピューター]管理コンソールで、目的のユーザーアカウントのActive Directoryユーザーのプロパティを開きます。
- [Unixアカウント] タブを選択します。
- [Unix対応] チェックボックスをオンにします。
- [プライマリGID番号] を、実際のドメインユーザーグループのグループIDに設定します。
注:
この手順は、ドメインユーザーがコンソール、RDP、SSH、またはその他のリモート処理プロトコルを使用してログオンできるように設定する場合も同じです。
Linux VDAでのQuestの構成
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
ユーザー認証の確認
QuestがPAMを介してドメインユーザーを認証できることを確認します。これを行うには、以前に使用したことがないドメインユーザーアカウントを使用してLinux VDAにログオンします。
ssh localhost -l domain\username
id -u
<!--NeedCopy-->
次のコマンドで、id -uコマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
次のコマンドで、Kerberos資格情報キャッシュのチケットが有効で、期限切れではないことを確認します:
/opt/quest/bin/vastool klist
<!--NeedCopy-->
次のコマンドで、セッションを終了します。
exit
<!--NeedCopy-->
GnomeコンソールまたはKDEコンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順6:Linux VDAのインストール」に進みます。
Centrify DirectControl
Windowsドメインへの参加
Centrify DirectControl Agentがインストールされている場合、次のようにCentrifyのadjoinコマンドを使用して、LinuxマシンをActive Directoryドメインに追加します:
sudo 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マシンがドメインに存在することを確認するには、次のコマンドを実行します:
sudo 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
SUSEでSSSDを使用している場合は、このセクションの指示に従ってください。このセクションでは、Linux VDAマシンのWindowsドメインへの参加手順、およびKerberos認証の構成について説明します。
SUSEでSSSDをセットアップするには、次の手順を実行します:
- ドメインに参加してホストのkeytabを作成
- SSSD用のPAMの構成
- SSSDのセットアップ
- SSSDの有効化
- ドメインメンバーシップの確認
- Kerberos構成の確認
- ユーザー認証の確認
ドメインに参加してホストのkeytabを作成
SSSDでは、ドメイン参加とシステムのkeytabファイルの管理に関するActive Directoryのクライアント機能が提供されていません。代わりにSambaアプローチを使用できます。SSSDを構成する前に、以下の手順を実行してください。
-
Name Service Cache Daemon(NSCD)デーモンを停止して無効にします。
sudo systemctl stop nscd sudo systemctl disable nscd <!--NeedCopy-->
-
ホスト名とChronyの時間同期を確認してください。
hostname hostname -f chronyc traking <!--NeedCopy-->
-
次のようにして、必要なパッケージをインストールまたは更新します:
sudo zypper install samba-client sssd-ad <!--NeedCopy-->
-
/etc/krb5.conf
ファイルをルートユーザーとして編集し、kinitユーティリティがターゲットドメインと通信できるようにします。[libdefaults]、[realms]、[domain_realm]セクションに次のエントリを追加します:注:
ADインフラストラクチャに基づいてKerberosを構成します。次の設定は、単一ドメイン、単一フォレストモデルを対象としています。
[libdefaults] dns_canonicalize_hostname = false rdns = false default_realm = REALM forwardable = true [realms] REALM = { kdc = fqdn-of-domain-controller default_domain = realm admin_server = fqdn-of-domain-controller } [domain_realm] .realm = REALM <!--NeedCopy-->
realmは、Kerberos領域名(example.comなど)です。REALMは、大文字のKerberos領域名(EXAMPLE.COMなど)です。
-
/etc/samba/smb.conf
をルートユーザーとして編集し、netユーティリティがターゲットドメインと通信できるようにします。[global]セクションで次のとおりにエントリを追加します:[global] workgroup = domain client signing = yes client use spnego = yes kerberos method = secrets and keytab realm = REALM security = ADS <!--NeedCopy-->
domainは、EXAMPLEなどのActive Directoryドメインの短いNetBIOS名です。
-
/etc/nsswitch.confファイルでpasswdおよびgroupエントリを変更して、ユーザーとグループの解決時にSSSDを参照します。
passwd: compat sss group: compat sss <!--NeedCopy-->
-
構成済みのKerberosクライアントを使用して、管理者としてターゲットドメインに対して認証します。
kinit administrator <!--NeedCopy-->
-
netユーティリティを使用して、システムをドメインに参加させ、システムのkeytabファイルを生成します。
net ads join osname="SUSE Linux Enterprise Server" osVersion=15 -U administrator <!--NeedCopy-->
SSSD用のPAMの構成
SSSD用のPAMを構成する前に、必要なパッケージをインストールまたは更新します:
sudo zypper install sssd sssd-ad
<!--NeedCopy-->
SSSD経由のユーザー認証用にPAMモジュールを構成し、ユーザーログオン用のホームディレクトリを作成します。
sudo pam-config --add --sss
sudo pam-config --add --mkhomedir
<!--NeedCopy-->
SSSDのセットアップ
-
/etc/sssd/sssd.conf
をルートユーザーとして編集し、SSSDデーモンがターゲットドメインと通信できるようにします。sssd.conf
の設定の例(必要に応じて追加の設定を行うことができます):[sssd] config_file_version = 2 services = nss,pam domains = domain-dns-name [domain/domain-dns-name] id_provider = ad auth_provider = ad access_provider = ad ad_domain = domain-dns-name ad_server = fqdn-of-domain-controller ldap_id_mapping = true ldap_schema = ad # Kerberos settings krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U # Comment out if the users have the shell and home dir set on the AD side fallback_homedir = /home/%d/%u default_shell = /bin/bash # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM ad_gpo_access_control = permissive <!--NeedCopy-->
domain-dns-nameは、example.comなどのDNSドメイン名です。
注:
ldap_id_mappingはtrueに設定されるため、SSSD自体がWindows SIDをUnix UIDにマッピングします。それ以外の場合、Active DirectoryはPOSIX拡張を提供できる必要があります。Linuxセッションでの無効なログオンのエラーを防ぐために、ad_gpo_access_controlはpermissiveに設定されます。
sssd.conf
およびsssd-ad
のmanページを参照してください。 -
ファイルの所有権およびアクセス権限を
sssd.conf
で設定します。sudo chmod 0600 /etc/sssd/sssd.conf <!--NeedCopy-->
SSSDの有効化
次のコマンドを実行して、SSSDデーモンを有効にし、システムの起動時に起動できるようにします。
sudo systemctl enable sssd
sudo systemctl start sssd
<!--NeedCopy-->
ドメインメンバーシップの確認
-
次のように、Sambaの
net ads
コマンドを実行して、マシンがドメインに参加していることを確認します:sudo net ads testjoin <!--NeedCopy-->
-
追加のドメインおよびコンピューターオブジェクト情報を検証するには、次のコマンドを実行します:
sudo net ads info <!--NeedCopy-->
Kerberos構成の確認
システムのkeytabファイルが作成され、このファイルに有効なキーが含まれていることを確認します:
sudo klist -ke
<!--NeedCopy-->
このコマンドにより、プリンシパル名と暗号スイートのさまざまな組み合わせに対して使用できるキーの一覧が表示されます。
Kerberosのkinitコマンドを実行し、これらのキーを使用して、マシンをドメインコントローラーに対して認証します:
sudo kinit –k MACHINE$@REALM
<!--NeedCopy-->
マシン名と領域名は大文字で指定する必要があります。ドル記号($)は、シェルによる置き換えを防ぐためにバックスラッシュ(**\**)でエスケープする必要があります。環境によっては、DNSドメイン名がKerberos領域名と異なります。したがって、必ず領域名を使用します。このコマンドが成功すると、出力は表示されません。
次のコマンドを使用して、マシンアカウントのTGTチケットがキャッシュされたことを確認します:
sudo klist
<!--NeedCopy-->
ユーザー認証の確認
SSSDは、デーモンで直接認証をテストするコマンドラインツールを提供しません。PAM経由でのみ完了できます。
SSSD PAMモジュールが正しく構成されていることを確認するには、以前に使用したことがないドメインユーザーアカウントを使用してLinux VDAにログオンします。
ssh localhost -l domain\username
id -u
klist
exit
<!--NeedCopy-->
ユーザーのklist
コマンドで返されるKerberosチケットが正しく、期限切れではないことを確認します。
ルートユーザーとして、前述のid -u
コマンドで返されたUIDに対応するチケットキャッシュファイルが作成されたことを確認します:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
GnomeコンソールまたはKDEコンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順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の情報を返します。参加していない場合は、ホスト名だけが表示されます。
ユーザー認証の確認
PBISがPAMを介してドメインユーザーを認証できることを確認します。これを行うには、以前に使用したことがないドメインユーザーアカウントを使用してLinux VDAにログオンします。
ssh localhost -l domain\user
id -u
<!--NeedCopy-->
次のコマンドで、id -uコマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
次のコマンドで、セッションを終了します。
exit
<!--NeedCopy-->
ドメイン参加の確認後、「手順6:Linux VDAのインストール」に進みます。
手順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 VDAを見つけます。例:
-
Linux VDAのリンクをクリックして、Linux VDAのダウンロードファイルにアクセスします。
-
使用中のLinuxディストリビューションに対応したLinux VDAパッケージをダウンロードします。
-
Linux VDAパッケージの整合性を検証するために使用できるGPG公開キーをダウンロードします。例:
公開キーを使用してLinux VDAパッケージの整合性を確認するには、次のコマンドを実行して公開キーをRPMデータベースにインポートし、パッケージの整合性を確認します:
rpmkeys --import <path to the public key> rpm --checksig --verbose <path to the Linux VDA package> <!--NeedCopy-->
手順6:Linux VDAのインストール
手順6a:古いバージョンのアンインストール
最新の2バージョンおよびLTSRリリース以外の古いバージョンのLinux VDAがインストールされている場合は、それをアンインストールしてから新しいバージョンをインストールする必要があります。
-
次のコマンドで、Linux VDAサービスを停止します:
sudo /sbin/service ctxvda stop sudo /sbin/service ctxhdx stop <!--NeedCopy-->
注:
ctxvdaおよびctxhdxサービスを停止する前に、systemctl stop ctxmonitordコマンドを実行して監視サービスデーモンを停止します。これを実行しない場合、監視サービスデーモンは停止したサービスを再起動します。
-
次のコマンドで、パッケージをアンインストールします:
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
重要:
最新の2バージョンからのアップグレードがサポートされます。
注:
インストールされているコンポーネントは、/opt/Citrix/VDA/ で確認できます。
コマンドを実行するには、フルパスが必要です。代わりに、システムパスに/opt/Citrix/VDA/sbinおよび/opt/Citrix/VDA/binを追加することもできます。
手順6b:Linux VDAのインストール
Zypperを使用してLinux VDAソフトウェアをインストールします:
sudo zypper install XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
RPM Package Managerを使用して、Linux VDAソフトウェアをインストールします:
sudo rpm -i XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
手順6c:Linux VDAのアップグレード(オプション)
最新の2バージョンとLTSRリリースから既存のインストールをアップグレードできます。
注:
既存のインストールをアップグレードすると、/etc/xdlにある構成ファイルが上書きされます。アップグレードを実行する前に、必ずファイルをバックアップしてください。
sudo rpm -U XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
RPM依存関係一覧(SUSE 15の場合):
java-11-openjdk >= 11
ImageMagick >= 7.0
dbus-1 >= 1.12.2
dbus-1-x11 >= 1.12.2
xorg-x11 >= 7.6_1
libXpm4 >= 3.5.12
libXrandr2 >= 1.5.1
libXtst6 >= 1.2.3
pam >= 1.3.0
bash >= 4.4
findutils >= 4.6
gawk >= 4.2
sed >= 4.4
cups >= 2.2
cups-filters >= 1.25
libxml2-2 >= 2.9
libmspack0 >= 0.6
ibus >= 1.5
libtcmalloc4 >= 2.5
libcap-progs >= 2.26
mozilla-nss-tools >= 3.53.1
libpython3_6m1_0 >= 3.6~
libQt5Widgets5 >= 5.12
libqrencode4 >= 4.0.0
libImlib2-1 >= 1.4.10
<!--NeedCopy-->
重要:
アップグレードした後、Linux VDAマシンを再起動してください。
手順7:NVIDIA GRIDドライバーのインストール
HDX 3D Proを有効にするには、ハイパーバイザーとVDAマシンにNVIDIA GRIDドライバーをインストールする必要があります。
特定のハイパーバイザーにNVIDIA GRID Virtual GPU Manager(ホストドライバー)をインストールして構成するには、次のガイドを参照してください:
NVIDIA GRIDゲストVMドライバーをインストールして構成するには、次の一般的な手順を実行します:
- ゲストVMがシャットダウンされていることを確認します。
- ハイパーバイザーのコントロールパネルで、GPUをVMに割り当てます。
- 仮想マシンを起動します。
- ゲストVMドライバーをVMにインストールします。
手順8:Linux VDAの構成
注:
ランタイム環境をセットアップする前に、en_US.UTF-8ロケールがインストールされていることを確認します。OSにこのロケールがない場合は、sudo locale-gen en_US.UTF-8コマンドを実行します。Debianの場合は、# en_US.UTF-8 UTF-8行のコメントを解除して/etc/locale.genファイルを編集してから、sudo locale-genコマンドを実行します。
パッケージのインストール後、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 VDA用に、システムのファイアウォールの必要なポート(デフォルトではポート80およびポート1494)を自動で開放できます。デフォルトではYに設定されています。
- CTX_XDL_AD_INTEGRATION=winbind | quest |centrify | sssd – Linux VDAには、Delivery Controllerに対して認証するためにKerberos構成設定が必要です。Kerberos構成は、システムにインストールおよび構成済みのActive Directory統合ツールから指定します。
- CTX_XDL_HDX_3D_PRO=Y | N - Linux VDAでは、HDX 3D Proがサポートされます。これは、強力なグラフィックアプリケーションの仮想化を最適にするための一連のGPUアクセラレーションテクノロジです。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, or ad1.mycompany.com:636 ad2.mycompany.com:3269 ad3.mycompany.com:3269(LDAPSを使用している場合)。Active Directoryフォレストでより高速なLDAPクエリを有効にするには、ドメインコントローラーで [グローバルカタログ] を有効にし、LDAPSを使用している場合、関連するLDAPポート番号で3268または3269 を指定します。この変数は、デフォルトでは <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に設定する必要があります。
次の手順を実行して、ターゲットセッションユーザーのデスクトップ環境を変更することもできます:
- VDAの$HOME/<ユーザー名\>ディレクトリに
.xsession
ファイルを作成します。 -
.xsession
ファイルを編集して、デスクトップ環境を指定します。-
SUSE 15上のMATEデスクトップの場合
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi
-
SUSE 15上のGNOMEクラシックデスクトップの場合
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi
-
SUSE 15上のGNOMEデスクトップの場合
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi
-
- ターゲットセッションユーザーと700ファイルのアクセス権限を共有します。
バージョン2209以降、セッションユーザーはデスクトップ環境をカスタマイズできます。この機能を有効にするには、事前にVDAに切り替え可能なデスクトップ環境をインストールする必要があります。詳しくは、「セッションユーザーによるカスタムデスクトップ環境」を参照してください。
- VDAの$HOME/<ユーザー名\>ディレクトリに
- 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=winbind | quest |centrify | sssd
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 --silent
<!--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=winbind | quest |centrify | sssd \
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 --silent
<!--NeedCopy-->
構成変更の削除
シナリオによっては、Linux VDAパッケージをアンインストールしないで、ctxsetup.sh スクリプトによって行われた構成変更を削除することが必要となる場合があります。
続行する前に、次のコマンドを使用してこのスクリプトのヘルプを確認します:
sudo /usr/local/sbin/ctxcleanup.sh --help
<!--NeedCopy-->
構成変更を削除するには:
sudo /usr/local/sbin/ctxcleanup.sh
<!--NeedCopy-->
重要:
このスクリプトにより、すべての構成データがデータベースから削除され、Linux VDAを操作できなくなります。
構成ログ
ctxsetup.sh および ctxcleanup.sh スクリプトでは、コンソールにエラーが表示され、次の構成ログファイルに追加情報が書き込まれます:
/tmp/xdl.configure.log
Linux VDAサービスを再起動し、変更を反映させます。
手順9:XDPingの実行
sudo /opt/Citrix/VDA/bin/xdping
を実行して、Linux VDA環境での一般的な構成の問題を確認します。詳しくは、「XDPing」を参照してください。
手順10:Linux VDAの実行
ctxsetup.sh スクリプトを使用してLinux VDAを構成したら、次のコマンドを使用してLinux VDAを制御します。
Linux VDAの起動:
Linux VDAサービスを起動するには、次のコマンドを実行します:
sudo /sbin/service ctxhdx start
sudo /sbin/service ctxvda start
<!--NeedCopy-->
Linux VDAの停止:
Linux VDAサービスを停止するには、次のコマンドを実行します:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx stop
<!--NeedCopy-->
注:
ctxvda
およびctxhdx
サービスを停止する前に、service ctxmonitorservice stop
コマンドを実行して監視サービスデーモンを停止します。これを実行しない場合、監視サービスデーモンは停止したサービスを再起動します。
Linux VDAの再起動:
Linux VDAサービスを再起動するには、次のコマンドを実行します:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx restart
sudo /sbin/service ctxvda start
<!--NeedCopy-->
Linux VDAの状態の確認:
Linux VDAサービスの実行状態を確認するには、次のコマンドを実行します:
sudo /sbin/service ctxvda status
sudo /sbin/service ctxhdx status
<!--NeedCopy-->
手順11:マシンカタログの作成
マシンカタログを作成し、Linux VDAマシンを追加する手順は、従来のWindows VDAでの方法と似ています。このタスクを完了する方法の説明について詳しくは、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
次のように、Linux VDAマシンを含むマシンカタログの作成にはいくつかの制約があるため、Windows VDAマシンのマシンカタログの作成手順と異なる点があります:
- オペレーティングシステムには、次を選択します:
- ホストされる共有デスクトップ配信モデルの場合、マルチセッションOSオプション
- VDI専用デスクトップ配信モデルの場合、シングルセッションOSオプション。
- 同じマシンカタログで、Linux VDAマシンとWindows VDAマシンを混在させないでください。
注:
Citrix Studioの以前のバージョンは、「Linux OS」という概念をサポートしていませんでした。ただし、[WindowsサーバーOS] オプションまたは [サーバーOS] オプションを選択すると、同等のホストされる共有デスクトップ配信モデルが暗黙的に選択されます。[WindowsデスクトップOS] オプションまたは [デスクトップOS] オプションを選択すると、マシンごとに単一ユーザーの配信モデルが暗黙的に選択されます。
ヒント:
マシンがActive Directoryドメインから削除された後に再度追加された場合は、そのマシンをマシンカタログから削除してから再度追加する必要があります。
手順12:デリバリーグループの作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加する手順は、Windows VDAマシンの場合とほとんど同じです。このタスクを完了する方法の説明について詳しくは、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合は、次の制約があります:
- 選択するADユーザーおよびグループを、Linux VDAマシンにログオンするように適切に構成しておきます。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- Windowsマシンを含むマシンカタログをデリバリーグループで混在させないでください。
重要:
アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、同一マシンへのデスクトップおよびアプリの配信は、Linux VDAでサポートされていません。
マシンカタログおよびデリバリーグループの作成方法について詳しくは、「Citrix Virtual Apps and Desktops 7 2308」を参照してください。