Debian 用 Linux Virtual Delivery Agent の手動インストール
重要:
新規インストールの場合、迅速なインストールには簡易インストールを使用することをお勧めします。簡易インストールは、時間と労力を節約し、この記事で詳述されている手動インストールよりもエラーが発生しにくくなっています。
ステップ 1: VDA インストールのための Debian の準備
ステップ 1a: ネットワーク構成の確認
ネットワークが正しく接続され、構成されていることを確認してください。たとえば、Linux VDA 上で DNS サーバーを構成する必要があります。
ステップ 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: パッケージのインストール
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
-
ステップ 1i: oldstable リポジトリの追加
- Debian ディストリビューションに必要な依存関係をインストールするには、
/etc/apt/sources.listファイルにdeb http://deb.debian.org/debian/ oldstable mainの行を追加します。
ステップ 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 の設定で、Integration Services を選択します。
- Time synchronization が選択されていることを確認します。
注記:
このアプローチは、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: 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-->
注記:
winbind スクリプトが
/etc/init.dの下にあることを確認してください。
Kerberos の構成
ルートユーザーとして /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 認証の構成
/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
WORKGROUP は REALM の最初のフィールドであり、REALM は大文字の Kerberos レルム名です。
nsswitch の構成
/etc/nsswitch.conf を開き、次の行に winbind を追加します。
passwd: systemd winbind
group: systemd 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 authentication および Create home directory on login オプションが選択されていることを確認します。
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 設定の確認
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-->
ここで指定するドメインは、Kerberos レルム名ではなく、AD ドメイン名です。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 認証サービス
ドメインコントローラーでの 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 ドメインに参加させる権限を持つ任意のドメインユーザーです。ドメイン名とは、たとえば 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エージェントがインストールされている状態で、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 を開き、パラメーターを設定します。
注:
KerberosはADインフラストラクチャに基づいて構成してください。以下の設定は、単一ドメイン、単一フォレストモデルを対象としています。
[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レルム名です。
-
ドメインへの参加
-
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にとって必要です。 -
-
システムキータブの確認
sudo klist -ketコマンドを実行して、システムキータブファイルが作成されていることを確認します。各キーのタイムスタンプが、マシンがドメインに参加した時刻と一致することを確認します。
Sambaを使用してドメインに参加する場合、次の手順を完了します。
-
パッケージをインストール
sudo apt-get install samba krb5-user <!--NeedCopy--> -
Samba の構成
- /etc/samba/smb.conf を開き、次の設定を行います。
[global]workgroup =WORKGROUPsecurity = ADSrealm =REALMclient signing = yesclient use spnego = yeskerberos method = secrets and keytabWORKGROUP は 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
# TGT の更新ライフタイムが 14 日よりも長い場合は、krb5_renewable_lifetime を高く設定します
krb5_renewable_lifetime = 14d
# TGT チケットのライフタイムが 2 時間よりも短い場合は、krb5_renew_interval を低く設定します
krb5_renew_interval = 1h
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# この ldap_id_mapping 設定はデフォルト値でもあります
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-->
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 構成の確認
Kerberos が Linux VDA で使用するために正しく構成されていることを確認するには、システム 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-->
同様のテストは、KDE または Gnome ディスプレイマネージャーにログオンすることで実行できます。ドメイン参加の確認後、手順 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-->
user は、Active Directory ドメインにコンピューターを追加する権限を持つドメインユーザーです。domain-name はドメインの DNS 名です(例:example.com)。
注: 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 3.1 のインストール
Linux VDA をインストールする前に、https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers の手順に従って .NET Core Runtime 3.1 をインストールします。
.NET Core Runtime 3.1 のインストール後、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 ソフトウェアをインストールします。
sudo dpkg -i xendesktopvda_<version>.debian10_amd64.deb
<!--NeedCopy-->
Debian 10.9 の Debian 依存関係リスト:
libqt5widgets5 >= 5.5~
ibus >= 1.5
postgresql >= 11
libpostgresql-jdbc-java >= 42.2
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.27~
libmspack0 >= 0.10
libgoogle-perftools4 >= 2.7~
libpython2.7 >= 2.7~
libsasl2-modules-gssapi-mit >= 2.1.~
<!--NeedCopy-->
注:
このバージョンの Linux VDA がサポートする Linux ディストリビューションと Xorg バージョンのマトリックスについては、「システム要件」を参照してください。
手順 6b:Linux VDA のアップグレード(オプション)
既存のインストールを以前の 2 つのバージョンおよび LTSR リリースからアップグレードできます。
sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->
注:
既存のインストールをアップグレードすると、/etc/xdl の下の構成ファイルが上書きされます。アップグレードを実行する前に、ファイルをバックアップしてください。
手順 7: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レコードを使用してデリバリーコントローラー名を指定することをサポートしています。デフォルトではNに設定されています。
- CTX_XDL_DDC_LIST=’list-ddc-fqdns’ – Linux VDAは、デリバリーコントローラーへの登録に使用するデリバリーコントローラーの完全修飾ドメイン名(FQDN)をスペース区切りでリストする必要があります。少なくとも1つのFQDNまたはCNAMEエイリアスを指定する必要があります。
- CTX_XDL_VDA_PORT=port-number – Linux VDAは、TCP/IPポートを介してデリバリーコントローラーと通信します。デフォルトのポートは80です。
- CTX_XDL_REGISTER_SERVICE=Y | N – Linux仮想デスクトップサービスは、マシンの起動後に開始されます。デフォルトではYに設定されています。
- CTX_XDL_ADD_FIREWALL_RULES=Y | N – Linux仮想デスクトップサービスでは、システムファイアウォールを介して受信ネットワーク接続が許可されている必要があります。Linux仮想デスクトップの場合、必要なポート(デフォルトではポート80および1494)をシステムファイアウォールで自動的に開くことができます。デフォルトではYに設定されています。
-
CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 |5 – Linux VDAは、デリバリーコントローラーで認証するためにKerberos構成設定を必要とします。Kerberos構成は、システムにインストールおよび構成されているActive Directory統合ツールから決定されます。使用するサポートされているActive Directory統合方法を指定します。
- 1 – Samba Winbind
- 2 – Quest Authentication Service
- 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は、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 Core Runtime 3.1をインストールするパスです。デフォルトのパスは/usr/binです。 -
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/mate – セッションで使用するGNOMEまたはMATEデスクトップ環境を指定します。変数を指定しない場合、VDAに現在インストールされているデスクトップが使用されます。ただし、現在インストールされているデスクトップがMATEの場合、変数値をmateに設定する必要があります。
注:
ターゲットセッションユーザーのデスクトップ環境は、次の手順で変更することもできます。
- VDA上の$HOME/<username>ディレクトリの下に
.xsessionファイルを作成します。 -
.xsessionファイルを編集して、ディストリビューションに基づいてデスクトップ環境を指定します。CentOS、Ubuntu、Debian上のMATEデスクトップの場合
MSESSION=”$(type -p mate-session)” if [ -n “$MSESSION” ]; then exec mate-session fi
CentOS上のGNOMEデスクトップの場合
GSESSION=”$(type -p gnome-session)” if [ -n “$GSESSION” ]; then
export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi **UbuntuおよびDebian上のGNOMEデスクトップの場合**GSESSION=”$(type -p gnome-session)” if [ -n “$GSESSION” ]; then
exec gnome-session fi - ターゲットセッションユーザーと700ファイル権限を共有します。
- 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=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_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|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_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 /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を含む依存パッケージの削除は含まれていません。
ステップ 8: XDPingの実行
sudo /opt/Citrix/VDA/bin/xdpingを実行して、Linux VDA環境における一般的な構成の問題を確認します。詳細については、「XDPing」を参照してください。
ステップ 9: 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-->
ステップ 10: Citrix Virtual AppsまたはCitrix Virtual Desktops™でのマシンカタログ作成
マシンカタログを作成し、Linux VDAマシンを追加するプロセスは、従来のWindows VDAのアプローチと似ています。これらのタスクを完了する方法の詳細については、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
Linux VDAマシンを含むマシンカタログを作成する場合、Windows VDAマシン用のマシンカタログを作成するプロセスとは異なるいくつかの制限があります。
- オペレーティングシステムについては、以下を選択します。
- ホスト型共有デスクトップ配信モデルの場合は、マルチセッションOSオプション
- VDI専用デスクトップ配信モデルの場合は、シングルセッションOSオプション
- 同じマシンカタログ内でLinux VDAマシンとWindows VDAマシンを混在させないでください。
注:
Citrix Studioの初期バージョンでは、「Linux OS」という概念はサポートされていませんでした。ただし、Windows Server OSまたはServer OSオプションを選択すると、同等のホスト型共有デスクトップ配信モデルが意味されます。Windows Desktop OSまたはDesktop OSオプションを選択すると、マシンあたり1ユーザーの配信モデルが意味されます。
ヒント:
マシンをActive Directoryドメインから削除して再参加させる場合、そのマシンをマシンカタログから削除し、再度追加する必要があります。
ステップ 11: Citrix Virtual Apps™またはCitrix Virtual Desktopsでのデリバリーグループ作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加するプロセスは、Windows VDAマシンとほぼ同じです。これらのタスクを完了する方法の詳細については、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合、以下の制限が適用されます。
- 選択したADユーザーとグループが、Linux VDAマシンにログオンするように適切に構成されていることを確認してください
- 認証されていない(匿名)ユーザーのログオンを許可しないでください
- デリバリーグループとWindowsマシンを含むマシンカタログを混在させないでください
マシンカタログとデリバリーグループの作成方法については、「Citrix Virtual Apps and Desktops 7 2109」を参照してください。
この記事の概要
- ステップ 1: VDA インストールのための Debian の準備
- ステップ 2: ハイパーバイザーの準備
- ステップ 3: Linux 仮想マシン (VM) を Windows ドメインに追加
- 手順 4:前提条件としての .NET Core Runtime 3.1 のインストール
- 手順 5:Linux VDA パッケージのダウンロード
- 手順 6:Linux VDA のインストール
- 手順 7:Linux VDA の構成
- ステップ 8: XDPingの実行
- ステップ 9: Linux VDAの実行
- ステップ 10: Citrix Virtual AppsまたはCitrix Virtual Desktops™でのマシンカタログ作成
- ステップ 11: Citrix Virtual Apps™またはCitrix Virtual Desktopsでのデリバリーグループ作成