重要:
新規インストールの場合、迅速なインストールには 簡易インストール の使用をお勧めします。簡易インストールは、時間と労力を節約し、この記事で詳述されている手動インストールよりもエラーが発生しにくいです。
ネットワークが正しく接続され、構成されていることを確認してください。たとえば、Linux VDA で DNS サーバーを構成する必要があります。
マシンのホスト名が正しく報告されるように、/etc/hostname ファイルをマシンのホスト名のみを含むように変更します。
hostname
マシンの 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 のホスト名にも適用されます。
ホスト名が正しく設定されていることを確認します。
hostname
<!--NeedCopy-->
このコマンドは、マシンのホスト名のみを返し、完全修飾ドメイン名 (FQDN) は返しません。
FQDN が正しく設定されていることを確認します。
hostname -f
<!--NeedCopy-->
このコマンドは、マシンの FQDN を返します。
FQDN を解決し、ドメインコントローラーと Delivery Controller™ に ping を実行できることを確認します。
- nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
FQDN を解決できない場合、またはこれらのマシンのいずれかに ping を実行できない場合は、続行する前に手順を確認してください。
VDA、Delivery Controller、およびドメインコントローラー間で正確なクロック同期を維持することは非常に重要です。Linux VDA を仮想マシンとしてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモート時刻サービスとの時刻同期が推奨されます。
RHEL 8 または RHEL 7 のデフォルト環境では、クロック同期に Chrony デーモン (chronyd) を使用します。
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-->
Linux VDA には OpenJDK 11 が必要です。
Amazon Linux 2 を使用している場合は、次のコマンドを実行して OpenJDK 11 を有効にしてインストールします
amazon-linux-extras install java-openjdk11
<!--NeedCopy-->
正しいバージョンを確認します。
sudo yum info java-11-openjdk
<!--NeedCopy-->
プリパッケージされた OpenJDK は以前のバージョンである可能性があります。OpenJDK 11 に更新します。
sudo yum -y update java-11-openjdk
<!--NeedCopy-->
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-->
マシン起動時にサービスを開始し、すぐにサービスを開始します。
- 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-->
サポートされているハイパーバイザー上でLinux VDAを仮想マシンとして実行する場合、いくつかの変更が必要です。使用しているハイパーバイザープラットフォームに基づいて、以下の変更を行います。Linuxマシンをベアメタルハードウェアで実行している場合、変更は不要です。
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を返します。
Hyper-V Linux Integration ServicesがインストールされているLinux VMは、Hyper-Vの時刻同期機能を使用してホストオペレーティングシステムの時刻を使用できます。システムクロックの正確性を維持するためには、この機能をNTPサービスと並行して有効にする必要があります。
管理オペレーティングシステムから:
注:
このアプローチは、NTPとの競合を避けるためにホストの時刻同期を無効にするVMwareおよびCitrix Hypervisorとは異なります。Hyper-Vの時刻同期はNTPの時刻同期と共存し、補完することができます。
VMwareの時刻同期機能が有効になっている場合、各準仮想化Linux VM内でNTPとハイパーバイザーの両方がシステムクロックを同期しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各Linuxゲスト内のシステムクロックがNTPと同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsがインストールされた準仮想化Linuxカーネルを実行している場合:
Linux VDAは、LinuxマシンをActive Directory (AD) ドメインに追加するためのいくつかの方法をサポートしています。
選択した方法に基づいて指示に従ってください。
注:
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッション起動が失敗する可能性があります。
必要なパッケージをインストールまたは更新します。
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デーモンは、マシン起動時に開始するように構成する必要があります。
sudo /sbin/chkconfig winbind on
<!--NeedCopy-->
Winbindを使用してKerberos認証用にマシンを構成します。
次のコマンドを実行します。
RHEL 8の場合:
sudo authselect select winbind with-mkhomedir --force
<!--NeedCopy-->
Amazon Linux 2 および 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 サービスを起動しようとしたときに発生する可能性があります。
/etc/samba/smb.conf を開き、[Global] セクションの authconfig ツールによって生成されたセクションの後に、次のエントリを追加します。
kerberos method = secrets and keytab
winbind refresh tickets = true
winbind offline logon = no
(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 がシステムキータブファイルを作成するよう強制されます。
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つ 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 モジュール (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-->
Linux VDA で Kerberos が正しく構成されていることを確認するには、システムキータブファイルが作成され、有効なキーが含まれていることを確認します。
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のインストールに進みます。
Active DirectoryドメインコントローラーにQuestソフトウェアをインストールして構成済みであり、Active Directoryでコンピューターオブジェクトを作成するための管理者権限が付与されていると仮定します。
ドメインユーザーがLinux VDAマシンでHDX™セッションを確立できるようにするには：
注：
これらの手順は、コンソール、RDP、SSH、またはその他のリモートプロトコルを使用してログオンするドメインユーザーを設定する場合にも同様に適用されます。
デフォルトのRHEL環境では、SELinuxが完全に強制されます。この強制は、Questが使用するUnixドメインソケットIPCメカニズムと干渉し、ドメインユーザーのログオンを妨げます。
この問題を回避する便利な方法は、SELinuxを無効にすることです。rootユーザーとして、/etc/selinux/configを編集し、SELinux設定を変更します。
SELINUX=permissive
この変更にはマシンの再起動が必要です。
reboot
<!--NeedCopy-->
重要：
この設定は慎重に使用してください。無効にした後にSELinuxポリシーの強制を再度有効にすると、rootユーザーや他のローカルユーザーであっても、完全にロックアウトされる可能性があります。
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時間短いです。チケット有効期間が短いシステムでは、このパラメーターをより低い値に設定してください。
HDXおよびsu、ssh、RDPなどの他のサービスを介したドメインユーザーのログオンを有効にするには、次のコマンドを実行してPAMとNSSを手動で構成します。
sudo /opt/quest/bin/vastool configure pam
sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->
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 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 を返すことを確認します。モードが starting 状態のままになっている場合、Centrify クライアントはサーバー接続または認証の問題を抱えています。
より包括的なシステムおよび診断情報は、以下を使用して利用できます。
adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->
さまざまな Active Directory および Kerberos サービスへの接続をテストします。
- adinfo --test
<!--NeedCopy-->
ドメイン参加の確認後、手順 6: Linux VDA のインストールに進みます。
SSSD を使用している場合は、このセクションの指示に従ってください。このセクションには、Linux VDA マシンを Windows ドメインに参加させるための手順と、Kerberos 認証を構成するためのガイダンスが含まれています。
RHEL および CentOS で SSSD をセットアップするには、次の手順を実行します。
SSSD は、ドメインへの参加やシステムキータブファイルの管理のための Active Directory クライアント機能を提供しません。代わりに adcli、realmd、または Samba を使用できます。
このセクションでは、Amazon Linux 2 および RHEL 7 の Samba アプローチと、RHEL 8 の adcli アプローチについて説明します。realmd については、RHEL または CentOS のドキュメントを参照してください。これらの手順は、SSSD を構成する前に実行する必要があります。
Samba (Amazon Linux 2 および RHEL 7):
必要なパッケージをインストールまたは更新します。
sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
<!--NeedCopy-->
適切に構成されたファイルを持つ Linux クライアントで、以下を実行します。
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 名です。
注：
この記事の設定は、単一ドメイン、単一フォレストモデルを対象としています。AD インフラストラクチャに基づいて Kerberos を構成してください。
KDC サーバーとレルム名の DNS ベースのルックアップが必要な場合は、上記のコマンドに次の 2 つのオプションを追加します。
--enablekrb5kdcdns --enablekrb5realmdns
/etc/samba/smb.conf を開き、[Global] セクションの下、ただし authconfig ツールによって生成されたセクションの後に、次のエントリを追加します。
kerberos method = secrets and keytab
winbind offline logon = no
Windows ドメインに参加します。ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つ Active Directory ユーザーアカウントがあることを確認します。
sudo net ads join REALM -U user
<!--NeedCopy-->
REALM は大文字の Kerberos レルム名、user はコンピューターをドメインに追加する権限を持つドメインユーザーです。
必要なパッケージをインストールまたは更新します。
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 の設定は、次の手順で構成されます。
- `sudo yum -y install sssd` コマンドを実行して、Linux VDA に **sssd-ad** パッケージをインストールします。
RHEL 7 の sssd.conf 構成例（必要に応じて追加オプションを追加できます）：
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
# 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
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-->
システム 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
username@domain.com
NetBIOS サフィックス形式: username@DOMAIN
- sudo ssh localhost –l DOMAIN\\username
- id -u
<!--NeedCopy-->
- コマンドによって返された **uid** に対応する Kerberos 資格情報キャッシュファイルが作成されたことを確認します。
- ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
- ユーザーの Kerberos 資格情報キャッシュ内のチケットが有効で、期限切れになっていないことを確認します。
klist
<!--NeedCopy-->
ドメイン参加の検証後、「手順 6: Linux VDA のインストール」に進みます。
wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
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-->
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つ Active Directory ユーザーアカウントが必要です。
/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
user は、コンピューターを Active Directory ドメインに追加する権限を持つドメインユーザーです。domain-name は、たとえば example.com のようなドメインの DNS 名です。
注: Bash をデフォルトシェルとして設定するには、/opt/pbis/bin/config LoginShellTemplate/bin/bash コマンドを実行します。
デリバリーコントローラーは、すべての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のインストールに進みます。
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バイナリパスとして使用します。
Citrix Virtual Apps and Desktopsダウンロードページに移動します。Citrix Virtual Apps and Desktopsの適切なバージョンを展開し、Componentsをクリックして、お使いのLinuxディストリビューションに一致するLinux VDAパッケージをダウンロードします。
新規インストールを実行するか、以前の2つのバージョンおよびLTSRリリースから既存のインストールをアップグレードできます。
(オプション) 古いバージョンのアンインストール
以前の2つのバージョンおよびLTSRリリース以外のバージョンをインストールした場合は、新しいバージョンをインストールする前にそれをアンインストールします。
Linux VDAサービスを停止します:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx stop
<!--NeedCopy-->
注:
ctxvdaおよびctxhdxサービスを停止する前に、service ctxmonitorservice stopコマンドを実行してモニターサービスデーモンを停止します。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
パッケージをアンインストールします:
sudo rpm -e XenDesktopVDA
<!--NeedCopy-->
注:
コマンドを実行するにはフルパスが必要です。または、/opt/Citrix/VDA/sbinおよび/opt/Citrix/VDA/binをシステムパスに追加できます。
Linux VDAのインストール
注:
RHELおよびCentOSの場合、Linux VDAを正常にインストールする前にEPELリポジトリをインストールしてください。EPELのインストール方法については、https://docs.fedoraproject.org/en-US/epel/の手順を参照してください。
Yumを使用してLinux VDAソフトウェアをインストールします:
Amazon Linux 2の場合:
- sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
RHEL 8の場合:
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
CentOS 7およびRHEL 7の場合:
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
RPMパッケージマネージャーを使用してLinux VDAソフトウェアをインストールします。そうする前に、次の依存関係を解決する必要があります:
Amazon Linux 2の場合:
sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
RHEL 8の場合:
sudo rpm -i XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
CentOS 7およびRHEL 7の場合:
sudo rpm -i XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
RHEL 8のRPM依存関係リスト:
qt5-qtbase >= 5.5~
ibus >= 1.5
nss-tools >= 3.44.0
gperftools-libs >= 2.4
cyrus-sasl-gssapi >= 2.1
python2 >= 2.7~
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-->
Amazon Linux 2、CentOS 7、およびRHEL 7のRPM依存関係リスト:
qt5-qtbase >= 5.5~
libmspack >= 0.5
ibus >= 1.5
cyrus-sasl-gssapi >= 2.1
gperftools-libs >= 2.4
nss-tools >= 3.44.0
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
xorg-x11-server-Xorg >= 1.20.4
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-websockifyとx11vncを手動でインストールすることです。詳細については、セッションシャドウイングを参照してください。
既存のインストールは、以前の2つのバージョンおよびLTSRリリースからアップグレードできます。
注:
既存のインストールをアップグレードすると、/etc/xdlの下にある構成ファイルが上書きされます。アップグレードを実行する前に、ファイルをバックアップしてください。
Yumを使用してソフトウェアをアップグレードするには:
Amazon Linux 2の場合:
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
RHEL 8の場合:
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
CentOS 7およびRHEL 7の場合:
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
RPMパッケージマネージャーを使用してソフトウェアをアップグレードするには:
Amazon Linux 2の場合:
sudo rpm -U XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
RHEL 8の場合:
sudo rpm -U XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
CentOS 7およびRHEL 7の場合:
sudo rpm -U XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
注:
RHEL 7を使用している場合は、上記のアップグレードコマンドを実行した後、以下の手順を完了してください。
/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ランタイムパスを設定します。ctxvdaサービスを再起動します。重要:
ソフトウェアのアップグレード後、Linux VDAマシンを再起動してください。
HDX 3D Proを有効にするには、ハイパーバイザーとVDAマシンにNVIDIA GRIDドライバーをインストールする必要があります。
注:
Amazon Linux 2でHDX 3D Proを使用するには、NVIDIAドライバー470をインストールすることをお勧めします。詳細については、システム要件を参照してください。
特定のハイパーバイザーにNVIDIA GRID Virtual GPU Manager（ホストドライバー）をインストールおよび構成するには、以下のガイドを参照してください。
NVIDIA GRIDゲストVMドライバーをインストールおよび構成するには、以下の手順を実行します。
NVIDIA GRIDドライバー用にVMを準備します:
yum install gcc
yum install "kernel-devel-$(uname -r)"
systemctl set-default multi-user.target
<!--NeedCopy-->
注:
GPUドライバーのインストール中、各質問に対してデフォルト（「いいえ」）を選択します。
重要:
GPUパススルーが有効になると、Linux VMはXenCenter経由でアクセスできなくなります。SSHを使用して接続してください。
カードの正しい構成を設定します:
etc/X11/ctx-nvidia.sh
高解像度およびマルチモニター機能を利用するには、有効なNVIDIAライセンスが必要です。ライセンスを申請するには、「GRID Licensing Guide.pdf - DU-07757-001 September 2015」の製品ドキュメントに従ってください。
パッケージをインストールした後、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_REGISTER_SERVICE=Y | N** - Linux VDAサービスは、マシンの起動後に開始されます。デフォルトではYに設定されています。 |
| **CTX_XDL_ADD_FIREWALL_RULES=Y | N** – Linux VDAサービスは、システムファイアウォールを介して受信ネットワーク接続が許可される必要があります。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統合方法を指定します |
| **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_SEARCH_BASE=search-base-set – Linux VDAは、Active Directoryドメインのルート（例: DC=mycompany,DC=com）に設定された検索ベースを介してLDAPにクエリを実行します。検索パフォーマンスを向上させるには、検索ベース（例: OU=VDI,DC=mycompany,DC=com）を指定できます。この変数はデフォルトで<none>に設定されています。
CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – 新しいブローカーエージェントサービス (ctxvda) をサポートするための .NET Runtime 6.0 のインストールパス。デフォルトのパスは /usr/bin です。
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate – セッションで使用する GNOME、GNOME Classic、または MATE デスクトップ環境を指定します。変数を指定しない場合、VDA に現在インストールされているデスクトップが使用されます。ただし、現在インストールされているデスクトップが MATE の場合、変数値を mate に設定する必要があります。
ターゲットセッションユーザーのデスクトップ環境は、次の手順で変更することもできます。
.xsession または .Xclients ファイルを作成します。Amazon Linux 2 を使用している場合は .Xclients ファイルを作成します。その他のディストリビューションを使用している場合は .xsession ファイルを作成します。ディストリビューションに基づいてデスクトップ環境を指定するように、.xsession または .Xclients ファイルを編集します。
Amazon Linux 2 および RHEL 8 上の MATE デスクトップの場合
MSESSION="$(type -p mate-session)"
if [ -n "$MSESSION" ]; then
exec mate-session
fi
Amazon Linux 2、CentOS、および RHEL 上の GNOME Classic デスクトップの場合
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
export GNOME_SHELL_SESSION_MODE=classic
exec gnome-session --session=gnome-classic
fi
Amazon Linux 2、CentOS、および RHEL 上の GNOME デスクトップの場合
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
exec gnome-session
fi
| **CTX_XDL_START_SERVICE=Y | N** – Linux VDA の構成が完了したときに Linux VDA サービスを開始するかどうか。デフォルトでは Y に設定されています。 |
環境変数を設定し、構成スクリプトを実行します。
export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N
export CTX_XDL_DDC_LIST='list-ddc-fqdns'
export CTX_XDL_VDA_PORT=port-number
export CTX_XDL_REGISTER_SERVICE=Y|N
export CTX_XDL_ADD_FIREWALL_RULES=Y|N
export CTX_XDL_AD_INTEGRATION=1|2|3|4|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 サービスを再起動します。
sudo /opt/Citrix/VDA/bin/xdping を実行して、Linux VDA 環境における一般的な構成の問題を確認します。詳細については、「XDPing」を参照してください。
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-->
マシンカタログを作成し、Linux VDA マシンを追加するプロセスは、従来の Windows VDA のアプローチに似ています。これらのタスクを完了する方法の詳細については、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
Linux VDA マシンを含むマシンカタログを作成する場合、Windows VDA マシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。
注：
Citrix Studio の初期バージョンでは、「Linux OS」という概念はサポートされていませんでした。ただし、Windows Server OS または Server OS オプションを選択すると、同等のホスト型共有デスクトップ配信モデルが暗示されます。Windows Desktop OS または Desktop OS オプションを選択すると、マシンごとに単一ユーザーの配信モデルが暗示されます。
ヒント：
マシンを Active Directory ドメインから削除して再参加させる場合、そのマシンをマシンカタログから削除して再度追加する必要があります。
デリバリーグループを作成し、Linux VDA マシンを含むマシンカタログを追加するプロセスは、Windows VDA マシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDA マシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。
重要：
アプリケーションの公開は、Linux VDA バージョン 1.4 以降でサポートされています。ただし、Linux VDA は、同じマシンへのデスクトップとアプリの配信をサポートしていません。
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2206」を参照してください。