Re: xinetd is a viable inet-superserver
-----BEGIN PGP SIGNED MESSAGE-----
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.
>  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 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----