GNU bug report logs - #52533
guix deploy breaks SSH access with a PAM error

Previous Next

Package: guix;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Thu, 16 Dec 2021 04:46:02 UTC

Severity: important

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mathieu Othacehe <othacehe <at> gnu.org>, 52533 <at> debbugs.gnu.org
Subject: bug#52533: guix deploy breaks SSH access with a PAM error
Date: Mon, 17 Jan 2022 17:13:17 +0100
Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
> [...]
>
>> sshd could also be started via socket activation; ‘sshd’ subprocesses
>> corresponding to existing logins would be unaffected.
>>
>>> Also, it seems to me inetd can already do "socket activation", if this
>>> was somehow useful.
>>
>> Yes, inetd can do that.  It would be nicer though to have it all
>> integrated in the Shepherd.
>
> I'm not sure.  The beauty of Shepherd, in my eyes, when compared to
> other init systems, is that it is lean and clean.  Leveraging what's
> already out there (and part of GNU) seems an obvious path to me, as it:
>
> 1. Means less code to write, document and maintain.
> 2. Creates more cohesion between various components of the GNU project.

Heheh, Guix was started to address #2 actually.  Today, I think #2 is
okay but should not be an obstacle.

As for #1, sure, but Shepherd will need to grow a proper event loop
anyway, so socket activation won’t make much of a difference.

Also, taking a step back, systemd undoubtedly changed user expectations
for the better in terms of integration, monitoring, and logging.  Having
the same level of integration in the Shepherd would be a step in that
direction.

>> (Basically, it’s a choice we could make right away: do we move all
>> network daemons, plus things like guix-daemon, dbus-daemon, etc. etc. to
>> inetd services, or do we instead extend the Shepherd to support socket
>> activation?  I’m rather in favor of the latter, but if in Guix System we
>> build an abstraction that can equally well target inetd or a future
>> Shepherd version, that’s even better.)
>
> We could start with just targeting inetd, and build the abstraction
> later, if the need arises, perhaps?  We may never need it.

Yes, so what I had in mind is, in Guix System, something like
<socket-activated-service>, which would kinda look like
<shepherd-service> but be lowered (for now) to an inetd service.

Thanks,
Ludo’.




This bug report was last modified 3 years and 147 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.