DebianへのLinux VDAの手動インストール
重要:
新規インストールの場合、迅速なインストールには簡易インストールの使用をお勧めします。簡易インストールは、時間と労力を節約し、この記事で詳述する手動インストールよりもエラーが発生しにくいです。
ステップ1:構成情報とLinuxマシンの準備
ステップ1a:ネットワーク構成の確認
ネットワークが正しく接続され、構成されていることを確認します。たとえば、Linux VDAでDNSサーバーを構成するには、次のコマンドを実行します。
echo "nameserver <dns ip address>" > "/etc/resolv.conf.custom"
echo "#!/bin/bash
#
# Description: script to override default resolv.conf file
# with customized file.
cp -f /etc/resolv.conf.custom /etc/resolv.conf">"/etc/NetworkManager/dispatcher.d/15-resolv"
chmod +x /etc/NetworkManager/dispatcher.d/15-resolv
<!--NeedCopy-->
ステップ1b:ホスト名の設定
マシンのホスト名が正しく報告されるように、/etc/hostnameファイルを変更して、マシンのホスト名のみが含まれるようにします。
hostname
ステップ1c:ホスト名へのループバックアドレスの割り当て
マシンのDNSドメイン名と完全修飾ドメイン名(FQDN)が正しく報告されることを確認します。これを行うには、/etc/hostsファイルの次の行を変更して、FQDNとホスト名を最初の2つのエントリとして含めます。
127.0.0.1 hostname-fqdn hostname localhost
例:
127.0.0.1 vda01.example.com vda01 localhost
ファイル内の他のエントリからhostname-fqdnまたはhostnameへの他の参照をすべて削除します。
注:
Linux VDAは現在、NetBIOS名の切り捨てをサポートしていません。ホスト名は15文字を超えないようにしてください。
ヒント:
a~z、A~Z、0~9、およびハイフン(-)文字のみを使用してください。アンダースコア(_)、スペース、その他の記号は避けてください。ホスト名を数字で始めたり、ハイフンで終わらせたりしないでください。このルールはDelivery Controllerのホスト名にも適用されます。
ステップ1d:ホスト名の確認
マシンを再起動し、ホスト名が正しく設定されていることを確認します。
hostname
<!--NeedCopy-->
このコマンドは、マシンのホスト名のみを返し、FQDNは返しません。
FQDNが正しく設定されていることを確認します。
hostname -f
<!--NeedCopy-->
このコマンドは、マシンのFQDNを返します。
ステップ1e:マルチキャストDNSの無効化
デフォルト設定ではマルチキャストDNS(mDNS)が有効になっており、名前解決の結果が一貫しない可能性があります。
mDNSを無効にするには、/etc/nsswitch.confを編集し、次の行を変更します。
hosts: files mdns_minimal [NOTFOUND=return] dns
次のように変更します。
hosts: files dns
ステップ1f:名前解決とサービス到達性の確認
FQDNを解決し、ドメインコントローラーとDelivery Controller™にpingを実行できることを確認します。
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
FQDNを解決できない場合、またはこれらのマシンのいずれかにpingを実行できない場合は、続行する前に手順を確認してください。
ステップ1g:クロック同期(chrony)の構成
VDA、Delivery Controller、およびドメインコントローラー間で正確なクロック同期を維持することは非常に重要です。Linux VDAを仮想マシン(VM)としてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモートタイムサービスとの時刻同期が推奨されます。
chronyをインストールします。
apt-get install chrony
<!--NeedCopy-->
rootユーザーとして、/etc/chrony/chrony.confを編集し、各リモートタイムサーバーのサーバーエントリを追加します。
server peer1-fqdn-or-ip-address iburst
server peer2-fqdn-or-ip-address iburst
一般的な展開では、パブリックNTPプールサーバーから直接ではなく、ローカルドメインコントローラーから時刻を同期します。ドメイン内の各Active Directoryドメインコントローラーのサーバーエントリを追加します。
ループバックIPアドレス、localhost、およびパブリックサーバー*.pool.ntp.orgエントリを含む、リストされている他のserverまたはpoolエントリをすべて削除します。
変更を保存し、Chronyデーモンを再起動します。
sudo systemctl restart chrony
<!--NeedCopy-->
ステップ1h:パッケージのインストール
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
ステップ1i:必要な依存関係をインストールするためのリポジトリの追加
Debian 11.3の場合、/etc/apt/sources.listファイルにdeb http://deb.debian.org/debian/ bullseye mainの行を追加します。
ステップ1j:使用するデータベースのインストールと指定
Linux VDAパッケージのインストール後、/etc/xdl/db.confを編集することで、使用するSQLiteまたはPostgreSQLを指定できます。手動インストールの場合、指定する前にSQLiteとPostgreSQLを手動でインストールする必要があります。
このセクションでは、PostgreSQLおよびSQLiteデータベースのインストール方法と、使用するデータベースの指定方法について説明します。
注:
SQLiteはVDIモードでのみ使用することをお勧めします。
PostgreSQLのインストール
PostgreSQLをインストールするには、次のコマンドを実行します。
sudo apt-get update
sudo apt-get install -y postgresql
sudo apt-get install -y libpostgresql-jdbc-java
<!--NeedCopy-->
マシンの起動時または即座にPostgreSQLを開始するには、それぞれ次のコマンドを実行します。
- sudo systemctl enable postgresql
sudo systemctl start postgresql
<!--NeedCopy-->
SQLiteのインストール
Debianの場合、SQLiteをインストールするには、次のコマンドを実行します。
sudo apt-get install -y sqlite3
<!--NeedCopy-->
使用するデータベースの指定
Linux VDAパッケージのインストール後、/etc/xdl/db.confを編集して使用するデータベースを指定できます。これを行うには、次の手順を完了します。
- /opt/Citrix/VDA/sbin/ctxcleanup.shを実行します。新規インストールの場合、この手順は省略します。
- /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
これらの変更を確認するには、システムを再起動します。
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の設定で、Integration Servicesを選択します。
- 時刻同期が選択されていることを確認します。
注:
このアプローチは、NTPとの競合を避けるためにホストの時刻同期が無効になっているVMwareおよびCitrix Hypervisorとは異なります。Hyper-Vの時刻同期は、NTPの時刻同期と共存し、補完することができます。
ESXおよびESXiでの時刻同期の修正
VMwareの時刻同期機能が有効になっている場合、各準仮想化Linux VM内でNTPとハイパーバイザーの両方で問題が発生します。両方がシステムクロックを同期しようとします。クロックが他のサーバーと同期しなくなるのを避けるため、各Linuxゲスト内のシステムクロックがNTPと同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsがインストールされた準仮想化Linuxカーネルを実行している場合:
- vSphere Clientを開きます。
- Linux VMの設定を編集します。
- Virtual Machine Propertiesダイアログで、Optionsタブを開きます。
- VMware Toolsを選択します。
- Advancedボックスで、Synchronize guest time with hostのチェックを外します。
ステップ3:WindowsドメインへのLinux VMの追加
Active Directory(AD)ドメインにLinuxマシンを追加するには、次の方法があります。
選択した方法に基づいて指示に従ってください。
注:
Linux VDAのローカルアカウントとADのアカウントで同じユーザー名を使用すると、セッションの起動に失敗する場合があります。
Samba Winbind
必要なパッケージのインストールまたは更新
sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user
<!--NeedCopy-->
マシン起動時にWinbindデーモンを有効にする
Winbindデーモンは、マシンの起動時に開始するように構成する必要があります。
sudo systemctl enable winbind
<!--NeedCopy-->
注:
winbindスクリプトが/etc/init.dの下にあることを確認してください。
Kerberosの構成
rootユーザーとして/etc/krb5.confを開き、次の設定を行います。
注:
ADインフラストラクチャに基づいてKerberosを構成してください。以下の設定は、単一ドメイン、単一フォレストモデルを対象としています。
[libdefaults]
default_realm = REALM
dns_lookup_kdc = false
[realms]
REALM = {
admin_server = domain-controller-fqdn
kdc = domain-controller-fqdn
}
[domain_realm]
domain-dns-name = REALM
.domain-dns-name = REALM
このコンテキストでのdomain-dns-nameパラメーターは、example.comのようなDNSドメイン名です。REALMは、EXAMPLE.COMのような大文字のKerberosレルム名です。
Winbind認証の構成
vim /etc/samba/smb.confコマンドを実行して/etc/samba/smb.confを開き、次の設定を行います。
[global]
workgroup = WORKGROUP
security = ADS
realm = REALM
encrypt passwords = yes
idmap config *:range = 16777216-33554431
kerberos method = secrets and keytab
winbind refresh tickets = yes
template shell = /bin/bash
WORKGROUP は REALM の最初のフィールドであり、REALM は大文字のKerberosレルム名です。
nsswitch の構成
/etc/nsswitch.conf を開き、次の行に winbind を追加します。
passwd: systemd winbind
group: systemd winbind
Windowsドメインへの参加
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
sudo net ads join <Kerberos realm name in uppercase> -U <domain user with permission to add computers to the domain>
<!--NeedCopy-->
Winbind の再起動
sudo systemctl restart winbind
<!--NeedCopy-->
Winbind 用 PAM の構成
次のコマンドを実行し、Winbind NT/Active Directory 認証とログイン時にホームディレクトリを作成オプションが選択されていることを確認します。
sudo pam-auth-update
<!--NeedCopy-->
ヒント:
winbind デーモンは、マシンがドメインに参加している場合にのみ実行され続けます。
ドメインメンバーシップの確認
Delivery Controller は、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-->
注:
SSH コマンドを正常に実行するには、SSH が有効になっており、正しく機能していることを確認してください。
id -u コマンドによって返された uid に対応する Kerberos 資格情報キャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_uid
<!--NeedCopy-->
ユーザーの Kerberos 資格情報キャッシュ内のチケットが有効で期限切れになっていないことを確認します。
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 は、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
Kerberosの構成
Kerberosをインストールするには、次のコマンドを実行します。
sudo apt-get install krb5-user
<!--NeedCopy-->
Kerberosを構成するには、rootとして /etc/krb5.conf を開き、パラメーターを設定します。
注:
ADインフラストラクチャに基づいてKerberosを構成してください。以下の設定は、単一ドメイン、単一フォレストモデルを対象としています。
[libdefaults]
default_realm = REALM
dns_lookup_kdc = false
rdns = false
[realms]
REALM = {
admin_server = domain-controller-fqdn
kdc = domain-controller-fqdn
}
[domain_realm]
domain-dns-name = REALM
.domain-dns-name = REALM
このコンテキストでの domain-dns-name パラメーターは、example.comなどのDNSドメイン名です。REALM は、EXAMPLE.COMなどの大文字のKerberosレルム名です。
ドメインへの参加
SSSDは、IDプロバイダーとしてActive Directoryを使用し、認証にKerberosを使用するように構成する必要があります。ただし、SSSDはドメイン参加やシステムキータブファイルの管理のためのADクライアント機能を提供しません。代わりに adcli、realmd、または Samba を使用できます。
注:
このセクションでは、adcli と Samba の情報のみを提供します。
- adcliを使用してドメインに参加する場合、次の手順を完了します。
-
adcli をインストールします。
sudo apt-get install adcli <!--NeedCopy--> -
adcli を使用してドメインに参加します。
古いシステムキータブファイルを削除し、次を使用してドメインに参加します。
su - - rm -rf /etc/krb5.keytab adcli join domain-dns-name -U user -H hostname-fqdn <!--NeedCopy-->user は、マシンをドメインに追加する権限を持つドメインユーザーです。hostname-fqdn は、マシンのFQDN形式のホスト名です。
-H オプションは、Linux VDAが必要とするhost/hostname-fqdn@REALM形式でSPNを生成するために adcli に必要です。
-
システムキータブを検証します。
sudo klist -ketコマンドを実行して、システムキータブファイルが作成されていることを確認します。各キーのタイムスタンプが、マシンがドメインに参加した時刻と一致することを確認します。
- Sambaを使用してドメインに参加する場合、次の手順を完了します。
-
パッケージをインストールします。
sudo apt-get install samba krb5-user <!--NeedCopy--> -
Samba を構成します。
-
/etc/samba/smb.conf を開き、次の設定を行います。
-
[global] -
workgroup =WORKGROUP -
security = ADS -
realm =REALM -
client signing = yes -
client use spnego = yes
kerberos method = secrets and keytab
- *WORKGROUP* は *REALM* の最初のフィールドであり、*REALM* は大文字のKerberosレルム名です。
-
Samba を使用してドメインに参加します。
ドメインコントローラーに到達可能である必要があり、コンピューターをドメインに追加する権限を持つWindowsアカウントが必要です。
sudo net ads join <the Kerberos realm name in uppercase> -U <domain user with permission to add computers to the domain> <!--NeedCopy-->
SSSDのセットアップ
必要なパッケージのインストールまたは更新:
まだインストールされていない場合は、必要なSSSDおよび構成パッケージをインストールします。
sudo apt-get install sssd
<!--NeedCopy-->
- パッケージがすでにインストールされている場合は、更新が推奨されます。
sudo apt-get install --only-upgrade sssd
<!--NeedCopy-->
SSSDの構成
SSSDデーモンを起動する前に、SSSD構成の変更が必要です。SSSDの一部のバージョンでは、/etc/sssd/sssd.conf構成ファイルはデフォルトでインストールされていないため、手動で作成する必要があります。rootとして、/etc/sssd/sssd.confを作成または開き、次の設定を行います。
[sssd]
services = nss, pam
config_file_version = 2
domains = domain-dns-name
[domain/domain-dns-name]
id_provider = ad
access_provider = ad
auth_provider = krb5
krb5_realm = REALM
# Set krb5_renewable_lifetime higher if TGT renew lifetime is longer than 14 days
krb5_renewable_lifetime = 14d
# Set krb5_renew_interval to lower value if TGT ticket lifetime is shorter than 2 hours
krb5_renew_interval = 1h
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# This ldap_id_mapping setting is also the default value
ldap_id_mapping = true
override_homedir = /home/%d/%u
default_shell = /bin/bash
ad_gpo_map_remote_interactive = +ctxhdx
注:
ldap_id_mappingはtrueに設定されており、SSSD自体がWindows SIDをUnix UIDにマッピングします。そうでない場合、
Active DirectoryはPOSIX拡張機能を提供できる必要があります。PAMサービスctxhdxがad_gpo_map_remote_interactiveに追加されます。このコンテキストでのdomain-dns-nameパラメーターは、example.comのようなDNSドメイン名です。REALMは、EXAMPLE.COMのような大文字のKerberosレルム名です。NetBIOSドメイン名を設定する必要はありません。
構成設定の詳細については、sssd.confおよび
sssd-adのmanページを参照してください。
SSSDデーモンは、構成ファイルが所有者による読み取り権限のみを持つことを要求します。
sudo chmod 0600 /etc/sssd/sssd.conf
<!--NeedCopy-->
SSSDデーモンの起動
SSSDデーモンを今すぐ起動し、マシンの起動時にデーモンが起動するようにするには、次のコマンドを実行します。
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
PAM構成
次のコマンドを実行し、SSS認証とログイン時にホームディレクトリを作成オプションが選択されていることを確認します。
sudo pam-auth-update
<!--NeedCopy-->
ドメインメンバーシップの確認
Delivery Controllerは、すべてのVDAマシン(Windows VDAおよびLinux VDA)がActive Directoryにコンピューターオブジェクトを持つことを要求します。
-
adcliを使用してドメインメンバーシップを確認する場合は、
sudo adcli info domain-dns-nameコマンドを実行してドメイン情報を表示します。 -
Sambaを使用してドメインメンバーシップを確認する場合は、
sudo net ads testjoinコマンドを実行してマシンがドメインに参加していることを確認し、sudo net ads infoコマンドを実行して追加のドメインおよびコンピューターオブジェクト情報を確認します。
Kerberos構成の確認
KerberosがLinux VDAで使用するために正しく構成されていることを確認するには、システムキータブファイルが作成され、有効なキーが含まれていることを確認します。
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-->
同様のテストは、KDEまたはGnomeディスプレイマネージャーにログオンすることで実行できます。ドメイン参加の確認後、手順6:Linux VDAのインストールに進みます。
PBIS
必要なPBISパッケージのダウンロード
sudo wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
PBISインストールスクリプトを実行可能にする
sudo chmod +x pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
PBISインストールスクリプトの実行
sudo sh pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
Windowsドメインへの参加
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
sudo /opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
The ユーザーは、Active Directory ドメインにコンピューターを追加する権限を持つドメインユーザーです。ドメイン名は、たとえば example.com のようなドメインの DNS 名です。
注: Bash をデフォルトシェルとして設定するには、sudo /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 にログオンします。
sudo 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 パッケージの整合性を検証するには、次のコマンドを実行して公開キーを DEB データベースにインポートし、パッケージの整合性を確認します:
sudo apt-get install dpkg-sig gpg --import <path to the public key> dpkg-sig --verify <path to the Linux VDA package> <!--NeedCopy-->
手順 6:Linux VDA のインストール
手順 6a:Linux VDA のインストール
Debian パッケージマネージャーを使用して Linux VDA ソフトウェアをインストールします:
sudo dpkg -i xendesktopvda_<version>.debian10_amd64.deb
<!--NeedCopy-->
Debian 11.3 の依存関係リスト:
openjdk-11-jdk >= 11
imagemagick >= 8:6.9.10
ufw >= 0.36
desktop-base >= 10.0.2
libxrandr2 >= 2:1.5.1
libxtst6 >= 2:1.2.3
libxm4 >= 2.3.8
util-linux >= 2.33
gtk3-nocsd >= 3
bash >= 5.0
findutils >= 4.6.0
sed >= 4.7
cups >= 2.2
ghostscript >= 9.53~
libmspack0 >= 0.10
ibus >= 1.5
libgoogle-perftools4 >= 2.7~
libpython3.9 >= 3.9~
libsasl2-modules-gssapi-mit >= 2.1.~
libqt5widgets5 >= 5.5~
mutter >= 3.38.6~
libqrencode4 >= 4.0.0
libimlib2 >= 1.5.1
<!--NeedCopy-->
注:
このバージョンの Linux VDA がサポートする Linux ディストリビューションと Xorg バージョンのマトリックスについては、「システム要件」を参照してください。
手順 6b:Linux VDA のアップグレード(オプション)
既存のインストールを以前の 2 つのバージョンおよび LTSR リリースからアップグレードできます。
sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->
注:
既存のインストールをアップグレードすると、/etc/xdl の下の構成ファイルが上書きされます。アップグレードを実行する前に、ファイルをバックアップしてください。
手順 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 の構成
注:
ランタイム環境をセットアップする前に、OS に en_US.UTF-8 ロケールがインストールされていることを確認してください。ロケールが 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 VDA サービスは、マシンの起動後に開始されます。デフォルトでは Y に設定されています
- CTX_XDL_ADD_FIREWALL_RULES=Y | N – Linux VDA サービスは、システムファイアウォールを介して受信ネットワーク接続が許可されることを必要とします。Linux VDA のシステムファイアウォールで、必要なポート(デフォルトではポート 80 および 1494)を自動的に開くことができます。デフォルトでは Y に設定されています
- CTX_XDL_AD_INTEGRATION=winbind | quest |centrify | sssd | pbis – 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は、LDAPサーバーを検出するためにDNSをクエリします。DNSがLDAPサービスレコードを提供できない場合、LDAPポートを含むスペース区切りのLDAP FQDNリストを指定できます。例:ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268。Active Directoryフォレスト内でLDAPクエリを高速化するには、ドメインコントローラーで グローバルカタログ を有効にし、関連するLDAPポート番号を3268として指定します。この変数はデフォルトで <none> に設定されています
- CTX_XDL_SEARCH_BASE=search-base-set – Linux VDAは、Active Directoryドメインのルート(例:DC=mycompany,DC=com)に設定された検索ベースを介してLDAPをクエリします。ただし、検索パフォーマンスを向上させるために、検索ベース(例:OU=VDI,DC=mycompany,DC=com)を指定できます。この変数はデフォルトで <none> に設定されています
- CTX_XDL_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 に設定する必要があります
次の手順を実行して、ターゲットセッションユーザーのデスクトップ環境を変更することもできます
- VDA上の $HOME/<username> ディレクトリの下に
.xsessionファイルを作成します -
ディストリビューションに基づいてデスクトップ環境を指定するように
.xsessionファイルを編集します-
MATEデスクトップの場合
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi -
GNOME Classic デスクトップの場合
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi -
GNOME デスクトップの場合
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi
-
- ターゲットセッションユーザーと 700 ファイル権限を共有します。
バージョン 2209 以降、セッションユーザーはデスクトップ環境をカスタマイズできます。この機能を有効にするには、VDA に切り替え可能なデスクトップ環境を事前にインストールする必要があります。詳しくは、「セッションユーザーによるカスタムデスクトップ環境」を参照してください。
- VDA上の $HOME/<username> ディレクトリの下に
-
**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 | pbis
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 | pbis \
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 /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->
構成変更を削除するには:
sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->
重要:
このスクリプトは、データベースからすべての構成データを削除し、Linux VDA を動作不能にします。
構成ログ
ctxsetup.sh および ctxcleanup.sh スクリプトは、コンソールにエラーを表示し、追加情報は構成ログファイル /tmp/xdl.configure.log に書き込まれます。
変更を有効にするには、Linux VDA サービスを再起動します。
Linux VDA ソフトウェアのアンインストール
Linux VDA がインストールされているかどうかを確認し、インストールされているパッケージのバージョンを表示するには:
dpkg -l xendesktopvda
<!--NeedCopy-->
詳細情報を表示するには:
apt-cache show xendesktopvda
<!--NeedCopy-->
Linux VDA ソフトウェアをアンインストールするには:
dpkg -r xendesktopvda
<!--NeedCopy-->
注:
Linux VDA ソフトウェアをアンインストールすると、関連する PostgreSQL およびその他の構成データが削除されます。ただし、Linux VDA のインストール前にセットアップされた PostgreSQL パッケージおよびその他の依存パッケージは削除されません。
ヒント:
このセクションの情報には、PostgreSQL を含む依存パッケージの削除は含まれていません。
手順 9:XDPing の実行
sudo /opt/Citrix/VDA/bin/xdping を実行して、Linux VDA 環境における一般的な構成の問題を確認します。詳しくは、「XDPing」を参照してください。
手順 10:Linux VDA の実行
ctxsetup.sh スクリプトを使用して Linux VDA を構成したら、次のコマンドを使用して Linux VDA を制御します。
Linux VDA の開始:
Linux VDA サービスを開始するには:
sudo systemctl start ctxhdx
sudo systemctl start ctxvda
<!--NeedCopy-->
Linux VDA の停止:
Linux VDA サービスを停止するには:
sudo systemctl stop ctxvda
sudo systemctl stop ctxhdx
<!--NeedCopy-->
注:
ctxvda および ctxhdx サービスを停止する前に、systemctl stop ctxmonitord コマンドを実行してモニターサービスデーモンを停止してください。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
Linux VDA の再起動:
Linux VDA サービスを再起動するには:
sudo systemctl stop ctxvda
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda
<!--NeedCopy-->
Linux VDA ステータスの確認:
Linux VDA サービスの実行ステータスを確認するには:
sudo systemctl status ctxvda
sudo systemctl status ctxhdx
<!--NeedCopy-->
手順 11:マシンカタログの作成
マシンカタログを作成し、Linux VDA マシンを追加するプロセスは、従来の Windows VDA のアプローチと似ています。これらのタスクを完了する方法の詳細については、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
Linux VDA マシンを含むマシンカタログを作成する場合、Windows VDA マシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。
- オペレーティングシステムには、以下を選択します。
- ホストされた共有デスクトップ配信モデルの場合は、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:デリバリーグループの作成
デリバリーグループを作成し、Linux VDA マシンを含むマシンカタログを追加するプロセスは、Windows VDA マシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDA マシンカタログを含むデリバリーグループを作成する場合、次の制限が適用されます。
- 選択した AD ユーザーとグループが、Linux VDA マシンにログオンするように適切に構成されていることを確認してください。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- デリバリーグループと Windows マシンを含むマシンカタログを混在させないでください。
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2305」を参照してください。