Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[David Timothy Strauss]

On Tue, Sep 8, 2015 at 10:48 AM Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> As far as I understand it, this duplication is present to give the
> sysadmin a choice between two ways to run sshd, depending on this
> particular ssh server's requirements.
>
> If ssh access is frequently used or needs to work quickly (for instance
> as the primary way to log in and fix things), enabling sshd.service
> means it will start "eagerly", on boot. Debian and its derivatives
> enable this by default (if sshd is installed).
>
> If ssh access is infrequently used, a sysadmin can disable sshd.service
> and enable sshd.socket instead. That means sshd will be started
> on-demand, which will take a bit longer (particularly if the reason to
> log in is that the server has hit performance problems), but reduces
> resource consumption until then. This would be appropriate if the reason
> for providing ssh access is as a rarely-used "developer console"
> analogous to Android's adb, for instance.
>

Starting SSH eagerly or lazily is an independent decision from using socket
activation. The lazy use case is clear, but you can use socket activation
for eager service startup by simply enabling the service and socket (if the
service doesn't already require the socket).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/08/2015 07:48 PM, Simon McVittie wrote:
> On 08/09/15 13:55, Francis Moreau wrote:
>> On 09/08/2015 12:09 PM, Richard Maw wrote:
>>> 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.
>>
>> 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.
> 
> As far as I understand it, this duplication is present to give the
> sysadmin a choice between two ways to run sshd, depending on this
> particular ssh server's requirements.
> 
> If ssh access is frequently used or needs to work quickly (for instance
> as the primary way to log in and fix things), enabling sshd.service
> means it will start "eagerly", on boot. Debian and its derivatives
> enable this by default (if sshd is installed).
> 
> If ssh access is infrequently used, a sysadmin can disable sshd.service
> and enable sshd.socket instead. That means sshd will be started
> on-demand, which will take a bit longer (particularly if the reason to
> log in is that the server has hit performance problems), but reduces
> resource consumption until then. This would be appropriate if the reason
> for providing ssh access is as a rarely-used "developer console"
> analogous to Android's adb, for instance.
> 

Yes that's my understanding too.

But I guess that some services can't be instanciated for each request
and in this case, there can be only one service unit, I think. And if
it's the case starting the service in on-demand mode will prevent to
start the service unit file by its own (ie. not using the socket unit file).

Thanks.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Simon McVittie]

On 08/09/15 13:55, Francis Moreau wrote:
> On 09/08/2015 12:09 PM, Richard Maw wrote:
>> 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.
> 
> 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.

As far as I understand it, this duplication is present to give the
sysadmin a choice between two ways to run sshd, depending on this
particular ssh server's requirements.

If ssh access is frequently used or needs to work quickly (for instance
as the primary way to log in and fix things), enabling sshd.service
means it will start "eagerly", on boot. Debian and its derivatives
enable this by default (if sshd is installed).

If ssh access is infrequently used, a sysadmin can disable sshd.service
and enable sshd.socket instead. That means sshd will be started
on-demand, which will take a bit longer (particularly if the reason to
log in is that the server has hit performance problems), but reduces
resource consumption until then. This would be appropriate if the reason
for providing ssh access is as a rarely-used "developer console"
analogous to Android's adb, for instance.

-- 
Simon McVittie
Collabora Ltd. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

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

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Richard Maw]

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.

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.

> > As another alternative though, you could consider the sshd_config file the
> > canonical location for the listen address, and have a generator parse
> > sshd_config, and write a drop-in snippet for sshd.socket to set the
> > ListenAddress.
> 
> Indeed that would work and would solve the problem, however not sure
> that sshd_config file will be available at the time when the generator
> will need it.

Systemd generally assumes that /usr and /etc are already mounted when it starts,
so generators should be able to read /etc/ssh/sshd_config.

> Also the generator would have to be generic enough to parse and support
> several config file syntax. And regarding the number of different config
> file syntax (can even be xml !), I'm not sure it will be a good idea.

Surely the generator for sshd.socket.d/listen-address.conf only needs to be
able to read the sshd_config file.

> Do you think that would be something that systemd upstream would be
> interested in ? Maybe there were already some discussions/works around
> that ?

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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

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

> As another alternative though, you could consider the sshd_config file the
> canonical location for the listen address, and have a generator parse
> sshd_config, and write a drop-in snippet for sshd.socket to set the
> ListenAddress.

Indeed that would work and would solve the problem, however not sure
that sshd_config file will be available at the time when the generator
will need it.

Also the generator would have to be generic enough to parse and support
several config file syntax. And regarding the number of different config
file syntax (can even be xml !), I'm not sure it will be a good idea.

Do you think that would be something that systemd upstream would be
interested in ? Maybe there were already some discussions/works around
that ?

Thanks.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Richard Maw]

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.

As another alternative though, you could consider the sshd_config file the
canonical location for the listen address, and have a generator parse
sshd_config, and write a drop-in snippet for sshd.socket to set the
ListenAddress.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

Hello,

Usually it's possible to specify the listen address a daemon/service
will listen to. For example, sshd has the 'ListenAddress' option that
can be used in its config file (sshd_config) which specifies the local
addresses sshd(8) should listen on.

The same parameter should be defined also in sshd.socket if we want to
use socket activation for sshd.

This can lead to odd situations because some listening addresses can be
defined in sshd_config whereas they're not specified in sshd.socket unit
file. In this case this address will never wake up sshd. However if sshd
is already running, because another listening address is used, then it
will serve the address only defined in sshd_config.

I think it's confusing (but I may be missing something).

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 ?

Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel