outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Sun, Dec 12, 2004 at 11:19:39AM +1100, tridge at samba.org wrote:
> Luke,
> 
>  >  tridge - please excuse me for mentioning this but after
>  >  _everything_ you said that i wasn't "allowed" to do because
>  >  of various detailed technical descriptions, 
> 
> Your memory of past events gets more and more twisted every year. As I

 no, it doesn't

> explained in great detail to you at the time, the problem with your
> proposal was not the fact that it added a new transport, but the
> _method_ you proposed for implementing it. Do you even remember your
> design any more? 

 yes - and it has very little to do with smbd:

 there are two critical juncture points at which data is "outsourced"
 from smbd and it becomes nothing to do with smbd any more:
 1) a namedpipe transport 2) security=server being used all
 the time - including for security=user.

 
> It involved nasty static variable hacks, 

 not in smbd it didn't.

 from the smbd perspective, which was all i was concerned about,
 it involved exactly the simple, _simple_ patch that anthony
 has submitted last week.

 if you had accepted that in 2000 - and we did begin on
 something like it when we were at no 24 marcus clarke st,
 but we got distracted by winbindd with tim - then i would have
 been able to use the services from the samba ntdom project /
 cvs branch in combination with the smbd from cvs main or even
 samba 2.0.

 ... and history would be completely different.

 ... i think where i failed was to be able to deal with anything
 other than black or white.

 in particular, i believe i initially proposed that the _whole_
 architecture be accepted or at least the status raised somehow.

 when you said "no" i then started to think of ways to move one
 component at a time.

 ... but every time i approached you, i believe you were still
 under the impression that i was advocating an all-or-nothing
 approach, and where i failed was that i didn't clearly
 emphasise enough to you just how critical, simple and
 non-intrusive adding the namedpipe transport is.



> making the
> code essentially untestable as a function could not be relied upon to
> perform the same way twice.
 
 i genuinely don't recall you mentioning any objections about static
 variables to me.

 i assume you are referring to the optimisation of the msrpc client 
 library, which was based on the "NET.EXE USE" principle?

 if that was all your objections were, i could have easily
 disabled that or made it a parameter!




>  > NOW you add in a ncalrpc transport into samba 4 and because it's
>  > you adding it, it's suddenly acceptable??
>  > 
>  >  ... did i miss something?
> 
> yes, you missed the fact that it wasn't me who added it. It was
> Jelmer. He proposed a clean interface, he thought through all the
> design issues, and he showed good prototype code and he then asked if
> he could add it. I reviewed his proposal in the same way I reviewed
> your proposals and this time I was convinced it was a good design. I
> did initially reject some aspects of it, but Jelmer addressed my
> concerns. Jelmers implemention is excellent.

 great, i am genuinely pleased.  having an ncalrpc interface is
 a really essential optimisation which allows separate services
 to communicate much more rapidly
 
 and, hopefully, securely (as root-only-accessible).

 even though it was slow, and even though you don't approve of the
 design or the implementation, the samba tng ncalrpc interface made
 the whole samba tng architecture _possible_.


 it also means that various services that implement the ncalrpc
 inter-communication mechanism will be able to interoperate, both you
 and users will be able to swap out services for testing purposes or
 even because one service has more complete features, use it in
 production environments.


> It is my job as project leader to decide if a proposal is good or
> not. 

 yes. it is.  for a given value of good.

 it is also your job to understand the big picture, which
 in 2000 you most certainly did not, and to make use of and
 encourage and teach and develop what talent and resources
 you have available at the time, which you most certainly did not.

 it is also your job to assess and weigh technical and strategic
 options - to not reject code that has vital strategic value
 because of controversial technical grounds [you successfully
 made such a decision for both nmbd and the msrpc client-side
 library that was needed for winbind], and to mitigate against
 any technical deficiencies of code introduced by making all
 options [the good, the bad and the ugly] available at runtime
 if possible, with Big Warnings about which is which.

 it's _not_ your job to squash talent or possibilities because
 you happen not to understand or agree with them, but instead
 to leave a path with Big Red Signs open for people to shoot
 themselves in the foot and to learn from their own visits to
 hospital.
 
 you _know_ i have a different approach to coding, so _why_
 didn't you help out, as the project leader, by putting in
 place structures, APIs and procedures that would let me carry
 on doing what i do best, eh??



> You rarely put the effort in to do a good, well thought out
> design, 

 oh, thanks.  

> so as a result a lot of your proposals were not accepted. The
> times when you did put in the effort (and there were quite a few of
> those) your code was accepted. 

 i believe that it was more a matter of demonstrably superior
 _features_ were present in code that i wrote, even with the
 nasty gribbly bits that i had - and i've always been honest
 about this once i realised that i was doing it, and have since
 made it clear many times - deliberately left until later,
 on the grounds that it was either likely that they would be
 thrown out in a redesign or if proved to be important, fixed.


 the nmbd rewrite is a good example.  i laid the groundwork
 whilst working at Pi Technology, exploring and documenting the
 network neighbourhood protocol, and i had to stop because i
 was coming in early, working for an hour and a half up until
 9:30, doing PiTech work, stopping at 5-5:30, switching the
 hard drive over and carrying on for another five hours.

 my manager asked me why i was spending so much time on an alternative
 project when i could be spending the time on PiTech work: i didn't have
 an answer, so i had to stop!

 and a couple of months later, you cut the code over to samba
 main (june, july 1996 i believe) at which point i went "shriek"
 because my PiTech deadline was august and there was so much left to
 sort out, plus i was under the watchful eye of my manager so i
 _couldn't_ help out.

 it took jeremy about ... another year to put that horrible
 gribbly code into a reasonable state, and his experiences
 with it left him - and you - scarred so badly that i could
 not propose to you or to him the design lessons i'd learned
 from working with it.

 consequently, the nmbd multiworkgroup support (1997), and
 the winsd stackable/hierarchical architecture (1998), _and_
 the NetBIOS client-side library / proxying / transport ideas
 (1999) and prototype code _all_ went to waste.



 then there's the msrpc client-side library code which was
 necessary to get winbinnd up-and-running. 


> It was not personal, or at least it wasn't personal until you started
> your public rampage of indignation that you have now persisted in for
> years.

 have a look at the winbindd's use of unix domain sockets,
 and the code in samba tng's use of unix domain sockets,
 [bearing in mind your technical objections and explanations
 that i cannot write secure code that uses unix domain sockets],
 and you will begin to see why.

 the difference between the code that you accepted and reviewed because
 you believed that it was tim who wrote it from scratch, and the code
 that you _didn't_ accept because it was written by me, is NEGLIGABLE.

 so you see, you _made_ it personal - in particular by thanking tim for
 completing winbind without even acknowledging that i had helped nor
 that it was using code i'd been developing for two-three years!

 
 after all this time, i'm just disappointed in you, even though
 the samba project - and you - are making good, if belated, progress.

 if we'd been able to compromise better, hundreds of thousands of
 companies would not still be wasting their money on what they are told
 is the only viable option - windows.

 l.