On Sun, 2002-03-31 at 16:19, Havoc Pennington wrote: > > 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? > Better explanation: Linux box, running rhl 7.2 + gnomehide Windows 98 box - running xwin32 and teraterm ssh allow orbit to support TCP connections login to the linux box from the windows box. run galeon watch it die with a "cannot get schema" error. The windows box does NOT have gconfd. I just want it to redirect the X session. It seems to fail with hot death. > 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. problem with this - it will be sending user-related data over a tcp connection. This data COULD be sensitive configuration information and should be encrytped/tunneled. > 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. it sounds like creating portmapper and portmapper has been an historic mess. What about moving in the direction of ACAP rather than reinventing the wheel? Setting up a single, largish, acap server for my dept/users that uses SSL/TLS for transport would make me MUCH happier than punching holes in my firewall(s) for the configuration you're talking about. On a single user machine the local database works fine - but when you have LOTS of users it makes sense to have an actual config server. A local cache for the acap-stored data would make sense for a quick lookup but then writing back the data when you've made a change. It might not buy you the signaling you want for notifying apps of changes to the config options but it would be a tidier configuration, I think. Has acap already been discarded for another reason that I'm not thinking of? -sv
Attachment:
signature.asc
Description: This is a digitally signed message part