[Fwd: Re: ORBit-0.5.13 TCP/IP networking]

[Michael Meeks <michael ximian com>]

Hi there,

	This quite possibly, (probably) belongs on the gconf list,

	It's likely if you've run gconf on a machine, that it is running on a
remote machine but without TCP/IP configured. Thus you need to re-start
it on the remote machine [ for which the IOR is registered on NFS ],
having updated the users ~/.orbitrc.

	Indeed, the reason it won't run in the first place is that - that it is
already running elsewhere.

	HTH,

		Michael.

-----Forwarded Message-----

From: J Maynard Gelinas <gelinas lns mit edu>
To: Michael Meeks <michael ximian com>
Cc: orbit <orbit-list gnome org>
Subject: Re: ORBit-0.5.13 TCP/IP networking
Date: 09 Aug 2002 17:50:26 -0400


   Hi Michael,

   So, I continue running into this problem where clients get these 
"Turn on TCP/IP" error messages even though it's configured and turned on 
in /etc/orbitrc. If I log the user out and wipe .gconf*, then have the 
user log back in, this will resolve the problem for a few sessions. I have 
no data on if this is happening after users log in with multiple 
concurrent sessions, or if this is happening for other reasons. However, 
sometimes I can't even delete ~/.gconf* even with administrator privs:

afs1:/afs/lns.mit.edu/user/krishna# cd .gconf
afs1:/afs/lns.mit.edu/user/krishna/.gconf# ls
%gconf-xml-backend.lock
afs1:/afs/lns.mit.edu/user/krishna/.gconf# ls -al
total 12
drwx------    2 krishna  krishna      2048 Aug  6 19:59 
%gconf-xml-backend.lock
drwx------    3 krishna  krishna      2048 Aug  8 13:16 .
drwxrwxrwx   76 krishna  krishna      8192 Aug  9 17:40 ..
afs1:/afs/lns.mit.edu/user/krishna/.gconf# rm -rf *
rm: cannot remove directory `%gconf-xml-backend.lock': Directory not empty
afs1:/afs/lns.mit.edu/user/krishna/.gconf# cd "%gconf-xml-backend.lock/"
afs1:/afs/lns.mit.edu/user/krishna/.gconf/%gconf-xml-backend.lock# ls -al
ls: ior: No such file or directory
total 4
drwx------    2 krishna  krishna      2048 Aug  6 19:59 .
drwx------    3 krishna  krishna      2048 Aug  8 13:16 ..
afs1:/afs/lns.mit.edu/user/krishna/.gconf/%gconf-xml-backend.lock#

   Here I have AFS administrator privs and should be able to delete
anything within the directory. Note the total "4" of files, even though ls
reports nothing but "." and "..". Note also that emacs M-X dired can't
delete the file (or directory), and I've run across few files emacs can't
delete. I've noticed other strange behavior of GNOME apps running in an
AFS environment:

   * Nautilus icons on the desktop and files read and displayed from an 
AFS volume within the filemanager will disappear upon the first click. The 
file remains, but it's not displayed within the until Nautilus is 
restarted. A "refresh" operation does not help. 

   * Once gconf goes FUBAR most other Gnome apps won't run properly. This 
isn't surprising. 

   * I've seen the same problem with Nautilus and excessive gconf errors 
(combined with the hidden undeleteable files) across NFS homedir volumes 
as well, so doesn't appear to be limited to AFS. 

   Note that all Kerberos tickets and AFS tokens are fresh here. So there
are no underlying authentication issues which might be causing this. Any
ideas?

Cheers,
--Maynard

On 23 Jul 2002, Michael Meeks wrote:

> Hi Maynard,
> 
> On Mon, 2002-07-22 at 12:29, J Maynard Gelinas wrote:
> >    I'm deploying a large number of desktop workstations which run 
> > Redhat-7.3 and provide home directories across AFS.
> 
> 	Sounds good.
> 
> > One problem I keep 
> > seeing is that on login certain GNOME applications complain about being 
> > unable to connect to ORBit and suggest turning on TCP/IP networking in 
> > ORBit config. Searching around the net I've found:
> 
> 	Ok - I hypothesise this is anything that uses gconf, such as galeon and
> gtkhtml.
> 
> > http://orbit-resource.sourceforge.net/faq.html#orbit
> > 
> > Which states that I should add "ORBIIOPIPv4=1" to /etc/orbitrc or
> > ~/.orbitrc. Unfortunately, this does not resolve the problem.
> 
> 	It's the correct fix. It seems likely that there's a stale gconfd-1 or
> gconfd-2 process lying around; you need to ensure these are killed
> before logging on again.
> 
> > RH73 ships
> > with ORBit-0.5.13 by default. I've looked through the SRPM spec file and 
> > source to see if I can find something but to no avail. Can anyone point 
> > either clue me in or point me to the correct docs so I can solve this 
> > problem?
> 
> 	More details on your problem would be good, warning messages etc.
> 
> 	HTH,
> 
> 		Michael.
> 
> 
-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot