|
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon McVittie:
Wrong tense. (-: I already gave it to people with nosh version 1.20 back in September 2015. The external configuration import subsystem sets up a user-dbus service bundle for each "real person" user account that it recognizes (i.e. not user accounts with nologin or with well-known Debian/FreeBSD/PC-BSD system account names). I fixed up the FreeBSD side, to not attempt the malfunctioning address=systemd:, in nosh version 1.22 in November 2015. No, I do not need a PAM module. In terms of needs, what I actually need is for you to respect the final paragraph of the environment section of the XDG Base Directory Specification, if you are not respecting it already, which I hope that you are but suspect that you might not be. * https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables As for what I would like, I'd like you (where that's plural, including Joe Marcus Clarke or whomever else) to please make either address=systemd: or address=unix:runtime=yes work in your program on FreeBSD/PC-BSD/OpenBSD. If for the former you're relying upon a library that the systemd authors have gradually made less and less cross-platform since the dizzy heights of "should compile fine on the most exotic Unixes" in 2010, then 2016 might be the time to look at Cameron T. Norman's or Pierre-Yves Ritschard's code instead. (-: * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#CrippledAdoptionIn https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon McVittie:
It makes it more BSD-friendly, too. As I said, make address=systemd: work, and the nosh toolset (for one) gets you the ability to outright *not care* about what the sockets are in the D-Bus broker at all, as it's perfectly capable of handing your program already-open file descriptors to listening sockets and a couple of environment variables. systemd most definitely did not invent *that* idea, after all. The Linux service bundles (built as aforementioned by the external configuration import subsystem) do exactly that. The FreeBSD/PC-BSD/OpenBSD service bundles could, were it not for the fact that your program doesn't have a way of being told to use the protocol. In fact, they *actually do* open the socket and pass it to your program with the environment variables. But there's no way to tell your program that that is happening. Please make your program actually capable of understanding address=systemd: on FreeBSD/PC-BSD/OpenBSD. In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon McVittie:
PCDMd, kdm, gdm, and lxdm on PC-BSD have some fairly poor behaviour in this area, such as for each session starting up a Desktop Bus broker running as the superuser in addition to starting one up as the logged-in user, because every man and his dog seems to consider it xyr responsibility to spawn off a Desktop Bus broker process. They ignore already-provided broker addresses in several cases, and kdeinit adds even more "fun" to the mixture. One can run PCDMd, kdm, gdm, and lxdm under nosh service management, and it would be good for the programs in the login session(s) to just expect "/run/user/$UID/..." sockets, as one already obtains from running "user" Desktop Bus brokers under nosh service management. In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon McVittie:
Quite! Are you prepared, five years on, to go another round with Lennart Poettering then? (-: * https://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html
|