source/lib/samba3/PLAN

   1 Three possible viable approaches:
   2  1) TDB conversion approach. Read in TDB dump out LDIF (one-way)
   3   - samr.ldb: from tdbsam/smbpasswd, account_policy.tdb, secrets.tdb, group_mapping.tdb
   4   - registry.ldb: from registry.tdb
   5   - wins.ldif: from wins.tdb/wins.dat
   6   - smb.conf/ea's: generated from the old smb.conf + share_info.tdb
   7   - winbind.ldif: from winbindd_idmap.tdb (custom file format, not used
   8                                                                                    by samba4 yet as it doesn't
   9                                                                                    have Winbind yet)
  10
  11   (one-way upgrades can be done by using ldbsearch -a on these dynamically
  12   generated ldb's)
  13   Since TDB's are local, there isn't much point in writing back backwards
  14   compatible data.
  15
  16  2) samr "mapping" backend (alternative for samr.ldb) (two-way)
  17     This would allow users to keep mixed domains containing Samba3 and Samba4.
  18
  19  3) The vampire way of doing things (one-way)
  20   - samba3 pidl backend
  21   - Samba4 vampire + server side samsync support in Samba3
  22   - unixinfo (\unixinfo)
  23    - in Samba4 (client side)
  24    - in Samba3 (server side)
  25   - winsrepl (thru seperate pipe?)
  26   - enum/add shares (\srvsvc)
  27   - enum/add registry (\winreg)
  28   - enum/add printers (\winreg, perhaps also \spoolss(?))
  29   - convert smb.conf (using Jerry's registry hack)
  30
  31 (going with a combination of 1 and 2)
  32
  33 ldb mapping backend:
  34  - do search in new and old (mapped) backend and merge results
  35
  36 Upgrade process:
  37  - take libdir & smb.conf
  38  - read various tdb files / old smb.conf
  39  - write new smb.conf (ejs)
  40   - list of parameters to keep.. generate some of the others
  41  - add generated LDIF (ejs). Call out to current provisioning