Bug#1000626: Bug#1000627: apache2: missing dependency setting

[Michael Biebl]

Binding to a specific interface is not the default Apache or OpenSSH 
configuration.


It can thus be argued that if the bug reporter want's to run such a 
configuration he can easily create a corresponding drop-in via

systemctl edit apache2.service
or
systemctl edit ssh.service

containing

[Unit]
Wants=network-online.target
After=network-online.target


I'd like to refer to https://systemd.io/NETWORK_ONLINE/ as well.
Especially to "Should network-online.target be used?" which suggest 
better and more robust options then using network-online.target


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#960023: SSHFP stops working with libc6 2.31 [AD bit stripped]

[Michael Biebl]

Control: reassing -1 ssh
Control: found -1 1:8.3p1-1
Control: notforwarded -1

Hi Iain

Am 10.05.20 um 10:25 schrieb Iain Lane:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/15767
> 
> On Sun, May 10, 2020 at 09:33:34AM +0200, Michael Biebl wrote:
>> Hi Iain
>>
>> Am 08.05.20 um 14:32 schrieb Iain Lane:
>>> systemd
>>> ===
>>>
>>> systemd-resolved similarly adds 'options edns0' to resolv.conf files it
>>> generates for its stub resolver. It could be extended (untested) to add
>>> the 'trust-ad' option.
>>
>>
>> Could you please raise this at
>> https://github.com/systemd/systemd/issues
>>
>> To me this sounds like something that should be discussed (and
>> eventually implemented) upstream .
> 
> Of course. I filed it here because I wanted to see if the Debian
> maintainers had any thoughts first (and because the SSH behaviour is a
> Debian patch).
> 
> Here you go: https://github.com/systemd/systemd/issues/15767

In the mean time,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965371 was filed as a
duplicate of this bug report.
I'm going to keep #965371 assigned to systemd and will reassign this one
to ssh.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#960023: SSHFP stops working with libc6 2.31 [AD bit stripped]

[Michael Biebl]

Hi Iain

Am 08.05.20 um 14:32 schrieb Iain Lane:
> systemd
> ===
> 
> systemd-resolved similarly adds 'options edns0' to resolv.conf files it
> generates for its stub resolver. It could be extended (untested) to add
> the 'trust-ad' option.


Could you please raise this at
https://github.com/systemd/systemd/issues

To me this sounds like something that should be discussed (and
eventually implemented) upstream .



signature.asc
Description: OpenPGP digital signature

Bug#935939: Does not respect local admin changes and recreates files in /etc/sv

[Michael Biebl]

Package: openssh-server
Version: 1:8.0p1-5
Severity: important

Since I have no use for runit, I removed the /etc/sv directory.
Unfortunately, if the openssh-server package is upgraded (or
reinstalled), the local admin choice is not respected and the files in
/etc/sv are recreated.
I have no idea if this is a bug in openssh-server or runit, please
reassign as necessary. Filed against openssh-server, since it is the
package exposing this behaviour.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.73
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.5-2
ii  libc6  2.28-10
ii  libcom-err21.45.3-4
ii  libgssapi-krb5-2   1.17-6
ii  libkrb5-3  1.17-6
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.9-2+b2
ii  libssl1.1  1.1.1c-1
ii  libsystemd0242-4
ii  libwrap0   7.6.q-28
ii  lsb-base   11.1.0
ii  openssh-client 1:8.0p1-5
ii  openssh-sftp-server1:8.0p1-5
ii  procps 2:3.3.15-2+b1
ii  runit-helper   2.8.13.2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages openssh-server recommends:
ii  libpam-systemd  242-4
ii  ncurses-term6.1+20190803-1
ii  xauth   1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
ii  ssh-askpass   1:1.2.4.1-10+b1
pn  ufw   

-- Configuration Files:
/etc/sv/ssh/.meta/installed [Errno 2] Datei oder Verzeichnis nicht gefunden: 
'/etc/sv/ssh/.meta/installed'
/etc/sv/ssh/finish [Errno 2] Datei oder Verzeichnis nicht gefunden: 
'/etc/sv/ssh/finish'
/etc/sv/ssh/log/run [Errno 2] Datei oder Verzeichnis nicht gefunden: 
'/etc/sv/ssh/log/run'
/etc/sv/ssh/run [Errno 2] Datei oder Verzeichnis nicht gefunden: 
'/etc/sv/ssh/run'

-- debconf information excluded

Bug#935937: gratuitous dependency on runit-helper

[Michael Biebl]

Package: openssh-client
Version: 1:8.0p1-5
Severity: normal

Since the latest update openssh-client got a dependency on runit-helper
which to be completely unnecessary.

Please consider dropping this gratuitous dependency.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  libedit2  3.1-20190324-1
ii  libgssapi-krb5-2  1.17-6
ii  libselinux1   2.9-2+b2
ii  libssl1.1 1.1.1c-1
ii  passwd1:4.7-2
ii  runit-helper  2.8.13.2
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
ii  ssh-askpass   1:1.2.4.1-10+b1

-- no debconf information

Bug#931631: Wrong dependency on virtual logind packages

[Michael Biebl]

Am 08.07.19 um 18:13 schrieb Colin Watson:
> On Mon, Jul 08, 2019 at 03:14:59PM +0200, Michael Biebl wrote:
>> in #923199, the recommends libpam-systemd was changed to
>> default-logind | logind | libpam-systemd
>>
>> This doesn't really make sense, as openssh does not use any of the
>> logind D-Bus interfaces that are supposed to be provided by those
>> virtual facilities.
>> The libpam-systemd recommends is there to ensure that login sessions are
>> registered by logind and properly moved into their own cgroups.
>> This is not a functionality that is provided by elogind or even relevant
>> for elogind.
> 
> CCing Adam, who suggested the default-logind | logind part of this; I
> know very little about elogind myself.
> 
> I can see how an "artificial" dependency like this might make sense to
> avoid libpam-systemd being pulled in for people who aren't using
> systemd, though, even if other logind implementations don't provide the
> same session registration features.

Well, if that is the sole reason why that alternative dependency was
added, then this is a poor choice.
Also, it would have been a good idea to mention that in the changelog.
What you really want to fix is apt trying to satisfy a recommends over
uninstalling/installing a new init system (which tbh I find kinda odd,
that apt prefers to uninstall a package over not installing a recommends).
And also, this alternative dependency is completely useless if you don't
already have elogind installed, which I suspect is the case (about 1%
have sysvinit installed, the number for elogind is only statistic noise).

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#931631: Wrong dependency on virtual logind packages

[Michael Biebl]

Package: openssh-server
Version: 1:7.9p1-10
Severity: normal

Hi,

in #923199, the recommends libpam-systemd was changed to
default-logind | logind | libpam-systemd

This doesn't really make sense, as openssh does not use any of the
logind D-Bus interfaces that are supposed to be provided by those
virtual facilities.
The libpam-systemd recommends is there to ensure that login sessions are
registered by logind and properly moved into their own cgroups.
This is not a functionality that is provided by elogind or even relevant
for elogind.



-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.72
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.45.2-1
ii  libgssapi-krb5-2   1.17-3
ii  libkrb5-3  1.17-3
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.9-2
ii  libssl1.1  1.1.1c-1
ii  libsystemd0242-2
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10
ii  openssh-sftp-server1:7.9p1-10
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd  242-2
ii  ncurses-term6.1+20181013-2
ii  xauth   1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
ii  ssh-askpass   1:1.2.4.1-10
pn  ufw   

-- debconf information excluded

Bug#912087: [Pkg-openssl-devel] Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Michael Biebl]

reassign -1 openssl  1.1.1-1

On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx  wrote:
> reassign 912087 openssh-server,systemd
> thanks
> 
> On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> > On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote:
> > > Reassigning to OpenSSL - could the OpenSSL maintainers please have a
> > > look and advise what's best to do?  (See the start of the bug, reporting
> > > a delay of more than one minute in system boot in some cases, mainly
> > > waiting for sshd to start.)
> > 
> > The biggest change related to this is that we know use
> > getrandom()/getentropy() on kernels that have it, so kernels
> > >= 3.17. And the kernel using that interface doesn't return random
> > numbers until it has been initialized.
> > 
> > Something should be initializing the kernel with random data from
> > the previous boot. This used to be done by /etc/init.d/urandom,
> > but I'm not sure if that's still used. This should be done as
> > early as possible during the boot not to cause such problems. You
> > should look into when during the boot process the kernel gets this
> > random data.
> 
> So I believe this is not an openssl issue, but something in the
> order that the kernel's RNG is initialized and openssh is started.
> Potentionally the RNG isn't initialized at all and you actually
> have to wait for the kernel to get it's random data from the slow
> way.

The service is called systemd-random-seed.service and stores the random
seed during shutdown and restores it during boot. Pretty much as urandom
did under sysvinit.
This service is run in sysinit.target, ssh.service is started in
multi-user.target, which is ordered after sysvinit.target.


> So I'm reassigning this to systemd and openssh-server, I have no
> idea where the problem really is.

I don't see anything which can be fixed from the systemd side of things,
so reassigning back to openssl.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade

[Michael Biebl]

Am 24.07.2016 um 17:47 schrieb Colin Watson:
> Compromise proposal: how about I make it do nothing if libpam-systemd is
> installed (e.g. "ConditionPathExists=!/usr/share/pam-configs/systemd",
> which is probably the simplest available check without needing to deal
> with multiarch paths), in which case presumably the hack isn't needed?
> (For backports to jessie, such a check would need to be deleted, unless
> you plan to backport the ordering fix as requested above.)

Counter-proposal: Add libpam-systemd as recommends and ship
ssh-session-cleanup.service only as an example file.
Add a section to README.Debian mentioning that libpam-systemd + UsePAM
yes is highly recommended (for the reasons I mentioned). If people want
to opt out of this proposed default configuration, they should enable
the ssh-session-cleanup.service unit by copying it to
/etc/systemd/system and running systemctl enable
ssh-session-cleanup.service.

This is something I could be ok with, as this would only affect users
which explicitly decide to use a non-default configuration.

Cheers,
Michael

P.S: I'm curious how this was supposed to work under sysvinit? I don't
see any special code which kills SSH user sessions on shutdown, am I
missing something?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade

[Michael Biebl]

Am 24.07.2016 um 17:47 schrieb Colin Watson:
> On Sun, Jul 24, 2016 at 01:38:25AM +0200, Michael Biebl wrote:

>> I referenced in my other reply that the network.target ordering has just
>> been added recently (in v230). So it is possible that previously there
>> was still an issue on shutdown. This is fixed now.
> 
> Do you plan to update jessie with this fix? 

I can do that. Unfortunately I've already filed the jessie-pu bug for
systemd a couple of hours ago (#832336, for 8.6), but I could update the
pu request accordingly.
I see what I can do, otherwise it will be in the next stable point
release, i.e 8.7

> dependencies.  Unfortunately there's no good way to say "Depends:
> libpam-systemd, but only if systemd is pid 1".

Right, we do not have conditional Depends. But since sysvinit-core is
the only existing alternative in stretch, we could use Depends:
libpam-systemd | sysvinit-core. It's slighly ugly but would probably do
the trick.


> It's unfortunate that we don't have a good way to simply be able to
> assume that all systemd users have libpam-systemd installed, which is
> what I'd really prefer to be able to do here.

I am more and more inclined that we should simply make libpam-systemd a
hard dependency of either systemd or systemd-sysv.

>> Please disable the ssh-session-cleanup.service hack by default if you
>> don't want to remove it. Or better, ship it as an example file.
> 
> Compromise proposal: how about I make it do nothing if libpam-systemd is
> installed (e.g. "ConditionPathExists=!/usr/share/pam-configs/systemd",
> which is probably the simplest available check without needing to deal
> with multiarch paths), in which case presumably the hack isn't needed?
> (For backports to jessie, such a check would need to be deleted, unless
> you plan to backport the ordering fix as requested above.)

I'm still pretty much convinced that a hack like this should not be
shipped by default, which is totally unnecessary for a default
installation. It set's a wrong precedent.
If we start piling up hacks like this, in 10 years we are back at that
mess that sysvinit has become.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade

[Michael Biebl]

Am 23.07.2016 um 12:29 schrieb Colin Watson:
> On Sat, Jul 23, 2016 at 01:35:04AM +0200, Michael Biebl wrote:
>> the addition of ssh-session-cleanup.service in the latest upload [1] is
>> imho a bad idea. It's an aweful hack and besides, it also kills your SSH
>> sessions on upgrades (thus severity RC).
>>
>> The proper fix is to use libpam-systemd. This will register a proper
>> session scope when users log in via SSH. Those session scopes are
>> ordered against systemd-user-sessions.service which itself has a proper
>> ordering against network.target. So those user session are stopped
>> before the network stack is shutdown.
>>
>> Please drop ssh-session-cleanup.service again and simply add a
>> dependency on libpam-systemd. It's the correct solution for this
>> problem.
> 
> While of course I have libpam-systemd installed on all my systems, I
> really don't want to depend on it; besides, the original report had
> people saying that they encountered occasional problems of sessions not
> being cleaned up even with PAM configured and libpam-systemd installed
> too.

I referenced in my other reply that the network.target ordering has just
been added recently (in v230). So it is possible that previously there
was still an issue on shutdown. This is fixed now.

Besides, there are many other reasons why you really want libpam-systemd
in combination with SSH.
You really want the user process be tracked as part of the user session,
so you can properly apply resource limits or safely kill user sessions.

  I think I'll add a Recommends on it, but I really want
> openssh-server to be usable on very minimal systems, including those
> using other init systems, without having to deal with dependency
> strangenesses.

Please disable the ssh-session-cleanup.service hack by default if you
don't want to remove it. Or better, ship it as an example file.
I really don't what such service file be installed (and active) by
default on every system. People might see it and think it's actually ok
to apply such hacks.

It doesn't help for the non-systemd case and people who opt to not
install recommends by default use a non-standard configuration, so it's
imho ok if those need to also apply additional configuration in case of
SSH. We should optimize for the common case.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade

[Michael Biebl]

Hi Colin

Am 23.07.2016 um 01:42 schrieb Michael Biebl:
> See also the relevant upstream commit:
> 
> https://github.com/systemd/systemd/commit/8c856804780681e135d98ca94d08afe247557770
> 
> This fix is part of v230. Before that, we had no proper ordering on
> shutdown, so it was indeed possible that some user sessions were not
> properly terminated before the network was stopped (as some users
> reported) due to race conditions.

Btw, if you have any systemd related questions, feel free to poke use
via the pkg-systemd-maintainers@ mailing list (in CC).
We are always happy to provide feedback/help.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade

[Michael Biebl]

See also the relevant upstream commit:

https://github.com/systemd/systemd/commit/8c856804780681e135d98ca94d08afe247557770

This fix is part of v230. Before that, we had no proper ordering on
shutdown, so it was indeed possible that some user sessions were not
properly terminated before the network was stopped (as some users
reported) due to race conditions.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#809035: ssh.service notification warning in syslog

[Michael Biebl]

Control: tags -1 + patch

Am 26.12.2015 um 17:27 schrieb Colin Watson:
> Michael, this looks like a regression from your readiness notification
> changes that I applied recently.  Please could you have a look?

Attached is a patch on top of the existing one, which fixes the issue by
running the sd_notify() call only in the main process and not the
spawned off children.
It moves it right next to the existing SIGSTOP readiness-signal.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 60aab01587f4974261882b7c4066750f34522ea4 Mon Sep 17 00:00:00 2001
From: Michael Biebl <bi...@debian.org>
Date: Sun, 27 Dec 2015 15:58:03 +0100
Subject: [PATCH] Call sd_notify() only for the main process

Move the sd_notify() call next to the existing SIGSTOP readiness
notification so it is only run in the main process and not for the
spawned off children.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809035
---
 sshd.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sshd.c b/sshd.c
index 4d28dc0..19ee92b 100644
--- a/sshd.c
+++ b/sshd.c
@@ -2015,11 +2015,6 @@ main(int ac, char **av)
 	/* ignore SIGPIPE */
 	signal(SIGPIPE, SIG_IGN);
 
-#ifdef HAVE_SYSTEMD
-	/* Signal systemd that we are ready to accept connections */
-	sd_notify(0, "READY=1");
-#endif
-
 	/* Get a connection, either from inetd or a listening TCP socket */
 	if (inetd_flag) {
 		server_accept_inetd(_in, _out);
@@ -2061,6 +2056,11 @@ main(int ac, char **av)
 			unsetenv("SSH_SIGSTOP");
 		}
 
+#ifdef HAVE_SYSTEMD
+		/* Signal systemd that we are ready to accept connections */
+		sd_notify(0, "READY=1");
+#endif
+
 		/* Accept a connection and return in a forked child */
 		server_accept_loop(_in, _out,
 		, config_s);
-- 
2.6.4



signature.asc
Description: OpenPGP digital signature

Bug#809035: ssh.service notification warning in syslog

[Michael Biebl]

Will do, thanks Colin 

Am 26. Dezember 2015 17:27:33 MEZ, schrieb Colin Watson :
>On Sat, Dec 26, 2015 at 01:34:47PM +0100, Yuri D'Elia wrote:
>> Package: openssh-server
>> Version: 1:7.1p1-5
>> Severity: minor
>> 
>> I started to see the following messages in syslog recently:
>> 
>> Dec 22 18:12:36 e systemd[1]: ssh.service: Got notification message
>from PID 6719, but reception only permitted for main PID 31374
>> Dec 22 18:32:55 e systemd[1]: ssh.service: Got notification message
>from PID 6783, but reception only permitted for main PID 31374
>> 
>> 
>> Is this an useless warning, or a real problem in the ssh service, or
>...?
>
>Michael, this looks like a regression from your readiness notification
>changes that I applied recently.  Please could you have a look?
>
>Yuri, please could you post the output of "systemctl status -l
>ssh.service"?
>
>Thanks,

Bug#809035: ssh.service notification warning in syslog

[Michael Biebl]

Am 26.12.2015 um 19:55 schrieb Yuri D'Elia:
> On 26/12/15 17:27, Colin Watson wrote:
>> Yuri, please could you post the output of "systemctl status -l
>> ssh.service"?
> 
> ● ssh.service - OpenBSD Secure Shell server
>Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
> enabled)
>Active: active (running) since Wed 2015-12-23 11:04:21 CET; 3 days ago
>  Main PID: 2576 (sshd)
>CGroup: /system.slice/ssh.service
>└─2576 /usr/sbin/sshd -D
> 
> Dec 26 19:51:22 e.thregr.org systemd[1]: ssh.service: Got notification 
> message from PID 17587, but reception only permitted for main PID 2576
> Dec 26 19:51:22 e.thregr.org sshd[17587]: Accepted publickey for root from ..
> Dec 26 19:51:22 e.thregr.org sshd[17587]: pam_unix(sshd:session): session 
> opened for user root by (uid=0)
> 
> In addition:
> 
> # ps -f 17587
> UIDPID  PPID  C STIME TTY  STAT   TIME CMD
> root 17587  2576  0 19:51 ?Ss 0:00 sshd: root@pts/0
> 

So the notification comes from the forked off sshd child process which
has been started for the logged in user and not the main sshd process.

We probably need to differentiate in the code whether it's the main
process or not and only send the sd_notify notification in the former case.

Colin, is there a simple check how we can determine if we are the main
process?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

Hi Colin,

it's me again.

Am 14.11.2015 um 17:33 schrieb Michael Biebl:
> Hi Colin, I didn't receive any feedback on this patch yet.
> Would be great if you can have a look so we can fix this issue for good.

Do you have any thoughts/concerns regarding the proposed patch?
If you don't find the patch acceptable, do you have ideas how we can
address this differently?

I think it would be important to fix this properly now that systemd is
the default.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

On Thu, 10 Sep 2015 18:13:24 +0200 Michael Biebl <bi...@debian.org> wrote:
> Hi Colin!
> 
> On Tue, 12 May 2015 22:54:04 +0200 Michael Biebl <bi...@debian.org> wrote:
> > Am 12.05.2015 um 17:42 schrieb Michael Biebl:
> > > Am 12.05.2015 um 17:07 schrieb Michael Biebl:
> > 
> > >> As you can see, systemd tries to repeatedly start the service until it 
> > >> hits
> > >> start-limit.
> > >> We should use sd_notify in that case to pass a correct error code to 
> > >> systemd.
> > > 
> > > Or we could use what's been proposed by Colin, i.e.
> > >  ExecStartPre=/usr/bin/sshd -t
> > > or my
> > >  RestartPreventExitStatus=255
> > 
> > Updated patch, adding RestartPreventExitStatus=, attached.
> > 
> > From my limited testing, seems to work fine here.
> 
> Now that jessie is out the door, it would be a great time to apply this
> patch and solve this issue for good.
> 
> Did you have time for a review yet?

Hi Colin, I didn't receive any feedback on this patch yet.
Would be great if you can have a look so we can fix this issue for good.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

Hi Colin!

On Tue, 12 May 2015 22:54:04 +0200 Michael Biebl <bi...@debian.org> wrote:
> Am 12.05.2015 um 17:42 schrieb Michael Biebl:
> > Am 12.05.2015 um 17:07 schrieb Michael Biebl:
> 
> >> As you can see, systemd tries to repeatedly start the service until it hits
> >> start-limit.
> >> We should use sd_notify in that case to pass a correct error code to 
> >> systemd.
> > 
> > Or we could use what's been proposed by Colin, i.e.
> >  ExecStartPre=/usr/bin/sshd -t
> > or my
> >  RestartPreventExitStatus=255
> 
> Updated patch, adding RestartPreventExitStatus=, attached.
> 
> From my limited testing, seems to work fine here.

Now that jessie is out the door, it would be a great time to apply this
patch and solve this issue for good.

Did you have time for a review yet?

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#794755: systemd kills ssh-server

[Michael Biebl]

Am 06.08.2015 um 12:28 schrieb Thomas Schmidt:
ug 06 10:43:50 9398 systemd[1]: ssh.service: Main process exited,
code=exited, status=255/n/a
 Aug 06 10:43:50 9398 systemd[1]: ssh.service: Unit entered failed state.
 Aug 06 10:43:50 9398 systemd[1]: ssh.service: Failed with result 'exit-code'.
 Aug 06 10:43:50 9398 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
 ses=4294967295 msg='unit=ssh comm=systemd exe=/lib/syAug 06 10:43:50 9398 
 NetworkManager[2046]: info  keyfile: new connection 
 /etc/NetworkManager/system-connections/Wired connectiAug 06 10:43:50 9398 
 smartd[2415]: Device: /dev/sda [SAT], is SMART capable. Adding to monitor 
 list.
 Aug 06 10:43:50 9398 avahi-daemon[2379]: Service 9398 
 (/services/udisks.service) successfully established.
 Aug 06 10:43:50 9398 systemd[1]: ssh.service: Service hold-off time over, 
 scheduling restart.
 Aug 06 10:43:50 9398 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
 ses=4294967295 msg='unit=ssh comm=systemd exe=/lib/sAug 06 10:43:50 9398 
 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 
 msg='unit=ssh comm=systemd exe=/lib/syAug 06 10:43:50 9398 systemd[1]: 
 ssh.service: Start request repeated too quickly.
 Aug 06 10:43:50 9398 systemd[1]: Failed to start OpenBSD Secure Shell server.
 -- Subject: Unit ssh.service has failed
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 --
 -- Unit ssh.service has failed.
 --
 -- The result is failed.
 


It looks like ssh service is restarted too often within a short period
of time due to some external process (most likely the if-up.d hook).
Therefor systemd marks the service as failed, it's not that systemd
kills ssh-server.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

Am 12.05.2015 um 17:07 schrieb Michael Biebl:
 root@pluto:~# echo foobar  /etc/ssh/sshd_config 
 
 root@pluto:~# systemctl restart ssh.service 
 Job for ssh.service failed. See 'systemctl status ssh.service' and 
 'journalctl -xn' for details.
 
 root@pluto:~# systemctl status ssh.service 
 ● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/etc/systemd/system/ssh.service; enabled)
Active: failed (Result: start-limit) since Di 2015-05-12 17:03:51 CEST; 5s 
 ago
   Process: 13053 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, 
 status=255)
  Main PID: 13053 (code=exited, status=255)
 
 Mai 12 17:03:51 pluto sshd[13053]: /etc/ssh/sshd_config: terminating, 1 bad 
 configuration options
 Mai 12 17:03:51 pluto systemd[1]: ssh.service: main process exited, 
 code=exited, status=255/n/a
 Mai 12 17:03:51 pluto systemd[1]: Failed to start OpenBSD Secure Shell server.
 Mai 12 17:03:51 pluto systemd[1]: Unit ssh.service entered failed state.
 Mai 12 17:03:51 pluto systemd[1]: ssh.service start request repeated too 
 quickly, refusing to start.
 Mai 12 17:03:51 pluto systemd[1]: Failed to start OpenBSD Secure Shell server.
 Mai 12 17:03:51 pluto systemd[1]: Unit ssh.service entered failed state.
 
 
 As you can see, systemd tries to repeatedly start the service until it hits
 start-limit.
 We should use sd_notify in that case to pass a correct error code to systemd.

Or we could use what's been proposed by Colin, i.e.
 ExecStartPre=/usr/bin/sshd -t
or my
 RestartPreventExitStatus=255

The latter has the benefit, that we don't need to parse the config twice
and there is no race condition between ExecStartPre and ExecStart where
the config file might have been modified.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

Am 12.05.2015 um 17:42 schrieb Michael Biebl:
 Am 12.05.2015 um 17:07 schrieb Michael Biebl:

 As you can see, systemd tries to repeatedly start the service until it hits
 start-limit.
 We should use sd_notify in that case to pass a correct error code to systemd.
 
 Or we could use what's been proposed by Colin, i.e.
  ExecStartPre=/usr/bin/sshd -t
 or my
  RestartPreventExitStatus=255

Updated patch, adding RestartPreventExitStatus=, attached.

From my limited testing, seems to work fine here.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/configure.ac b/configure.ac
index f5c65c5..ef154ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4137,6 +4137,29 @@ AC_ARG_WITH(consolekit,
 	fi ]
 )
 
+# Check whether user wants systemd support
+SYSTEMD_MSG=no
+AC_ARG_WITH(systemd,
+	[  --with-systemd  Enable systemd support],
+	[ if test x$withval != xno ; then
+		AC_PATH_TOOL([PKGCONFIG], [pkg-config], [no])
+		if test $PKGCONFIG != no; then
+			AC_MSG_CHECKING([for libsystemd])
+			if $PKGCONFIG --exists libsystemd; then
+SYSTEMD_CFLAGS=`$PKGCONFIG --cflags libsystemd`
+SYSTEMD_LIBS=`$PKGCONFIG --libs libsystemd`
+CPPFLAGS=$CPPFLAGS $SYSTEMD_CFLAGS
+SSHDLIBS=$SSHDLIBS $SYSTEMD_LIBS
+AC_MSG_RESULT([yes])
+AC_DEFINE(HAVE_SYSTEMD, 1, [Define if you want systemd support.])
+SYSTEMD_MSG=yes
+			else
+AC_MSG_RESULT([no])
+			fi
+		fi
+	fi ]
+)
+
 # Looking for programs, paths and files
 
 PRIVSEP_PATH=/var/empty
@@ -4939,6 +4962,7 @@ echolibedit support: $LIBEDIT_MSG
 echo   Solaris process contract support: $SPC_MSG
 echoSolaris project support: $SP_MSG
 echo ConsoleKit support: $CONSOLEKIT_MSG
+echosystemd support: $SYSTEMD_MSG
 echoIP address in \$DISPLAY hack: $DISPLAY_HACK_MSG
 echoTranslate v4 in v6 hack: $IPV4_IN6_HACK_MSG
 echo   BSD Auth support: $BSD_AUTH_MSG
diff --git a/debian/control b/debian/control
index c513f4e..6144cf3 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: openssh
 Section: net
 Priority: standard
 Maintainer: Debian OpenSSH Maintainers debian-ssh@lists.debian.org
-Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev (= 1:1.2.3), libssl-dev (= 0.9.8g), libpam0g-dev | libpam-dev, libgtk2.0-dev, libedit-dev, debhelper (= 9~), dh-exec, libselinux1-dev [linux-any], libkrb5-dev | heimdal-dev, dpkg-dev (= 1.16.1~), libck-connector-dev, dh-autoreconf, autotools-dev, dh-systemd (= 1.4)
+Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev (= 1:1.2.3), libssl-dev (= 0.9.8g), libpam0g-dev | libpam-dev, libgtk2.0-dev, libedit-dev, debhelper (= 9~), dh-exec, libselinux1-dev [linux-any], libkrb5-dev | heimdal-dev, dpkg-dev (= 1.16.1~), libck-connector-dev, dh-autoreconf, autotools-dev, dh-systemd (= 1.4), libsystemd-dev [linux-any]
 XS-Testsuite: autopkgtest
 Standards-Version: 3.9.6
 Uploaders: Colin Watson cjwat...@debian.org, Matthew Vernon matt...@debian.org
diff --git a/debian/rules b/debian/rules
index 570e651..8429054 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,6 +91,7 @@ confflags += --with-kerberos5=/usr
 confflags += --with-ssl-engine
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 confflags += --with-selinux
+confflags += --with-systemd
 endif
 ifeq ($(DISTRIBUTOR),Ubuntu)
 confflags += --with-consolekit
diff --git a/debian/systemd/ssh.service b/debian/systemd/ssh.service
index ff28d39..3df8c64 100644
--- a/debian/systemd/ssh.service
+++ b/debian/systemd/ssh.service
@@ -9,6 +9,8 @@ ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
 ExecReload=/bin/kill -HUP $MAINPID
 KillMode=process
 Restart=on-failure
+RestartPreventExitStatus=255
+Type=notify
 
 [Install]
 WantedBy=multi-user.target
diff --git a/sshd.c b/sshd.c
index 23d5a64..180e9eb 100644
--- a/sshd.c
+++ b/sshd.c
@@ -84,6 +84,10 @@
 #include prot.h
 #endif
 
+#ifdef HAVE_SYSTEMD
+#include systemd/sd-daemon.h
+#endif
+
 #include xmalloc.h
 #include ssh.h
 #include ssh1.h
@@ -1927,6 +1931,12 @@ main(int ac, char **av)
 	/* ignore SIGPIPE */
 	signal(SIGPIPE, SIG_IGN);
 
+
+#ifdef HAVE_SYSTEMD
+	/* Signal systemd that we are ready to accept connections */
+	sd_notify(0, READY=1);
+#endif
+
 	/* Get a connection, either from inetd or a listening TCP socket */
 	if (inetd_flag) {
 		server_accept_inetd(sock_in, sock_out);


signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

On Mon, 30 Mar 2015 04:02:01 +0200 Christoph Anton Mitterer
cales...@scientia.net wrote:
 Hi Michael.

(since this was targetted at me, you should have CCed me. I don't get
openssh-server bug mail)

 Your proposal seems to be a good solution for now. Maybe Colin can merge
 it and it will find it's way into jessie.

See my followup [1], Type=forking turned up to have it's own set of
problems.

 As for sd_notify,... a simply google query didn't turn up any existing
 patches for that and it may be hard to convince upstream to do it ;)

A patch for that should be not that complicated and might even be worth
shipping downstream if upstream doesn't want to apply it.

 Since this problem may affect other services as well... is there some
 concentrated effort in Debian to identify these?

Not that I'm aware of.

Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913#45

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

Control: tags -1 + patch

Am 12.05.2015 um 13:45 schrieb Michael Biebl:
 On Mon, 30 Mar 2015 04:02:01 +0200 Christoph Anton Mitterer
 As for sd_notify,... a simply google query didn't turn up any existing
 patches for that and it may be hard to convince upstream to do it ;)
 
 A patch for that should be not that complicated and might even be worth
 shipping downstream if upstream doesn't want to apply it.

Attached is a patch which adds support for sd_notify.
The configure.ac changes are a bit more convoluted then I hoped since 
openssh doesn't use the pkg-config provided macros.


A quick test (with a broken configuration file) at least seems to 
properly error out:


root@pluto:~# systemctl status ssh.service 
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/etc/systemd/system/ssh.service; enabled)
   Active: active (running) since Di 2015-05-12 17:03:28 CEST; 4s ago
 Main PID: 13021 (sshd)
   CGroup: /system.slice/ssh.service
   └─13021 /usr/sbin/sshd -D

Mai 12 17:03:28 pluto sshd[13021]: Server listening on 0.0.0.0 port 22.
Mai 12 17:03:28 pluto sshd[13021]: Server listening on :: port 22.

root@pluto:~# echo foobar  /etc/ssh/sshd_config 

root@pluto:~# systemctl restart ssh.service 
Job for ssh.service failed. See 'systemctl status ssh.service' and 'journalctl 
-xn' for details.

root@pluto:~# systemctl status ssh.service 
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/etc/systemd/system/ssh.service; enabled)
   Active: failed (Result: start-limit) since Di 2015-05-12 17:03:51 CEST; 5s 
ago
  Process: 13053 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, 
status=255)
 Main PID: 13053 (code=exited, status=255)

Mai 12 17:03:51 pluto sshd[13053]: /etc/ssh/sshd_config: terminating, 1 bad 
configuration options
Mai 12 17:03:51 pluto systemd[1]: ssh.service: main process exited, 
code=exited, status=255/n/a
Mai 12 17:03:51 pluto systemd[1]: Failed to start OpenBSD Secure Shell server.
Mai 12 17:03:51 pluto systemd[1]: Unit ssh.service entered failed state.
Mai 12 17:03:51 pluto systemd[1]: ssh.service start request repeated too 
quickly, refusing to start.
Mai 12 17:03:51 pluto systemd[1]: Failed to start OpenBSD Secure Shell server.
Mai 12 17:03:51 pluto systemd[1]: Unit ssh.service entered failed state.


As you can see, systemd tries to repeatedly start the service until it hits
start-limit.
We should use sd_notify in that case to pass a correct error code to systemd.

The patch is not complete yet, more a PoC.

That said, would be glad if Colin could give it some proper review.
Don't want to spend time on it, if it's unlikely to get merged.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/configure.ac b/configure.ac
index f5c65c5..ef154ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4137,6 +4137,29 @@ AC_ARG_WITH(consolekit,
 	fi ]
 )
 
+# Check whether user wants systemd support
+SYSTEMD_MSG=no
+AC_ARG_WITH(systemd,
+	[  --with-systemd  Enable systemd support],
+	[ if test x$withval != xno ; then
+		AC_PATH_TOOL([PKGCONFIG], [pkg-config], [no])
+		if test $PKGCONFIG != no; then
+			AC_MSG_CHECKING([for libsystemd])
+			if $PKGCONFIG --exists libsystemd; then
+SYSTEMD_CFLAGS=`$PKGCONFIG --cflags libsystemd`
+SYSTEMD_LIBS=`$PKGCONFIG --libs libsystemd`
+CPPFLAGS=$CPPFLAGS $SYSTEMD_CFLAGS
+SSHDLIBS=$SSHDLIBS $SYSTEMD_LIBS
+AC_MSG_RESULT([yes])
+AC_DEFINE(HAVE_SYSTEMD, 1, [Define if you want systemd support.])
+SYSTEMD_MSG=yes
+			else
+AC_MSG_RESULT([no])
+			fi
+		fi
+	fi ]
+)
+
 # Looking for programs, paths and files
 
 PRIVSEP_PATH=/var/empty
@@ -4939,6 +4962,7 @@ echolibedit support: $LIBEDIT_MSG
 echo   Solaris process contract support: $SPC_MSG
 echoSolaris project support: $SP_MSG
 echo ConsoleKit support: $CONSOLEKIT_MSG
+echosystemd support: $SYSTEMD_MSG
 echoIP address in \$DISPLAY hack: $DISPLAY_HACK_MSG
 echoTranslate v4 in v6 hack: $IPV4_IN6_HACK_MSG
 echo   BSD Auth support: $BSD_AUTH_MSG
diff --git a/debian/control b/debian/control
index c513f4e..6144cf3 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: openssh
 Section: net
 Priority: standard
 Maintainer: Debian OpenSSH Maintainers debian-ssh@lists.debian.org
-Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev (= 1:1.2.3), libssl-dev (= 0.9.8g), libpam0g-dev | libpam-dev, libgtk2.0-dev, libedit-dev, debhelper (= 9~), dh-exec, libselinux1-dev [linux-any], libkrb5-dev | heimdal-dev, dpkg-dev (= 1.16.1~), libck-connector-dev, dh-autoreconf, autotools-dev, dh-systemd (= 1.4)
+Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev (= 1:1.2.3), libssl-dev (= 0.9.8g), libpam0g-dev | libpam-dev, libgtk2.0-dev, libedit-dev, debhelper (= 9~), dh-exec, libselinux1-dev [linux-any], libkrb5-dev | heimdal-dev, dpkg-dev (= 1.16.1~), libck-connector

Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success

[Michael Biebl]

Am 30.03.2015 um 01:17 schrieb Michael Biebl:
 So I suggest using the Type=forking option but also setting
 RestartPreventExitStatus=255 [1], since 255 seems to be the return code
 on config errors and I don't think it makes sense to restart in that case.
 
 The resulting ssh.service would look like
 
 [Unit]
 Description=OpenBSD Secure Shell server
 After=network.target auditd.service
 ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
 
 [Service]
 EnvironmentFile=-/etc/default/ssh
 ExecStart=/usr/sbin/sshd $SSHD_OPTS
 ExecReload=/bin/kill -HUP $MAINPID
 KillMode=process
 Restart=on-failure
 Type=forking
 PIDFile=/var/run/sshd.pid
 RestartPreventExitStatus=255
 
 [Install]
 WantedBy=multi-user.target
 Alias=sshd.service
 
 
 With those changes, ssh.service ssems to behave as expected on failures.

I spoke too soon. As it turns out, sshd has a rather strange, or let's
say broken, SIGHUP behaviour (when in daemon mode): It reexecs, i.e.
changes its PID but doesn't write a new /var/run/sshd.pid. Since ssh
runs reload in it's if-up.d hook under systemd, this will break make it
break badly, since systemd will lose track of the sshd main process.

Colin, any idea, why sshd behaves so strange on SIGHUP?




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#764841: please use pam_exec to display dynamic motd

[Michael Biebl]

On Sun, 12 Oct 2014 08:39:18 +0100 Colin Watson cjwat...@debian.org wrote:
 On Sat, Oct 11, 2014 at 05:09:38PM +0200, Romain Francoise wrote:
  As of systemd 208-7, the motd init script is masked and no longer runs
  at boot. login was updated to replace its use of /run/motd.dynamic with
  a pam_exec invocation:
  
  | # Prints the message of the day upon succesful login.
  | # (Replaces the `MOTD_FILE' option in login.defs)
  | sessionoptional   pam_exec.so type=open_session stdout /bin/uname 
  -snrvm
  | sessionoptional   pam_motd.so
  
  Please consider doing the same in openssh-server's pam configuration.
 
 Doesn't the motd stuff do considerably more than just uname?  On my
 Ubuntu system it says:
 
   Welcome to Ubuntu Utopic Unicorn (development branch) (GNU/Linux 
 3.16.0-17-generic x86_64)
   
* Documentation:  https://help.ubuntu.com/
   
   485 packages can be updated.
   0 updates are security updates.
   
   *** System restart required ***
 
 So I think I need to find a way to avoid regressing that.

Since you still keep the pam_motd line, the worst that can happen
afaics, is that on Ubuntu the uname information would be printed twice
(if you don't want to have delta)
Or what kind of regression did you have in mind?

Bringing Steve into the loop here, as PAM maintainer:
Quoting IRC:
vorlon mbiebl: I believe we should use /etc/update-motd.d for this,
yes.  In principle I think it's also fine to do this via pam_exec, but
update-motd needs to be externalized as a script first.


As for jessie, I don't know how much effort it would be to switch to the
update-motd mechanism and also update the login package accordingly.

Steve, do you think it's too late to do that for jessie? What would you
suggest?

We did mask the motd init script in systemd after we were told that the
login package was updated to no longer require it and we weren't aware
that there were other users of that motd.dynamic file.

We can certainly revert this change again for jessie, if you think the
uname information for ssh logins is important enough.
That said, if this can be avoided and we find an agreeable solution for
everyone which doesn't involved generating a motd.dynamic file, then I'd
certainly prefer that.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#747743: systemd: After switching from sysvinit to systemd former disabled services are started

[Michael Biebl]

Am 11.05.2014 18:51, schrieb Tollef Fog Heen:
 
 reassign 747743 openssh-server
 thanks
 
 ]] Julian Wollrath 
 
 I have the package openssh-server installed but disabled starting the server
 daemon via 'update-rc.d ssh disable', since I do not need it running all the
 time. When I switched to systemd suddenly the ssh service was started despite
 the fact, that I had disabled it. But I also had kdm only enabled for 
 runlevel
 5, systemd recognized that correctly and did not started it in different
 runlevels. Somehow the detection that ssh was totally disabled failed (or it
 was not even tried to detect that). The same holds for the bluetooth service,
 which I also disabled but which got started by systemd nevertheless.
 
 This sounds like a bug in the SSH packaging, so reassigning to
 openssh-server.
 
 Colin, feel free to poke us if there's anything we can help with.  (Or
 reassign back if you feel this is a bug in systemd/dh_systemd.)

Actually, I discussed that with Michael Stapelberg when we worked on the
dh-systemd helper. The problem is, update-rc.d doesn't provide any API
to query if a SysV init script is enabled or not. We filed a bug for
that a while ago without any feedback so far from the sysvinit
maintainers [0].
So, when adding a native service file, it's not really possible to
mirror the enabled state in a way which works universally and I don't
think there is anything we can do in the dh_systemd helper regarding
that. I'm also not sure if it is fixable manually.
If you add the code into postinst before the #DEBHELPER# stanza, the
service is not setup yet. If you add it after the #DEBHELPER# stanza,
the service has already been started.

Michael


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705254
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-systemd-maintainers] systemd support in openssh-server

[Michael Biebl]

Hi, me again...

Am 11.02.2014 00:32, schrieb Michael Biebl:
 I noticed that you added systemd .service files in openssh 1:6.5p1-1.
 Thanks a lot for that!
 There are a few issues though that I noticed which I'd like to discuss.

It was pointed out on IRC today, that the SysV/LSB init script has
# Provides: sshd
in its LSB header and there exist other SysV/LSB init scripts which use
that name:

drbd8-utils/init.d/drbd:# Should-Start:   sshd multipathd
smokeping/init.d/smokeping:# Should-Start:  sshd apache
sshguard/init.d/sshguard:# Should-Start:  sshd
vzctl/init.d/vz:# Should-Start:  sshd vzeventd


Sine the native .service is named ssh.service, we should add an alias so
the 4 services above get the correct ordering.

For that I'd suggest to use

[Install]
Alias=sshd.service

in your ssh.service file. When you run systemctl enable this will
create a symlink /etc/systemd/system/sshd.service pointing to the
original name.

IIRC the dh-systemd machinery should be sophisticated enough to update
the symlinks automatically on upgrades if the [Install] section of the
.service file has changed.


Michael

(Thanks Alam_Squeeze for notifying us about this issue)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-systemd-maintainers] systemd support in openssh-server

[Michael Biebl]

Am 12.02.2014 03:09, schrieb Uoti Urpala:
 On Tue, 2014-02-11 at 17:33 -0800, Russ Allbery wrote:
 Colin Watson cjwat...@debian.org writes:
 Aha, I see.  Just inverting the check wouldn't be the right fix, IMO,
 but I'll retest this and sort out a proper fix.  Thanks for the
 clarification.
 
 Not quite right, as in it would enter the inconsistent state I mentioned
 - for example if the admin for some reason ran systemctl stop ssh in
 that state, systemd would stop it but not actually manage to kill the
 process, and then start-stop-daemon wouldn't be called either because it
 would no longer be in active state.
 
 Is it as simple as just stopping and starting sshd once the systemd unit
 file is installed and systemd has been reloaded?  Does systemd remember
 that the service was started via an init script so that it will stop via
 the init script and then start via the unit?
 
 I don't think it has any feature to keep two sets of configuration like
 that. After ssh.service has been installed and daemon-reload called,
 stopping initscript-started ssh through systemd will no longer work -
 it'll try to stop it with KillMode=process, without having the correct
 main PID.
 
 Simplest fix would be to stop sshd in preinst, but then it would of
 course be nice to have a way to tell dpkg to not wait arbitrarily long
 after that before running postinst...

I'm copying here the relevant postinst bits:

if dpkg --compare-versions $2 lt 1:6.5p1-1  \
[ -d /run/systemd/system ]  \
! systemctl --quiet is-active ssh; then
# We must stop the sysvinit-controlled sshd before we can
# restart it under systemd.
start-stop-daemon --stop --quiet --oknodo --pidfile
/var/run/sshd.pid || true
fi


The problem here is special to ssh indeed, since it uses
KillMode=process in the native service file, i.e. not all processes in
the cgroup are killed on stop, only the main PID.
Since MainPID won't be set, when the ssh service was started with the
SysV init script, you can't use systemctl stop when migrating to a
native service file.

For a simpler daemon, which doesn't use KillMode=process, shipping a
native systemd service file usually doesn't require special handling in
the maintainer scripts to stop the old process.


Uoti's observation is also correct, that the admin could issue systemctl
stop during the middle of the upgrade, thus systemd no longer
considering the ssh service in active state although there is still a
running sshd process. The chances to trigger that are probably very
small, but it can happen nonetheless.

Instead of moving the stop into preinst though, my suggestion would be
to remove the check ! systemctl --quiet is-active ssh completely.

This obviously has the downside, that sshd could not actually be running
and in case there is a stale pid file, we might end up killing a wrong
process. To avoid that, I'd probably use and additional --exec test like

start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/sshd.pid
--exec /usr/sbin/sshd || true

Regards,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

systemd support in openssh-server

[Michael Biebl]

Hi Colin,


I noticed that you added systemd .service files in openssh 1:6.5p1-1.
Thanks a lot for that!
There are a few issues though that I noticed which I'd like to discuss.

SSH supports two modes:

a/ The traditional way of being started via ssh.service, which starts
the service on boot via multi-user.target (basically what the SysV init
script does, daemon mode)
b/ On-demand starting via socket activation using: ssh.socket +
ssh@.service.
This will only setup the socket file defined in ssh.socket and start
sshd on demand on incoming requests. (inetd mode)

I think it makes sense to keep using the traditional setup i.e. a/ and
if an administrator wants mode b/ it should be enabled explicilty (and
ssh.service disabled).

But the package both enables ssh.socket and ssh.service (in postinst),
which is kinda odd. They shouldn't be used at the same time. Maybe this
is just an oversight? ssh.socket specifically includes
Conflicts=ssh.service, so what happens now is that systemd will setup
ssh.socket early during boot (via sockets.target) and as soon as
ssh.service is started (via multi-user.target), the ssh.socket unit will
be stopped.

Do you think it would be helpful if we write a small paragraph in
README.Debian explaining the two different modes and how to enable/use them?


I also wonder why the following check was added:

ExecStartPre=/usr/bin/test -c /dev/null

Why is this needed? Seems rather odd to me. With devtmpfs being
mandatory (in systemd/udev) nowadays, /dev/null is guaranteed to exist.
Do you remember why this check was added? Afaics it doesn't seem
necessary anymore nowadays.

If you have further questions, we are happy to help. You can reach us
via pkg-systemd-maintain...@lists.alioth.debian.org or #pkg-systemd on OFTC.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-systemd-maintainers] systemd support in openssh-server

[Michael Biebl]

Am 11.02.2014 00:32, schrieb Michael Biebl:
 I also wonder why the following check was added:
 
 ExecStartPre=/usr/bin/test -c /dev/null
 
 Why is this needed? Seems rather odd to me. With devtmpfs being
 mandatory (in systemd/udev) nowadays, /dev/null is guaranteed to exist.
 Do you remember why this check was added? Afaics it doesn't seem
 necessary anymore nowadays.

If you really want to keep this check, you might consider using a
Condition test [1] like this:

[Unit]
ConditionPathExists=/dev/null
...

Granted, this doesn't check whether /dev/null is a character device. But
it is a much more lightweight check (doesn't need to execute a binary)
and I'm having a hard time finding a scenario where /dev/null is
anything but a character device

Cheers,
Michael


[1] man 5 systemd.unit

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#549620: ssh: slogin segfaults on MIPS

[Michael Biebl]

Colin Watson wrote:
 reassign 538313 openssh 1:5.1p1-6
 reassign 549620 openssh 1:5.1p1-7
 forcemerge 538313 549620
 thanks
 
 On Mon, Oct 05, 2009 at 05:10:23AM +0200, Michael Biebl wrote:
 Erik de Castro Lopo wrote:
 Using slogin to connect to another machine on the local network results
 in slogin segfaulting. The ssh daemon is also segfaulting on startup.

 The machine is a qemu VM but people on the debian-mips mailing list 
 are reporing the same problem on read MIPS hardware.
 That's another instance of the binutils -PIE bug:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526961
 
 Indeed, thanks - and #538313 is for the workaround. Will upload soon.

Couldn't we just fix binutils to ignore -pie on mips and make it a noop instead
of having to patch a lot of packages?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#549620: ssh: slogin segfaults on MIPS

[Michael Biebl]

Colin Watson wrote:
 On Mon, Oct 05, 2009 at 10:34:30AM +0200, Michael Biebl wrote:
 Colin Watson wrote:
 On Mon, Oct 05, 2009 at 05:10:23AM +0200, Michael Biebl wrote:
 Erik de Castro Lopo wrote:
 Using slogin to connect to another machine on the local network results
 in slogin segfaulting. The ssh daemon is also segfaulting on startup.

 The machine is a qemu VM but people on the debian-mips mailing list 
 are reporing the same problem on read MIPS hardware.
 That's another instance of the binutils -PIE bug:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526961
 Indeed, thanks - and #538313 is for the workaround. Will upload soon.
 Couldn't we just fix binutils to ignore -pie on mips and make it a noop 
 instead
 of having to patch a lot of packages?
 
 I wouldn't object, obviously, but I'm still going to make the OpenSSH
 problem go away rather than waiting for a binutils fix/workaround. I can
 always undo this change later.

Ok, my fault. Should have checked firsted before complaining.

Apparently binutils since 2.19.91.20090927-1 already contains a patch which
disables -pie on mips.
I assume this means that a binNMU would be sufficient, given that the buildds
have a recent enough binutils version.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#454085: openssh-server: Unconditional call of deluser in postrm

[Michael Biebl]

Package: openssh-server
Version: 1:4.6p1-6
Severity: normal

The adduser package is non-essential, so the call to deluser in
postrm/purge has to be conditional.

Cheers,
Michael


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23.9
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser   3.105  add and remove users and groups
ii  debconf [debconf-2.0] 1.5.17 Debian configuration management sy
ii  dpkg  1.14.12package maintenance system for Deb
ii  libc6 2.7-3  GNU C Library: Shared libraries
ii  libcomerr21.40.2-1   common error description library
ii  libkrb53  1.6.dfsg.3~beta1-2 MIT Kerberos runtime libraries
ii  libpam-modules0.99.7.1-5 Pluggable Authentication Modules f
ii  libpam-runtime0.99.7.1-5 Runtime support for the PAM librar
ii  libpam0g  0.99.7.1-5 Pluggable Authentication Modules l
ii  libselinux1   2.0.15-2+b1SELinux shared libraries
ii  libssl0.9.8   0.9.8g-3   SSL shared libraries
ii  libwrap0  7.6.dbs-14 Wietse Venema's TCP wrappers libra
ii  lsb-base  3.1-24 Linux Standard Base 3.1 init scrip
ii  openssh-client1:4.6p1-6  secure shell client, an rlogin/rsh
ii  zlib1g1:1.2.3.3.dfsg-7   compression library - runtime

openssh-server recommends no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]