Re: gconfd, multiple concurrent logins, orbit, pain

[Havoc Pennington <hp redhat com>]

seth vidal <skvidal phy duke edu> writes: 
> 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.

So all executables (gconfd, galeon) are running on the Linux machine?

If so I don't think this is related to the TCP issue at all, it's
probably just some other issue. See http://www.gnome.org/projects/gconf/
for stuff to troubleshoot.
 
A recent popular bug was that installing GConf2 broke Galeon for non-C
locales - this was fixed in latest GConf2.

> 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. 

Yes, that's true.
 
> it sounds like creating portmapper and portmapper has been an historic
> mess.

It is much like portmapper. I'm not familiar with the historic mess
though I know what portmapper does - can you point me at docs on that,
or summarize?

> What about moving in the direction of ACAP rather than reinventing
> the wheel?

Good point, this is the other possible design: that instead of
many-to-many connections (where each of N machines you log into can
have a connection to each of other machines), we have a one-to-many
connection, i.e. a single server and then all N machines you log into
connect to that one server.

(Whether that server is an ACAP server specifically is another issue,
I think the answer is no because a) ACAP isn't exactly right for
config info, and since no one uses it there's no advantage of using a
standard anyway and b) we want to do things other than configuration
information.)

> 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. 

Right, thanks for the reminder.
 
> 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.

I think a single-server design could still support the signaling.

OK, despite I think bringing up the single-server/ACAP solution in
previous conversations, I had gotten in a brain rut the last few days
and forgotten about it. Let me restart my train of thought in that
direction and see if I can figure it out. ;-)

Havoc