Bug 1214409

Duplicate of bug 1198626?

(In reply to Fabian Vogt from comment #1)
> Duplicate of bug 1198626?
Yes and no.
The source of the problem is the change in the bluez package.
obexd now is in a separate rpm and it needs systemctl --user to get activated.
In the past all it was necessary was to install the rpm bluez.
After reading boo#1198626 I came to the conclusion that now each desktop environment needs to take care to install bluez-obexd and start the obex service.

For plasma it means:
In the package powerdevil5, in the file /usr/lib/systemd/user/plasma-powerdevil.service, add the line:
   [Unit]
   Description=Powerdevil
   PartOf=graphical-session.target
   After=plasma-core.target
  +Wants=obex.service
and also add:
  Requires: bluez-obexd
in the spec file of either powerdevil5 or bluedevil5 (which one do you think is more appropriate?).

I tested such changes and with them in place, bluetooth now works in Leap 15.5 as it was working in 15.4.
Please let me know your thoughts so I can submit a sr for tumbleweeed.

Yeah, arguably bluedevil5 should require bluez-obexd.

But obexd.service needs to be dbus activated, not unconditionally started by Plasma or each DE individually.

(In reply to Fabian Vogt from comment #3)
 
> But obexd.service needs to be dbus activated, not unconditionally started by
> Plasma or each DE individually.

If I understand correctly, you mean that the fix has to come from the bluez-obexd package. Unfortunately boo#1198626 has been sitting there unfixed for 16 months.
I have almost no experience with dbus, so at the moment I cannot be of much help. Can you point me to some documentation where I can better understand the dbus/systemd business?

(In reply to Giacomo Comes from comment #4)
> (In reply to Fabian Vogt from comment #3)
>  
> > But obexd.service needs to be dbus activated, not unconditionally started by
> > Plasma or each DE individually.
> 
> If I understand correctly, you mean that the fix has to come from the
> bluez-obexd package. Unfortunately boo#1198626 has been sitting there
> unfixed for 16 months.

Yep :-/

> I have almost no experience with dbus, so at the moment I cannot be of much
> help. Can you point me to some documentation where I can better understand
> the dbus/systemd business?

Maybe you can check how other distros do it? Maybe it's documented for bluez upstream?

I think I found the proper solution. The package bluez-obexd does already have all what is required and it doesn't need to be changed (it is identical to the fedora rpm). What is missing is to automatically enable the user obex.service.

This is done by adding the line:
  enable obex.service
in the file /usr/lib/systemd/user-preset/95-default-SUSE.preset (package systemd-presets-common-SUSE)

With such change in place, and by making bluedevil5 require bluez-obexd, the problem is solved. If you don't have objections, I'll prepare and submit the changes for bluedevil5 and systemd-presets-common-SUSE.

(In reply to Giacomo Comes from comment #6)
> I think I found the proper solution. The package bluez-obexd does already
> have all what is required and it doesn't need to be changed (it is identical
> to the fedora rpm). What is missing is to automatically enable the user
> obex.service.
> 
> This is done by adding the line:
>   enable obex.service
> in the file /usr/lib/systemd/user-preset/95-default-SUSE.preset (package
> systemd-presets-common-SUSE)
> 
> With such change in place, and by making bluedevil5 require bluez-obexd, the
> problem is solved. If you don't have objections, I'll prepare and submit the
> changes for bluedevil5 and systemd-presets-common-SUSE.

That would require a review by the security team.

All the "enabling" of the service does is create an alias of dbus-org.bluez.obex.service to obex.service, which seems weird. Are there any other providers of this service? IMO /usr/share/dbus-1/services/org.bluez.obex.service needs to be changed to use SystemdService=obex.service instead, then no preset needs to be changed.

> That would require a review by the security team.
> 
> All the "enabling" of the service does is create an alias of
> dbus-org.bluez.obex.service to obex.service, which seems weird. Are there
> any other providers of this service? IMO
> /usr/share/dbus-1/services/org.bluez.obex.service needs to be changed to use
> SystemdService=obex.service instead, then no preset needs to be changed.

I think upstream decided to implement /usr/share/dbus-1/services/org.bluez.obex.service the way it did because the user then have the option to enable or disable the dbus obex service. Previously is was always enabled and the user could not disable it (I think).

About the review by the security team, are you sure that it is required?
It is not like a new dbus services is being introduced. In Leap 15.4 the obexd dbus service was already there and enabled by default. In Leap 15.5 it is necessary to add: enable obex.service to systemd-presets-common-SUSE to enable it, but I don't see how the final result is different from Leap 15.4 and why the security team should be opposed to it.

(In reply to Giacomo Comes from comment #8)
> > That would require a review by the security team.
> > 
> > All the "enabling" of the service does is create an alias of
> > dbus-org.bluez.obex.service to obex.service, which seems weird. Are there
> > any other providers of this service? IMO
> > /usr/share/dbus-1/services/org.bluez.obex.service needs to be changed to use
> > SystemdService=obex.service instead, then no preset needs to be changed.
> 
> I think upstream decided to implement
> /usr/share/dbus-1/services/org.bluez.obex.service the way it did because the
> user then have the option to enable or disable the dbus obex service.
> Previously is was always enabled and the user could not disable it (I think).

The only reason to use an `Alias` is because there could be multiple providers.

> About the review by the security team, are you sure that it is required?
> It is not like a new dbus services is being introduced. In Leap 15.4 the
> obexd dbus service was already there and enabled by default. In Leap 15.5 it
> is necessary to add: enable obex.service to systemd-presets-common-SUSE to
> enable it, but I don't see how the final result is different from Leap 15.4
> and why the security team should be opposed to it.

I'm not entirely sure. It depends on whether they also add the preset file checksum to rpmlint.

IMO using an alias for this is unnecessary, the dbus service file should just activate obexd directly. This would fix this everywhere without having to enable any service.

> The only reason to use an `Alias` is because there could be multiple
> providers.

I did find the message in the linux-bluetooth mailing list about why the alias line was introduced. See these messages:
  https://marc.info/?t=133720198500001&r=1&w=4
As I supposed, the alias is there to allow enable/disable of the service using systemd and that was the way fedora was doing it before it was officially implemented in bluez.

What do you think? Should I keep the upstream way, or do I modify the dbus obex.service?