From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Mathieu Othacehe <othacehe@gnu.org>, 52533@debbugs.gnu.org
Subject: bug#52533: guix deploy breaks SSH access with a PAM error
Date: Mon, 17 Jan 2022 17:13:17 +0100 [thread overview]
Message-ID: <875yqimjc2.fsf@gnu.org> (raw)
In-Reply-To: <87v8yijsp6.fsf@gmail.com> (Maxim Cournoyer's message of "Mon, 17 Jan 2022 10:19:17 -0500")
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> Ludovic Courtès <ludo@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’.
next prev parent reply other threads:[~2022-01-17 16:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 4:45 bug#52533: guix deploy breaks SSH access with a PAM error Maxim Cournoyer
2021-12-16 5:27 ` bug#52533: [PATCH] " Maxim Cournoyer
2021-12-16 15:02 ` Ludovic Courtès
2022-01-13 12:31 ` Mathieu Othacehe
2022-01-13 12:38 ` Mathieu Othacehe
2022-01-13 15:04 ` Ludovic Courtès
2022-01-13 16:45 ` Maxim Cournoyer
2022-01-17 13:25 ` Ludovic Courtès
2022-01-17 15:19 ` Maxim Cournoyer
2022-01-17 16:13 ` Ludovic Courtès [this message]
2022-01-18 4:33 ` Maxim Cournoyer
2022-01-18 11:27 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875yqimjc2.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=52533@debbugs.gnu.org \
--cc=maxim.cournoyer@gmail.com \
--cc=othacehe@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).