Re: [gdm-list] Layered config files in gdm

[Brian Cameron <Brian Cameron Sun COM>]

Jeff:

> Hi! I'd like to achieve a similar solution for gdm as we have for gconf
> with /etc/gconf2/2/path.  This is useful for distributions because we
> can ship upstream defaults, provide our own defaults, and then look at
> the users configuration file after that.
>
> Where I'm tripping up is in gdm_get_custom_config.  Right now there's
> handling to cope with GDM_OLD_CONF versus GDM_CUSTOM_CONF.  What I'd
> been thinking is that by default, it should ship a config file
> (/etc/gdm/gdmconfig.conf):
>
> /usr/share/gdm/gdm.conf
> /etc/gdm.conf
> /etc/gdm.conf-custom

I think you may be confused by the GDM_OLD_CONF logic.  Currently the
GDM daemon just uses the /etc/gdm/gdm.conf file as the custom file if
it exists on the system, for backwards compatibility.  If the file
is not there, it uses /etc/gdm/custom.conf.

So if there is no gdm.conf on the system it uses:

/usr/share/gdm/defaults.conf
/etc/gdm/custom.conf (values override the defaults.conf)

If there is a gdm.conf on the system it uses:

/usr/share/gdm/defaults.conf
/etc/gdm/gdm.conf (values override the defaults.conf)

> Where the last one to be read in that exists is where the custom
> modifications get put.  A distro could change this to be:
>
> /usr/share/gdm/gdm.conf
> /usr/share/ubuntu-artwork/gdm/gdm.conf
> /etc/gdm.conf-custom

Or we could just add a single layer so it works like this

/usr/share/gdm/defaults.conf
/usr/share/gdm/distro.conf
/etc/gdm/custom.conf (or /etc/gdm/gdm.conf if on system).

We could also set up a configuration file like /etc/gconf2/2/path
where the distro could list a collection of files that would be
processed one after the other, if you think that would add more value.
It would probably offer more flexibility.  This file could perhaps
be called /usr/share/gdm/path.

The only problem with doing this approach is what we really want
is for gdm.conf to be used instead of custom.conf for backwards
compatibility.  I guess we could make the file contain the following:

/usr/share/gdm/defaults.conf
(distro files could go here)
/etc/gdm/custom.conf
/etc/gdm/gdm.conf

Which would cause the gdm.conf to override the custom.conf if it
is on the system.

To make this sort of change, you would have to do the following:

1) Modify gdm_load_config_option so that it processes the
   additional files.  Currently it just works with custom and
   defaults files.  This shouldn't be too hard.  You just
   want to use the same logic to get the value from the custom
   file.  Note this function is called with a hash_foreach
   function so you have to modify the GdmConfigFiles structure
   so you can pass in the list of files to read.

2) Notice in gdm_config_parse that there is logic to manage
   reading the [servers] and [server-foo] sections.  These
   will need some work, which I detail below since this is
   a bit complicated.

3) gdm_update_config would need to be modified to reload values
   from more than just the custom and default file.  Note the
   timestamp logic in this function and gdm_config_parse that
   needs work to handle additional files.

4) In gdm.c, the GET_CUSTOM_CONFIG_FILE is supposed to return
   the filename that gdmsetup should modify when users run it.
   This should probably be always set to the last file loaded.

If you want all this to work with a /usr/share/gdm/path file,
perhaps the best way to do this would be to build a global array
at the beginning of gdm_config_parse with a list of the files,
then the array can be passed around to access the list of files.

Note that the logic first calls gdm_load_xservers with the custom
file and then with the default file.  This file ignores an id value
if it has already been read, so this means that if a [server-foo]
section is in both the default and custom file, then the custom
file value is used.

There currently is no way to say "remove a [server-foo] definition
in a previously read file".  Though this is probably okay since the
server-foo sections are only referenced them in the [servers] section,
and this does allow the custom file to override the defaults
settings.

Note I do the same sort of thing with gdm_load_displays.  First
read from the custom file and then read from the defaults file.
Note that the display can be set to "inactive" which causes it
to not be added to the actual list of displays.  gdmsetup works
so if you delete a [server] value that is in the defaults file
like so...

0=Standard

It will put the following in the custom file.

0=inactive

Then this allows the custom file to turn off the display defined
in the defaults file.

So make sure to test that the overriding of values works for
not just keys, but also for the [servers] and [server-foo]
sections.

This really shouldn't be so bad, you just have to remember to
read the files in reverse order since the logic is written to
accept the first value it reads and ignore duplicate values in
subsequent files.

> I'd like feedback before I dive into this.  I'd like to offer this for
> inclusion upstream.

Yes I would accept a patch like this.  Hope all the description
helps you understand how to make the change.

Brian