Sambaバックアップスクリプトを使用する

2019-03-12T15:27:14Z

Meisina04: /* はじめに */

== はじめに ==

: {{Imbox
| type = content
| style = margin:4px 2%;
| text = このページはSamba v4.0-v4.8上でバックアップを作成することについて記載しています。Samba v4.9以降では、バックアップの作成が大幅に改善されました。詳細は[[Samba_AD_DCのバックアップとリストア | こちら]]を参照してください。
}}

このドキュメントの内容は、samba 4.xで使用するためのものです。

これは、Samba AD DCのバックアップと復元に関するチュートリアルです。それは有用であることが期待されていますが、保証は一切ありません！

'''この行が削除されるまで、このドキュメントはDRAFTとみなされます。'''

== 一般 ==

{{imbox
| type = content
| style = margin:4px 2%;
| text = 警告：複数のDCを動作させている場合：バックアップからDCを復元しないでください。レプリケーションのメタデータが同期しなくなると、ディレクトリが破損します。
}}

少なくとも1つの他のDCがまだ動作している場合は、[[Samba DCを既存のActive Directoryに参加させる|新しいマシンをDCとして再び接続]]します。他の実行中のDCからすべてが同期されます - まだ実装されていないSysVolレプリケーションを除きます。

{{imbox
| style = margin:4px 2%;
| text = 元のDC上でのみバックアップを使用し、新しいDCに移動してDCをアップグレードすることは絶対にしないでください。この場合、代わりに新しいDCに参加してください。
}}

ドメイン内のすべてのDCが壊れている場合は、http://lists.samba.orgのsamba-technicalメーリングリストに投稿して、これを解決する最善の方法について議論する必要があります。

=== LDBおよびTDBファイルのバックアップ/リストア方法 ===

'samba_backup'スクリプトを修正する予定がある場合や独自のソリューションを作成する場合は、ここでいくつかの有益な情報を見つけるでしょう：

* 実行中のデータベースを決してコピーする必要はありませんが、<code>* .ldb</code>＆<code>* .tdb</code>ファイルを'tdbbackup'でオンラインでバックアップできます。
* tdbbackupによって作成されたファイルは、完全なTDBファイルと通常のTDBファイルです。 tdbbackupは安全に抽出を行います。
* <code>* .ldb</code>ファイルのバックアップは、単に '.bak'というサフィックスを削除するだけで元の名前に復元できます。

=== samba_backupスクリプトについて ===

Sambaはデータベースをバックアップする非常に基本的なシェルスクリプトを提供しています（ソースtarballの<code>source4/scripting/bin/samba_backup</code>）。これには、Sambaインストール全体が1つの場所にあることが必要です（<code>/usr /local/samba/</code>など）。 configureオプションを使用して異なる場所にsambaを格納している場合は、スクリプトを調整するか、ベースとして使用して独自のスクリプトを作成できます。

スクリプトは非常に基本的なものであり、それをそのまま使用する予定がある場合、注意すべき点が1つあります。

* スクリプトは拡張ACLをバックアップしません。したがって、あなたはパーミッションを失います（例：SysVol共有）。--xattrsオプションをサポートするtarバージョン（tarのマンページを参照）がある場合は、このオプションをスクリプト内のすべての 'tar'コマンドに追加する必要があります。これにより、tarはアーカイブ内の拡張ACLを保持できます。

== バックアップ ==

Sambaのバックアップスクリプトは、 'make install'によってインストールされません。ソースディレクトリ（<code>source4/scripting/bin/samba_backup</code>）から<code>/usr/sbin</code>のような場所にコピーし、安全な権限を設定する必要があります：

<pre># cp .../source4/scripting/bin/samba_backup /usr/sbin
# chown root:root /usr/sbin/samba_backup
# chmod 750 /usr/sbin/samba_backup</pre>
スクリプト内の以下の変数を必要に応じて調整します。

<pre>FROMWHERE=/usr/local/samba
WHERE=/usr/local/backups
DAYS=90</pre>
<code>$WHERE</code>変数に設定してアクセス権を設定した宛先フォルダを作成します。

<pre># mkdir /usr/local/backups
# chmod 750 /usr/local/backups</pre>
最初のテストのバックアップスクリプトを開始します。

<pre># /usr/sbin/samba_backup</pre>
スクリプトがエラーなしで終了する場合は、出力先フォルダに3つのファイルがあります。

* <code>etc.{Timestamp}.tar.bz2</code>
* <code>samba4_private.{Timestamp}.tar.bz2</code>
* <code>sysvol.{Timestamp}.tar.bz2</code>

テストバックアップが成功した場合は、毎日のバックアップ用にcronジョブを追加する必要があります。

<pre># crontab -e</pre>
毎日2:00AMにバックアップするために、次の行を追加します。

<pre>0 2 * * * /usr/sbin/samba_backup</pre>
注意：cronを使用してスクリプトを実行するときは、すべての必要なバイナリが<code>$PATH</code>変数の一部であるディレクトリにあることを確認してください。正しいパスがシステム全体で定義されていない場合は、変数をcrontabに設定するか、またはスクリプトの先頭でshebang(#!)行の後に設定します。

== リストア ==

以下のリストアガイドでは、 'samba_backup'スクリプトを使用してデータベースをバックアップしたことを前提としています。独自のスクリプトをお持ちの場合は、手順を調整してください。

'''非常に重要なメモ：'''

* '''同時に、復元とバージョンの変更を行わないでください！バックアップを作成したものと同じSambaバージョンを使用しているシステムでは、常に復元してください！'''
* '''同じIPとホスト名を持つシステムでは、常にリストアしてください。そうしないと、KerberosとDNSの問題が発生します。'''
* '''推奨：バックアップを作成したのと同じOSで復元してください。'''

'''復元状況で最も重要なことは、システムを実行状態に戻すことです。すべてアップしてテストされたら、必要な変更を行うことができます。復元と一緒に変更しようとしないでください！'''

システム全体が壊れている場合は、まずHowTo（[[SambaをActive Directoryドメインコントローラとして設定する]]）の説明に従ってマシン全体をセットアップする必要があります。

復元するフォルダを削除します（sambaは停止している状態で）：

<pre># rm -rf /usr/local/samba/etc
# rm -rf /usr/local/samba/private
# rm -rf /usr/local/samba/var/locks/sysvol</pre>
最新の作業用バックアップファイルを元の場所に展開します。

<pre># cd /usr/local/backups
# tar -jxf etc.{Timestamp}.tar.bz2 -C /usr/local/samba/
# tar -jxf samba4_private.{Timestamp}.tar.bz2 -C /usr/local/samba/
# tar -jxf sysvol.{Timestamp}.tar.bz2 -C /usr/local/samba/</pre>
<code>private</code>ディレクトリの<code>*.ldb.bak</code>ファイルの名前を<code>*.ldb</code>に戻します。これはGNU <code>find</code> と<code>Bash</code>で行うことができます：

<pre># find /usr/local/samba/private/ -type f -name '*.ldb.bak' -print0 | while read -d $'\0' f ; do mv "$f" "${f%.bak}" ; done</pre>
バックアップに拡張ACLが含まれていない場合（[[#samba_backupスクリプトについて|samba_backupスクリプトについて]]を参照）、以下を実行する必要があります：

<pre># samba-tool ntacl sysvolreset</pre>
Bind as DNSバックエンドを使用する場合は、DNSデータベースのハードリンクを修正する必要があります。

<pre># samba_upgradedns --dns-backend=BIND9_DLZ</pre>
「[[BIND9 DLZ DNSバックエンド#新しいDNSエントリが解決できない|DNSバックエンド BIND - 新しいDNSバックエンドエントリが解決できない]]」を参照してください。

これで、sambaを起動し、復元が成功したかどうかをテストできます。

'''ヒント'''：バックアップから単一のデータベースを復元することは可能ですが、一部のデータベースは他のデータベースにリンクされている可能性があるため、矛盾するシステムがないように注意してください。壊れたデータベースが他のデータベースに依存しているかどうか不明な場合は、http://lists.samba.orgの[mailto:samba-technical@lists.samba.org samba技術的]メーリングリストに問い合わせるか、すべてを復元する必要があります。

Samba AD DCのバックアップとリストア

2019-03-12T15:06:30Z

Meisina04: ページの作成:「 : {{Imbox | type = important | text = This page describes creating a backup on Samba v4.9 onwards. For backups on Samba v4.0-v4.8, see Using_the_samba_backup_script|he…」

: {{Imbox
| type = important
| text = This page describes creating a backup on Samba v4.9 onwards. For backups on Samba v4.0-v4.8, see [[Using_the_samba_backup_script|here]] for more details.
}}

== Overview ==

Samba backups provide a way to recover your Samba network, in the unlikely event that a catastrophic failure of the domain occurs.

There are a few different flavours of backup, which work in different ways and achieve different things:

* '''Online'''. This takes a clone of a running DC's database. It's similar in functionality to joining a new DC to the network.
* '''Offline''' (or 'local'). This backs up the Samba files as they appear on disk. This includes replication meta-data that's local to this particular DC and which is not included in online backups. It can also create a backup file when the DC is offline (i.e. the <code>samba</code> process is not actually running).
* '''Rename'''. This produces a backup file with the domain renamed, and is intended as only a temporary replacement.

These different types of backup have several things in common. The backups are all produced using a variant of the 'samba-tool domain backup' command. Each command creates a .tar.bz2 backup-file which contains an entire backup of the domain (based on a given DC). The backup-file can then be used to restore the domain using the 'samba-tool domain backup restore' command.

: {{Imbox
| type = important
| text = Note that the backup-file is a backup of your ''domain'', not your ''DC''. Restoring the backup-file will create a brand new DC with your domain's information. To restore subsequent DCs you must then [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|join]] fresh new DCs to the restored DC.
}}

== So which backup should I use? ==

This is a difficult question to answer, as it somewhat involves predicting how your Samba domain will fail. It also depends on how you plan to react to the failure. By creating a backup, you may be trying to achieve one of several different objectives:

* Provide temporary replacment DC(s), which will buy you time while you troubleshoot and fix the problems on your original Samba network.
* Provide a long-term replacement for your domain, i.e. you plan to completely discard your failed domain and rollback to the last backup taken.
* Provide forensics on why the domain failure occurred in the first place, e.g. if a database corruption occurred, what factors may have led to the problem?
* Provide a 'good working state' database that can be used as a guide for repairing and recovering deleted or corrupted objects in the production database.

The rename backup works best for providing a temporary replacement domain, however, it is no good as a long-term replacement for the domain. Normally you can't run restored DCs and troubleshoot the failed domain DCs at the same time, because both will be using the same domain name (which will cause even more wild and weird problems to appear in your network). However, because the renamed backup is using a different domain name, it means you can safely run both the restored domain and the original domain in parallel.

The online backup works best for providing a long-term replacement for your domain. It can be used as a temporary replacement, but you cannot easily troubleshoot the failed domain DCs at the same time. Investigating the reason behind the failure of a Samba domain could be time-consuming and technically complex work. If, in the event of a catastrophic domain failure, you don't intend to investigate the problem and just want to revert back to a older copy of a working domain, then this is the best option for you.

The offline backup works best for forensics purposes, as it contains additional data that is not normally replicated. It can also be quicker to run an offline backup for a large domain, as you don't have the extra overhead of sending the database over the network and re-writing it to disk. However, note that the offline backup-file contains all the sensitive/secret information for your entire domain, so you still may not be able to share this backed-up information easily with Samba developers or mailing-lists. Also note that because the backup is copying the actual database on disk, there is potentially more chance that a corruption in the database is copied through to the backup.

If you want to create multiple different types of backups, note that the details of the backup are saved in a 'backup.txt' file within the backup-file itself.

== Testing the backup restoration ==

The often overlooked step in any disaster recovery plan is testing that your recovery system actually works before you need to put it into practice. Creating the backup-file is not much good if <code>samba</code> fails to start up on your restored DC.

Note that the backup/restore commands are new to Samba v4.9, and there may be something specific to your network which means they don't work as well as intended. It's better to find any problems now (and report them to the Samba mailing-list), rather than in an emergency.

Unfortunately, testing a Samba backup is hard to do. Because the online and offline backups use the exact same domain information as your production network, it is not safe to run <code>samba</code> on a restored backup - the restored DC will interfere with your production network traffic.

Here are a few options to help you gain confidence that your Samba backup will actually be useful.
* If you're generating a 'rename' backup, then it's always safe to restore the backup-file onto a new DC and start <code>samba</code> on it. So you can always sanity-check that your rename backup works successfully. A rename backup is quite similar to an online backup, so if your rename backup works, then you can have some confidence that your online backup would probably work too.
* It's always safe to restore the backup-file to disk, as long as you don't actually start <code>samba</code> on the restored database. You could then use tools like ldbsearch (by specifying the local filepath of the database on disk) to sanity-check database objects were backed up correctly.
* If you just want to get a better feel for what the various backup options do, one option is to [[create a samba lab-domain]], and then create and restore online/offline backups within the lab domain itself.
* Another option is configure your network switches to ''completely'' isolate the restored DC from the rest of your Samba network, although in practice this proves quite tricky to get right.

Note that the backup tool creates a 'warts and all' copy of the domain database. If you don't run <code>samba-tool dbcheck</code> over your Samba database regularly, then it's worth getting into the habit, especially before you generate a new backup. Otherwise, any problems in your database will persist right through a backup and restore of your domain. Dbcheck will report any obvious problems that exist in your database, and provides a '--fix' option that will resolve the problems for you.

== Online DC backup ==

To create an online backup, use:

<pre>sudo samba-tool domain backup online --targetdir=<output-dir> --server=<DC-server> -UAdministrator</pre>

This command can be run locally on the DC or remotely. If running the command remotely, you may want to specify a <code>--configfile</code> option so that the correct smb.conf settings get included in the backup.

== Offline/local DC backup ==

To create a offline backup, login on the DC you're backing up, and simply specify the target-directory location to write the backup-file to. E.g.

<pre>sudo samba-tool domain backup offline --targetdir=<output-dir></pre>

Note that despite this option's name, the DC does not actually need to be offline when running this command. The tool is simply backing up the local files and it has sufficient locking in place to ensure the backup is generated safely.

Note that while the other backup commands are available from Samba v4.9 onwards, the offline command is not included until the subsequent Samba release.

== Domain rename backup ==

For more details on creating a rename backup, see [[Domain rename tool]].

== Untarring backups ==

If you simply want to use the backup for forensic purposes (i.e. interrogating the details of specific database objects in a 'good' state), then it's safe to just untar the backup-file and query the database directly on disk. Note that you cannot run <code>samba</code> on an untarred backup - you ''must'' use the restore command to do this.

== Restoring the domain ==

In the event of a catastrophic domain failure, to restore the domain from backup-file you would do the following:
<ol>
<li> Stop <code>samba</code> on ''all'' the old DCs. (Unless you're using a renamed backup, in which case you can skip this step).
<li> Run the 'samba-tool domain backup restore' command to restore the domain database on a single new DC. See below for more details.
<li> Start <code>samba</code> on the new DC.
<li> Re-add the old DCs back to the network by [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|joining]] them to the restored DC, e.g.
<pre>samba-tool domain join <dns-realm> DC --server=<restored-dc></pre>
<li> If you're using a renamed backup, you would then need to re-configure your network appliances so that traffic is redirected to the restored domain, instead of the failed/original domain.
</ol> 
: {{Imbox
| type = important
| text = Note that the backup-file is recovering the ''entire domain'', not a specific DC. The 'samba-tool domain backup restore' step is only done once, which re-creates the domain on a single DC. All old DCs must then be re-joined to the restored DC, in order to rejoin the domain.
}}

== Restoring the backup-file ==

The step to restore a backup is similar to the 'domain provision' you did back when you first setup your Samba network, except this time the backup contains all the database objects you've added since then. Similar to doing a provision, you need to specify a new DC when you run the restore command. This new DC '''''must not''''' have existed previously in the Samba network. The restore command will look something like:

<pre>sudo samba-tool domain backup restore --backup-file=<tar-file> --newservername=<DC-name> --targetdir=<new-samba-dir></pre>

Note that the target-directory specified must be empty (or non-existent). This means it's not practical to restore the domain database back into the default installation location (e.g. <tt>/usr/local/samba</tt>). Instead, we recommend that you restore the domain database into a different targetdir, and then use the '-s' (or '--configfile') option when running <code>samba</code>, e.g.

<pre>samba -s <targetdir>/etc/smb.conf</pre>

Specifying the restored smb.conf will mean that Samba will use the database files in the correct location.

The restored DC will be added to the 'Default-First-Site-Name' site. This site will be created in the restored DB if it does not already exist. You can specify an alternative site to add the restored DC to using the <tt>--site</tt> option.

Before starting <code>samba</code> on the restored DC, you should double-check the restored smb.conf settings are correct. It may also be helpful to run <code>samba_dnsupdate</code> (although this still gets run automatically when you start <code>samba</code>).

== Recommended strategy ==

Restoring the backup-file has a couple of minor annoyances:
* Having to use a different directory to the default installation location.
* Having to specify a different DC server-name to what was previously in your network.

The simple way to minimize these annoyances is to use a temporary server (or VM) for your restored DC. i.e.
* Restore the backup-file onto the temporary DC and start Samba.
* Rejoin the original DCs to the temporary DC one at a time. You can re-use the same server-name and default installation location during the join.
* Once all the original DCs have joined the restored domain, you can remove the temporary DC (i.e. using 'samba-tool domain demote'). Your network of DCs should now be exactly the same as it was previously (except hopefully now in a valid working state!).

= Troubleshooting =

Note that if the backup or restore commands unexpectedly throw an error, they may leave behind a temporary directory in the <code>--targetdir</code> you specified. These may help to provide clues as to why the failure occurred. If you're running the restore command, then you will need to clean these up manually before re-running the command.

== Creating Backups ==

* Note that you should run the backup as root. Online backups can actually succeed as a non-root user, but it will cause you headaches later when you try to restore it.

* For 'online' or 'rename' backups, sanity-check that the credentials and server details you're using are correct. E.g. try:
<pre>ldbsearch -H ldap://<server> -UAdministrator</pre>

* Try increasing the debug-level to see if that tells you more about the failure. E.g. add the <code>--debug=3</code> option to the command.

* The 'online' and 'rename' commands work in a very similar way to a joining a DC. If joining a DC is known to fail on your network, then these commands are unlikely to work either. If you see the 'Committing SAM database' and 'Cloned domain <domain>' messages, then the join-like part of the backup has likely succeeded.

* The backup tools do not work against a Windows DC (mostly just backing up the sysvol files fails). If you have a mixed DC domain, then backup a Samba DC rather than a Windows DC.

* When doing an 'online' or 'rename' backup, samba-tool connects to DC over SMB to backup the sysvol share files (and their NTACLs). Depending on the 'min/max protocol' smb.conf settings on your client/server, this SMB connection may fail, producing an error like:

<pre>
Cloned domain BACKUPDOMAIN (SID S-1-5-21-2948945078-3345239999-1381142759)
smbXcli_negprot: SMB signing is mandatory and the selected protocol level doesn't support it.
ERROR(runtime): uncaught exception - (3221225506, '{Access Denied} A process has requested access to an object but has not been granted those access rights.')
File "bin/python/samba/netcmd/__init__.py", line 183, in _run
return self.run(*args, **kwargs)
File "bin/python/samba/netcmd/domain_backup.py", line 248, in run
smb_conn = smb.SMB(server, "sysvol", lp=lp, creds=creds, sign=True)
</pre>

:This error message is a little misleading. The problem is the backup tool only works with SMBv1 protocols, and recent CVEs have recommended disabling SMBv1 on your DCs. Therefore the client and server cannot negotiate a compatible protocol, and the SMB connection can't be established. Bug #13621 is currently tracking this issue. The current workaround is to either do an 'offline' backup locally on the DC (which doesn't require an SMB connection), or to temporarily re-enable SMBv1 while the backup is made.

* An unusual corner-case is where you try to backup a brand new DC, before it's allocated a RID, which results in an error like below. Most users would be unlikely to ever see this, but if you do, the solution is to add a temporary user (i.e. <tt>samba-tool user create</tt>), just to force a RID allocation.
<pre>
samba-tool domain backup offline --targetdir=/home/ubuntu/backup<ldb result>
ERROR(<type 'exceptions.IndexError'>): uncaught exception - list index out of range
File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/__init__.py", line 184, in _run
return self.run(*args, **kwargs)
File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/domain_backup.py", line 941, in run
sid = get_sid_for_restore(samdb)
File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/domain_backup.py", line 80, in get_sid_for_restore
rid = int(res[0].get('rIDNextRID')[0])
</pre>

* Note that offline backups require the lmdb-utils package installed, otherwise it throws an exception trying to run mdb_copy(). E.g.
<pre>
ERROR(<type 'exceptions.OSError'>): uncaught exception - [Errno 2] No such
file or directory
File "bin/python/samba/netcmd/__init__.py", line 184, in _run
return self.run(*args, **kwargs)
File "bin/python/samba/netcmd/domain_backup.py", line 982, in run
self.backup_smb_dbs(paths.private_dir, samdb, lp, logger)
File "bin/python/samba/netcmd/domain_backup.py", line 907, in backup_smb_dbs
copy_function(sam_file)
File "bin/python/samba/netcmd/domain_backup.py", line 866, in
offline_mdb_copy
mdb_copy(path, path + self.backup_ext)
File "bin/python/samba/mdb_util.py", line 35, in mdb_copy
status = subprocess.check_call(mdb_copy_cmd, close_fds=True, shell=False)
File "/usr/lib64/python2.7/subprocess.py", line 185, in check_call
retcode = call(*popenargs, **kwargs)
File "/usr/lib64/python2.7/subprocess.py", line 172, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib64/python2.7/subprocess.py", line 394, in __init__
errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1047, in _execute_child
raise child_exception
</pre>

* Running the backup against a Windows DC generally fails during the backup of the sysvol share. You may see an error like the following:
<pre>
INFO 2019-01-15 15:29:11,850 pid:208088 bin/python/samba/join.py #1554: Cloned domain WINDOWS2012R2 (SID S-1-5-21-886655096-618523297-2770022155)
ERROR(runtime): uncaught exception - (3221225539, 'A file cannot be opened because the share access flags are incompatible.')
File "bin/python/samba/netcmd/__init__.py", line 184, in _run
return self.run(*args, **kwargs)
File "bin/python/samba/netcmd/domain_backup.py", line 264, in run
backup_online(smb_conn, sysvol_tar, remote_sam.get_domain_sid())
File "bin/python/samba/ntacls.py", line 512, in backup_online
ntacl_sddl_str = smb_helper.get_acl(r_name, as_sddl=True)
File "bin/python/samba/ntacls.py", line 334, in get_acl
smb_path, SECURITY_SECINFO_FLAGS, SECURITY_SEC_FLAGS)
</pre>

The problem seems to be accessing the DfsrPrivate\Deleted and DfsrPrivate\Installing folders.

== Restoring backups ==

* The restore command needs to be run as root. Part of the backup process involves preserving and restoring the NTACLs of the sysvol files, and some of the file operations involved require root permissions. If you're not root, then you'll probably see an error like:
<pre>ERROR(<type 'exceptions.TypeError'>): uncaught exception - (1, 'Operation not permitted')
File "bin/python/samba/netcmd/__init__.py", line 177, in _run
return self.run(*args, **kwargs)
File "bin/python/samba/netcmd/domain_backup.py", line 520, in run
backup_restore(sysvol_tar, dest_sysvol_dir, samdb, smbconf)
File "bin/python/samba/ntacls.py", line 589, in backup_restore
ntacls_helper.setntacl(dst, ntacl_sddl_str)
File "bin/python/samba/ntacls.py", line 445, in setntacl
return setntacl(self.lp, path, ntacl_sd, self.dom_sid)
File "bin/python/samba/ntacls.py", line 214, in setntacl
ndr_pack(ntacl))
</pre>

* The <code>--newservername</code> you specify for the restored DC must not already exist in the original domain. Otherwise you'll see an error like:
<pre>
Adding CN=PROD-DC,OU=Domain Controllers,DC=lab,DC=example,DC=com
ERROR(ldb): uncaught exception - Entry CN=PROD-DC,OU=Domain Controllers,DC=lab,DC=example,DC=com already exists
File "bin/python/samba/netcmd/__init__.py", line 177, in _run
return self.run(*args, **kwargs)
File "bin/python/samba/netcmd/domain_backup.py", line 439, in run
ctx.join_add_objects(specified_sid=dom_sid(sid))
File "bin/python/samba/join.py", line 625, in join_add_objects
ctx.samdb.add(rec, controls=controls)
</pre>

* If the backup command was run locally on the DC, then the backup-file should contain the DC's smb.conf. However, the smb.conf in the backup-file may contain 'interfaces' configuration that doesn't match the IP addresses on the DC you're restoring on. If this happens, you'll get an error like:
<pre>
Looking up IPv4 addresses
WARNING: no network interfaces found
No IPv4 address will be assigned
Looking up IPv6 addresses
WARNING: no network interfaces found
No IPv6 address will be assigned
ERROR: Please specify a host-ip for the new server
</pre>
: You can avoid this problem by specifying a <code>--host-ip</code> argument during the restore. This should only affect rename backups.

== Starting samba ==

If you ran the backup as a non-root user, the restore will still succeed, but you'll hit errors when you try to start <code>samba</code>. E.g.
<pre>
sudo samba -s /tmp/online4/etc/smb.conf -i -d 3
samba version 4.10.0pre1-DEVELOPERBUILD started.
Copyright Andrew Tridgell and the Samba Team 1992-2018
...
directory_create_or_exist_strict: invalid ownership on directory /tmp/restore/private/msg.sock
exit_daemon: STATUS=daemon failed to start: Samba failed to setup parent messaging, error code -1073741801
</pre>
: You could <tt>chown</tt> your way out of this, but it's a lot simpler just to run the backup command as root.

[[Category:Backup]] [[Category:Active Directory]]

Sambaバックアップスクリプトを使用する

2019-03-12T15:02:26Z

Meisina04: Meisina04 がページ「Samba AD DCのバックアップとリストア」を「Sambaバックアップスクリプトを使用する」に移動しました

== はじめに ==

: {{Imbox
| type = content
| style = margin:4px 2%;
| text = このページはSamba v4.0-v4.8上でバックアップを作成することについて記載しています。Samba v4.9以降では、バックアップの作成が大幅に改善されました。詳細はこちらを参照してください。
}}

このドキュメントの内容は、samba 4.xで使用するためのものです。

これは、Samba AD DCのバックアップと復元に関するチュートリアルです。それは有用であることが期待されていますが、保証は一切ありません！

'''この行が削除されるまで、このドキュメントはDRAFTとみなされます。'''

== 一般 ==

{{imbox
| type = content
| style = margin:4px 2%;
| text = 警告：複数のDCを動作させている場合：バックアップからDCを復元しないでください。レプリケーションのメタデータが同期しなくなると、ディレクトリが破損します。
}}

少なくとも1つの他のDCがまだ動作している場合は、[[Samba DCを既存のActive Directoryに参加させる|新しいマシンをDCとして再び接続]]します。他の実行中のDCからすべてが同期されます - まだ実装されていないSysVolレプリケーションを除きます。

{{imbox
| style = margin:4px 2%;
| text = 元のDC上でのみバックアップを使用し、新しいDCに移動してDCをアップグレードすることは絶対にしないでください。この場合、代わりに新しいDCに参加してください。
}}

ドメイン内のすべてのDCが壊れている場合は、http://lists.samba.orgのsamba-technicalメーリングリストに投稿して、これを解決する最善の方法について議論する必要があります。

=== LDBおよびTDBファイルのバックアップ/リストア方法 ===

'samba_backup'スクリプトを修正する予定がある場合や独自のソリューションを作成する場合は、ここでいくつかの有益な情報を見つけるでしょう：

* 実行中のデータベースを決してコピーする必要はありませんが、<code>* .ldb</code>＆<code>* .tdb</code>ファイルを'tdbbackup'でオンラインでバックアップできます。
* tdbbackupによって作成されたファイルは、完全なTDBファイルと通常のTDBファイルです。 tdbbackupは安全に抽出を行います。
* <code>* .ldb</code>ファイルのバックアップは、単に '.bak'というサフィックスを削除するだけで元の名前に復元できます。

=== samba_backupスクリプトについて ===

Sambaはデータベースをバックアップする非常に基本的なシェルスクリプトを提供しています（ソースtarballの<code>source4/scripting/bin/samba_backup</code>）。これには、Sambaインストール全体が1つの場所にあることが必要です（<code>/usr /local/samba/</code>など）。 configureオプションを使用して異なる場所にsambaを格納している場合は、スクリプトを調整するか、ベースとして使用して独自のスクリプトを作成できます。

スクリプトは非常に基本的なものであり、それをそのまま使用する予定がある場合、注意すべき点が1つあります。

* スクリプトは拡張ACLをバックアップしません。したがって、あなたはパーミッションを失います（例：SysVol共有）。--xattrsオプションをサポートするtarバージョン（tarのマンページを参照）がある場合は、このオプションをスクリプト内のすべての 'tar'コマンドに追加する必要があります。これにより、tarはアーカイブ内の拡張ACLを保持できます。

== バックアップ ==

Sambaのバックアップスクリプトは、 'make install'によってインストールされません。ソースディレクトリ（<code>source4/scripting/bin/samba_backup</code>）から<code>/usr/sbin</code>のような場所にコピーし、安全な権限を設定する必要があります：

<pre># cp .../source4/scripting/bin/samba_backup /usr/sbin
# chown root:root /usr/sbin/samba_backup
# chmod 750 /usr/sbin/samba_backup</pre>
スクリプト内の以下の変数を必要に応じて調整します。

<pre>FROMWHERE=/usr/local/samba
WHERE=/usr/local/backups
DAYS=90</pre>
<code>$WHERE</code>変数に設定してアクセス権を設定した宛先フォルダを作成します。

<pre># mkdir /usr/local/backups
# chmod 750 /usr/local/backups</pre>
最初のテストのバックアップスクリプトを開始します。

<pre># /usr/sbin/samba_backup</pre>
スクリプトがエラーなしで終了する場合は、出力先フォルダに3つのファイルがあります。

* <code>etc.{Timestamp}.tar.bz2</code>
* <code>samba4_private.{Timestamp}.tar.bz2</code>
* <code>sysvol.{Timestamp}.tar.bz2</code>

テストバックアップが成功した場合は、毎日のバックアップ用にcronジョブを追加する必要があります。

<pre># crontab -e</pre>
毎日2:00AMにバックアップするために、次の行を追加します。

<pre>0 2 * * * /usr/sbin/samba_backup</pre>
注意：cronを使用してスクリプトを実行するときは、すべての必要なバイナリが<code>$PATH</code>変数の一部であるディレクトリにあることを確認してください。正しいパスがシステム全体で定義されていない場合は、変数をcrontabに設定するか、またはスクリプトの先頭でshebang(#!)行の後に設定します。

== リストア ==

以下のリストアガイドでは、 'samba_backup'スクリプトを使用してデータベースをバックアップしたことを前提としています。独自のスクリプトをお持ちの場合は、手順を調整してください。

'''非常に重要なメモ：'''

* '''同時に、復元とバージョンの変更を行わないでください！バックアップを作成したものと同じSambaバージョンを使用しているシステムでは、常に復元してください！'''
* '''同じIPとホスト名を持つシステムでは、常にリストアしてください。そうしないと、KerberosとDNSの問題が発生します。'''
* '''推奨：バックアップを作成したのと同じOSで復元してください。'''

'''復元状況で最も重要なことは、システムを実行状態に戻すことです。すべてアップしてテストされたら、必要な変更を行うことができます。復元と一緒に変更しようとしないでください！'''

システム全体が壊れている場合は、まずHowTo（[[SambaをActive Directoryドメインコントローラとして設定する]]）の説明に従ってマシン全体をセットアップする必要があります。

復元するフォルダを削除します（sambaは停止している状態で）：

<pre># rm -rf /usr/local/samba/etc
# rm -rf /usr/local/samba/private
# rm -rf /usr/local/samba/var/locks/sysvol</pre>
最新の作業用バックアップファイルを元の場所に展開します。

<pre># cd /usr/local/backups
# tar -jxf etc.{Timestamp}.tar.bz2 -C /usr/local/samba/
# tar -jxf samba4_private.{Timestamp}.tar.bz2 -C /usr/local/samba/
# tar -jxf sysvol.{Timestamp}.tar.bz2 -C /usr/local/samba/</pre>
<code>private</code>ディレクトリの<code>*.ldb.bak</code>ファイルの名前を<code>*.ldb</code>に戻します。これはGNU <code>find</code> と<code>Bash</code>で行うことができます：

<pre># find /usr/local/samba/private/ -type f -name '*.ldb.bak' -print0 | while read -d $'\0' f ; do mv "$f" "${f%.bak}" ; done</pre>
バックアップに拡張ACLが含まれていない場合（[[#samba_backupスクリプトについて|samba_backupスクリプトについて]]を参照）、以下を実行する必要があります：

<pre># samba-tool ntacl sysvolreset</pre>
Bind as DNSバックエンドを使用する場合は、DNSデータベースのハードリンクを修正する必要があります。

<pre># samba_upgradedns --dns-backend=BIND9_DLZ</pre>
「[[BIND9 DLZ DNSバックエンド#新しいDNSエントリが解決できない|DNSバックエンド BIND - 新しいDNSバックエンドエントリが解決できない]]」を参照してください。

これで、sambaを起動し、復元が成功したかどうかをテストできます。

'''ヒント'''：バックアップから単一のデータベースを復元することは可能ですが、一部のデータベースは他のデータベースにリンクされている可能性があるため、矛盾するシステムがないように注意してください。壊れたデータベースが他のデータベースに依存しているかどうか不明な場合は、http://lists.samba.orgの[mailto:samba-technical@lists.samba.org samba技術的]メーリングリストに問い合わせるか、すべてを復元する必要があります。

2019-03-09T07:33:52Z

Meisina04:

= はじめに =

<code>Winbindd</code>サービスを使用すると、次のことが可能になります。

* <code>chown</code> や<code>chgrp</code> などのローカルコマンドでドメインユーザやドメイングループを使用できます。
* <code>ls</code> コマンド等で、ドメインユーザやグループを表示できます。

Samba アクティブディレクトリ(AD)ドメインコントローラ(DC)での<code>Winbindd</code>の構成は、ドメインメンバの場合とは異なります。ドメインメンバとしてサービスを設定するには、[[Sambaをドメインメンバとして構成する]] を参照して下さい。

== Winbind と Winbinddサービスとの違い==

Samba 4.0と4.1は、<code>samba</code>コマンドに組み込まれた新しい<code>Winbind</code>実装を使用していました。しかし、この実装は正
しく機能しませんでした。このため、Samba 4.2では<code>winbindd</code>ユーティリティをドメインコントローラ（DC）で使用することがで
きました。 Samba 4.2よりも前のSambaを実行している場合、<code>Winbindd</code>を使用する前に、サポートされているバージョンに更新してください。詳細は、「[[Sambaの更新]]」を参照してください。

== Sambaドメインコントローラ上でのIDマッピング ==

IDマッピングは、Samba ドメインコントローラ(DC)では、ドメインメンバの場合とは異なる動作をします。例えば、<code>smb.conf</code> ファイルで<code>ad</code>(rfc2307)や<code>rid</code>などのIDマッピングバックエンドを構成することはサポートされていないため、<code>samba</code>サービスが失敗する可能性があります。詳細については「[[Sambaの更新#idmap configパラメータがsmb.confファイルで設定されているとドメインコントローラ上の共有にアクセスできない|idmap configパラメータがsmb.confファイルで設定されているとドメインコントローラ上の共有にアクセスできない]]」を参照して下さい

SambaアクティブディレクトリDCでは、<code>Winbindd</code>は常にユーザID(<code>UID</code>)およびグループID(<code>GID</code>)を、ADオブジェクトに設定された<code>uidNumber</code>および<code>gidNumber</code>属性で設定された値から、読み取ります。<code>UID</code>または<code>GID</code>が割りあてられていないユーザ、及びグループの場合、IDはDC上でローカルに作成され、<code>/usr/local/samba/private/idmap.ldb</code>に格納されます。

{{imbox
| style = margin:4px 2%;
| text = ローカルIDが生成された後にADオブジェクトのプロパティにIDを設定すると、Winbinddはwinbinddのキャッシュの有効期限が切れた後、または<code>net cache flush</code>を手動で実行した後にディレクトリの値を使用します。
オペレーティングシステムは、IDを使用してファイルの所有権を管理します。ユーザーが新しいIDを使用してファイルにアクセスできるように、ファイルのアクセス許可を手動でリセットする必要があります。
}}

= smb.confファイルでの<code>Winbindd</code>パラメータの設定 =

Samba Active Directory（AD）ドメインコントローラ（DC）上で<code>Winbindd</code>を実行するには、ほとんどの場合、<code>smb.conf</code>ファイルの設定は必要ありません。

ユーザーIDとグループIDは、Active Directory（AD）からロードされるか、ローカルで自動的に生成されます。詳細については、「[[#Sambaドメインコントローラ上でのIDマッピング|Sambaドメインコントローラ上でのIDマッピング]]」を参照してください。

Samba DCでは、winbindテンプレートモードのみがサポートされています。このモードでは、すべてのユーザーが以下を取得します。

* 割り当てられたホームディレクトリパス。<code>template homedir</code>パラメータで設定します。このパラメータのデフォルト値は<code>/home/%D/%U</code>です。
* 割り当てられたシェル。<code>template shell</code>パラメーターで設定します。このパラメータのデフォルト値は<code>/bin/false</code>です。

<code>Winbindd</code>が提供するすべてのドメインユーザーにログオンシェルとして<code>/bin/bash</code>と、ホームディレクトリパスとし
て <code>/home/%U</code>を割り当てるには：

* <code>smb.conf</code>ファイルの<code>[global]</code>セクションに次のパラメータを追加します。

<pre> template shell = /bin/bash
template homedir = /home/%U</pre>
詳細は、<code>smb.conf（5）</code>のマニュアルページを参照してください。

* sambaサービスを再起動します。

{{imbox
| type = speedy
| style = margin: 4px 2%;
| text = Samba AD DCでは、<code>smb.conf（5）</code>のマニュアルページに記載されているすべての<code>Winbindd</code>関連パラメータがサポートされているわけではありません。さらに、<code>idmap config</code>などの一部のパラメータでは、<code>samba</code>サービスが失敗する可能性があります。現在、マニュアルページでは、DCでサポートされているパラメータは強調表示されていません。したがって、デフォルトを維持するか、このセクションで説明するパラメータのみを使用することをお勧めします。
}}

= Libnss winbindリンク =

{{:Libnss_winbind_リンク}}

= ネームサービススイッチの設定 =

ネームサービススイッチ（NSS）ライブラリを有効にして、ドメインユーザとグループをローカルシステムで使用できるようにするには：

* <code>/etc/nsswitch.conf</code>ファイルの次のデータベースに<code>winbind</code>エントリを追加します。

passwd: files winbind
group: files winbind

:* 両方のデータベースの最初のソースとして<code>files</code>エントリを保持します。これにより、NSSはWinbindサービスを照会する前に<code>/etc/passwd</code>および<code>/etc/group</code>ファイルからドメインユーザーとグループを検索できます。
:* <code>winbind</code>エントリをNSS <code>shadow</code>データベースに追加しないでください。これにより、<code>wbinfo</code>ユーティリティが失敗する可能性があります。
:* Sambaをコンパイルした場合、<code>libnss_winbind</code>ライブラリからOSのシステムライブラリパスにシンボリックリンクを追加してください。詳細は、[[Libnss_winbind_リンク|Libnss winbind リンク]]を参照してください。Sambaのインストールにパッケージを使用した場合は、リンクは自動的に作成されます。

{{ imbox
| style = margin:4px 2%;
| text = ローカルの<code>/etc/passwd</code>ファイルでドメインと同じユーザー名を使用しないでください。
}}

= winbinddサービス =

Samba Active Directory（AD）ドメインコントローラ（DC）で<code>winbindd</code>サービスを手動で起動しないでください。このサービスは、<code>samba</code>プロセスのサブプロセスとして自動的に開始されます。確認するには、次を入力します。

<pre># ps axf
...
2156 ? Ss 0:00 /usr/local/samba/sbin/samba -D
2158 ? S 0:00 \_ /usr/local/samba/sbin/samba -D
2172 ? R 0:00 \_ /usr/local/samba/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
...</pre>

= Winbindd接続のテスト =
[[Sambaをドメインメンバーとして設定#Winbindへの接続を確認|Winbindへの接続を確認]]を参照。

= PAMを利用したドメインユーザーの認証 =

[[PAMを使用したドメインユーザーの認証]]を参照。

----
[[Category:Active Directory]]

Samba AD DC上でのWinbinddの設定

2019-03-09T07:32:22Z

Meisina04:

= はじめに =

<code>Winbindd</code>サービスを使用すると、次のことが可能になります。

* <code>chown</code> や<code>chgrp</code> などのローカルコマンドでドメインユーザやドメイングループを使用できます。
* <code>ls</code> コマンド等で、ドメインユーザやグループを表示できます。

Samba アクティブディレクトリ(AD)ドメインコントローラ(DC)での<code>Winbindd</code>の構成は、ドメインメンバの場合とは異なります。ドメインメンバとしてサービスを設定するには、[[Sambaをドメインメンバとして構成する]] を参照して下さい。

= Winbind と Winbinddサービスとの違い==

Samba 4.0と4.1は、<code>samba</code>コマンドに組み込まれた新しい<code>Winbind</code>実装を使用していました。しかし、この実装は正
しく機能しませんでした。このため、Samba 4.2では<code>winbindd</code>ユーティリティをドメインコントローラ（DC）で使用することがで
きました。 Samba 4.2よりも前のSambaを実行している場合、<code>Winbindd</code>を使用する前に、サポートされているバージョンに更新してください。詳細は、「[[Sambaの更新]]」を参照してください。

= Sambaドメインコントローラ上でのIDマッピング =

IDマッピングは、Samba ドメインコントローラ(DC)では、ドメインメンバの場合とは異なる動作をします。例えば、<code>smb.conf</code> ファイルで<code>ad</code>(rfc2307)や<code>rid</code>などのIDマッピングバックエンドを構成することはサポートされていないため、<code>samba</code>サービスが失敗する可能性があります。詳細については「[[Sambaの更新#idmap configパラメータがsmb.confファイルで設定されているとドメインコントローラ上の共有にアクセスできない|idmap configパラメータがsmb.confファイルで設定されているとドメインコントローラ上の共有にアクセスできない]]」を参照して下さい

SambaアクティブディレクトリDCでは、<code>Winbindd</code>は常にユーザID(<code>UID</code>)およびグループID(<code>GID</code>)を、ADオブジェクトに設定された<code>uidNumber</code>および<code>gidNumber</code>属性で設定された値から、読み取ります。<code>UID</code>または<code>GID</code>が割りあてられていないユーザ、及びグループの場合、IDはDC上でローカルに作成され、<code>/usr/local/samba/private/idmap.ldb</code>に格納されます。

{{imbox
| style = margin:4px 2%;
| text = ローカルIDが生成された後にADオブジェクトのプロパティにIDを設定すると、Winbinddはwinbinddのキャッシュの有効期限が切れた後、または<code>net cache flush</code>を手動で実行した後にディレクトリの値を使用します。
オペレーティングシステムは、IDを使用してファイルの所有権を管理します。ユーザーが新しいIDを使用してファイルにアクセスできるように、ファイルのアクセス許可を手動でリセットする必要があります。
}}

= smb.confファイルでの<code>Winbindd</code>パラメータの設定 =

Samba Active Directory（AD）ドメインコントローラ（DC）上で<code>Winbindd</code>を実行するには、ほとんどの場合、<code>smb.conf</code>ファイルの設定は必要ありません。

ユーザーIDとグループIDは、Active Directory（AD）からロードされるか、ローカルで自動的に生成されます。詳細については、「[[#Sambaドメインコントローラ上でのIDマッピング|Sambaドメインコントローラ上でのIDマッピング]]」を参照してください。

Samba DCでは、winbindテンプレートモードのみがサポートされています。このモードでは、すべてのユーザーが以下を取得します。

* 割り当てられたホームディレクトリパス。<code>template homedir</code>パラメータで設定します。このパラメータのデフォルト値は<code>/home/%D/%U</code>です。
* 割り当てられたシェル。<code>template shell</code>パラメーターで設定します。このパラメータのデフォルト値は<code>/bin/false</code>です。

<code>Winbindd</code>が提供するすべてのドメインユーザーにログオンシェルとして<code>/bin/bash</code>と、ホームディレクトリパスとし
て <code>/home/%U</code>を割り当てるには：

* <code>smb.conf</code>ファイルの<code>[global]</code>セクションに次のパラメータを追加します。

<pre> template shell = /bin/bash
template homedir = /home/%U</pre>
詳細は、<code>smb.conf（5）</code>のマニュアルページを参照してください。

* sambaサービスを再起動します。

{{imbox
| type = speedy
| style = margin: 4px 2%;
| text = Samba AD DCでは、<code>smb.conf（5）</code>のマニュアルページに記載されているすべての<code>Winbindd</code>関連パラメータがサポートされているわけではありません。さらに、<code>idmap config</code>などの一部のパラメータでは、<code>samba</code>サービスが失敗する可能性があります。現在、マニュアルページでは、DCでサポートされているパラメータは強調表示されていません。したがって、デフォルトを維持するか、このセクションで説明するパラメータのみを使用することをお勧めします。
}}

= Libnss winbindリンク =

{{:Libnss_winbind_リンク}}

= ネームサービススイッチの設定 =

ネームサービススイッチ（NSS）ライブラリを有効にして、ドメインユーザとグループをローカルシステムで使用できるようにするには：

* <code>/etc/nsswitch.conf</code>ファイルの次のデータベースに<code>winbind</code>エントリを追加します。

passwd: files winbind
group: files winbind

:* 両方のデータベースの最初のソースとして<code>files</code>エントリを保持します。これにより、NSSはWinbindサービスを照会する前に<code>/etc/passwd</code>および<code>/etc/group</code>ファイルからドメインユーザーとグループを検索できます。
:* <code>winbind</code>エントリをNSS <code>shadow</code>データベースに追加しないでください。これにより、<code>wbinfo</code>ユーティリティが失敗する可能性があります。
:* Sambaをコンパイルした場合、<code>libnss_winbind</code>ライブラリからOSのシステムライブラリパスにシンボリックリンクを追加してください。詳細は、[[Libnss_winbind_リンク|Libnss winbind リンク]]を参照してください。Sambaのインストールにパッケージを使用した場合は、リンクは自動的に作成されます。

{{ imbox
| style = margin:4px 2%;
| text = ローカルの<code>/etc/passwd</code>ファイルでドメインと同じユーザー名を使用しないでください。
}}

= winbinddサービス =

Samba Active Directory（AD）ドメインコントローラ（DC）で<code>winbindd</code>サービスを手動で起動しないでください。このサービスは、<code>samba</code>プロセスのサブプロセスとして自動的に開始されます。確認するには、次を入力します。

<pre># ps axf
...
2156 ? Ss 0:00 /usr/local/samba/sbin/samba -D
2158 ? S 0:00 \_ /usr/local/samba/sbin/samba -D
2172 ? R 0:00 \_ /usr/local/samba/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
...</pre>

= Winbindd接続のテスト =
[[Sambaをドメインメンバーとして設定#Winbindへの接続を確認|Winbindへの接続を確認]]を参照。

= PAMを利用したドメインユーザーの認証 =

[[PAMを使用したドメインユーザーの認証]]を参照。

----
[[Category:Active Directory]]