CVS update: samba/source/include (fwd)

[Luke Kenneth Casson Leighton]

andrew does not want me to add the ability for unix admins to decide
whether to start and stop unix services.

i definitely want to add the ability to start and stop msrpc services, as
i find it a bit of a pain to do a killall srvsvcd; make; bin/svcctld about
once every ten minutes throughout the day.

andrew did not want the "magic script" option in smb.conf, which runs
scripts if you copy them onto a samba server (it's a bit like rexec).

if you don't speak up in favour, start/stop services as remote
administrator certainly won't ever get added.  if you are just a unix
admin and do not touch NT or do not use any remote unix administrative
tools with the similar capability [to start/stop services], please say so,
and your opinion will be noted but given less weight.

thx,

luke

---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 20:43:34 +1100
From: bs at niggard.org
To: Multiple recipients of list SAMBA-CVS <samba-cvs at samba.org>
Subject: Re: CVS update: samba/source/include

This mail is entirely based on my intuition, not on hard facts or
anything; don't hit me, i just have no time digging into the internals
of smb...

On Fri, 17 Dec 1999, Andrew Tridgell wrote:

> > > I want SMB/MSRPC to die, not to become a core piece of every unix
> > > admins toolbox. I can't think of any unix admin who wants the ablity
> > > to control unix daemons from NT.
> > 
> > you might not.  the unix admins might.
> 
> they won't. ask a few if they want to start/stop sendmail via
> Samba. 
> 
> I asked our local sysadmin. His answer was "its crap"

True, any sane admin that can use a shell and X will never ever want to
fire up windows to do administration work. but reality looks like this:
more and more people are using samba that never ever used a shell. and
they want to be able to do everything from their known NT-tools and they
want to have a linux/bsd server. sad but true.

so first i thought: hey, if we can do it, why not? it's not my problem if
the luser messes everything up. i've warned him enough, he'll have to pay
me for fixing it. but after thinking over it: no, it's just too dirty. and
unix is not about doing it dirty, it's about doing it right and letting
you the freedom to do it dirty. so, dont bother implementing this. give
people a framework to do anything they want with msrpcs. what *i* would
love is a plugin system comparable to gimp: handle msrpcs in plugins. the
api is nearly as easy as simple function calling. as there will be no
"external" plugins for some time, the api can evolve. every plugin will
have 3 major functions: load_plugin(...) handle_rpc(struct rpc*)
unload_plugin(). the plugin chooses which rpc's it handles. if the user
loads a plugin not by the samba team, that formats her hd, can be fucked
by overflows or whatever => it's not your fault! of course lots of thinking
will have to go in a system like this, like how to catch segfaults in
plugins and so on. but it still looks easier than doing this over pipes!

i dont see what you lose over the multi-server system: instead of starting
and stopping, load and unload. instead of 3rd party servers, 3rd party
plugins. instead of running another process, just let the plugin fork() in
the load_plugin() code. the code for decoding rpcs can be provided by
smbd. the only problem that comes in to my mind is plugins and smbd being
linked to different versions of the same library. but this is unlikely,
isn't it?

(OTOH i do not see the need to do an lsarpcd either...)

when i can get some time on weekend and i'll try to distill some example
code out of the gimp.

cu,
bertl.