Re: FUSA vs. GDM


Simply copying the user's /etc/gdm/gdm.conf file to /etc/gdm/custom.conf
will workaround the problem until I correct it in the next release of

Again, apologies for the trouble.

The problem is that everything FUSA currently reads from the config file
(exceptions, min/max uid, global face dir, max user filesize, and allow
root) are no longer reliably stored in one file anymore. The config file
location is already compile-time configurable, but as you mentioned, the
*intended* use is to keep everything possible in default.conf, with an
almost-blank custom.conf that overrides a few values.

I probably overreacted by suggesting that FUSA get pulled, but if
there's a pretty obvious bug with recent GDMs (namely a totally
uncontrollable user list), then I'm willing to hold off until 2.16. That
said, I'll try to get the fix done by the end of this week and see what
the release team thinks.

I think I understand what your problem is, now.  Is FUSA trying to
read the GDM configuration files directly?  If so, I would very much
recommond *not* doing this.  It is likely that the configuration
format in GDM will get futher complicated in the future.  There is a
GDM bug where people are asking to be able to set [server-foo]
specific key/values that would override the default and custom values.
Not really sure how this would work, but someone may provide a patch
for that someday and make it even harder to parse.

The enhanced configuration management in GDM makes implementing
enhancements like this easier, so it is more likely that you might
have to continue dealing with complicated GDM config file parsing
if you go this route.

The better way to get config data is to call the following command
(using the gui/Include key as an example):

   gdmflexiserver --command="GET_CONFIG gui/Include"

Because the daemon knows how to parse the config file, this ensures
that you are using the same configuration value that the daemon
is using, which is what you probably want.  If you do things
like grep and awk the config file directly, you may not be using
the same value that GDM is using.  This is because GDM does validation
on some config values so the daemon may not be using the same values
that are in the config file.

Does this make your problem easier to fix?  This is a much more
stable mechanism for getting config data from GDM and should be
easier for you to fix than writing a bunch of code to parse the
config files.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]