24 Sambaを介したCephデータのエクスポート #
この章では、Cephクラスタに保存されたデータをSamba/CIFS共有を介してエクスポートし、Windows*クライアントマシンからデータに簡単にアクセスできるようにする方法について説明します。また、Ceph Sambaゲートウェイを設定してWindows*ドメインのActive Directoryに参加し、ユーザを認証および承認するのに役立つ情報も含まれています。
プロトコルオーバーヘッドが増加し、クライアントとストレージ間の余分なネットワークホップによって追加の遅延が発生するため、Sambaゲートウェイ経由でCephFSにアクセスすると、ネイティブのCephFSクライアントと比較して、アプリケーションのパフォーマンスが大幅に低下する場合があります。
24.1 Samba共有を介したCephFSのエクスポート #
ネイティブのCephFSおよびNFSクライアントは、Sambaを介して取得されるファイルロックによる制限を受けません。また、その逆も同様です。クロスプロトコルファイルロックに依存するアプリケーションでは、CephFSを利用するSamba共有パスに他の手段でアクセスした場合、データの破壊が発生することがあります。
24.1.1 Sambaパッケージの設定とエクスポート #
Samba共有を設定およびエクスポートするには、パッケージ samba-ceph および samba-winbindをインストールします。これらのパッケージがインストールされていない場合、インストールします。
cephuser@smb > zypper install samba-ceph samba-winbind24.1.2 ゲートウェイが1つの場合の例 #
Samba共有をエクスポートする準備として、Sambaゲートウェイとして動作する適切なノードを選択します。このノードは、Cephクライアントネットワークに加え、十分なCPU、メモリ、およびネットワーキングリソースにアクセスできる必要があります。
フェールオーバー機能は、CTDBとSUSE Linux Enterprise High Availability Extensionで提供できます。HAセットアップの詳細については、24.1.3項 「高可用性の設定」を参照してください。
クラスタ内に動作中のCephFSがすでに存在することを確認します。
Ceph管理ノード上にSambaゲートウェイに固有のキーリングを作成して、両方のSambaゲートウェイノードにコピーします。
cephuser@adm >cephauth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringcephuser@adm >scpceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/SAMBA_NODEは、Sambaゲートウェイノードの名前に置き換えます。
Sambaゲートウェイノードで次の手順を実行します。Ceph統合パッケージとともにSambaをインストールします。
cephuser@smb >sudo zypper in samba samba-ceph/etc/samba/smb.confファイルのデフォルトの内容を以下に置き換えます。[global] netbios name = SAMBA-GW clustering = no idmap config * : backend = tdb2 passdb backend = tdbsam # disable print server load printers = no smbd: backgroundqueue = no [SHARE_NAME] path = CEPHFS_MOUNT read only = no oplocks = no kernel share modes = no
先のCEPHFS_MOUNTパスは、カーネルCephFS共有設定でSambaを起動する前にマウントする必要があります。23.3項 「
/etc/fstabでのCephFSのマウント」を参照してください。この共有設定はLinuxカーネルのCephFSクライアントを使用しています。パフォーマンス上の理由から、この設定をお勧めします。もしくは、Samba
vfs_cephモジュールをCephクラスタとの通信に使用することもできます。設定内容を以下に示します。この方法は旧来の用途向けであり、新しいSambaの展開にはお勧めしません。[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read only = no oplocks = no kernel share modes = no
ヒント: Oplocksと共有モードoplocks(SMB2+ leasesとしても知られている)は、積極的なクライアントキャッシングによってパフォーマンスを向上させることができますが、現在のところ、Sambaが他のCephFSクライアント(カーネルmount.cephf、FUSE、NFS Ganeshaなど)とともに展開されている場合は安全ではありません。すべてのCephFSファイルシステムパスアクセスをSambaで排他的に処理する場合は、
oplocksパラメータを有効化しても安全です。現在のところ、ファイルサービスを正しく動作させるには、CephFS vfsモジュールで実行されている共有では、
kernel share modesを無効にする必要があります。重要: アクセスの許可SambaはSMBユーザとグループをローカルアカウントにマッピングします。次のコマンドにより、Samba共有アクセス用のパスワードをローカルユーザに割り当てることができます。
root #smbpasswd -a USERNAMEI/Oを正常に実行するには、共有パスのアクセス制御リスト(ACL)を使用して、Samba経由で接続されているユーザへのアクセスを許可する必要があります。ACLを変更するには、CephFSカーネルクライアントを介して一時的にマウントし、共有パスに対して
chmod、chown、またはsetfaclのユーティリティを使用します。たとえば、すべてのユーザに対してアクセスを許可するには、次のコマンドを実行します。root #chmod 777 MOUNTED_SHARE_PATH
24.1.2.1 Sambaサービスの起動 #
次のコマンドを使用して、スタンドアロンのSambaサービスを起動または再起動します。
root #systemctl restart smb.serviceroot #systemctl restart nmb.serviceroot #systemctl restart winbind.service
Sambaサービスがブート時に起動するようにするには、次のコマンドで有効化します。
root #systemctl enable smb.serviceroot #systemctl enable nmb.serviceroot #systemctl enable winbind.service
nmbサービスとwinbindサービス
ネットワーク共有ブラウジングが不要な場合は、nmbサービスの有効化と起動は不要です。
winbindサービスは、Active Directoryドメインメンバーとして設定する場合にのみ必要です。24.2項 「SambaゲートウェイとActive Directoryの参加」を参照してください。
24.1.3 高可用性の設定 #
Samba + CTDBのマルチノード展開では単一ノードと比較して可用性が高くなりますが(第24章 「Sambaを介したCephデータのエクスポート」を参照)、クライアント側の透過的なフェールオーバーはサポートされていません。Sambaゲートウェイノードで障害が発生した場合、アプリケーションが短時間停止する可能性があります。
このセクションでは、Sambaサーバの2ノード高可用性設定の方法について例を使って説明します。このセットアップでは、SUSE Linux Enterprise High Availability Extensionが必要です。これら2つのノードは、earth (192.168.1.1)およびmars (192.168.1.2)という名前です。
SUSE Linux Enterprise High Availability Extensionの詳細については、https://documentation.suse.com/sle-ha/15-SP1/を参照してください。
さらに、2つの浮動仮想IPアドレスにより、実行している物理ノードがどれであれ、クライアントからの該当サービスへの接続が可能になります。Hawk2でのクラスタ管理には192.168.1.10を使用し、CIFSエクスポートには192.168.2.1を排他的に使用します。これにより、後で簡単にセキュリティ制約を適用できます。
次の手順では、インストールの例について説明します。詳細については、https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/art-sleha-install-quick.htmlを参照してください。
管理ノード上にSambaゲートウェイに固有のキーリングを作成して、両方のノードにコピーします。
cephuser@adm >cephauth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringcephuser@adm >scpceph.client.samba.gw.keyringearth:/etc/ceph/cephuser@adm >scpceph.client.samba.gw.keyringmars:/etc/ceph/SLE-HAセットアップには、アクティブクラスタノードが非同期状態になった場合に「スプリットブレイン」状態に陥ることを避けるため、フェンシングデバイスが必要です。このため、SBD (Stonith Block Device)を使用したCeph RBDイメージを使用できます。詳細については、https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/cha-ha-storage-protect.html#sec-ha-storage-protect-fencing-setupを参照してください。
RBDイメージが存在しない場合は、
rbdという名前のRBDプールを作成し(18.1項 「プールの作成」を参照してください)、rbdを関連付けます(18.5.1項 「プールとアプリケーションの関連付け」を参照してください)。そして、sbd01という名前の関連するRBDイメージを作成します。cephuser@adm >ceph osd pool create rbdcephuser@adm >ceph osd pool application enable rbd rbdcephuser@adm >rbd -p rbd create sbd01 --size 64M --image-sharedearthおよびmarsを、Sambaサービスをホストするように準備します。次のパッケージがインストールされていることを確認してから進んでください: ctdb、 tdb-tools、および sambaをインストールします。
root #zypperin ctdb tdb-tools samba samba-cephSambaサービスとCTDBサービスが停止され、無効化されていることを確認します。
root #systemctl disable ctdbroot #systemctl disable smbroot #systemctl disable nmbroot #systemctl disable winbindroot #systemctl stop ctdbroot #systemctl stop smbroot #systemctl stop nmbroot #systemctl stop winbindすべてのノードのファイアウォールのポート
4379を開きます。これは、CTDBが他のクラスタノードと通信するために必要です。
earth上にSambaの設定ファイルを作成します。これらは、後で自動的にmarsに同期します。Sambaゲートウェイノード上のプライベートIPアドレスのリストを
/etc/ctdb/nodesファイルに挿入します。詳細については、ctdbのマニュアルのページ(man 7 ctdb)を参照してください。192.168.1.1 192.168.1.2
Sambaを設定します。
/etc/samba/smb.confの[global]セクションに次の行を追加します。CTDB-SERVERの代わりに、任意のホスト名を使用します(クラスタ内のすべてのノードは、この名前を持つ1つの大きなノードとして表示されます)。共有の定義も追加します。一例として、SHARE_NAMEを検討してください。[global] netbios name = SAMBA-HA-GW clustering = yes idmap config * : backend = tdb2 passdb backend = tdbsam ctdbd socket = /var/lib/ctdb/ctdb.socket # disable print server load printers = no smbd: backgroundqueue = no [SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read only = no oplocks = no kernel share modes = no
すべてのSambaゲートウェイノードで
/etc/ctdb/nodesのファイルと/etc/samba/smb.confのファイルが一致している必要があることに注意してください。
SUSE Linux Enterprise High Availabilityクラスタをインストールして起動します。
earthおよびmarsでSUSE Linux Enterprise High Availability Extensionを登録します。root@earth #SUSEConnect-r ACTIVATION_CODE -e E_MAILroot@mars #SUSEConnect-r ACTIVATION_CODE -e E_MAIL両方のノードに ha-cluster-bootstrap をインストールします。
root@earth #zypperin ha-cluster-bootstraproot@mars #zypperin ha-cluster-bootstrapRBDイメージ
sbd01を両方のSambaゲートウェイにrbdmap.serviceを介してマッピングします。/etc/ceph/rbdmapを編集して、SBDイメージのエントリを追加します。rbd/sbd01 id=samba.gw,keyring=/etc/ceph/ceph.client.samba.gw.keyring
rbdmap.serviceを有効化し、起動します。root@earth #systemctl enable rbdmap.service && systemctl start rbdmap.serviceroot@mars #systemctl enable rbdmap.service && systemctl start rbdmap.service/dev/rbd/rbd/sbd01のデバイスは両方のSambaゲートウェイで使用可能である必要があります。earthのクラスタを初期化し、marsを参加させます。root@earth #ha-cluster-initroot@mars #ha-cluster-join-c earth重要クラスタの初期化および参加の処理中に、SBDを使用するかどうかが対話形式で確認されます。
yで確定し、ストレージデバイスのパスとして/dev/rbd/rbd/sbd01を指定してください。
クラスタの状態を確認します。クラスタに2つのノードが追加されたことがわかります。
root@earth #crmstatus 2 nodes configured 1 resource configured Online: [ earth mars ] Full list of resources: admin-ip (ocf::heartbeat:IPaddr2): Started earthearthで次のコマンドを実行して、CTDBリソースを設定します。root@earth #crmconfigurecrm(live)configure#primitivectdb ocf:heartbeat:CTDB params \ ctdb_manages_winbind="false" \ ctdb_manages_samba="false" \ ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper ceph client.samba.gw cephfs_metadata ctdb-mutex" ctdb_socket="/var/lib/ctdb/ctdb.socket" \ op monitor interval="10" timeout="20" \ op start interval="0" timeout="200" \ op stop interval="0" timeout="100"crm(live)configure#primitivesmb systemd:smb \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure#primitivenmb systemd:nmb \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure#primitivewinbind systemd:winbind \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure#groupg-ctdb ctdb winbind nmb smbcrm(live)configure#clonecl-ctdb g-ctdb meta interleave="true"crm(live)configure#commitヒント: オプションのnmbプリミティブとwinbindプリミティブネットワーク共有ブラウジングが不要な場合は、
nmbプリミティブの追加は不要です。winbindプリミティブは、Active Directoryドメインメンバーとして設定する場合にのみ必要です。24.2項 「SambaゲートウェイとActive Directoryの参加」を参照してください。設定オプション
ctdb_recovery_lockのバイナリ/usr/lib64/ctdb/ctdb_mutex_rados_helperには、パラメータCLUSTER_NAME、CEPHX_USER、CEPH_POOL、およびRADOS_OBJECTがこの順序で指定されています。追加のlock-timeoutパラメータを付加して、使用されているデフォルト値(10秒)を上書きできます。値を大きくすると、CTDB回復マスタのフェールオーバー時間が長くなり、値を小さくすると、回復マスタがダウンとして不正確に検出され、フラッピングフェールオーバーがトリガされる可能性があります。
クラスタ対応のIPアドレスを追加します。
crm(live)configure#primitiveip ocf:heartbeat:IPaddr2 params ip=192.168.2.1 \ unique_clone_address="true" \ op monitor interval="60" \ meta resource-stickiness="0"crm(live)configure#clonecl-ip ip \ meta interleave="true" clone-node-max="2" globally-unique="true"crm(live)configure#colocationcol-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure#ordero-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure#commitunique_clone_addressがtrueに設定されている場合、IPaddr2リソースエージェントはクローンIDを指定のアドレスに追加し、3つの異なるIPアドレスを設定します。これらは通常必要とされませんが、負荷分散に役立ちます。この項目の詳細については、https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/cha-ha-lb.htmlを参照してください。結果を確認します。
root@earth #crmstatus Clone Set: base-clone [dlm] Started: [ factory-1 ] Stopped: [ factory-0 ] Clone Set: cl-ctdb [g-ctdb] Started: [ factory-1 ] Started: [ factory-0 ] Clone Set: cl-ip [ip] (unique) ip:0 (ocf:heartbeat:IPaddr2): Started factory-0 ip:1 (ocf:heartbeat:IPaddr2): Started factory-1クライアントコンピュータからテストを行います。次のコマンドをLinuxクライアントで実行して、システムからファイルをコピーしたり、システムにファイルをコピーできるかどうか確認します。
root #smbclient//192.168.2.1/myshare
24.1.3.1 HA Sambaリソースの再起動 #
SambaまたはCTDBの設定に何らかの変更を加えた場合、変更を有効にするためHAリソースの再起動が必要になる場合があります。再起動は次のコマンドにより実行できます。
root #crmresource restart cl-ctdb
24.2 SambaゲートウェイとActive Directoryの参加 #
Ceph Sambaゲートウェイを、AD (Active Directory)をサポートするSambaドメインのメンバーになるように設定できます。Sambaドメインのメンバーは、エクスポートされたCephFSのファイルとディレクトリで、ローカルACL (アクセスリスト)のドメインユーザとグループを使用できます。
24.2.1 Sambaのインストール準備 #
このセクションでは、Samba自体を設定する前に、注意する必要がある準備手順について説明します。クリーンな環境から開始することで、混乱を防ぎ、以前のSambaインストールのファイルが新しいドメインメンバーのインストールと混在しないようにします。
すべてのSambaゲートウェイノードのクロックをActive Directoryドメインコントローラと同期する必要があります。クロックスキューがあると、認証が失敗する場合があります。
Sambaまたは名前キャッシュプロセスが実行されていないことを確認します。
cephuser@smb > ps ax | egrep "samba|smbd|nmbd|winbindd|nscd"
この出力に、samba、smbd、nmbd、winbindd、またはnscdのプロセスが一覧にされる場合は、これらを停止します。
以前にこのホストでSambaのインストールを実行したことがある場合は、/etc/samba/smb.confファイルを削除します。また、*.tdbファイル、*.ldbファイルなど、Sambaデータベースファイルもすべて削除します。Sambaデータベースが含まれるディレクトリを一覧にするには、次のコマンドを実行します。
cephuser@smb > smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"24.2.2 DNSの検証 #
AD (Active Directory)は、DNSを使用して、Kerberosなどの他のDC (ドメインコントローラ)とサービスを検索します。したがって、ADドメインメンバーとサーバがAD DNSゾーンを解決できる必要があります。
DNSが正しく設定されていること、および前方参照と逆引き参照の両方が正しく解決されることを確認します。次に例を示します。
cephuser@adm > nslookup DC1.domain.example.com
Server: 10.99.0.1
Address: 10.99.0.1#53
Name: DC1.domain.example.com
Address: 10.99.0.1cephuser@adm > 10.99.0.1
Server: 10.99.0.1
Address: 10.99.0.1#53
1.0.99.10.in-addr.arpa name = DC1.domain.example.com.24.2.3 SRVレコードの解決 #
ADは、SRVレコードを使用して、KerberosやLDAPなどのサービスを検索します。SRVレコードが正しく解決されることを確認するには、次のようにnslookupの対話型シェルを使用します。
cephuser@adm > nslookup
Default Server: 10.99.0.1
Address: 10.99.0.1
> set type=SRV
> _ldap._tcp.domain.example.com.
Server: UnKnown
Address: 10.99.0.1
_ldap._tcp.domain.example.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc1.domain.example.com
domain.example.com nameserver = dc1.domain.example.com
dc1.domain.example.com internet address = 10.99.0.124.2.4 Kerberos の設定 #
Sambaは、HeimdalおよびMIT Kerberosのバックエンドをサポートしています。ドメインメンバーにKerberosを設定するには、/etc/krb5.confファイルに以下を設定します。
[libdefaults] default_realm = DOMAIN.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true
前の例では、DOMAIN.EXAMPLE.COMレルムに対してKerberosを設定します。/etc/krb5.confファイルには、他のパラメータを設定しないことをお勧めします。/etc/krb5.confにinclude行が含まれる場合、この行は機能しません。この行を削除する「必要があります」。
24.2.5 ローカルホスト名の解決 #
ホストをドメインに参加させる場合、Sambaは、そのホスト名をAD DNSゾーンに登録しようとします。このため、netユーティリティで、DNSまたは/etc/hostsファイルの正しいエントリを使用してホスト名を解決できる必要があります。
ホスト名が正しく解決されることを確認するには、getent hostsコマンドを使用します。
cephuser@adm > getent hosts example-host
10.99.0.5 example-host.domain.example.com example-host
ホスト名とFQDNは、IPアドレス127.0.0.1、またはドメインメンバーのLANインタフェースで使用するアドレス以外のIPアドレスに解決されてはなりません。出力が表示されないか、またはホストが間違ったIPアドレスに解決される場合に、DHCPを使用しないときは、/etc/hostsファイルに正しいエントリを設定します。
127.0.0.1 localhost 10.99.0.5 example-host.samdom.example.com example-host
/etc/hosts
DHCPを使用する場合、/etc/hostsには「127.0.0.1」の行のみが含まれていることを確認します。問題が続く場合は、DHCPサーバの管理者に連絡してください。
マシンのホスト名にエイリアスを追加する必要がある場合は、「127.0.0.1」の行ではなく、マシンのIPアドレスで始まる行の終わりに追加します。
24.2.6 Sambaの設定 #
このセクションでは、Sambaの設定に含める必要がある特定の設定オプションについて説明します。
Active Directoryのドメインメンバーシップの主要な設定を行うにはは、/etc/samba/smb.confの[global]セクションで、security = ADSに加えて、適切なKerberosレルムとIDマッピングパラメータを設定します。
[global] security = ADS workgroup = DOMAIN realm = DOMAIN.EXAMPLE.COM ...
24.2.6.1 winbinddでのIDマッピングのバックエンドの選択 #
ユーザが異なるログインシェルやUnixホームディレクトリパスを使用する必要がある場合、またはユーザにすべての場所で同じIDを使用させたい場合は、winbindの「ad」バックエンドを使用し、RFC2307の属性をADに追加する必要があります。
ユーザまたはグループの作成時に、RFC2307属性は自動的には追加されません。
DCで見つかるID番号(3000000の範囲の番号)は、RFC2307の属性では「ない」ので、Unixドメインメンバーでは使用されません。すべての場所で同じID番号が必要な場合は、uidNumber属性とgidNumber属性をADに追加し、Unixドメインメンバーで「ad」バックエンドを使用します。uidNumber属性とgidNumber属性をADに追加する場合は、3000000の範囲の番号を使用しないでください。
ユーザがSamba AD DCを認証にのみ使用し、Samba AD DCにデータを保存したりログインしたりしない場合は、「ind」バックエンドを使用できます。この場合、ユーザとグループのIDはWindows* RIDから計算されます。すべてのUnixドメインメンバーでsmb.confの同じ[global]セクションを使用している場合は、同じIDが取得されます。「rid」バックエンドを使用する場合は、ADに何も追加する必要はなく、RFC2307の属性は無視されます。「rid」バックエンドを使用する場合、smb.confでtemplate shellパラメータとtemplate homedirパラメータを設定します。これらの設定はグルーバルで、全員が同じログインシェルとUnixホームディレクトリパスを取得します(個別のUnixホームディレクトリパスとシェルを設定可能なRFC2307の属性とは異なります)。
Sambaを設定する方法はもう1つあります。この方法は、すべての場所でユーザとグループに同じIDを設定する必要があるものの、ユーザに同じログインシェルを設定し、ユーザが同じUnixホームディレクトリパスを使用するだけで良い場合に使用できます。このためには、winbindの「rid」バックエンドとsmb.confのテンプレート行を使用します。このように、uidNumber属性とgidNumber属性をADに追加するだけで済みます。
IDマッピングに使用可能なバックエンドの詳細については、関連するマニュアルページのman 8 idmap_ad、man 8 idmap_rid、およびman 8 idmap_autoridを参照してください。
24.2.6.2 ユーザとグループのID範囲の設定 #
使用するwinbindバックエンドを決定した後、smb.confのidmap configオプションで、使用する範囲を指定する必要があります。Unixドメインメンバーでは、複数のブロックのユーザIDとグループIDが最初から予約されています。
| ID | 範囲 |
|---|---|
| 0~999 | ローカルシステムユーザとグループ |
| 1000から開始 | ローカルUnixユーザとグループ |
| 10000から開始 | DOMAINユーザとグループ |
上の範囲からわかるように、「*」または「DOMAIN」の範囲を999以下から始まるように設定しないでください。この範囲は、ローカルシステムユーザとグループに干渉するためです。また、ローカルUnixユーザとグループの領域も残しておく必要があるため、idmap configの範囲を3000にするのが適切な妥協点である可能性があります。
「DOMAIN」の規模がどのくらい拡大する可能性があるか、および信頼できるドメインを使用する計画があるかどうかを判断する必要があります。その後、idmap configの範囲を次のように設定できます。
| Domain | 範囲 |
|---|---|
| * | 3000~7999 |
| DOMAIN | 10000~999999 |
| TRUSTED | 1000000~9999999 |
24.2.6.3 ローカルrootユーザへのドメイン管理者アカウントのマッピング #
Sambaでは、ドメインアカウントをローカルアカウントにマップすることができます。この機能を使用して、クライアントで操作を要求したアカウントとは異なるユーザとして、ドメインメンバーのファイルシステムでファイル操作を実行します。
ドメイン管理者をローカルrootアカウントにマッピングするかどうかはオプションです。このマッピングを設定するのは、ドメイン管理者がroot許可を使用してドメインメンバーでファイル操作を実行できる必要がある場合だけにしてください。また、管理者をrootアカウントにマッピングしても、「管理者」としてUnixドメインメンバーにログインすることはできないことに注意してください。
ドメイン管理者をローカルrootアカウントにマップするには、次の手順に従います。
smb.confファイルの[global]セクションに次のパラメータを追加します。username map = /etc/samba/user.map
次の内容で
/etc/samba/user.mapファイルを作成します。!root = DOMAIN\Administrator
「ad」のIDマッピングバックエンドを使用する場合は、ドメイン管理者アカウントにuidNumber属性を設定しないでください。アカウントにこの属性が設定されていると、その値によってrootユーザのローカルUID「0」が上書きされるため、マッピングが失敗します。
詳細については、smb.confマニュアルページのusername mapパラメータ(man 5 smb.conf)を参照してください。
24.2.7 Active Directoryドメインへの参加 #
ホストをActive Directoryドメインに参加させるには、次のコマンドを実行します。
cephuser@smb > net ads join -U administrator
Enter administrator's password: PASSWORD
Using short domain name -- DOMAIN
Joined EXAMPLE-HOST to dns domain 'DOMAIN.example.com'24.2.8 ネームサービススイッチの設定 #
ドメインユーザとグループをローカルシステムで利用できるようにするには、NSS (ネームサービススイッチ)ライブラリを有効にする必要があります。/etc/nsswitch.confファイルの次のデータベースにwinbindのエントリを追加します。
passwd: files winbind group: files winbind
両方のデータベースに対し、
filesエントリを最初のソースのままにします。これにより、NSSは、winbindサービスに照会する前に、/etc/passwdファイルと/etc/groupファイルからドメインユーザとグループを検索できます。NSS
shadowデータベースにはwinbindエントリを追加しないでください。これにより、wbinfoユーティリティが失敗する可能性があります。ローカルの
/etc/passwdファイルで、ドメイン内のファイルと同じユーザ名を使用しないでください。
24.2.9 サービスの起動 #
設定の変更後、24.1.2.1項 「Sambaサービスの起動」または24.1.3.1項 「HA Sambaリソースの再起動」に従って、Sambaサービスを再起動してください。
24.2.10 winbindd接続のテスト #
24.2.10.1 winbinddのping送信 #
winbinddサービスがAD DC (ドメインコントローラ)またはPDC (プライマリドメインコントローラ)に接続できるかどうかを確認するには、次のコマンドを入力します。
cephuser@smb > wbinfo --ping-dc
checking the NETLOGON for domain[DOMAIN] dc connection to "DC.DOMAIN.EXAMPLE.COM" succeeded
上のコマンドが失敗する場合は、winbinddサービスが実行されていること、およびsmb.confファイルが正しく設定されていることを確認します。
24.2.10.2 ドメインユーザとグループの検索 #
libnss_winbindライブラリでは、ドメインユーザとグループを検索できます。たとえば、ドメインユーザ「DOMAIN\demo01」を検索するには、次のコマンドを実行します。
cephuser@smb > getent passwd DOMAIN\\demo01
DOMAIN\demo01:*:10000:10000:demo01:/home/demo01:/bin/bashドメイングループ「Domain Users」を検索するには、次のコマンドを実行します。
cephuser@smb > getent group "DOMAIN\\Domain Users"
DOMAIN\domain users:x:10000:24.2.10.3 ドメインユーザとグループへのファイル許可の割り当て #
NSS (ネームサービススイッチ)ライブラリでは、ドメインユーザアカウントとグループをコマンドで使用できます。たとえば、ファイルの所有者を「demo01」ドメインユーザに設定し、グループを「Domain Users」ドメイングループに設定するには、次のコマンドを入力します。
cephuser@smb > chown "DOMAIN\\demo01:DOMAIN\\domain users" file.txt