Re: gconfd, multiple concurrent logins, orbit, pain

[Havoc Pennington <hp redhat com>]

seth vidal <skvidal phy duke edu> writes: 
> [all good stuff] 
> Just rough ideas, I don't know how wise any of those are w/o giving it
> some more thought and talking to some folks who are wiser in the ways of
> authentication security than me. :)

There are some people around Red Hat who know this stuff that I still
need to ask.

I definitely think the ideal situation would be to avoid typing any
passwords beyond the usual gdm one.
 
> mostly I am interested in being able to mandate certain things in the
> user's config with relative ease. At the moment the gconf
> required-options is not terribly intuitive or documented so its hard for
> me to sort out how to set options globally that cannot be changed. I am
> thinking of something like a pine.conf.fixed or mandatory policies from
> WinNT/2K
> 
> Also, if we're going to have a registry (more or less) in the form of
> the gconf/gconfd it might be worthwhile to have a graphical regedit.

Both of these things are visible in a preliminary form in GNOME
2. Mandatory options involves just setting the key in the
gconf.xml.mandatory backend, and the GUI editor is called
gconf-editor. It needs a lot of work though, and one of the work items
is to let it retarget to gconf.xml.mandatory instead of the user's
preferences.

Nautilus 1 and probably Galeon don't handle a locked-down setting
correctly though, they probably start spitting unhelpful error
messages. This is slowly improving in GNOME 2 but involves a lot of
educating app developers. ;-)

> If there is one and I've not heard about it/found it then PLEASE let me
> know. It would be nice to have the user be able to edit their settings
> w/o having to enter the program. Especially if a setting accidentally
> makes a program unusable. 

gconf-editor does work with gconf 1 (Galeon/Nautilus) settings, but it
requires GTK 2 and GConf 2 libraries to be compiled, and gconf-editor
itself is still a bit unstable. So you may want to wait a bit before
trying it.

You can always use "gconftool" from the command line of course.

> Nitpicky but - nautilus needs to have a [special dirs] option like gmc
> had. I would rather that nautilus NOT try to traverse /afs when it runs.
> this is more an rfe - but its useful in places using lots of automounts.
> Teach nautilus about autofs. So that it see that the dir is an
> automounted point and grab the map and put the top level of dirs in
> folder for easy browsing for the user. I know sun has made
> tab-completion possible in bash for their mounter. So something like
> this should be do-able.

Yep.

> A nice way of sucking out a users config into a tarball or a single file
> would be incredibly handy. If the config-server had the data in an ldap
> server then you could, theoretically, yank the data out in an ldif and
> be able to reupload it to wherever you want, if you wanted to copy the
> info, easily to a different config-server.
> Ldap could also buy you SOME amount of replication ease so you don't
> beat up config server too much if you have A LOT of users.

Excellent. I wanted to do something like:

 gconftool --dump > foo.out
 gconftool --load < foo.out

This would be backend-independent; of course if we had an LDAP
backend, you could use LDAP tools to achieve the same effect. With the 
current XML text file backend, the ~/.gconf directory can also be
tarred up.

Havoc