Management of Samba (again)

[Luke Kenneth Casson Leighton]

On Sat, 28 Mar 1998, Christopher R. Hertel wrote:

> > The problem with this is *speed*. If all lp_XX calls 
> > were redirected to a separate daemon Samba would run
> > slower than a one-legged dog in a whippet race (sorry,
> > that's my northen England background coming out there :-).
> 
> Jeremy,
> 
> That's exactly why I put all of the disclaimers into my message.  I was 
> simply giving examples of how this *might* be done, not how we'd do it 
> because you're exactly right about such changes.  The point of the 
> message was to architect a means by which we could support all of the 
> different management interfaces that people were kicking around.

have i missed something here?  i don't recall seeing the original message.
oh well!
 
> ..but, to the practical...
> 
> Each Samba dameon (nmbd, smbd) could keep a cache of all parameter 
> settings as they do now.  When they got a reload signal, they might
> reload from the config daemon instead of smb.conf.

yep.
 
> That's just a quick fix to the problem you brought up.  There are 
> probably better ways.  I just don't want to get stuck on implementation 
> issues--as important as they may be--yet.

i wanted to suggest something, here.  reloading of services can be done
unnecessarily, sometimes.

1) put all the options that are used in standard_sub_basic() and
standard_sub() into a struct.

2) make two of these structs: sub_params and sub_params_old.

3) when you get a reload_services() call, if sub_params == sub_params_old,
terminate reload_services().

luke