UMC created samba shares - testparm shows includes off-by-1

UCS - Univention Corporate Server
#1

Hi all, I have a possible issue with the way UMC creates samba shares and I’d like to check that I’m not crazy or that there’s no bug in either UMC or samba testparm output.

On our 4.1-2 e176 system consisting of 1 DC-Master, 1DC-Backup and a member samba server, what I’ve done is:
[ol]
[li]created a list of shares under UMC > domain > shares assigned to the member server[/li]
[li]UMC looks like it creates the folders for the shares on the member server, and generates specific configuration files for samba under /etc/samba/shares.conf.d/[/li]
[li]UMC looks like it creates includes for the /etc/samba/shares.conf.d/ files in /etc/samba/shares.conf[/li][/ol]

If I run samba testparm on the UCS samba server, I receive the usual output, however each share definition appears to have an “include” statement assigned to it for the following share. So for example [Share A] has an “include” directive referencing “/etc/samba/shares.conf.d/shareb” for the [Share b] definition following it.

Here’s a screenshot of the resulting output:

I stress that I have not used any local overrides or done anything to mess with samba outside of creating the definitions in LDAP with standard UMC features. The testparm output is representative of the default configuration generated by UMC on this system.

What I’d like to know is:
[ul][li] Anyone else getting similar results? [/li]
[li]Is this just a cosmetic bug with testparm not doing the merging of the various UMC created config files properly - and so there is no real effect on the actual configuration?
For example: the files under /etc/samba/shares.conf.d/ all include the relevant [sharename] in their configuration, so you would assume they would get correctly merged in the final active samba config?[/li]
[li]Or, is there a bug in the way that UMC is generating the samba config files from it’s UCR templates so that the includes are put in the wrong share definitions?[/li][/ul]

My main concern is that some share specific configuration for [share B] ends up affecting [share A] as the include will pull the /etc/samba/shares.conf.d/shareb file into the wrong place (see screenshot).

Just want to find out if this is nothing to worry about (because testparm is wrong) or it could have weird side-effects (because UMC shows correct settings while the final merged samba config is including config into the wrong shares).

Hope that’s clear, thanks for any help.
Mark.

#2

Hi,

I can at least confim the behaviour.
It might be similar to [bug]36581[/bug] which says:

[quote]The samba configuration parser has been reworked and now it seems to dislike the way we include files:[/quote].
At this time I can not see any misbehaviour but I didnt look deeper.

You might create a bug-report by yourself in case you have more reason to believe that this is more than cosmetic.

Best Regards,
Dirk Ahrnke

#3

Hi Dirk, I’m starting to think its just a cosmetic issue with the way testparm displays the includes.

Univention support was also able to replicate the output, but nothing seems to be amiss with the configuration. In any case the included files from /etc/samba/shares.conf.d/ all have correct [sharename] definitions within them for each share configured in UMC. So at the file level nothing is amiss.

So perhaps this is just a testparm visual quirk that that the include line for the next file to be added appears visually within the previous share service declaration in the service definition output.

Will keep testing with some config variations to make sure there’s no chance share config is in the wrong place.

Thanks for confirming similar results!

Mark.

#4

Looks like it’s intentional behaviour from testparm.

lists.samba.org/archive/samba/2 … 41526.html

Sample output at the bottom of the email shows exactly the same behaviour. It makes sense that you see an include directive and then the included content.

What threw me was that include directive being in the middle of the previous share definition rather than appended to the end of the share definition right before the content that gets included.

Mastodon