A networking/X configuration question:

A networking/X configuration question:

Hardware configuration:

__________ __________ LAN A __________
|CPU #1 | LAN C |Gateway |_________|CPU #2 |
| |__________| | | |
| | | |_________| |
---------- ---------- LAN B ----------

CPU #1:
Red Hat 7.2
X-app display exported to CPU #2 via LAN A
X-app display mapped to CPU #2 via LAN B

Gateway:
Red Hat 7.2
Running NAT to prevent LAN C addresses on LAN A or LAN B

CPU #2:
Red Hat 7.1
X-server

Background:
If LAN A goes down (broken/disconnected cable, intermediate [not shown]
switch dies, etc.) CPU #1 can be notified of failure on LAN A. CPU
#1's unmapped LAN B display (containing the same data as the display
that was exported via LAN A) should be brought to the fore on CPU #2.
I can reliably detect a failure on LAN A.

Question:
How can I bring the unmapped display to the fore without killing and
restarting the X server on CPU #2?? Killing the server sends the user
to the login panel, which is unacceptable.

Thanks and have a nice day,

Chuck

> Question:
> How can I bring the unmapped display to the fore without killing and
> restarting the X server on CPU #2?? Killing the server sends the user
> to the login panel, which is unacceptable.

Run two X servers on VTs 7 and 8, and run chvt 8 when you need it?

--
To reply by email, replace "deadspam.com" by "alumni.utexas.net"

: (E-Mail Removed)
: How can I bring the unmapped display to the fore without killing and
: restarting the X server on CPU #2?? Killing the server sends the user
: to the login panel, which is unacceptable.

One of NX, Xvnc, xmove. The first two would provide virtual desktops
seved from CPU 1 but displayed on CPU 2; when one, or both, links go down,
you can re-establish the connection and pick up where you left off.

The xmove system, on the other hand, is a way to arrange for migration
of x apps from display to display; again, you run a virtual server on
CPU 1, but it's far lighter weight, and you establish connections to
apps rather than a whole desktop.

Note that this isn't an alternate display with similar apps in it.
It's the exact same display, accessed by a different route. For the
ability to swap between two displays, just starting multiple X servers
on CPU 2 is simplest.


Wayne Throop (E-Mail Removed) http://sheol.org/throopw

(E-Mail Removed) écrivait news:1108134350.883877.287050
@g14g2000cwa.googlegroups.com:
> __________ __________ LAN A __________
>|CPU #1 | LAN C |Gateway |_________|CPU #2 |
>| |__________| | | |
>| | | |_________| |
> ---------- ---------- LAN B ----------

What the problem ?

You have two hosts linked throw two networks, use routing protocol such as
RIPE to manage this network problem. That's the normal way.

On the gateway, you should define the LAN A and LAN B as two possible
routes to the interface of the CPU#2 host. Then the RIPE protocol could
switch to the second route if the first is down.

This need a daemon like gated, but it's a network problem only, and the
rest would be "transparent".

Regard