Re: gconfd, multiple concurrent logins, orbit, pain

[Havoc Pennington <hp redhat com>]

seth vidal <skvidal phy duke edu> writes:
>  So on the advice of this list I made my orbitrc support tcp.
> 
> So then presto my local users were able to have multiple concurrent
> logins.
> 
> then, just to be thorough, I logged in from far far far away on a
> windows machine using xwin32 and ssh. Now, one would think this might
> work, but b/c orbit had tcp support it attempted to connect to the
> windows box and promptly died when I ran galeon.
> the same goes for most any other gnome app that uses gconfd or
> orbit.

I don't have a clear picture of the setup here, you're saying you
have gconfd running on the windows machine, but ORBit doesn't accept
TCP connections on Windows? Or you have the gconfd on UNIX but ORBit
doesn't make outgoing TCP connections _from_ windows?
 
> Would there be a way for me to specify subnets that can connect via tcp
> and have other connections just be treated normally?

I'm not sure that would solve anything.

I've spent many hours the last couple of weeks trying to rethink this
issue. Short answer, for this and various other things, we need to
have a network connection between all instances of a user being logged
in. So what's the best way to go about this?

The current answer with ORBit is that you can globally have all apps
listen on an ephemeral port (in Stevens's terminology, i.e. a
dynamically-allocated high-numbered port), so any app can talk to any
other app via TCP.

An idea I've been tossing around is that instead of each app
listening, we have a single per-user daemon that's a "message bus"
that does the listening. The message bus would be per-machine
(avoiding the NFS locking thing in user homedirs), but each message
bus would get messages that appear on any machine the user is using.

These per-user message bus daemons would also be on ephemeral ports,
but only one such port per user, not per app.

Even that could be eliminated though if we had a system daemon on a
well-known root-requiring port that acted as a proxy between user
message buses. This would allow us to require only a single open
well-known port, instead of per-user or per-app ports, but would
create the complexity of a system daemon, and keep people from
installing things without root access.

This is all made more complex to sort out since there is no unique
per-machine identifier (multiple network interfaces are allowed), and
there is no fixed relationship between X displays and machines either.

Havoc