Re: Should libpam-elogind Provide libpam-systemd ?

[Felipe Sateler]

On Mon, Nov 5, 2018 at 10:32 AM Ian Jackson 
wrote:

> So I promised that I would summarise.  I found that trying to write a
> summary involved me doing a bit of research, and that not everyone in
> the thread seemed to agree about everything.  To make a coherent
> picture I had to make some suppositions, which may well be wrong.
>
> So I'd appreciate a review of the draft summary/conclusions below.
>
>
> Clear recommendations from the thread:
>
> Don't provide libpam-systemd.
> Do provide a separate pam module, rather than pam_systemd.so.
> File bugs against packages whose dependencies must be updated.
>

I agree providing libpam-systemd is wrong. As noted elsewhere on this
thread, libpam-systemd provides two related services:

1. systemd-logind integration
2. systemd --user integration

Therefore I think we need two virtual packages, to signal the dependency on
each service. That way, libpam-elogind can provide the first one but not
the latter. Packages requiring (or wanting) can Depend (or Recommend) the
latter. As usual for multiple providing packages, there should be a
default-foo alternative listed first.

I'll leave the hard problem of naming the packages to others :)


> On Conflicts and/or switchability:
>
> There was a suggestion that libpam-elogind should Conflict
> libpam-systemd, to avoid complicating debugging or situations where
> they might interfere.  Conversely it was suggested that this might
> impede switching init systems by installing different sets of
> packages, although it's not clear to me whether this is actually a
> problem.  There was one suggestion to write yet another pam module
> which would switch between pam_elogind and pam_systemd according to
> whichever was available.
>
> I think experimentation will show which of these approaches is best.
>

Won't elogind have to conflict with systemd anyway? Or how could the same
dbus name be owned by multiple providers?


>
> On the meaning of dependencies on libpam-systemd:
>
> Some people suggested that usually a dependency on libpamd-systemd
> would usually imply a dependency on systemd --user.  Having looked at
> the packages in question (searching sid for Depends or Recommends
> only) that seems to sometimes be the case, but only rarely.
>
> Looking at the list I think a manual review of the proposed MBF list
> would be sensible (and of course there would be a formal MBF proposal
> here on -devel) but in most cases testing would not be needed.
>

Sometimes it might me a bug, sometimes not. I think having both virtual
packages, and filing bugs when the systemd --user integration is not
required/too strictly enforced is the right solution.

-- 

Saludos,
Felipe Sateler

Re: Should libpam-elogind Provide libpam-systemd ?

[Felipe Sateler]

On Tue, 06 Nov 2018 12:29:10 +, Ian Jackson wrote:

> Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd
> ?"):
>> Similarly, I think pulseaudio's Recommends is because pulseaudio is
>> frequently a systemd user service (one per uid). One of pulseaudio's
>> control protocols is that it can be sent commands via D-Bus IPC, but
>> again, that isn't going to work if the D-Bus session bus is
>> shorter-lived than the pulseaudio daemon.
> 
> If you have multiple concurrent login sessions they each need their own
> pulseaudio setup, because sounds from one session should not appear in
> another.

No they don't, because pulseaudio can route different streams to 
different output sinks. However, I agree that this handling is not 
optimal right now, and you may end up with sound going somewhere 
unexpected (but you can change it back!). I think discussion and patches 
would be more than welcome upstream. However, please note that "ssh-ing 
into the sound server and changing the volume" is something you can do 
with the per-user pulseaudio but not with a per-session one (or at least, 
not without some gymnastics).

I think there are three interrelated issues to have in mind when 
discussing this:

1. Services should be automatically started, be that on first login (for 
the per-user model), or on each login (for the par-session model). The 
only solution we have right now is either systemd --user, or have people 
put stuff in their login shell, because getty won't start dbus or 
pulseaudio. Pulseaudio has an autostart feature to work around this 
problem.

2. Access to shared resources should have reasonable mediation. Access to 
devices is usually granted per-user. That is, a given user either has or 
doesn't have access to /dev/snd/foo. There is currently no way to give 
access to a certain set of processes but not others, if all the processes 
are owned by the same user. With this plus autostart as noted above, you 
get multiple pulseaudio instances that fight each other for sound device 
access.

3. Supporting multiple instances per user is harder than allowing just 
one. Dconf was already mentioned in this regard, and it is reasonable to 
expect dconf to only allow one process per user, the same way you 
wouldn't expect to be able to run multiple mysqld processes against the 
same on-disk database. Similarly, any user service that writes anywhere 
is bound to have these synchronization problems.

Solving problems 2 and 3 is hard. I think it is quite reasonable for some 
upstreams to have decided that they will only support the per-user model. 
In fact, these problems are so hard that there are suggestions that 
access to sound devices should no longer be granted to users but to a 
single system-wide daemon (pulseaudio itself is apparently not really 
viable for this role for other reasons). Problems for blind users when 
espeakup and pulseaudio fight each other for device access is one reason 
this might be a good idea.

With my pulseaudio maintainer hat on, I welcome a bug report, but please 
be explicit on what you actually think the bug is. If the bug is related 
to problems 2 or 3, I don't think I can help you much. If you think the 
bug is just about avoiding broken Recommends, then please see #883756, as 
it is not quite trivial to solve (I want systemd --user integration by 
default, and unfortunately this currently means manual action if you want 
to disable it).

-- 
Saludos,
Felipe Sateler

Re: Should libpam-elogind Provide libpam-systemd ?

[Ian Jackson]

Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd ?"):
> I don't want this to turn into "us vs. them", and I'm trying not to get
> drawn into a debate about the merits of these approaches because I can
> already see how much time and motivation that will burn if it happens,
> most likely leaving each of us angry with the other and without any
> actually changed opinions.

Thanks.  I wanted to say separately that appreciate that and I
appreciate your technical input, even if I may not agree with
everything.

> I've gone to some lengths to make sure that
> the conceptual model implied by dbus-user-session is not mandatory in
> Debian (which is why we have it as a separate package at all);

That is also helpful.  Thank you.

Ian.

Re: Should libpam-elogind Provide libpam-systemd ?

[Ian Jackson]

Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd ?"):
> On Mon, 05 Nov 2018 at 13:32:40 +, Ian Jackson wrote:
> > pinentry-gnome3 and pulseaudio seem wrong to me.  PINs should not be
> > shared between login sessions and sound control should be per-session,
> > not per-uid.
> 
> First of all, these are Recommends, not Depends.

I don't think violating Recommends is a practical alternative for our
non-systemd users.  The packaging system makes that too hard.

> If we had a way to spell "Recommends: dbus-user-session if init is
> systemd" or "Depends: dbus-user-session if init is systemd" then these
> packages could use it, but as far as I'm aware we don't, so they can't.

Recommends: dbus-user-session | sysvinit-core ?

We can probably find another way of spelling this.  But I remain to be
convinced that the three uses I found are correct even on those terms.

> The pinentry-gnome3 Recommends is because gpg-agent is shared between
> login sessions, so anything that is invoked by gpg-agent had better
> have all its dependencies similarly shared.

I don't understand how anyone could expect this to work, when there
are multiple login sessions.  Popping up a pin entry prompt on a
different display to the one the user is currently typing at is not
useful.  Obviously there are fundamental architectural problems with
the gnupg2 agent and there is little point rehearsing them again, but
starting the agent on demand does work better because pinentry
requests go to the right place.

But since pinentry-gnome3 comes from src:gnupg2, this is all part of
the same source package: the bug is in gnupg2 and should be fixed
there.

> Similarly, I think pulseaudio's Recommends is because pulseaudio is
> frequently a systemd user service (one per uid). One of pulseaudio's
> control protocols is that it can be sent commands via D-Bus IPC, but
> again, that isn't going to work if the D-Bus session bus is shorter-lived
> than the pulseaudio daemon.

If you have multiple concurrent login sessions they each need their
own pulseaudio setup, because sounds from one session should not
appear in another.

> > I'm not sure about rygel but it doesn't seem likely to me that this
> > dependency on dbus-user-session is necessary.  Perhaps there is
> > another way to implement this on non-systemd systems.
> 
> It's another Recommends. Rygel is a long-running per-user D-Bus service
> that requires a D-Bus session bus with a scope at least as long as rygel
> itself; on systemd systems, making it a `systemd --user` service is
> desirable; but that user-service can't start without dbus-user-session.
> This would be "Depends: dbus-user-session if init is systemd" if we had
> a way to spell that in dependencies.

This still doesn't explain to me why Rygel is per-user rather than
per-login-session.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Should libpam-elogind Provide libpam-systemd ?

[Simon McVittie]

On Mon, 05 Nov 2018 at 13:32:40 +, Ian Jackson wrote:
> When a package does not want, specifically, this sharing, the
> dependency should be on
>default-dbus-session-bus | dbus-session-bus

This is right for packages that don't particularly care whether the
session bus is per-uid or per-login-session and want to follow the
default chosen globally for Debian, including most D-Bus session clients
and services.

> or maybe the older form which I found in some packages in sid:
>dbus-user-session | dbus-x11
> (xdg-desktop-portal-gtk).

I don't remember why I set up xdg-desktop-portal-gtk like this, tbh.
It's probably a bug. I think I probably added that dependency when
dbus-user-session wasn't yet the default/preferred form of session bus,
because xdg-desktop-portal-gtk benefitted significantly in some way
from using it.

Depends: dbus-user-session | dbus-session-bus would perhaps make sense
for packages that strongly prefer the session-bus-per-uid model but can
work either way, as a way to make it explicit that they would prefer
dbus-user-session even if that wasn't Debian's default.

Depends: dbus-user-session (with no alternative) makes sense for
packages that can only work in one-session-bus-per-uid world. Those are
systemd-specific for the forseeable future.

Recommends: dbus-user-session makes sense for packages that have
significantly degraded functionality without one-session-bus-per-uid,
but can be made to work by unusual or non-default configuration.

> The value of this feature is IMO questionable.

There are various reasonable things that you might assume can be done
with D-Bus, but that turn out not to work, or can work but only badly,
when the session bus is not shared in this way. There are also things
that can work with one bus per login session, but can't work or can't
work well with one bus per uid (most of them involve multiple parallel
graphical login sessions). Can we agree to disagree on which of those
two classes is the more important one?

I don't want this to turn into "us vs. them", and I'm trying not to get
drawn into a debate about the merits of these approaches because I can
already see how much time and motivation that will burn if it happens,
most likely leaving each of us angry with the other and without any
actually changed opinions. I've gone to some lengths to make sure that
the conceptual model implied by dbus-user-session is not mandatory in
Debian (which is why we have it as a separate package at all); it would
have made D-Bus maintenance much simpler if I'd said that from now on,
one D-Bus session per uid per machine was the only supported situation,
as it is in (for example) Fedora and Arch Linux.

> pinentry-gnome3 and pulseaudio seem wrong to me.  PINs should not be
> shared between login sessions and sound control should be per-session,
> not per-uid.

First of all, these are Recommends, not Depends. If you are confident that
your use of these packages (if you even use these packages) can work
without a per-(uid,machine)-scoped D-Bus session bus, you're welcome to
not satisfy the Recommends. Not having `systemd --user` on the class of
systems that these packages target is an unusual configuration, so I
think it's reasonable for Recommends to assume it.

If we had a way to spell "Recommends: dbus-user-session if init is
systemd" or "Depends: dbus-user-session if init is systemd" then these
packages could use it, but as far as I'm aware we don't, so they can't.

The pinentry-gnome3 Recommends is because gpg-agent is shared between
login sessions, so anything that is invoked by gpg-agent had better
have all its dependencies similarly shared. pinentry-gnome3 is one of
several possible implementations of a PIN/passphrase/secret prompt; it
is implemented using D-Bus IPC (it communicates with GNOME Shell, to ask
GNOME Shell to prompt for PINs/passphrases/secrets using a system-modal
dialog). This works very poorly if the D-Bus session is shorter-lived
than the gpg-agent, because the gpg-agent receives its environment
variables on startup (including the DBUS_SESSION_BUS_ADDRESS that will
be inherited by its shorter-lived pinentry subprocesses) and does not
have a way to replace them. (#801247)

Similarly, I think pulseaudio's Recommends is because pulseaudio is
frequently a systemd user service (one per uid). One of pulseaudio's
control protocols is that it can be sent commands via D-Bus IPC, but
again, that isn't going to work if the D-Bus session bus is shorter-lived
than the pulseaudio daemon.

> I'm not sure about rygel but it doesn't seem likely to me that this
> dependency on dbus-user-session is necessary.  Perhaps there is
> another way to implement this on non-systemd systems.

It's another Recommends. Rygel is a long-running per-user D-Bus service
that requires a D-Bus session bus with a scope at least as long as rygel
itself; on systemd systems, making it a `systemd --user` service is
desirable; but that user-service can't start without 

Re: Should libpam-elogind Provide libpam-systemd ?

[Ian Jackson]

So I promised that I would summarise.  I found that trying to write a
summary involved me doing a bit of research, and that not everyone in
the thread seemed to agree about everything.  To make a coherent
picture I had to make some suppositions, which may well be wrong.

So I'd appreciate a review of the draft summary/conclusions below.


Clear recommendations from the thread:

Don't provide libpam-systemd.
Do provide a separate pam module, rather than pam_systemd.so.
File bugs against packages whose dependencies must be updated.

On Conflicts and/or switchability:

There was a suggestion that libpam-elogind should Conflict
libpam-systemd, to avoid complicating debugging or situations where
they might interfere.  Conversely it was suggested that this might
impede switching init systems by installing different sets of
packages, although it's not clear to me whether this is actually a
problem.  There was one suggestion to write yet another pam module
which would switch between pam_elogind and pam_systemd according to
whichever was available.

I think experimentation will show which of these approaches is best.


On the meaning of dependencies on libpam-systemd:

Some people suggested that usually a dependency on libpamd-systemd
would usually imply a dependency on systemd --user.  Having looked at
the packages in question (searching sid for Depends or Recommends
only) that seems to sometimes be the case, but only rarely.

Looking at the list I think a manual review of the proposed MBF list
would be sensible (and of course there would be a formal MBF proposal
here on -devel) but in most cases testing would not be needed.


On dbus-user-session:

There was considerable discussion of this.  It provides a session dbus
which is shared by all processes with the same uids.  So it differs
from (eg) dbus-x11, which provides one per graphical session.

This sharing of a single bus between different sessions is the purpose
of dbus-user-session.  Its maintainer says that its use of
libpam-systemd would not work with elogind and I see no reason to
doubt that.

When a package does not want, specifically, this sharing, the
dependency should be on
   default-dbus-session-bus | dbus-session-bus
or maybe the older form which I found in some packages in sid:
   dbus-user-session | dbus-x11
(xdg-desktop-portal-gtk).

The value of this feature is IMO questionable.  (As background, there
were assertions on -devel that modern GNOME (eg dconf) does not work
properly if the same user logs in twice in parallel.  I'm sure that
contributors to debian-init-diversity would regard such a situation as
a significant bug.  But that's out of scope right now.)

I looked for dependencies on dbus-user-session in sid and found only
these:
  pinentry-gnome3 (src:pinentry)
  pulseaudio
  rygel

Of these:

pinentry-gnome3 and pulseaudio seem wrong to me.  PINs should not be
shared between login sessions and sound control should be per-session,
not per-uid.

I'm not sure about rygel but it doesn't seem likely to me that this
dependency on dbus-user-session is necessary.  Perhaps there is
another way to implement this on non-systemd systems.

So I think we should probably file bugs right away against these three
(two at severity normal, one at severity wishlist inviting further
discussion).  I think also I may file a bug against lintian asking for
plain dependencies on dbus-user-session to get a warning.

Ian.

Re: Should libpam-elogind Provide libpam-systemd ?

[Simon McVittie]

On Mon, 05 Nov 2018 at 08:44:45 +0100, Philipp Kern wrote:
> Do you know if any idea was
> already floated somewhere on how to make this work? I.e. have multiple
> systemd user instances per user?

This is specifically not supported. `systemd --user` always has the
same semantics as the $XDG_RUNTIME_DIR that it uses: it is one per uid
per machine. If you need multiple instances of foo per uid, then foo
must either not be a systemd user service, or be an instanced user
service (e.g. you could have a foo@.service with instances like
foo@0.service for X11 display :0, if that's how foo is meant to work).

The D-Bus session bus can be configured to be either one per uid per
machine, i.e. one per `systemd --user` (install dbus-user-session)
or one per X11 display (don't install dbus-user-session, do install
dbus-x11), depending on what you think "session" should mean. This is
why the dbus-user-session package is separate from dbus: it gives you
an opt-in or opt-out for the one-per-uid semantics. In some non-Debian
distros, you don't get that choice: for example, in Arch Linux and Fedora,
there is a single dbus package that contains the equivalent of both our
dbus and our dbus-user-session.

> In our case a remote desktop is spawned in parallel to the regular one,
> in the background. That makes for all sort of weird behavior

Yes, it will tend to. Many applications and services don't really cope
gracefully with multiple instances sharing a home directory. D-Bus does,
but many of the applications and services that communicate via D-Bus
don't (in particular, dconf has last-write-wins semantics that can lose
writes, and other configuration storage mechanisms will usually have
similar behaviour).

If you want a separate foo for the GUI and the remote desktop, then foo
cannot be run as a (non-instanced) systemd user service. If you want to
share foo between the two, then it can (and probably should).

smcv

Re: Should libpam-elogind Provide libpam-systemd ?

[Paul Wise]

On Mon, Nov 5, 2018 at 4:00 PM Philipp Kern wrote:

> I.e. have multiple systemd user instances per user?

That sounds strange, something like systemd session instances and
services seems more logical to me. systemd already has session scopes
so it isn't too much of a stretch to add session instances and
services IMO.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Should libpam-elogind Provide libpam-systemd ?

[Philipp Kern]

Hi Simon,

On 03.11.2018 12:11, Simon McVittie wrote:
> However, note that if you want multiple parallel dbus-daemons per uid,
> in particular one per X11 display, then dbus-user-session is not for you,
> and you should continue to use dbus-x11 or some third party implementation
> of the dbus-session-bus virtual package instead.

we learned this the hard way and then people are confused about
systemd's session management not coming up. Do you know if any idea was
already floated somewhere on how to make this work? I.e. have multiple
systemd user instances per user?

In our case a remote desktop is spawned in parallel to the regular one,
in the background. That makes for all sort of weird behavior (what if
you want to have different settings in one of your two sessions?) and
dbus-user-session is only a part of it. But it's something users seem to
slowly expect to be working...

Kind regards and thanks
Philipp Kern

Re: Should libpam-elogind Provide libpam-systemd ?

[Simon McVittie]

On Sat, 03 Nov 2018 at 00:08:50 +0100, Adam Borowski wrote:
> On Fri, Nov 02, 2018 at 10:22:58PM +, Simon McVittie wrote:
> > libpam-elogind is very unlikely to be enough to satisfy
> > dbus-user-session's dependency, for instance, unless elogind has taken
> > an excursion into systemd-like service management while I wasn't looking.
> 
> And for that reason dbus-user-session has Depends: systemd, which describes
> this requirement just fine.  It runs systemd's user parts.

No, a dependency on systemd merely guarantees that /lib/systemd/systemd
and .../systemd-logind binaries exist. It does not provide the system
integration that dbus-user-session relies on, which is: whenever uid N has
at least one login session open, there is an XDG_RUNTIME_DIR for uid N
(created by systemd-logind), and a `systemd --user` process running as
uid N (systemd system unit user@N.service, started by pid 1 on request
from systemd-logind).

You might be misinterpreting dbus-user-session as being the component
that runs `systemd --user`? If so, it isn't - it's the other way around,
`systemd --user` runs a dbus-daemon because dbus-user-session asks it to.
To get `systemd --user`, you need a working systemd-logind (represented by
a dependency on libpam-systemd, meaning you have the necessary pam_systemd
PAM module to tell it about your login sessions), and you also need
systemd as pid 1 (which is not something we can express in dependency
relationships, but is approximated by Recommends: systemd-sysv).

If you don't have `systemd --user` working, then dbus-user-session will
not have the opportunity to start a dbus-daemon via socket activation,
which means it doesn't provide its intended "API" either.

If people who prefer elogind want to add appropriate glue to
dbus-user-session to arrange for D-Bus clients to be able to connect to
$XDG_RUNTIME_DIR/bus and find a working bus there even in the absence
of `systemd --user`, I'm open to suggestions. Implementing this would
probably require an additional PAM module that starts one dbus-daemon
per XDG_RUNTIME_DIR, or that starts a helper process that uses the
socket activation protocol to start the actual dbus-daemon on-demand,
or something; I'm not going to maintain such a thing myself, but I
wouldn't mind adding it as an alternative dependency.

However, note that if you want multiple parallel dbus-daemons per uid,
in particular one per X11 display, then dbus-user-session is not for you,
and you should continue to use dbus-x11 or some third party implementation
of the dbus-session-bus virtual package instead. Packages that use the
session bus should depend on "default-dbus-session-bus | dbus-session-bus"
so that you can continue to use dbus-x11 to satisfy their dependency,
unless they specifically rely on the "one bus per XDG_RUNTIME_DIR" model.

smcv

Re: Should libpam-elogind Provide libpam-systemd ?

[Adam Borowski]

On Fri, Nov 02, 2018 at 10:22:58PM +, Simon McVittie wrote:
> On Fri, 02 Nov 2018 at 12:20:55 -0700, Josh Triplett wrote:
> > please work with packages
> > that depend on libpam-systemd to add appropriate alternatives like
> > libpam-systemd | libpam-elogind if and *only* if they work with both.
> 
> Yes, this. libpam-elogind is very unlikely to be enough to satisfy
> dbus-user-session's dependency, for instance, unless elogind has taken
> an excursion into systemd-like service management while I wasn't looking.

And for that reason dbus-user-session has Depends: systemd, which describes
this requirement just fine.  It runs systemd's user parts.  The rest of the
world has dbus-x11 which has some important features dbus-user-session
lacks, such as the ability to login multiple times.

A package whose very description says in its title:
"simple interprocess messaging system (systemd --user integration)"
depends on systemd, that's not surprising.  So as long as no dependency
chain forces it in, all is ok.

> Some packages depending on libpam-systemd want logind's D-Bus and
> libsystemd APIs, which elogind can mostly or entirely provide; policykit-1
> is likely to be one of these.
>
> Other packages depending on libpam-systemd want systemd --user, which
> elogind can't provide, and which I'm reasonably sure people who don't
> like systemd wouldn't want anyway (if you have a reason not to want
> systemd managing system services as pid 1, then the same reason probably
> applies equally to your per-user services).

Is there a package that wants something beyond logind, yet doesn't depend on
systemd itself?  I can't seem to find any obvious candidate.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: Should libpam-elogind Provide libpam-systemd ?

[Simon McVittie]

On Fri, 02 Nov 2018 at 12:20:55 -0700, Josh Triplett wrote:
> please work with packages
> that depend on libpam-systemd to add appropriate alternatives like
> libpam-systemd | libpam-elogind if and *only* if they work with both.

Yes, this. libpam-elogind is very unlikely to be enough to satisfy
dbus-user-session's dependency, for instance, unless elogind has taken
an excursion into systemd-like service management while I wasn't looking.

Some packages depending on libpam-systemd want logind's D-Bus and
libsystemd APIs, which elogind can mostly or entirely provide; policykit-1
is likely to be one of these.

Other packages depending on libpam-systemd want systemd --user, which
elogind can't provide, and which I'm reasonably sure people who don't
like systemd wouldn't want anyway (if you have a reason not to want
systemd managing system services as pid 1, then the same reason probably
applies equally to your per-user services).

smcv

Re: Should libpam-elogind Provide libpam-systemd ?

[Russ Allbery]

Adam Borowski  writes:

> Conflicts would greatly simplify packaging, but I'm afraid we need
> coinstallability at least for upgrades.  With d-i installing systemd,
> the user needs to be able to switch to sysvinit -- and, horrors, some
> might want to go the other way.

> It'd be damage to allow two loginds running at the same time, thus what
> about:
> * the "systemd" package starts its logind only if systemd is pid 1
> * elogind starts its logind only if pid 1 is not systemd

I may be missing some complexity here, but it feels as if there should be
a PAM module that determines which logind is running and then dispatches
the PAM calls to the appropriate module for the running logind.

-- 
Russ Allbery (r...@debian.org)   

Re: Should libpam-elogind Provide libpam-systemd ?

[Adam Borowski]

On Fri, Nov 02, 2018 at 03:39:10PM -0400, Michael Stone wrote:
> On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
> > Should it also Conflict libpam-systemd ?
> 
> Does it somehow prevent the admin from configuring one or the other in pam?

Conflicts would greatly simplify packaging, but I'm afraid we need
coinstallability at least for upgrades.  With d-i installing systemd, the
user needs to be able to switch to sysvinit -- and, horrors, some might
want to go the other way.

It'd be damage to allow two loginds running at the same time, thus what
about:
* the "systemd" package starts its logind only if systemd is pid 1
* elogind starts its logind only if pid 1 is not systemd

That would handle runtime dependencies, I wonder how to handle them
apt-wise.  Alas, the only robust idea I have so far doesn't work with
multiarch, thus is worthless.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: Should libpam-elogind Provide libpam-systemd ?

[Adam Borowski]

On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?

This has been briefly discussed before: it's a quite bad idea to have
provides with same name as a real package.  This works in Devuan where
there's no libpam-systemd, but in Debian we'd want something like:
Depends: default-logind | logind
or, if a specific version is needed:
Depends: default-logind (>= 3.14.15.926) | logind (>= 3.14.15.926)
(as suggested by smcv a while ago).

I even prepared a set of packages with that dependencies, although they're
badly outdated by now:
deb http://angband.pl/debian logind main
deb-src http://angband.pl/debian logind main
Key at:
https://angband.pl/debian/pool/main/k/kilobyte-archive-keyring/kilobyte-archive-keyring_3_all.deb
or:
wget -qO- https://angband.pl/deb/archive.html|apt-key add -

If you guys still think these deps are ok, tell me so and I'll refresh the
reverse dependencies in that repo.

> (emailing the systemd maintainers since that's Providing their package
>  name, and also d-devel since I'm not sure what input others may have)

Yeah.

> In stretch this was handled on many sysvinit systems by systemd-shim.
> That is not really maintained - the version in sid right now is broken
> - and its approach means that it keeps breaking and is awkward to fix.

It never worked for me, even when it was "maintained".  All -shim did was to
fulfill dependencies without actually bringing functionality such as suspend
/etc from the GUI.  For that you had to recompile the Utopia stack against
consolekit.  Elogind on the other hand does it ok.

> In buster it looks like we are going to try to do this by using
> elogind.  elogind is not in sid yet but we already have a half-working
> prototype.

Its packaging is tailored for Devuan where there's no systemd to deal with.
On the other hand they're doing necromancy with consolekit which seems to be
a waste of time to me.

> The alternative to this Provides would seem to be an MBF requesting
> updates of all the dependencies.  (Maybe some other virtual package is
> needed.)

I'm afraid this would be needed, per smcv's suggestion.

> (Our draft package ships libpam_elogind.so, but there are some
> difficulties with pam configuration ending up referring to both
> libpam_elogind.so and libpam_systemd.so and generating warnings, and a
> few packages seem to explicitly refer to pam_systemd.so, for instance
> lightdm's /etc/pam.d/lightdm-greeter.  If we can't resolve that we may
> need to ship the pam module as libpam_systemd.so and that might
> involve Replaces as well as Conflicts.)

I have yet to test newer packages, apologies for not having done that yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away.
⠈⠳⣄ 

Re: Should libpam-elogind Provide libpam-systemd ?

[Michael Stone]

On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:

Should it also Conflict libpam-systemd ?


Does it somehow prevent the admin from configuring one or the other in 
pam?



(Our draft package ships libpam_elogind.so, but there are some
difficulties with pam configuration ending up referring to both
libpam_elogind.so and libpam_systemd.so and generating warnings, and a
few packages seem to explicitly refer to pam_systemd.so, for instance
lightdm's /etc/pam.d/lightdm-greeter.  If we can't resolve that we may
need to ship the pam module as libpam_systemd.so and that might
involve Replaces as well as Conflicts.)


I'd rather see an additional module that just calls one of the two for 
automated config (or via alternatives?), and the ability to manually 
configure anything else.

Re: Should libpam-elogind Provide libpam-systemd ?

[Josh Triplett]

Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?

Please don't, no, for multiple reasons.

First, various packages followed the widely offered advice of using
libpam-systemd as the correct package to depend on if you need systemd
services, as it incorporated the appropriate alternatives on
systemd-sysv and systemd-shim. So packages depending on libpam-systemd
may depend on more aspects of systemd than just the pam module.

Second, based on experiences with systemd-shim, I would expect that
elogind will likely be *mostly* compatible with systemd's services, but
not necessarily perfectly compatible, especially when it comes to
current features. Using a Provides would make it more difficult for
packages to handle such compatibility issues.

Please instead just continue providing a separate pam module, please
*conflict* with libpam-systemd to avoid having debugging adventures
involving one interfering with the other, and please work with packages
that depend on libpam-systemd to add appropriate alternatives like
libpam-systemd | libpam-elogind if and *only* if they work with both.

Should libpam-elogind Provide libpam-systemd ?

[Ian Jackson]

Hi.

tl/dr: would this be wrong
   Package: libpam-elogind
   Provides: libpam-systemd
and should there be a Conflicts too ?

(emailing the systemd maintainers since that's Providing their package
 name, and also d-devel since I'm not sure what input others may have)


There's an active effort now to fix some of the problems that are
evident with sysvinit in buster.[1]  We are tackling the services
provided to (primarily) desktop sessions by systemd-logind, and
specifically pam_systemd.so which AIUI is part of the machinery for
arranging that console users get permission to do various things.

In stretch this was handled on many sysvinit systems by systemd-shim.
That is not really maintained - the version in sid right now is broken
- and its approach means that it keeps breaking and is awkward to fix.

In buster it looks like we are going to try to do this by using
elogind.  elogind is not in sid yet but we already have a half-working
prototype.

elogind provides a pam module to replace pam_systemd.so.  We are
considering having libpam-elogind.deb Provide libpam-systemd.

Is there some reason that would be a bad idea ?  Should it also
Conflict libpam-systemd ?

The alternative to this Provides would seem to be an MBF requesting
updates of all the dependencies.  (Maybe some other virtual package is
needed.)

(Our draft package ships libpam_elogind.so, but there are some
difficulties with pam configuration ending up referring to both
libpam_elogind.so and libpam_systemd.so and generating warnings, and a
few packages seem to explicitly refer to pam_systemd.so, for instance
lightdm's /etc/pam.d/lightdm-greeter.  If we can't resolve that we may
need to ship the pam module as libpam_systemd.so and that might
involve Replaces as well as Conflicts.)

We would be grateful to receive technical advice and opinions - and
corrections to any wrong assumptions.  To save my colleagues on d-i-d
having to come to debian-devel I will summarise the responses.

Thanks,
Ian.

[1] If you would like to come and help with improving Debian's
support for alternatives to systemd, please join this mailman list
  http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity

We are particularly in need of more `desktoppy' expertise.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.