-Three possible viable approaches:
- 1) TDB conversion approach. Read in TDB dump out LDIF (one-way)
- - samr.ldb: from tdbsam/smbpasswd, account_policy.tdb, secrets.tdb, group_mapping.tdb
- - registry.ldb: from registry.tdb
- - wins.ldif: from wins.tdb/wins.dat
- - smb.conf/ea's: generated from the old smb.conf + share_info.tdb
- - winbind.ldif: from winbindd_idmap.tdb (custom file format, not used
- by samba4 yet as it doesn't
- have Winbind yet)
-
- (one-way upgrades can be done by using ldbsearch -a on these dynamically
- generated ldb's)
- Since TDB's are local, there isn't much point in writing back backwards
- compatible data.
-
- 2) samr "mapping" backend (alternative for samr.ldb) (two-way)
- This would allow users to keep mixed domains containing Samba3 and Samba4.
-
- 3) The vampire way of doing things (one-way)
- - samba3 pidl backend
- - Samba4 vampire + server side samsync support in Samba3
- - unixinfo (\unixinfo)
- - in Samba4 (client side)
- - in Samba3 (server side)
- - winsrepl (thru seperate pipe?)
- - enum/add shares (\srvsvc)
- - enum/add registry (\winreg)
- - enum/add printers (\winreg, perhaps also \spoolss(?))
- - convert smb.conf (using Jerry's registry hack)
-
-(going with a combination of 1 and 2)
-
-ldb mapping backend:
-
-
-Upgrade process:
- - take libdir & smb.conf
- - read various tdb files / old smb.conf
- - write new smb.conf (ejs)
- - list of parameters to keep.. generate some of the others
- - add generated LDIF (ejs). Call out to current provisioning
-
-TODO:
+TODO (SoC project):
- move ini parsing stuff to seperate file param/ini.c
+ - parse "passdb backend" setting and parse tdbsam/passdb based on it
+ - test ldb_map backend (testsuite?)
+ - testsuite for the static upgrade
git.samba.org / sfrench / samba-autobuild / .git / blobdiff