Linux Virtual Delivery Agent for Ubuntuのインストール
この記事の手順に従って手動でインストールするか、簡単インストールを使用して自動でインストールして構成するかを選択できます。簡単インストールは時間と労力を節約するだけでなく、手動のインストールよりもエラーを減らすことができます。
注
:新規のインストールでは、簡単インストールのみを使用します。既存インストールの更新には、簡単インストールを使用しないでください。
手順1:Ubuntu for VDAをインストールする準備
手順1a:ネットワーク構成の確認
続行前にネットワークの接続と、適切に構成されていることを確認します。
手順1b:ホスト名の設定
マシンのホスト名が確実に正しく報告されるようにするには、/etc/hostname ファイルを変更してマシンのホスト名のみを記述します。
hostname
手順1c:ホスト名へのループバックアドレスの割り当て
マシンのDNSドメイン名と完全修飾ドメイン名(FQDN)が確実に正しく報告されるようにするには、/etc/hosts ファイルの以下の行を変更し、最初の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)ではなく、そのホスト名のみが返されます。
次のコマンドで、完全修飾ドメイン名が正しく設定されていることを確認します:
hostname -f
<!--NeedCopy-->
このコマンドにより、そのマシンの完全修飾ドメイン名が返されます。
手順1e:マルチキャストDNSの無効化
デフォルトの設定でマルチキャストDNS(mDNS)が有効であるため、名前解決の結果に不整合が発生する場合があります。
mDNSを無効にするには、/etc/nsswitch.confを編集して、以下を含む行を変更します:
hosts: files mdns_minimal [NOTFOUND=return] dns
変更後:
hosts: files dns
手順1f:名前解決とサービス到達可能性の確認
次のコマンドで、完全修飾ドメイン名が解決できることと、ドメインコントローラーとDelivery Controllerからpingに応答があることを確認します:
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
完全修飾ドメイン名を解決できない、またはこれらのマシンのいずれかからpingに応答がない場合は、手順を確認してから次に進んでください。
手順1g:時刻同期の構成(chrony)
VDA、Delivery Controller、ドメインコントローラーの間で正確な時刻同期を維持することは重要です。仮想マシンとしてLinux VDAをホストすると、時刻が不正確になる問題が発生する可能性があります。したがって、リモートのタイムサービスを使用して時刻を維持することをお勧めします。
chronyのインストール:
apt-get install chrony
<!--NeedCopy-->
ルートユーザーとして /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 エントリなど、一覧にあるその他のサーバーまたはプールエントリを削除します。
変更を保存してから、次のコマンドでChronyデーモンを再起動します:
sudo systemctl restart chrony
<!--NeedCopy-->
手順1h:OpenJDKのインストール
Linux VDAはOpenJDKに依存しています。通常、Runtime Environmentは、オペレーティングシステムの一部としてインストールされています。次のコマンドで、インストールされているか確認してください。
sudo apt-get install -y default-jdk
<!--NeedCopy-->
手順1i:PostgreSQLのインストール
Linux VDAには、Ubuntu 16.04に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-->
手順1k:他のパッケージのインストール
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-->
手順2:ハイパーバイザーの準備
サポートされるハイパーバイザー上で仮想マシンとしてLinux VDAを実行する場合、いくつかの変更が必要です。使用するハイパーバイザーのプラットフォームに合わせて、次の変更を行います。ベアメタルハードウェアでLinuxマシンを実行する場合、変更は必要ありません。
Citrix XenServerでの時刻同期の修正
XenServerの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとXenServerの両方がシステムの時間を管理しようとすることが原因となり問題が発生します。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。HVMモードでは、変更は必要ありません。
一部のLinuxディストリビューションでは、XenServer Toolsがインストールされた準仮想化Linuxカーネルを実行している場合、XenServerの時刻同期機能が存在するかどうかと、Linux仮想マシン内で有効になっているかどうかを確認できます:
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
このコマンドは0または1を返します:
- 0 - 時刻同期機能が有効になっているため、無効にする必要があります。
- 1 - 時刻同期機能が無効になっています。これ以上の操作は必要ありません。
/proc/sys/xen/indepent_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統合サービスがインストールされたLinux仮想マシンでは、Hyper-Vの時刻同期機能を使用してホストオペレーティングシステムの時間を利用できます。システムの時間を正確な状態で維持するには、NTPサービスとともにこの機能を有効にする必要があります。
管理オペレーティングシステムで、次の操作を行います。
- Hyper-Vマネージャーを開きます。
- Linux仮想マシンの設定で、[統合サービス] を選択します。
- [時刻の同期] が選択されていることを確認します。
注:
この方法はVMwareおよびXenServerの場合とは異なります。VMwareおよびXenServerでは、NTPとの競合を避けるためにホストの時刻同期を無効にします。Hyper-Vの時刻同期は、NTPと共存し、NTPの時刻同期を補完することができます。
ESXおよびESXiでの時刻同期の修正
VMwareの時刻同期機能が有効な場合、それぞれの準仮想化Linux仮想マシンで、NTPとハイパーバイザーの両方がシステムの時間を同期しようとすることが原因となり問題が発生します。システムの時間と他のサーバーの時間との同期が失われるのを防ぐには、各Linuxゲストのシステムの時間がNTPと同期する必要があります。この場合、ホストの時刻同期を無効にする必要があります。
VMware Toolsをインストールした状態で準仮想化Linuxカーネルを実行している場合は、次の操作を行います。
- vSphere Clientを開きます。
- Linux仮想マシンの設定を編集します。
- [仮想マシンのプロパティ] ダイアログボックスで、[オプション] タブをクリックします。
- [VMware Tools] を選択します。
- [詳細] ボックスで、[ホストとゲスト時刻を同期] チェックボックスをオフにします。
手順3:Linux仮想マシン(VM)をWindowsドメインに追加
Linux VDAは、LinuxマシンをActive Directory(AD)ドメインに追加するさまざまな方法をサポートします。
- Samba Winbind
- Quest Authentication Service
- Centrify DirectControl
- SSSD
選択した方法の手順に従います。
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プロパティは、DNSドメイン名(example.comなど)です。REALMは、大文字のKerberos領域名(EXAMPLE.COMなど)です。
Winbind認証の構成
RHELのauthconfig
や、SUSEのyast2のようなツールがUbuntuにないため、手動で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 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ファイルが作成済みで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シェルの場合、バックスラッシュ文字(\)は、もう1つバックスラッシュ文字を指定してエスケープする必要があります。このコマンドにより、成功または失敗を示すメッセージが返されます。
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コンソールに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順4:Linux VDAのインストール」に進みます。
ヒント:
ユーザー認証に成功しても、ドメインアカウントでログオンしたときにデスクトップを表示できない場合、マシンを再起動して再試行します。
Quest Authentication Service
ドメインコントローラーでのQuestの構成
次の操作は、QuestソフトウェアをActive Directoryドメインコントローラーにインストールし、構成していることと、管理者特権が付与され、Active Directoryにコンピューターオブジェクトを作成できることを前提としています。
Linux VDAマシンにドメインユーザーがログオンできるようにする
Linux VDAマシンでHDXセッションを確立する必要がある各ドメインユーザーに対して、次の操作を行います。
- [Active Directoryユーザーとコンピューター]管理コンソールで、目的のユーザーアカウントのActive Directoryユーザーのプロパティを開きます。
- [Unixアカウント] タブを選択します。
- [Unix対応] チェックボックスをオンにします。
- [プライマリGID番号] を、実際のドメインユーザーグループのグループIDに設定します。
注:
この手順は、ドメインユーザーがコンソール、RDP、SSH、またはその他のリモート処理プロトコルを使用してログオンできるように設定する場合も同じです。
Linux VDAでのQuestの構成
SELinuxポリシー適用の回避策
デフォルトのRHEL環境では、SELinuxが完全に適用されています。この適用により、Questが使用するUnixドメインソケットのIPCのメカニズムに干渉し、ドメインユーザーのログオンを妨げます。
この問題を回避するための便利な方法は、SELinuxの無効化です。ルートユーザーとして、/etc/selinux/config を編集し、SELinux設定を次のとおりに変更します:
SELINUX=disabled
この変更にはマシンの再起動が必要です:
reboot
<!--NeedCopy-->
重要:
この設定は注意して使用してください。SELinuxポリシーの適用を無効にした後に再度有効にすると、ルートユーザーやその他のローカルユーザーであっても、完全にロックアウトされてしまう可能性があります。
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-->
userは、コンピューターをActive Directoryドメインに追加する権限を持つ任意のドメインユーザーです。domain-nameは、ドメインのDNS名(example.comなど)です。
ドメインメンバーシップの確認
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
ユーザー認証の確認
PAMを使用したQuestのドメインユーザーの認証が可能かどうかを確認するには、ドメインユーザーアカウントを使用して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-->
ドメイン参加の確認後、「手順4: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が返されることを確認します。CentrifyDC modeがstartingのまま変化しない場合は、Centrifyクライアントにサーバーとの接続の問題、または認証の問題が発生しています。
次を使用すると、より包括的なシステム情報と診断情報を取得できます。
adinfo --sysinfo all
adinfo --diag
<!--NeedCopy-->
さまざまなActive DirectoryおよびKerberosサービスとの接続をテストします。
adinfo --test
<!--NeedCopy-->
ドメイン参加の確認後、「手順4:Linux VDAのインストール」に進みます。
SSSD
Kerberosの構成
Kerberosをインストールするには、次のコマンドを実行します:
sudo apt-get install krb5-user
<!--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
プロパティは、DNSドメイン名(example.com
など)です。REALM
は大文字のKerberos領域名で、EXAMPLE.COM
などです。
ドメインに参加する
SSSDを構成して、Active DirectoryをIDプロバイダーおよび認証のKerberosとして使用します。ただし、SSSDでは、ドメイン参加とシステムのkeytabファイルの管理に関するADのクライアント機能が提供されていません。代わりにadcli
、realmd
またはSamba
を使用できます。
注:
このセクションでは、
adcli
とSamba
に関する情報のみを提供します。
adcliを使用してドメインに参加させる:
adcliのインストール:
必要なパッケージをインストールします。
sudo apt-get install adcli
<!--NeedCopy-->
adcliでドメインに参加させる:
次を使用して古いシステムkeytabファイルを削除し、ドメインに参加させます。
su -
rm -rf /etc/krb5.keytab
adcli join domain-dns-name -U user -H hostname-fqdn
<!--NeedCopy-->
userは、ドメインにマシンを追加する権限があるドメインユーザーです。hostname-fqdn は、完全修飾ドメイン名形式のマシンのホスト名です。
-H オプションは、adcliが、Linux VDAで必要なhost/hostname-fqdn@REALMという形式でSPNを生成するのに必要です。
システムのKeytabの確認:
adcliツールの機能は限られており、マシンがドメインに参加しているかどうかをテストする方法は提供されていません。システムのkeytabファイルが作成されていることを確認するための最良の代替方法:
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 update 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プロパティは、DNSドメイン名(example.comなど)です。REALMは、大文字のKerberos領域名(EXAMPLE.COMなど)です。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 authentication] オプションと [Create home directory on login] オプションが選択されているようにします:
sudo pam-auth-update
<!--NeedCopy-->
ドメインメンバーシップの確認
Delivery Controllerを使用するには、すべてのVDAマシン(WindowsとLinux VDA)でActive Directoryにコンピューターオブジェクトが必要です。
adcliを使用したドメインメンバーシップの確認:
次のコマンドを実行して、ドメイン情報を表示します。
sudo adcli info domain-dns-name
<!--NeedCopy-->
sambaを使用したドメインメンバーシップの確認:
次のように、Sambaのnet ads
コマンドを実行して、マシンがドメインに参加していることを確認します:
sudo net ads testjoin
<!--NeedCopy-->
追加のドメインおよびコンピューターオブジェクト情報を検証するには、次のコマンドを実行します:
sudo net ads info
<!--NeedCopy-->
Kerberos構成の確認
Linux VDAで使用できるようにKerberosが正しく構成されていることを確認するには、次のコマンドによって、システムのkeytabファイルが作成済みで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チケットが正しく、期限切れではないことを確認します。
ルートユーザーとして、前述の id -u コマンドで返されたUIDに対応するチケットキャッシュファイルが作成されたことを確認します:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
KDEまたはGnome Display Managerに直接ログオンすると、同様のテストを実行できます。ドメイン参加の確認後、「手順4:Linux VDAのインストール」に進みます。
手順4:Linux VDAのインストール
手順4a:Linux VDAパッケージのダウンロード
Citrix Webサイトにアクセスし、環境のLinuxディストリビューションに基づいて適切なLinux VDAパッケージをダウンロードします。
手順4b:Linux VDAのインストール
次のように、Debian Package Managerを使用してLinux VDAソフトウェアをインストールします。
sudo dpkg -i xendesktopvda_7.15.0.404-1.ubuntu16.04_amd64.deb
<!--NeedCopy-->
Ubuntuの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~
<!--NeedCopy-->
手順4c: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つまたは複数の完全修飾ドメイン名または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では、HDX 3D Proがサポートされます。これは、強力なグラフィックアプリケーションの仮想化を最適にするための一連のグラフィックアクセラレーションテクノロジです。HDX 3D Proを選択した場合、Virtual Delivery Agentは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のFQDNおよびLDAPポートのスペース区切りの一覧を指定できます。たとえば、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_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
export CTX_XDL_HDX_3D_PRO=Y|N
export CTX_XDL_VDI_MODE=Y|N
export CTX_XDL_SITE_NAME=dns-name
export CTX_XDL_LDAP_LIST=list-ldap-servers
export CTX_XDL_SEARCH_BASE=search-base-set
export CTX_XDL_START_SERVICE=Y|N
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
sudoコマンドに-Eオプションを指定して実行し、作成する新しいシェルに既存の環境変数を渡します。最初の行として #!/bin/bash を記述し、前述のコマンドからなるシェルスクリプトファイルを作成することをCitrixではお勧めします。
または、次のようにして、1つのコマンドですべてのパラメーターを指定することができます。
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_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など、依存するパッケージの削除方法については説明していません。
手順5: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-->
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-->
手順6:XenAppまたはXenDesktopでマシンカタログを作成
マシンカタログを作成し、Linux VDAマシンを追加する手順は、従来のWindows VDAでの方法と似ています。このタスクを完了する方法の説明について詳しくは、「マシンカタログの作成」および「マシンカタログの管理」を参照してください。
次のように、Linux VDAマシンを含むマシンカタログの作成にはいくつかの制約があるため、Windows VDAマシンのマシンカタログの作成手順と異なる点があります:
- オペレーティングシステムには、次を選択します:
- ホストされる共有デスクトップ配信モデルの場合、[サーバーOS]オプション
- VDI専用デスクトップ配信モデルの場合、[デスクトップOS]オプション
- マシンが電源管理を行わない設定になっていることを確認します。
- MCSはLinux VDAではサポートされないため、PVSまたは他のサービスまたはテクノロジ(既存のイメージ)の展開方法を選択してください。
- 同じマシンカタログで、Linux VDAマシンとWindows VDAマシンを混在させないでください。
注:
Citrix Studioの以前のバージョンは、「Linux OS」という概念をサポートしていませんでした。ただし、[WindowsサーバーOS] オプションまたは [サーバーOS] オプションを選択すると、同等のホストされる共有デスクトップ配信モデルが暗黙的に選択されます。[WindowsデスクトップOS] オプションまたは [デスクトップOS] オプションを選択すると、マシンごとに単一ユーザーの配信モデルが暗黙的に選択されます。
ヒント:
マシンがActive Directoryドメインから削除された後に再度追加された場合は、そのマシンをマシンカタログから削除してから再度追加する必要があります。
手順7:XenAppまたはXenDesktopでデリバリーグループを作成
デリバリーグループを作成し、Linux VDAマシンを含むマシンカタログを追加する手順は、Windows VDAマシンの場合とほとんど同じです。このタスクを完了する方法の説明について詳しくは、「デリバリーグループの作成」を参照してください。
Linux VDAマシンカタログを含むデリバリーグループを作成する場合は、次の制約があります:
- 配信の種類には、[デスクトップ] を選択します。Linux VDA for Ubuntuでは、アプリケーション配信はサポートされていません。
- 選択するADユーザーおよびグループを、Linux VDAマシンにログオンするように適切に構成しておきます。
- 認証されていない(匿名)ユーザーのログオンを許可しないでください。
- Windowsマシンを含むマシンカタログをデリバリーグループで混在させないでください。