Linux Virtual Delivery Agent for SUSEの手動インストール
重要:
新規インストールの場合は、簡単インストールを使用して簡易インストールを行うことをお勧めします。簡単インストールは時間と労力を節約するだけでなく、本記事に記載されている手動インストールよりもエラーを減らすことができます。
手順1:インストールの準備
手順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の構成
- YaSTの[ネットワーク設定]を開きます。
- SLED 12のみ: [グローバルオプション] タブで、[ネットワークのセットアップ方法] を [Wickedサービス] に変更します。
- [ホスト名/DNS] タブを開きます。
- [DHCPでホスト名を変更する] チェックボックスをオフにします。
- [ホスト名をループバックIPに割り当てる] チェックボックスをオンにします。
- 以下を編集してネットワーク設定に反映させます。
- ホスト名 – マシンのDNSホスト名を追加します。
- ドメイン名 – マシンのDNSドメイン名を追加します。
- ネームサーバー – DNSサーバーのIPアドレスを追加します。通常はADドメインコントローラーのIPアドレスです。
- [ドメイン検索]一覧 – DNSドメイン名を追加します。
注:
Linux VDAは現在、NetBIOS名の切り捨てをサポートしていません。したがって、ホスト名は15文字以内である必要があります。 ヒント:
a~z、A~Z、0~9、およびハイフン(-)の文字のみ使用してください。アンダースコア(_)、スペース、およびその他の記号は使用しないでください。ホスト名を数字で開始したり、ハイフンで終了したりしないでください。このルールは、Delivery Controllerのホスト名にも適用されます。
マルチキャストDNSの無効化
SLEDでのみ、デフォルトの設定でマルチキャストDNS(mDNS)が有効であるため、名前解決の結果に不整合が発生する場合があります。SLESの場合、mDNSはデフォルトでは有効化されていないため、特に操作を行う必要はありません。
mDNSを無効にするには、/etc/nsswitch.confを編集して、以下を含む行を変更します:
hosts: files mdns_minimal [NOTFOUND=return] dns
変更後:
hosts: files dns
ホスト名の確認
次のコマンドで、ホスト名が正しく設定されていることを確認します:
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、ドメインコントローラーの間で正確な時刻同期を維持することが重要です。仮想マシンとしてLinux VDAをホストすると、時刻が不正確になる問題が発生する可能性があります。したがって、リモートNTPサービスを使用して時刻を維持することをお勧めします。次のように、デフォルトNTP設定にいくつかの変更が必要な場合があります。
- YaSTの[NTP環境設定]を開いて、[一般的な設定] タブをクリックします。
- [NTPデーモンを起動する]セクションで、[今すぐ開始し、システム起動時に開始するよう設定] をクリックします。
- 表示されている場合は、[規律に従わないローカル時計(LOCAL)] 項目を選択し、[削除] をクリックします。
- [追加] をクリックして、NTPサーバーのエントリを追加します。
- [サーバーの種類] を選択して、[次へ] をクリックします。
- [アドレス]フィールドに、NTPサーバーのDNS名を入力します。このサービスは、通常Active Directoryドメインコントローラーでホストされます。
- [オプション]フィールドは変更しません。
- [テスト] をクリックして、NTPサービスに到達できるかどうかを確認します。
- 一連のウィンドウで [OK] をクリックして、変更を保存します。
注:
SLES 12の実装では、AppArmorポリシーに関するSUSEの既知の問題が原因で、NTPデーモンが起動に失敗することがあります。詳しくは、解決方法に従ってください。
手順1d:Linux VDAに依存するパッケージのインストール
SUSE Linux Enterprise用のLinux VDAソフトウェアは、次のパッケージに依存しています。
- Postgresql10-server 10.12以降
- OpenJDK 11
- OpenMotif Runtime Environment 2.3.1以降
- Cups 1.6.0以降
- Foomatic filters 3.0.0以降
- ImageMagick 6.8以降
リポジトリの追加
PostgreSQLやImageMagickなどの必要なパッケージは、SUSE Linux Enterprise Software Development Kit(SDK)から入手できます。パッケージを取得するには、YaSTを使用してSDKリポジトリを追加するか、SDKイメージファイルをダウンロードして、次のコマンドを使用してローカルにマウントします:
sudo mkdir -p /mnt/sdk
sudo mount -t iso9660 path-to-iso/SLE-12-SP5-SDK-DVD-x86_64-GM-DVD1.iso /mnt/sdk
sudo zypper ar -f /mnt/sdk sdk
<!--NeedCopy-->
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-->
PostgreSQLのインストール
SLED/SLES 12で、次のようにしてパッケージをインストールします:
sudo zypper install postgresql-init
sudo zypper install postgresql10-server
sudo zypper install postgresql-jdbc
<!--NeedCopy-->
データベースサービスを初期化し、マシンの起動時にPostgreSQLが確実に開始されるようにするには、次に示すインストール後の手順が必要です。
sudo systemctl enable postgresql
sudo systemctl restart postgresql
<!--NeedCopy-->
データベースファイルは/var/lib/pgsql/dataにあります。
リポジトリの削除
依存関係パッケージがインストールされている状態で、次のコマンドを実行して、以前にセットアップされたSDKリポジトリとマウントされたメディアを削除します:
sudo zypper rr sdk
sudo umount /mnt/sdk
sudo rmdir /mnt/sdk
<!--NeedCopy-->
手順2:ハイパーバイザー用Linux仮想マシンの準備
サポートされるハイパーバイザー上で仮想マシンとしてLinux VDAを実行する場合、いくつかの変更が必要です。使用するハイパーバイザーのプラットフォームに合わせて、次の変更を行います。ベアメタルハードウェアでLinuxマシンを実行する場合、変更は必要ありません。
Citrix Hypervisorでの時刻同期の修正
Citrix Hypervisorの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとCitrix Hypervisorの両方がシステムの時間を管理しようとすることが原因となり問題が発生します。システムの時刻と他のサーバーの時刻との同期が失われるのを防ぐには、各Linuxゲストのシステムの時刻がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは、変更は必要ありません。
一部のLinuxディストリビューションでは、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とハイパーバイザーの両方がシステムの時間を同期しようとすることが原因で問題が発生します。システムの時刻と他のサーバーの時刻との同期が失われるのを防ぐには、各Linuxゲストのシステムの時刻をNTPと同期させます。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsをインストールした状態で準仮想化Linuxカーネルを実行している場合は、次の操作を行います。
- vSphere Clientを開きます。
- Linux仮想マシンの設定を編集します。
- [仮想マシンのプロパティ] ダイアログボックスで、[オプション] タブをクリックします。
- [VMware Tools] を選択します。
- [詳細] ボックスで、[ホストとゲスト時刻を同期] チェックボックスをオフにします。
手順3:Linux仮想マシン(VM)をWindowsドメインに追加
Linux VDAは、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] をクリックします。いくつかのパッケージのインストールを促すメッセージが表示された場合は、[インストール] をクリックします。
-
ドメインコントローラーが見つかると、ドメインに参加するかどうかを確認するメッセージが表示されます。[Yes] をクリックします。
-
メッセージが表示されたら、コンピューターをドメインに追加する権限を持つドメインユーザーの資格情報を入力し、[OK] をクリックします。
-
成功を示すメッセージが表示されます。
-
いくつかのSambaおよびkrb5パッケージのインストールを促すメッセージが表示されたら、[インストール] をクリックします。
YaSTにより、これらの変更には一部のサービスまたはマシンの再起動が必要であることが示される場合があります。マシンを再起動することをお勧めします:
su -
reboot
<!--NeedCopy-->
SUSE 12のみ:Kerberos資格情報キャッシュ名のパッチ適用
SUSE 12は、デフォルトのKerberos資格情報キャッシュ名指定が通常のFILE:/tmp/krb5cc_%{uid}からDIR:/run/user/%{uid}/krb5ccに変更されました。Linux VDAはこの新しいDIRによるキャッシュ方法に対応していないため、手動で変更する必要があります。次の設定がない場合は、ルートユーザーとして /etc/krb5.conf を編集して、[libdefaults] セクションに追加します:
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-->
次のコマンドで、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ドメインコントローラーにインストールし、構成していることと、管理者特権が付与され、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
ユーザー認証の確認
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
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-->
-
次のようにして、必要なパッケージをインストールまたは更新します:
sudo zypper install krb5-client sudo zypper install samba-client <!--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 realm = REALM <!--NeedCopy-->
realmは、Kerberos領域名(example.comなど)です。REALMは、EXAMPLE.COMなどの大文字のKerberos領域名です。fqdn-of-domain-controllerは、ドメインコントローラーのFQDNです。
-
/etc/samba/smb.confをルートユーザーとして編集し、netユーティリティがターゲットドメインと通信できるようにします。[global]セクションで次のとおりにエントリを追加します:
[global] workgroup = domain realm = REALM security = ADS kerberos method = secrets and keytab client signing = yes client use spnego = yes <!--NeedCopy-->
domainは、EXAMPLEなどのActive Directoryドメインの短いNetBIOS名です。
-
/etc/nsswitch.confファイルでpasswdおよびgroupエントリを変更して、ユーザーとグループの解決時にSSSDを参照します。
passwd: compat sss group: compat sss <!--NeedCopy-->
-
Windowsドメインに参加します。ドメインコントローラーに到達できることと、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントがあることを確認します:
sudo realm join REALM -U user <!--NeedCopy-->
userは、コンピューターをドメインに追加する権限を持つドメインユーザーです。
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のマニュアルページを参照してください。
-
ファイルの所有権およびアクセス権限を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構成の確認
Linux VDAで使用できるようにKerberosが正しく構成されていることを確認するには、次のコマンドによって、システムのkeytabファイルが作成済みで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/8.8.0/pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->
PBISインストールスクリプトを実行可能にする
例:
chmod +x pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->
PBISインストールスクリプトを実行する
例:
sh pbis-open-8.8.0.506.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 Coreランタイム3.1をインストール
Linux VDAのインストール前に、https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managersの手順に従って.NET Coreランタイム3.1をインストールします。
.NET Coreランタイム3.1のインストール後、which dotnetコマンドを実行してランタイムパスを特定します。
コマンド出力に基づいて、.NET Coreランタイムのバイナリパスを設定します。たとえば、コマンド出力が/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のインストール
手順6a:古いバージョンのアンインストール
最新の2バージョンおよびLTSRリリース以外の古いバージョンのLinux VDAがインストールされている場合は、それをアンインストールしてから新しいバージョンをインストールする必要があります。
-
次のコマンドで、Linux VDAサービスを停止します:
sudo /sbin/service ctxvda stop sudo /sbin/service ctxhdx stop <!--NeedCopy-->
注:
ctxvda
およびctxhdx
サービスを停止する前に、service ctxmonitorservice stop
コマンドを実行して監視サービスデーモンを停止します。これを実行しない場合、監視サービスデーモンは停止したサービスを再起動します。 -
次のコマンドで、パッケージをアンインストールします:
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
重要:
最新の2バージョンからのアップグレードがサポートされます。
注:
インストールコンポーネントは/opt/Citrix/VDA/にあります。
コマンドを実行するには、フルパスが必要です。代わりに、システムパスに/opt/Citrix/VDA/sbinおよび/opt/Citrix/VDA/binを追加することもできます。
手順6b:Linux VDAのインストール
Zypperを使用してLinux VDAソフトウェアをインストールします:
SUSE 12の場合:
sudo zypper install XenDesktopVDA-<version>.sle12_x.x86_64.rpm
<!--NeedCopy-->
RPM Package Managerを使用して、Linux VDAソフトウェアをインストールします。その前に、次の依存関係を解決します。
SUSE 12の場合:
sudo rpm -i XenDesktopVDA-<version>.sle12_x.x86_64.rpm
<!--NeedCopy-->
手順6c:Linux VDAのアップグレード(オプション)
最新の2バージョンとLTSRリリースから既存のインストールをアップグレードできます。
注:
既存のインストールをアップグレードすると、/etc/xdlにある構成ファイルが上書きされます。アップグレードを実行する前に、必ずファイルをバックアップしてください。
SUSE 12の場合:
sudo rpm -U XenDesktopVDA-<version>.sle12_x.x86_64.rpm
<!--NeedCopy-->
RPM依存関係一覧(SUSE 12の場合):
mozilla-nss-tools >= 3.47.1
postgresql-server >= 10.12
postgresql-jdbc >= 9.2
java-11-openjdk >= 11
ImageMagick >= 6.8
dbus-1 >= 1.8.8
dbus-1-x11 >= 1.8.8
libXpm4 >= 3.5.11
libXrandr2 >= 1.4.2
libXtst6 >= 1.2.2
motif >= 2.3
pam >= 1.1.8
bash >= 4.2
findutils >= 4.5
gawk >= 4.1
sed >= 4.2
cups >= 1.6.0
cups-filters-foomatic-rip >= 1.0.0
openldap2 >= 2.4
cyrus-sasl >= 2.1
cyrus-sasl-gssapi >= 2.1
libxml2 >= 2.9
libmspack0 >= 0.4
python-requests >= 2.8.1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsLzma) <= 4.4.6-1
libtcmalloc4 >= 2.5
libcap-progs >= 2.22
xorg-x11-server >= 7.6_1.18.3-76.15
ibus >= 1.5
xorg- x11-server = 7.6_1.19.6
xorg-x11 = 7.6_1
postgresql10-server >= 10.12
libgtk-2_0-0 >= 2.24
libgthread-2_0-0 >= 2.48
pulseaudio-utils >= 5.0
lsb-release >= 2.0
<!--NeedCopy-->
重要:
アップグレードした後、Linux VDAマシンを再起動してください。
手順7: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を選択した場合、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となります。この変数は、デフォルトでは <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> という文字列で埋めて、サーバーアドレスの順番は変更しません。
-
CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime - 新しいブローカーエージェントサービス(
ctxvda
)をサポートするための.NET Coreランタイム3.1をインストールするパス。デフォルトのパスは/usr/binです。 -
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/mate –セッションで使用するGNOMEまたはMATEデスクトップ環境を指定します。変数を指定しないままにすると、現在VDAにインストールされているデスクトップが使用されます。ただし、現在インストールされているデスクトップがMATEの場合は、変数値をmateに設定する必要があります。
注:
次の手順を実行して、ターゲットセッションユーザーのデスクトップ環境を変更することもできます:
- VDAの $HOME/<username> ディレクトリに
.xsession
ファイルを作成します。ここで、usernameはユーザー名です。-
.xsession
ファイルを編集して、ディストリビューションに基づいてデスクトップ環境を指定します。
-
CentOS、Ubuntu、Debian上のMATEデスクトップの場合:
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi <!--NeedCopy-->
CentOS上のGNOMEデスクトップの場合:
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi <!--NeedCopy-->
UbuntuおよびDebian上のGNOMEデスクトップの場合:
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi <!--NeedCopy-->
- 700ファイルパーミッションをターゲットセッションユーザーと共有します。
- VDAの $HOME/<username> ディレクトリに
- CTX_XDL_START_SERVICE = Y | N - Linux VDA構成の完了時にLinux VDAサービスが開始されるようにするかどうかを指定します。デフォルトではYに設定されています。
- CTX_XDL_TELEMETRY_SOCKET_PORT – Citrix Scoutをリッスンするためのソケットポート。デフォルトのポートは7503です。
- CTX_XDL_TELEMETRY_PORT – Citrix Scoutと通信するためのポート。デフォルトのポートは7502です。
次のようにして、環境変数を設定し、構成スクリプトを実行します:
export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N
export CTX_XDL_DDC_LIST=‘list-ddc-fqdns’
export CTX_XDL_VDA_PORT=port-number
export CTX_XDL_REGISTER_SERVICE=Y|N
export CTX_XDL_ADD_FIREWALL_RULES=Y|N
export CTX_XDL_AD_INTEGRATION=1|2|3|4
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 | 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 \
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 | 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 /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サービスを再起動し、変更を反映させます。
手順 8:XDPingの実行
sudo /opt/Citrix/VDA/bin/xdping
を実行して、Linux VDA環境での一般的な構成の問題を確認します。詳しくは、「XDPing」を参照してください。
手順9: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-->
手順10: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ドメインから削除された後に再度追加された場合は、そのマシンをマシンカタログから削除してから再度追加する必要があります。
手順11: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 2106」を参照してください。
この記事の概要
- 手順1:インストールの準備
- 手順2:ハイパーバイザー用Linux仮想マシンの準備
- 手順3:Linux仮想マシン(VM)をWindowsドメインに追加
- 手順4:前提条件として.NET Coreランタイム3.1をインストール
- 手順5:Linux VDAパッケージのダウンロード
- 手順6:Linux VDAのインストール
- 手順7:Linux VDAの構成
- 手順 8:XDPingの実行
- 手順9:Linux VDAの実行
- 手順10:Citrix Virtual AppsまたはCitrix Virtual Desktopsでのマシンカタログの作成
- 手順11:Citrix Virtual AppsまたはCitrix Virtual Desktopsでのデリバリーグループの作成