Looking more closely at one of the other approaches I could’ve taken for migrating from Samba3. We will probably end up supporting this method later on anyway, once we expand the vampire code. I do think the path I’ve taken for SoC is the right one though - it allows the upgrade with the least hassle and user input.
This approach could be splitted up into the various parts:
- samba3 pidl backend
- Samba4 vampire + server side samsync support in Samba3
- unixinfo (unixinfo) (exposes idmap) - in Samba4 (client side) - in Samba3 (server side)
- winsrepl (thru seperate pipe?)
- enum/add shares (srvsvc)
- enum/add registry (winreg)
- enum/add printers (spoolss(?))
- convert smb.conf (using Jerry’s registry hack)
Advantages of this approach:
- Can be used to ‘clone’ Samba4 boxes as well
- Relatively few extra loc necessary (a lot shared with vampire)
- ‘Clean’ code - simply enumerates and adds
Disadvantages:
- Needs running Samba3 daemon for upgrade (!)
- Needs (complex?) Samba3 code changes
- Needs latest version of Samba3