Discussion:
Releasing Samba 4.0 RC1?
(too old to reply)
Andrew Bartlett
2012-08-12 11:59:01 UTC
Permalink
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).


Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!

Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.

The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.

There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).

That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.

My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?

We also still need help with manpages, documentation of new smb.conf
options.

Finally, this brings us to timing, and the challenges and opportunities
presented by the upcoming SDC event and plugfest at Microsoft.

We could release RC1 before SDC
http://snia.org/events/storage-developer2012/plugfest (starts 16 Sept)
and the Microsoft AD plugfest (ends 28 Sept). However, then if we find
issues (and that is the express purpose of such events) we will need to
go via the full bug+patch process for all of them.

Or we could release RC1 after both events, but that starts to be early
October, and that seems like a long delay, and I for one will be pretty
exhausted after jet-lag and 2 weeks of travel, putting any RC1 into mid
October at the earliest. That in turn makes it harder to get a release
actually made in 2012.

The other disadvantage is that while conferences are a great goal to aim
at for releases, the quick-and-dirty development style (needed to
isolate issues quickly) may simply mean we either have patches in the
tree that are not totally ready (simply because they were prepared under
pressure) or we have a long delay as we wait for folks to work though
their backlog.

This timing also affects our downstream distributions, so I would
appreciate any views from that direction as well.

Thanks,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Gémes Géza
2012-08-12 12:30:00 UTC
Permalink
Hi,
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?
We also still need help with manpages, documentation of new smb.conf
options.
Finally, this brings us to timing, and the challenges and opportunities
presented by the upcoming SDC event and plugfest at Microsoft.
We could release RC1 before SDC
http://snia.org/events/storage-developer2012/plugfest (starts 16 Sept)
and the Microsoft AD plugfest (ends 28 Sept). However, then if we find
issues (and that is the express purpose of such events) we will need to
go via the full bug+patch process for all of them.
Or we could release RC1 after both events, but that starts to be early
October, and that seems like a long delay, and I for one will be pretty
exhausted after jet-lag and 2 weeks of travel, putting any RC1 into mid
October at the earliest. That in turn makes it harder to get a release
actually made in 2012.
The other disadvantage is that while conferences are a great goal to aim
at for releases, the quick-and-dirty development style (needed to
isolate issues quickly) may simply mean we either have patches in the
tree that are not totally ready (simply because they were prepared under
pressure) or we have a long delay as we wait for folks to work though
their backlog.
This timing also affects our downstream distributions, so I would
appreciate any views from that direction as well.
Thanks,
Andrew Bartlett
Will functionality enhancement patches for samba-tool and other
utilities be accepted after RC1? Or only bugfixes?
In the later case shall I start coding what I would want to push
(especially better handling of posix attrs, but also OU manipulation
subcommands) even in an obviously buggy version ;-) , and produce fixes
later.

Cheers

Geza
Gémes Géza
2012-08-13 06:26:19 UTC
Permalink
Hi,
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?
We also still need help with manpages, documentation of new smb.conf
options.
Finally, this brings us to timing, and the challenges and opportunities
presented by the upcoming SDC event and plugfest at Microsoft.
We could release RC1 before SDC
http://snia.org/events/storage-developer2012/plugfest (starts 16 Sept)
and the Microsoft AD plugfest (ends 28 Sept). However, then if we find
issues (and that is the express purpose of such events) we will need to
go via the full bug+patch process for all of them.
Or we could release RC1 after both events, but that starts to be early
October, and that seems like a long delay, and I for one will be pretty
exhausted after jet-lag and 2 weeks of travel, putting any RC1 into mid
October at the earliest. That in turn makes it harder to get a release
actually made in 2012.
The other disadvantage is that while conferences are a great goal to aim
at for releases, the quick-and-dirty development style (needed to
isolate issues quickly) may simply mean we either have patches in the
tree that are not totally ready (simply because they were prepared under
pressure) or we have a long delay as we wait for folks to work though
their backlog.
This timing also affects our downstream distributions, so I would
appreciate any views from that direction as well.
Thanks,
Andrew Bartlett
IMHO the biggest (most probable source for possible user grief) issue is
s3fs behavior in handling policies. To my experiments (I've just
switched our production network from 3 to 4 in the weekend) not only
does it prohibit setting policies initially but after manually given
full access to Domain Admins, I was able to set up some policies. The
problem which persist is inability to change the ACLs for policies. I
think will give ntvfs a try.

Cheers

Geza Gemes
Ricky Nance
2012-08-13 07:17:17 UTC
Permalink
Geza, make sure you have the right mount options in fstab and also the
right headers for ACL's I had a similar problem initially, but once I got
those fixed up, all went well. See the samba4 howto wiki for more info on
this.

Good luck,
Ricky
Post by Andrew Bartlett
Hi,
(TLDR: I want us to think about if we should release Samba 4.0 before or
Post by Andrew Bartlett
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/**show_bug.cgi?id=8622<https://bugzilla.samba.org/show_bug.cgi?id=8622>but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?
We also still need help with manpages, documentation of new smb.conf
options.
Finally, this brings us to timing, and the challenges and opportunities
presented by the upcoming SDC event and plugfest at Microsoft.
We could release RC1 before SDC
http://snia.org/events/**storage-developer2012/plugfest<http://snia.org/events/storage-developer2012/plugfest>(starts 16 Sept)
and the Microsoft AD plugfest (ends 28 Sept). However, then if we find
issues (and that is the express purpose of such events) we will need to
go via the full bug+patch process for all of them.
Or we could release RC1 after both events, but that starts to be early
October, and that seems like a long delay, and I for one will be pretty
exhausted after jet-lag and 2 weeks of travel, putting any RC1 into mid
October at the earliest. That in turn makes it harder to get a release
actually made in 2012.
The other disadvantage is that while conferences are a great goal to aim
at for releases, the quick-and-dirty development style (needed to
isolate issues quickly) may simply mean we either have patches in the
tree that are not totally ready (simply because they were prepared under
pressure) or we have a long delay as we wait for folks to work though
their backlog.
This timing also affects our downstream distributions, so I would
appreciate any views from that direction as well.
Thanks,
Andrew Bartlett
IMHO the biggest (most probable source for possible user grief) issue is
s3fs behavior in handling policies. To my experiments (I've just switched
our production network from 3 to 4 in the weekend) not only does it
prohibit setting policies initially but after manually given full access to
Domain Admins, I was able to set up some policies. The problem which
persist is inability to change the ACLs for policies. I think will give
ntvfs a try.
Cheers
Geza Gemes
--
Gémes Géza
2012-08-13 08:36:22 UTC
Permalink
Hi Ricky,
Post by Ricky Nance
Geza, make sure you have the right mount options in fstab and also the
right headers for ACL's I had a similar problem initially, but once I
got those fixed up, all went well. See the samba4 howto wiki for more
info on this.
Good luck,
Ricky
Thanks for the answer, but I'm afraid that doesn't help me (I'we chose
xfs as the file system for the partition holding /usr/local/samba
especially to avoid acl related problems on sysvol) and I'm able to set
some ACLs from windows, but if I try to make some policies applicable to
Domain Admins as well it complains about inability to set access rights
(a device connected doesn't work) on the folder containing the policy
({...}).

BTW. my attempt to use ntvfs wasn't successful either, it seems that it
doesn't understand at all the acls set by s3fs.

Cheers

Geza
Michael Wood
2012-08-13 08:46:13 UTC
Permalink
Post by Gémes Géza
Hi Ricky,
Post by Ricky Nance
Geza, make sure you have the right mount options in fstab and also the
right headers for ACL's I had a similar problem initially, but once I got
those fixed up, all went well. See the samba4 howto wiki for more info on
this.
Good luck,
Ricky
Thanks for the answer, but I'm afraid that doesn't help me (I'we chose xfs
as the file system for the partition holding /usr/local/samba especially to
avoid acl related problems on sysvol) and I'm able to set some ACLs from
windows, but if I try to make some policies applicable to Domain Admins as
well it complains about inability to set access rights (a device connected
doesn't work) on the folder containing the policy ({...}).
BTW. my attempt to use ntvfs wasn't successful either, it seems that it
doesn't understand at all the acls set by s3fs.
I think Andrew is working on these ACL issues.
--
Michael Wood <esiotrot at gmail.com>
Andrew Bartlett
2012-08-22 03:37:50 UTC
Permalink
Post by Gémes Géza
Hi Ricky,
Post by Ricky Nance
Geza, make sure you have the right mount options in fstab and also the
right headers for ACL's I had a similar problem initially, but once I
got those fixed up, all went well. See the samba4 howto wiki for more
info on this.
Good luck,
Ricky
Thanks for the answer, but I'm afraid that doesn't help me (I'we chose
xfs as the file system for the partition holding /usr/local/samba
especially to avoid acl related problems on sysvol) and I'm able to set
some ACLs from windows, but if I try to make some policies applicable to
Domain Admins as well it complains about inability to set access rights
(a device connected doesn't work) on the folder containing the policy
({...}).
BTW. my attempt to use ntvfs wasn't successful either, it seems that it
doesn't understand at all the acls set by s3fs.
That is correct.

An implementation of provision with (I hope) correct setting of group
policy acls is in my posix-acl-provision-wip branch.

https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/posix-acl-provision-wip

Please test it out (requires a fresh provision run) and let me know if
you can now modify ACLs as non-administrator, using s3fs.

I'll write a tool to fix existing installations shortly.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Andrew Bartlett
2012-08-22 10:18:42 UTC
Permalink
Post by Andrew Bartlett
Post by Gémes Géza
Hi Ricky,
Post by Ricky Nance
Geza, make sure you have the right mount options in fstab and also the
right headers for ACL's I had a similar problem initially, but once I
got those fixed up, all went well. See the samba4 howto wiki for more
info on this.
Good luck,
Ricky
Thanks for the answer, but I'm afraid that doesn't help me (I'we chose
xfs as the file system for the partition holding /usr/local/samba
especially to avoid acl related problems on sysvol) and I'm able to set
some ACLs from windows, but if I try to make some policies applicable to
Domain Admins as well it complains about inability to set access rights
(a device connected doesn't work) on the folder containing the policy
({...}).
BTW. my attempt to use ntvfs wasn't successful either, it seems that it
doesn't understand at all the acls set by s3fs.
That is correct.
An implementation of provision with (I hope) correct setting of group
policy acls is in my posix-acl-provision-wip branch.
https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/posix-acl-provision-wip
Please test it out (requires a fresh provision run) and let me know if
you can now modify ACLs as non-administrator, using s3fs.
I'll write a tool to fix existing installations shortly.
With that branch, you can now call:
samba-tool ntacl sysvolreset

To fix your sysvol ACLs. I still plan on having a generic conversion
utility if there is demand (for file shares on the ntvfs server), but in
the meantime you can do a backup/restore from a windows client using an
ACL-preserving tool.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Stefan (metze) Metzmacher
2012-08-13 09:01:01 UTC
Permalink
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).
I think we should tread the once as blockers, which are
- security/acl relevant
- may cause directory inconsistency.
- allow DoS attacks by doing

E.g. https://bugzilla.samba.org/show_bug.cgi?id=8620
https://bugzilla.samba.org/show_bug.cgi?id=8621
https://bugzilla.samba.org/show_bug.cgi?id=8638
https://bugzilla.samba.org/show_bug.cgi?id=8929
https://bugzilla.samba.org/show_bug.cgi?id=9089
https://bugzilla.samba.org/show_bug.cgi?id=8077
https://bugzilla.samba.org/show_bug.cgi?id=9029

I still need to file some new bugs...
Post by Andrew Bartlett
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?
I would like to have initial support for durable handles (SMB 2.0/2.1)
in the final release, we made good progress in last months, but there's
still some cleanup to be done before it's ready for master.

See
https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-durable

This branch has also support for durable handles v2 (SMB3), but we
may need to add some more input validation there (we need to test
against windows).

There're some other we need to check regarding input validation,
(related to the replay and channel sequence stuff in SMB3).

I have SMB3 encryption almost ready, but as Windows clients doesn't
behave exactly as documented, I need to have some minor details
in this branch:
https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-signing

We're working hard to get this ready before the SDC.
The plan is to change the default for "server max protocol" to SMB3,
and get as much testing as possible during the SDC.
If we're happy with the result we can keep that default for the final
release.

It would be really nice if we could get SMB2/3 support for smbclient
for 4.0.0, because that would mean admin don't have to wait Samba,
in order to disable SMB1 (as proposed by Microsoft if all clients
are at least at Windows Vista level). But I think that's not a blocker
for our release.
Post by Andrew Bartlett
We also still need help with manpages, documentation of new smb.conf
options.
Finally, this brings us to timing, and the challenges and opportunities
presented by the upcoming SDC event and plugfest at Microsoft.
We could release RC1 before SDC
http://snia.org/events/storage-developer2012/plugfest (starts 16 Sept)
and the Microsoft AD plugfest (ends 28 Sept). However, then if we find
issues (and that is the express purpose of such events) we will need to
go via the full bug+patch process for all of them.
Or we could release RC1 after both events, but that starts to be early
October, and that seems like a long delay, and I for one will be pretty
exhausted after jet-lag and 2 weeks of travel, putting any RC1 into mid
October at the earliest. That in turn makes it harder to get a release
actually made in 2012.
The other disadvantage is that while conferences are a great goal to aim
at for releases, the quick-and-dirty development style (needed to
isolate issues quickly) may simply mean we either have patches in the
tree that are not totally ready (simply because they were prepared under
pressure) or we have a long delay as we wait for folks to work though
their backlog.
I'm ok with before or after the events, we'll need rc2, rc3 later anyway.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120813/22463363/attachment.pgp>
Andrew Bartlett
2012-08-13 10:42:46 UTC
Permalink
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).
I think we should tread the once as blockers, which are
- security/acl relevant
- may cause directory inconsistency.
- allow DoS attacks by doing
E.g. https://bugzilla.samba.org/show_bug.cgi?id=8620
https://bugzilla.samba.org/show_bug.cgi?id=8621
https://bugzilla.samba.org/show_bug.cgi?id=8638
https://bugzilla.samba.org/show_bug.cgi?id=8929
https://bugzilla.samba.org/show_bug.cgi?id=9089
https://bugzilla.samba.org/show_bug.cgi?id=8077
https://bugzilla.samba.org/show_bug.cgi?id=9029
The challenge I see with this list is that all of these issues have been
known about for quite some time (most more than a year). How do can we
reasonably block the release when we have no reasonable prospect that
someone will step up and fix them?
Post by Stefan (metze) Metzmacher
I still need to file some new bugs...
Even with this just this list, given current resources working on AD
stuff, I just don't see how we can fix these. In the meantime, our
users seem very happy to deploy our current code, and I would prefer to
warn them about these challenges than deny them a stable release because
of them.

Do you have any time to address these? (From the below, it seems you
will be pretty busy on SMB3 stuff)
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?
I would like to have initial support for durable handles (SMB 2.0/2.1)
in the final release, we made good progress in last months, but there's
still some cleanup to be done before it's ready for master.
See
https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-durable
This branch has also support for durable handles v2 (SMB3), but we
may need to add some more input validation there (we need to test
against windows).
There're some other we need to check regarding input validation,
(related to the replay and channel sequence stuff in SMB3).
I have SMB3 encryption almost ready, but as Windows clients doesn't
behave exactly as documented, I need to have some minor details
https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-signing
How soon do you expect to land this?
Post by Stefan (metze) Metzmacher
I'm ok with before or after the events, we'll need rc2, rc3 later anyway.
It would be grand if we could really treat RC1 as a real release
candidate, but I fear we will have a situation like 3.6 where we keep
bluffing our vendors and users with 'this is the real RC this time,
please test it' (while we pile more and more changes and have to release
RC after RC). It would be good if we could focus on RC1 as the release,
and plan for 4.0.1 for fixes that are not earth-shattering. Otherwise,
the term 'release candidate' doesn't really mean anything.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Nadezhda Ivanova
2012-08-13 12:16:07 UTC
Permalink
With the current LDAP acl missing functionality, I don't know if RC is
feasible... Unfortunately I am not able to work on this at the moment, or
in the near future. If someone wants to do it I will help, but I am not in
a position anymore to maintain this code...

Regards,
Nadya
Post by Andrew Bartlett
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before
or
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of
these
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
have not seen much attention since being filed (and don't seem to be
bothering our production users).
I think we should tread the once as blockers, which are
- security/acl relevant
- may cause directory inconsistency.
- allow DoS attacks by doing
E.g. https://bugzilla.samba.org/show_bug.cgi?id=8620
https://bugzilla.samba.org/show_bug.cgi?id=8621
https://bugzilla.samba.org/show_bug.cgi?id=8638
https://bugzilla.samba.org/show_bug.cgi?id=8929
https://bugzilla.samba.org/show_bug.cgi?id=9089
https://bugzilla.samba.org/show_bug.cgi?id=8077
https://bugzilla.samba.org/show_bug.cgi?id=9029
The challenge I see with this list is that all of these issues have been
known about for quite some time (most more than a year). How do can we
reasonably block the release when we have no reasonable prospect that
someone will step up and fix them?
Post by Stefan (metze) Metzmacher
I still need to file some new bugs...
Even with this just this list, given current resources working on AD
stuff, I just don't see how we can fix these. In the meantime, our
users seem very happy to deploy our current code, and I would prefer to
warn them about these challenges than deny them a stable release because
of them.
Do you have any time to address these? (From the below, it seems you
will be pretty busy on SMB3 stuff)
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that
development
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
effort where it is logical to pause and release?
I would like to have initial support for durable handles (SMB 2.0/2.1)
in the final release, we made good progress in last months, but there's
still some cleanup to be done before it's ready for master.
See
https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-durable
Post by Stefan (metze) Metzmacher
This branch has also support for durable handles v2 (SMB3), but we
may need to add some more input validation there (we need to test
against windows).
There're some other we need to check regarding input validation,
(related to the replay and channel sequence stuff in SMB3).
I have SMB3 encryption almost ready, but as Windows clients doesn't
behave exactly as documented, I need to have some minor details
https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-signing
How soon do you expect to land this?
Post by Stefan (metze) Metzmacher
I'm ok with before or after the events, we'll need rc2, rc3 later anyway.
It would be grand if we could really treat RC1 as a real release
candidate, but I fear we will have a situation like 3.6 where we keep
bluffing our vendors and users with 'this is the real RC this time,
please test it' (while we pile more and more changes and have to release
RC after RC). It would be good if we could focus on RC1 as the release,
and plan for 4.0.1 for fixes that are not earth-shattering. Otherwise,
the term 'release candidate' doesn't really mean anything.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Andrew Bartlett
2012-08-13 13:20:59 UTC
Permalink
Post by Nadezhda Ivanova
With the current LDAP acl missing functionality, I don't know if RC is
feasible... Unfortunately I am not able to work on this at the moment, or
in the near future. If someone wants to do it I will help, but I am not in
a position anymore to maintain this code...
Thanks Nadya,

I really didn't mean this to put you on the spot with this. What you
have done with our ACL code is extraordinary, and we are much better off
because of it. It is sad that the great push that we were both a part
of didn't work out in the long run, but we all benefit from the work
that was done.
Post by Nadezhda Ivanova
From here, what we do need to be is realistic with regards to how much
we can do, with the resources that are available day-to-day.

My position has always been to release Samba 4.0 'as is' in terms of
major features (and I consider things like moving to read ACLs to be a
new major feature). The view of the team was that we had to finish s3fs
first, and so I've been working on that, but it just isn't realistic to
try and schedule any other such work before RC1, even if it is listed as
a blocker bug.

For myself, I seem to remain tied up with that s3fs integration work.
(As an example, I still haven't fixed up the DNS replication situation
to my satisfaction).

I'll continue to promote Samba 4.0 to our users and to companies that
see the promise that our former employer saw in our work here.
Hopefully we will again see the great strides forward in AD function
that you I and the others achieved.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Marc Muehlfeld
2012-08-13 15:00:22 UTC
Permalink
Hello,

can a samba 4 server meanwhile act as a print server for windows clients
(including providing drivers to the clients)? I think many who run a samba 3
PDC also have their printing services on the same host.

Regards,
Marc
Andrew Bartlett
2012-08-17 06:54:24 UTC
Permalink
Post by Marc Muehlfeld
Hello,
can a samba 4 server meanwhile act as a print server for windows clients
(including providing drivers to the clients)? I think many who run a samba 3
PDC also have their printing services on the same host.
The parts are available to make this work, but at the moment many of our
printing tests fail in make test. We someone to take on the task of
making this work. It may be nothing more than changing the smb.conf
values we write out into fileserver.conf (see the code in file_server).

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
steve
2012-08-13 15:27:33 UTC
Permalink
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).
Hi Andrew, hi everyone.

Having done all this work on s3fs and still not being able to recommend
it as a file server on the same box a the DC doesn't look good. The
rfc2307 compatibility doesn't yet work for the full set of rfc2307. It
seems unlikely to do so in the near future. Unless. . .

Many of us use predominantly Linux clients on our Samba4 LAN's keeping
only the xp and windows compatibility for e.g. photoshop and admin
programs that will only run under m$. For we users, the S4 LDAP is a
vast improvement over S3/openLDAP.

Please do not release a RC until the rfc2307 requirements of a large
number of Samba devotees have been met. On s3fs.

Cheers,
Steve
Matthieu Patou
2012-08-14 05:50:25 UTC
Permalink
Post by Andrew Bartlett
(TLDR: I want us to think about if we should release Samba 4.0 before or
after SDC and the MS plugfest).
Over the past couple of months now, I have been releasing a Samba 4.0
beta every two weeks, as we proceed on the path to a release candidate.
Indeed, while I can't find the schedule right now, it called for the
next release (Tuesday Aug 14) to be RC1!
Now that I have your attention, I'm not seriously suggesting pulling an
RC next week, but I do want to discuss what we will do to get to making
an RC of Samba 4.0, and how that might fit into other major development
effort that is ongoing.
The background is that since Beta 2, s3fs has been the default and
hasn't caused major issues. This was consisdered the single biggest
blocking issue. That said, I am not totally happy with it, as the ACL
handling needs work: we set ACLs during provision that are sent to the
client, but not actually honoured by Samba. I'm working to fix this.
There is of course the series of bugs attached to
https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
have not seen much attention since being filed (and don't seem to be
bothering our production users).
That covers the AD side of the house, but clearly there is a massive
development effort ongoing for the SMB3 support. This is really
important, as it not only emphasises that Samba 4.0 is a major leap
forward across all of our many parts, but it also gives us a chance to
get SMB3 (even without many of the optional features) into the hands of
our users.
My question on SMB3 is: Are we at or nearing a point in that development
effort where it is logical to pause and release?
We also still need help with manpages, documentation of new smb.conf
options.
Finally, this brings us to timing, and the challenges and opportunities
presented by the upcoming SDC event and plugfest at Microsoft.
We could release RC1 before SDC
http://snia.org/events/storage-developer2012/plugfest (starts 16 Sept)
and the Microsoft AD plugfest (ends 28 Sept). However, then if we find
issues (and that is the express purpose of such events) we will need to
go via the full bug+patch process for all of them.
Or we could release RC1 after both events, but that starts to be early
October, and that seems like a long delay, and I for one will be pretty
exhausted after jet-lag and 2 weeks of travel, putting any RC1 into mid
October at the earliest. That in turn makes it harder to get a release
actually made in 2012.
The other disadvantage is that while conferences are a great goal to aim
at for releases, the quick-and-dirty development style (needed to
isolate issues quickly) may simply mean we either have patches in the
tree that are not totally ready (simply because they were prepared under
pressure) or we have a long delay as we wait for folks to work though
their backlog.
This timing also affects our downstream distributions, so I would
appreciate any views from that direction as well.
I think we should really start to tackle all our blocking bugs for 4.0
before the RC, we can recheck the list also we discussed about a white
paper for users about 4.0 in terms of understanding what is this 4.0
release (ie. stability of the file server between version 3.6.x and
4.0.x, ...) I think if we decide not to have read ACLs activated it's
*really* important to state it in this kind of paper so that admin
picking this are aware of it.
A release a bit before SDC didn't sounds to bad if we starts to tackle
the two points mentioned before.

I'm sorry for being quite offline, I'm quite busy at work with new
projects that are leaving me a bit lazy in the evening. I'm hoping to
get back in the track pretty soon though.
--
Matthieu Patou
Samba Team
http://samba.org
Andrew Bartlett
2012-08-14 07:25:05 UTC
Permalink
Post by Matthieu Patou
I think we should really start to tackle all our blocking bugs for 4.0
before the RC, we can recheck the list also we discussed about a white
paper for users about 4.0 in terms of understanding what is this 4.0
release (ie. stability of the file server between version 3.6.x and
4.0.x, ...) I think if we decide not to have read ACLs activated it's
*really* important to state it in this kind of paper so that admin
picking this are aware of it.
A release a bit before SDC didn't sounds to bad if we starts to tackle
the two points mentioned before.
Matthieu,

I'm confused. How can we start to tackle all our blocking bugs for 4.0
before the RC and a do an RC before SDC?

To be clear: I don't have time for any of the bugs attached as blockers
there so far, and don't expect that situation to improve in the next
month. (I'm still swamped by trying to keep on top of the various
things reported on the list daily and the remaining s3fs issues).

I appreciate your offer to find time to work on this, but I also think
we need to be much more realistic about what we can actually achieve.

All that said, I agree it would be useful to start on a document
explaining how Samba 4.0 and it's components fits into Samba's release
stream. Perhaps this is something concrete you can start on?

Thanks,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Matthieu Patou
2012-08-15 18:07:39 UTC
Permalink
Post by Andrew Bartlett
Post by Matthieu Patou
I think we should really start to tackle all our blocking bugs for 4.0
before the RC, we can recheck the list also we discussed about a white
paper for users about 4.0 in terms of understanding what is this 4.0
release (ie. stability of the file server between version 3.6.x and
4.0.x, ...) I think if we decide not to have read ACLs activated it's
*really* important to state it in this kind of paper so that admin
picking this are aware of it.
A release a bit before SDC didn't sounds to bad if we starts to tackle
the two points mentioned before.
Matthieu,
I'm confused. How can we start to tackle all our blocking bugs for 4.0
before the RC and a do an RC before SDC?
start to tackle didn't mean ihmo resolving all the issues before RC but
at least starting to work on them to see those that are still relevant
and those which aren't anymore.
Post by Andrew Bartlett
To be clear: I don't have time for any of the bugs attached as blockers
there so far, and don't expect that situation to improve in the next
month. (I'm still swamped by trying to keep on top of the various
things reported on the list daily and the remaining s3fs issues).
Well you do a pretty good job on this but
Post by Andrew Bartlett
I appreciate your offer to find time to work on this, but I also think
we need to be much more realistic about what we can actually achieve.
All that said, I agree it would be useful to start on a document
explaining how Samba 4.0 and it's components fits into Samba's release
stream. Perhaps this is something concrete you can start on?
I'm quite ok to work on this just if we agree that's important it will
be eventually a blocker for the final release. Code feature are
important but documentation for users is important to.

Matthieu.
--
Matthieu Patou
Samba Team
http://samba.org
Andrew Bartlett
2012-08-17 04:47:29 UTC
Permalink
Post by Matthieu Patou
Post by Andrew Bartlett
Post by Matthieu Patou
I think we should really start to tackle all our blocking bugs for 4.0
before the RC, we can recheck the list also we discussed about a white
paper for users about 4.0 in terms of understanding what is this 4.0
release (ie. stability of the file server between version 3.6.x and
4.0.x, ...) I think if we decide not to have read ACLs activated it's
*really* important to state it in this kind of paper so that admin
picking this are aware of it.
A release a bit before SDC didn't sounds to bad if we starts to tackle
the two points mentioned before.
Matthieu,
I'm confused. How can we start to tackle all our blocking bugs for 4.0
before the RC and a do an RC before SDC?
start to tackle didn't mean ihmo resolving all the issues before RC but
at least starting to work on them to see those that are still relevant
and those which aren't anymore.
That much I have been doing, and with one or two exceptions where the
reporter is being pinged, what remains is, if we were to fix it, a
substantial amount of work, particularly in comparison to the resources
we have normally had available.

Naturally, if more folks have more time, we can fix more bugs, but the
list in bugzilla is pretty much the 'hard basket' at this point.
Post by Matthieu Patou
Post by Andrew Bartlett
To be clear: I don't have time for any of the bugs attached as blockers
there so far, and don't expect that situation to improve in the next
month. (I'm still swamped by trying to keep on top of the various
things reported on the list daily and the remaining s3fs issues).
Well you do a pretty good job on this but
Post by Andrew Bartlett
I appreciate your offer to find time to work on this, but I also think
we need to be much more realistic about what we can actually achieve.
All that said, I agree it would be useful to start on a document
explaining how Samba 4.0 and it's components fits into Samba's release
stream. Perhaps this is something concrete you can start on?
I'm quite ok to work on this just if we agree that's important it will
be eventually a blocker for the final release. Code feature are
important but documentation for users is important to.
My view is that given that folks are extensively using what we have
already, that we should only assign blocker status to thing that we have
folks signing up to fix. That is, both our documentation and code seems
good enough for a wide selection of our current users.

There are some things that are non-negotiable, because we already set
down a rule: like a smb.conf section for each new parameter, and a
man-page for each installed binary. But beyond that we should focus on
what each of us can fix ourselves, rather than creating an arbitrary
list of things that someone else should fix.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Juan Pablo Lorier
2012-08-15 11:27:57 UTC
Permalink
First my apologies as I know this threat is not for users, but I just
wanted to add an "outside" point of view.

You are doing a great job with samba4 and us, the users, are eager to
use it in our production environments, but I think that you shouldn't
rush to the RC before having fixed some mayor (at my point of view)
features as many users will be encouraged to get samba running and they
may disappoint after having issues or even corruption of their
production environments.
In my opinion, an RC should be for a product that you have almost
completed and need more testing to get new bugs you just missed, but at
this time, you already have many important bugs waiting to get time to
be fixed.
I'm trying to get samba to substitute windows but domain controller is
not working properly yet, so I'm not even trying to test s3fs just to
pile up more problems. But I'm a fun of your work and I'll keep trying
until I'll get it working, others may not have such enthusiasm and just
think "this doesn't work, I'm not wasting time... let's keep windows".
Again, just an user's opinion.
Regards,

Juan Pablo Lorier

PS: I'll be back from vacation next week and I'll try this new betas :-)
Andrew Bartlett
2012-08-17 10:48:14 UTC
Permalink
Post by Juan Pablo Lorier
First my apologies as I know this threat is not for users, but I just
wanted to add an "outside" point of view.
You are doing a great job with samba4 and us, the users, are eager to
use it in our production environments, but I think that you shouldn't
rush to the RC before having fixed some mayor (at my point of view)
features as many users will be encouraged to get samba running and they
may disappoint after having issues or even corruption of their
production environments.
Are you aware of any issues that have actually caused corruption of a
production environment?

I certainly am aware of the issues folks had around DNS replication, but
there are now guards to prevent those issues re-occurring.

I know you have had challenges with your installation conflicting with a
system ldb. Did you get that resolved?

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Juan Pablo Lorier
2012-08-17 16:46:31 UTC
Permalink
Hi Andrew,

First of all, my apologies for talking about corruption without actually
knowing the state of the project. I was commenting over some mails in
the list a few months ago.
About my setup, I'll get back to work on Monday after my vacation and
after dealing with all those things that often wait for our return, I'll
compile the new betas and see if I can get the replication to work.
I didn't mean to alarm anybody, just wanted to contribute with my
opinion as somebody not involved in the developing of samba.
I deal with a lot of Microsoft lovers that often diminish the power of
open source software and Samba is a keystone for Unix/linux system to
stay strong in server environments and for gaining new desktops everyday
and I defend it as the great product it is, just don't want those guys
something to ground their critics.
Regards,

Juan Pablo Lorier
Post by Andrew Bartlett
Post by Juan Pablo Lorier
First my apologies as I know this threat is not for users, but I just
wanted to add an "outside" point of view.
You are doing a great job with samba4 and us, the users, are eager to
use it in our production environments, but I think that you shouldn't
rush to the RC before having fixed some mayor (at my point of view)
features as many users will be encouraged to get samba running and they
may disappoint after having issues or even corruption of their
production environments.
Are you aware of any issues that have actually caused corruption of a
production environment?
I certainly am aware of the issues folks had around DNS replication, but
there are now guards to prevent those issues re-occurring.
I know you have had challenges with your installation conflicting with a
system ldb. Did you get that resolved?
Andrew Bartlett
Andrew Bartlett
2012-08-17 21:52:44 UTC
Permalink
Post by steve
Hi Andrew,
I deal with a lot of Microsoft lovers that often diminish the power of
open source software and Samba is a keystone for Unix/linux system to
stay strong in server environments and for gaining new desktops everyday
and I defend it as the great product it is, just don't want those guys
something to ground their critics.
Regards,
G'day Juan Pablo,

I understand your concern, and we may very well ship Samba 4.0 with a
general caution on multi-DC use (also because we do not have a file
systems replication protocol for sysvol yet).

However, as you would have seen elsewhere in this thread, there is a
cost to constantly calling this a beta: network administrators who have
tested Samba carefully and do have Samba 4.0 working very well for them
are forced to argue why their networks should be trusted the beta
software. We know our code isn't perfect, but our automated testing
also shows it is pretty good, and we also need to show some of the same
confidence our users are already putting in it.

We will not stop working to address the very real issues that do come
up, but we should draw a line in the sand and say 'our users can
confidently use this'.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Michael Wood
2012-08-18 17:48:52 UTC
Permalink
Hi
Post by Andrew Bartlett
Post by steve
Hi Andrew,
I deal with a lot of Microsoft lovers that often diminish the power of
open source software and Samba is a keystone for Unix/linux system to
stay strong in server environments and for gaining new desktops everyday
and I defend it as the great product it is, just don't want those guys
something to ground their critics.
Regards,
G'day Juan Pablo,
I understand your concern, and we may very well ship Samba 4.0 with a
general caution on multi-DC use (also because we do not have a file
systems replication protocol for sysvol yet).
However, as you would have seen elsewhere in this thread, there is a
cost to constantly calling this a beta: network administrators who have
tested Samba carefully and do have Samba 4.0 working very well for them
are forced to argue why their networks should be trusted the beta
software. We know our code isn't perfect, but our automated testing
also shows it is pretty good, and we also need to show some of the same
confidence our users are already putting in it.
We will not stop working to address the very real issues that do come
up, but we should draw a line in the sand and say 'our users can
confidently use this'.
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
--
Michael Wood <esiotrot at gmail.com>
steve
2012-08-18 18:16:15 UTC
Permalink
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
Hi
OK. So I run:
samba
I then have AD and a decent fileserver which manifests itself as smbd in
the logs. Both run on the same box. winbind seems to be running too.

If I type:
samba
I get AD, a fileserver and winbind
If I type:
smbd
I get just a fileserver.

Questions:
1. Is that correct?
2. Is the smbd that is in /usr/local/samba/sbin the same smbd that ships
with samba 3.6?
3. Wait, it can't be becasue I can't use my old S3 smb.conf with it
because it doesn't understand stuff like create mask = 0700. What do the
devs say?

It may be clear to devs but to end users it seems very difficult to
penetrate the technical barrier.

Thanks,
Steve
Gémes Géza
2012-08-18 21:38:02 UTC
Permalink
Post by steve
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
Hi
samba
I then have AD and a decent fileserver which manifests itself as smbd
in the logs. Both run on the same box. winbind seems to be running too.
samba
I get AD, a fileserver and winbind
smbd
I get just a fileserver.
1. Is that correct?
2. Is the smbd that is in /usr/local/samba/sbin the same smbd that
ships with samba 3.6?
3. Wait, it can't be becasue I can't use my old S3 smb.conf with it
because it doesn't understand stuff like create mask = 0700. What do
the devs say?
It may be clear to devs but to end users it seems very difficult to
penetrate the technical barrier.
Thanks,
Steve
For a samba4 AD controller you need to run samba.
For a samba3 style server (standalone or domain member) you would need
to run smbd and nmbd (+winbind if domain member). I'm not sure the smbd
binary which gets installed with a top level (waf based) build is
suitable for this kind of operation. But building smbd by running
./configure ; make ; make install from the source3 directory produces a
typical samba3 installation (except lot more advanced like support for
smb3 dialect etc.)

Regards

Geza Gemes
Andrew Bartlett
2012-08-18 22:32:34 UTC
Permalink
Post by Gémes Géza
I'm not sure the smbd
binary which gets installed with a top level (waf based) build is
suitable for this kind of operation. But building smbd by running
./configure ; make ; make install from the source3 directory produces a
typical samba3 installation (except lot more advanced like support for
smb3 dialect etc.)
The smbd binary produced by the waf build is suitable for this work. As
we explain in BUILD_SYSTEMS.txt, you should use the waf build unless you
cannot meet the python requirements.

(There is an RC bug about our configure tests for quota and ACL support
on more unusual platforms, which will be addressed)

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Andrew Bartlett
2012-08-18 21:50:57 UTC
Permalink
Post by Michael Wood
Hi
Post by Andrew Bartlett
Post by steve
Hi Andrew,
I deal with a lot of Microsoft lovers that often diminish the power of
open source software and Samba is a keystone for Unix/linux system to
stay strong in server environments and for gaining new desktops everyday
and I defend it as the great product it is, just don't want those guys
something to ground their critics.
Regards,
G'day Juan Pablo,
I understand your concern, and we may very well ship Samba 4.0 with a
general caution on multi-DC use (also because we do not have a file
systems replication protocol for sysvol yet).
However, as you would have seen elsewhere in this thread, there is a
cost to constantly calling this a beta: network administrators who have
tested Samba carefully and do have Samba 4.0 working very well for them
are forced to argue why their networks should be trusted the beta
software. We know our code isn't perfect, but our automated testing
also shows it is pretty good, and we also need to show some of the same
confidence our users are already putting in it.
We will not stop working to address the very real issues that do come
up, but we should draw a line in the sand and say 'our users can
confidently use this'.
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Rowland Penny
2012-08-19 06:53:07 UTC
Permalink
Post by Andrew Bartlett
Post by Michael Wood
Hi
Post by Andrew Bartlett
Post by steve
Hi Andrew,
I deal with a lot of Microsoft lovers that often diminish the power of
open source software and Samba is a keystone for Unix/linux system to
stay strong in server environments and for gaining new desktops everyday
and I defend it as the great product it is, just don't want those guys
something to ground their critics.
Regards,
G'day Juan Pablo,
I understand your concern, and we may very well ship Samba 4.0 with a
general caution on multi-DC use (also because we do not have a file
systems replication protocol for sysvol yet).
However, as you would have seen elsewhere in this thread, there is a
cost to constantly calling this a beta: network administrators who have
tested Samba carefully and do have Samba 4.0 working very well for them
are forced to argue why their networks should be trusted the beta
software. We know our code isn't perfect, but our automated testing
also shows it is pretty good, and we also need to show some of the same
confidence our users are already putting in it.
We will not stop working to address the very real issues that do come
up, but we should draw a line in the sand and say 'our users can
confidently use this'.
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
If you do not allow smbd/nmbd/winbindd to start without fully
transferring their actions to the samba daemon, you will not in my
opinion have an AD domain controller as per microsofts spec or what the
majority of users want.
This is just my opinion, but I would have thought that most users want a
server that could be a direct swap with a microsoft one, if you read
what a microsoft server can do, there is a long way to go.

Rowland
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
steve
2012-08-19 07:12:48 UTC
Permalink
Post by Andrew Bartlett
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
Hi
Oh dear. That sounds bad. Does that mean that we will no longer be able
to use AD, s3fs and winbind on the same box as we can do (reliably) at
the moment?
Cheers,
Steve
Gémes Géza
2012-08-20 08:20:54 UTC
Permalink
Post by steve
Post by Andrew Bartlett
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
Hi
Oh dear. That sounds bad. Does that mean that we will no longer be
able to use AD, s3fs and winbind on the same box as we can do
(reliably) at the moment?
Cheers,
Steve
No, that would mean you won't be able to run conflicting binaries
simultaneously.
For clarity, samba4 (with s3fs) consist of two (server function
providing) binaries: samba and smbd. smbd listens on ports 139 and 445
providing file services (s3fs), samba listens on a plenty of ports
providing lots of services like a kerberos kdc, etc. It also provides
its internal nmbd and winbind services. On the other hand a samba3 lets
call it classic installation consist of three (server function
providing) binaries: smbd, nmbd and winbind. If you would start any of
those that would cause unpredictable conflicts.
In conclusion disallowing the start of smbd, nmbd and winbind daemons if
the samba binary is running would save the users from shooting
themselves on foot.

Regards

Geza Gemes
Rowland Penny
2012-08-20 08:55:32 UTC
Permalink
Post by Gémes Géza
Post by steve
Post by Andrew Bartlett
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
Hi
Oh dear. That sounds bad. Does that mean that we will no longer be
able to use AD, s3fs and winbind on the same box as we can do
(reliably) at the moment?
Cheers,
Steve
No, that would mean you won't be able to run conflicting binaries
simultaneously.
For clarity, samba4 (with s3fs) consist of two (server function
providing) binaries: samba and smbd. smbd listens on ports 139 and 445
providing file services (s3fs), samba listens on a plenty of ports
providing lots of services like a kerberos kdc, etc. It also provides
its internal nmbd and winbind services. On the other hand a samba3
lets call it classic installation consist of three (server function
providing) binaries: smbd, nmbd and winbind. If you would start any of
those that would cause unpredictable conflicts.
In conclusion disallowing the start of smbd, nmbd and winbind daemons
if the samba binary is running would save the users from shooting
themselves on foot.
Regards
Geza Gemes
After I have had it explained to me I would basically go with Geza here,
yes stop nmbd & winbind running if the samba daemon is started, but as
you need smbd to get s3fs (as far as I understand) this needs to be
stopped from running unless it is started automatically via samba or if
you are not going to run the samba daemon ( i.e. mutually exclusive) in
which case you would need /etc/samba/smb.conf, nmbd and possibly winbind.

Rowland
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
steve
2012-08-20 09:30:07 UTC
Permalink
Post by Rowland Penny
Post by Gémes Géza
Post by steve
Post by Andrew Bartlett
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
Hi
Oh dear. That sounds bad. Does that mean that we will no longer be
able to use AD, s3fs and winbind on the same box as we can do
(reliably) at the moment?
Cheers,
Steve
No, that would mean you won't be able to run conflicting binaries
simultaneously.
For clarity, samba4 (with s3fs) consist of two (server function
providing) binaries: samba and smbd. smbd listens on ports 139 and 445
providing file services (s3fs), samba listens on a plenty of ports
providing lots of services like a kerberos kdc, etc. It also provides
its internal nmbd and winbind services. On the other hand a samba3
lets call it classic installation consist of three (server function
providing) binaries: smbd, nmbd and winbind. If you would start any of
those that would cause unpredictable conflicts.
In conclusion disallowing the start of smbd, nmbd and winbind daemons
if the samba binary is running would save the users from shooting
themselves on foot.
Regards
Geza Gemes
After I have had it explained to me I would basically go with Geza here,
yes stop nmbd & winbind running if the samba daemon is started, but as
you need smbd to get s3fs (as far as I understand) this needs to be
stopped from running unless it is started automatically via samba or if
you are not going to run the samba daemon ( i.e. mutually exclusive) in
which case you would need /etc/samba/smb.conf, nmbd and possibly winbind.
Rowland
Hi
The samba binary seems to start a version of smbd when it start up. You
can see it in the logs. Is the smbd that samba starts called s3fs if it
is started via samba? If so, what is it called if it is started would
samba. smbd? And does it then allow all the smb.conf configure options
one would expect from Samba 3.x?

Cheers,
Steve
steve
2012-08-20 09:26:08 UTC
Permalink
Post by Gémes Géza
Post by steve
Post by Andrew Bartlett
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
Hi
Oh dear. That sounds bad. Does that mean that we will no longer be
able to use AD, s3fs and winbind on the same box as we can do
(reliably) at the moment?
Cheers,
Steve
No, that would mean you won't be able to run conflicting binaries
simultaneously.
For clarity, samba4 (with s3fs) consist of two (server function
providing) binaries: samba and smbd. smbd listens on ports 139 and 445
providing file services (s3fs), samba listens on a plenty of ports
providing lots of services like a kerberos kdc, etc. It also provides
its internal nmbd and winbind services. On the other hand a samba3 lets
call it classic installation consist of three (server function
providing) binaries: smbd, nmbd and winbind. If you would start any of
those that would cause unpredictable conflicts.
In conclusion disallowing the start of smbd, nmbd and winbind daemons if
the samba binary is running would save the users from shooting
themselves on foot.
Regards
Geza Gemes
Hi G?za
To summarize the conclusion could you give a [Y/N] on these?

Either:
1. You run samba. It starts its own versions of smbd and winbind.
or
2. You run smbd and winbind (and nmbd if you want browsing)
3. You do not, ever, start samba and then smbd
4. You do not, ever, start samba and then winbindd
5. You do not, ever, start samba and nmbd
6. Andrew wants to add code to physically stop you doing 3, 4 and 5.

Cheers,
Steve
Ricky Nance
2012-08-20 10:52:16 UTC
Permalink
Post by steve
Post by Gémes Géza
Post by steve
Post by Michael Wood
Post by Michael Wood
Hi
I think it might help to make it extremely clear and explicit that
Post by Michael Wood
Samba 4 can be run as a DC using the samba binary, or it can be run
like a Samba 3 file/print server using the smbd/nmbd binaries, and any
other modes it can be used in. I know the release notes try to do
this, but I think there's still a lot of confusion from users.
I actually plan to do more than that. It's a little tricky (which is
why it's not done yet), and I'll allow an override, but being a AD DC
puts 'server role = active directory domain controller' in the smb.conf.
I would like to have smbd/nmbd/winbindd check this value and then simply
fail to start up.
Andrew Bartlett
Hi
Oh dear. That sounds bad. Does that mean that we will no longer be
able to use AD, s3fs and winbind on the same box as we can do
(reliably) at the moment?
Cheers,
Steve
No, that would mean you won't be able to run conflicting binaries
simultaneously.
For clarity, samba4 (with s3fs) consist of two (server function
providing) binaries: samba and smbd. smbd listens on ports 139 and 445
providing file services (s3fs), samba listens on a plenty of ports
providing lots of services like a kerberos kdc, etc. It also provides
its internal nmbd and winbind services. On the other hand a samba3 lets
call it classic installation consist of three (server function
providing) binaries: smbd, nmbd and winbind. If you would start any of
those that would cause unpredictable conflicts.
In conclusion disallowing the start of smbd, nmbd and winbind daemons if
the samba binary is running would save the users from shooting
themselves on foot.
Regards
Geza Gemes
Hi G?za
To summarize the conclusion could you give a [Y/N] on these?
1. You run samba. It starts its own versions of smbd and winbind.
or
2. You run smbd and winbind (and nmbd if you want browsing)
3. You do not, ever, start samba and then smbd
4. You do not, ever, start samba and then winbindd
5. You do not, ever, start samba and nmbd
6. Andrew wants to add code to physically stop you doing 3, 4 and 5.
Cheers,
Steve
Steve, the idea is that smbd,nmbd, and winbindd have conflicting ports with
samba, so they need to fail to start up if samba is running. That being
said, s3fs stands for Samba 3 File Server, so yes smbd MUST run for s3fs to
function properly, however, if the smbd that runs isn't aware that it
should be using the Samba 4 config, then you end up having more issues.
Basically look at it this way, if you have smbd from s3 running and you run
samba, and everything seems to startup fine, it won't run fine, because
smbd in this case is actually spawning a samba 3 server, and samba is
actually spawning a samba 4 server, so part of the request made to the
server is handled by samba 4 and part by samba 3, confused? So is your
windows/linux client. Basically, if you run smbd,nmbd,winbind, samba SHOULD
fail to start (they use the same ports, also slapd and kerberos and
probably various other programs will conflict with samba), or if you run
samba then smbd,nmbd, and winbind should fail to start (again they use the
same ports). For more of a real life example on this, set slapd to use port
389 and then start samba, then start slapd, does slapd fail to run? Why?

Hope this makes it a little more clear,
Ricky


--
Andreas Schneider
2012-08-20 16:08:38 UTC
Permalink
Post by Ricky Nance
Steve, the idea is that smbd,nmbd, and winbindd have conflicting ports with
samba, so they need to fail to start up if samba is running. That being
said, s3fs stands for Samba 3 File Server
It stands for SMB3 File Server, cause it supports SMB2.0, SMB2.1 and SMB3
protocols :)


-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
Samba Team asn at samba.org
www.samba.org
Juan Pablo Lorier
2012-08-19 00:30:10 UTC
Permalink
Hi Andrew,

Thanks for taking so much time to consider my opinion, even when I'm
just a simple user. I understand your position, and I agree that trying
to get the bosses to accept a beta software in production is hard (me
myself had to deal with that).
I'm the first to support the RC release as long as you feel it's time to
move ahead, all of you know what a great software you have and I just
expressed a concern without much knowledge of the status of the code.
Thanks again, I'll keep in touch, trying every release and sharing my
experience.
Regards,

Juan Pablo Lorier
Denis Cardon
2012-08-17 13:00:06 UTC
Permalink
Hi Juan,
Post by Juan Pablo Lorier
First my apologies as I know this threat is not for users, but I just
wanted to add an "outside" point of view.
You are doing a great job with samba4 and us, the users, are eager to
use it in our production environments, but I think that you shouldn't
rush to the RC before having fixed some mayor (at my point of view)
features as many users will be encouraged to get samba running and they
may disappoint after having issues or even corruption of their
production environments.
a sysadmin ought to read the release notes before deployement. Otherwise
he should stick to the "buy and click" kind of software so he may
harrass some tech support when he will have screwed up his network.

I have been using samba4 in non-critical production environement for a
year (3 primary schools, 2 libraries, 3 SMBs, total around 90 windows
workstations) with only a few minor hiccups.

And with the project going forward, everything is going so smoothly now
that one can get an AD setup by just typing apt-get samba4, modifying 2
files and lauching one command line...

Proposing an infrastructure with software that is tagged as "Beta" is
not an easy sale, even if stability is well tested and rock solid in
simple target setup (no replication, no forest, etc.). I'm eager to see
this great samba4 project going to RC then to Release so that it becomes
and easy sell for SMBs and then larger networks.

Granted I always setup a separate samba3 member server for file and
print service, but in a world where virtualisation is ubiquitous, it
should not make a sysadmin afraid (at least not the sysadmin that would
deploy an AD).

Cheers,

Denis
Post by Juan Pablo Lorier
In my opinion, an RC should be for a product that you have almost
completed and need more testing to get new bugs you just missed, but at
this time, you already have many important bugs waiting to get time to
be fixed.
I'm trying to get samba to substitute windows but domain controller is
not working properly yet, so I'm not even trying to test s3fs just to
pile up more problems. But I'm a fun of your work and I'll keep trying
until I'll get it working, others may not have such enthusiasm and just
think "this doesn't work, I'm not wasting time... let's keep windows".
Again, just an user's opinion.
Regards,
Juan Pablo Lorier
PS: I'll be back from vacation next week and I'll try this new betas :-)
--
Denis Cardon
Tranquil IT Systems
44 bvd des pas enchant?s
44230 Saint S?bastien sur Loire
tel : +33 (0) 2.40.97.57.57
http://www.tranquil-it-systems.fr
Juan Pablo Lorier
2012-08-17 17:14:47 UTC
Permalink
Hi Denis,

Glad to hear your experience with samba 4, just let me tell you that
I've been trying to set it to work aside a couple of windows DCs keeping
all the domain intact until I can securely turn of windows and I've been
unable to get it to work (most likely for I'm no so qualified as I
should, though I'm not a rookie) and have talked to others users that
had problems too. I'm also aware that many people managed to get it to
work, but maybe they have other scenarios, some I know just started with
a brand new domain, which I can't as I've have to deal with a company
with over 100 hosts and almost 200 users.
Anyway, nothing further to my intentions than criticizing Samba, I'm a
huge fun and I'm really enthusiast of having Samba 4 asap as I've been
waiting for it for over 2 years now, but I felt the need to show my
concerns.
There's no point in having a final release that you may "sell" and after
selling it you have to deal with problems that create a bad image of the
product. Again, I'm not up to date with the betas as I'm not in the
office, I need to try all the hard work the team has managed to offer us
in fixing and improving the product.
Hope I could get to explain myself, don't want to create noise in a list
meant for technical contribution.
Regards,

Juan Pablo Lorier
Post by Denis Cardon
Hi Juan,
Post by Juan Pablo Lorier
First my apologies as I know this threat is not for users, but I just
wanted to add an "outside" point of view.
You are doing a great job with samba4 and us, the users, are eager to
use it in our production environments, but I think that you shouldn't
rush to the RC before having fixed some mayor (at my point of view)
features as many users will be encouraged to get samba running and they
may disappoint after having issues or even corruption of their
production environments.
a sysadmin ought to read the release notes before deployement.
Otherwise he should stick to the "buy and click" kind of software so
he may harrass some tech support when he will have screwed up his
network.
I have been using samba4 in non-critical production environement for a
year (3 primary schools, 2 libraries, 3 SMBs, total around 90 windows
workstations) with only a few minor hiccups.
And with the project going forward, everything is going so smoothly
now that one can get an AD setup by just typing apt-get samba4,
modifying 2 files and lauching one command line...
Proposing an infrastructure with software that is tagged as "Beta" is
not an easy sale, even if stability is well tested and rock solid in
simple target setup (no replication, no forest, etc.). I'm eager to
see this great samba4 project going to RC then to Release so that it
becomes and easy sell for SMBs and then larger networks.
Granted I always setup a separate samba3 member server for file and
print service, but in a world where virtualisation is ubiquitous, it
should not make a sysadmin afraid (at least not the sysadmin that
would deploy an AD).
Cheers,
Denis
Post by Juan Pablo Lorier
In my opinion, an RC should be for a product that you have almost
completed and need more testing to get new bugs you just missed, but at
this time, you already have many important bugs waiting to get time to
be fixed.
I'm trying to get samba to substitute windows but domain controller is
not working properly yet, so I'm not even trying to test s3fs just to
pile up more problems. But I'm a fun of your work and I'll keep trying
until I'll get it working, others may not have such enthusiasm and just
think "this doesn't work, I'm not wasting time... let's keep windows".
Again, just an user's opinion.
Regards,
Juan Pablo Lorier
PS: I'll be back from vacation next week and I'll try this new betas :-)
Andrew Bartlett
2012-08-21 21:48:53 UTC
Permalink
I'm starting to feel really good about how Samba 4.0 is coming along.
We have addressed the major memory leaks, and I am about to push changes
to have us use posix ACLs during the AD provision, which was for me the
most important remaining issue.

Therefore, I would like to propose releasing Samba 4.0 RC1 on Sept 4.

Between now and then I would like to:
- Work with Karolin to see how I can be of assistance to her during
this RC series and if the date is OK for her schedule.
- Fix the configure tests for quotas not to require librpc
- Implement the remaining ACL/quota configure tests in WAF
- Discuss removing the PIDL and perl pre-generation in autogen.sh (once
configure doesn't need it)
- Add running (a hopefully reduced) ./autogen.sh to the waf dist
process
- Add docs to the waf dist process
- consider removing the alpha13 provision (used in a test) from the
release tarball due to space requirements
- Ensure that the new release scripts are sufficient for a correct
autoconf build
- Adding startup inhibitors for running samba/smbd/nmbd/winbind in the
incorrect roles.

If someone else could take on:
- Adding at least initial manpages for any currently undocumented
binaries
- Moving provision into samba-tool domain provision if we don't want to
document it separately.
- Triaging the 'blocker' bugs on
https://bugzilla.samba.org/show_bug.cgi?id=8622 into those we can fix,
and those we can't plausibly fix.
or working with me on any of the above it would be most, most helpful.

This is a lot of work for 2 weeks, but I want to avoid doing it in the
week before SDC as that will be busy with preparation for travel.

Thanks,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Stefan (metze) Metzmacher
2012-08-23 08:17:57 UTC
Permalink
Hi Andrew,
Post by Andrew Bartlett
I'm starting to feel really good about how Samba 4.0 is coming along.
We have addressed the major memory leaks, and I am about to push changes
to have us use posix ACLs during the AD provision, which was for me the
most important remaining issue.
Therefore, I would like to propose releasing Samba 4.0 RC1 on Sept 4.
- Work with Karolin to see how I can be of assistance to her during
this RC series and if the date is OK for her schedule.
- Fix the configure tests for quotas not to require librpc
- Implement the remaining ACL/quota configure tests in WAF
- Discuss removing the PIDL and perl pre-generation in autogen.sh (once
configure doesn't need it)
- Add running (a hopefully reduced) ./autogen.sh to the waf dist
process
- Add docs to the waf dist process
- consider removing the alpha13 provision (used in a test) from the
release tarball due to space requirements
- Ensure that the new release scripts are sufficient for a correct
autoconf build
- Adding startup inhibitors for running samba/smbd/nmbd/winbind in the
incorrect roles.
We really need initial support for durable handles in RC1!

I'm working hard to get the patches ready, but until September 4th there
only 5 days in the office for me.
Post by Andrew Bartlett
- Adding at least initial manpages for any currently undocumented
binaries
- Moving provision into samba-tool domain provision if we don't want to
document it separately.
- Triaging the 'blocker' bugs on
https://bugzilla.samba.org/show_bug.cgi?id=8622 into those we can fix,
and those we can't plausibly fix.
or working with me on any of the above it would be most, most helpful.
If possible we should add some magic that rejects to work as AD DC in a
domain
which also has Windows DCs. As that can't work as SYSVOL replication
isn't supported
and we could also corrupt the Windows database if we send replication
notifications
while a windows dc is currently replicating from us. (We could have an
option to
allow this, but that should be off similar to the "dsdb:schema update
allowed"
option.
Post by Andrew Bartlett
This is a lot of work for 2 weeks, but I want to avoid doing it in the
week before SDC as that will be busy with preparation for travel.
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120823/6d0c1fbb/attachment.pgp>
Andrew Bartlett
2012-08-23 10:07:08 UTC
Permalink
Post by steve
Hi Andrew,
Post by Andrew Bartlett
I'm starting to feel really good about how Samba 4.0 is coming along.
We have addressed the major memory leaks, and I am about to push changes
to have us use posix ACLs during the AD provision, which was for me the
most important remaining issue.
Therefore, I would like to propose releasing Samba 4.0 RC1 on Sept 4.
- Work with Karolin to see how I can be of assistance to her during
this RC series and if the date is OK for her schedule.
- Fix the configure tests for quotas not to require librpc
- Implement the remaining ACL/quota configure tests in WAF
- Discuss removing the PIDL and perl pre-generation in autogen.sh (once
configure doesn't need it)
- Add running (a hopefully reduced) ./autogen.sh to the waf dist
process
- Add docs to the waf dist process
- consider removing the alpha13 provision (used in a test) from the
release tarball due to space requirements
- Ensure that the new release scripts are sufficient for a correct
autoconf build
- Adding startup inhibitors for running samba/smbd/nmbd/winbind in the
incorrect roles.
We really need initial support for durable handles in RC1!
I'm working hard to get the patches ready, but until September 4th there
only 5 days in the office for me.
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.

Is there anything I can do to assist with this?

More broadly, one of the biggest challenges for but also the biggest
achievement of the Samba 4.0 release process is bringing our two major
development strands together into a single release. We have much to be
proud of!

That our synchronization on a first-suggestion date for RC1 is only off
by a few days or a week is pretty impressive, and I'm sure we can work
it out.

Given the feedback earlier, I think it's best that we do the RC before
SDC. That way, we can focus on testing what features we have, not
adding the next major feature to this particular release.
Post by steve
If possible we should add some magic that rejects to work as AD DC in a
domain
which also has Windows DCs. As that can't work as SYSVOL replication
isn't supported
and we could also corrupt the Windows database if we send replication
notifications
while a windows dc is currently replicating from us. (We could have an
option to
allow this, but that should be off similar to the "dsdb:schema update
allowed"
option.
This is the first I've heard of this. Can you explain more about the
corruption you fear?
Post by steve
Post by Andrew Bartlett
This is a lot of work for 2 weeks, but I want to avoid doing it in the
week before SDC as that will be busy with preparation for travel.
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).

Thanks,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Stefan (metze) Metzmacher
2012-08-23 19:11:05 UTC
Permalink
Hi Andrew,
Post by Andrew Bartlett
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.
Is there anything I can do to assist with this?
More broadly, one of the biggest challenges for but also the biggest
achievement of the Samba 4.0 release process is bringing our two major
development strands together into a single release. We have much to be
proud of!
Indeed!
Post by Andrew Bartlett
That our synchronization on a first-suggestion date for RC1 is only off
by a few days or a week is pretty impressive, and I'm sure we can work
it out.
yes :-)
Post by Andrew Bartlett
Given the feedback earlier, I think it's best that we do the RC before
SDC. That way, we can focus on testing what features we have, not
adding the next major feature to this particular release.
Post by Stefan (metze) Metzmacher
If possible we should add some magic that rejects to work as AD DC in a
domain
which also has Windows DCs. As that can't work as SYSVOL replication
isn't supported
and we could also corrupt the Windows database if we send replication
notifications
while a windows dc is currently replicating from us. (We could have an
option to
allow this, but that should be off similar to the "dsdb:schema update
allowed"
option.
This is the first I've heard of this. Can you explain more about the
corruption you fear?
While doing migrations from samba3 to windows via samba4, it was
needed to disable (at least) the drepl service in samba4.

What happened is this you add about 5000 computers, 5000 users and 5000
groups
and about 10000 groupmemberships to the samba4 ldb
(after a vampire run, but before starting 'samba')

Then you start 'samba', as the replication of this amount of objects/links
takes some time, it's very likely that some local task in 'samba' triggers
a modification to the domain ldb file. This is picked up by our drepl task
which sends a notification to the windows dc, which is currently within
a replication cycle with our drsuapi task.

This somehow confuses the windows (at least 2008R2) dc, It cancels the
running
replication cycle and starts a new one (but with the wrong meta data!)
All objects/links which were pending in the running replication cycle
are lost
and they won't ever be replicated to the windows dc, as he believes that
they're already replicated.

I was able to reproduce this and disabling the 'drepl' task fixed it.
I used samba-tool ldapcmp to compare the servers.
Post by Andrew Bartlett
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
This is a lot of work for 2 weeks, but I want to avoid doing it in the
week before SDC as that will be busy with preparation for travel.
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).
Let's see where we are next week.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120823/f7162123/attachment.pgp>
Andrew Bartlett
2012-08-23 20:44:17 UTC
Permalink
Post by steve
Hi Andrew,
Post by Andrew Bartlett
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.
Is there anything I can do to assist with this?
More broadly, one of the biggest challenges for but also the biggest
achievement of the Samba 4.0 release process is bringing our two major
development strands together into a single release. We have much to be
proud of!
Indeed!
Post by Andrew Bartlett
That our synchronization on a first-suggestion date for RC1 is only off
by a few days or a week is pretty impressive, and I'm sure we can work
it out.
yes :-)
Post by Andrew Bartlett
Given the feedback earlier, I think it's best that we do the RC before
SDC. That way, we can focus on testing what features we have, not
adding the next major feature to this particular release.
Post by Stefan (metze) Metzmacher
If possible we should add some magic that rejects to work as AD DC in a
domain
which also has Windows DCs. As that can't work as SYSVOL replication
isn't supported
and we could also corrupt the Windows database if we send replication
notifications
while a windows dc is currently replicating from us. (We could have an
option to
allow this, but that should be off similar to the "dsdb:schema update
allowed"
option.
This is the first I've heard of this. Can you explain more about the
corruption you fear?
While doing migrations from samba3 to windows via samba4, it was
needed to disable (at least) the drepl service in samba4.
What happened is this you add about 5000 computers, 5000 users and 5000
groups
and about 10000 groupmemberships to the samba4 ldb
(after a vampire run, but before starting 'samba')
Then you start 'samba', as the replication of this amount of objects/links
takes some time, it's very likely that some local task in 'samba' triggers
a modification to the domain ldb file. This is picked up by our drepl task
which sends a notification to the windows dc, which is currently within
a replication cycle with our drsuapi task.
This somehow confuses the windows (at least 2008R2) dc, It cancels the
running
replication cycle and starts a new one (but with the wrong meta data!)
All objects/links which were pending in the running replication cycle
are lost
and they won't ever be replicated to the windows dc, as he believes that
they're already replicated.
I was able to reproduce this and disabling the 'drepl' task fixed it.
I used samba-tool ldapcmp to compare the servers.
Thanks for the details. Sorting this out sounds like a perfect task for
the IO Lab with Microsoft. Do you happen to still have a test script to
make the broken domain?

Did you try and fix the windows domain using drepl commands
(/fullsync?)?
Post by steve
Post by Andrew Bartlett
Post by Stefan (metze) Metzmacher
Post by Andrew Bartlett
This is a lot of work for 2 weeks, but I want to avoid doing it in the
week before SDC as that will be busy with preparation for travel.
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).
Let's see where we are next week.
Thanks,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Michael Adam
2012-08-23 21:43:01 UTC
Permalink
Post by steve
Hi Andrew,
Post by Andrew Bartlett
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.
Is there anything I can do to assist with this?
[...]
Post by Stefan (metze) Metzmacher
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).
Let's see where we are next week.
Yeah, let's aim for Sep 7 (with a fallback to 10). This gives us
a couple of additional days, and I am positive we can sort it out.
As I wrote in the other thread, I think it should be ok to do the
RC1 as you did the betas, Andrew - the important thing is the
change in mode once the RC1 has been cut.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120823/0882a9bb/attachment.pgp>
Alexander Bokovoy
2012-08-23 21:53:08 UTC
Permalink
Post by Michael Adam
Post by steve
Hi Andrew,
Post by Andrew Bartlett
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.
Is there anything I can do to assist with this?
[...]
Post by Stefan (metze) Metzmacher
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).
Let's see where we are next week.
Yeah, let's aim for Sep 7 (with a fallback to 10). This gives us
a couple of additional days, and I am positive we can sort it out.
As I wrote in the other thread, I think it should be ok to do the
RC1 as you did the betas, Andrew - the important thing is the
change in mode once the RC1 has been cut.
I agree.

I'm going to work on the doc issues to minimize effect of older
environments though it might take more time than we have for RC1.

I also need to finish private libraries ABI patches that are cooking
in https://git.samba.org/?p=ab/samba.git/.git;a=shortlog;h=refs/heads/stableabi,
more on which on Monday.
--
/ Alexander Bokovoy
Andrew Bartlett
2012-08-27 23:04:48 UTC
Permalink
Post by Alexander Bokovoy
Post by Michael Adam
Post by steve
Hi Andrew,
Post by Andrew Bartlett
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.
Is there anything I can do to assist with this?
[...]
Post by Stefan (metze) Metzmacher
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).
Let's see where we are next week.
Yeah, let's aim for Sep 7 (with a fallback to 10). This gives us
a couple of additional days, and I am positive we can sort it out.
As I wrote in the other thread, I think it should be ok to do the
RC1 as you did the betas, Andrew - the important thing is the
change in mode once the RC1 has been cut.
I agree.
I'm going to work on the doc issues to minimize effect of older
environments though it might take more time than we have for RC1.
I also need to finish private libraries ABI patches that are cooking
in https://git.samba.org/?p=ab/samba.git/.git;a=shortlog;h=refs/heads/stableabi,
more on which on Monday.
Thanks for the heads up. In return, I would like to flag that I would
like to talk about these, to make sure I understand exactly what is
linking against private libs and what promises we are making.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Michael Adam
2012-09-06 15:57:11 UTC
Permalink
Hi Andrew,

we are currently shortly before finishing the durable handle and
SMB3 code we have been working on hard recently.

There are a couple of cleanups and details left that we are
currently erasing, so could we please use the fallback date
(early next week) for the RC1 instead of tomorrow (sep 7).

Thanks - Michael
Post by Michael Adam
Post by steve
Hi Andrew,
Post by Andrew Bartlett
I agree this is a key feature, as durable handles are a major part of
what is really special in SMB3.
Is there anything I can do to assist with this?
[...]
Post by Stefan (metze) Metzmacher
Maybe we should aim for September 7th? Which would mean 3 additional
days for me.
But still I can't promise that it's ready by then.
I'm happy with Sep 7 or Sep 10 (at the latest) if Karolin is happy with
me doing the RC1. (That close to SDC, I would prefer to just handle it
with existing processes and scripts personally than also co-ordinate it
with someone else).
Let's see where we are next week.
Yeah, let's aim for Sep 7 (with a fallback to 10). This gives us
a couple of additional days, and I am positive we can sort it out.
As I wrote in the other thread, I think it should be ok to do the
RC1 as you did the betas, Andrew - the important thing is the
change in mode once the RC1 has been cut.
Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120906/2f878408/attachment.pgp>
Andrew Bartlett
2012-09-06 21:59:38 UTC
Permalink
Post by steve
Hi Andrew,
we are currently shortly before finishing the durable handle and
SMB3 code we have been working on hard recently.
There are a couple of cleanups and details left that we are
currently erasing, so could we please use the fallback date
(early next week) for the RC1 instead of tomorrow (sep 7).
Sounds good to me!

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Andreas Schneider
2012-08-23 10:34:35 UTC
Permalink
Post by Andrew Bartlett
- Add docs to the waf dist process
I can help you with that next week.
Post by Andrew Bartlett
- Adding at least initial manpages for any currently undocumented
binaries
- Moving provision into samba-tool domain provision if we don't want to
document it separately.
- Triaging the 'blocker' bugs on
https://bugzilla.samba.org/show_bug.cgi?id=8622 into those we can fix,
and those we can't plausibly fix.
or working with me on any of the above it would be most, most helpful.
I will look into printing stuff next week and get the tests working.


-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
Samba Team asn at samba.org
www.samba.org
Andrew Bartlett
2012-08-23 10:45:07 UTC
Permalink
Post by Andreas Schneider
Post by Andrew Bartlett
- Add docs to the waf dist process
I can help you with that next week.
Thanks!

Have a look at how I now add the .distversion file - it shows how we can
generate files during 'waf dist' (just os.system should be fine to run
the script) and how we can include them at the end of the tarball.
Post by Andreas Schneider
Post by Andrew Bartlett
- Adding at least initial manpages for any currently undocumented
binaries
- Moving provision into samba-tool domain provision if we don't want to
document it separately.
- Triaging the 'blocker' bugs on
https://bugzilla.samba.org/show_bug.cgi?id=8622 into those we can fix,
and those we can't plausibly fix.
or working with me on any of the above it would be most, most helpful.
I will look into printing stuff next week and get the tests working.
Thanks. It really should be just a matter of fixing the config written
out in file_server/file_server.c to have the right stuff in it.

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Continue reading on narkive:
Loading...