Amazon Linux 2、CentOS、RHEL 向け Linux Virtual Delivery Agent の手動インストール

重要:

新規インストールの場合、迅速なインストールには 簡易インストール の使用をお勧めします。簡易インストールは時間と労力を節約し、この記事で詳述されている手動インストールよりもエラーが発生しにくいです。

手順 1: VDA インストール用の Linux ディストリビューションの準備

手順 1a: ネットワーク構成の確認

ネットワークが正しく接続され、構成されていることを確認してください。たとえば、Linux VDA 上で DNS サーバーを構成する必要があります。

手順 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 が必要です。

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

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

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

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

手順 1h: PostgreSQL のインストール

Linux VDA には PostgreSQL が必要です。次のコマンドは、Linux VDA パッケージから PostgreSQL をインストールします (Amazon Linux 2、RHEL 7、CentOS 7 の場合は PostgreSQL 9、RHEL 8 の場合は PostgreSQL 10)。

sudo yum -y install postgresql-server

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

データベースを初期化し、マシン起動時にサービスが開始されるようにするには、次のインストール後の手順が必要です。このアクションにより、/var/lib/pgsql/data の下にデータベースファイルが作成されます。

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モードでは変更は不要です。

Citrix VM Toolsがインストールされたパラ仮想化Linuxカーネルを実行している場合、Linux VM内からCitrix Hypervisorの時刻同期機能が存在し、有効になっているかを確認できます。

su -

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

このコマンドは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の場合:

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

Amazon Linux 2、CentOS 7、およびRHEL 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-->

    Amazon Linux 2、CentOS 7、および 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 サービスの起動失敗に関するエラーは無視してください。これらのエラーは、マシンがまだドメインに参加していない状態で authconfig が winbind サービスを起動しようとしたときに発生する可能性があります。

  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 で認証および登録するためにシステム keytab ファイル /etc/krb5.keytab を必要とします。以前の kerberos method 設定により、マシンが最初にドメインに参加したときに Winbind がシステム keytab ファイルを作成するよう強制されます。

Windows ドメインへの参加

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

RHEL 8 の場合:

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

Amazon Linux 2 および 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 が Linux VDA で使用するために正しく構成されていることを確認するには、システム 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シェルでは、円記号 (\) 文字を別の円記号でエスケープする必要があります。このコマンドは、成功または失敗を示すメッセージを返します。

Winbind PAMモジュールが正しく構成されていることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用してLinux VDAにログオンします。

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Kerberos資格情報キャッシュ内のチケットが有効で、期限切れになっていないことを確認します。

klist
<!--NeedCopy-->

exit
<!--NeedCopy-->

同様のテストは、GnomeまたはKDEコンソールに直接ログオンして実行できます。ドメイン参加の検証後、手順 6: Linux VDAのインストールに進みます。

Quest認証サービス

ドメインコントローラーでの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ドメインに参加させる権限を持つドメインユーザーです。ドメイン名は、たとえばexample.comのようなドメインのDNS名です。

ドメインメンバーシップの検証

Delivery Controllerでは、すべてのVDAマシン（WindowsおよびLinux VDA）がActive Directoryにコンピューターオブジェクトを持っている必要があります。Questに参加しているLinuxマシンがドメイン上にあることを確認するには：

sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->

マシンがドメインに参加している場合、このコマンドはドメイン名を返します。マシンがどのドメインにも参加していない場合、次のエラーが表示されます。

ERROR: No domain could be found. ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm default_realm not configured in vas.conf. Computer may not be joined to domain

ユーザー認証の検証

QuestがPAMを介してドメインユーザーを認証できることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用してLinux VDAにログオンします。

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

id -uコマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します。

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Kerberos資格情報キャッシュ内のチケットが有効で、期限切れになっていないことを確認します。

/opt/quest/bin/vastool klist
<!--NeedCopy-->

セッションを終了します。

exit
<!--NeedCopy-->

同様のテストは、GnomeまたはKDEコンソールに直接ログオンして実行できます。ドメイン参加の検証後、手順 6: Linux VDAのインストールに進みます。

Centrify DirectControl

Windowsドメインへの参加

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

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

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

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

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

su –
adinfo
<!--NeedCopy-->

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

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

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

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

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

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

SSSD

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

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

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

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

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

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

SSSDのセットアップ

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

-  `sudo yum -y install sssd` コマンドを実行して、Linux VDA に **sssd-ad** パッケージをインストール

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

RHEL 7 の SSSD 構成例

ad.example.com、server.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

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

Amazon Linux 2、CentOS 7、および RHEL 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 コマンドを使用して確認します。

サポートされているログオン形式は次のとおりです。

    -  sudo ssh localhost –l DOMAIN\\username

    -  id -u
<!--NeedCopy-->

-  コマンドによって返された **uid** に対応する Kerberos 資格情報キャッシュファイルが作成されたことを確認します。

    -  ls /tmp/krb5cc_{uid}
<!--NeedCopy-->

-  ユーザーの Kerberos 資格情報キャッシュ内のチケットが有効であり、期限切れになっていないことを確認します。

klist
<!--NeedCopy-->

ドメイン参加の検証後、手順 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/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-->

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

手順4：前提条件として.NET Runtime 6.0をインストール

Linux VDAをインストールする前に、https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managersの指示に従って.NET Runtime 6.0をインストールします。

.NET Runtime 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ディストリビューションに一致するLinux VDAパッケージをダウンロードします。

手順6：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をシステムパスに追加することもできます。

  2. Linux VDAのインストール

    注：

    RHELおよびCentOSの場合、Linux VDAを正常にインストールする前にEPELリポジトリをインストールしてください。EPELのインストール方法については、https://docs.fedoraproject.org/en-US/epel/の指示を参照してください。

    注:

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

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

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

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

注:

既存のインストールをアップグレードすると、/etc/xdlの下にある構成ファイルが上書きされます。アップグレードを実行する前に、ファイルをバックアップしてください。

注:

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

  1. .NETランタイムパスを正しく設定するために、/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を実行します。
  2. ctxvdaサービスを再起動します。

重要:

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

ステップ 7: NVIDIA GRIDドライバーのインストール

HDX 3D Proを有効にするには、ハイパーバイザーとVDAマシンにNVIDIA GRIDドライバーをインストールする必要があります。

注:

Amazon Linux 2でHDX 3D Proを使用するには、NVIDIAドライバー470をインストールすることをお勧めします。詳細については、システム要件を参照してください。

特定のハイパーバイザーにNVIDIA GRID Virtual GPU Manager（ホストドライバー）をインストールおよび構成するには、次のガイドを参照してください。

NVIDIA GRIDゲストVMドライバーをインストールおよび構成するには、次の手順を実行します。

  1. ゲストVMがシャットダウンされていることを確認します。
  2. XenCenter®で、VMにGPUを割り当てます。
  3. VMを起動します。

  4. NVIDIA GRIDドライバー用にVMを準備します:

    yum install gcc

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

systemctl set-default multi-user.target
<!--NeedCopy-->
  5. Red Hat Enterprise Linuxドキュメントの手順に従って、NVIDIA GRIDドライバーをインストールします。

注:

GPUドライバーのインストール中に、各質問に対してデフォルト（「no」）を選択します。

重要:

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

NVIDIA smiコードスニペット

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

etc/X11/ctx-nvidia.sh

高解像度およびマルチモニター機能を利用するには、有効なNVIDIAライセンスが必要です。ライセンスを申請するには、「GRID Licensing Guide.pdf - DU-07757-001 September 2015」の製品ドキュメントに従ってください。

ステップ 8: 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エイリアスを指定する必要があります。

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

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 | 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
<!--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|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
<!--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サービスを再起動します。

ステップ9：XDPingの実行

Linux VDA環境における一般的な構成の問題を確認するには、sudo /opt/Citrix/VDA/bin/xdpingを実行します。詳細については、「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：Citrix Virtual AppsまたはCitrix Virtual Desktops™でのマシンカタログの作成

マシンカタログを作成し、Linux VDAマシンを追加するプロセスは、従来のWindows VDAのアプローチと似ています。これらのタスクを完了する方法の詳細については、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。

Linux VDAマシンを含むマシンカタログを作成する場合、Windows VDAマシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。

注：

Citrix Studioの初期バージョンでは、「Linux OS」という概念はサポートされていませんでした。ただし、Windows Server OSまたはServer OSオプションを選択すると、同等のホスト型共有デスクトップ配信モデルが意味されます。Windows Desktop OSまたはDesktop OSオプションを選択すると、マシンあたり1ユーザーの配信モデルが意味されます。

ヒント：

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

ステップ12：Citrix Virtual Apps™またはCitrix Virtual Desktopsでのデリバリーグループの作成

デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加するプロセスは、Windows VDAマシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。

Linux VDAマシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。

重要：

アプリケーションの公開はLinux VDAバージョン1.4以降でサポートされています。ただし、Linux VDAは、同じマシンへのデスクトップとアプリの配信をサポートしていません。

マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2206」を参照してください。