I found the following statement at ISPconfig.org, and am not sure I understand what I'm being told: They say that the ISPconfig service supports "vsftpd as inetd/xinetd/standalone version". I assume "standalone" means, "launched manually" and not as part of the bootup sequence, or something like that? Are not inetd and xinetd just ways to configure services to run? How are they different than the runlevel schemes with script in /etc/inet.d? Peter
Peter Van Lone wrote:
I found the following statement at ISPconfig.org, and am not sure I understand what I'm being told:
They say that the ISPconfig service supports "vsftpd as inetd/xinetd/standalone version".
I assume "standalone" means, "launched manually" and not as part of the bootup sequence, or something like that?
Stand-alone means just as a daemon. Probably as part of the regular startup sequence.
Are not inetd and xinetd just ways to configure services to run? How are they different than the runlevel schemes with script in /etc/inet.d?
inetd and xinetd run services on-demand - if you start them via /etc/init.d/ scripts they run all the time. For instance, you could start vsftpd via a script in /etc/init.d/ and it would always be active. Or you could start it via xinetd in which case vsftpd would only be started when someone accessed your ftp-service. /Per Jessen, Zürich
On 5/24/06, Per Jessen
Stand-alone means just as a daemon. Probably as part of the regular startup sequence.
ok, thnx
inetd and xinetd run services on-demand - if you start them via /etc/init.d/ scripts they run all the time.
hmm ... is delivering services that way a "standard practice"? Generally, I can't think of a good reason to do it, other than perhaps if you have a small "general purpose" server that is close to capacity, you might want to setup services this way, so as not to burn memory/cpu cycles more than is required. Is that about right? Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-05-24 at 13:14 -0500, Peter Van Lone wrote:
inetd and xinetd run services on-demand - if you start them via /etc/init.d/ scripts they run all the time.
hmm ... is delivering services that way a "standard practice"?
Of course it is. It is your choice to do things one way or others depending on your requirements... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEdKXBtTMYHG2NR9URAiEpAJwNy93018GcA2A77e0zcEo7sTjbcwCfS9qa VHcp9Cq7qUmQYLnJPkrwHLc= =LYlk -----END PGP SIGNATURE-----
Peter Van Lone wrote:
inetd and xinetd run services on-demand - if you start them via /etc/init.d/ scripts they run all the time.
hmm ... is delivering services that way a "standard practice"?
Fairly standard practice I would say. Or certainly not uncommon.
Generally, I can't think of a good reason to do it, other than perhaps if you have a small "general purpose" server that is close to capacity, you might want to setup services this way, so as not to burn memory/cpu cycles more than is required.
Is that about right?
Well, not quite. An idle daemon does not consume many resources, memory nor CPU, so IMHO it's not so much about saving resources, but more about management. If I have a service, tftp for instance, that is only being used e.g. every 2-3 days, it goes straight into xinetd. I would say anything that isn't in use at least 3-4 times per day belongs in xinetd. I have some systems where I even run sshd through xinetd. /Per Jessen, Zürich
On 5/24/06, Per Jessen
Well, not quite. An idle daemon does not consume many resources, memory nor CPU, so IMHO it's not so much about saving resources, but more about management. If I have a service, tftp for instance, that is only being used e.g. every 2-3 days, it goes straight into xinetd. I would say anything that isn't in use at least 3-4 times per day belongs in xinetd. I have some systems where I even run sshd through xinetd.
ok, excellent, thank you Per One of the hardest things to get a handle on, as a long-time "netware" dude, is just this sort of thing. I know by instinct how to put together and trouble-shoot a netware networking environment. I know, from amongst the myriad choices, which make sense and which do not. That is not the case, yet ... in the linux world. Learnin' to walk, again! ;-)
Peter Van Lone wrote:
ok, excellent, thank you Per
One of the hardest things to get a handle on, as a long-time "netware" dude, is just this sort of thing. I know by instinct how to put together and trouble-shoot a netware networking environment. I know, from amongst the myriad choices, which make sense and which do not.
That is not the case, yet ... in the linux world. Learnin' to walk, again!
One thing it's worth being aware of - there are very, very few absolutely right or wrong answers to questions like this. There is a lot of tradition about, and the elegance of a particular choice or solution can also be quite "important". That I like using xinetd for infrequently used services/daemons doesn't automagically mean you should do the same - running those infrequently used services as standalone daemons will not eat away all your performance :-) /Per Jessen, Zürich
On 5/25/06, Per Jessen
One thing it's worth being aware of - there are very, very few absolutely right or wrong answers to questions like this. There is a lot of tradition about, and the elegance of a particular choice or solution can also be quite "important".
that's why I ask ...
That I like using xinetd for infrequently used services/daemons doesn't automagically mean you should do the same - running those infrequently used services as standalone daemons will not eat away all your performance :-)
yes, I get it. I've been around long enough to trust my own counsel. But yet, to know that gathering opinions, is always a good thing. Thank you! Peter
participants (3)
-
Carlos E. R.
-
Per Jessen
-
Peter Van Lone