svn commit: lorikeet r177 - in trunk/white-papers: .
vance at samba.org
vance at samba.org
Sat Jan 8 23:01:12 GMT 2005
Author: vance
Date: 2005-01-08 23:01:11 +0000 (Sat, 08 Jan 2005)
New Revision: 177
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=lorikeet&rev=177
Log:
More minor changes.
Vance
Modified:
trunk/white-papers/samba3-samba4.lyx
Changeset:
Modified: trunk/white-papers/samba3-samba4.lyx
===================================================================
--- trunk/white-papers/samba3-samba4.lyx 2005-01-08 11:49:45 UTC (rev 176)
+++ trunk/white-papers/samba3-samba4.lyx 2005-01-08 23:01:11 UTC (rev 177)
@@ -293,7 +293,8 @@
3.0 to be launched to handle the file storage requirements of a Samba4 share
connection.
The purpose of this patch was to demonstrate the capabilities of Samba4,
- but also to avoid the fact that, at that stage, Samba4 would perform all
+ but also to allow file serving using the same user contexts as Samba 3.0
+ since Samba4, at that early stage, performed all
operations as root and lacked a full mapping of expected CIFS features.
At the time, this seemed to be an issue that would be a long time in the
fixing.
@@ -335,7 +336,7 @@
Merging code-bases is perhaps one of the hardest tasks in software development,
particularly when they have diverged in the way that Samba 3.0 and Samba4
have.
- Samba4 branched off the same code-base in early 2003, and has been radically
+ Samba4 branched off the same code-base in early 2003 and has been radically
rewritten since.
Perhaps more troubling in the merge process were the less radical rewrites,
with lots of simple changes to function arguments proving a frustration
@@ -355,56 +356,58 @@
The integration of the Samba 3.0 Winbind client into Samba4, with its associated
authentication module has been a success.
- This is partly because the Winbind interface is comparatively stable, and
- the addition of an authentication module is very unobtrusive.
+ This is partly because the Winbind interface is relatively stable and
+ partly because the addition of an authentication module is very unobtrusive.
The module allowed the demonstration and testing of Samba4's
\family typewriter
ntlm_auth
\family default
utility (which was otherwise very hard to test without backing to a Windows
- 2003 domain), as well as development of parts of the code required for
- domain membership.
+ 2003 domain). The Winbind module also enabled development of parts of the
+ code required for domain membership.
However, by providing a solution to immediate issues of domain membership,
- it made the construction of a real solution less urgent, and less of a
- priority.
+ it made the construction of a real solution less urgent, and therefore less
+ of a priority.
\layout Subsubsection*
-smbtorture application to Samba4
+smbtorture Application to Samba4
\layout Standard
In rather a different way to the other approaches described in this document,
the Samba4 smbtorture utility has become `intergrated' as the de-facto
testing tool for Samba 3.0.
- As such, it has been a great success, with short-term issues of correctness
- patched up in Samba 3.0, which everybody agrees will still be in production
- sites for some time to come.
+ In this role it has been a great success, prompting fixes for short-term
+ issues of correctness to Samba 3.0. While Samba4 is progressing very rapidly,
+ everybody agrees that Samba 3.0 will still be in production sites for some
+ time to come, meaning Samba4's smbtorture has and will continue to improve
+ the quality of Samba 3.0.
\layout Standard
Likewise, the IDL generated by the Samba4 product has been used to correct
defects in the hand-generated Samba 3.0 code.
While this practice can be continued long-term, it is very human-resource
- intensive, because of the manual translation process.
+ intensive because of the manual translation process.
\layout Subsubsection*
-Kerberos code merge
+Kerberos Code Merge
\layout Standard
In October 2004, work was undertaken in the Samba 3.0 code branch that drasticall
y improved the reliability of the Kerberos code, in particular when faced
with salted encryption types.
- This work was done originally by RedHat, and merged by Jeremy Allison into
+ This work was done originally by RedHat and merged by Jeremy Allison into
Samba 3.0.
Because Samba 3.0's Kerberos code was copied and kept largely intact in
- Samba4, Andrew Bartlett successfully merged this code into Samba4, in Dec
- 2004 / Jan 2005.
+ Samba4, Andrew Bartlett was able to successfully merged this code into Samba4
+ in December 2004 / January 2005.
\layout Section*
-Ideas for Samba 3.0 / Samba4 integration
+Ideas for Samba 3.0 / Samba4 Integration
\layout Subsection*
-Named Pipe redirection
+Named Pipe Redirection
\layout Standard
This is perhaps the oldest suggestion regarding Samba and RPC services.
@@ -413,11 +416,11 @@
This, it is argued, would allow each named pipe to be developed separately
and in parallel, with a faster overall result.
Unfortunately, for core RPC services this soon becomes an `all or nothing'
- proposition - all of the core RPC pipes must be handled together, and a
+ proposition; all of the core RPC pipes must be handled together, and a
matching authentication module written.
Also, issues surrounding SID/UID mappings must usually also be handled
- by the same integrated back-end, and the LANMAN pipe (used by OS/2 and
- Win9X clients) must be explicitly handled.
+ by the same integrated back end, and the LANMAN pipe (used by OS/2 and
+ Windows 9x clients) must be explicitly handled.
\layout Subsubsection*
Authentication
@@ -426,10 +429,10 @@
It should be noted that redirection of incoming PDUs on named pipes is not
as simple as simply forwarding datagrams, as there is a significant amount
of state that is inherited from the CIFS level connection.
- Correctly handling this state transfer has for the XAD and Samba-TNG cases
+ Correctly handling this state transfer has, for the XAD and Samba-TNG cases,
been done by an `out of band' mechanism, or by prefixing it to the first
message.
- In either case, details such as user identity, groups and session keys
+ In either case, details such as user identity, groups, and session keys
must be communicated and accepted.
\layout Subsubsection*
@@ -439,7 +442,7 @@
All this is possible, and it should indeed be possible to hand off named
pipes from Samba 3.0 to Samba4 in the same way that a patched Samba 3.0 hands
off pipes to XAD.
- However, there seems to be little benefit - Samba4 already includes a mature
+ However, there seems to be little benefit: Samba4 already includes a mature
file-server, and as such a Samba 3.0 integration project of this type seems
to add little of value.
\layout Subsubsection*
@@ -452,7 +455,7 @@
a known RPC server.
This is more interesting, until Samba4 surpasses Samba 3.0 in RPC function,
but will require some effort to correctly handle UID mappings (which are
- tightly integrated with ldb in samba4).
+ tightly integrated with ldb in Samba4).
\layout Subsection*
LDB integration efforts
@@ -471,27 +474,27 @@
Perhaps the most interesting LDB related integration idea is that Samba4
would re-implement the SamSync `vampire' code, and place the results in
an structured LDB.
- This could then be extracted to LDIF, and munged into a format compatible
+ This could then be extracted to LDIF and munged into a format compatible
with the Samba 3.0 LDAP schema, or one of the other compatible passdb back-ends.
\layout Subsubsection*
pdb_ldb
\layout Standard
-The proposal here is that Samba 3.0 will use it's standard LDAP libraries
+The proposal here is that Samba 3.0 will use its standard LDAP libraries
to talk to a ldapi:// LDAP server, which is in fact Samba4, running the
Samba4 ldb schema.
- This will allow Samba4 to update the database in it's native format, and
+ This will allow Samba4 to update the database in its native format and
Samba 3.0 to read it.
\layout Subsection*
Winbind replacement
\layout Standard
-The winbind interface is very interesting, because of it's relative stability,
+The winbind interface is very interesting because of it's relative stability
and the fact that it is largely an interface to external programs.
- As such, it is possible to conceive that Samba 3.0 or Samba4 could provide
- this interface, in a useful way.
+ As such, it is possible to conceive that either Samba 3.0 or Samba4 could
+ provide this interface.
\layout Subsubsection*
Samba 3.0 Winbindd for Samba4
@@ -499,7 +502,7 @@
As Samba4 matures, it is reaching the stage where it would be quite practical
to treat it as an external domain controller (even if on the same machine),
- and have winbindd provide accounts to POSIX, and perform the other duties
+ and have winbindd provide accounts to POSIX, while performing the other duties
typically assigned to it.
This may bridge the gap between Samba4's ldb implementation of user details,
and the POSIX world's expectation of user and group behaviour.
@@ -508,23 +511,25 @@
Samba4 Winbindd for Samba 3.0
\layout Standard
-Samba4 has many advantages in the construction of a Winbind deamon, particularly
- in it's asynchronous nature.
+Samba4 has many advantages in the construction of a Winbind daemon particularly
+ in its asynchronous nature.
While not all calls are available asynchronously at the remote end, it
is very attractive to consider that the local system should not block waiting
for each and every one of them.
- A winbindd compatible with Samba 3.0's file-serving and DC logic could be
- constructed, and 'dropped in' to the otherwise existing Samba 3.0 infrastructure.
+ A winbindd compatible with Samba 3.0's file-serving and domain-control logic
+ could be constructed, and 'dropped in' to the otherwise existing Samba 3.0
+ infrastructure.
\layout Section*
-Perhaps no integration at all?
+Perhaps No Integration at All?
\layout Standard
-The final option this paper must explore is that of no integration, and
- simply the completion of Samba4 along it's current development path.
- While it it true that Samba4 has a long way to go, and it is a big change,
- the risks associated with creating products based on a hybrid are real,
+The final option that must be explored is that of no integration;
+ simply allow Samba 3.0 and Samba4 to follow along their current development
+ paths.
+ While it is true that Samba4 has a long way to go and it is a big change,
+ the risks associated with creating products based on a hybrid are real
and do need to be quantified.
In Samba 3.0 development, many vendors of products using Samba wondered
if it would be `safer' or `easier' to simply merge the aspects of Samba
@@ -538,16 +543,16 @@
development.
These vendors were able to take advantage of their position with new and
better products, using the new functionality.
- These vendors also helped particularly on QA of the new code, and were
- able to drive development in that way.
+ These vendors also helped particularly on quality assurance of the new code,
+ and were able to drive development in that way.
\layout Standard
-Samba4 promises to be the same - while Jeremy and others (particularly those
+Samba4 promises to be the same; while Jeremy and others (particularly those
contracted to `enterprise' customers) will almost certainly continue to
`fix' Samba 3.0 as best as they can, the Samba4 development program will
provide new and significant functionality, that will simply not be available
on the old platform.
- While it may be tempting to try and back-port functionality, the efforts
+ While it may be tempting to try and back-port functionality, the efforts
that appear viable are those that put as much arms-length between the two
branches.
\layout Standard
More information about the samba-cvs
mailing list