Default services enabled

[Bill Nottingham]

Stephen John Smoogen (smooge at gmail.com) said: 
> > A socket-activated service is much the same as a non-socket-activated
> > service, in that installing the unit won't activate the service unless
> > something calls for it, or the admin/rpm scripts run 'systemctl enable'. So
> 
> A couple of questions:
> 
> 1) Does the above mean that every netscan will start up various
> services on systems?

Note that the most common socket-activated daemons are Unix domain sockets.

But, if you have a socket-activated service that's listening on TCP/UDP,
and have the socket enabled, yes, a connection to the socket would start
the service.


> 2) Would those services haven been listening before?

If you had enabled the service, sure. So, the rule of thumb would
be to enable the socket in the same situations where you would enable
the service, and disable the socket in the same situations where you'd
disable the service.

> 3) What is a good example that people can look at so we aren't all
> hand-wavy in this discussion about couldas and such. If we have
> something that is the "way it should be" we can then measure against
> it.

As an example, we have avahi-daemon.socket now. However, that socket is only
listening on the local socket in /run/avahi-daemon. So, if this socket was
enabled, a local request to avahi would activate the service, but a network
scan would not.

A different example is the current cups.socket. It listens on both the
local socket in /run/cups, and on port 631. So, in this case, a network
scan that hit TCP port 631 would activate cupsd.

In both cases, this behavior would require that the .socket file be enabled.

Bill