Glue Pipe dependencies
abartlet at pcug.org.au
Wed Jan 9 23:47:02 GMT 2002
I've been thinking about what things need to be done before the proposed
'glue pipes' become a reality. (For the archives: This is the proposed
mechisim to allow TNG style RPC deamons to work on a Samba HEAD smbd).
I think its a great idea, as it must be a *hell* of a job maintaining
TNG, and I want it to be as easy as possible for people to do
The dependencies I can see are as follows:
Boring stuff (ie not done yet, but also pretty simple):
- generic module loading in samba
- allow modules to take over pipes
- supply modules with critical data (part lm hash, session key etc)
I'm looking at making this practical for other reasons, much in the
way TNG carts around an info3 on the vuid (it won't be an info3, but it
will have the required info).
- per-pipe module registration.
- glue pipe module
At this point an outside developer should be able to register their
module/pipe and it should 'just work'.
However, the modules people are interested in are from Samba-TNG, things
like netlogond, samrd, etc... Here the dependencies begin to bite...
We need a few things in HEAD before most of these modules become any use
- tng_netlogond auth module.
This is an authentication module that does the same job as
'ask_local_netlogond' does in TNG. Without this, both HEAD and TNG
would have to use the same smbpasswd file - it would be a mess.
Possible alternative is to do normal domain_client_validate() over
TCP/IP but I prefer this.
- plugable password change mechisnm.
If you use Samba-TNG's netlogond, you must also use TNG's samrd (as
far as I can tell, please correct me otherwise). This certainly means
that password changes can't occur direct to HEAD's passdb. TNG has a
mechanism to this, and a similar one (possibly based/modeled/dependent
on the auth subsystem) needs to be written in HEAD.
- lanman.c stuff. Many of the lanman.c functions depend on data that
might be locked on the other side of the split.
- and a pile of things I can't think of - TNG is a separate project
(rather than a minor patch) for a very good reason
I suppose the point is that while it will be fairly sane for new pipes,
pipes (and functionality) already implemented in HEAD could prove
difficult to replace. However, I feel its worth it and I'll do what I
can to allow this to happen.
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical