9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Multi-stack mail problem.
@ 2003-09-30  0:48 Dan Cross
  2003-09-30  1:12 ` David Presotto
  0 siblings, 1 reply; 35+ messages in thread
From: Dan Cross @ 2003-09-30  0:48 UTC (permalink / raw)
  To: 9fans

I mentioned this before, perhaps back in January.  My mail server has
two network interfaces, with seperate IP stacks for each.  The internal
stack gets mounted on /net, and the external stack gets mounted on
/net.alt.  However, for the last few months, I've noticed that when I
try to send mail, smtp blocks and hangs trying to send it out the
internal interface (mounted on /net); I've not spent the time to track
down when and where it's hanging, but worked around it by adding:
``bind /net.alt /net'' to /mail/lib/remotemail before invoking smtp.
That seems like an imperfect solution; what if I decide to add a
machine on the internal network that accepts mail via SMTP?  I suppose
I could hack remotemail to try and be smart about binding stacks around
based on where one is sending to, but one would hope for something more
automatic.

Indeed, it seems it used to be different.  In particular, I remember
dhog once saying that if DNS failed, it would try the lookup on
/net.alt, and if that succeeded, use that stack instead.  What's more,
I distinctly remember this working.  On the other hand, Dave said it
was a terrible hack (and indeed, it is).  But Dave had also changed the
IP stack so that if a default route didn't exist on an interface, an
error would immediately be bounced up the stack if a packet couldn't be
sent, and higher-level code (such as that which tries /net.alt) could
take over and try something else.  Only it seems that somewhere along
the way, something broke, and the `try /net.alt next' trick no longer
works.  Lamentable hack though it was, it did serve a purpose, and its
disappearance makes me sad.  :-(  Does anyone know what happened, and
how to either a) `fix' it, or b) do something to give the same effect?
Thanks.

	- Dan C.



^ permalink raw reply	[flat|nested] 35+ messages in thread
* Re: [9fans] Multi-stack mail problem.
@ 2003-09-30 13:29 David Presotto
  0 siblings, 0 replies; 35+ messages in thread
From: David Presotto @ 2003-09-30 13:29 UTC (permalink / raw)
  To: 9fans

 From the comments, I see that some people are confused.  My
terrible hack is only to live with totally separate stacks.
If you want to openly route between different interfaces, or
just have different interfaces to the 'open' internet, there's
no reason for separate stacks.  Any stack can have as many
interfaces as you'ld like.  The record so far was on the
path star switch which support 256 interfaces on a single
stack.

In addition to multiple stacks, there are also multiple mount
points.  More than one network type can be on a single mount
point.  For example, you can have and IP stack and a datakit
stack unioned on the same mount point.  'cs' is artificially
intelligent and tries to figure out which you mean by the name
you give it.  If the name is possible on multiple network
types, it gives you back the union of possibilities for you
to work through.  We lived that way for a long time while
datakit was reliable and IP wasn't.  Eventually datakit
just died to be replaced by the monstrosity called ATM
to later be replaced by the super-monstrosity called
MPLS...  Nothing against wasting bandwidth (it makes money
for our company) just against the amazingly complex connection
setup in those two networks.  They are to datakit, what PPP
is to SLIP.

Clearly, dial doing what it does is a mistake, though I
doubt it is Dan's problem.  I could have made
cs smart enough that I don't nead one per network mount
point but instead one per system that understands all the
mount points.  That way it could consult all the stacks/mount
points and see what is possible.  The reason for not doing that
to date is that the cs doesn't know which mount points/stacks
the user process has in its name space.  If I import an outside
stack from our outside machine, there's no way for my cs
to know that or even have access to that stack.  Having cs under the
mount point makes that a non-problem but pushes the responsibility
to the library.

To wit, I don't have a good idea for the correct solution and
continue the hack until someone comes up with one.


^ permalink raw reply	[flat|nested] 35+ messages in thread
end of thread, other threads:[~2003-10-01  8:32 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-30  0:48 [9fans] Multi-stack mail problem Dan Cross
2003-09-30  1:12 ` David Presotto
2003-09-30  8:00   ` Lucio De Re
2003-09-30  8:20     ` Charles Forsyth
2003-09-30  8:41       ` Lucio De Re
2003-09-30  8:54         ` boyd, rounin
2003-09-30  9:34           ` C H Forsyth
2003-09-30  8:42     ` boyd, rounin
2003-09-30  8:52       ` Lucio De Re
2003-09-30  9:16         ` Fco.J.Ballesteros
2003-09-30  9:27           ` Lucio De Re
2003-09-30  9:38           ` C H Forsyth
2003-09-30  9:39             ` Geoff Collyer
2003-09-30  9:41             ` Geoff Collyer
2003-09-30 12:07               ` C H Forsyth
2003-09-30 17:09                 ` boyd, rounin
2003-09-30 17:18                   ` ron minnich
2003-09-30 17:45                   ` C H Forsyth
2003-09-30  9:48             ` Bruce Ellis
2003-09-30  9:55               ` C H Forsyth
2003-09-30 11:51               ` Lucio De Re
2003-09-30 17:07                 ` boyd, rounin
2003-10-01  8:32                   ` Fco.J.Ballesteros
2003-09-30  9:41           ` Geoff Collyer
2003-09-30  9:16         ` boyd, rounin
2003-09-30  9:37           ` Lucio De Re
2003-09-30  9:52             ` boyd, rounin
2003-09-30  9:53             ` Geoff Collyer
2003-09-30 10:11               ` boyd, rounin
2003-09-30 10:13               ` boyd, rounin
2003-09-30 11:51               ` C H Forsyth
2003-09-30 17:00                 ` boyd, rounin
2003-10-01  0:09                 ` Geoff Collyer
2003-10-01  0:23                   ` Charles Forsyth
2003-09-30 13:29 David Presotto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).