Re: F29 System Wide Change: Enable dbus-broker
On Tue, Mar 13, 2018 at 01:38:24PM +0100, Tom Gundersen wrote: > On Fri, Feb 23, 2018 at 7:59 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote: > >> Proposed System Wide Change: Enable dbus-broker > >> https://fedoraproject.org/wiki/Changes/EnableDbusBroker > > > > What about renaming this to DbusBrokerAsTheDefaultDbusImplementation? > > > > "Enable" correctly describes the technical operation (systemctl invocation), > > but it isn't obvious just from the title that this is about replacing > > normal dbus daemon. > > Will do. > > >> == Scope == > >> * Proposal owners: > >> ** Fix regressions. > >> ** Enabledbus-broker.service in system and user-global context of > >> systemd (via systemd presets). > > > >> ** Pull in dbus-broker package from dbus package. > > I'm not sure if this is the correct way to do this. People might want > > to install systems with just normal dbus (e.g. in containers or minimal > > installations). It'd be better to update comps [1] to pull in dbus-broker > > instead of dbus into @Standard. > > > > [Based on our preeliminary discussions] > > This replaces the system wide bus and user busses. > > What about the at-spi2 private dbus instance? > > I have submitted a patch to enable at-spi2 to use dbus-broker in > addition to dbus-daemon. > > > Would dbus-broker be fast > > enough to change gdm to use the user bus? > > /gdm/at-spi2/ ? Yes, not sure what happened there. > A priori, I would have thought so, but I have not tried to reproduce > their benchmarks, so I can't say for certain. > > > Do you have plans to replace this last use too? > > It is certainly possible, but I see this as an orthogonal issue to > providing the system/user bus so it is not something we have looked > into (apart from making sure it is possible), and ultimately it is up > to the at-spi2 maintainers what bus implementation they want to depend > on. FTR: https://github.com/GNOME/at-spi2-core/pull/2 From the point of view of the whole distro, it makes a lot of sense to switch all uses. Maybe not all at once, to make it easier to diagnose regressions, but in the long term. Carrying two implementations increases the disk and memory footprint, the attack and bug surface, the number of updates, and hence the amount of testing. In this case none of those costs are very big, but since dbus runs pretty much everywhere, it still makes sense to (plan to) minimize them. > > If dbus-broker becomes the default like described in the Change page, > > what other dependencies on dbus will remain? > > On the daemon itself, none to my knowledge (assuming my at-spi2 patch > is merged). Great! That's the answer I was hoping for ;) > > Since this is already testable [2], what about asking for testing on > > devel-announce@ and test-announce@ ? This is a pretty big change, and > > I don't we can make the decision to use this by default without > > widespread testing. > > Will do. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Enable dbus-broker
On Fri, Feb 23, 2018 at 7:59 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote: >> Proposed System Wide Change: Enable dbus-broker >> https://fedoraproject.org/wiki/Changes/EnableDbusBroker > > What about renaming this to DbusBrokerAsTheDefaultDbusImplementation? > > "Enable" correctly describes the technical operation (systemctl invocation), > but it isn't obvious just from the title that this is about replacing > normal dbus daemon. Will do. >> == Scope == >> * Proposal owners: >> ** Fix regressions. >> ** Enabledbus-broker.service in system and user-global context of >> systemd (via systemd presets). > >> ** Pull in dbus-broker package from dbus package. > I'm not sure if this is the correct way to do this. People might want > to install systems with just normal dbus (e.g. in containers or minimal > installations). It'd be better to update comps [1] to pull in dbus-broker > instead of dbus into @Standard. > > [Based on our preeliminary discussions] > This replaces the system wide bus and user busses. > What about the at-spi2 private dbus instance? I have submitted a patch to enable at-spi2 to use dbus-broker in addition to dbus-daemon. > Would dbus-broker be fast > enough to change gdm to use the user bus? /gdm/at-spi2/ ? A priori, I would have thought so, but I have not tried to reproduce their benchmarks, so I can't say for certain. > Do you have plans to replace this last use too? It is certainly possible, but I see this as an orthogonal issue to providing the system/user bus so it is not something we have looked into (apart from making sure it is possible), and ultimately it is up to the at-spi2 maintainers what bus implementation they want to depend on. > If dbus-broker becomes the default like described in the Change page, > what other dependencies on dbus will remain? On the daemon itself, none to my knowledge (assuming my at-spi2 patch is merged). > Since this is already testable [2], what about asking for testing on > devel-announce@ and test-announce@ ? This is a pretty big change, and > I don't we can make the decision to use this by default without > widespread testing. Will do. Cheers, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Enable dbus-broker
On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote: > Proposed System Wide Change: Enable dbus-broker > https://fedoraproject.org/wiki/Changes/EnableDbusBroker What about renaming this to DbusBrokerAsTheDefaultDbusImplementation? "Enable" correctly describes the technical operation (systemctl invocation), but it isn't obvious just from the title that this is about replacing normal dbus daemon. > == Scope == > * Proposal owners: > ** Fix regressions. > ** Enabledbus-broker.service in system and user-global context of > systemd (via systemd presets). > ** Pull in dbus-broker package from dbus package. I'm not sure if this is the correct way to do this. People might want to install systems with just normal dbus (e.g. in containers or minimal installations). It'd be better to update comps [1] to pull in dbus-broker instead of dbus into @Standard. [Based on our preeliminary discussions] This replaces the system wide bus and user busses. What about the at-spi2 private dbus instance? Would dbus-broker be fast enough to change gdm to use the user bus? Do you have plans to replace this last use too? If dbus-broker becomes the default like described in the Change page, what other dependencies on dbus will remain? Since this is already testable [2], what about asking for testing on devel-announce@ and test-announce@ ? This is a pretty big change, and I don't we can make the decision to use this by default without widespread testing. [1] https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in [2] https://fedoraproject.org/wiki/Changes/EnableDbusBroker#How_To_Test Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F29 System Wide Change: Enable dbus-broker
Proposed System Wide Change: Enable dbus-broker https://fedoraproject.org/wiki/Changes/EnableDbusBroker Owner(s): * David Herrmann * Tom Gundersen Enable dbus-broker.service to use dbus-broker as system and session message bus backend. == Detailed description == The dbus-broker project is an implementation of a message bus as defined by the D-Bus specification. Its aim is to provide high performance and reliability, while keeping compatibility to the D-Bus reference implementation. It is exclusively written for linux systems, and makes use of many modern features provided by recent linux kernel releases. The main focus points of dbus-broker are reliability, scalability and security. The dbus-broker project tries to improve on these points over dbus-daemon, and thus provide a better alternative. And in-depth analysis can be found in the initial [https://dvdhrm.github.io/rethinking-the-dbus-message-bus/ announcement] of dbus-broker. An excerpt: * [https://github.com/bus1/dbus-broker/wiki/Accounting Accounting]: dbus-broker maintains per-user accounting, including inter-user quotas. This guarantees that no single user can cause irregularly high memory consumption in the daemon. Unlike dbus-broker, dbus-daemon accounts memory in a multi-tier system, based on plain resource counters on users, connections, and other resources. The multi-tier system suffers from resource-chaining-exhaustion, where clients effectively circumvent the accounting by creating multiple connections/objects, which themselves grant them each a new set of quotas. The [https://github.com/bus1/dbus-broker/wiki/Accounting single-tier accounting] scheme of dbus-broker avoids this, while at the same time adding inter-user quotas to prevent misuse even across clients. * [https://github.com/bus1/dbus-broker/wiki/Reliability Reliability]: While D-Bus is used on reliable transports, dbus-daemon might still silently drop messages and given circumstances. This is the only possible solution dbus-daemon has, given several of its runtime guarantees. The dbus-broker project changed the architecture of the bus daemon to a degree, that it can provide many [https://github.com/bus1/dbus-broker/wiki/Reliability guarantees], including that no message will be silently, or unexpectedly, dropped. * [https://github.com/bus1/dbus-broker/wiki/Scalability Scalability]: The message bus broker is a crucial infrastructure on modern linux system, which is a hot-path for almost all IPC going on. Hence, the broker should perform fast and be scalable to its users. dbus-daemon has several **global** data-structures that affect the overall scalability of independent message transactions. dbus-broker does not employ any global data-structures (unless required by the spec), as such any message transaction is only affected by the data provided by the involved peers. Moreover, even for spec-defined global behavior, dbus-broker avoids global data-structures, unless clients actually make use of these obscure features. In several other cases, dbus-daemon scales O(n) time looking up message targets and related data. dbus-broker runs all these in O(log(n)) time. * Linux-specific: The dbus-broker project was explicitly designed for linux system, making use of many linux-specific APIs and behavior. This allows mitigation of several possible DoS attacks. == Scope == * Proposal owners: ** Fix regressions. ** Enabledbus-broker.service in system and user-global context of systemd (via systemd presets). ** Pull in dbus-broker package from dbus package. * Other developers: ** Watch for regressions * Release engineering: [https://pagure.io/releng/issues/7262 #7262] ** List of deliverables: N/A * Policies and guidelines: No changes needed. * Trademark approval: No changes needed. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
