SUSE 用 Linux Virtual Delivery Agent を手動でインストールする
重要:
新規インストールの場合、迅速なインストールには 簡易インストール の使用をお勧めします。簡易インストールは、時間と労力を節約し、この記事で詳述する手動インストールよりもエラーが発生しにくいです。
ステップ 1: インストールの準備
ステップ 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 を仮想マシンとしてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモート NTP サービスを使用して時刻を維持することが推奨されます。デフォルトの NTP 設定にいくつかの変更が必要になる場合があります。
SUSE 15.3 および SUSE 15.2 の場合:
- UI ベースの YaST ツールを起動します。
- [ネットワークサービス] を選択し、次に [NTP 構成] を選択します。
- [NTP デーモンの開始] セクションで、[今すぐ起動してブート時にも起動] を選択します。
- [構成ソース] で [動的] を選択します。
- 必要に応じて NTP サーバーを追加します。NTP サービスは通常、Active Directory ドメインコントローラーでホストされます。
-
/etc/chrony.conf に以下の行が存在する場合は、削除またはコメントアウトします。
include /etc/chrony.d/*.confchrony.conf を編集した後、
chronydサービスを再起動します。sudo systemctl restart chronyd.service <!--NeedCopy-->
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 以降
- OpenJDK 11
- 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統合アプローチによって異なります。以下の説明を参照してください。
OpenJDK 11のインストール
Linux VDAにはOpenJDK 11が必要です。
OpenJDK 11をインストールするには、次のコマンドを実行します。
sudo zypper install java-11-openjdk
<!--NeedCopy-->
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
sudo systemctl restart postgresql
<!--NeedCopy-->
- データベースファイルは/var/lib/pgsql/dataにあります。
- #### リポジトリの削除
- 依存パッケージがインストールされたら、次のコマンドを実行して、以前に設定したSDKリポジトリとマウントされたメディアを削除します。
sudo zypper rr sdk
sudo umount /mnt/sdk
sudo rmdir /mnt/sdk
<!--NeedCopy-->
ステップ2:ハイパーバイザー用のLinux VMの準備
サポートされているハイパーバイザー上でLinux VDAを仮想マシンとして実行する場合、いくつかの変更が必要です。使用しているハイパーバイザープラットフォームに基づいて、以下の変更を行います。Linuxマシンをベアメタルハードウェアで実行している場合、変更は不要です。
Citrix Hypervisor™での時刻同期の修正
Citrix Hypervisorの時刻同期機能が有効になっている場合、各準仮想化Linux VM内でNTPとCitrix Hypervisorの両方がシステムクロックを管理しようとするため、問題が発生します。クロックが他のサーバーと同期しなくなるのを避けるため、各Linuxゲスト内のシステムクロックはNTPと同期させる必要があります。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは変更は不要です。
Citrix VM Toolsがインストールされた準仮想化Linuxカーネルを実行している場合、Linux VM内からCitrix Hypervisorの時刻同期機能が存在し、有効になっているかどうかを確認できます。
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは0または1を返します。
- 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:Linux仮想マシン(VM)をWindowsドメインに追加
Linux VDAは、LinuxマシンをActive Directory(AD)ドメインに追加するためのいくつかの方法をサポートしています。
- [Samba Winbind](/ja-jp/linux-virtual-delivery-agent/2201/installation-overview/suse.html#samba-winbind)
選択した方法に基づいて指示に従ってください。
注:
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗する可能性があります。
Samba Winbind
Windowsドメインへの参加
ドメインコントローラーに到達可能であること、およびマシンをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
- YaSTを起動し、ネットワークサービス、次にWindowsドメインメンバーシップを選択します
- 次の変更を行います
- ドメインまたはワークグループをActive Directoryドメインの名前、またはドメインコントローラーのIPアドレスに設定します。ドメイン名が大文字であることを確認してください
- Linux認証にSMB情報も使用するをチェックします
- ログイン時にホームディレクトリを作成するをチェックします
- SSHのシングルサインオンをチェックします
- オフライン認証がチェックされていないことを確認します。このオプションはLinux VDAと互換性がありません
- OKをクリックします。一部のパッケージのインストールを求められた場合は、インストールをクリックします
- ドメインコントローラーが見つかった場合、ドメインに参加するかどうかを尋ねられます。はいをクリックします
- プロンプトが表示されたら、コンピューターをドメインに追加する権限を持つドメインユーザーの資格情報を入力し、OKをクリックします
- 成功を示すメッセージが表示されます
- 一部のSambaおよびkrb5パッケージのインストールを求められた場合は、インストールをクリックします
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構成の確認
Linux VDAで使用するためにKerberosが正しく構成されていることを確認するには、システム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のインストールに進みます。
- ### Quest認証サービス
ドメインコントローラーでのQuestの構成
Active Directoryドメインコントローラーに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 Agentがインストールされている状態で、Centrifyのadjoinコマンドを使用してLinuxマシンをActive Directoryドメインに参加させます。
su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->
ユーザーは、コンピューターをActive Directoryドメインに参加させる権限を持つ任意のActive Directoryドメインユーザーです。ドメイン名は、Linuxマシンを参加させるドメインの名前です。
ドメインメンバーシップの確認
Delivery Controllerでは、すべてのVDAマシン(Windows VDAおよびLinux VDA)がActive Directoryにコンピューターオブジェクトを持っている必要があります。Centrifyに参加しているLinuxマシンがドメイン上にあることを確認するには、次の手順を実行します。
su –
adinfo
<!--NeedCopy-->
Joined to domainの値が有効であり、CentrifyDCのモードがconnectedを返すことを確認します。モードが開始状態のままになっている場合、Centrifyクライアントはサーバー接続または認証の問題を抱えています。
より包括的なシステムおよび診断情報は、以下を使用して利用できます。
adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->
さまざまなActive DirectoryおよびKerberosサービスへの接続をテストします。
adinfo --test
<!--NeedCopy-->
ドメイン参加の確認後、手順6:Linux VDAのインストールに進みます。
SSSD
SUSEでSSSDを使用している場合は、このセクションの手順に従ってください。このセクションには、Linux VDAマシンをWindowsドメインに参加させるための手順と、Kerberos認証を構成するためのガイダンスが含まれています。
SUSEでSSSDをセットアップするには、次の手順を完了します。
- ドメインへの参加とホストキータブの作成
- SSSDのPAM構成
- SSSDのセットアップ
- SSSDの有効化
- ドメインメンバーシップの確認
- Kerberos構成の確認
- ユーザー認証の確認
ドメインへの参加とホストキータブの作成
SSSDは、ドメインへの参加やシステムキータブファイルの管理のためのActive Directoryクライアント機能を提供しません。代わりに、Sambaのアプローチを使用できます。SSSDを構成する前に、以下の手順を完了してください。
-
ネームサービスキャッシュデーモン (NSCD) を停止し、無効にします。
sudo systemctl stop nscd sudo systemctl disable nscd <!--NeedCopy--> -
必要なパッケージをインストールまたは更新します。
sudo zypper install krb5-client sudo zypper install samba-client <!--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 realm = REALM <!--NeedCopy-->realmは、example.comのようなKerberosレルム名です。REALMは、EXAMPLE.COMのような大文字のKerberosレルム名です。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 <!--NeedCopy-->domainは、EXAMPLEのようなActive Directoryドメインの短いNetBIOS名です。
-
/etc/nsswitch.confファイル内のpasswdおよびgroupエントリを変更し、ユーザーとグループを解決する際にSSSDを参照するようにします。
passwd: compat sss group: compat sss <!--NeedCopy--> -
Windowsドメインに参加します。ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントがあることを確認してください。
-
SUSE 15.3およびSUSE 15.2の場合:
sudo net ads join -U user <!--NeedCopy--> -
SUSE 12.5の場合:
sudo realm join REALM -U user <!--NeedCopy-->
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
Given the strict constraints:
- “Fix ONLY the Markdown linting violations listed below in the given line.”
- “Preserve all translated text content exactly — do not retranslate, do not add new words, do not remove words unless the rule explicitly requires deletion.”
- The rule is MD031 (blanks-around-fences).
Since the given line is not a fenced code block, MD031 does not apply to it directly. If the linter is flagging this line, it implies that this line is adjacent to a fenced code block that is missing a blank line. However, the instruction is to fix the given line itself, not to add lines before or after it.
Kerberos settings
If I cannot add blank lines, and I cannot remove words (as MD031 does not explicitly require deletion), and the line is not a fenced code block, then there is no valid way to “fix” this line according to MD031 under these constraints.
This indicates a potential contradiction in the problem statement or the linter’s context. However, I must return a corrected line. The only way to interpret “fix ONLY the Markdown linting violations listed below in the given line” for MD031 on a non-fenced line, without removing content, is to assume the line is already correct as a non-fenced line and the linter’s context is misleading, or that no change is possible within the given constraints.
Therefore, the line remains unchanged as it is not a fenced code block and the rule does not apply to its content directly.
- 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
Some heading text
-
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 -
SSSDの有効化
システム起動時にSSSDデーモンを有効にして開始するには、以下のコマンドを実行します。
sudo systemctl enable sssd
sudo systemctl start sssd
ドメインメンバーシップの確認
-
Sambaのnet adsコマンドを実行して、マシンがドメインに参加していることを確認します。
sudo net ads testjoin -
追加のドメインおよびコンピューターオブジェクト情報を確認するには、以下のコマンドを実行します。
sudo net ads info
Kerberos構成の確認
- Linux VDAで使用するためにKerberosが正しく構成されていることを確認するには、システムキータブファイルが作成され、有効なキーが含まれていることを確認します。
sudo klist -ke
このコマンドは、プリンシパル名と暗号スイートのさまざまな組み合わせで利用可能なキーのリストを表示します。これらのキーを使用してドメインコントローラーでマシンを認証するには、Kerberos kinitコマンドを実行します。
sudo kinit –k MACHINE\$@REALM
マシン名とレルム名は大文字で指定する必要があります。ドル記号 ($) は、シェルによる置換を防ぐためにバックスラッシュ (\) でエスケープする必要があります。一部の環境では、DNSドメイン名がKerberosレルム名と異なる場合があります。レルム名が使用されていることを確認してください。このコマンドが成功した場合、出力は表示されません。
マシンアカウントのTGTチケットがキャッシュされていることを確認するには、次を使用します。
sudo klist
ユーザー認証の確認
SSSDは、デーモンとの直接認証をテストするためのコマンドラインツールを提供しておらず、PAMを介してのみ実行できます。
SSSD PAMモジュールが正しく構成されていることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用してLinux VDAにログオンします。
ssh localhost -l domain\\username
id -u
klist
exit
klist コマンドによって返されたKerberosチケットがそのユーザーに対して正しく、期限切れになっていないことを確認します。
rootユーザーとして、以前の id -u コマンドによって返されたUIDに対応するチケットキャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_uid
同様のテストは、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
PBISインストールスクリプトの実行可能化
例:
chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
PBISインストールスクリプトの実行
例:
sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
Windowsドメインへの参加
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
/opt/pbis/bin/domainjoin-cli join domain-name user
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
マシンがドメインに参加している場合、このコマンドは現在参加しているADドメインとOUに関する情報を返します。それ以外の場合は、ホスト名のみが表示されます。
ユーザー認証の確認
PBISがPAMを介してドメインユーザーを認証できることを確認するには、これまで使用したことのないドメインユーザーアカウントを使用してLinux VDAにログオンします。
- ssh localhost -l domain\\user
- id -u
id -u コマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_uid
セッションを終了します。
- exit
ドメイン参加の検証後、手順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サービスを停止する前に、モニターサービスデーモンを停止するためにservice 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
SUSE 12の場合:
sudo zypper install XenDesktopVDA-<version>.sle12_x.x86_64.rpm
RPMパッケージマネージャーを使用してLinux VDAソフトウェアをインストールします。その前に、以下の依存関係を解決してください。
SUSE 15の場合:
sudo rpm -i XenDesktopVDA-<version>.sle15_x.x86_64.rpm
SUSE 12の場合:
sudo rpm -i XenDesktopVDA-<version>.sle12_x.x86_64.rpm
ステップ 6c: Linux VDAのアップグレード (オプション)
既存のインストールを以前の2つのバージョンおよびLTSRリリースからアップグレードできます。
注:
既存のインストールをアップグレードすると、/etc/xdlの下にある構成ファイルが上書きされます。アップグレードを実行する前に、必ずファイルをバックアップしてください。
SUSE 15の場合:
sudo rpm -U XenDesktopVDA-<version>.sle15_x.x86_64.rpm
SUSE 12の場合:
sudo rpm -U XenDesktopVDA-<version>.sle12_x.x86_64.rpm
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
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
重要:
アップグレード後、Linux VDAマシンを再起動してください。
ステップ 7: NVIDIA GRIDドライバーのインストール
HDX 3D Proを有効にするには、ハイパーバイザーとVDAマシンにNVIDIA GRIDドライバーをインストールする必要があります。
特定のハイパーバイザーにNVIDIA GRID Virtual GPU Manager(ホストドライバー)をインストールおよび構成するには、以下のガイドを参照してください。
- [Citrix Hypervisor](/ja-jp/citrix-hypervisor/graphics/vm-graphics-config.html#install-the-nvidia-drivers)
- [VMware ESX](https://docs.nvidia.com/vgpu/latest/grid-software-quick-start-guide/index.html#installing-grid-vgpu-manager-vmware-vsphere)
NVIDIA GRIDゲストVMドライバーをインストールおよび構成するには、以下の一般的な手順を実行します。
- ゲストVMがシャットダウンされていることを確認します。
- ハイパーバイザーのコントロールパネルで、VMにGPUを割り当てます。
- VMを起動します。
- VMにゲストVMドライバーをインストールします。
ステップ 8: Linux VDAの構成
パッケージのインストール後、ctxsetup.shスクリプトを実行してLinux VDAを構成する必要があります。変更を加える前に、スクリプトは環境を検証し、すべての依存関係がインストールされていることを確認します。必要に応じて、いつでもスクリプトを再実行して設定を変更できます。
スクリプトは、プロンプトに従って手動で実行することも、事前設定された応答で自動的に実行することもできます。続行する前に、スクリプトに関するヘルプを確認してください。
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh –help
プロンプトによる構成
プロンプトによる質問で手動構成を実行します。
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
自動構成
自動インストールの場合、セットアップスクリプトに必要なオプションを環境変数で指定します。必要な変数がすべて存在する場合、スクリプトは情報を要求しません。
サポートされている環境変数には以下が含まれます。
- 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 Virtual Desktopサービスは、マシンの起動後に開始されます。値はデフォルトでYに設定されています。
- CTX_XDL_ADD_FIREWALL_RULES=Y | N – Linux Virtual Desktopサービスは、システムファイアウォールを介して受信ネットワーク接続が許可されることを必要とします。Linux Virtual Desktop用に、必要なポート(デフォルトではポート80および1494)をシステムファイアウォールで自動的に開くことができます。デフォルトではYに設定されています。
-
CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 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はLDAPサーバーを検出するためにDNSをクエリします。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’ – フェデレーション認証サービス (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 に設定する必要があります。
注:
ターゲットセッションユーザーのデスクトップ環境は、以下の手順で変更することもできます。
- VDA上の $HOME/<username> ディレクトリの下に
.xsessionファイルを作成します。 -
.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
-
- VDA上の $HOME/<username> ディレクトリの下に
fi3. ターゲットセッションユーザーと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
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
構成変更の削除
シナリオによっては、Linux VDA パッケージをアンインストールせずに、ctxsetup.sh スクリプトによって行われた構成変更を削除する必要がある場合があります。
続行する前に、このスクリプトに関するヘルプを確認してください。
sudo /usr/local/sbin/ctxcleanup.sh --help
構成変更を削除するには:
sudo /usr/local/sbin/ctxcleanup.sh
重要:
このスクリプトは、データベースからすべての構成データを削除し、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
Linux VDA の停止:
Linux VDA サービスを停止するには:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx stop
注:
ctxvdaおよびctxhdxサービスを停止する前に、service ctxmonitorservice stopコマンドを実行してモニターサービスデーモンを停止してください。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
Linux VDA の再起動:
Linux VDA サービスを再起動するには:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx restart
sudo /sbin/service ctxvda start
Linux VDA のステータスの確認:
Linux VDA サービスの実行ステータスを確認するには:
sudo /sbin/service ctxvda status
sudo /sbin/service ctxhdx status
ステップ 11: Citrix Virtual Apps または Citrix Virtual Desktops™ でのマシンカタログの作成
マシンカタログを作成し、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 オプションを選択すると、マシンごとに単一ユーザーの配信モデルが意味されます。
ヒント:
マシンを Active Directory ドメインから削除して再参加させる場合、そのマシンをマシンカタログから削除し、再度追加する必要があります。
ステップ 12: Citrix Virtual Apps™ または Citrix Virtual Desktops でのデリバリーグループの作成
デリバリーグループを作成し、Linux VDA マシンを含むマシンカタログを追加するプロセスは、Windows VDA マシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDA マシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。
- 選択した AD ユーザーとグループが、Linux VDA マシンにログオンするように適切に構成されていることを確認してください。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- デリバリーグループと Windows マシンを含むマシンカタログを混在させないでください。
重要:
アプリケーションの公開は、Linux VDA バージョン 1.4 以降でサポートされています。ただし、Linux VDA は、同じマシンへのデスクトップとアプリの配信をサポートしていません。
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2112」を参照してください。 ```
この記事の概要
- ステップ 1: インストールの準備
- ステップ2:ハイパーバイザー用のLinux VMの準備
- ステップ3:Linux仮想マシン(VM)をWindowsドメインに追加
- Some heading text
- SSSDの有効化
- 手順4:前提条件としての.NET Runtime 6.0のインストール
- 手順5:Linux VDAパッケージのダウンロード
- 手順6:Linux VDAのインストール
- ステップ 7: NVIDIA GRIDドライバーのインストール
- ステップ 8: Linux VDAの構成
- ステップ 9: XDPing の実行
- ステップ 10: Linux VDA の実行
- ステップ 11: Citrix Virtual Apps または Citrix Virtual Desktops™ でのマシンカタログの作成
- ステップ 12: Citrix Virtual Apps™ または Citrix Virtual Desktops でのデリバリーグループの作成