>>>>> "Bastian" == Bastian Blank <wa...@debian.org> writes:
Bastian> On Thu, Dec 01, 2016 at 10:43:18AM +0100, Thomas Goirand wrote:
>> > If so, yeah, that broke for most nontrivial installations in
>> stretch. After some tests, it is libpam-systemd that is pulling
Bastian> This is a bug in the dependency resolver in debootstrap.
Bastian> The easiest fix is to not use it but call apt-get install
Bastian> with all the stuff.
>> 1/ Do we really need libpam-systemd?
Bastian> If you want login, yes.
This is misleading as best I can tell. I may be getting something wrong
here, but I did try to engage with Bastian to understand the issue at
the cloud sprint and the answer was assertion-heavy and detail-light.
Perhaps you meant to say that if you want logind to be useful, then you
So, as best I can tell, without libpam-systemd you get a very classic
unixy setup. Nothing gives console users access to devices, nothing
does much with the cgroup hierarchy and most sessions get left in
ssh.service or the unit of the getty.
Now, I'll point out that unix and linux survived just fine with that
configuration for decades.
Debian will work almost as well as it ever did in that configuration.
There was a period of a few years where we used consolekit to grant
access to devices and where policykit used consolekit.
If you need functionality like that then you'll want libpam-systemd.
If you're happy with a classic unix server that doesn't automatically
let people have privileged access, that doesn't automatically give
access to devices, and that doesn't do much with cgroups, I think you're
mostly (or completely) fine without libpam-systemd.
Honestly for a server without non-administrative logins, that might
actually be a feature.
For virtualized desktop or for an ssh server with a lot of users (say
grid computing gateway node), that would be horrible.