On 09/08/2015 12:09 PM, Richard Maw wrote: > On Tue, Sep 08, 2015 at 10:05:05AM +0200, Francis Moreau wrote: >> On 09/07/2015 11:28 AM, Richard Maw wrote: >>> On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote: >>>> How is this handled ? Should we put a big warning in sshd_config to hint >>>> user to configure ListenAddress in sshd.socket in the case socket >>>> activation is used ? >>> >>>> Or should sshd simply ignore all listening addresses defined in sshd_config >>>> when in socket activation mode ? >>> >>> That would be my preferred solution. I may be missing something important >>> here, >>> but I'd always assumed that sshd wouldn't need to worry about the listen >>> address if something else was accepting the connections on the socket. >>> >> >> The downside of this would be that starting the service directly (ie not >> the socket unit) won't work anymore > > Does it? > > I understood that the common configuration for socket activated sshd was to > have a sshd.service for if you want it to always be running, and a pair of > sshd@.service and sshd.socket. > > The former runs with -D, and the latter runs with -i. >
Ah no, with this design starting sshd.service should do the right thing but that's because there're 2 different service unit files: sshd@.service and sshd.service. I suppose that was done because sshd wasn't modified to use systemd's native socket passing interface (sd_listen_fds). If it was the case then only one service unit file would be used I think. And in this case, the service unit would start sshd in 'OnDemand' mode always. In this case we can't start directly sshd.service, but have to use socket activation. > Presumably this would be sufficient information that sshd could be made to > ignore the listen address in the sshd_config if it's being run with -i. > I'm not sure I'm understanding... [...] > > For parsing config files of other configuration systems, no, sysvinit and > /etc/fstab are mostly the only foreign configuration formats systemd cares > about. > > These are also split out into the generator mechanism rather than parsed by > systemd directly. > > Systemd tends not to carry service configuration for other software, > though the openssh upstream, or their distribution downstreams could > carry the code for a listen address configuration generator. > > See http://www.freedesktop.org/software/systemd/man/systemd.generator.html for > how generators work and > https://github.com/systemd/systemd/blob/master/src/debug-generator/debug-generator.c > for an example. > Thanks for the pointer. That makes sense although I'm not sure that service projects are willing to include a systemd generator in their repo. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel