Bug 15359 - Improved template capability for configuration
Summary: Improved template capability for configuration
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.13.13
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-04-15 20:03 UTC by incansvl
Modified: 2023-04-15 20:03 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description incansvl 2023-04-15 20:03:35 UTC
The config directive "copy" pulls a pre-existing service definition into the current definition as a kind of template. However it is limited by two issues-

1) The "template" section must itself be a valid service definition (i.e. it must contain a valid path directive)

2) The parser only seems to recognise explicit "path =" declarations in the current service definition. It does not recognise when a template brought in by the "copy =" directive includes a dynamically defined path such as "path = /home/%S" which would still be usable (and unique) in the context of a new section.

Example 1
=========
It would be useful to be able to define defaults in "template" section e.g.-

[home_defaults]
	valid users = @groupname
	write list = %S @sudo
	force group = +groupname
	force create mode = 640
	force directory mode = 2770

[user1]
	copy = home_defaults
	path = /home/user1
	...

However this currently fails as [home_defaults] is not a valid service definition without a valid path entry.

Example 2
=========
Another example would be-

[home_defaults]
	path = /home/%S
	valid users = @groupname
	write list = %S @sudo
	force group = +groupname
	force create mode = 640
	force directory mode = 2770

[user1]
	copy = user_defaults

This one fails because the parser does not realise that the copied-in template includes a path directive that expands to a usable unique path in the [user1] section. Instead it rejects this with a "no path defined" error.


Other Comments
==============
This idea of "template sections" is analogous to the function of the "include =" directive. However the way I read the description of how "include" is processed now using registry data it seems that "include" is processed LAST in the config setup, so included directives will override those in explicit config sections.

An elegant solution therefore might be to -

1) Define a new "template =" directive that works just like include but specifically defines entries that are processed FIRST in the config, and are primarily intended to be referenced via "copy=", or overridden by per-share definitions.

2) Allow "template" sections to be defined that are not required to be valid service definitions on their own. This would require new syntax, e.g. {templatename} to define a template  vs. [servicename] to define a service.

3) Improve the parser so it understands that a path directive can be "imported" via a copy , and not just explicitly coded in the current service definition.