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

Re: xinetd is a viable inet-superserver

On Wed, Nov 28, 2007 at 07:06:13PM +0000, Klaus Ethgen wrote:
> Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit:

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

  Debconf can be used if there isn't a sane default.

> >   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.

  and to allow the auto-configuration debian is supposed to give for
inetd-powered services.

> > > 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.

  your call.

> > > 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.

  I still don't understand how it's relevant to -inetd_compat.

> >   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.

  oh and there are services with the same name in /etc/inetd.conf ? I
bet that not. I try to make the packager life simple with this one.
Nothing more. I still don't understand why you're fighting here. I don't
force you to also write an /etc/inetd.conf right ?

> >   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!

  Admins are supposed to read the documentation about the package they
install, and if they believe it's a dangerous thing, they can change the
default in /etc/default/xinetd once for all.

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

  I grow tired of that argument, why should I sacrifice Debian
auto-configurability for the 99% of the users that use xinetd extensions
for some of the services only ? Again, just edit your
/etc/default/xinetd. It's a conffile, it won't be overwritten behind
your back, give me a break.

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpASJyUQkCll.pgp
Description: PGP signature

Reply to: