Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Simon McVittie]

On Sat, 03 Dec 2016 at 11:18:43 +0530, MohanR wrote:
> I'm looking through this --enable-user-session in dbus-daemon. Even if
> I enable that option, how can I retrive uniq DBUS_SESSION_BUS_ADDRESS
> from systemd started dbus-daemon to pass it to gnome-session?

I suggest taking a look at how it has been done in an OS distribution that
integrates --enable-user-session, such as Debian (with the dbus-user-session
package), Fedora or Arch Linux.

The socket used for the systemd-started dbus-daemon is predictable per-uid,
and recent versions of the major D-Bus implementations (libdbus, GDBus,
sd-bus) all try that socket before autostarting a new one.

Setting DBUS_SESSION_BUS_ADDRESS is only necessary to be nice to minor
D-Bus implementations (ndesk-dbus, dbus-java, etc.) or programs that
second-guess how D-Bus works (which currently includes gnome-session,
).

S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[MohanR]

On Fri, 2016-12-02 at 12:28 +, Simon McVittie wrote:
> Does this mean your user is trying to be physically present in two
> places
> at the same time? How is this a useful thing to do? :-)

I thought the same when I came across this requirement. People
explained me that the admins who are going to use our solution will
mostly be Windows Admins and they are scared (or lazy) to create
different accounts for each people. They also said this kind of setup
possible in Windows (but I don't know exactly how it works) and they
will require that kind of setup in Linux too.

> pam_systemd does not do this unless you have configured dbus-daemon
> to provide one bus per logind user-session
> (./configure --enable-user-session), which is not the default.
> Either you or your OS vendor have explicitly chosen this model: if
> that
> doesn't match your requirements, you need to revert this choice.
> 
> If you require multiple D-Bus sessions per logind user-session, you
> must
> either configure dbus without --enable-user-session (the default is
> equivalent to --disable-user-session), or mask or remove the
> dbus.service and dbus.socket systemd user units that are installed
> by enabling that option (/usr/lib/systemd/dbus.*).

I'm looking through this --enable-user-session in dbus-daemon. Even if
I enable that option, how can I retrive uniq DBUS_SESSION_BUS_ADDRESS
from systemd started dbus-daemon to pass it to gnome-session?

I think this is a silly requirement and will make our display-manager
stop user starting two sessions by checking with logind whether that
user already have a graphical session.

Thanks,
Mohan R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Jóhann B . Guðmundsson]

On 12/02/2016 12:28 PM, Simon McVittie wrote:


Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do?:-)


Clones are very useful things to have.

You just sit a drink a pina colada in hut in bora bora while they do all 
the hard work ;)


JGB
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Simon McVittie]

On Fri, 02 Dec 2016 at 13:58:01 +0530, Mohan R wrote:
> Let say if a user already have a session(session0) in a seat (customseat0) and
> he want to start another session in another seat (customseat1).

Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do? :-)

> Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS 
> for
> every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is
> there any way to ask 'systemd --user' to provide different
> DBUS_SESSION_BUS_ADDRESS to the childs?

More background on user-sessions in general:
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

pam_systemd does not do this unless you have configured dbus-daemon
to provide one bus per logind user-session
(./configure --enable-user-session), which is not the default.
Either you or your OS vendor have explicitly chosen this model: if that
doesn't match your requirements, you need to revert this choice.

If you require multiple D-Bus sessions per logind user-session, you must
either configure dbus without --enable-user-session (the default is
equivalent to --disable-user-session), or mask or remove the
dbus.service and dbus.socket systemd user units that are installed
by enabling that option (/usr/lib/systemd/dbus.*).

The user-session support in dbus is designed to be easy to enable or
disable by adding/removing packages, if your OS vendor packages it
suitably. For example, in Debian (including derivatives like Ubuntu),
/usr/lib/systemd/dbus.* are packaged separately in the dbus-user-session
package, so you can remove that package to go back to the older model.

If your OS vendor has not packaged dbus like that, perhaps ask them to
look at how it's done in Debian? Or if they have deliberately chosen
not to support multiple D-Bus sessions per logind user-session, then
that OS distribution is not suitable for your requirements, and you
need to change either your requirements or your OS distribution.

Regards,
S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Mantas Mikulėnas]

On Fri, Dec 2, 2016 at 10:28 AM, Mohan R  wrote:

> Hi,
>
> I'm working on a display-manager for a multiseat environment. Here is how
> we use logind
>
> 1. create new seat through udev
> 2. we set the XDG_SEAT in pamenv before calling pam_open_session()
> 3. we take XDG_SESSION_ID, XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS
> from pam_systemd
>
> Let say if a user already have a session(session0) in a seat (customseat0)
> and he want to start another session in another seat (customseat1). Our
> display manager would get the same DBUS_SESSION_BUS_ADDRESS from
> pam_systemd for session1.
>
> As we cannot use the same address for two sessions, we have to start
> dbus-session manually. Using the address provided by dbus-session as
> DBUS_SESSION_BUS_ADDRESS, we then proceed with starting gnome-keyring and
> gnome-session.
>
> Problem is, processes forked by 'systemd --user' will have
> DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" but processes
> forked by gnome-session will have DBUS_SESSION_BUS_ADDRESS=$
> DBUS_SESSION_PROVIDED_ADDRESS.
>
> Is there any way to make pam_systemd provides uniq
> DBUS_SESSION_BUS_ADDRESS for every session (may be
> unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is there any way to
> ask 'systemd --user' to provide different DBUS_SESSION_BUS_ADDRESS to the
> childs?
>

No, only one graphical session at a time is supported. While you can start
additional sessions using `dbus-run-session` or the old `dbus-launch` (and
have them run independently, "traditional way"), systemd --user will only
ever use the main user bus.

Also, if you made systemd specify different bus envvars for different
services, you wouldn't be able to start the same service for *both*
sessions at once...

(*Technically,* I suppose it would be possible to make logind start
per-session instances of --user and so on and so on, but as it is nothing
like that is supported.)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Mohan R]

Hi,

I'm working on a display-manager for a multiseat environment. Here is how
we use logind

1. create new seat through udev
2. we set the XDG_SEAT in pamenv before calling pam_open_session()
3. we take XDG_SESSION_ID, XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS
from pam_systemd

Let say if a user already have a session(session0) in a seat (customseat0)
and he want to start another session in another seat (customseat1). Our
display manager would get the same DBUS_SESSION_BUS_ADDRESS from
pam_systemd for session1.

As we cannot use the same address for two sessions, we have to start
dbus-session manually. Using the address provided by dbus-session as
DBUS_SESSION_BUS_ADDRESS, we then proceed with starting gnome-keyring and
gnome-session.

Problem is, processes forked by 'systemd --user' will have
DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" but processes
forked by gnome-session will have
DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_PROVIDED_ADDRESS.

Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS
for every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)?
or is there any way to ask 'systemd --user' to provide different
DBUS_SESSION_BUS_ADDRESS to the childs?

Thanks,
Mohan R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel