dbus upgrade issue

[Havoc Pennington]

Hi,

Ray Strode wrote:
> It turns out that the session dbus-daemon is calling exit() after
> reloading its config following a hangup signal that's generated during
> the upgrade (because of an selinux policy update).  The session daemon
> is calling exit(1) because a new, incompatible session.conf is getting
> installed to /etc/dbus-1.  The new session.conf adds a
> <standard_session_servicedirs /> tag that the old, running session
> daemon doesn't understand.

Hmm, the exit() seems plain wrong; better behavior would be to just 
ignore the new config file. So step 1 is to just be sure we patch this bug.

However - are you sure this is due to HUP? I thought the daemon had a 
watch on the config directory.

If it is due to HUP, I believe I complained at one point about a 
"killall -HUP dbus-daemon" in the init script that should have only 
killed the particular pid... whether or not that's the source of the 
problem, in general I'm not sure HUP'ing the *session* buses on upgrade 
is appropriate. I think it would be fine for the session bus config to 
be loaded only at login time and never again, or maybe only on explicit 
HUP by the user.

> To get around this we need to keep the running dbus-daemon happy, and
> still give the updated config file to the new version of the
> dbus-daemon when the user logs out and logs in.  The easiest way I can
> come up with to do that is to move the config file to a new location,
> and keep a backward compatible config file in the old place.

Assuming we aren't moving the config file anyway (let's keep the /etc 
vs. datadir issue separate from this issue), this seems like an 
overreaction to me. Surely there's a less disruptive solution.

Have you thought about the upgrade scenarios if you do this? For 
example, if there are new security policies required for HAL to work, 
and you have moved the security policy files to /usr/share, the running 
system daemon will never see the new policies. HAL will thus not work 
until the system is rebooted. Or worse, the running bus could see that 
all its policies have vanished and adopt the default 100% locked down 
policy, which would basically hose everything.

Remember also that RPM either can't replace a directory with a symlink 
or vice versa, I don't remember which, in any case it seems a bit scary.

> This brings up an interesting observation though.  session.conf and
> system.conf aren't really config files at all.  They even say
> something like "don't ever edit this file, use session-local.conf
> instead" or something.  In fact, the options in there seem more
> distribution specific than system specific.  So given that 1) the user
> shouldn't change the settings 2) the user wouldn't even normally want
> to change the settings, why are we installing the files in /etc ?

There may be cases where editing the file is required; for example, I 
don't think we allow removing a listen address in the -local.conf, there 
may be other things that are impossible to override in -local.conf. 
AFAIK the conf file has not been audited or designed in such a way that 
the .d/-local are always enough.

You are correct that the config files mix mostly "factory" configuration 
with maybe one or two things a local site might change, but I'm not sure 
the split is cleanly between the main file and the -local.

I believe a number of things in /etc are like this; dbus did not invent 
the -local/.d approach....  you'd have to ask an FHS geek what the 
Official Word is.

> For FC-6 I'm moving the files to /usr/share/dbus-1 and stripping the
> write permissions off of them.  This seems more correct and will help
> fix our bad upgrade issue.  I've attached the patch that I'm using to
> do that.

Doing this in a Fedora-specific patch I consider a bad idea, fwiw. There 
is nothing Fedora-specific about the /etc vs. /usr/share issue, and 
these file locations are something of an application interface.

> One thing I'm not moving for FC-6 is the /etc/dbus-1/system.d
> directory because a lot of packages depend on it being there.  It
> might make sense to move it, though, and create a compatibility
> symlink.

I think you'd find this creates a world of pain (and cross-distribution 
incompatibility) if done only in Fedora. Even if done globally, it will 
be a nasty migration period just due to apps trying to run on both old 
and new distributions.

I'd recommend separating the two issues (upgrade crash and file 
locations) for discussion and thinking purposes, and be sure we have 
independent ideas of the right fix for each. If it so happens that we 
should do /usr/share anyway then it will fortuitously fix the Fedora 
upgrade problem too.

Havoc