Rant on controlled migration [was: Changing security parameters]
davecb at canada.sun.com
Mon Nov 12 06:00:11 GMT 2001
To oversimplify, if you can make an old Samba parameter
take up a distinguished "does not apply" value when
queried or used, and if you can add new parameters, you can
update the consumers of the parameter, the clients,
independently of the producer of the parameter, the
This corresponds to databases having null values and
allowing addition of new columns to relations, respectively.
This in turn is the necessary-and-sufficient part (but not
the laborious part) of allowing asynchronous development
The laborious part is writing the old-to-new and new-to-old
interface helper-functions, introducing them at the
right time, making them produce the right error
messages and retiring them at the right time.
Concrete proposal re the labourious part:
Introduce the new parameters in 2.x, map it
to the security=x implementation, warn loudly
if it's used wrong, mention quietly if it's
Mention quietly if other parameters are
inconsistant with the values set (eg, auth
server set with auth order = unix)
Put the new code into service in a late 2.x
**development** release, providing
Phase compatability out starting with 3.0:
in 3.0.0, warn loudly if compatability used,
in 3.1.0 diagnose and halt.
David Collier-Brown, | Always do right. This will gratify
Americas Customer Engineering, | some people and astonish the rest.
SunPS Integration Services. | -- Mark Twain
(905) 415-2849 | davecb at canada.sun.com
More information about the samba-technical