SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[Nicolas Williams]

On Tue, Feb 08, 2000 at 11:30:53PM +0100, Jean Francois Micouleau wrote:
> 
> On Wed, 9 Feb 2000, Nicolas Williams wrote:
> 
> >  - SYSKEY
> > 
> >    I'm now for it as Luke's LDAP/NIS/other name services argument is a
> >    winning one. The /etc/shadow approach should still be supported and
> >    used where no such cleartext protocols are in use.
> 
> Everyone has a point of view :)

Heh!

> >  - TNG code freeze
> > 
> >    Don't do it yet; wait a few more weeks. So much progress is taking
> >    place that it seems worthwhile to wait a bit longer.
> 
> NO. freeze Now ! I know Luke well enough to say that if you leave him just
> a week, he will have a new idea he'll want to code. Of course if you have
> spent more than an afternoon on his roof then you know him better than I
> :-)

Yes, but I wanted to give Luke a chance to settle the PID/VUID
standard_sub_vuser stuff that's been going on in a separate thread.

That bit is important.

> >  - 2.0.x->TNG merge
> > 
> >    This should be easy, actually: take smbd code from 2.0.x as is, drop
> >    all the MSRPC code save for the loopback to MSRPC daemons code.
> 
> totally unrealistic. You know why ? Because I've done it. And give up. And
> felt some much depressed than I was close to install win95 on my machines.
> 
> Merging TNG in HEAD is not much realistic. I also tried, still have a
> tar.gz of the result somewhere.

No, no. I didn't mean merge TNG into HEAD. I meant merge 2.0.x into TNG,
and then ONLY the SMBD fileserving portions.

Think about it, Luke has already modified the head so that non-TNG SMBDs
can play with TNG MSRPC daemons! So completing the merge of head into
TNG is a simple matter of dropping the _dead_ MSRPC code in SMBD.

Pardon my naming of the various branches. I've not done any CVS
checkouts of any Samba CVS branches, so I don't know which is which...

Anyways, once that merge into TNG is done, do as someone else has
already said: make a copy of TNG and call it something else and that
branch will be the release branch and TNG will be the development branch
for it, with future TNG work being merged into the new branch in a
timely fashion.

> The only viable path is to extract features of TNG in diff files and
> incorporate by hand in HEAD.

That should work too, I guess.

> >    TNG seems to be much further ahead on the MSRPC issues, which means
> >    there's no merge to do from 2.0.x there.
> 
> wrong. the smb/rpc layer (the prs_struct structure) is much cleaner in
> HEAD. Some RPC functions have been rewritten in HEAD and must be kept.

Really?!

> >    Same thing with utilities such as rpcclient, though smbclient and
> >    nmblookup might be best taken from 2.0.x.
> 
> rpcclient yes.
> 
> > I think it's safe to say that TNG is so jam-packed with good ideas that
> > it will become the next Samba. But then, that's just a view from the
> > sidelines... others may differ on that...
> 
> it's also jam-packed with unstability and non-portability. And stability
> and portability are much more important than new features.

Yes, but the domain-related MSRPC stuff is unstable in ALL branches.
TNG's domain-related code seems to be the best, from reading these
lists. At least TNG's modular architecture is already paying off, with
more than one different implementation of the SAM RPC daemon, each with
different database backends.

The TNG modularity ought to be kept. That's the best feature by far of
TNG. But Luke must settle the PID/VUID/standard_sub_vuser stuff soon.

> 	J.F.


Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.