states that it is good practice to keep smb.conf as small as possible and recommends keeping documentation in smb.conf.master, then running
testparm -s smb.conf.master > smb.conf
In this regard it is counterproductive to print include statements like
include = /etc/smb.conf.global
because this will lead to re-inclusion (and double evaluation) of smb.conf.global
There is no gain in mentioning included files other than documentation purposes. Consequently I propose to prefix include statements with '#'.
I agree that testparm should present a flattened view of the config, not putting include statements generally.
This applies to version 3.2, 3.3 and following, too...
I have applied a fix to master and v3-4-test.
It not only excludes "include" but also the other
meta directives "config file" and "config backend"
from being printed.
Hmm, is this important enough to go into 3.3?
Created attachment 4166 [details]
fix for v3-3-test
This is the patch with the bugfix for v3-3-test.
Could we take it for 3.3?
I'm not sure I necessarily agree with the "flattened" view thing. There is no such thing as a flattened view, as includes depend on the runtime-macros that testparm can never catch. I would much rather like a testparm that does not execute the includes at all but just print them as is, without having done the includes.
(In reply to comment #4)
> I'm not sure I necessarily agree with the "flattened" view thing. There is no
> such thing as a flattened view, as includes depend on the runtime-macros that
> testparm can never catch.
This is right, but testparm currently _does_ provide flattened view of the config, at least the config that it can see with the current values of macros: as it is, testparm runs lp_load(), which loads the current configuration expamding all includes, thus flattening the include tree, and afterwards dumps out the config from the globals struct and services array.
Therefore imho, as long as this is the modus operandi, includes and other meta directives ("config file" and "config backend") should not be printed.
At least as long as it is a recommended procedure to run
"testparm -s smb.conf> smb.conf.checked"
to get a working smb.conf file, testparm is currently wrong,
and my fix attacks exactly this.
> I would much rather like a testparm that does not
> execute the includes at all but just print them as is, without having done the
This of course also a valid way of dealing with things.
But it would mean a change in paradigm, so I would rather
have it as a second mode of testparm that can be triggered
with a command line switch, or even as a separate binary.
Well, testparm together with includes just does not work. So we need to fix the documentation or provide a hint that "testparm -s smb.conf.master > smb.conf" should *not* be used if meta statements are around.
(In reply to comment #6)
> Well, testparm together with includes just does not work.
It does now in master and v3-4-test. :-)
> So we need to fix the documentation or provide a hint that
> "testparm -s smb.conf.master > smb.conf" should *not* be
> used if meta statements are around.
It is not just that:
It is really that printing includes from testparm is deceiving
since it will for one section (share ir global) only ever print
the last include file encountered in that section.
So it is not just a matter of fixing documentation but broken-ness
of testparm printing include statements.
Sorry for insisting, but I think with this change it is really
better than without, even though a completely rewritten testparm
might be better.
Closing this bug report: It is fixed in 3.4 and won't be fixed in 3.3 any more.
*** Bug 6152 has been marked as a duplicate of this bug. ***