I'm not sure about this. What's the pattern that users can expect to see across all packages that provide socket activated services in Ubuntu in the future? I think there are three options here: "always", "sometimes" and "never". We could ensure that there's _always_ a generator that creates the corresponding socket unit by doing ad-hoc, probably incomplete parsing of the relevant configuration file; that there _never_ is a generator and users must tweak it by hand; or that there _sometimes_ might be a generator and sometimes not, depending on the service, so manual tweaking may or may not be necessary.
The problem with "always" is the difficulty of parsing the relevant configuration file. So if users start expecting "always" behaviour across all socket activated services across the archive, that's going to be unreliable in a way that we will never be able to fully fix. "Sometimes" seems horribly inconsistent and unpredictable. For "never", in https://discourse.ubuntu.com/t/spec-definition-of-an- online-system/27838 I think we agreed that "There will always be cases where if you configure one thing in one place, you’re expected/required to configure another thing in another place to match." I don't think it's unreasonable for the "correct" way to customize an Ubuntu system is to make those other related configuration changes. It's not perfect for UX; neither is any alternative, but at least this way would be consistent and predictable. The pain is in the upgrade path and discoverability of what is required, but we can work to make those things smoother for common use cases. This principle would then apply not only to socket activated services, but also to network-online.target and AppArmor rules that users already have to fix when tweaking system configuration today. Given the problems with making "always" work in all cases in practice, I think I'd prefer to see us doing what we can as one-off "heuristic" type special handling in the upgrade path in return for a consistent and complete experience for users starting afresh. > Its just wholly unrequired to allocate an on-demand socket for a daemon that listens all the time, anyways. The point is to reduce footprint for greater density in production environments. Most instances don't need an ssh daemon running all the time. There's lots of demand from users to make the default installation less "bloated", and I think Ubuntu developers are agreed that one aspect to that is to use socket activation wherever possible. Socket activation for ssh is included in that list. > If ubuntu wants to use .socket, then please do this only for new openssh-server installations, never on upgrades. You will lock out too many people I like this idea in principle, but I think it'd just be kicking the can down the road. For example, in a few releases time, we'll inevitably touch something that might break users who upgraded up without converting to socket activation because that will have become a non- obvious configuration. Preventing this would require conditional handling of this special case indefinitely, and maintaining and QA-ing the special case would become impractically difficult over time. Instead, I think there comes a point where "ripping the band-aid off" becomes necessary, and a release upgrade - particularly the one immediately following an LTS - is the least-worst time to do that. However, please note that I'm not meaning to dismiss the feedback here, or imply that the current upgrade path problems are OK. We should do what we can to automatically handle the common upgrade path issues, and I appreciate the reports because that helps us identify what those are and gives us a set of test cases that might not previously have been identified. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1991592 Title: openssh-server should ship a systemd generator to generate ssh socket port configuration from sshd_config Status in openssh package in Ubuntu: Triaged Bug description: A criticism of the existing sshd socket activation implementation is that Port/ListenAddress options are migrated on a one-time basis at package upgrade time, and afterwards users get the surprising behavior that Port/ListenAddress settings added to sshd_config are ignored. A systemd generator could be used to change the ssh socket unit configuration on boot, and on each change of /etc/ssh/sshd_config. Sample implementation from Dimitri: ssh.socket: [Unit] Wants=sshd-config.path # # Note the below defaults are cleared and overriden by # /lib/systemd/system-generators/sshd-generator # based on the sshd config from the sshd -T output # ListenStream=[::]:22 ListenStream=0.0.0.0:22 diff --git a/systemd/sshd-config.path b/systemd/sshd-config.path new file mode 100644 index 000000000..cfa9674a3 --- /dev/null +++ b/systemd/sshd-config.path @@ -0,0 +1,4 @@ +[Unit] +ConditionPathExists=!/etc/ssh/sshd_not_to_be_run +[Path] +PathChanged=/etc/ssh/sshd_config diff --git a/systemd/sshd-config.service b/systemd/sshd-config.service new file mode 100644 index 000000000..b009ea52c --- /dev/null +++ b/systemd/sshd-config.service @@ -0,0 +1,5 @@ +[Unit] +Description=Regenerate ssh.socket.d/ssh-listen.conf drop-in + +[Service] +ExecStart=/bin/systemctl daemon-reload diff --git a/systemd/sshd-generator b/systemd/sshd-generator new file mode 100755 index 000000000..72c6aac04 --- /dev/null +++ b/systemd/sshd-generator @@ -0,0 +1,10 @@ +#!/bin/sh +set -eu +mkdir -p /run/sshd +sshd -t +mkdir -p $1/ssh.socket.d +target="$1/ssh.socket.d/ssh-listen.conf" +echo '[Socket]' > $target +echo 'ListenStream=' >> $target +sshd -T | sed -n 's/^listenaddress /ListenStream=/p' >> $target +rmdir --ignore-fail-on-non-empty /run/sshd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1991592/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
