High-availability cluster and samba

[Nicolas Williams]

On Sat, Feb 05, 2000 at 05:35:52AM +1100, Luke Kenneth Casson Leighton wrote:
> > Luke, can you make sure that smbd communicates with the MSRPC daemons in
> > SAMBA_TNG in a way that allows the running of more than one set of
> > daemons per host, with each set being conceptually separate as I showed
> > above?
> 
> actually, i have to do that.  i am going to have to associate _one_ msrpc
> daemon per _separate_ smb virtual user id (vuid).

Why? I don't get it. And I read your posts today and yesterday.

Why can't you pass the PID/vuid along with the DCE/RPC NDR packets to
the msrpc daemons??

I see no conceptual difference. And remember how VMS has difficulty
dealing with fork(), so do try to always pass along enough context in
all your function calls and IPC so as to make it easy to someday modify
the msrpc daemons to either be multi-threaded, async I/O based (yes,
yes, I know about blocking RPCs) or multi-process but based on a single
dispatcher.

> this will only happen for Windd / winframe/ TSE, but it's not very pretty.
> 
> the old code (2_0 and 3.0) used to pass in a vuid.  i am going to have to
> pass that over somehow with cli_connection_init().
> 
> argh.

What I had in mind is that the directory containing the Unix sockets (or
whatever it is you use for IPC) be configurable.

Of course, if each smbd forks its own msrpc daemons then there's no
issue as far as HA goes.

So maybe there is no issue here [yet].

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.