CVS update: tng/source/passdb

Andrew Bartlett abartlet at pcug.org.au
Mon Jan 7 16:05:05 GMT 2002


Luke Kenneth Casson Leighton wrote:
> 
> On Mon, Jan 07, 2002 at 03:16:05PM -0800, Andrew Tridgell wrote:
> > [lckl]
> > >  loadable module support is _not_ the way to do it.
> >
> > For those who have only just joined us the loadable module proposal
> > goes like this:
> >
> > - allow smbd to load arbitrary .so module for any pipe
> 
>  likely to be insufficient.
> 
>  see message i sent in response to jfm's message
>  describing the lm proposal, three months ago.

Do you have an archive reference? - or a one liner of what the 'lm
proposal' was?.

> > - a single .so can handle multiple pipes
> > - the .so can have its own parameters in smb.conf
> 
> > That's the basic infrastructure. Then to allow compatibility with
> > existing TNG pipes I suggested we have a single simple "glue" module
> > that is loaded into smbd and interfaces to the existing TNG pipes
> > interface. So you might have something like:
> >
> > pipe handler = *:pipe_tng_glue.so
> >
> > (meaning "for pipes that match the name * use pipe_tng_glue.so")
> >
> > or we could use symlinks in a pipe directory or whatever.
> >
> > >  "controlled" from HEAD is not the way to do it.
> >
> > well, if head is running then the packets will be going via smbd
> > code. No choice about that.
> 
>   that's not the issue.
> 
>   how can an ARBITRARY dce/rpc-based program - NOT a .so - one
>   that is UTTERLY INDEPENDENT of samba, run and register
>   itself?
> 
>   if your pipe glue deals with this issue, then i will be
>   amazed and will have finally got through to you, after just
>   over two years of very unnecessary and painful experiences.

So let me see if I have this right:

glue_pipe_smbd.so is loaded in Samba.

glub pipe helper is running, listening on its own named pipe, waiting
for simple rpc server to start.

simple rpc server starts, (built with glue pipe lib) and asks for an
interface.

glue pipe daemon enters this in tdb and creates pipe/socket, smbd picks
it up on next reload_services (gluepiped hits it with a -HUP to help
this along) and opens its end up, simple rpc server got the socket fd
back across the named pipe.  (Doesn't even need root privs -
gluepiped.conf has a simple acl for non-root daemons).

glue_pipe_smbd.so sets up the bindings and sends down the inbound
connections - with the required state info.

--snip--

> > as I've mentioned, the packets go via smbd if they are using the SMB
> > transport, so you really can't avoid a smb.conf.
> >
> > I don't imagine any of this
> > (which has been said so many times before)
> 
> not to me it hasn't.
> 
> remember: you have not communicated to me any forward-thinking
> or strategic software designs that will allow samba to rapidly
> catch up with man-decades of microsoft proprietary practices,
> except for the "glue" pipe idea.

This is a valid criticism of the entire way Samba is developed.  There
is very little formal 'this is where we want to be, this is the way we
will do it'.  

Most ideas in Samba are driven (at least initially) by the interest of
one person - and then others either like it and help or the original
author maintains it.  Very little of it is documented before the fact,
and hopelessly little after the fact (I'm guilty of this as much as
anyone).  This does mean that we don't get much of the 'forward-thinking
or strategic software designs' until they are implemented.

This is how it works, its a pity at times, but I simply don't see it
changing much in *any* OSS project.

Andrew Bartlett

-- 
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 mailing list