GNOME Bugzilla – Bug 84101
GConf should not be per user $(HOME)
Last modified: 2005-02-24 21:06:56 UTC
Currently running gconf from 2 seperate machines with a shared $(HOME) will present huge problems since the lock is held by gconfd on one machine and other machine can't contact it - unless TCP/IP sockets are turned on. Enabling this is not really an option - so a good workaround would be nice until we sort this out in the future. This is fairly critical for Sun. Pasting some comments from hp - - right now the default thing is that gconf on machine #2 will get upset that the lock is held in the home dir yet it can't contact gconfd. If we run gconf-sanity-check in gnome-session, it will detect this case and warn the user. User will have to turn off gconf on one of the systems. - if you turn on TCP/IP for ORBit in /etc/orbitrc, then assuming there is no firewall between the two systems, gconf on system #2 will contact and use gconfd on system #1 and things should Just Work However we ship with TCP/IP disabled by default because sysadmins complain about the open ports. Should not be an issue behind firewalls, though. - In the future, things will be redone to have one gconfd per machine, and then a server somewhere that those gconfd connect to, and also a provision for "disconnected"mode. So then the setup will be more like IMAP and you don't need network connections between all the desktop machines, and even if you lose the connection to the server machine there's a mode you can use.
High/major as per Glynn's comments. I should note that the first point is already made- sanity check is now in the session manger, IIRC.
Federico: All yours. High priority.
Locking is not a problem. But how do we do the notification between the two GConfs if TCP/IP is disabled? Touching a magic file doesn't sound very pretty...
Well my plan here was to write a ton of new code to make multiple gconf instances client-server instead of peer-to-peer. That isn't an option at all for 2.0.x. But I could send you my OLS paper about it in private. Conceivably you could use a "create/destroy files" "protocol" to ask another gconfd to exit. When you log in, gconf-sanity-check-2 could stamp the ~/.gconfd/everyone-please-exit file. All gconfd instances could poll this file and exit if it's stamped. Uber-hack! Then we say you have to do TCP/IP if you are using two machines simultaneously. How does that sound? BTW, there's a "markup" backend in a branch in CVS that's a whole lot easier to figure out than the stupid XML backend... but again, not really a 2.0.x option probably. May be a Sun/Red Hat ship date option.
Gman: why is enabling TCP/IP not really an option? Is that true even after the security audit?
Hum, I guess lack of faith in ORBit2? - it was just decided [not by me] that it would be bad to enable it...so I have no clue.
Yes - it's a (fairly) bad idea to turn that on - sadly. Ideally; it would be nice if GConf went into a 'read-only' mode, and did atomic writes when it output XML [ it may do this already ]. Thus a new gconfd, could start, and just view the configuration options readonly, so you could actually startup. Ultimately, how many times do you want to change your configuration after all.
Suggest looking at how "pine" works if you open two copies, and try to copy that approach. ("Another pine is accessing inbox", etc.)
I'm not sure thats such a great idea since you would need to keep dropping the locks and dumping the cache on both sides every time you wanted to do a write. In the case of pine you don't want to do that, you only want one process able to write ... An even worse idea is to make a copy of the xml which the second gconfd operates on and merging the copies at some point later when you notice that the lock is dropped and the user won't get freaked out by preferences merging. Okay, so that's a horrible idea, and I don't expect that it'll ever do into CVS, but I hacked it up anyway so Sun can use it if no better hackaround is found. I'll attach the patch. Its kinda broken though :/
Created attachment 9339 [details] [review] de crack laden patch
Hmm, that's some major crack on the one hand, but on the other hand it's not _that_ different from the actual long-term plan - it's just using "gconfd" as the remote server discussed in said plan. My main worry is how do we stabilize it - put it in 2.1.x and try to get people using that branch I guess. Also, I'd like to be moving to the gconf-markup-hacking branch... and this change is going to conflict with the changes on that branch. For the merging, in my mind file (rather than node) granularity might be fine, I'm not sure if going the extra mile to actually parse the file is a good thing or just extra likely-to-create-bugs complexity. If you look at the markup backend on the gconf-markup-hacking branch, it has a MarkupTree data structure, perhaps the merging could take place on that level (markup_tree_merge_other_markup_tree(MarkupTree,MarkupTree)) - that might feel more robust. In any case, summary: I would not be opposed to getting something along these lines in CVS, I am trying to think through the merge with the gconf-markup-hacking branch, and I have not yet looked at the line-by-line details of this patch.
One more thought - this would feel a lot less risky if we had a test case that: - wrote a bunch of values to a mirror tree - merged the mirror tree to another tree containing some existing values, including some overlapping and some not - read the mirror values back and checked that they were all retained - read the non-overlapping values back and checked that they were not lost overlap = value was written in both trees. i.e. point is to be sure that values in the original tree that aren't changed in the mirror tree aren't lost during the merge.
A nice bit of paranoia and also a speedup might be to call gethostname() only once for a given gconfd process.
[Search for 'luis spamming' to catch every instance of this email.] In order to better track Sun's bugs for Sun and Ximian's internal use, I've added a temporary keyword to some bugs. I apologize for the spam, and for the use of an additional keyword, but this is the best way for Sun to track 'it's' bugs without interfering with the community's own triage and bug behavior. If you have any questions or objections, please drop me a note at louie@ximian.com or email bugmaster@gnome.org for more open discussion.
I just put Mark's patch in sun-patches, btw.
Federico: does this mean it works ? :-) I didn't have a second machine to try it with so I just did something hacky (can't remember what) to stop two daemons on the same machine communicating for testing it ... So it works okay for you ?
I haven't tested it, as I don't have two machines with shared homes. Let me see if I can grab a spare machine around the office to set it up. The patch is missing your gconf-test-lock.c; could you please attach it here? Thanks :)
Ooops, sorry. gconf-test-lock was just a little test app I wrote while figuring out how best to do this. It should be removed from Makefile.am. Thanks :-)
OK, removed it from the patch.
The GCONF_LOCAL_LOCKS hack seems like the simplest short-term hack here. Also, the OLS paper is now public of course, 2002 proceedings at http://www.linuxsymposium.org Anyway, I think we need to move to the markup backend as this and a number of other things we'd like to do for 2.4/2.6 are going to require poking around in the backend.
*** Bug 107693 has been marked as a duplicate of this bug. ***
*** Bug 87870 has been marked as a duplicate of this bug. ***
*** Bug 106867 has been marked as a duplicate of this bug. ***
I guess this problem also causes problems with evolution and galeon when locks aren't removed (due to crashes and power failures). We're using evolution as our main e-mail program and since we have our home directories on a central server using nfs, this causes regular problems with accessing mail folders and even printing from evolution can be broken because of this. It's easy to fix, but it just shouldn't happen (or be apparent to the user).
Removing PATCH keyword unless someone wants to propose revising this patch for 2.6. As gconf is now per-machine by default in 2.4, I'm closing this bug, though the overall issue isn't really quite fixed; but the larger fixes are more major refactorings than bugfixes. http://www.gnome.org/projects/gconf/plans.html
*** Bug 117846 has been marked as a duplicate of this bug. ***
I'm curious - has anyone tested this patch with afs-homedirs? in my environment it's easy for system 1 to mount a homedir on afs and system 2 to do the same and system 1 and system 2 to NEVER be able to see each other. Not just firewalled but networks that can not route to each other. Also if config data is going to pass over a non-filesystem protocol then it should be encrypted or encryptable. Config information can contain all sorts of sensitive data. While file systems are uniquely not well advanced for crypt nfsv4 makes crypted data and auth a reality. If this protocol for the config data is not secureable then it's not a terribly good solution. One additional question, is this patch enabled in fedora core 1 gnome 2.4? If so I can test how well it stands up to abuse on nfs and afs systems.
Havoc: so, are you no longer going to ship this patch with RH by default? [I haven't checked FC1/2 for it yet, but I know it was in RH9.]
Havoc, you wrote, "as gconf is now per-machine by default in 2.4, I'm closing this bug, though the overall issue isn't really quite fixed." Can you summarize what the 2.4 changes mean for a site using shared home directories? (Assuming the site cannot turn on TCP/IP in ORBit for security reasons, and thus does not turn on GCONF_GLOBAL_LOCKS.) My current best guess is that two gconfds on different machines will both gain access to the configuration XML files, and in the unlikely event that they both try to write to the same area of the config database at the same time, there could be problems. Also, changes made by one gconfd won't result in notifications to the clients of the other gconfd. That's acceptable to me, but I'd like to know if I'm right. (And ideally, I'd like to know how bad the problems would be if two gconfds do try to write to the same part of the config DB, but I realize that might not be an easy question to answer.) Thanks.