Re: proposed architecture evolutions for GConf

["Francisco Javier F. Serrador" <javier serrador openshine com>]

Some time ago I did a deployment test for an enterprise-wide migration
to GNOME (around 10,000 hosts), and I found useful some python scripts
to tweak some GConf keys in Evolution, and retrieve data from a LDAP.
>From this special case I had to query an Active Directory server to
obtain users data and I realized that customizing on very large
deployments is very tricky and error prone. If we can provide an easy
way for GConf to obtain data from an LDAP already in place, we can
target enterprise wide migrations more easily, providing for example a
template with the required data to change Outlook for Evolution with
Exchange, as in my case or some other useful data for large deployments
(like a global enterprise certificate storage, for example).

Questioning about replacing CORBA, recently I heard about ICE
http://www.zeroc.com/ice.html, but I do not know if it can give us more
than Orbit does.


Cheers


El s� 11-11-2006 a las 12:02 +0100, Josselin Mouette escribi� Hi,
> 
> being repeatedly faced with trouble about the GConf architecture, I've
> thought a bit about the global GConf situation, and I'm therefore
> proposing some improvements I'd like this to be discussed a bit before
> any code comes up. I'll try to summarize the current situation for those
> who don't know it and show my conclusions. I hope I won't be too much
> stating the obvious.
> 
> There are several ways to deal with a single-session, single-host
> configuration engine. Real problems arise when the user can log in
> several times on different machines, with a shared filesystem. With the
> number of corporate users working over NFS, this is not something we can
> ignore.
> 
> The current implementation communicates with gconfd using CORBA.
> However, by default it uses a local lock in /tmp/gconfd-$user and starts
> one daemon for each host. This has several major drawbacks:
>       * configuration changes are not notified to other hosts;
>       * worse, they are written on disk without locking and can end up
>         corrupted if two hosts write at the same moment;
>       * even worse, there is a trivial local denial of service attack
>         that consists in creating a /tmp/gconfd-$otheruser directory.
> 
> I think a good short-term change is to revert to global locking by
> default. Global locking is done in $HOME, avoiding the denial of service
> issue and proper write locking is implemented. As only one daemon is
> started, remote notification works. However, you need to tell ORBit to
> accept IP connections in this case, which is deactivated by default for
> obvious security reasons. There is already an explicit error message
> asking to enable this support, so I don't think there's anything more to
> do.
> 
> For a longer term, we can envision a new communication backend.
> Obviously, dbus comes to mind. Unfortunately, while it definitely brings
> some improvement for the single-host use, it is completely unsuitable
> for multiple host setups. And apart from dbus, I don't know of anything
> else that would give sufficient improvement over CORBA to justify the
> move.
> 
> 
> How about forgetting this communication thing? Configuration is stored
> in files, we just need to read and write these files. We even have some
> decent ways to monitor files now: local using inotify, remote using fam
> with dnotify.
> 
> To achieve this, the first thing to do - and it should have been done
> for a long time - is to move the file notification API from gnome-vfs to
> glib. To avoid introducing a new dependency, it would require to
> dlopen /usr/lib/libfam.so.0, or to dlopen a plugin linking to it,
> instead of linking to it directly. This GMonitor interface could then be
> used by various applications needing monitoring, like gnome-vfs,
> gnome-menus, evolution...
> 
> ... and GConf. If we move back again to a split-file backend for GConf,
> we can make libgconf directly read, write (with proper locking) and
> monitor these files, without any need for a daemon. If a migration
> script is provided, complete source and binary compatibility could be
> retained. The backend could use libxml as currently, or move to a
> GKeyFile implementation if someone really feels the need to integrate
> GConf into Glib.
> 
> It would also bring more consistency in how configuration is handled, as
> the freedesktop MIME information is already dealt up by the way of file
> monitoring.
> 
> Comments anyone?
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
 Francisco Javier F. Serrador

Director de operaciones - Openshine -