「Sambaの更新」の版間の差分
ページの作成:「== はじめに == 次のドキュメントでは、Sambaを新しいバージョンに更新するプロセスについて説明します。 Samba NT4ドメインをSa...」 |
|||
| 29行目: | 29行目: | ||
* Sambaを起動します。 | * Sambaを起動します。 | ||
: 以前のバージョンと同じデーモンを起動してください： | : 以前のバージョンと同じデーモンを起動してください： | ||
:* Samba AD DCについて：<code>samba</code> | |||
:* Samba NT4形式のPDC/BDC：<code>smbd</code>、<code>nmbd</code> | |||
:* Sambaドメインメンバ上で：`smbd`、`nmbd`（`winbind`、使用されている場合） | |||
:* Sambaのスタンドアロンホストの場合：`smbd` | |||
- Samba AD DCのみ：[](#Samba AD DCデータベースチェック)を実行します。 | - Samba AD DCのみ：[](#Samba AD DCデータベースチェック)を実行します。 | ||
2018年3月23日 (金) 10:25時点における版
はじめに
次のドキュメントでは、Sambaを新しいバージョンに更新するプロセスについて説明します。
Samba NT4ドメインをSamba Active Directory（AD）に移行する場合は、Samba NTドメインのSamba ADへの移行（Classicアップグレード）を参照してください。
Samba4についての誤解
{{#invoke:Message box|imbox}}
Active Directory（AD）ドメインコントローラ（DC）サポートは、Samba 4.0で導入された拡張機能の1つです。しかし、すべての新しいバージョンには、以前のバージョンの機能が含まれています。これには、NT4スタイルの（古典的な）ドメインサポートが含まれます。つまり、以前に更新したように、Samba 3.x NT4形式のプライマリドメインコントローラ（PDC）を最新バージョンに更新することができます（たとえば、3.4.xから3.5.xへ）。 NT4形式のドメインをADに移行する必要はありません。
さらに、最近のすべてのバージョンでは、新しいNT4形式のPDCの設定が引き続きサポートされています。 Samba 4.0以降のADサポートはオプションで、PDC機能のいずれかを置き換えるものではありません。 Sambaチームは、既存のLDAP構造によってもたらされる困難を理解しています。そのため、従来のPDCサポートを削除する予定はありません。さらに、継続的な統合システムでPDCサポートのテストを続けます。
更新のプロセス
Samba Active Directory（AD）ドメインコントローラ（DC）、Samba NT4形式のPDC、Sambaドメインメンバ、またはスタンドアロンインストールを更新するかどうかにかかわらず、次の手順を実行します。
- すべてのSambaサービスを停止します。
- バックアップを作成します。
- スキップされたバージョンのリリースノートを読んでください。それらには、新機能、変更されたパラメータ、バグ修正などの重要な情報が含まれています。新しいメジャーリリースに切り替える場合は、初期バージョン（x.y.0）のリリースノートとマイナーバージョンからアップデートする新しいバージョンまでのリリースノートをお読みください。たとえば、4.4.4から4.6.2に更新する場合は、4.5.0,4.6.0,4.6.1、および4.6.2のリリースノートをお読みください。
- 既存のバージョンに最新バージョンをインストールします。
- ソースからSambaをコンパイルする場合は、以前のバージョンで使用したのと同じconfigureオプションを使用します。詳細は、「ソースからのSambaのビルド」を参照してください。
- パッケージを使用して更新する場合、更新方法については、ディストリビューションのドキュメントをお読みください。
- Sambaを起動します。
- 以前のバージョンと同じデーモンを起動してください：
- Samba AD DCについて：
samba - Samba NT4形式のPDC/BDC：
smbd、nmbd - Sambaドメインメンバ上で：`smbd`、`nmbd`（`winbind`、使用されている場合）
- Sambaのスタンドアロンホストの場合：`smbd`
- Samba AD DCについて：
- Samba AD DCのみ：[](#Samba AD DCデータベースチェック)を実行します。
- Sambaのログファイルにエラーがないかどうか確認してください。
- 更新されたインストールをテストします。
- 複数のSambaドメインコントローラの更新
複数のSamba Active Directory（AD）ドメインコントローラ（DC）を更新する場合、推奨される順序は次のとおりです。
- Flexible single master operations（FSMO）の役割を持たないSamba AD DCを1つ更新します。 - 更新されたDC上でSambaを起動します。 - すべてのDC間のディレクトリ複製が正しく機能していることを確認します。
```
- samba-tool drs showrepl
```
- インストールをテストして、新しいバージョンが正しく動作することを確認します。 - 他のすべてのSamba DCを一度に1つずつアップグレードし、常にレプリケーションが正しく機能していることを確認します。
- Samba AD DCデータベースチェック
samba-toolユーティリティを使用すると、Samba Active Directory（AD）データベースの問題を検出して修正できます。たとえば、以前のSambaのバージョンが属性を誤って格納していて、更新されたバージョンが問題を修正した場合などです。一部の修正は複製されていない属性に適用され、変更が他のDCに複製されないため、すべてのSamba AD DCでcheckとfixコマンドをローカルで実行する必要があります。
ADデータベースを確認するには、次のコマンドを実行します。
```
- samba-tool dbcheck --cross-ncs
```
報告されたエラーを修正するには、
```
- samba-tool dbcheck --cross-ncs --fix
```
コマンドに`--yes`パラメータを渡すと、すべての質問に`yes`が自動的に返されます。 --yesパラメータを省略すると、データベースチェックは各オブジェクトに対して3つの`fsync()`呼び出しを実行することに注意してください。その結果、実行時間が長くなります。たとえば、テスト環境では、-yesパラメータを10秒間に3500個のオブジェクトを固定したコマンドに渡します。このパラメータがないと、コマンドは同じ操作で4:50分必要でした。
修復後、データベースを再確認して、正常な操作を確認します。
- 注目すべき拡張と変更
Sambaを更新する場合は、前のバージョンと更新するバージョンのリリースノートを必ずお読みください。これらには、新機能、変更されたパラメータオプションなどに関する重要な追加情報が含まれています。
このセクションでは、以前のバージョンの問題を修正するために注意が必要な重要な変更の概要を示し、パフォーマンスの低下などを回避します。
- すべてのSambaインストールモードに影響する変更
- ファイル実行権限
- 4.0.0以降
以前は、Sambaはファイルの実行ビットをチェックしていませんでした。その結果、xビットが設定されていない場合、ユーザーは共有上で* .exeや* .batなどのファイルを実行できます。 Sambaが拡張され、xビットが設定されていない場合、ファイルの実行を拒否しました。以前のバージョンからアップグレードする場合など、実行可能ファイルにxビットがない可能性があります。回避策として、個々の共有または[global]セクションに次のパラメータを設定すると、古い動作を有効にすることができます。
``` acl allow execute always = yes ```
- Samba Active Directoryドメインコントローラ
- ntvfs ファイルサーバーのバックエンドが無効になっています
- 4.5.0以降
以前は、Sambaを使用して、`ntvfs`ファイルサーバーのバックエンドを使用してドメインコントローラ（DC）をプロビジョニングすることができました。このバックエンドはサポートされていないため、`ntvfs`機能はSamba 4.5.0ではデフォルトではビルドされなくなりました。その結果、`ntvfs`バックエンドを使用してDC上でsambaサービスを開始すると、更新後にエラーが発生し、次のエラーが記録されます。
``` [2016/09/01 08:00:00.000000, 0, pid=995] ../source4/smbd/service.c:98(server_service_startup)
Failed to start service 'smb' - NT_STATUS_INVALID_SYSTEM_SERVICE
[2016/09/01 08:00:00.000000, 0, pid=995] ../lib/util/become_daemon.c:111(exit_daemon)
STATUS=daemon failed to start: Samba failed to start services, error code -1073741796
```
この問題を解決するには、DC上のファイルサーバーバックエンドをサポートされている`s3fs`バックエンドに移行します。詳細は、[`ntvfs`ファイルサーバーのバックエンドを`s3fs`に移行する](/svradmin/samba4/transdoc/migrating_the_ntvfs_file_server_back_end_to_s3fs)を参照してください。
- replPropertyMetaData属性の修正
- 4.5.0以降
4.5.0より前のバージョンのSambaでは、replPropertyMetaData属性が誤って格納されていました。結果として、管理者は、たとえば競合の名前を変更するなどの経験をすることができます。この問題は4.5.0以降のバージョンで修正され、Sambaは属性を正しく保存するようになりました。 samba-toolユーティリティは、間違って格納されたreplPropertyMetaData属性を検出するように拡張されました。
``` ＃samba-tool dbcheck --cross-ncs ```
属性を修正するには、次のコマンドを実行します。
```
- samba-tool dbcheck --cross-ncs --fix --yes
... CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000003 CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000000 ERROR: unsorted attributeID values in replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Fix replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com by sorting the attribute list? [YES] Fixed attribute 'replPropertyMetaData' of 'CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com' ```
`--yes`パラメータは`replPropertyMetaData`属性だけでなく、見つかったすべての問題を自動的に修正することに注意してください。
`replPropertyMetaData`は複製されていない属性であり、変更は他のDCに複製されないため、すべてのSambaドメインコントローラ（DC）で検査と修正の操作を実行します。
詳細については、[](#Samba AD DCデータベースチェック)セクションを参照してください。
- idmap configパラメータがsmb.confファイルで設定されているとドメインコントローラ上の共有にアクセスできない
- 4.4.6以降
Samba Active Directory（AD）ドメインコントローラ（DC）の`winbindd`サービスは、ユーザーアカウントとグループのActive Directoryの`uidNumber`と`gidNumber`属性で設定されたIDを自動的に使用します。属性が設定されていない場合、SambaはDC上でIDをローカルに生成し、`idmap.ldb`データベースに格納します。したがって、Samba AD DCでは、`smb.conf`ファイルに設定された`idmap config`パラメータは無視されました。 Samba 4.4.6以降のバグにより、パラメータは無視されなくなり、クライアントはDC上の共有に接続できなくなります。問題を解決するには：
- DC上の`smb.conf`ファイル内のすべての`idmap config`パラメータを削除します。 - samba`サービス`を再起動します。 - クライアントを再起動します。
その結果、クライアントはDC上の共有に正しく接続するようになります。
- 新しいデフォルトのLDAP接続はで強力な認証を必要とします
- 4.4.1以降/ 4.3.7以降/ 4.2.10以降
セキュリティ更新プログラム4.4.1,4.3.7および4.2.10では、Active Directory（AD）LDAPサーバー用に強力な認証を実施するための新しいsmb.confオプションが導入されました。この新しいオプション、`ldap server require strong auth`のデフォルトは`yes`で、TLS暗号化接続を介した認証方式Simpleのみが許可されます。その結果、LDAPを使用してADに接続する外部アプリケーションは、TLS暗号化接続を使用していないか、またはサポートしていない場合、接続を確立できません。
暗号化せずにLDAPプロトコルを使用してSamba ADに接続するアプリケーションは、次のエラーメッセージを表示します。 ``` ldap_bind: Strong(er) authentication required (8)
additional info: BindSimple: Transport encryption required.
```
詳細は、4.4.1,4.3.7、または4.2.10のリリースノートを参照してください。
- 削除されたLDAP DNSエントリのADデータベースクリーンアップ
- 4.1.12以降
以前は、Sambaは、削除されたDNSエントリの削除されたActive Directory（AD）オブジェクトを誤って作成しました。問題は修正されました。固定Sambaバージョンで最初のドメインコントローラ（DC）を起動すると、削除されたオブジェクトはすべて削除されます。その結果、削除されたオブジェクトが削除されるまでパフォーマンスが低下する可能性があります。
- 不適切なTLSファイルのアクセス許可
- 4.1.2以降/ 4.0.12以降
以前は、Sambaは安全でないアクセス権を持つLDAP TLS暗号化に使用される* .pemファイルを作成していました。安全でない接続を回避するには、すべてのドメインコントローラ（DC）上のファイルを削除します。
```
- rm /usr/local/samba/private/tls/*.pem
```
新しい証明書を自動的に再作成するためにファイルを削除した後でSambaを再起動してください。
- 動的DNSアップデートの問題の修正
- 4.0.7以降
詳細については、Samba 4.0.7より前のバージョンでのDNS動的更新の修正を参照してください。
- 不適切なSysvolおよびディレクトリACLの修正
- 4.0.x以前のバージョンからアップデートする場合、4.0beta と 4.0RC
- 不適切なSysvol ACLをリセットするには、次のコマンドを実行します。
```
- samba-tool ntacl sysvolreset
```
- ディレクトリ内のよく知られているすべてのACLをリセットするには、次のコマンドを実行します。
```
- samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
```
- Active Directory（AD）データベースのエラーを修正するには、次のコマンドを実行します。
```
- samba-tool dbcheck --cross-ncs --fix
```
- Sambaドメインメンバ
- IDマッピングの設定検証
- 4.6.0以降
以前は、Sambaはドメインメンバーの`smb.conf`ファイルのIDマッピング設定を確認していませんでした。したがって、ユーザーは、重複するID範囲や、デフォルトドメインの不正なバックエンドなど、誤ったIDマッピング構成を設定する可能性があります。その結果、`winbindd`サービスが開始され、IDマッピングが失敗したか、期待どおりに動作しませんでした。 `testparm`ユーティリティが強化され、誤ったIDマッピング設定が報告されるようになりました。例えば：
``` ERROR: The idmap range for the domain * (tdb) overlaps with the range of SAMDOM (ad)! ```
``` ERROR: Do not use the 'ad' backend as the default idmap backend! ```
さらに、誤ったIDマッピング設定を使用すると、winbinddサービスが起動できず、エラーメッセージが記録されます。例えば：
``` [2017/03/01 12:00:00.000000, 0, pid=980] ../source3/winbindd/winbindd.c:1705(main)
main: FATAL: Invalid idmap backend ad configured as the default backend!
```
Samba 4.6.0以降を使用すると、ユーザーは誤ったIDマッピング設定を使用できなくなります。
詳細、ドメインメンバーのサポートされているバックエンド、およびその設定については、以下を参照してください。
- [Identity Mapping Back Ends](https://wiki.samba.org/index.php/Identity_Mapping_Back_Ends) - `smb.conf(5)`のマニュアルページの「`IDENTITY MAPPING CONSIDERATIONS`」セクション
- adマッピングのバックエンドは、ドメインごとにRFC2307またはテンプレートモードを有効にすることをサポートしています
- 4.6.0以降
以前は、`winbind nss info`パラメータが`rfc2307`に設定されていたとき、Sambaの`ad`IDマッピングバックエンドはすべてのActive Directory（AD）ドメインのシェルとホームディレクトリ設定をADから取得しました。 Samba 4.6.0では、新しい`idmap config domain_name：unix_nss_info`パラメータが追加されました。このパラメータを使用すると、管理者は、ユーザーのシェルおよびホームディレクトリ設定をADから取得する必要がある場合、またはテンプレートシェルおよびテンプレートのhomedirパラメータに設定されているテンプレート設定が適用されている場合、ADドメイン単位で設定できます。
新しい`idmap config domain_name：unix_nss_info`パラメータの優先度は、グローバル`winbind nss info = rfc2307`の設定よりも高くなっています。したがって、`idmap config domain_name：unix_nss_info = no`を ADドメインのデフォルト設定としての使用すると、シェルおよびホームディレクトリはADから取得されなくなり、`template shell`および`template homedir`パラメータに設定された値が適用されます。ドメインのADから値を取得できるようにするには、`smb.conf`ファイルの`[global]`セクションで次のように設定します。
``` idmap config domain_name：unix_nss_info = yes ```
詳細と設定方法の例については、[idmap config ad - `ad`バックエンドの設定](https://wiki.samba.org/index.php/Idmap_config_ad#Configuring_the_ad_Back_End)を参照してください。