[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade



Hi,

On 2021-08-04 14:34, Ron wrote:
> On Tue, Aug 03, 2021 at 10:08:42PM +0200, Aurelien Jarno wrote:
> > On 2021-08-01 00:05, Ron wrote:
> > > 
> > > Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > > Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
> > > Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > > Preparing to unpack .../runit-helper_2.10.3_all.deb ...
> > > Unpacking runit-helper (2.10.3) ...
> > > Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
> > > Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > > Preparing to unpack .../libc6_2.31-13_amd64.deb ...
> > > Checking for services that may need to be restarted...
> > > Checking init scripts...
> > > Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
> > > Setting up libc6:amd64 (2.31-13) ...
> > > Checking for services that may need to be restarted...
> > > Checking init scripts...
> > > Services to restart for GNU libc library upgrade:
> > > cron atd
> > > Restarting services possibly affected by the upgrade:
> > >   cron: restarting...done.
> > >   atd: restarting...done.
> > > Services restarted successfully.
> > > Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
> > > Unpacking libc-bin (2.31-13) over (2.28-10) ...
> > > Setting up libc-bin (2.31-13) ...
> > >  ...
> > >  <much later>
> > >  ...
> > > Setting up openssh-server (1:8.4p1-5) ...
> > 
> > Thanks for this upgrade log, with it I have been able to understand and
> > reproduce the issue. The libc restart logic looks for installed
> > packaged, however due to all the breaks and depends between
> > openssh-server and libc6 in the buster -> bullseye upgrade path, it
> > could happen that at the moment the libc6 postinst script is ran, the
> > openssh-server has been degraded from installed to unpacked.
> > 
> > I have tested the following fix, which works well when used in the same
> > conditions as the above log:
> > 
> > diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
> > index 8406a543..ee99ac16 100644
> > --- a/debian/script.in/nsscheck.sh
> > +++ b/debian/script.in/nsscheck.sh
> > @@ -1,8 +1,8 @@
> >  	    echo -n "Checking for services that may need to be restarted..."
> >  	    # Only get the ones that are installed, of the same architecture
> >  	    # as libc (or arch all) and configured
> > -	    check=$(dpkg-query -W -f='${binary:Package} ${Status} ${Architecture}\n' $check 2> /dev/null | \
> > -			grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
> > +	    check=$(dpkg-query -W -f='${binary:Package} ${db:Status-Want} ${Architecture}\n' $check 2> /dev/null | \
> > +			grep -E "(install|hold) (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
> >  	    # some init scripts don't match the package names
> >  	    check=$(echo $check | \
> >  		    sed -e's/\bapache2.2-common\b/apache2/g' \
> > 
> > However before uploading such a fix so close to the release, I think it
> > requires a review by many more pair of eyes.
> 
> Again flying blind to a lot of important details -- but what happens if
> libc postinst tries to restart a service that is unpacked but not yet
> configured?
> 
> I'm guessing that depends a lot on what the service post* do, but how
> horrible could that get?  Does this really need to be a trigger that
> (also?) restarts each of the half-installed services after they are
> fully (re)configured again?

Well this bug report complains that SSH is unavailable during an upgrade
until the package is fully configured again. For making it available
again as soon as possible, it has to be restarted after the new glibc
has been installed, even if it has only been unpacked at this stage.

That said you are fully right that it might not work for some other
services.

> I was able to restart ssh manually during the upgrade, but by the time I
> figured out that was what was needed, the install was probably far enough
> through that it had likely been configured and was fully installed again ...

Given I have been able to reproduce the issue, I have tested the above
patch, and I can confirm that openssh can be restarted when it has only
been unpacked.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: