lsarpcd

[Luke Kenneth Casson Leighton]

On Sun, 12 Dec 1999, Dan Kaminsky wrote:

> Luke--
> 
> 	Sounds like you're hacking together some interesting stuff.  A
> couple comments, though--
> 
> 	1)  We accept it as obvious that multiple incoming SMB connections
> should spawn multiple smbd processes to feed files to them.  We don't,
> however, accept it as obvious that we should need to preload as many
> available SMB daemons as we expect to have simultaneous links :-)

you won't.  each daemon provides particular services (mostly
self-contained, surprisingly enough).

i cut/paste smbd as the basis for the daemon-starter, therefore in exactly
the same way that smbd self-spawns for incoming SMB connections, the
individual msrpc daemons self-spawn for incoming MSRPC connections, and
terminate in the same way.

the amount of time that an average MSRPC daemon is up and servicing
requests is of the order of... let's take a look at a netmon trace...
srvsvcd will be up for 9ms to service a NetrShareEnum.  lsarpcd will be up
for 16ms to service an LSaOpenPolicy / LookupSidss / LsaClose sequence.

>  Could not one daemon autospawn the required NT daemons on demand?

i don't see why not, however this would be best done in a startup script,
don't you think?
 
> 	2)  Whatever you do, don't make a "stable release" that can
> destroy NT networks.  I know of at least one major company that's banned
> all Linux workstations due to *one box running gated* that took down
> entire subnets.  Eek.

what they don't realise is that nt can do likewise, therefore they should
ban NT from their NT networks.