By default, the D-Bus system bus is locked down tightly. Each service is
expected to provide its own bus configuration that tells D-Bus what is and is not
allowed. Our configurations are stored in
etc-conf/com.redhat.RHSM1.Facts.conf. If you add a new interface, you must
edit the appropriate file to expose it.
For example, let’s suppose we add a new interface
that reports on a consumer’s installed products. We would need to edit
etc-conf/com.redhat.RHSM1.conf and add a stanza like
<allow send_destination="com.redhat.RHSM1" send_interface="com.redhat.RHSM1.Config"/>
under the default context policy element.
You may want to develop subscription-manager without having its RPMs installed.
For D-Bus development, you have to copy the two mentioned
.conf files to
/etc/dbus-1/system.d/. After adding or editing them, you have to tell D-Bus
to reload the configuration for the changes to take effect:
$ sudo systemctl reload dbus
Then you can start the server by running
$ sudo PYTHONPATH=src/ python3 -m subscription_manager.scripts.rhsm_service --verbose
I find the easy way to test is with
d-feet which is a graphically application
that allows you to browse D-Bus objects and the interfaces they make available.
d-feet is only available in Fedora. So when testing on Red Hat
Enterprise Linux systems, my tool of choice is
dbus-send. The manual page for
dbus-send is fairly good, but in essence you tell
dbus-send the bus to use,
the bus name to talk to and the bus method (including the interface) to call
and then any required arguments. Here’s how to call the
GetAll method for example.
$ sudo dbus-send --system --print-reply --dest=com.redhat.RHSM1 '/com/redhat/RHSM1/Config' com.redhat.RHSM1.Config.GetAll
sudo is required since I’m talking to the system bus.
The services can be brought up without installing them and all the requisite
configuration files by running the relevant executable in the
For example, running
bin/rhsm-service will bring up the
object. Pass in the
-h flag for information on the options the script can
take. You can define verbosity level, a different bus name, and specify which
bus (system or session) to use.
I find d-feet to be the easiest to use for just ad-hoc tests. One of the CLI tools is the better choice if you’re going to be running the same command over and over.
certmongerhas a D-Bus api that models X.509 certs (
dnfdaemonhas an interface to packages/repos (
telepathyhas and extensive D-Bus API and python bindings (
seahorseis a keyring tool with D-Bus interfaces (
kwallethas a large D-Bus API (
org.freedesktop.Udisks2is a good example of using the
org.fedoraproject.FirewallD1is another large API