SUSE に Linux VDA を手動でインストール
重要:
新規インストールの場合、迅速なインストールには 簡易インストール の使用をお勧めします。簡易インストールは、時間と労力を節約し、この記事で詳述されている手動インストールよりもエラーが発生しにくいです。
ステップ 1:構成情報と Linux マシンの準備
ステップ 1a:YaST ツールの起動
SUSE Linux Enterprise の YaST ツールは、オペレーティングシステムのあらゆる側面を構成するために使用されます。
テキストベースの YaST ツールを起動するには:
su -
yast
<!--NeedCopy-->
UI ベースの YaST ツールを起動するには:
su -
yast2 &
<!--NeedCopy-->
- ### ステップ 1b:ネットワークの構成
以下のセクションでは、Linux VDA で使用されるさまざまなネットワーク設定とサービスの構成に関する情報を提供します。ネットワークの構成は、Network Manager などの他の方法ではなく、YaST ツールを介して実行されます。これらの手順は、UI ベースの YaST ツールを使用することに基づいています。テキストベースの YaST ツールも使用できますが、ここでは文書化されていない異なるナビゲーション方法があります。
ホスト名とドメインネームシステム (DNS) の構成
- UI ベースの YaST ツールを起動します。
- System を選択し、次に Network Settings を選択します。
- Hostname/DNS タブを開きます。
- Set Hostname via DHCP のオプションで no を選択します。
- Modify DNS Configuration のオプションで Use Custom Policy を選択します。
-
ネットワーク設定を反映するように以下を編集します。
- Static Hostname – マシンの DNS ホスト名を追加します。
- Name Server – DNS サーバーの IP アドレスを追加します。通常、これは AD ドメインコントローラーの IP アドレスです。
- Domain Search List – DNS ドメイン名を追加します。
-
/etc/hostsファイルの次の行を、最初の 2 つのエントリとして FQDN とホスト名を含むように変更します。127.0.0.1 <VDA の FQDN> <VDA のホスト名> localhost
注:
Linux VDA は現在、NetBIOS 名の切り捨てをサポートしていません。したがって、ホスト名は 15 文字を超えてはなりません。 ヒント:
a–z、A–Z、0–9、およびハイフン (-) の文字のみを使用してください。アンダースコア (_)、スペース、およびその他の記号は避けてください。ホスト名を数字で始めたり、ハイフンで終わらせたりしないでください。このルールは Delivery Controller のホスト名にも適用されます。
ホスト名の確認
ホスト名が正しく設定されていることを確認します。
hostname
<!--NeedCopy-->
このコマンドは、マシンのホスト名のみを返し、完全修飾ドメイン名 (FQDN) は返しません。
FQDN が正しく設定されていることを確認します。
hostname -f
<!--NeedCopy-->
このコマンドは、マシンの FQDN を返します。
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
FQDN を解決できない場合、またはこれらのマシンのいずれかに ping できない場合は、続行する前に手順を確認してください。
ステップ 1c:NTP サービスの構成
VDA、Delivery Controller、およびドメインコントローラー間で正確なクロック同期を維持することが重要です。Linux VDA を仮想マシン (VM) としてホストすると、クロックずれの問題が発生する可能性があります。このため、リモート NTP サービスを使用して時刻を維持することが推奨されます。デフォルトの NTP 設定にいくつかの変更が必要になる場合があります。
SUSE 15.4 の場合:
- UI ベースの YaST ツールを起動します。
- Network Services を選択し、次に NTP Configuration を選択します。
- Start NTP Daemon セクションで、Now and on Boot を選択します。
- Configuration Source で Dynamic を選択します。
- 必要に応じて NTP サーバーを追加します。NTP サービスは通常、Active Directory ドメインコントローラーでホストされます。
-
/etc/chrony.conf に次の行が存在する場合は、削除またはコメントアウトします。
include /etc/chrony.d/*.confchrony.conf を編集した後、
chronydサービスを再起動します。sudo systemctl restart chronyd.service <!--NeedCopy-->
ステップ 1d:Linux VDA 依存パッケージのインストール
SUSE Linux Enterprise 用の Linux VDA ソフトウェアは、以下のパッケージに依存しています。
- OpenJDK 11
- Open Motif Runtime Environment 2.3.1 以降
- Cups 1.6.0 以降
- ImageMagick 6.8 以降
リポジトリの追加
ImageMagick を除くほとんどの必要なパッケージは、公式リポジトリから入手できます。ImageMagick パッケージを入手するには、YaST または次のコマンドを使用して sle-module-desktop-applications リポジトリを有効にします。
SUSEConnect -p sle-module-desktop-applications/<version number>/x86_64
Kerberos クライアントのインストール
Linux VDA と Delivery Controller 間の相互認証のために Kerberos クライアントをインストールします。
sudo zypper install krb5-client
<!--NeedCopy-->
Kerberos クライアントの構成は、使用される Active Directory 統合アプローチによって異なります。以下の説明を参照してください。
OpenJDK 11 のインストール
Linux VDA には OpenJDK 11 が必要です。
OpenJDK 11 をインストールするには、次のコマンドを実行します。
sudo zypper install java-11-openjdk
<!--NeedCopy-->
データベースのインストールと指定
Linux VDAパッケージのインストール後、/etc/xdl/db.confを編集することで、使用するSQLiteまたはPostgreSQLを指定できます。手動インストールの場合は、それらを指定する前にSQLiteとPostgreSQLを手動でインストールする必要があります。
このセクションでは、PostgreSQLおよびSQLiteデータベースのインストール方法と、使用するデータベースの指定方法について説明します。
注記:
SQLiteはVDIモードでのみ使用することをお勧めします。
PostgreSQLのインストール
Postgresqlをインストールするには、次のコマンドを実行します。
sudo zypper install postgresql-server
sudo zypper install postgresql-jdbc
<!--NeedCopy-->
マシン起動時または即座にPostgreSQLを起動するには、それぞれ次のコマンドを実行します。
sudo systemctl enable postgresql
- sudo systemctl restart postgresql
<!--NeedCopy-->
SQLiteのインストール
SUSEの場合、SQLiteをインストールするには次のコマンドを実行します。
sudo zypper install sqlite3
<!--NeedCopy-->
使用するデータベースの指定
- SQLite、PostgreSQL、またはその両方をインストールした後、Linux VDAパッケージのインストール後に**/etc/xdl/db.conf**を編集することで、使用するデータベースを指定できます。これを行うには、次の手順を完了します。
- 1. **/opt/Citrix/VDA/sbin/ctxcleanup.sh**を実行します。新規インストールの場合は、この手順を省略します。
- 1. **/etc/xdl/db.conf**を編集して、使用するデータベースを指定します。
- ctxsetup.shを実行します。
注記:
/etc/xdl/db.confを使用して、PostgreSQLのポート番号を構成することもできます。
ステップ2: ハイパーバイザーの準備
サポートされているハイパーバイザー上でLinux VDAをVMとして実行する場合、いくつかの変更が必要です。使用しているハイパーバイザープラットフォームに基づいて、次の変更を行います。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を返します。
- 0 - 時刻同期機能が有効になっており、無効にする必要があります
- 1 - 時刻同期機能が無効になっており、それ以上の操作は不要です
/proc/sys/xen/independent_wallclockファイルが存在しない場合、以下の手順は不要です。
有効になっている場合、ファイルに1を書き込むことで時刻同期機能を無効にします。
sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
この変更を再起動後も永続的にするには、/etc/sysctl.confファイルを編集し、次の行を追加します。
xen.independent_wallclock = 1
これらの変更を確認するには、システムを再起動します。
reboot
<!--NeedCopy-->
再起動後、設定が正しいことを確認します。
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは値1を返します。
Microsoft Hyper-Vでの時刻同期の修正
Hyper-V Linux統合サービスがインストールされているLinux VMは、Hyper-Vの時刻同期機能を使用してホストオペレーティングシステムの時刻を使用できます。システムクロックが正確に保たれるように、NTPサービスと並行してこの機能を有効にします。
管理オペレーティングシステムから:
- Hyper-Vマネージャーコンソールを開きます
- Linux VMの設定で、統合サービスを選択します
- 時刻同期が選択されていることを確認します
注記:
このアプローチは、NTPとの競合を避けるためにホストの時刻同期が無効になっているVMwareおよびCitrix Hypervisorとは異なります。Hyper-Vの時刻同期は、NTPの時刻同期と共存し、補完することができます。
ESXおよびESXiでの時刻同期の修正
VMwareの時刻同期機能が有効になっている場合、各準仮想化Linux VM内でNTPとハイパーバイザーに関する問題が発生します。両方ともシステムクロックを同期しようとします。クロックが他のサーバーと同期しなくなるのを避けるため、各Linuxゲスト内のシステムクロックをNTPと同期させます。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsがインストールされた準仮想化Linuxカーネルを実行している場合:
- vSphere Clientを開きます
- Linux VMの設定を編集します
- 仮想マシンのプロパティダイアログで、オプションタブを開きます
- VMware Toolsを選択します
- 詳細設定ボックスで、ゲストの時刻をホストと同期のチェックを外します
ステップ3: Linux VMのWindowsドメインへの追加
LinuxマシンをActive Directory (AD) ドメインに追加するには、次の方法が利用可能です。
- [Samba Winbind](/ja-jp/linux-virtual-delivery-agent/2308/installation-overview/manual-installation-overview/suse.html#samba-winbind)
- [Centrify DirectControl](/ja-jp/linux-virtual-delivery-agent/2308/installation-overview/manual-installation-overview/suse.html#centrify-directcontrol)
選択した方法に基づいて指示に従ってください。
注記:
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗する場合があります。
Samba Winbind
Windowsドメインへの参加
ドメインコントローラーに到達可能であり、マシンをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
-
YaSTを起動し、ネットワークサービスを選択し、次にWindowsドメインメンバーシップを選択します。
-
以下の変更を行います。
- ドメインまたはワークグループをActive Directoryドメインの名前またはドメインコントローラーのIPアドレスに設定します。ドメイン名が大文字であることを確認してください。
-
Linux認証にSMB情報を使用をチェックします。
- ログイン時にホームディレクトリを作成をチェックします。
- SSHのシングルサインオンをチェックします。
- オフライン認証がチェックされていないことを確認します。このオプションはLinux VDAと互換性がありません。
-
OKをクリックします。いくつかのパッケージのインストールを求められた場合は、インストールをクリックします。
-
ドメインコントローラーが見つかると、ドメインに参加するかどうかを尋ねられます。はいをクリックします。
-
プロンプトが表示されたら、マシンをドメインに追加する権限を持つドメインユーザーの資格情報を入力し、OKをクリックします。
-
サービスを手動で再起動するか、マシンを再起動します。マシンの再起動をお勧めします。
su - reboot <!--NeedCopy-->
ドメインメンバーシップの確認
Delivery Controllerは、すべてのVDAマシン(WindowsおよびLinux VDA)がActive Directoryにコンピューターオブジェクトを持つことを要求します。
Sambaのnet adsコマンドを実行して、マシンがドメインに参加していることを確認します。
sudo net ads testjoin
<!--NeedCopy-->
追加のドメインおよびコンピューターオブジェクト情報を確認するには、次のコマンドを実行します。
sudo net ads info
<!--NeedCopy-->
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-->
id -uコマンドによって返されたuidに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_uid
<!--NeedCopy-->
ユーザーのKerberos資格情報キャッシュ内のチケットが有効で期限切れになっていないことを確認します。
klist
<!--NeedCopy-->
セッションを終了します。
exit
<!--NeedCopy-->
同様のテストは、GnomeまたはKDEコンソールに直接ログオンして実行できます。ドメイン参加の確認後、ステップ6: Linux VDAのインストールに進みます。
Quest認証サービス
ドメインコントローラーでのQuestの構成
ドメインコントローラーにQuestソフトウェアをインストールおよび構成済みであり、Active Directoryでコンピューターオブジェクトを作成するための管理者権限が付与されていると仮定します。
ドメインユーザーがLinux VDAマシンにログオンできるようにする
ドメインユーザーがLinux VDAマシンでHDX™セッションを確立できるようにするには:
- Active Directoryユーザーとコンピューター管理コンソールで、そのユーザーアカウントのActive Directoryユーザープロパティを開きます。
- Unixアカウントタブを選択します。
- Unix対応をチェックします。
- プライマリGID番号を実際のドメインユーザーグループのグループIDに設定します。
注記:
これらの手順は、コンソール、RDP、SSH、またはその他のリモートプロトコルを使用してログオンするドメインユーザーを設定する場合と同等です。
Linux VDAでのQuestの構成
VASデーモンの構成
Kerberosチケットの自動更新を有効にし、切断する必要があります。認証(オフラインログオン)は無効にする必要があります。
sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400
sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->
このコマンドは、更新間隔を9時間(32,400秒)に設定します。これは、デフォルトの10時間であるチケットの有効期間より1時間短いです。チケットの有効期間が短いシステムでは、このパラメーターをより低い値に設定してください。
PAMとNSSの構成
HDXおよびsu、ssh、RDPなどの他のサービスを介したドメインユーザーログオンを有効にするには、PAMとNSSを手動で構成します。
sudo /opt/quest/bin/vastool configure pam
sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->
Windowsドメインへの参加
Questのvastoolコマンドを使用して、LinuxマシンをActive Directoryドメインに参加させます。
sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->
ユーザーは、マシンをActive Directoryドメインに参加させる権限を持つ任意のドメインユーザーです。ドメイン名は、example.comなどのドメインのDNS名です。
ドメインメンバーシップの確認
Delivery Controllerでは、すべてのVDAマシン(Windows VDAおよび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エージェントがインストールされている状態で、Centrifyのadjoinコマンドを使用してLinuxマシンをActive Directoryドメインに参加させます。
sudo adjoin -w -V -u user domain-name
<!--NeedCopy-->
ユーザーは、マシンをActive Directoryドメインに参加させる権限を持つ任意のActive Directoryドメインユーザーです。ドメイン名は、Linuxマシンを参加させるドメインの名前です。
ドメインメンバーシップの確認
Delivery Controllerでは、すべてのVDAマシン(Windows VDAおよびLinux VDA)がActive Directory内にコンピューターオブジェクトを持つ必要があります。Centrifyに参加しているLinuxマシンがドメイン上にあることを確認するには、次のようにします。
sudo adinfo
<!--NeedCopy-->
Joined to domainの値が有効であり、CentrifyDCのmodeがconnectedを返すことを確認します。モードが開始状態のままになっている場合、Centrifyクライアントはサーバー接続または認証の問題を抱えています。
より包括的なシステムおよび診断情報は、以下を使用して利用できます。
adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->
さまざまなActive DirectoryおよびKerberosサービスへの接続をテストします。
adinfo --test
<!--NeedCopy-->
ドメイン参加の確認後、手順6:Linux VDAのインストールに進みます。
SSSD
SUSEでSSSDを使用している場合は、このセクションの手順に従ってください。このセクションには、Linux VDAマシンをWindowsドメインに参加させるための手順と、Kerberos認証を構成するためのガイダンスが含まれています。
SUSEでSSSDをセットアップするには、次の手順を完了します。
- ドメインへの参加とホストキータブの作成
- SSSD用のPAMの構成
- SSSDのセットアップ
- SSSDの有効化
- ドメインメンバーシップの確認
- Kerberos構成の確認
- ユーザー認証の確認
ドメインへの参加とホストキータブの作成
SSSDは、ドメインへの参加やシステムキータブファイルの管理のためのActive Directoryクライアント機能を提供しません。代わりにSambaアプローチを使用できます。SSSDを構成する前に、次の手順を完了してください。
-
Name Service Cache Daemon(NSCD)デーモンを停止して無効にします。
sudo systemctl stop nscd sudo systemctl disable nscd <!--NeedCopy--> -
ホスト名とChrony時刻同期を確認します。
hostname hostname -f chronyc traking <!--NeedCopy--> -
必要なパッケージをインストールまたは更新します。
sudo zypper install samba-client sssd-ad <!--NeedCopy--> -
ルートユーザーとして
/etc/krb5.confファイルを編集し、kinitユーティリティがターゲットドメインと通信できるようにします。[libdefaults]、[realms]、および[domain_realm]セクションに以下のエントリを追加します。注記:
KerberosはADインフラストラクチャに基づいて構成してください。以下の設定は、単一ドメイン、単一フォレストモデルを対象としています。
[libdefaults] dns_canonicalize_hostname = false rdns = false default_realm = REALM forwardable = true [realms] REALM = { kdc = fqdn-of-domain-controller default_domain = realm admin_server = fqdn-of-domain-controller } [domain_realm] .realm = REALM <!--NeedCopy-->realmは、example.comのようなKerberosレルム名です。REALMは、EXAMPLE.COMのような大文字のKerberosレルム名です。
-
ルートユーザーとして
/etc/samba/smb.confを編集し、netユーティリティがターゲットドメインと通信できるようにします。[global]セクションに以下のエントリを追加します。[global] workgroup = domain client signing = yes client use spnego = yes kerberos method = secrets and keytab realm = REALM security = ADS <!--NeedCopy-->domainは、EXAMPLEのようなActive Directoryドメインの短いNetBIOS名です。
-
/etc/nsswitch.confファイル内のpasswdおよびgroupエントリを変更し、ユーザーとグループを解決する際にSSSDを参照するようにします。
passwd: compat sss group: compat sss <!--NeedCopy-->
-
- 構成済みのKerberosクライアントを使用して、Administratorとしてターゲットドメインに認証します。
kinit administrator <!--NeedCopy-->
-
netユーティリティを使用して、システムをドメインに参加させ、システムキータブファイルを生成します。
net ads join osname="SUSE Linux Enterprise Server" osVersion=15 -U administrator <!--NeedCopy-->
SSSDのPAM構成
SSSDのPAMを構成する前に、必要なパッケージをインストールまたは更新します。
sudo zypper install sssd sssd-ad
<!--NeedCopy-->
SSSDを介したユーザー認証のためにPAMモジュールを構成し、ユーザーログオン用のホームディレクトリを作成します。
sudo pam-config --add --sss
sudo pam-config --add --mkhomedir
<!--NeedCopy-->
-
SSSDのセットアップ
-
- ルートユーザーとして
/etc/sssd/sssd.confを編集し、SSSDデーモンがターゲットドメインと通信できるようにします。sssd.conf構成の例(必要に応じて追加オプションを追加できます):
[sssd] config_file_version = 2 services = nss,pam domains = domain-dns-name [domain/domain-dns-name] id_provider = ad auth_provider = ad access_provider = ad ad_domain = domain-dns-name - ad_server = fqdn-of-domain-controller ldap_id_mapping = true ldap_schema = ad ### Kerberos settings - krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U ### Comment out if the users have the shell and home dir set on the AD side fallback_homedir = /home/%d/%u - default_shell = /bin/bash Uncomment and adjust if the default principal SHORTNAME$@REALM is not available ## ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM ad_gpo_access_control = permissive <!--NeedCopy-->domain-dns-nameは、example.comのようなDNSドメイン名です。
注記:
ldap_id_mappingは、SSSD自体がWindows SIDをUnix UIDにマッピングするようにtrueに設定されています。そうでない場合、Active DirectoryはPOSIX拡張機能を提供できる必要があります。ad_gpo_access_controlは、Linuxセッションでの無効なログオンエラーを防ぐためにpermissiveに設定されています。
sssd.confおよびsssd-adのmanページを参照してください。 - ルートユーザーとして
-
sssd.confのファイル所有権とパーミッションを設定します。sudo chmod 0600 /etc/sssd/sssd.conf <!--NeedCopy-->
SSSDの有効化
システム起動時にSSSDデーモンを有効にして開始するには、以下のコマンドを実行します。
sudo systemctl enable sssd
sudo systemctl start sssd
<!--NeedCopy-->
ドメインメンバーシップの確認
-
Sambaの
net adsコマンドを実行して、マシンがドメインに参加していることを確認します。sudo net ads testjoin <!--NeedCopy--> -
追加のドメインおよびコンピューターオブジェクト情報を確認するには、以下のコマンドを実行します。
sudo net ads info <!--NeedCopy-->
Kerberos構成の確認
システムキータブファイルが作成され、有効なキーが含まれていることを確認します。
sudo klist -ke
<!--NeedCopy-->
このコマンドは、プリンシパル名と暗号スイートのさまざまな組み合わせで利用可能なキーのリストを表示します。
これらのキーを使用してドメインコントローラーでマシンを認証するには、Kerberosのkinitコマンドを実行します。
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
マシン名とレルム名は大文字で指定する必要があります。ドル記号($)は、シェル置換を防ぐためにバックスラッシュ(\)でエスケープする必要があります。一部の環境では、DNSドメイン名がKerberosレルム名と異なる場合があります。レルム名が使用されていることを確認してください。このコマンドが成功した場合、出力は表示されません。
マシンアカウントのTGTチケットがキャッシュされていることを確認するには、以下を使用します。
sudo klist
<!--NeedCopy-->
ユーザー認証の確認
SSSDはデーモンとの認証を直接テストするためのコマンドラインツールを提供しておらず、PAMを介してのみ実行できます。
SSSD PAMモジュールが正しく構成されていることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用してLinux VDAにログオンします。
ssh localhost -l domain\\username
id -u
klist
exit
<!--NeedCopy-->
klistコマンドによって返されたKerberosチケットがそのユーザーに対して正しく、期限切れになっていないことを確認します。
rootユーザーとして、以前のid -uコマンドによって返されたUIDに対応するチケットキャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_uid
<!--NeedCopy-->
GnomeまたはKDEコンソールに直接ログオンすることで、同様のテストを実行できます。ドメイン参加の検証後、手順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-->
ドメインコントローラーに到達可能であり、ドメインにマシンを追加する権限を持つ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および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の適切なバージョンを展開します。
-
コンポーネントを展開して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 のインストール
ステップ 6a: 旧バージョンのアンインストール
以前の 2 つのバージョンおよび LTSR リリース以外の古いバージョンをインストールしている場合は、新しいバージョンをインストールする前にアンインストールしてください。
-
Linux VDA サービスを停止します。
sudo /sbin/service ctxvda stop sudo /sbin/service ctxhdx stop <!--NeedCopy-->注:
ctxvda および ctxhdx サービスを停止する前に、systemctl stop ctxmonitord コマンドを実行してモニターサービスデーモンを停止してください。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
-
パッケージをアンインストールします。
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
重要:
最新の 2 つのバージョンからのアップグレードがサポートされています。
注:
インストールされているコンポーネントは /opt/Citrix/VDA/ の下にあります。
コマンドを実行するには、フルパスが必要です。または、/opt/Citrix/VDA/sbin と /opt/Citrix/VDA/bin をシステムパスに追加することもできます。
ステップ 6b: Linux VDA のインストール
Zypper を使用して Linux VDA ソフトウェアをインストールします。
sudo zypper install XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
RPM パッケージマネージャーを使用して Linux VDA ソフトウェアをインストールします。
sudo rpm -i XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
ステップ 6c: Linux VDA のアップグレード (オプション)
既存のインストールを、以前の 2 つのバージョンおよび LTSR リリースからアップグレードできます。
注:
既存のインストールをアップグレードすると、/etc/xdl の下の構成ファイルが上書きされます。アップグレードを実行する前に、ファイルをバックアップしてください。
sudo rpm -U XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
SUSE 15 の RPM 依存関係リスト:
java-11-openjdk >= 11
ImageMagick >= 7.0
dbus-1 >= 1.12.2
dbus-1-x11 >= 1.12.2
xorg-x11 >= 7.6_1
libXpm4 >= 3.5.12
libXrandr2 >= 1.5.1
libXtst6 >= 1.2.3
pam >= 1.3.0
bash >= 4.4
findutils >= 4.6
gawk >= 4.2
sed >= 4.4
cups >= 2.2
cups-filters >= 1.25
libxml2-2 >= 2.9
libmspack0 >= 0.6
ibus >= 1.5
libtcmalloc4 >= 2.5
libcap-progs >= 2.26
mozilla-nss-tools >= 3.53.1
libpython3_6m1_0 >= 3.6~
libQt5Widgets5 >= 5.12
libqrencode4 >= 4.0.0
libImlib2-1 >= 1.4.10
<!--NeedCopy-->
重要:
アップグレード後、Linux VDA マシンを再起動してください。
ステップ 7: NVIDIA GRID ドライバーのインストール
HDX 3D Pro を有効にするには、ハイパーバイザーと VDA マシンに NVIDIA GRID ドライバーをインストールする必要があります。
特定のハイパーバイザーに NVIDIA GRID Virtual GPU Manager (ホストドライバー) をインストールおよび構成するには、次のガイドを参照してください。
NVIDIA GRID ゲスト VM ドライバーをインストールおよび構成するには、次の一般的な手順を実行します。
- ゲスト VM がシャットダウンされていることを確認します。
- ハイパーバイザーのコントロールパネルで、VM に GPU を割り当てます。
- VM を起動します。
- VM にゲスト VM ドライバーをインストールします。
ステップ 8: Linux VDA の構成
注:
ランタイム環境をセットアップする前に、en_US.UTF-8 ロケールが OS にインストールされていることを確認してください。ロケールが OS で利用できない場合は、sudo locale-gen en_US.UTF-8 コマンドを実行してください。Debian の場合は、/etc/locale.gen ファイルの # en_US.UTF-8 UTF-8 行のコメントを解除して編集し、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\_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 は、TCP/IP ポート (デフォルトではポート 80) を介して Delivery Controller と通信します。
- CTX_XDL_REGISTER_SERVICE=Y | N - Linux VDA サービスはマシンの起動後に開始されます。デフォルトでは Y に設定されています。
- CTX_XDL_ADD_FIREWALL_RULES=Y | N – Linux VDA サービスは、システムファイアウォールを介した受信ネットワーク接続を許可する必要があります。Linux VDA のシステムファイアウォールで必要なポート (デフォルトではポート 80 と 1494) を自動的に開くことができます。デフォルトでは Y に設定されています。
- CTX_XDL_AD_INTEGRATION=winbind | quest |centrify | sssd – Linux VDA は、Delivery Controller で認証するために Kerberos 構成設定を必要とします。Kerberos 構成は、システムにインストールおよび構成されている 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_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 ad2.mycompany.com:3268 ad3.mycompany.com:3268、または LDAPS を使用している場合は ad1.mycompany.com:636 ad2.mycompany.com:3269 ad3.mycompany.com:3269 です。Active Directory フォレスト内で LDAP クエリを高速化するには、ドメインコントローラーで Global Catalog を有効にし、関連する LDAP ポート番号を 3268 または LDAPS を使用している場合は 3269 として指定します。この変数はデフォルトで <none> に設定されています。
- CTX_XDL_SEARCH_BASE=search-base-set – Linux VDA は、Active Directory ドメインのルート (例: DC=mycompany,DC=com) に設定された検索ベースを介して LDAP を照会します。検索パフォーマンスを向上させるには、検索ベース (例: OU=VDI,DC=mycompany,DC=com) を指定できます。この変数はデフォルトで <none> に設定されています。
- CTX_XDL_FAS_LIST=’list-fas-servers’ – Federated Authentication Service (FAS) サーバーは、AD グループポリシーを介して構成されます。Linux VDA は AD グループポリシーをサポートしていませんが、代わりに FAS サーバーのセミコロン区切りリストを提供できます。シーケンスは AD グループポリシーで構成されているものと同じである必要があります。サーバーアドレスが削除された場合は、その空白を <none> テキスト文字列で埋め、サーバーアドレスの順序を変更しないでください。FAS サーバーと適切に通信するには、FAS サーバーで指定されているものと一致するポート番号を追加してください。例: CTX_XDL_FAS_LIST=’fas_server_1_url:port_number; fas_server_2_url: port_number; fas_server_3_url: port_number’。
-
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 に設定する必要があります。
ターゲットセッションユーザーのデスクトップ環境を変更するには、次の手順を実行します。
1. VDA上の **$HOME/<username\>** ディレクトリに `.xsession` ファイルを作成します。
1. `.xsession` ファイルを編集して、デスクトップ環境を指定します。
- **SUSE 15上のMATEデスクトップの場合**
MSESSION="$(type -p mate-session)"
if [ -n "$MSESSION" ]; then
exec mate-session
fi
- **SUSE 15上のGNOME Classicデスクトップの場合**
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
export GNOME_SHELL_SESSION_MODE=classic
exec gnome-session --session=gnome-classic
fi
- **SUSE 15上のGNOMEデスクトップの場合**
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
exec gnome-session
fi
1. ターゲットセッションユーザーと700ファイル権限を共有します。
バージョン2209以降、セッションユーザーはデスクトップ環境をカスタマイズできます。この機能を有効にするには、VDAに切り替え可能なデスクトップ環境を事前にインストールする必要があります。詳細については、「[セッションユーザーによるカスタムデスクトップ環境](/ja-jp/linux-virtual-delivery-agent/2308/configure/session/custom-desktop-environments-by-session-users.html)」を参照してください。
-
**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=winbind | quest |centrify | sssd
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 --silent
<!--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=winbind | quest |centrify | sssd \
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 --silent
<!--NeedCopy-->
構成変更の削除
シナリオによっては、Linux VDAパッケージをアンインストールせずに、ctxsetup.shスクリプトによって行われた構成変更を削除する必要がある場合があります。
続行する前に、このスクリプトに関するヘルプを確認してください。
sudo /usr/local/sbin/ctxcleanup.sh --help
<!--NeedCopy-->
構成変更を削除するには:
sudo /usr/local/sbin/ctxcleanup.sh
<!--NeedCopy-->
重要:
このスクリプトは、データベースからすべての構成データを削除し、Linux VDAを動作不能にします。
構成ログ
ctxsetup.shおよびctxcleanup.shスクリプトは、コンソールにエラーを表示し、追加情報は構成ログファイルに書き込まれます。
/tmp/xdl.configure.log
変更を有効にするには、Linux VDAサービスを再起動します。
ステップ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:マシンカタログの作成
マシンカタログを作成し、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ドメインから削除して再参加させる場合、そのマシンをマシンカタログから削除して再度追加する必要があります。
ステップ12:デリバリーグループの作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加するプロセスは、Windows VDAマシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。
- 選択したADユーザーとグループが、Linux VDAマシンにログオンするように適切に構成されていることを確認してください。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- デリバリーグループとWindowsマシンを含むマシンカタログを混在させないでください。
重要:
アプリケーションの公開は、Linux VDAバージョン1.4以降でサポートされています。ただし、Linux VDAは、デスクトップとアプリを同じマシンに配信することをサポートしていません。
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2308」を参照してください。