Linux Virtual Delivery Agent 2104

RHEL/CentOS 用 Linux Virtual Delivery Agent のインストール

手動インストールについては本記事の手順に従うか、自動インストールおよび構成には 簡易インストール を使用できます。簡易インストールは時間と労力を節約し、手動インストールよりもエラーが発生しにくいです。

注:

簡易インストール は新規インストールにのみ使用してください。既存のインストールを更新するために簡易インストールを使用しないでください。

ステップ 1: VDAインストール用のRHEL 8/CentOS 8、RHEL 7/CentOS 7の準備

ステップ 1a: ネットワーク構成の確認

続行する前に、ネットワークが正しく接続され、構成されていることをお勧めします。

ステップ 1b: ホスト名の設定

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

hostname

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

マシンの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 への他の参照をすべて削除します。

注:

Linux VDAは現在、NetBIOS名の切り捨てをサポートしていません。したがって、ホスト名は15文字を超えてはなりません。

ヒント:

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 8/RHEL 7のデフォルト環境では、クロック同期にChronyデーモン (chronyd) を使用します。

Chronyサービスの構成

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 のエントリを含む、リストされている他のすべてのサーバーエントリを削除します。

変更を保存し、Chronyデーモンを再起動します。

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

ステップ 1g: OpenJDK 11のインストール

Linux VDAにはOpenJDK 11が必要です。Linux VDAをインストールすると、ランタイム環境は依存関係として自動的にインストールされます。

正しいバージョンを確認します。

sudo yum info java-11-openjdk
<!--NeedCopy-->

プリパッケージされたOpenJDKは以前のバージョンである可能性があります。OpenJDK 11に更新します。

sudo yum -y update java-11-openjdk
<!--NeedCopy-->

新しいシェルを開き、Javaのバージョンを確認します。

java -version
<!--NeedCopy-->

ヒント:

Delivery Controllerへの登録失敗を避けるため、OpenJDK 11のみがインストールされていることを確認してください。システムから他のすべてのJavaバージョンを削除してください。

ステップ 1h: PostgreSQLのインストール

Linux VDAには、RHEL 8ではPostgreSQL 10.5以降、またはRHEL 7ではPostgreSQL 9.2以降が必要です。

次のパッケージをインストールします。

sudo yum -y install postgresql-server

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

データベースを初期化し、マシン起動時にサービスが開始されるようにするために、次のインストール後手順が必要です。この操作により、/var/lib/pgsql/data の下にデータベースファイルが作成されます。コマンドはPostgreSQL 10と9で異なります。

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

ステップ 1i: PostgreSQLの起動

  • マシン起動時にサービスを開始し、すぐにサービスを開始します。
-  sudo systemctl enable postgresql

sudo systemctl start postgresql
<!--NeedCopy-->

PostgreSQLのバージョンを確認するには、以下を使用します。

psql --version
<!--NeedCopy-->

(RHEL 7のみ) psql コマンドラインユーティリティを使用して、データディレクトリが設定されていることを確認します。

sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->

ステップ2: ハイパーバイザーの準備

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

Citrix Hypervisor™での時刻同期の修正

Citrix Hypervisorの時刻同期機能が有効になっている場合、各準仮想化Linux VM内でNTPとCitrix Hypervisorの両方がシステムクロックを管理しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各Linuxゲスト内のシステムクロックがNTPと同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは変更は不要です。

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

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

このコマンドは0または1を返します。

  • 0 - 時刻同期機能が有効であり、無効にする必要があります。
  • 1 - 時刻同期機能が無効であり、それ以上の操作は不要です。

/proc/sys/xen/independent_wallclock ファイルが存在しない場合、以下の手順は不要です。

有効になっている場合、ファイルに1を書き込むことで時刻同期機能を無効にします。

sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

この変更を再起動後も永続的にするには、/etc/sysctl.conf ファイルを編集し、以下の行を追加します。

xen.independent_wallclock = 1

これらの変更を確認するには、システムを再起動します。

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

このコマンドは値1を返します。

Microsoft Hyper-Vでの時刻同期の修正

Hyper-V Linux Integration ServicesがインストールされたLinux VMは、Hyper-Vの時刻同期機能を使用してホストオペレーティングシステムの時刻を利用できます。システムクロックの正確性を確保するためには、この機能をNTPサービスと並行して有効にする必要があります。

管理オペレーティングシステムから:

  1. Hyper-Vマネージャーコンソールを開く
  2. Linux VMの設定で、統合サービスを選択する
  3. 時刻同期が選択されていることを確認する

注:

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

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

VMwareの時刻同期機能が有効になっている場合、各準仮想化Linux VM内でNTPとハイパーバイザーの両方がシステムクロックを同期しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各Linuxゲスト内のシステムクロックがNTPと同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。

VMware Toolsがインストールされた準仮想化Linuxカーネルを実行している場合:

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

ステップ3: Linux仮想マシン (VM) をWindowsドメインに追加

Linux VDAは、LinuxマシンをActive Directory (AD) ドメインに追加するためのいくつかの方法をサポートしています。

選択した方法に基づいて指示に従ってください。

注:

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

Samba Winbind

必要なパッケージをインストールまたは更新します。

RHEL 8/CentOS 8の場合:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->

RHEL 7/CentOS 7の場合:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir
<!--NeedCopy-->

マシン起動時にWinbindデーモンを有効にする

Winbindデーモンは、マシン起動時に開始するように構成する必要があります。

sudo /sbin/chkconfig winbind on
<!--NeedCopy-->

Winbind認証の構成

Winbindを使用して、Kerberos認証用にマシンを構成します。

  1. 次のコマンドを実行する

    RHEL 8の場合:

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

    RHEL 7の場合:

    sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall
    <!--NeedCopy-->
    

    ここで、REALM は大文字のKerberosレルム名であり、domain はドメインのNetBIOS名です。

    KDCサーバーとレルム名のDNSベースのルックアップが必要な場合は、前のコマンドに次の2つのオプションを追加します。

    --enablekrb5kdcdns --enablekrb5realmdns

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

  2. /etc/samba/smb.conf を開き、[Global] セクションの下に、ただし authconfig ツールによって生成されたセクションの後に、次のエントリを追加します。

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

  3. (RHEL 8のみ) /etc/krb5.conf を開き、[libdefaults]、[realms]、および [domain_realm] セクションにエントリを追加します。

    [libdefaults] セクションの下:

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

    [realms] セクションの下:

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

    [domain_realm] セクションの下:

    realm = REALM .realm = REALM

Linux VDAは、Delivery Controllerとの認証および登録のためにシステムキータブファイル /etc/krb5.keytab を必要とします。以前のKerberosメソッド設定により、マシンが最初にドメインに参加したときにWinbindがシステムキータブファイルを作成するよう強制されます。

Windowsドメインへの参加

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

RHEL 8:

sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->

RHEL 7:

sudo net ads join REALM -U user
<!--NeedCopy-->

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

WinbindのPAM設定

デフォルトでは、Winbind PAMモジュール (pam_winbind) の設定では、Kerberosチケットのキャッシュとホームディレクトリの作成が有効になっていません。/etc/security/pam_winbind.conf を開き、[Global] セクションの下に次のエントリを追加または変更します。

krb5_auth = yes krb5_ccache_type = FILE mkhomedir = yes

各設定の先頭にあるセミコロンが削除されていることを確認してください。これらの変更には、Winbindデーモンの再起動が必要です。

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

ヒント:

winbind デーモンは、マシンがドメインに参加している場合にのみ実行を継続します。

/etc/krb5.conf を開き、[libdefaults] セクションの下にある次の設定をKEYRINGからFILEタイプに変更します。

default_ccache_name = FILE:/tmp/krb5cc_%{uid}

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

Delivery Controllerは、すべてのVDAマシン (WindowsおよびLinux VDA) がActive Directoryにコンピューターオブジェクトを持っていることを必要とします。

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

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

次のコマンドを実行して、追加のドメインおよびコンピューターオブジェクト情報を確認します。

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

Kerberos設定の確認

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

ドメインコントローラーでのQuestの設定

Active DirectoryドメインコントローラーにQuestソフトウェアをインストールおよび構成済みであり、Active Directoryでコンピューターオブジェクトを作成するための管理者権限が付与されていると仮定します。

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

Linux VDAマシンでHDX™セッションを確立するためのドメインユーザーの有効化:

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

注:

これらの手順は、コンソール、RDP、SSH、またはその他のリモートプロトコルを使用してログオンするドメインユーザーを設定する場合にも同様に適用されます。

Linux VDAでのQuestの構成

SELinuxポリシー強制の回避策

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

この問題を回避する便利な方法は、SELinuxを無効にすることです。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ドメインに参加させる権限を持つ任意のドメインユーザーです。ドメイン名はドメインの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コンソールに直接ログオンすることで実行できます。ドメイン参加の確認後、ステップ4:Linux VDAのインストールに進みます。

Centrify DirectControl

Windowsドメインへの参加

Centrify DirectControlエージェントがインストールされている状態で、Centrifyのadjoinコマンドを使用してLinuxマシンをActive Directoryドメインに参加させます。

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

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

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

Delivery Controllerは、すべてのVDAマシン(WindowsおよびLinux VDA)がActive Directoryにコンピューターオブジェクトを持つことを要求します。Centrifyに参加しているLinuxマシンがドメイン上にあることを確認するには、次のようにします。

su –
adinfo
<!--NeedCopy-->

「Joined to domain」の値が有効であり、CentrifyDCモードが「connected」を返すことを確認します。モードが「starting」状態のままになっている場合、Centrifyクライアントはサーバー接続または認証の問題を抱えています。

より包括的なシステムおよび診断情報は、以下を使用して利用できます。

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

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

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

ドメイン参加の確認後、ステップ4:Linux VDAのインストールに進みます。

SSSD

SSSDを使用している場合は、このセクションの手順に従ってください。このセクションには、Linux VDAマシンをWindowsドメインに参加させるための手順と、Kerberos認証を構成するためのガイダンスが含まれています。

RHELおよびCentOSでSSSDをセットアップするには、次の手順を実行します。

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

ドメインへの参加とホストキータブの作成

SSSDは、ドメインへの参加やシステムキータブファイルの管理のためのActive Directoryクライアント機能を提供しません。代わりに、adclirealmd、またはSambaを使用できます。

このセクションでは、RHEL 7およびRHEL 8におけるSambaadcliのアプローチについてそれぞれ説明します。realmdについては、RHELまたはCentOSのドキュメントを参照してください。これらの手順は、SSSDを構成する前に実行する必要があります。

  • Samba (RHEL 7):

    必要なパッケージをインストールまたは更新します。

     sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
     <!--NeedCopy-->
    

    適切に構成されたファイルを持つLinuxクライアントで:

    • /etc/krb5.conf
    • /etc/samba/smb.conf:

    SambaおよびKerberos認証用にマシンを構成します。

     sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
     <!--NeedCopy-->
    

    ここで、REALMはKerberosレルム名の大文字表記、domainはActive Directoryドメインの短いNetBIOS名です。

    注:

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

    KDCサーバーとレルム名のDNSベースのルックアップが必要な場合は、前のコマンドに次の2つのオプションを追加します。

    --enablekrb5kdcdns --enablekrb5realmdns

    /etc/samba/smb.confを開き、authconfigツールによって生成されたセクションの後に、[Global]セクションの下に次のエントリを追加します。

    kerberos method = secrets and keytab winbind offline logon = no

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

     sudo net ads join REALM -U user
     <!--NeedCopy-->
    

    REALMはKerberosレルム名の大文字表記であり、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。

  • Adcli (RHEL 8):

    必要なパッケージをインストールまたは更新します。

     sudo yum -y install samba-common samba-common-tools krb5-workstation authconfig oddjob-mkhomedir realmd oddjob authselect
     <!--NeedCopy-->
    

    SambaおよびKerberos認証用にマシンを構成します。

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

    /etc/krb5.confを開き、[realms]セクションと[domain_realm]セクションの下にエントリを追加します。

    [realms]セクションの下に:

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

    [domain_realm]セクションの下に:

    realm = REALM .realm = REALM

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

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

    REALMはKerberosレルム名の大文字表記であり、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。

SSSDのセットアップ

SSSDのセットアップは、次の手順で構成されます。

-  `sudo yum -y install sssd`コマンドを実行して、Linux VDAに**sssd-ad**パッケージをインストールします。
-  さまざまなファイル(例: sssd.conf)に構成変更を加えます。
  • sssdサービスを開始します。

RHEL 7のsssd.conf構成例(必要に応じて追加オプションを追加できます):

-  [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.comserver.ad.example.comを対応する値に置き換えます。詳細については、sssd-ad(5) - Linux man pageを参照してください。

(RHEL 8のみ) /etc/sssd/sssd.confを開き、[domain/ad.example.com]セクションの下に次のエントリを追加します。

ad_gpo_access_control = permissive full_name_format = %2$s\%1$s fallback_homedir = /home/%d/%u # Kerberos settings krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U

sssd.confのファイルの所有権と権限を設定します。

chown root:root /etc/sssd/sssd.conf chmod 0600 /etc/sssd/sssd.conf restorecon /etc/sssd/sssd.conf

SSSDの有効化

RHEL 8:

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

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

RHEL 7/CentOS 7:

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クレデンシャルキャッシュ内のチケットが有効であり、期限切れになっていないことを確認します。

klist
<!--NeedCopy-->

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

PBIS

必要なPBISパッケージのダウンロード

例: RHEL 7/CentOS 7の場合

wget https://github.com/BeyondTrust/pbis-open/releases/download/8.8.0/pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->

例: RHEL 8/CentOS 8の場合

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インストールスクリプトの実行可能化

例: RHEL 7/CentOS 7の場合

chmod +x pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->

例: RHEL 8/CentOS 8の場合

chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

PBISインストールスクリプトの実行

例: RHEL 7/CentOS 7の場合

sh pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->

例: RHEL 8/CentOS 8の場合

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/config LoginShellTemplate/bin/bashコマンドを実行します。

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

Delivery Controllerでは、すべてのVDAマシン(Windows VDAおよび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-->

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

  • 手順4:Linux VDAのインストール

新規インストールを実行するか、以前の2つのバージョンおよびLTSRリリースから既存のインストールをアップグレードできます。

新規インストール

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

    以前の2つのバージョンおよびLTSRリリース以外の古いバージョンをインストールしている場合は、新しいバージョンをインストールする前にアンインストールしてください。

    1. Linux VDAサービスを停止します。

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

      注記:

      ctxvda および ctxhdx サービスを停止する前に、service ctxmonitorservice stop コマンドを実行してモニターサービスデーモンを停止してください。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。

  2. パッケージをアンインストールします。

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

注記:

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

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

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

  2. Linux VDAのインストール

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

      RHEL 8/CentOS 8の場合:

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

      RHEL 7/CentOS 7の場合:

       sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
       <!--NeedCopy-->
      
    • RPMパッケージマネージャーを使用してLinux VDAソフトウェアをインストールします。これを行う前に、以下の依存関係を解決する必要があります。

      RHEL 8/CentOS 8の場合:

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

      RHEL 7/CentOS 7の場合:

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

      RHEL 8.2/CentOS 8.2のRPM依存関係リスト:

       postgresql-jdbc >= 42.2.3
      
       postgresql-server >= 10.6
      
       java-11-openjdk >= 11
      
       icoutils >= 0.32
      
       firewalld  >= 0.8.0
      
       policycoreutils-python-utils >= 2.9
      
       python3-policycoreutils >= 2.9
      
       dbus >= 1.12.8
      
       dbus-common  >= 1.12.8
      
       dbus-daemon   >= 1.12.8
      
       dbus-tools  >= 1.12.8
      
       dbus-x11 >= 1.12.8
      
       xorg-x11-server-utils >= 7.7
      
       xorg-x11-xinit >= 1.3.4
      
       libXpm >= 3.5.12
      
       libXrandr >= 1.5.1
      
       libXtst >= 1.2.3
      
       motif >= 2.3.4
      
       pam >= 1.3.1
      
       util-linux >= 2.32.1
      
       util-linux-user  >= 2.32.1
      
       xorg-x11-utils  >= 7.5
      
       bash >= 4.4
      
       findutils >= 4.6
      
       gawk >= 4.2
      
       sed >= 4.5
      
       cups >= 2.2
      
       foomatic-filters >= 4.0.9
      
       cups-filters >= 1.20.0
      
       ghostscript  >= 9.25
      
       libxml2 >= 2.9
      
       libmspack >= 0.7
       <!--NeedCopy-->
      

      RHEL 7/CentOS 7のRPM依存関係リスト:

       postgresql-server >= 9.2
      
       postgresql-jdbc >= 9.2
      
       java-11-openjdk >= 11
      
       ImageMagick >= 6.7.8.9
      
       firewalld >= 0.3.9
      
       policycoreutils-python >= 2.0.83
      
       dbus >= 1.6.12
      
       dbus-x11 >= 1.6.12
      
       xorg-x11-server-utils >= 7.7
      
       xorg-x11-xinit >= 1.3.2
      
       libXpm >= 3.5.10
      
       libXrandr >= 1.4.1
      
       libXtst >= 1.2.2
      
       motif >= 2.3.4
      
       pam >= 1.1.8
      
       util-linux >= 2.23.2
      
       bash >= 4.2
      
       findutils >= 4.5
      
       gawk >= 4.0
      
       sed >= 4.2
      
       cups >= 1.6.0
      
       foomatic-filters >= 4.0.9
      
       openldap >= 2.4
      
       cyrus-sasl >= 2.1
      
       cyrus-sasl-gssapi >= 2.1
      
       libxml2 >= 2.9
      
       python-requests >= 2.6.0
      
       gperftools-libs >= 2.4
      
       rpmlib(FileDigests) <= 4.6.0-1
      
       rpmlib(PayloadFilesHavePrefix) <= 4.0-1
      
       pmlib(CompressedFileNames) <= 3.0.4-1
      
       rpmlib(PayloadIsXz) <= 5.2-1
       <!--NeedCopy-->
      

      注記:

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

      注記:

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

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

既存のインストールは、以前の2つのバージョンおよびLTSRリリースからアップグレードできます。

  • Yum を使用してソフトウェアをアップグレードする場合:

    RHEL 7/CentOS 7の場合:

     sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
     <!--NeedCopy-->
    
  • RPMパッケージマネージャーを使用してソフトウェアをアップグレードする場合:

    RHEL 7/CentOS 7の場合:

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

注記:

RHEL 7を使用している場合は、上記のアップグレードコマンドを実行した後、以下の手順を完了していることを確認してください。

  1. /opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "DotNetRuntimePath" -d "/opt/rh/rh-dotnet31/root/usr/bin/" --force を実行して、正しい.NETランタイムパスを設定します。
  2. ctxvda サービスを再起動します。

重要:

ソフトウェアのアップグレード後、Linux VDAマシンを再起動してください。

手順 5: NVIDIA GRIDドライバーのインストール

HDX 3D Proを有効にするには、ハイパーバイザーおよびVDAマシンに必須のグラフィックドライバーをインストールするための追加のインストール手順が必要です。

以下を構成します。

  1. Citrix Hypervisor
  2. VMware ESX

選択したハイパーバイザーの手順に従ってください。

Citrix Hypervisor:

この詳細セクションでは、Citrix HypervisorへのNVIDIA GRIDドライバーのインストールと構成について説明します。

VMware ESX:

VMware ESX用のNVIDIA GRIDドライバーをインストールおよび構成するには、このガイドに含まれる情報に従ってください。

VDAマシン:

各Linux VMゲストのドライバーをインストールおよび構成するには、以下の手順に従ってください。

  1. 開始する前に、Linux VMがシャットダウンされていることを確認します。
  2. XenCenter®で、GPUパススルーモードでGPUをVMに追加します。
  3. RHEL VMを起動します。

NVIDIA GRIDドライバー用にマシンを準備するには、以下のコマンドを実行します。

yum install gcc

yum install "kernel-devel-$(uname -r)"

systemctl set-default multi-user.target
<!--NeedCopy-->

NVIDIA GRIDドライバーをインストールするには、Red Hat Enterprise Linuxドキュメントの手順に従ってください。

注記:

GPUドライバーのインストール中、各質問に対してデフォルトの「いいえ」を選択してください。

重要:

GPUパススルーが有効になった後、Linux VMはXenCenter経由でアクセスできなくなります。SSHを使用して接続してください。

NVIDIA smiコードスニペットの画像

カードの正しい構成を設定します。

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は、デフォルトでポート80であるTCP/IPポートを介して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 | 5 – Linux VDAは、Delivery Controllerとの認証のためにKerberos構成設定を必要とします。Kerberos構成は、システムにインストールおよび構成されているActive Directory統合ツールから決定されます。使用するサポートされているActive Directory統合方法を指定します。
    • 1 – Samba Winbind
    • 2 – Quest Authentication Services
    • 3 – Centrify DirectControl
    • 4 – SSSD
    • 5 – PBIS
  • CTX_XDL_HDX_3D_PRO=Y | N – Linux VDAは、リッチグラフィックアプリケーションの仮想化を最適化するように設計されたGPUアクセラレーションテクノロジーのセットであるHDX 3D Proをサポートします。HDX 3D Proが選択されている場合、VDAはVDIデスクトップ(シングルセッション)モード(つまり、CTX_XDL_VDI_MODE=Y)用に構成されます。
  • CTX_XDL_VDI_MODE=Y | N – マシンを専用デスクトップ配信モデル(VDI)として構成するか、ホスト型共有デスクトップ配信モデルとして構成するかどうかを指定します。HDX 3D Pro環境の場合、この変数をYに設定します。この変数はデフォルトでNに設定されます。
  • CTX_XDL_SITE_NAME=dns-name – Linux VDAは、DNSを介してLDAPサーバーを検出します。DNS検索結果をローカルサイトに制限するには、DNSサイト名を指定します。この変数はデフォルトで<none>に設定されます。
  • CTX_XDL_LDAP_LIST=’list-ldap-servers’ – Linux VDAは、DNSを照会してLDAPサーバーを検出します。DNSがLDAPサービスレコードを提供できない場合、LDAPポートを持つLDAP FQDNのスペース区切りリストを提供できます。たとえば、ad1.mycompany.com:389です。この変数はデフォルトで<none>に設定されます。
  • CTX_XDL_SEARCH_BASE=search-base-set – Linux VDAは、Active Directoryドメインのルートに設定された検索ベースを介してLDAPを照会します(例:DC=mycompany,DC=com)。検索パフォーマンスを向上させるには、検索ベース(例: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 Runtime 3.1をインストールするパスです。デフォルトのパスは/usr/binです。

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

    注記:

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

    1. VDA上の$HOME/<username>ディレクトリの下に.xsessionファイルを作成します。
    2. .xsessionファイルを編集して、ディストリビューションに基づいてデスクトップ環境を指定します。

      CentOS、Ubuntu、およびDebian上のMATEデスクトップの場合

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

      CentOS上のGNOMEデスクトップの場合

      GSESSION=”$(type -p gnome-session)” if [ -n “$GSESSION” ]; then

         export GNOME_SHELL_SESSION_MODE=classic
         exec gnome-session --session=gnome-classic    fi **UbuntuおよびDebian上のGNOMEデスクトップの場合**
      

      GSESSION=”$(type -p gnome-session)” if [ -n “$GSESSION” ]; then

         exec gnome-session    fi
      
    3. ターゲットセッションユーザーと700ファイル権限を共有します。
  • CTX_XDL_START_SERVICE=Y | N – Linux VDAの構成が完了したときにLinux VDAサービスが開始されるかどうかを指定します。デフォルトではYに設定されます。
  • CTX_XDL_TELEMETRY_SOCKET_PORT – Citrix Scoutのリッスン用ソケットポートです。デフォルトポートは7503です。
  • CTX_XDL_TELEMETRY_PORT – Citrix Scoutとの通信用ポートです。デフォルトポートは7502です。

環境変数を設定し、構成スクリプトを実行します。

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST='list-ddc-fqdns'

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4|5

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-site-name | '<none>'

export CTX_XDL_LDAP_LIST='list-ldap-servers' | '<none>'

export CTX_XDL_SEARCH_BASE=search-base-set | '<none>'

export CTX_XDL_FAS_LIST='list-fas-servers' | '<none>'

export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime

export CTX_XDL_DESKTOP_ENVIRONMENT= gnome | 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を含むシェルスクリプトファイルを作成することをお勧めします。

または、単一のコマンドを使用してすべてのパラメーターを指定することもできます。

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST='list-ddc-fqdns' \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4|5 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST='list-ldap-servers' \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST='list-fas-servers' \

CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \

CTX_XDL_DESKTOP_ENVIRONMENT=gnome | mate \

CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \

CTX_XDL_TELEMETRY_PORT=port-number \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->

構成変更の削除

場合によっては、Linux VDAパッケージをアンインストールせずに、ctxsetup.shスクリプトによって行われた構成変更を削除する必要があるかもしれません。

続行する前に、このスクリプトに関するヘルプを確認してください。

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

構成変更を削除するには、次のようにします。

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->

重要:

このスクリプトは、データベースからすべての構成データを削除し、Linux VDAを動作不能にします。

構成ログ

ctxsetup.shおよびctxcleanup.shスクリプトは、コンソールにエラーを表示し、追加情報は構成ログファイル/tmp/xdl.configure.logに書き込まれます。

変更を有効にするには、Linux VDAサービスを再起動します。

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

注記:

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

手順8: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 Server OSまたはServer OSオプションを選択すると、同等のホスト型共有デスクトップ配信モデルが示唆されます。Windows Desktop OSまたはDesktop OSオプションを選択すると、マシンあたり1ユーザーの配信モデルが示唆されます。

ヒント:

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

ステップ9: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 2103」を参照してください。