[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xinetd is a viable inet-superserver

Hash: SHA1


Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit:
> > (May there are a debconf question?)
>   No I won't use debconf here, because it's definitely the most viable
> way to use xinetd nowadays. Though the next upload will document that
> fact completely in the README.Debian
>   I don't want to use debconf. It's an overkill.

Pardon? debconf overkill? This is right the correct place for it as it
change the basic way the package work completely.

> > >   Since xinetd conflicts with inet-superserver it's the sole one that
> > > can honour /etc/inetd.conf.
> > 
> > Well, not completely true. There might be more than one understanding.
> > Mine is that providing a inet-superserver provides the _functionality_
> > of a inet-superserver not the same _config file_.
>   wrong. providing inet-superserver means that you are able to perform
> what any implementation of inetd(8) does, namely, reading
> /etc/inetd.conf, and _then_ possibly have extended features on its own.

There we have completely other understanding of. xinetd is a replacement
(with its own configuration). Using the inetd.conf you have no benefit
of using the plain old one. The compat mode is only good for migration.

> > Disabled can also mean that the respective file is not created or
> > deleted.
>   Too bad. Note that given that xinetd proposes the handly "disabled =
> yes" configuration option, that's unwise.

Why? I know the option. But a deleted (or truncated to zero size) file
is more clear than a option inside.

> > Only if it provides the full functionality of xinetd (like ie. only
> > allow specified ip range or only few connection at once).
>   Gni ? I don't understand what you're talking about.

See manpage options only_from or instances or log_on_* for example.

>   because the duplicated configuration in stock /etc/inetd.conf _and_
> /etc/xinetd.c/* configuration will come from packages that want to
> support both, and then the service name will be the same.

Untrue. If I look for my configuration, around 50% of the xinetd
services are handmade.

>   I don't expect administrators to be dumb enough to configure mutual
> exclusive services in their /etc/inetd.conf _and_ xinetd.conf.

Well, just to think about a (fictive) common one, admins might start
with inetd and /etc/inetd.conf and configure there stuff. Then after
years they decide switching to xinetd to have a more granularly way to
control there services. They ignore the old inetd.conf and configure all
services in xinetd. Sometimes later they decide to switch of a service
(by deleting the file as they don't need it anymore). But it is still
running as xinetd uses the entry in inetd.conf. A horror thought!

Am Mi den 28. Nov 2007 um 12:34 schrieb Pierre Habouzit:
> And upgrading xinetd from a previous version won't activate it by
> default (with the except of -3 sorry for them). I believe this is the
> best way to handle the transition: statu quo for "old" users, new
> behavior for new ones.


>   [0] the reasoning is: this is clear to me that through update-inetd
>       that is the debian way to enable inet-like services, something
>       that claims to be an inet-superserver must react on update-inetd
>       triggered changes.  update-inetd atm only acts on /etc/inetd.conf,
>       so as a consequences I believe it's necessary for an
>       inet-superserver provider to grok /etc/inetd.conf.

Well, it might be clear for you but I install xinetd to get away from
this crap of the old inetd config. So for me the idea that xinetd might
use /etc/inetd.conf is a horror! (Well I controll it after each update
now but what about other who see that the same than I?)

   Klaus Ethgen
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: