Amazon Linux 2、RHEL、およびRocky LinuxへのLinux VDAの手動インストール
重要:
新規インストールの場合は、簡単インストールを使用して簡易インストールを行うことをお勧めします。簡単インストールは時間と労力を節約するだけでなく、本記事に記載されている手動インストールよりもエラーを減らすことができます。
手順1: 構成ファイル情報およびLinuxマシンの準備
手順1a:ネットワーク構成の確認
ネットワークが正しく接続および構成されていることを確認してください。たとえば、DNSサーバーはLinux VDAで構成する必要があります。
手順1b:ホスト名の設定
マシンのホスト名が確実に正しく報告されるようにするには、/etc/hostnameファイルを変更してマシンのホスト名のみを記述します。
hostname
手順1c:ホスト名へのループバックアドレスの割り当て
マシンのDNSドメイン名と完全修飾ドメイン名(FQDN)が確実に正しく報告されるようにするには、/etc/hosts
ファイルの以下の行を変更し、最初の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)ではなく、そのホスト名のみが返されます。
次のコマンドで、完全修飾ドメイン名が正しく設定されていることを確認します:
hostname -f
<!--NeedCopy-->
このコマンドにより、そのマシンの完全修飾ドメイン名が返されます。
手順1e:名前解決とサービス到達可能性の確認
次のコマンドで、完全修飾ドメイン名が解決できることと、ドメインコントローラーとDelivery Controllerからpingに応答があることを確認します:
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
完全修飾ドメイン名を解決できない、またはこれらのマシンのいずれかからpingに応答がない場合は、手順を確認してから次に進んでください。
手順1f:時刻同期の構成
VDA、Delivery Controller、ドメインコントローラーの間で正確な時刻同期を維持することは重要です。仮想マシン(VM)としてLinux VDAをホストすると、時刻が不正確になる問題が発生する可能性があります。したがって、リモートのタイムサービスを使用して時刻を維持することをお勧めします。
RHELのデフォルト環境では、時刻同期にChronyデーモン(chronyd
)を使用します。
Chronyサービスの構成
ルートユーザーとして /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エントリなど、一覧にあるその他のserverエントリを削除します。
変更を保存してから、次のコマンドでChronyデーモンを再起動します:
sudo systemctl restart chronyd
<!--NeedCopy-->
手順1g:OpenJDK 11のインストール
Linux VDAには、OpenJDK 11が必要です。
- RHELを使用している場合は、Linux VDAをインストールすると、依存関係としてOpenJDK 11が自動的にインストールされます。
-
Amazon Linux 2またはRocky Linuxを使用している場合は、次のコマンドを実行して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-->
手順1h:使用するデータベースのインストールと指定
注:
VDIモードのみでSQLiteを使用し、ホストされる共有デスクトップ配信モデルにはPostgreSQLを使用することをお勧めします。
簡単インストールとMCSのために、SQLiteとPostgreSQLは、それぞれを手動でインストールすることなく指定することができます。/etc/xdl/db.confで特に指定しない限り、Linux VDAはデフォルトでPostgreSQLを使用します。
手動インストールの場合は、SQLite、PostgreSQL、またはその両方を手動でインストールする必要があります。SQLiteとPostgreSQLの両方をインストールする場合、Linux VDAパッケージをインストールしてから/etc/xdl/db.confを編集すると、どちらを使用するかを指定できます。
このセクションでは、PostgreSQLとSQLiteをインストールする方法と、どちらを使用するかを指定する方法について説明します。
PostgreSQLのインストール
Linux VDAにはPostgreSQLが必要です:
- PostgreSQL 9:Amazon Linux 2の場合
- PostgreSQL 10:RHEL 8.x、Rocky Linux 8.xの場合
- PostgreSQL 13:RHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2の場合
次のコマンドを実行して、PostgreSQLをインストールします:
sudo yum -y install postgresql-server
sudo yum -y install postgresql-jdbc
<!--NeedCopy-->
RHEL 8.xとRHEL 9.4/9.3/9.2の場合、次のコマンドを実行してPostgreSQLのlibpq
をインストールします:
sudo yum -y install libpq
<!--NeedCopy-->
次のコマンドを実行して、データベースを初期化します。この操作により、/var/lib/pgsql/data にデータベースファイルが作成されます。
sudo postgresql-setup initdb
<!--NeedCopy-->
マシンの起動時または即時でPostgreSQL起動するには、それぞれ次のコマンドを実行します:
sudo systemctl enable postgresql
sudo systemctl start postgresql
<!--NeedCopy-->
次のコマンドを使用して、PostgreSQLのバージョンを確認します:
psql --version
<!--NeedCopy-->
(Amazon Linux 2の場合のみ)次のようにpsqlコマンドラインユーティリティを使用して、データディレクトリが設定されていることを確認します:
sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->
SQLiteをインストールする
次のコマンドを実行してSQLiteをインストールします:
sudo yum -y install sqlite
<!--NeedCopy-->
使用するデータベースを指定する
SQLiteとPostgreSQLの両方をインストールする場合、Linux VDAパッケージをインストールしてから/etc/xdl/db.confを編集すると、どちらを使用するかを指定できます。
- /opt/Citrix/VDA/sbin/ctxcleanup.shを実行します。新規インストールの場合、この手順は省きます。
- /etc/xdl/db.confを編集して、使用するデータベースを指定します。
- ctxsetup.shを実行します。
注:
/etc/xdl/db.conf を使用してPostgreSQLのポート番号を構成することもできます。
手順2:ハイパーバイザーの準備
サポートされるハイパーバイザー上でVMとしてLinux VDAを実行する場合、いくつかの変更が必要です。使用するハイパーバイザーのプラットフォームに合わせて、次の変更を行います。ベアメタルハードウェアでLinuxマシンを実行する場合、変更は必要ありません。
XenServer(旧称Citrix Hypervisor)での時刻同期の修正
XenServerの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとXenServerの問題が発生します。これは、NTPとCitrix Hypervisorの両方がシステムの時間を管理しようとすることが原因です。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは、変更は必要ありません。
XenServer Toolsがインストールされた準仮想化Linuxカーネルを実行している場合、XenServerの時刻同期機能が存在するかどうかと、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
これらの変更を確認するため、次のようにしてシステムを再起動します:
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは1を返します。
Microsoft Hyper-Vでの時刻同期の修正
Hyper-V Linux統合サービスがインストールされたLinux仮想ホストでは、Hyper-Vの時刻同期機能を適用してホストオペレーティングシステムの時間を利用できます。システムの時間を正確な状態で維持するには、NTPサービスとともにこの機能を有効にする必要があります。
管理オペレーティングシステムで、次の操作を行います。
- Hyper-Vマネージャーを開きます。
- Linux仮想マシンの設定で、[統合サービス] を選択します。
- [時刻の同期] が選択されていることを確認します。
注:
この方法はVMwareおよびXenServer(旧称Citrix Hypervisor)の場合とは異なります。VMwareおよびXenServerでは、NTPとの競合を避けるためにホストの時刻同期を無効にします。Hyper-Vの時刻同期は、NTPと共存し、NTPの時刻同期を補完することができます。
ESXおよびESXiでの時刻同期の修正
VMwareの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとハイパーバイザーで問題が発生します。これは、NTPとハイパーバイザーの両方がシステムの時間を同期しようとすることが原因です。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsをインストールした状態で準仮想化Linuxカーネルを実行している場合は、次の操作を行います。
- vSphere Clientを開きます。
- Linux仮想マシンの設定を編集します。
- [仮想マシンのプロパティ] ダイアログボックスで、[オプション] タブをクリックします。
- [VMware Tools] を選択します。
- [詳細] ボックスで、[ホストとゲスト時刻を同期] チェックボックスをオフにします。
手順3:Linux VMをWindowsドメインに追加
以下は、LinuxマシンをActive Directory(AD)ドメインに追加する方法です:
選択した方法の手順に従います。
注:
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗することがあります。
Samba Winbind
RHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2,の場合、次のコマンドを実行して、pam_winbindがルートディレクトリの所有権を変更しないようにします:
usermod -d /nonexistent nobody
<!--NeedCopy-->
次のようにして、必要なパッケージをインストールまたは更新します:
RHEL 9.4/9.3/9.2/8.xおよびRocky Linux 9.4/9.3/9.2/8.xの場合:
sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->
Amazon Linux 2の場合:
sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authconfig
<!--NeedCopy-->
マシンの起動時にWinbindデーモンを開始できるようにする
次のコマンドで、マシン起動時にWinbindデーモンが開始するように構成する必要があります:
sudo /sbin/chkconfig winbind on
<!--NeedCopy-->
Winbind認証の構成
次のようにして、Winbindを使用したKerberos認証用にマシンを構成します:
-
次のコマンドを実行します。
RHEL 9.4/9.3/9.2/8.xおよびRocky Linux 9.4/9.3/9.2/8.xの場合:
sudo authselect select winbind with-mkhomedir --force <!--NeedCopy-->
Amazon Linux 2の場合:
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 9.4/9.3/9.2/8.xおよびRocky Linux 9.4/9.3/9.2/8.xの場合のみ)/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
Delivery Controllerに対する認証と登録には、Linux VDAにシステムのkeytabファイル/etc/krb5.keytabが必要です。前述のkerberosを使用した設定により、マシンが初めてドメインに参加するときに、Winbindによってシステムのkeytabファイルが強制的に作成されます。
Windowsドメインへの参加
ドメインコントローラーがアクセス可能で、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
Linux仮想マシンをWindowsドメインに追加するには、次のコマンドを実行します。
sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->
ヒント:
Amazon Linux 2で実行されているLinux仮想マシンの場合は、次のコマンドを使用してWindowsドメインに追加することもできます:
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 systemctl restart winbind
<!--NeedCopy-->
ヒント:
マシンがドメインに参加済みの場合にのみ、
winbind
デーモンは実行を続けます。
/etc/krb5.conf を開いて、[libdefaults]セクションで次の設定をKEYRINGからFILEタイプに変更します:
default_ccache_name = FILE:/tmp/krb5cc_%{uid}
RHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2の場合、次のコマンドを実行してWinbindでSELinuxの問題を解決します:
ausearch -c 'winbindd' --raw | audit2allow -M my-winbindd -p /etc/selinux/targeted/policy/policy.*
semodule -X 300 -i my-winbindd.pp
<!--NeedCopy-->
ドメインメンバーシップの確認
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-->
次のコマンドで、Kerberos資格情報キャッシュのチケットが有効で、期限切れではないことを確認します:
klist
<!--NeedCopy-->
次のコマンドで、セッションを終了します。
exit
<!--NeedCopy-->
GnomeコンソールまたはKDEコンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順6:Linux VDAのインストール」に進みます。
Quest Authentication Services
ドメインコントローラーでのQuestの構成
次の操作は、QuestソフトウェアをActive Directoryドメインコントローラーにインストールし、構成していることと、管理者特権が付与され、Active Directoryにコンピューターオブジェクトを作成できることを前提としています。
Linux VDAマシンにドメインユーザーがログオンできるようにする
Linux VDAマシンでHDXセッションを確立する必要がある各ドメインユーザーに対して、次の操作を行います。
- [Active Directoryユーザーとコンピューター]管理コンソールで、目的のユーザーアカウントのActive Directoryユーザーのプロパティを開きます。
- [Unixアカウント] タブを選択します。
- [Unix対応] チェックボックスをオンにします。
- [プライマリGID番号] を、実際のドメインユーザーグループのグループIDに設定します。
注:
この手順は、ドメインユーザーがコンソール、RDP、SSH、またはその他のリモート処理プロトコルを使用してログオンできるように設定する場合も同じです。
Linux VDAでのQuestの構成
SELinuxポリシー適用の回避策
デフォルトのRHEL環境では、SELinuxが完全に適用されています。この適用により、Questが使用するUnixドメインソケットのIPCのメカニズムに干渉し、ドメインユーザーのログオンを妨げます。
この問題を回避するための便利な方法は、SELinuxの無効化です。ルートユーザーとして、/etc/selinux/config を編集し、SELinux設定を次のとおりに変更します:
SELINUX=permissive
この変更にはマシンの再起動が必要です:
reboot
<!--NeedCopy-->
重要:
この設定は注意して使用してください。SELinuxポリシーの適用を無効にした後に再度有効にすると、ルートユーザーやその他のローカルユーザーであっても、完全にロックアウトされてしまう可能性があります。
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など)です。
ドメインに追加後、Linuxマシンを再起動します。
ドメインメンバーシップの確認
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
SSSDを使用している場合は、このセクションの指示に従ってください。このセクションでは、Linux VDAマシンのWindowsドメインへの参加手順、およびKerberos認証の構成について説明します。
SSSDをRHELでセットアップするには、次の作業を行います:
- ドメインに参加してホストのkeytabを作成
- SSSDのセットアップ
- SSSDの有効化
- Kerberos構成の確認
- ユーザー認証の確認
ドメインに参加してホストのkeytabを作成
SSSDでは、ドメイン参加とシステムのkeytabファイルの管理に関するActive Directoryのクライアント機能が提供されていません。代わりにadcli、realmd、またはSambaを使用できます。
このセクションでは、Amazon Linux 2の場合のSambaのアプローチと、RHEL 8.x/9.xとRocky Linux 8.x/9.xの場合のadcli
のアプローチについて説明します。realmdに関しては、RHELのドキュメントを参照してください。SSSDを構成する前に、以下の手順に従う必要があります。
-
Samba(Amazon Linux 2):
次のようにして、必要なパッケージをインストールまたは更新します:
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名です。
注:
この記事の設定は、単一ドメイン、単一フォレストモデルを対象としています。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はコンピューターをドメインに追加する権限を持つドメインユーザーです。
-
Adcli(RHEL 9.4/9.3/9.2/8.xおよびRocky Linux 9.4/9.3/9.2/8.x):
次のようにして、必要なパッケージをインストールまたは更新します:
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 9.4/9.3/9.2/8.xおよびRocky Linux 9.4/9.3/9.2/8.xのみ) /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
ad.example.com と server.ad.example.com を対応する値で置き換えます。詳しくは、「sssd-ad(5) - Linux man page」を参照してください。
ファイルの所有権およびアクセス権をsssd.confで設定します:
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
SSSDの有効化
RHEL 9.4/9.3/9.2/8.xおよびRocky Linux 9.4/9.3/9.2/8.xの場合:
SSSDを有効にするには、次のコマンドを実行します:
sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->
Amazon Linux 2の場合:
authconfigを使用してSSSDを有効にします。oddjob-mkhomedir をインストールして、このホームディレクトリの作成機能がSELinuxに対応していることを確認します:
authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
sudo systemctl start sssd
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-->
ドメイン参加の確認後、「手順6:Linux VDAのインストール」に進みます。
PBIS
必要なPBISパッケージをダウンロードする
wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
PBISインストールスクリプトを実行可能にする
chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
PBISインストールスクリプトを実行する
sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Windowsドメインへの参加
ドメインコントローラーがアクセス可能で、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です:
/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
userは、コンピューターをActive Directoryドメインに追加する権限を持つドメインユーザーです。domain-nameは、ドメインのDNS名(example.comなど)です。
注: Bashをデフォルトのシェルとして設定するには、/opt/pbis/bin/configLoginShellTemplate/bin/bashコマンドを実行します。
ドメインメンバーシップの確認
Delivery Controllerを使用するには、すべてのVDAマシン(WindowsとLinux VDA)でActive Directoryにコンピューターオブジェクトが必要です。PBISによって追加されたLinuxマシンがドメインに存在することを確認するには、次のコマンドを実行します:
/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->
マシンがドメインに参加している場合、このコマンドは現在のADドメインとOUの情報を返します。参加していない場合は、ホスト名だけが表示されます。
ユーザー認証の確認
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をインストールする
Linux VDAをインストールまたはアップグレードする前に、サポートされているすべてのLinuxディストリビューションに、.NETランタイムに加えて.ASP.NET Coreランタイムをインストールする必要があります。Amazon Linux 2にはバージョン6が必要です。他のディストリビューションにはバージョン8が必要です。
Linuxディストリビューションに必要な.NETバージョンが含まれている場合は、組み込みフィードからインストールします。それ以外の場合は、Microsoftパッケージフィードから.NETをインストールします。詳しくは、https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managersを参照してください。
.NETのインストール後、which dotnetコマンドを実行してランタイムパスを特定します。
コマンド出力に基づいて、.NETランタイムのバイナリパスを設定します。たとえば、コマンド出力が/aa/bb/dotnetの場合、/aa/bbを.NETバイナリパスとして使用します。
手順5:Linux VDAパッケージのダウンロード
- Citrix Virtual Apps and Desktopsのダウンロードページにアクセスします。
- 適切なバージョンのCitrix Virtual Apps and Desktopsを展開します。
-
Componentsを展開してLinux VDAを見つけます。例:
-
Linux VDAのリンクをクリックして、Linux VDAのダウンロードファイルにアクセスします。
-
使用中のLinuxディストリビューションに対応したLinux VDAパッケージをダウンロードします。
-
Linux VDAパッケージの整合性を検証するために使用できるGPG公開キーをダウンロードします。例:
Linux VDAパッケージの整合性を確認するには、次のコマンドを実行して公開キーをRPMデータベースにインポートし、パッケージの整合性を確認します:
rpmkeys --import <path to the public key> rpm --checksig --verbose <path to the Linux VDA package> <!--NeedCopy-->
手順6:Linux VDAのインストール
新規インストールを実行することも、既存のインストールをアップグレードすることもできます。Linux VDAは、最新バージョンからのアップグレードをサポートしています。たとえば、Linux VDAを2308から2311に、および1912 LTSRから2203 LTSRにアップグレードできます。
手順6a:新規インストールを実行する
-
(オプション)古いバージョンのアンインストール
最新の2バージョンおよびLTSRリリース以外の古いバージョンのLinux VDAがインストールされている場合は、それをアンインストールしてから新しいバージョンをインストールする必要があります。
-
次のコマンドで、Linux VDAサービスを停止します:
sudo systemctl stop ctxvda sudo systemctl stop ctxhdx <!--NeedCopy-->
注:
ctxvdaおよびctxhdxサービスを停止する前に、systemctl stop ctxmonitordコマンドを実行して監視サービスデーモンを停止します。これを実行しない場合、監視サービスデーモンは停止したサービスを再起動します。
-
次のコマンドで、パッケージをアンインストールします:
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
注:
コマンドを実行するには、フルパスが必要です。代わりに、システムパスに/opt/Citrix/VDA/sbinおよび/opt/Citrix/VDA/binを追加することもできます。
-
-
Linux VDAパッケージのダウンロード
Citrix Virtual Apps and Desktopsのダウンロードページにアクセスします。適切なバージョンのCitrix Virtual Apps and Desktopsを展開し、Componentsをクリックして、使用中のLinuxディストリビューションに対応するLinux VDAパッケージをダウンロードします。
-
Linux VDAのインストール
注:
-
RHELおよびRocky Linuxの場合、EPELリポジトリを先にインストールしておかないと、Linux VDAを正常にインストールできません。EPELのインストール方法については、https://docs.fedoraproject.org/en-US/epel/の説明を参照してください。
-
Linux VDAをRHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2にインストールする前に、libsepolパッケージをバージョン3.4以降に更新します。
-
Yum
を使用してLinux VDAソフトウェアをインストールします:Amazon Linux 2の場合:
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm <!--NeedCopy-->
RHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2の場合:
sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm <!--NeedCopy-->
RHEL 8.xおよびRocky Linux 8.xの場合:
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm <!--NeedCopy-->
-
RPM Package Managerを使用して、Linux VDAソフトウェアをインストールします。その前に、次の依存関係を解決する必要があります。
Amazon Linux 2の場合:
sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm <!--NeedCopy-->
RHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2の場合:
sudo rpm -i XenDesktopVDA-<version>.el9_x.x86_64.rpm <!--NeedCopy-->
RHEL 8.xおよびRocky Linux 8.xの場合:
sudo rpm -i XenDesktopVDA-<version>.el8_x.x86_64.rpm <!--NeedCopy-->
RPM依存関係一覧( RHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2の場合):
gtk2 >= 2.24.33 java-11-openjdk >= 11 tzdata-java >= 2022 ImageMagick >= 6.9 firewalld >= 0.6.3 policycoreutils-python-utils >= 2.8 python3-policycoreutils >= 2.8 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 pam >= 1.3.1 util-linux >= 2.32.1 util-linux-user >= 2.32.1 xorg-x11-utils >= 7.5 bash >= 4.3 findutils >= 4.6 gawk >= 4.2 sed >= 4.5 cups >= 1.6.0 cups-filters >= 1.20.0 ghostscript >= 9.25 libxml2 >= 2.9 libmspack >= 0.7 ibus >= 1.5 nss-tools >= 3.44.0 chkconfig >= 1.20 cyrus-sasl-gssapi >= 2.1 python3 >= 3.6~ qt5-qtbase >= 5.5~ qt5-qtbase-gui >= 5.5~ qrencode-libs >= 3.4.4 imlib2 >= 1.4.9 fuse-libs >= 2.9 pulseaudio-utils >= 15.0 <!--NeedCopy-->
RPM依存関係一覧(RHEL 8.xおよびRocky Linux 8.xの場合):
java-11-openjdk >= 11 icoutils >= 0.32 firewalld >= 0.6.3 policycoreutils-python >= 2.8.9 policycoreutils-python-utils >= 2.8 python3-policycoreutils >= 2.8 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 pam >= 1.3.1 util-linux >= 2.32.1 util-linux-user >= 2.32.1 xorg-x11-utils >= 7.5 bash >= 4.3 findutils >= 4.6 gawk >= 4.2 sed >= 4.5 cups >= 1.6.0 foomatic-filters >= 4.0.9 cups-filters >= 1.20.0 ghostscript >= 9.25 libxml2 >= 2.9 libmspack >= 0.7 krb5-workstation >= 1.13 ibus >= 1.5 nss-tools >= 3.44.0 gperftools-libs >= 2.4 cyrus-sasl-gssapi >= 2.1 python3 >= 3.6~ qt5-qtbase >= 5.5~ qt5-qtbase-gui >= 5.5~ qrencode-libs >= 3.4.4 imlib2 >= 1.4.9 <!--NeedCopy-->
RPM依存関係一覧(Amazon Linux 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 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 libxml2 >= 2.9 libmspack >= 0.5 ibus >= 1.5 cyrus-sasl-gssapi >= 2.1 gperftools-libs >= 2.4 nss-tools >= 3.44.0 qt5-qtbase >= 5.5~ qrencode-libs >= 3.4.1 imlib2 >= 1.4.5 <!--NeedCopy-->
注:
このバージョンのLinux VDAでサポートされているLinuxディストリビューションとXorgのバージョンについては、「システム要件」を参照してください。
-
手順6b:既存のインストールをアップグレードする(オプション)
Linux VDAは、最新バージョンからのアップグレードをサポートしています。たとえば、Linux VDAを2308から2311に、および1912 LTSRから2203 LTSRにアップグレードできます。
Amazon Linux 2、RHEL、Rocky Linuxディストリビューションの場合:
sudo yum -y localinstall <PATH>/<Linux VDA RPM>
<!--NeedCopy-->
注:
既存のインストールをアップグレードすると、/etc/xdlにある構成ファイルが上書きされます。アップグレードを実行する前に、必ずファイルをバックアップしてください。
- Linux VDAをRHEL 9.4/9.3/9.2およびRocky Linux 9.4/9.3/9.2でアップグレードする前に、libsepolパッケージをバージョン3.4以降に更新します。
2407リリース以降、Linux VDAは、アップグレード中に構成ファイルを処理するために、パッケージマネージャーrpmまたはdpkgに委任します。以下では、rpmとdpkgが構成ファイルの変更でどのように機能するかについて説明しています:
rpm:デフォルトでは、ローカルバージョンが保持され、パッケージから新しいバージョンが.rpmnew拡張子で保存されます。
dpkg:どのように続行するかを選択するよう対話形式で促します。ローカル構成ファイルを保持し、新しいパッケージバージョンを.dpkg-newまたは.dpkg-distとして保存しながらLinux VDAを自動アップグレードするには、次のコマンドを使用します:
dpkg --force-confold -i package.deb # Always keep your version, then save new package's version as *.dpkg-new or *.dpkg-dist <!--NeedCopy-->
- ソフトウェアをアップグレードした後、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ドライバーをインストールして構成するには、次の手順を実行します:
- ゲストVMがシャットダウンされていることを確認します。
- XenCenterで、GPUをVMに割り当てます。
- 仮想マシンを起動します。
-
NVIDIA GRIDドライバー用にVMを準備します:
yum install gcc yum install "kernel-devel-$(uname -r)" systemctl set-default multi-user.target <!--NeedCopy-->
- Red Hat Enterprise Linuxのドキュメントの手順に従って、NVIDIA GRIDドライバーをインストールします。
注:
GPUドライバーのインストール時は、すべての質問でデフォルト(「いいえ」)を選択してください。
重要:
GPUパススルーを有効にすると、XenCenterを利用してLinux仮想マシンにアクセスできなくなります。SSHを使用して接続します。
次のコマンドで、カードに適切な構成を設定します:
etc/X11/ctx-nvidia.sh
高い解像度やマルチモニター機能を利用するには、有効なNVIDIAライセンスが必要です。このライセンスを申請するには、『GRID Licensing Guide.pdf - DU-07757-001 September 2015』の製品ドキュメントの指示に従ってください。
手順8:Linux VDAの構成
注:
ランタイム環境をセットアップする前に、en_US.UTF-8ロケールがインストールされていることを確認します。OSにこのロケールがない場合は、sudo locale-gen en_US.UTF-8コマンドを実行します。Debianの場合は、# en_US.UTF-8 UTF-8行のコメントを解除して/etc/locale.genファイルを編集してから、sudo locale-genコマンドを実行します。
パッケージのインストール後、ctxsetup.shスクリプトを実行して、Linux VDAを構成する必要があります。このスクリプトは、変更を行う前に環境を確認し、すべての依存コンポーネントがインストールされていることが確認されます。必要に応じて、いつでもこのスクリプトを再実行して設定を変更できます。
このスクリプトは、手動で質問に回答しながら、または事前に構成した回答を使用して自動で実行できます。続行する前に、次のコマンドを使用してこのスクリプトのヘルプを確認します:
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help
<!--NeedCopy-->
質問に回答する構成
次のようにして、質問に回答する手動構成を実行します:
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
自動化された構成
インストールを自動化するために、環境変数を使用して、セットアップスクリプトで必要となるオプションを指定できます。必要な変数がすべて指定されていると、スクリプトによってユーザーに情報の入力を求めるメッセージが表示されることがなくなります。
サポートされる環境変数には次のようなものがあります:
-
CTX_XDL_NON_DOMAIN_JOINED=’y|n’ – マシンをドメインに参加させるかどうか。デフォルト値は’n’です。ドメイン参加済みシナリオの場合は’n’に設定します。
-
CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’– Linux VDAには、Delivery Controllerに対して認証するためにKerberos構成設定が必要です。Kerberos構成は、システムにインストールおよび構成済みのActive Directory統合ツールから指定します。
-
CTX_XDL_DDC_LIST=’<list-ddc-fqdns>’ - Linux VDAには、Delivery Controllerの登録に使用するDelivery Controllerの、完全修飾ドメイン名(FQDN)のスペース区切りの一覧が必要です。1つまたは複数の完全修飾ドメイン名またはCNAMEを指定する必要があります。
-
CTX_XDL_VDI_MODE=’y|n’ – 専用デスクトップ配信モデル(VDI)またはホストされる共有デスクトップ配信モデルのどちらとしてマシンを構成するかを決定します。HDX 3D Pro環境の場合は、値を ‘y’ に設定します。
-
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_START_SERVICE = ‘y|n’ - 構成の完了時にLinux VDAサービスが開始されるようにするかどうかを指定します。
-
CTX_XDL_REGISTER_SERVICE = ‘y|n’ - Linux Virtual Desktopサービスは、マシンの起動後に開始します。
-
CTX_XDL_ADD_FIREWALL_RULES = ‘y|n’ - Linux VDAサービスでは、ネットワーク受信接続がシステムのファイアウォールの通過を許可されている必要があります。Linux Virtual Desktop用に、システムのファイアウォールの必要なポート(デフォルトではポート80およびポート1494)を自動で開放できます。
-
CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/kde/mate/xfce/’<none>‘ - セッションで使用するGNOME、GNOMEクラシック、KDE、MATE、またはXfceデスクトップ環境を指定します。‘<none>‘に設定すると、VDAで構成されているデフォルトのデスクトップが使用されます。
コマンドを実行したり、システムトレイを使用したりして、デスクトップ環境を切り替えることもできます。 詳しくは、「デスクトップ切り替えコマンド」および「システムトレイ」を参照してください。
-
CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime – 新しいブローカーエージェントサービス(ctxvda)をサポートするための.NETをインストールするパス。デフォルトのパスは‘/usr/bin’です。
-
CTX_XDL_VDA_PORT=port-number - Linux VDAは、TCP/IPポート経由でDelivery Controllerと通信します。
-
CTX_XDL_SITE_NAME =<dns-name> - Linux VDAは、DNSを使用してLDAPサーバーを検出します。DNSの検索結果をローカルサイトに制限するには、DNSサイト名を指定します。不要な場合は、‘<none>‘に設定します。
-
CTX_XDL_LDAP_LIST=’<list-ldap-servers>’ - Linux VDAは、DNSを照会してLDAPサーバーを検出します。DNSがLDAPサービスレコードを提供できない場合は、LDAPのFQDNおよびLDAPポートのスペース区切りの一覧を指定できます。例:「ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268」。Active Directoryフォレストでより高速なLDAPクエリを有効にするには、ドメインコントローラーで [グローバルカタログ] を有効にし、関連するLDAPポート番号で3268を指定します。この変数は、デフォルトでは‘<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_SUPPORT_DDC_AS_CNAME=’y|n’ - Linux VDAでは、DNS CNAMEレコードを使用して、Delivery Controller名を指定することができます。
次のようにして、環境変数を設定し、構成スクリプトを実行します:
export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=sssd|winbind|centrify|pbis|quest
export CTX_XDL_DDC_LIST='<list-ddc-fqdns>'
export CTX_XDL_VDI_MODE='y|n'
export CTX_XDL_HDX_3D_PRO='y|n'
export CTX_XDL_START_SERVICE='y|n'
export CTX_XDL_REGISTER_SERVICE='y|n'
export CTX_XDL_ADD_FIREWALL_RULES='y|n'
export CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|xfce|'<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>'
export CTX_XDL_VDA_PORT='<port-number>'
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_SUPPORT_DDC_AS_CNAME='y|n'
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->
sudoコマンドに-Eオプションを指定して実行し、作成する新しいシェルに既存の環境変数を渡します。最初の行として #!/bin/bash を記述し、前述のコマンドからなるシェルスクリプトファイルを作成することをお勧めします。
または、次のようにして、1つのコマンドですべてのパラメーターを指定することができます:
sudo CTX_XDL_NON_DOMAIN_JOINED='n' \
CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest \
CTX_XDL_DDC_LIST='<list-ddc-fqdns>' \
CTX_XDL_VDI_MODE='y|n' \
CTX_XDL_HDX_3D_PRO='y|n' \
CTX_XDL_START_SERVICE='y|n' \
CTX_XDL_REGISTER_SERVICE='y|n' \
CTX_XDL_ADD_FIREWALL_RULES='y|n' \
CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|xfce|'<none>' \
CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>' \
CTX_XDL_VDA_PORT='<port-number>' \
CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>' \
CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>' \
CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>' \
CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n' \
/opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--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の実行
sudo /opt/Citrix/VDA/bin/xdping
を実行して、Linux VDA環境での一般的な構成の問題を確認します。詳しくは、「XDPing」を参照してください。
手順10:Linux VDAの実行
ctxsetup.sh スクリプトを使用してLinux VDAを構成したら、次のコマンドを使用してLinux VDAを制御します。
Linux VDAの起動:
Linux VDAサービスを起動するには、次のコマンドを実行します:
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda
<!--NeedCopy-->
Linux VDAの停止:
Linux VDAサービスを停止するには、次のコマンドを実行します:
sudo systemctl stop ctxvda
sudo systemctl stop ctxhdx
<!--NeedCopy-->
注:
ctxvdaおよびctxhdxサービスを停止する前に、systemctl stop ctxmonitordコマンドを実行して監視サービスデーモンを停止します。これを実行しない場合、監視サービスデーモンは停止したサービスを再起動します。
Linux VDAの再起動:
Linux VDAサービスを再起動するには、次のコマンドを実行します:
sudo systemctl stop ctxvda
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda
<!--NeedCopy-->
Linux VDAの状態の確認:
Linux VDAサービスの実行状態を確認するには、次のコマンドを実行します:
sudo systemctl status ctxvda
sudo systemctl status ctxhdx
<!--NeedCopy-->
手順11:マシンカタログの作成
マシンカタログを作成し、Linux VDAマシンを追加する手順は、従来のWindows VDAでの方法と似ています。このタスクを完了する方法の説明について詳しくは、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
次のように、Linux VDAマシンを含むマシンカタログの作成にはいくつかの制約があるため、Windows VDAマシンのマシンカタログの作成手順と異なる点があります:
- オペレーティングシステムには、次を選択します:
- ホストされる共有デスクトップ配信モデルの場合、マルチセッションOSオプション
- VDI専用デスクトップ配信モデルの場合、シングルセッションOSオプション。
- 同じマシンカタログで、Linux VDAマシンとWindows VDAマシンを混在させないでください。
注:
Citrix Studioの以前のバージョンは、「Linux OS」という概念をサポートしていませんでした。ただし、[WindowsサーバーOS] オプションまたは [サーバーOS] オプションを選択すると、同等のホストされる共有デスクトップ配信モデルが暗黙的に選択されます。[WindowsデスクトップOS] オプションまたは [デスクトップOS] オプションを選択すると、マシンごとに単一ユーザーの配信モデルが暗黙的に選択されます。
ヒント:
削除されたマシンをActive Directoryドメインに再度追加する場合は、そのマシンをマシンカタログから削除してから再度追加する必要があります。
手順12:デリバリーグループの作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加する手順は、Windows VDAマシンの場合とほとんど同じです。このタスクを完了する方法の説明について詳しくは、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合は、次の制約があります:
- 選択するADユーザーおよびグループを、Linux VDAマシンにログオンするように適切に構成しておきます。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- Windowsマシンを含むマシンカタログをデリバリーグループで混在させないでください。
重要:
アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、同一マシンへのデスクトップおよびアプリの配信は、Linux VDAでサポートされていません。
マシンカタログおよびデリバリーグループの作成方法について詳しくは、「Citrix Virtual Apps and Desktops 7 2407」を参照してください。