unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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 14:25:24 +0100	[thread overview]
Message-ID: <877daypk8r.fsf@gnu.org> (raw)
In-Reply-To: <87mtjz1t63.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 13 Jan 2022 11:45:08 -0500")

Hi,

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

>>> I was just kicked out of my own server due to this PAM/SSH issue. It
>>> happens quite frequently here. Time for a fix :).
>
> Not a meaningful contribution to the discussion, but my workaround is to
> disable PAM; as it is not enabled in OpenSSH by default, perhaps we
> should also leave it off unless requested?  What are the advantages of
> having it on?

Consistency: authentication had rather work consistently across all
system services that depend on it.

[...]

>> The crux of the problem rather is the global /etc/pam.d: it’s valid for
>> pre-glibc upgrade programs, or for post-glibc upgrade programs, but not
>> both.
>>
>> FHS distros have a similar problem though; how do they handle it?  Do
>> they force services to be restarted when glibc is upgraded, or something
>> along these lines?
>
> I just asked this question in Debian's OFTC channel:
>
> "how does debian handle glibc updates?  are services restarted when it
> happens?  Or does it postpone updating glibc until the next reboot?"
>
> And got for answer: "there is no magic postponing of updates"; the
> external needrestart [0] program was also mentioned.
>
> Researching some more, it seems this may be handled on Debian by the use
> of postinst scripts (which is an arbitrary shell script run after a
> package is installed); so the libc package of Debian for example
> restarts the postgres service to avoid problems:
>
> [0]  https://github.com/liske/needrestart
> [1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710275

Yeah.  My recollection is that apt is interactive by default, and it
would typically pop up a dialog telling you that services X and Y need
to be restarted, and asking whether you want to restart them now.

The difference compared to what we have (a message at then telling that
you “may need” to run ‘herd restart X’), the benefit IIRC is that it
tells you which services need to be restarted.

[...]

>> We could maybe sidestep the issue altogether with socket-activated
>> services: they’d be started on-demand, so the second scenario above
>> would be unlikely.  But getting there is quite a bit of work…
>
> I fail to see how this would be a solution for openssh, which would
> typically already be running unless you've never login ounce since the
> machine was up (or am I missing something?).

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.

(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.)

Ludo’.




  reply	other threads:[~2022-01-17 14:05 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 [this message]
2022-01-17 15:19           ` Maxim Cournoyer
2022-01-17 16:13             ` Ludovic Courtès
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=877daypk8r.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).