Ubuntu
Samba

Ubuntu18.04 Samba-ad-dcのバックアップ

2019.06.30

各システムのユーザーをLDAPで一元管理しようと考えて、Kopanoから…と検討を始めた。作業を進めていくうちに、LDAPにスキーマを登録することになり、それがまた明確な場所が分からず、ちょっと登録を試してだめなら元に戻そうと考えた。



広告

現在稼働しているLDAPはSamba ad dc内蔵のもので、何らかの間違いで設定を壊すとちょっと面倒なことになる。しっかりとバックアップをとって元に戻せるようにしようと調べ始めたら、一週間が過ぎてしまった…

Samba ad dc バックアップスクリプト

前置き

色々探していたら、こんな素晴らしい仕事が！
GitHub / thctlo/samba4/backup-script
※こちらを利用される方は、以下の投稿を読む必要なしです。

また、Samba のバージョンが 4.9以上になれば samba-tool がバックアップ機能を持つらしいので、コンパイルして使う手がある。

それでもなおSamba Version 4.7.6-Ubuntu で、リスクを踏まえてバックアップをとってみようという方は読み進めてみてください。自信はないけど、それっぽいのができてマスです。

スクリプト

Samba が提供しているスクリプトに後述の考え方で手を加えてみた。
テストが不十分なため、利用する場合は自己責任で。
Use at your own risk, Because the test is insufficient.

2022/08/24版 samba_backup(zip圧縮)
2019/06/30版 samba_backup(zip圧縮)
★問題を発見したら教えてください。

  • 2019/06/30版
    • rootで実行すること。rootでないと操作できないディレクトリからバックアップを抽出するため。
    • スクリプトは private ディレクトリ以下の *.ldb.bak と *.tdb.bak を消す→作る→消すという動作をするので、これらのファイルを何らかに利用している場合には退避しておく必要あり。
    • バックアップ対象となるディレクトリはスクリプトの中で指定すること。元々はバックアップ対象となるディレクトリを1つだけ引数で受け取るようになっていたが、対象を3ヶ所に増やしたのでスクリプトへの直書きに変更。
    • バックアップ対象から netlogon_creds_cli.tdb を除外している。バックアップ処理でエラーが発生したため確認したところ、Samba-Bugzilla – Bug 13088 でバックアップの必要がないとの指摘があったので除外。
    • 拡張属性を各バックアップ対象ディレクトリの1つ上で acl.txt という名前で作成し、バックアップ対象ディレクトリに移動してバックアップし、その後に削除する。acl.txt というファイルが関係するディレクトリに存在する場合には上書き動作となるので注意。また、acl.txtはは参考情報でしかなく、拡張属性の復元には利用不可(エラーが発生)。
  • 2022/08/24版
    • acl.txtを作成する処理を削除。
    • sysvolについて、属性を復元するためのコマンドをNTACLというファイルに出力するよう変更。

バックアップ

スクリプトを実行するための事前準備(初回のみ)。

ダウンロードしたスクリプトを展開し、権限周りを整理して /usr/bin に投入。

$ unzip samba_backup.zip
$ sudo chown root:root samba_backup
$ sudo chmod 750 samba_backup
$ sudo mv samba_backup /usr/bin

スクリプトの中にある設定を修正。
/usr/bin/samba_backup

PROV_ETC=/etc/samba
PROV_PRV=/var/lib/samba/private
PROV_SVL=/var/lib/samba/sysvol
WHERE=/var/backup
DAYS=90             # Set default retention period.

PROV_*はバックアップ対象となるディレクトリを指定する。
インストール時に特別なことをしていないならば変えなくて良いと思う。存在の確認はスクリプトがやってくれるので、違っていたら修正…というレベルでいいかと。

WHEREはバックアップファイルができる場所。このディレクトリは存在しないので、どこか適切な場所を作り、そのディレクトリを指定する。

DAYSはバックアップファイルの保持期間。90日は長いかもしれない。14(2週間)くらいでいかが？

初回設定はここまで。

設定を終えたら、スクリプトを実行する。

$ sudo samba_backup

とれたバックアップの中身は以下で確認できる。

$ tar tvfj samba4_対象のファイル.tar.bz2

リストア

復元が必要になるのは設定を繰り返す最初のうちだけっぽいのと、ディレクトリをまるごと置き換えるような操作でたいした手間ではなさそうなことから、リストア用のスクリプトは作成していない(手抜き)。

以下のコマンドでファイルを解凍し、必要分を規定のディレクトリに持って行く。

$ tar jxvf samba4_対象のファイル.tar.bz2

sysvolについては、/var/lib/samba/sysvolに展開後、以下を実行することで、属性が復元できる。

$ sudo rm /var/lib/samba/sysvol/*
$ sudo tar jxvf samba4_sysvol.2022-08-24.tar.bz2 -C /var/lib/samba/
$ cd /var/lib/samba/
$ sudo bash sysvol/NTACL
$ sudo rm sysvol/NTACL

設定された結果が、何か状況が変わったことを感じるのに、以下のコマンドが使える。

$ sudo samba-tool ntacl get /var/lib/samba/sysvol --as-sddl
O:LAG:BAD:P(A;OICI;0x001f01ff;;;BA)(A;OICI;0x001200a9;;;SO)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)

属性設定前の状態だと、少し属性情報が長くなっている。

$ sudo samba-tool ntacl get /var/lib/samba/sysvol --as-sddl
O:LAG:BAD:(A;;0x001f01ff;;;LA)(A;;0x001f01ff;;;BA)(A;;;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD)

中身を詳しく確認したいときは、--as-sddlを外して実行すれば良いのではないだろうか。

なお、Samba Wikiには以下の記述があるので注意。

警告、複数のDCを実行している場合は、バックアップからDCを復元しないでください。レプリケーションメタデータが同期しなくなるため、ディレクトリが破損します。(Google先生の翻訳)

ウチのように1つのSamba ad dc を動かしている場合はここから復元ができそうだけれど、複数のDCを組み合わせて使っている場合には別の方法を考える必要がありそう。

バックアップスクリプトの考え方

バックアップ対象は何か、どうやればバックアップできるのかを整理しようと考えた。

バックアップの対象

明確にこれ！と教えてくれる場所を見つけることができなかったので、状況証拠の積み重ね＋カンで決めている。本当にこれで良いのか？

関連するディレクトリをビルド情報とsmb.confの設定値から確認。

$ samba -b
Samba version: 4.7.6-Ubuntu
Build environment:
Paths:
   BINDIR: /usr/bin
   SBINDIR: /usr/sbin
   CONFIGFILE: /etc/samba/smb.conf
   NCALRPCDIR: /var/run/samba/ncalrpc
   LOGFILEBASE: /var/log/samba
   LMHOSTSFILE: /etc/samba/lmhosts
   DATADIR: /usr/share
   MODULESDIR: /usr/lib/x86_64-linux-gnu/samba
   LOCKDIR: /var/run/samba
   STATEDIR: /var/lib/samba
   CACHEDIR: /var/cache/samba
   PIDDIR: /var/run/samba
   PRIVATE_DIR: /var/lib/samba/private
   CODEPAGEDIR: /usr/share/samba/codepages
   SETUPDIR: /usr/share/samba/setup
   WINBINDD_SOCKET_DIR: /var/run/samba/winbindd
   NTP_SIGND_SOCKET_DIR: /var/lib/samba/ntp_signd

$ testparm -v
…
        private dir = /var/lib/samba/private
…
[sysvol]
        path = /var/lib/samba/sysvol
…

ビルド情報をディレクトリ基準で整理すると…

項目設定値
BINDIR/usr/bin
SBINDIR/usr/sbin
MODULESDIR/usr/lib/x86_64-linux-gnu/samba
CONFIGFILE/etc/samba/smb.conf
LMHOSTSFILE/etc/samba/lmhosts
NCALRPCDIR/var/run/samba/ncalrpc
LOGFILEBASE/var/log/samba
DATADIR/usr/share
CODEPAGEDIR/usr/share/samba/codepages
SETUPDIR/usr/share/samba/setup
LOCKDIR/var/run/samba
PIDDIR/var/run/samba
WINBINDD_SOCKET_DIR/var/run/samba/winbindd
STATEDIR/var/lib/samba
PRIVATE_DIR/var/lib/samba/private
NTP_SIGND_SOCKET_DIR/var/lib/samba/ntp_signd
CACHEDIR/var/cache/samba

大雑把に分類するなら、パッケージに含まれるもの(黒)、起動するたびに作られる動作用のもの(黒)、キャッシュ(黒)、設定ファイル(赤)、恒久的に保管されるデータ(赤)となり、赤文字部分がバックアップ対象と想定される。

加えて、後述のバックアップスクリプトの考え方を見れば、
/var/lib/samba/sysvol
がバックアップ対象になる。

さて、/var/lib/samba には、結構な数のファイルやディレクトリが入っている。
いる・いらないの判断は、色々なところに書かれている情報から整理。

ディレクトリファイル名用途保存
./account_policy.tdbパスワードの有効期限設定を含むSamba/NTアカウントポリシー設定。 
./group_mapping.tdbWindowsグループ/SIDからUNIXグループへの対応表。 
./registry.tdbwinreg RPCを介してさまざまなデータベーステーブルをエクスポートするためのサポートを提供する、読み取り専用なWindowsレジストリスケルトン。 
./share_info.tdb共有ごとのACL情報。？
./winbindd_cache.tdbNT4ドメインまたはADSから受信したID情報のキャッシュ。ユーザーリスト、他。 
./wins.ldbWINSに登録された情報。 
ntp_signd/-NTPソケット置き場。 
printers/-プリンタドライバ置き場。△
private/-IDマップやパスワードなど様々なデータ置き場。○
sysvol/-ドメインコントローラー間で共有されるファイル置き場。○
usershares/-ユーザー定義の共有フォルダ。△
winbindd_privileged/-winbinddとの通信用パイプ置き場。 

account_policy.tdb は、samba-tool を使ってパスワードの有効期限を変えてみたが更新されなかった。となると、group_mapping.tdb 相当の情報もここでは持っていなさそうなので対象外(どちらも、インストールした日から一度も更新されていない)。

registry.tdb は読み取り専用、インストール時に作られる(どこで？)っぽいから対象外とした。

share_info.tdb は private/share.ldb に情報を持っているのではないかと考えて除外。ただし、Sambaが起動するたびにタイムスタンプが変わっていて、それでいてprivate/share.ldbが変わっていなかったので気になる部分。
バックアップスクリプトはこのファイルを対象にしていないので、不安があるなら手動でバックアップする。

winbindd_cache.tdbは本来cacheにあるべきと思われるが、何か設定をミスってしまっているのかも…起動時に壊れていれば作り直されるらしいので対象外。

wins.ldbがココにあるのは正解のようだが、起動時に作り直されるらしいので対象外。

ntp_signd/ は内容からして /var/run/samba にあった方が良さそうなものと考えて除外。

printers/ はプリンタドライバ置き場、usershares/ はユーザー間のファイル共有ディレクトリなので、バックアップをとるのであれば「システム」のバックアップとしてではなく「ユーザーファイル」のバックアップとして考えるべきだと考えて除外。

winbindd_priviledged/ は /var/run/samba とかにあっても良さそうなディレクトリだなって思う。アクセス権を変えることで、他のシステムから認証機能が使えるようになるから、そのためにココにしたのかな？と考えて除外。

以上を踏まえてバックアップ対象を決定。

  • /etc/samba/*
  • /var/lib/samba/private/*
  • /var/lib/samba/sysvol/*

バックアップの方法

Samba Wiki をたどっていくとバックアップについて書かれている。
Version4.9から方法が変わっており、4.7.6は少し古い感じ。
Samba wiki / Using the samba backup script

ここで説明されているバックアップスクリプトは Ubuntu のパッケージに入っていないので、以下の順でたどっていってSamba.orgからソースを落としてくる。
Samba wiki / Samba Release Planning
Samba wiki / Release Planning for Samba 4.7
Samba 4.7.6 Available for Download
※ここに gzipped なソースがある。

展開すると、スクリプトがある。
samba-4.7.6/source4/scripting/bin/samba_backup

このスクリプトはSambaが単一のディレクトリにインストールされていることが前提になっているためそのままは使えない。よって、考え方を読み込んでみたところ…

  • privateディレクトリにあるldbファイルをtdbbackupというコマンドで安全にバックアップし、その他のファイルと共にtarballにまとめる。
  • etc と sysvol はまるごとtarballにまとめる。
    ※これでsysvolがバックアップ対象なのだと気がついた。

を行っている。この手順を踏めばホットバックアップが可能。

なお、

スクリプトは非常に基本的なものであり、そのまま使用する予定の場合は、注意が必要なことが1つあります。
・スクリプトは拡張ACLをバックアップしません。そのため、SysVol共有などのアクセス許可を失うことになります。--xattrsオプションをサポートするtarバージョンがある場合（tarのマンページを参照）、スクリプト内のすべての 'tar'コマンドにこのオプションを追加する必要があります。これにより、tarはアーカイブ内に拡張ACLを保持できます。(Google先生の翻訳)

という記述があり、tarballを作るにあたって拡張属性(root名前空間のNTACLという属性)を含めておくことが勧められているわけだが、実際に -xattrs オプションを作ってみたけど拡張属性は復旧できない。--acls とかも試したけどだめ。理由は後述。

2022/08/24 追記
サーバーOSのバージョンアップを真剣に検討してみていて、新バージョンで提供されているバックアップ機能を使用してみた。
すると、sysvolにあるディレクトリ・ファイルに対して1つずつ ～.NTACL というファイルが作られていた。
ここから探っていくと、Ubuntu 18.04のバージョンでも samba-tool ntacl get ～ コマンドで拡張属性を確認・設定できることが分かった。

拡張情報を取り出すのに、以下のコマンドを使うことができた。

# samba-tool ntacl get /var/lib/samba/sysvol/
    security_descriptor: struct security_descriptor
        revision                 : SECURITY_DESCRIPTOR_REVISION_1 (1)
        type                     : 0x9014 (36884)
               0: SEC_DESC_OWNER_DEFAULTED
…

これをSDDLフォーマットで取り出すとこうなる。

# samba-tool ntacl get /var/lib/samba/sysvol/ --as-sddl
O:LAG:BAD:P(A;OICI;0x001f01ff;;;BA)(A;OICI;0x001200a9;;;SO)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)

取り出しておいた属性は samba-tool ntacl set ～ /path/to/fileOrDirectory で設定できることが分かった。

復元のために、一番お手軽な方法を考えたとき、設定用のコマンドを吐き出して、復元先でそれを実行すれば拡張属性を設定できるのが良いのでは？と考えて、実装している。

やったこと

調べる

TDBファイルがバックアップ対象なのかどうなのかが分からず、あっちこっちと見て回った。

日本Sambaユーザー会 / smb.conf — Samba の設定ファイル
ここで、バージョン3.4.0から lock directory を cache directory(一時的なデータを含むTDB) とか state directory(持続的なデータを含むTDB) に分けられるようになったという記載がある。lock directory の意味がよく分からないが、ほとんどのTDBはここに置かれると書かれおり、かつ、ビルド情報では /var/run/samba が割り当てられている。以下の情報を読み込んだ後でこの記述を見つけて、大体の考え方が分かったような気がした。

Samba wiki / TDB Locations
Samba3系。最初はこの表を見てもうまく理解ができなかったのだが、Locationがビルド情報のディレクトリとつながっていることに気付いた。cache(=CACHEDIR)、lock(=LOCKDIR)、private(=PRIVATE_DIR)、state(=STATEDIR)とtortureがある。
また、TDB_CLEAR_IF_FIRSTと書かれているファイルは、Sambaが起動するたびに作り直されることが分かる。

Samba wiki / LDB
LDBがLDAP準拠で作られていること、TDBの上位階層になっていることが分かる。

日本Sambaユーザー会 / Chapter 38. TDB ファイルの管理
Version3系。この表は2008年に書かれており、今のバージョンと違ってるんだろうなぁと思っていたが、上記TDB Locationsと突き合わせて、バックアップすべきはprivateとかstateにあるファイルなんじゃないかと予測ができた。
※AD DC機能はVersion4系から。

Samba / Chapter 1. How to Install and Test SAMBA
IBM Developer / 簡易データベース (TDB) ファイル
Version3系。恒久ファイルと一時ファイルの表があり、バックアップすべきファイルを予測した。

拡張属性を見てみる

拡張属性は以下で見ることができた。

$ sudo getfacl -R /var/lib/samba/sysvol

これをバックアップして復元できればいいかも…と考えたが、SYSTEM ACCOUNTはUbuntuからは利用できないため、setfaclコマンドが失敗する。具体的には…

$ sudo setfacl --restore=sysvol/acl.txt
setfacl: sysvol/acl.txt: Invalid argument in line 10

このファイルの中身はというと…

# file: sysvol
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:3000000:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:BUILTIN\134server\040operators:r-x
group:NT\040AUTHORITY\134system:rwx ← 10行目
group:NT\040AUTHORITY\134authenticated\040users:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000000:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:BUILTIN\134server\040operators:r-x
default:group:NT\040AUTHORITY\134system:rwx
default:group:NT\040AUTHORITY\134authenticated\040users:r-x
default:mask::rwx
default:other::---

これは Samba ad dc 特有の問題、NT AUTHORITY ～というグループを Ubuntu の側から扱えないから。そんなグループとかがなければ問題なく復元できるはず。
Server World / ACL によるアクセス制御

さいごに

日頃は「超簡単～♪」くらいの勢いで使わせてもらっている Samba だけど、いざバックアップ！と思ったら情報なさ過ぎ…。マニュアルを読んでいないのが悪い！という指摘もあるかもしれないが、tar で –xattrs とか指定したって属性保管できないぜ？何を読めばいいんだよ？

でもね、この記事を書いていて思っていたのは、色々試すのよ、でも全部の記録なんか残せなくってさ、それを思えば書き漏らすことなんて「あるある」な話なんだと思うんだよね。その点で、Samba の姿勢は本当に素晴らしい！と思う。色々ある指摘の中でも特に難しそうなところを、samba-toolでバックアップができるようにラッピングしようとしてくれるんだもん。

一方で、とある他のシステムはそうじゃない。Q&Aを見れば、やれ「ログに出るはずだ」「マニュアルに書いてある」「あなたの使っている○○は本当に正しいの？」って感じ。でも、書いてあるとおりにやったってうまくいかない。多分、知識がないのが原因じゃないよ、動かすために必要なことが書けてないんだよ。反省の前に自己保身のスタイルって超クール！

ところで、エンジニアとして身近に結構ある話として、とにかく「書け！」ってのがある。これってどういうこと？○○です。なら書けよ、って流れ。んで、書くのよ、とにかく書く。結果、無駄な情報が大量に生み出されて大事な情報が見つからない。結局読むのは「書け！」って言った「読む義務のある人」だけで、他の人は読まないからタダの無駄。無駄なだけならいいけど、無駄な情報が多すぎて必要な情報を見落とすことになるからマイナス、超マイナス！

資料を読む人って書いた人の思考をなぞりたいわけじゃないので「スカッと必要なことを言って欲しい、疑問になったことはその後教えて」なんだよね。あるいは「あなたが考えてくれたなら、考えて整理した結果が知りたい」なわけ。なのに、書いて！って頼むとしばしば「僕はこの順序でこう考えて結果はこうなりました！」とか「判断材料はこれ、察して！とにかく察して！」ってのができあがってくる。これでオレにどうして欲しいのさ？って思ったり。

あぁ、最近考え始めたことを書いちゃった。オレの過去記事…いや、これは自分用のメモなんですよ、はは、はは、ははは…。

広告
rohhie

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他