Proposal - change some default parameter settings for 4.9.0.

[Jeremy Allison via samba-technical]

Hi all,

I'd like to propose changing the following
defaults for Samba 4.9.0 and above.

New proposed defaults:
----------------------

map readonly = no
store dos attributes = yes
ea support = yes

(the current defaults are the inverse of
these).

I'm asking as our most common deployed
systems (Linux with ext4/XFS/brtfs)
and FreeBSD (with ZFS or ffs) both
support extended attibutes out of
the box on standard installs.

This should make installing a default
Samba fileserver work much closer to
an out-of-the-box Windows fileserver
experience (these are the setting I
always have to change as soon as I
set up any server).

Thoughts and comments ?

If we can get agreement I'll create
and propose patches for master.

Cheers,

Jeremy.

[Andrew Bartlett via samba-technical]

On Mon, 2018-05-14 at 09:36 -0700, Jeremy Allison via samba-technical

Post by Jeremy Allison via samba-technical
Hi all,
I'd like to propose changing the following
defaults for Samba 4.9.0 and above.
----------------------
map readonly = no
store dos attributes = yes
ea support = yes
(the current defaults are the inverse of
these).
I'm asking as our most common deployed
systems (Linux with ext4/XFS/brtfs)
and FreeBSD (with ZFS or ffs) both
support extended attibutes out of
the box on standard installs.
This should make installing a default
Samba fileserver work much closer to
an out-of-the-box Windows fileserver
experience (these are the setting I
always have to change as soon as I
set up any server).
Thoughts and comments ?
If we can get agreement I'll create
and propose patches for master.

I strongly agree that our out of the box solution should be as simple
as (or better still, simpler than) running windows. This has been the
policy (if not always the implementation) for the AD DC for a long time
and I think the same should apply to the fileserver too.

What about ACLs? Should we store the full NT ACL by default like the
AD DC does? Can we somehow make acl_xattr the default vfs module
without breaking everything?

(I'm not gloating, the advantage of being the new feature is much less
history and less existing installations to impact).

Thanks,

Andrew Bartlett

[Jeremy Allison via samba-technical]

Post by Andrew Bartlett via samba-technical
I strongly agree that our out of the box solution should be as simple
as (or better still, simpler than) running windows. This has been the
policy (if not always the implementation) for the AD DC for a long time
and I think the same should apply to the fileserver too.
What about ACLs? Should we store the full NT ACL by default like the
AD DC does? Can we somehow make acl_xattr the default vfs module
without breaking everything?

Maybe :-). But that is a separate patch I think which means
*much* more re-working of our test infrastructure.

Right now I think I'll start small and just fix this
immediate pain point. I really want to do this as it
help to adding the SMB2 unix extensions, which will need
EA support to store symlinks (correctly).

Cheers,

Jeremy.

[Andrew Bartlett via samba-technical]

Post by Jeremy Allison via samba-technical

Post by Andrew Bartlett via samba-technical
I strongly agree that our out of the box solution should be as simple
as (or better still, simpler than) running windows. This has been the
policy (if not always the implementation) for the AD DC for a long time
and I think the same should apply to the fileserver too.
What about ACLs? Should we store the full NT ACL by default like the
AD DC does? Can we somehow make acl_xattr the default vfs module
without breaking everything?

Maybe :-). But that is a separate patch I think which means
*much* more re-working of our test infrastructure.

Yeah. Don't hold up some progress for perfect progress.

Post by Jeremy Allison via samba-technical
Right now I think I'll start small and just fix this
immediate pain point. I really want to do this as it
help to adding the SMB2 unix extensions, which will need
EA support to store symlinks (correctly).

Very interesting!

Thanks,

Andrew Bartlett

[Ralph Böhme via samba-technical]

Post by Jeremy Allison via samba-technical

Post by Andrew Bartlett via samba-technical
I strongly agree that our out of the box solution should be as simple
as (or better still, simpler than) running windows. This has been the
policy (if not always the implementation) for the AD DC for a long time
and I think the same should apply to the fileserver too.
What about ACLs? Should we store the full NT ACL by default like the
AD DC does? Can we somehow make acl_xattr the default vfs module
without breaking everything?

Maybe :-). But that is a separate patch I think which means
*much* more re-working of our test infrastructure.
Right now I think I'll start small and just fix this
immediate pain point. I really want to do this as it
help to adding the SMB2 unix extensions, which will need
EA support to store symlinks (correctly).

fwiw, the "ea support" option should only take affect the SMB protocol level
these das, not the use of xattr at a lower level. Cf
4bfd27b077f0932c82cfe702bd4ba6628f75a526.

-slow

[Timur I. Bakeyev via samba-technical]

On 14 May 2018 at 21:20, Jeremy Allison via samba-technical <

Post by Andrew Bartlett via samba-technical
I strongly agree that our out of the box solution should be as simple
as (or better still, simpler than) running windows. This has been the
policy (if not always the implementation) for the AD DC for a long time
and I think the same should apply to the fileserver too.
What about ACLs? Should we store the full NT ACL by default like the
AD DC does? Can we somehow make acl_xattr the default vfs module
without breaking everything?

Can we be a bit cautious with the defaults here? With FreeBSD we already
have a hard time disabling acl_xattr
during the provisioning to the ZFS-only systems, as NTACLs are expressed
via NFSv4 ACLs instead.

Even worse situation is with the provisioning to the UFS, due theSamba 4.6
"fix" to extattr code, which now rejects
security.* xattrs entirely, breaking provisioning.

In general, I'd love to see NFSv4 ACLs as a first class citizen in Samba,
as defaulting unconditionally vfs_posixacl
complicates ZFS deployments as well.

With regards,
Timur Bakeyev.

[Andrew Bartlett via samba-technical]

In general, I'd love to see NFSv4 ACLs as a first class citizen in Samba, as defaulting unconditionally vfs_posixacl
complicates ZFS deployments as well.

For the AD DC case, I've been waiting for someone to write and test a
patch for this for a number of years. I don't have the need, but
clearly it is how it 'should' work.

Famous last words, but it should not be that difficult.

Thanks,

Andrew Bartlett

[Timur I. Bakeyev via samba-technical]

Post by Timur I. Bakeyev via samba-technical
In general, I'd love to see NFSv4 ACLs as a first class citizen in

Samba, as defaulting unconditionally vfs_posixacl

Post by Timur I. Bakeyev via samba-technical
complicates ZFS deployments as well.

For the AD DC case, I've been waiting for someone to write and test a
patch for this for a number of years. I don't have the need, but
clearly it is how it 'should' work.

We have some hacks around to make thing work as desired, but for the proper
patch it would be nice to have
the idea how it should fit into the rest of the code.

ATM vfs_posixacl is hard-coded for all ACL operations and vfs_acl_xattr is
hard-coded for sysvol and netlogon shares.

We had the idea to check the FS type and based on that load appropriate vfs
objects, but as such an approach isn't
used yet, there must be reasons for that. Another option, at least for
provisioning was to test if NFSv4 ACLs are applicable
to the SYSVOL, as it's done now for POSIX ACLs, but that requires tighted
NFSv4 integration into the Samba code.

Right now we use the following patch for ZFS provisioning:

https://github.com/b-a-t/samba/commit/d4cf0ebf2a28205af234c31f1e86e39b236124f8

With regards,
Timur Bakeyev.

[Andrew Bartlett via samba-technical]

We have some hacks around to make thing work as desired, but for the proper patch it would be nice to have
the idea how it should fit into the rest of the code.
ATM vfs_posixacl is hard-coded for all ACL operations and vfs_acl_xattr is hard-coded for sysvol and netlogon shares.
We had the idea to check the FS type and based on that load appropriate vfs objects, but as such an approach isn't
used yet, there must be reasons for that. 

I wouldn't assume that. You certainly could check at provision time and write in an option or flag that changes the vfs objects.

Loadparm shouldn't be auto-detecting at runtime, but a vfs module could.

Andrew Bartlett