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

Re: xinetd is a viable inet-superserver



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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.

True.

>   [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?)

Regards
   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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBR028JZ+OKpjRpO3lAQLrjAf7B6erOuJ+yKJdaCvdwlQqC9LSz8XuhLsj
P4KoPy8M+FpswpdyaIVdhqAnavs7TY4228eFhT8MDtK5r2f4zQYKUwZhCxunNFNk
HyOg7Sz2uml8ZH+Erjv0nTBvGckh56xaReGlXFvNewEMIH+Xf+T0NatNOFUY61Ek
BeH1BJyumFyhFFkrSnpqchHLV+FHc3AYI3Fq6YcYz2aOsh+nxZ3dEewHi+o18btj
K9r7QdqaZBZ/ebChXdntE8UNdncWC/tKpyjti9ksggmp0LykvbCLpJ9sGH11gRLw
mYosNbLuYkfBhQzfUNmqMiX4S1JY1hiL8/0OnYVnkAuJwevqtkPUMA==
=B9iW
-----END PGP SIGNATURE-----



Reply to: