where should smb.conf % macros be supported?

[Andrew Bartlett]

On Tue, 2011-05-24 at 17:32 +0200, Volker Lendecke wrote:
> Hi, Andrew!
> 
> I've been there, many times. I know lp_string is one of the
> dirtiest pieces that Samba has, and probably the most
> difficult one to extinguish.
> 
> The approach I had tried once was to make all the expansion
> variables explicit. Maybe we should pick the ones that have
> only very few callers, convert those to CONST_STRING and do
> the required expansion explicitly in the callers. This is
> really a case-by-case conversion unfortunately, at least
> that's my 2ct on the issue.

Thank you very much for the review.  The background is very helpful in
trying to pin down a set of semantics here. 

> On Tue, May 24, 2011 at 12:02:12PM +1000, Andrew Bartlett wrote:
> > To start bridging the gap, I would like to convert the following
> > parameters to FN_GLOBAL_CONST_STRING, which are truly constant (at least
> > until an smb.conf reload):
> > 
> > FN_GLOBAL_STRING(lp_dos_charset, &Globals.dos_charset)
> > FN_GLOBAL_STRING(lp_unix_charset, &Globals.unix_charset)
> > FN_GLOBAL_STRING(lp_display_charset, &Globals.display_charset)
> 
> > FN_GLOBAL_STRING(lp_logfile, &Globals.szLogFile)
> > FN_GLOBAL_STRING(lp_configfile, &Globals.szConfigFile)
> 
> Both log file and config file definitely need the
> expansions.

Indeed (they, and 'include =' are the items that perhaps will always
need the full range of expansions).

> > FN_GLOBAL_STRING(lp_smb_passwd_file, &Globals.szSMBPasswdFile)
> > FN_GLOBAL_STRING(lp_private_dir, &Globals.szPrivateDir)
> > FN_GLOBAL_STRING(lp_lockdir, &Globals.szLockDir)
> > FN_GLOBAL_STRING(lp_piddir, &Globals.szPidDir)
> > FN_GLOBAL_STRING(lp_utmpdir, &Globals.szUtmpDir)
> > FN_GLOBAL_STRING(lp_wtmpdir, &Globals.szWtmpDir)
> > FN_GLOBAL_STRING(lp_realm, &Globals.szRealm)
> > FN_GLOBAL_STRING(lp_name_resolve_order, &Globals.szNameResolveOrder)
> > FN_GLOBAL_STRING(lp_panic_action, &Globals.szPanicAction)
> > FN_GLOBAL_STRING(lp_dedicated_keytab_file,
> > &Globals.szDedicatedKeytabFile)
> > FN_GLOBAL_STRING(lp_ncalrpc_dir, &Globals.ncalrpc_dir)
> > FN_GLOBAL_STRING(lp_passwordserver, &Globals.szPasswordServer)
> 
> The other ones I could see as CONST_STRING.

Thanks, it is this list (with the addition of passdb backend, smb ports)
that I need most urgently to be in common and would like to become
CONST_STRING, without any subs.

My remaining question is about ensuring I do this right by our users:
For this set, do we need to warn our users with a deprecation message in
3.6.0?  

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org