Ubuntu 用 Linux Virtual Delivery Agent の手動インストール
重要:
新規インストールの場合、迅速なインストールには 簡易インストール の使用をお勧めします。簡易インストールは、時間と労力を節約し、この記事で詳述されている手動インストールよりもエラーが発生しにくいです。
手順 1: VDA インストールのための Ubuntu の準備
手順 1a: ネットワーク構成の確認
ネットワークが正しく接続され、構成されていることを確認します。たとえば、Linux VDA で DNS サーバーを構成する必要があります。
Ubuntu 18.04 Live Server を使用している場合は、ホスト名を設定する前に /etc/cloud/cloud.cfg 構成ファイルで次の変更を行います。
preserve_hostname: true
手順 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 を仮想マシンとしてホストすると、クロックスキューの問題が発生する可能性があります。このため、リモート時刻サービスとの時刻同期が推奨されます。
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: OpenJDK のインストール
Linux VDA は OpenJDK に依存しています。通常、ランタイム環境はオペレーティングシステムのインストールの一部としてインストールされます。
Ubuntu 16.04 では、次を使用して OpenJDK をインストールします。
sudo apt-get install -y default-jdk
<!--NeedCopy-->
Ubuntu 18.04 では、次を使用して OpenJDK をインストールします。
sudo apt-get install -y openjdk-8-jdk
<!--NeedCopy-->
手順 1i: PostgreSQL のインストール
Linux VDA には、Ubuntu 上で PostgreSQL バージョン 9.x が必要です。
sudo apt-get install -y postgresql
sudo apt-get install -y libpostgresql-jdbc-java
<!--NeedCopy-->
手順 1j: Motif のインストール
- sudo apt-get install -y libxm4
<!--NeedCopy-->
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libsasl2-modules-gssapi-mit
sudo apt-get install -y libldap-2.4-2
sudo apt-get install -y krb5-user
sudo apt-get install -y cups
<!--NeedCopy-->
ステップ 1l: 次のパッケージのインストール (Ubuntu 18.04 のみ)
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
ステップ 2: ハイパーバイザーの準備
サポートされているハイパーバイザー上で Linux VDA を仮想マシンとして実行する場合、いくつかの変更が必要です。使用中のハイパーバイザープラットフォームに応じて、次の変更を行ってください。Linux マシンをベアメタルハードウェアで実行している場合、変更は不要です。
Citrix Hypervisor™ での時刻同期の修正
Citrix Hypervisor の時刻同期機能が有効になっている場合、各準仮想化 Linux VM 内で NTP と Citrix Hypervisor の両方で問題が発生します。これらは両方ともシステムクロックを管理しようとします。クロックが他のサーバーと同期がずれるのを避けるため、各 Linux ゲスト内のシステムクロックが NTP と同期していることを確認してください。この場合、ホストの時刻同期を無効にする必要があります。HVM モードでは変更は不要です。
一部の Linux ディストリビューションでは、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 の設定で、統合サービスを選択します。
- 時刻の同期が選択されていることを確認します。
注:
このアプローチは、VMware および Citrix Hypervisor とは異なります。VMware および Citrix Hypervisor では、NTP との競合を避けるためにホストの時刻同期が無効になっています。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) ドメインに追加するためのいくつかの方法をサポートしています。
選択した方法に基づいて手順に従ってください。
注:
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-->
Kerberos の構成
ルートユーザーとして /etc/krb5.conf を開き、次の設定を行います。
[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
<!--NeedCopy-->
このコンテキストでの domain-dns-name プロパティは、example.com などの DNS ドメイン名です。REALM は、EXAMPLE.COM などの大文字の Kerberos レルム名です。
Winbind 認証の構成
Ubuntu には RHEL の authconfig や SUSE の yast2 のようなツールがないため、Winbind を手動で構成します。
/etc/samba/smb.conf を開き、次の設定を行います。
[global]
workgroup = WORKGROUP
security = ADS
realm = REALM
encrypt passwords = yes
idmap config *:range = 16777216-33554431
winbind trusted domains only = no
kerberos method = secrets and keytab
winbind refresh tickets = yes
template shell = /bin/bash
<!--NeedCopy-->
WORKGROUP は REALM の最初のフィールドであり、REALM は大文字の Kerberos レルム名です。
nsswitch の構成
/etc/nsswitch.conf を開き、次の行に winbind を追加します。
passwd: compat winbind
group: compat winbind
Windows ドメインへの参加
ドメインコントローラーに到達可能である必要があり、コンピューターをドメインに追加する権限を持つ Active Directory ユーザーアカウントが必要です。
sudo net ads join REALM -U user
<!--NeedCopy-->
ここで、REALM は大文字の Kerberos レルム名であり、user はコンピューターをドメインに追加する権限を持つドメインユーザーです。
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 のインストールに進みます。
ヒント:
ユーザー認証に成功しても、ドメインアカウントでログオンしたときにデスクトップが表示されない場合は、マシンを再起動してから再試行してください。
Quest Authentication Services
ドメインコントローラーでの Quest の構成
Active Directory ドメインコントローラーに Quest ソフトウェアをインストールおよび構成済みであり、Active Directory でコンピューターオブジェクトを作成するための管理者権限が付与されているものとします。
ドメインユーザーが Linux VDA マシンにログオンできるようにする
ドメインユーザーが Linux VDA マシンで HDX™ セッションを確立できるようにするには、次の手順を実行します。
- Active Directory ユーザーとコンピューター管理コンソールで、そのユーザーアカウントの Active Directory ユーザープロパティを開きます
- Unix アカウント タブを選択します
- Unix-enabled をオンにします
- プライマリ GID 番号 を実際のドメインユーザーグループのグループ ID に設定します
注:
これらの手順は、コンソール、RDP、SSH、またはその他のリモートプロトコルを使用してログオンするドメインユーザーを設定する場合にも同様に適用されます。
Linux VDA での Quest の構成
SELinux ポリシー強制の回避策
デフォルトの RHEL 環境では、SELinux が完全に強制されています。この強制は、Quest が使用する Unix ドメインソケット IPC メカニズムと干渉し、ドメインユーザーがログオンできないようにします。
この問題を回避する便利な方法は、SELinux を無効にすることです。root ユーザーとして /etc/selinux/config を編集し、SELinux 設定を変更します。
SELINUX=disabled
この変更にはマシンの再起動が必要です。
reboot
<!--NeedCopy-->
重要:
この設定は慎重に使用してください。無効にした後に SELinux ポリシー強制を再度有効にすると、root ユーザーや他のローカルユーザーであっても、完全にロックアウトされる可能性があります。
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 ドメインに参加させる権限を持つ任意のドメインユーザーです。domain-name は、たとえば example.com のようなドメインの DNS 名です。
ドメインメンバーシップの確認
Delivery Controller は、Windows または Linux のいずれであっても、すべての VDA マシンが Active Directory にコンピューターオブジェクトを持つことを要求します。Quest で参加した Linux マシンがドメイン上にあることを確認するには、次のようにします。
sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->
マシンがドメインに参加している場合、このコマンドはドメイン名を返します。マシンがどのドメインにも参加していない場合、次のエラーが表示されます。
ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain
ユーザー認証の確認
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-->
ドメイン参加の確認後、手順 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-->
SSSD
Kerberos の構成
Kerberos をインストールするには、次のコマンドを実行します。
sudo apt-get install krb5-user
<!--NeedCopy-->
Kerberos を構成するには、root として /etc/krb5.conf を開き、次の設定を行います。
[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
<!--NeedCopy-->
このコンテキストでの domain-dns-name プロパティは、example.com のような DNS ドメイン名です。REALM は、EXAMPLE.COM のような大文字の Kerberos レルム名です。
ドメインへの参加
SSSD は、Active Directory を ID プロバイダーとして、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に必要です。- システムキータブの確認。
adcliツールの機能は限られており、マシンがドメインに参加しているかどうかをテストする方法は提供されていません。システムキータブファイルが作成されたことを確認するための最良の代替手段は次のとおりです。sudo klist -ket <!--NeedCopy-->- 各キーのタイムスタンプが、マシンがドメインに参加した時刻と一致することを確認します。
Sambaを使用してドメインに参加する場合は、次の手順を実行します。- パッケージのインストール
sudo apt-get install samba <!--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 <!--NeedCopy-->WORKGROUP は REALM の最初のフィールドであり、REALM は大文字の Kerberos レルム名です。
-
-
Sambaを使用したドメインへの参加ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つ Windows アカウントが必要です。
sudo net ads join REALM -U user <!--NeedCopy-->ここで、REALM は大文字の Kerberos レルム名であり、user はコンピューターをドメインに追加する権限を持つドメインユーザーです。
SSSD のセットアップ
必要なパッケージのインストールまたは更新:
必要な SSSD および構成パッケージがまだインストールされていない場合は、インストールします。
sudo apt-get install sssd
<!--NeedCopy-->
パッケージがすでにインストールされている場合は、更新をお勧めします。
sudo apt-get install --only-upgrade sssd
<!--NeedCopy-->
注:
デフォルトでは、Ubuntu のインストールプロセスは nsswitch.conf と PAM ログインモジュールを自動的に構成します。
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
<!--NeedCopy-->
注:
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-->
sudo pam-auth-update
<!--NeedCopy-->
ドメインメンバーシップの確認
Delivery Controller は、すべての VDA マシン (Windows および Linux VDA) が Active Directory にコンピューターオブジェクトを持つことを要求します。
- `adcli` を使用してドメインメンバーシップを確認する場合は、`sudo adcli info domain-dns-name` コマンドを実行してドメイン情報を表示します。
- `Samba` を使用してドメインメンバーシップを確認する場合は、`sudo net ads testjoin` コマンドを実行してマシンがドメインに参加していることを確認し、`sudo net ads info` コマンドを実行して追加のドメインおよびコンピューターオブジェクト情報を確認します。
Kerberos 構成の確認
Linux VDA で使用するために 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-->
同様のテストは、KDE または Gnome Display Manager にログオンすることで実行できます。ドメイン参加の確認後、手順 6: Linux VDA のインストールに進みます。
PBIS
必要な PBIS パッケージのダウンロード
例:
sudo wget https://github.com/BeyondTrust/pbis-open/releases/download/8.8.0/pbis-open-8.8.0.506.linux.x86_64.deb.sh
<!--NeedCopy-->
PBISインストールスクリプトの実行可能化
例：
sudo chmod +x pbis-open-8.8.0.506.linux.x86_64.deb.sh
<!--NeedCopy-->
PBISインストールスクリプトの実行
例：
sudo sh pbis-open-8.8.0.506.linux.x86_64.deb.sh
<!--NeedCopy-->
Windowsドメインへの参加
ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つActive Directoryユーザーアカウントが必要です。
sudo /opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
ユーザーは、コンピューターを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 Core Runtimeのインストール
Linux VDAをインストールする前に、https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managersの指示に従って.NET Core Runtimeをインストールします。
- 1912 LTSRの初期リリース、CU1、およびCU2の場合、.NET Core Runtime 2.1をインストール
- CU3以降のリリースの場合、.NET Core Runtime 3.1をインストール
.NET Core Runtimeのインストール後、which dotnetコマンドを実行してランタイムパスを見つけます。
コマンド出力に基づいて、.NET Coreランタイムバイナリパスを設定します。たとえば、コマンド出力が/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：Linux VDAのインストール
Debianパッケージマネージャーを使用してLinux VDAソフトウェアをインストールします。
Ubuntu 18.04の場合：
sudo dpkg -i xendesktopvda_19.12.0.50-1.ubuntu18.04_amd64.deb
<!--NeedCopy-->
Ubuntu 16.04の場合：
sudo dpkg -i xendesktopvda_19.12.0.50-1.ubuntu16.04_amd64.deb
<!--NeedCopy-->
Ubuntu 18.04のDebian依存関係リスト：
postgresql >= 9.5
libpostgresql-jdbc-java >= 9.2
openjdk-8-jdk >= 1.8.0
gtk3-nocsd >=3
imagemagick >= 8:6.8.9.9
ufw >= 0.35
ubuntu-desktop >= 1.361
libxrandr2 >= 2:1.5.0
libxtst6 >= 2:1.2.2
libxm4 >= 2.3.4
util-linux >= 2.27.1
bash >= 4.3
findutils >= 4.6.0
sed >= 4.2.2
cups >= 2.1
libldap-2.4-2 >= 2.4.42
libsasl2-modules-gssapi-mit >= 2.1.~
python-requests >= 2.9.1
libgoogle-perftools4 >= 2.4~
xserver-xorg-core >= 2:1.18
xserver-xorg-core << 2:1.19
x11vnc>=0.9.13
python-websockify >= 0.6.1
<!--NeedCopy-->
Ubuntu 16.04のDebian依存関係リスト：
postgresql >= 9.5
libpostgresql-jdbc-java >= 9.2
default-jdk >= 2:1.8
imagemagick >= 8:6.8.9.9
ufw >= 0.35
ubuntu-desktop >= 1.361
libxrandr2 >= 2:1.5.0
libxtst6 >= 2:1.2.2
libxm4 >= 2.3.4
util-linux >= 2.27.1
bash >= 4.3
findutils >= 4.6.0
sed >= 4.2.2
cups >= 2.1
libldap-2.4-2 >= 2.4.42
libsasl2-modules-gssapi-mit >= 2.1.~
python-requests >= 2.9.1
libgoogle-perftools4 >= 2.4~
xserver-xorg-core >= 2:1.18
xserver-xorg-core << 2:1.19
x11vnc>=0.9.13
python-websockify >= 0.6.1
<!--NeedCopy-->
注：
このバージョンのLinux VDAがサポートするLinuxディストリビューションとXorgバージョンのマトリックスについては、システム要件を参照してください。
ステップ6b：Linux VDAのアップグレード（オプション）
既存のインストールを以前の2つのバージョンおよびLTSRリリースからアップグレードできます。
sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->
ステップ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)
NVIDIA GRIDゲストVMドライバーをインストールおよび構成するには、次の一般的な手順を実行します。
- ゲストVMがシャットダウンされていることを確認
- ハイパーバイザーのコントロールパネルで、VMにGPUを割り当て
- VMを起動
- VMにゲストVMドライバーをインストール
ステップ8：Linux VDAの構成
パッケージのインストール後、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ポートを介してDelivery Controllerと通信します。デフォルトではポート80です。
-
**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 5** – Linux VDAは、Delivery Controllerとの認証のためにKerberos構成設定を必要とします。Kerberos構成は、システムにインストールおよび構成されているActive Directory統合ツールから決定されます。使用するサポートされているActive Directory統合方法を指定します。 - 1 – Samba Winbind
- 2 – Quest Authentication Services
- 3 – Centrify DirectControl
- 4 – SSSD
- 5 – PBIS
-
**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 Core Runtimeをインストールするパス。デフォルトのパスは/usr/binです。 -
**CTX_XDL_START_SERVICE=Y N** – Linux VDAの構成が完了したときにLinux VDAサービスを開始するかどうか。デフォルトではYに設定されています。
環境変数を設定し、構成スクリプトを実行します。
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|5
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_START_SERVICE=Y|N
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
sudoコマンドを実行する際は、既存の環境変数を新しく作成されるシェルに渡すために-Eオプションを入力します。Citrixは、上記のコマンドから、最初の行に#!/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|5 \
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_START_SERVICE=Y|N \
/opt/Citrix/VDA/sbin/ctxsetup.sh
<!--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の実行
Linux VDA環境における一般的な構成の問題を確認するためのコマンドラインユーティリティであるLinux XDPingツールを提供しています。XDPingパッケージは、サポートされているLinuxディストリビューションを実行している任意のマシンにインストールできます。XDPingは、Linux VDAパッケージがマシンにインストールされている必要はありません。このツールの詳細については、Knowledge Centerの記事CTX202015を参照してください。
ステップ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サービスを停止する前に、service ctxmonitorservice stopコマンドを実行してモニターサービスデーモンを停止してください。そうしないと、モニターサービスデーモンが停止したサービスを再起動します。
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：Citrix Virtual AppsまたはCitrix Virtual Desktops™でのマシンカタログ作成
マシンカタログを作成し、Linux VDAマシンを追加するプロセスは、従来のWindows VDAのアプローチと同様です。これらのタスクを完了する方法の詳細については、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
Linux VDAマシンを含むマシンカタログを作成する場合、Windows VDAマシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。
- オペレーティングシステムについては、以下を選択します。
- ホスト型共有デスクトップ配信モデルの場合は、Multi-session OSオプション
- VDI専用デスクトップ配信モデルのシングルセッション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マシンを含むマシンカタログを混在させないでください。
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 1912 LTSR」を参照してください。
この記事の概要
- 手順 1: VDA インストールのための Ubuntu の準備
- ステップ 2: ハイパーバイザーの準備
- ステップ 3: Linux 仮想マシン (VM) を Windows ドメインに追加
- ステップ4：前提条件としての.NET Core Runtimeのインストール
- ステップ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でのデリバリーグループの作成