Tim wrote:
> As far as I was aware, xinetd (or the prior inetd), was just for running
> services that didn't act as stand-alone, continuously running, services.
> Xinetd would start them up, as needed. Which, obviously, isn't
> efficient for anything that's slow to start up. (Been there, done that,
> before having anything ever to do with Linux.)
>
> Perhaps xinetd wasn't working as you thought it did, or that there's a
> way to use it with ssh in the manner I just described.
You're right, except ...
Many services can be run from (x)inetd even if they can also run as
standalone daemons. This used to be considered good practice for daemons
which might well not be needed -- they would start and run if you needed
them, otherwise they didn't take up precious memory.
I understand that OpenSSH can be run this way: from man sshd on FC6:
-i Specifies that sshd is being run from inetd(8). sshd is normally
not run from inetd because it needs to generate the server key
before it can respond to the client, and this may take tens of
seconds. Clients would have to wait too long if the key was
regenerated every time. However, with small key sizes (e.g.,
512) using sshd from inetd may be feasible.
As far as I can tell, the server key is only needed for SSH protocol 1,
and it wouldn't take so long on todays computers anyway.
These days, it's considered better practice to turn network daemons right
off if you're not going to use them, and daemons you are going to use
might as well be loaded anyway. That only leaves daemons you *might* use,
and for many sites there won't be enough of them to justify running an
extra (x)inetd process.
Hope this helps,
James.
--
E-mail: james@ | "No animals were harmed in the making of this burger."
aprilcottage.co.uk | -- "I'm Sorry, I Haven't A Clue", BBC Radio 4
