製品ドキュメント

Linux Virtual Delivery Agent

PDFを表示

SUSE に Linux VDA を手動でインストール

April 20, 2026

寄稿者:

C C

重要:

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

手順 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 ツールを起動します。
［システム］、次に［ネットワーク設定］を選択します。
SLED 12 のみ: ［グローバルオプション］タブで、［ネットワーク設定方法］を［Wicked Service］に変更します。
［ホスト名/DNS］タブを開きます。
［ループバック IP にホスト名を割り当てる］を選択します。
［DHCP 経由でホスト名を変更する］のチェックを外します。
［ループバック IP にホスト名を割り当てる］を選択します。
［DNS 構成の変更］で［カスタムポリシーを使用する］オプションを選択します。
ネットワーク設定を反映するように、以下を編集します。
- ホスト名 – マシンの DNS ホスト名を追加します。
- ドメイン名 – マシンの DNS ドメイン名を追加します。
- ネームサーバー – DNS サーバーの IP アドレスを追加します。通常、これは AD ドメインコントローラーの IP アドレスです。
- ドメイン検索リスト – DNS ドメイン名を追加します。

注:

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

a～z、A～Z、0～9、およびハイフン (-) の文字のみを使用してください。アンダーバー (_)、スペース、その他の記号は避けてください。ホスト名を数字で始めたり、ハイフンで終わらせたりしないでください。このルールは、Delivery Controller のホスト名にも適用されます。

マルチキャスト DNS の無効化

SLED のみ、デフォルト設定ではマルチキャスト DNS (mDNS) が有効になっており、名前解決の結果が一貫しない可能性があります。mDNS は SLES ではデフォルトで有効になっていないため、アクションは不要です。

mDNS を無効にするには、/etc/nsswitch.conf を編集し、以下の行を変更します。

hosts: files mdns_minimal [NOTFOUND=return] dns

から:

hosts: files dns

ホスト名の確認

ホスト名が正しく設定されていることを確認します。

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 を実行できない場合は、続行する前に手順を確認してください。

手順 1c: NTP サービスの構成

VDA、Delivery Controller、およびドメインコントローラー間で正確なクロック同期を維持することが重要です。Linux VDA を仮想マシン (VM) としてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモート NTP サービスを使用して時刻を維持することが推奨されます。デフォルトの NTP 設定にいくつかの変更が必要になる場合があります。

SUSE 15.3 および SUSE 15.2 の場合:

UI ベースの YaST ツールを起動します。
［ネットワークサービス］、次に［NTP 構成］を選択します。
［NTP デーモンの開始］セクションで、［今すぐ起動してブート時にも起動］を選択します。
［構成ソース］で［動的］を選択します。
必要に応じて NTP サーバーを追加します。NTP サービスは通常、Active Directory ドメインコントローラーでホストされます。
/etc/chrony.conf に以下の行が存在する場合は、削除またはコメントアウトします。

include /etc/chrony.d/*.conf

chrony.conf を編集した後、chronyd サービスを再起動します。
```
sudo systemctl restart chronyd.service

```

SUSE 12.5 の場合:

YaST NTP 構成を開き、［一般設定］タブを選択します。
［NTP デーモンの開始］セクションで、［今すぐ起動してブート時にも起動］をオンにします。
存在する場合は、［規律のないローカルクロック (LOCAL)］項目を選択し、［削除］をクリックします。
［追加］をクリックして、NTP サーバーのエントリを追加します。
［サーバーの種類］を選択し、［次へ］をクリックします。
アドレスフィールドに NTP サーバーの DNS 名を入力します。このサービスは通常、Active Directory ドメインコントローラーでホストされます。
オプションフィールドは変更しないでください。
［テスト］をクリックして、NTP サービスに到達可能であることを確認します。
一連のウィンドウで［OK］をクリックして、変更を保存します。

注:

SLES 12 の実装では、AppArmor ポリシーに関する既知の SUSE の問題により、NTP デーモンが起動に失敗する可能性があります。詳細については、解決策を参照してください。

手順 1d: Linux VDA 依存パッケージのインストール

SUSE Linux Enterprise 用の Linux VDA ソフトウェアは、以下のパッケージに依存しています。

Postgresql10-server 10.12 以降
Open Motif Runtime Environment 2.3.1 以降
Cups 1.6.0 以降
Foomatic filters 3.0.0 以降
ImageMagick 6.8 以降

リポジトリの追加

PostgreSQL や ImageMagick など、一部の必要なパッケージは、SUSE Linux Enterprise Software Development Kit (SDK) から入手できます。パッケージを入手するには、YaST を使用して SDK リポジトリを追加するか、SDK イメージファイルをダウンロードして、以下のコマンドを使用してローカルにマウントします。

sudo mkdir -p /mnt/sdk

sudo mount -t iso9660 path-to-iso/SLE-12-SP5-SDK-DVD-x86_64-GM-DVD1.iso /mnt/sdk

sudo zypper ar -f /mnt/sdk sdk
<!--NeedCopy-->

Kerberos クライアントのインストール

Linux VDAとDelivery Controller間の相互認証のためにKerberosクライアントをインストールします。

sudo zypper install krb5-client
<!--NeedCopy-->

Kerberosクライアントの設定は、使用するActive Directory統合アプローチによって異なります。以下の説明を参照してください。

PostgreSQLのインストール

SLED/SLES 12で、パッケージをインストールします。

sudo zypper install postgresql-init

sudo zypper install postgresql10-server

sudo zypper install postgresql-jdbc
<!--NeedCopy-->

データベースサービスを初期化し、マシンの起動時にPostgreSQLが開始されるようにするために、インストール後の手順が必要です。

sudo systemctl enable postgresql

ux virtual masudo systemctl restart postgresql
<!--NeedCopy-->

データベースファイルは/var/lib/pgsql/dataにあります。

リポジトリの削除

-  依存パッケージがインストールされたら、以前に設定したSDKリポジトリとマウントされたメディアを削除するために、以下のコマンドを実行します。

    -  sudo zypper rr sdk

sudo umount /mnt/sdk

sudo rmdir /mnt/sdk
<!--NeedCopy-->

ステップ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 Integration Servicesがインストールされた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：VMをWindowsドメインに追加

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

-  [Samba Winbind](/ja-jp/linux-virtual-delivery-agent/2203-ltsr/installation-overview/manual-installation-overview/suse.html#samba-winbind)
-  [Quest Authentication Service](/ja-jp/linux-virtual-delivery-agent/2203-ltsr/installation-overview/manual-installation-overview/suse.html#quest-authentication-service)
-  [Centrify DirectControl](/ja-jp/linux-virtual-delivery-agent/2203-ltsr/installation-overview/manual-installation-overview/suse.html#centrify-directcontrol)
-  [SSSD](/ja-jp/linux-virtual-delivery-agent/2203-ltsr/installation-overview/manual-installation-overview/suse.html#sssd)
-  [PBIS](/ja-jp/linux-virtual-delivery-agent/2203-ltsr/installation-overview/manual-installation-overview/suse.html#pbis)

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

注：

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

Samba Winbind

Windowsドメインへの参加

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

YaSTを起動し、ネットワークサービス、次にWindowsドメインメンバーシップを選択します
次の変更を行います。
- Domain or Workgroup を、Active Directory ドメインの名前またはドメインコントローラーの IP アドレスに設定します。ドメイン名が大文字であることを確認してください。
- Also Use SMB information for Linux Authentication をオンにします。
- Create Home Directory on Login をオンにします。
- Single Sign-on for SSH をオンにします。
- Offline Authentication がオフになっていることを確認します。このオプションは Linux VDA と互換性がありません。
OK をクリックします。一部のパッケージのインストールを求められた場合は、Install をクリックします。
ドメインコントローラーが見つかった場合、ドメインへの参加を求められます。Yes をクリックします。
プロンプトが表示されたら、コンピューターをドメインに追加する権限を持つドメインユーザーの資格情報を入力し、OK をクリックします。
成功を示すメッセージが表示されます。
一部の Samba および krb5 パッケージのインストールを求められた場合は、Install をクリックします。

YaST は、これらの変更に一部のサービスまたはマシンの再起動が必要であることを示している場合があります。マシンの再起動をお勧めします。

su -

reboot
<!--NeedCopy-->

SUSE 12 のみ: Kerberos 資格情報キャッシュ名のパッチ適用

SUSE 12 では、デフォルトの Kerberos 資格情報キャッシュ名の指定が、通常の FILE:/tmp/krb5cc_%{uid} から DIR:/run/user/%{uid}/krb5cc に変更されました。この新しい DIR キャッシュ方法は Linux VDA と互換性がないため、手動で変更する必要があります。root ユーザーとして /etc/krb5.conf を編集し、設定されていない場合は [libdefaults] セクションに次の設定を追加します。

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

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

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

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

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

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

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

Kerberos 構成の確認

Kerberos が Linux VDA で使用するために正しく構成されていることを確認するには、システム keytab ファイルが作成され、有効なキーが含まれていることを確認します。

sudo klist –ke
<!--NeedCopy-->

このコマンドは、プリンシパル名と暗号スイートのさまざまな組み合わせで利用可能なキーのリストを表示します。これらのキーを使用してマシンをドメインコントローラーで認証するには、Kerberos kinit コマンドを実行します。

sudo kinit -k MACHINE\$@REALM
<!--NeedCopy-->

マシン名とレルム名は大文字で指定する必要があります。ドル記号 ($) は、シェルによる置換を防ぐためにバックスラッシュ (\) でエスケープする必要があります。一部の環境では、DNS ドメイン名が Kerberos レルム名と異なる場合があります。レルム名が使用されていることを確認してください。このコマンドが成功した場合、出力は表示されません。

マシンアカウントの TGT チケットがキャッシュされていることを確認するには、次を使用します。

sudo klist
<!--NeedCopy-->

マシンアカウントの詳細を確認するには、次を使用します。

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

ユーザー認証の確認

wbinfo ツールを使用して、ドメインユーザーがドメインで認証できることを確認します。

wbinfo --krb5auth=domain\\username%password
<!--NeedCopy-->

ここで指定するドメインは AD ドメイン名であり、Kerberos レルム名ではありません。bash シェルの場合、バックスラッシュ (\) 文字は別のバックスラッシュでエスケープする必要があります。このコマンドは、成功または失敗を示すメッセージを返します。

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

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

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

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

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

klist
<!--NeedCopy-->

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

exit
<!--NeedCopy-->

-  同様のテストは、Gnome または KDE コンソールに直接ログオンすることで実行できます。ドメイン参加の確認後、[手順 6: Linux VDA のインストール](/ja-jp/linux-virtual-delivery-agent/2203-ltsr/installation-overview/manual-installation-overview/suse.html#step-6-install-the-linux-vda)に進みます。

Quest 認証サービス

ドメインコントローラーでの Quest の構成

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

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

ドメインユーザーが Linux VDA マシンで HDX™ セッションを確立できるようにするには、次の手順を実行します。

Active Directory ユーザーとコンピューター管理コンソールで、そのユーザーアカウントの Active Directory ユーザープロパティを開きます。
Unix Account タブを選択します。
Unix-enabled をオンにします。
Primary GID Number を実際のドメインユーザーグループのグループ 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 ドメインへの参加

Linux マシンを Active Directory ドメインに参加させるには、Quest の vastool コマンドを使用します。

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: ドメインが見つかりませんでした。 ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm default_realm not configured in vas.conf. Computer may not be joined to domain

ユーザー認証の確認

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

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

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

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

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

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

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

exit
<!--NeedCopy-->

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

Centrify DirectControl

Windows ドメインへの参加

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

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

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 を返すことを確認します。モードが開始状態のままになっている場合、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

```

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

sudo zypper install krb5-client

sudo zypper install samba-client
<!--NeedCopy-->

ルートユーザーとして /etc/krb5.conf ファイルを編集し、kinit ユーティリティがターゲットドメインと通信できるようにします。[libdefaults]、[realms]、および [domain_realm] セクションに次のエントリを追加します。

注：

ADインフラストラクチャに基づいてKerberosを構成します。以下の設定は、単一ドメイン、単一フォレストモデルを対象としています。
```
[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

    realm = REALM

```
realm は Kerberos レルム名（例：example.com）です。REALM は大文字の Kerberos レルム名（例：EXAMPLE.COM）です。fqdn-of-domain-controller はドメインコントローラーの FQDN です。
ルートユーザーとして /etc/samba/smb.conf を編集し、net ユーティリティがターゲットドメインと通信できるようにします。[global] セクションに次のエントリを追加します。
```
[global]
    workgroup = domain

    realm = REALM

    security = ADS

    kerberos method = secrets and keytab

    client signing = yes

    client use spnego = yes

```
domain は Active Directory ドメインの短い NetBIOS 名（例：EXAMPLE）です。
/etc/nsswitch.conf ファイルの passwd および group エントリを変更し、ユーザーとグループの解決時に SSSD を参照するようにします。
```
passwd: compat sss

group: compat sss

```
Windows ドメインに参加します。ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つ Active Directory ユーザーアカウントがあることを確認します。
- SUSE 15.3 および SUSE 15.2 の場合：
```
 sudo net ads join -U user
 
```
- SUSE 12.5 の場合：
```
 sudo realm join REALM -U user
 
```
user は、コンピューターをドメインに追加する権限を持つドメインユーザーです。

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


```
- domain-dns-name は DNS ドメイン名（例：example.com）です。
- 注：
- ldap_id_mapping は true に設定されており、SSSD 自体が Windows SID を Unix UID にマッピングします。そうでない場合、Active Directory は POSIX 拡張機能を提供できる必要があります。ad_gpo_access_control は permissive に設定されており、Linux セッションの無効なログオンエラーを防ぎます。sssd.conf および sssd-ad の man ページを参照してください。
1. sssd.conf のファイル所有権とアクセス許可を設定します。
```
sudo chmod 0600 /etc/sssd/sssd.conf


```

SSSD の有効化

システム起動時に SSSD デーモンを有効にして開始するには、次のコマンドを実行します。

sudo systemctl enable sssd
sudo systemctl start sssd
<!--NeedCopy-->

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

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

```

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

Kerberos 構成の確認

Linux VDA で使用するために Kerberos が正しく構成されていることを確認するには、システム keytab ファイルが作成され、有効なキーが含まれていることを確認します。

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

Windowsドメインへの参加

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

/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->

userは、Active Directoryドメインにコンピューターを追加する権限を持つドメインユーザーです。domain-nameは、ドメインのDNS名です（例: example.com）。

注: Bashをデフォルトシェルとして設定するには、/opt/pbis/bin/config LoginShellTemplate/bin/bashコマンドを実行します。

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

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

        -  /opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->

    -  マシンがドメインに参加している場合、このコマンドは現在参加しているADドメインとOUに関する情報を返します。それ以外の場合は、ホスト名のみが表示されます。

ユーザー認証の確認

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

ssh localhost -l domain\\user

id -u
<!--NeedCopy-->

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

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

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

exit
<!--NeedCopy-->

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

ステップ4: .NET Runtime 6.0のインストール

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

.NET Runtime 6.0のインストール後、which dotnetコマンドを実行してランタイムパスを見つけます。

コマンド出力に基づいて、.NETランタイムバイナリパスを設定します。たとえば、コマンド出力が/aa/bb/dotnetの場合、/aa/bbを.NETバイナリパスとして使用します。

ステップ5: Linux VDAパッケージのダウンロード

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

ステップ6: Linux VDAのインストール

ステップ6a: 旧バージョンのアンインストール

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

Linux VDAサービスを停止します
```
sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

```
注:

ctxvdaおよびctxhdxサービスを停止する前に、systemctl ctxmonitorservice stopコマンドを実行してモニターサービスデーモンを停止します。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
パッケージをアンインストールします
```
sudo rpm -e XenDesktopVDA

```

重要:

最新の2つのバージョンからのアップグレードがサポートされています。

注:

インストールコンポーネントは /opt/Citrix/VDA/ にあります。

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

ステップ 6b: Linux VDA のインストール

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

SUSE 15 の場合:

sudo zypper install XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->

SUSE 12 の場合:

sudo zypper install XenDesktopVDA-<version>.sle12_x.x86_64.rpm
<!--NeedCopy-->

RPM パッケージマネージャーを使用して Linux VDA ソフトウェアをインストールします。その前に、以下の依存関係を解決してください。

SUSE 15 の場合:

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

SUSE 12 の場合:

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

ステップ 6c: Linux VDA のアップグレード (オプション)

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

注:

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

SUSE 15 の場合:

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

SUSE 12 の場合:

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

SUSE 15 の RPM 依存関係リスト:

postgresql >= 13

postgresql-server >= 13

postgresql-jdbc >= 9.4

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

motif >= 2.3.4

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

libpython2_7-1_0 >= 2.7
<!--NeedCopy-->

SUSE 12 の RPM 依存関係リスト:

libQt5Core5 >= 5.5~

mozilla-nss-tools >= 3.47.1

postgresql-server >= 10.12

postgresql-jdbc >= 9.2

java-11-openjdk >= 11

ImageMagick >= 6.8

dbus-1 >= 1.8.8

dbus-1-x11 >= 1.8.8

libXpm4 >= 3.5.11

libXrandr2 >= 1.4.2

libXtst6 >= 1.2.2

motif >= 2.3

pam >= 1.1.8

bash >= 4.2

findutils >= 4.5

gawk >= 4.1

sed >= 4.2

cups >= 1.6.0

cups-filters-foomatic-rip >= 1.0.0

openldap2 >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

libmspack0 >= 0.4

python-requests >= 2.8.1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsLzma) <= 4.4.6-1

libtcmalloc4 >= 2.5

libcap-progs >= 2.22

xorg-x11-server >= 7.6_1.18.3-76.15

ibus >= 1.5

xorg- x11-server = 7.6_1.19.6

xorg-x11 = 7.6_1

postgresql10-server >= 10.12

libgtk-2_0-0 >= 2.24

libgthread-2_0-0 >= 2.48

pulseaudio-utils >= 5.0

lsb-release >= 2.0
<!--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 は、デフォルトでポート 80 である TCP/IP ポートを介して Delivery Controller と通信します。

**CTX_XDL_REGISTER_SERVICE=Y

N** - Linux Virtual Desktop サービスは、マシンの起動後に開始されます。デフォルト値は Y です。

**CTX_XDL_ADD_FIREWALL_RULES=Y

N** – Linux Virtual Desktop サービスは、システムファイアウォールを介して受信ネットワーク接続が許可される必要があります。Linux Virtual Desktop の必要なポート (デフォルトではポート 80 および 1494) をシステムファイアウォールで自動的に開くことができます。デフォルトでは Y に設定されています。

**CTX_XDL_AD_INTEGRATION=1

4** – Linux VDA は、Delivery Controller と認証するために Kerberos 構成設定を必要とします。Kerberos 構成は、システムにインストールおよび構成されている Active Directory 統合ツールから決定されます。使用するサポートされている Active Directory 統合方法を指定します。

1 – Samba Winbind
2 – Quest Authentication Service
3 – Centrify DirectControl
4 – SSSD

**CTX_XDL_HDX_3D_PRO=Y

N** – Linux VDA は、リッチグラフィックアプリケーションの仮想化を最適化するために設計された GPU アクセラレーション技術のセットである HDX 3D Pro をサポートしています。HDX 3D Pro が選択されている場合、VDA は VDI デスクトップ (シングルセッション) モード (つまり、CTX_XDL_VDI_MODE=Y) 用に構成されます。

**CTX_XDL_VDI_MODE=Y

N** – マシンを専用デスクトップ配信モデル (VDI) として構成するか、ホスト型共有デスクトップ配信モデルとして構成するか。HDX 3D Pro 環境の場合、この変数を Y に設定します。この変数はデフォルトで N に設定されています。

CTX_XDL_SITE_NAME=dns-name – Linux VDA は DNS を介して LDAP サーバーを検出します。DNS 検索結果をローカルサイトに制限するには、DNS サイト名を指定します。この変数はデフォルトで <none> に設定されています。
CTX_XDL_LDAP_LIST=’list-ldap-servers’ – Linux VDA は DNS にクエリを実行して LDAP サーバーを検出します。DNS が LDAP サービスレコードを提供できない場合、LDAP ポートを含む LDAP FQDN のスペース区切りリストを提供できます。例: ad1.mycompany.com:389。この変数はデフォルトで <none> に設定されています。
CTX_XDL_SEARCH_BASE=search-base-set – Linux VDA は、Active Directory ドメインのルート (例: 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> テキスト文字列で埋め、サーバーアドレスの順序を変更しないでください。
CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – 新しいブローカーエージェントサービス (ctxvda) をサポートするための .NET Runtime 6.0 をインストールするパス。デフォルトのパスは /usr/bin です。
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/mate – セッションで使用する GNOME または MATE デスクトップ環境を指定します。変数を指定しない場合、VDA に現在インストールされているデスクトップが使用されます。ただし、現在インストールされているデスクトップが MATE の場合は、変数値を mate に設定する必要があります。

ターゲットセッションユーザーのデスクトップ環境を変更するには、以下の手順を完了することもできます。
1. VDA 上の $HOME/<username> ディレクトリの下に .xsession ファイルを作成します。
2. ディストリビューションに基づいてデスクトップ環境を指定するように .xsession ファイルを編集します。
  - SUSE 15 の MATE デスクトップの場合
    MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi
  - SUSE 15 および SUSE 12.5 の GNOME デスクトップの場合
    GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic

1.  ターゲットセッションユーザーと700ファイル権限を共有します。

CTX_XDL_START_SERVICE=Y | N – Linux VDAの構成が完了したときにLinux VDAサービスを開始するかどうか。デフォルトはYです。
CTX_XDL_TELEMETRY_SOCKET_PORT – Citrix Scoutのリッスン用ソケットポート。デフォルトポートは7503です。
CTX_XDL_TELEMETRY_PORT – Citrix Scoutとの通信用ポート。デフォルトポートは7502です。

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

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST='list-ddc-fqdns'

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

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

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

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

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

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

export CTX_XDL_DESKTOP_ENVIRONMENT= gnome | mate | '<none>'

export CTX_XDL_TELEMETRY_SOCKET_PORT=port-number

export CTX_XDL_TELEMETRY_PORT=port-number

export CTX_XDL_START_SERVICE=Y|N

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

sudoコマンドを実行するときは、既存の環境変数を新しく作成されるシェルに渡すために、-Eオプションを入力します。前述のコマンドから、最初の行に#!/bin/bashを含むシェルスクリプトファイルを作成することをお勧めします。

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

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST='list-ddc-fqdns' \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST='list-ldap-servers' \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST='list-fas-servers' \

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

CTX_XDL_DESKTOP_ENVIRONMENT=gnome | mate \

CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \

CTX_XDL_TELEMETRY_PORT=port-number \

CTX_XDL_START_SERVICE=Y|N \

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

構成変更の削除

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

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

sudo /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の実行

sudo /opt/Citrix/VDA/bin/xdpingを実行して、Linux VDA環境における一般的な構成の問題を確認します。詳細については、「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サービスを停止する前に、systemctl 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マシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。

オペレーティングシステムの場合、以下を選択します。
- ホスト型共有デスクトップ配信モデルの場合は、Multi-session OSオプション。
- VDI専用デスクトップ配信モデルの場合は、Single-session 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 2203」を参照してください。

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

SUSE に Linux VDA を手動でインストール

April 20, 2026

寄稿者:

C C

April 20, 2026

寄稿者:

C C

この情報は役に立ちましたか?