dbus upgrade issue

[Ray Strode]

Hi,

> In case other distributions encounter this issue, I had a private
> conversation with Ray where he was going to try having a post-logout
> script that updated the config file instead of simply including a new
> config file. Ray maybe you should post whether this works and how you
> did it.
I haven't done it yet (only working on it a little in the evenings
because I've been in San Diego on vacation), but I'm going to to have
some script called /usr/libexec/dbus-rh-upgrade-config.sh
that's just something like:

#!/bin/sh

MD5SUM="22fc46fda1b2cfd93ccb1f5825bdf0d5  /etc/dbus-1/session.conf"

set -e

if [ "$1" != "--force" ]; then

    # if we've already upgraded the config then bail
    [ -e /var/lib/dbus/.rh-upgraded-config ] && exit 0

    # if someone else has modified the config then bail
    echo ${MD5SUM} | md5sum --check --status || exit 0
fi

sed -i -e 's@<servicedir>/usr/share/dbus-1/services</servicedir>@<standard_session_servicedirs
/>@g' /etc/dbus-1/session.conf

# we've upgraded the config, don't do it again
touch /var/lib/dbus/.rh-upgraded-config

and run it at the top of /etc/init.d/messagebus

I haven't tested the above script, yet, fwiw.

> Also fwiw talked to Owen about this today (after he hit the bug) and his
> suggestion was the rename the file solution, specifically rename
> session.conf to session2.conf, ship both in the RPM, have session.conf
> be the backward-compatible one with a big comment in it "THIS CONFIG
> FILE IS IGNORED, USE session2.conf" and point the new dbus-daemon at
> session2.conf as the default config file.
That's definitely one way to go. In addition to the fat warning, we
could also remove all the other comments and strip the newlines from
the xml in session.conf so that it doesn't remotely human editable.
The file wouldn't need write permissions either.  I'll probably go
that route if the dbus config file is extended incompatibly again.

One disadvantage is that site-admin's changes will get lost on the
switchover unless we do config file munging.  If we're going to munge
anyway, then the dbus-rh-upgrade-config.sh is less invasive of a
change I guess.

Another disadvantage is that the config file location is sort of a
standard right now.  If we change it to something else, we should
either be forward looking and give it a name upstream will eventually
be adopting as a new standard or we should be explicitly separate from
upstream and go with /etc/dbus-1/redhat-session.conf or something else
that won't ever clash.


> Owen felt that /usr/share
> wasn't right, citing fontconfig as another example where a config file
> is in /etc even though few local sites would change it.
I think that having two separate config files: distro defaults versus
system settings makes a lot of sense.  The split in GDM made
maintenance for that package a lot easier, for example.  But as you've
mentioned before that's really a separate issue from this one and will
need some more thought/discussion.

> A final thought today, does the selinux stuff really need to raise(HUP)
> ? Is there no other way to tell the selinux lib to reload its config?
> Having to raise(HUP) seems pretty busted.
definitely.  I think the way it works (although I didn't really
investigate it that closely) is

1) raise(SIGHUP) causes a reread of /etc/dbus-1/session.conf
2) /etc/dbus-1/session.conf has
<include>/etc/selinux/targeted/contexts/dbus_contexts</include>
3) The included file has the <selinux/> tag in it which is tied to
some api in the selinux lib that reloads the policy.

--Ray