r9744: - [upgrade.js] Start working on smb.conf conversion.
[ira/wip.git] / source4 / 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
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
42
43 TODO:
44  - move ini parsing stuff to seperate file param/ini.c