[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 22:05 schrieb Pierre Habouzit:
> > 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.

Not all automatically enabled inetd services are wanted. (OK, that is
a completely other problem of the related package.)

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

The main point was if one use the interface update_inetd or provides its
own xinetd.d file. With update_inetd you cannot restrict your service
to, say, localhost.

> > >   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 didn't check. I do not ever care about /etc/inetd.conf as there is
many wast inside from old installations.

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

Right, you don't force ME (I come to that point a bit later). My goal is
to help making Debian the best and most secure distribution. If I see a
problem I tell about.

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

Because the users decides to install xinetd instead of inetd for special
reason. They want to have a more secure setup than the one with inetd.
That's the point. This is like using a complete other init like runsrv.
There cannot and shouldn't be a one to one mapping.

A small story I have experienced: Some time ago I had tested a backup
from a stable (I think sarge or older) distribution to restore on a sid
system. I had some points where I knew of configuration changes and
other (like xinetd) which hasn't (I believed). After the restore there
was some strange ports xinetd was listening on. I was really pissed when
I realiced the (default on) option in /etc/defaults/xinetd as it has
taken many time to find why the hell the new xinetd is handling services
it is explicit not configured to do! One more was that I was using samba
as daemon and was running into strange problems that many 1000 processes
was running cause of the conflict. But this is long ago.

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)

iQEVAwUBR06MXp+OKpjRpO3lAQKQ+Qf/XWDV0JjqPYq4jrits2msT/U8gEmgQ9ik
NpgJ1422/icZZ9h6pZaRlgs3ylnhc5Q9MUwrVWpQ+jIuSGhwz39HTc7wIhqp94ri
kYIM7Yr57zlkFRMZxd3DfEDYIYB+6FiA218wCbnLrB8Cct3C/JPuor/56LhMtGk2
dW0jE5tzylqxGcXeJIFocAaomw0AjkfW3S1QmvQBM89GoSLUAb+HUA/UNcJHEmS1
FWByM4zwembqNkr3+09ygiagLdm7Rjk6TTSW5lZ62ZFkapF8j5JqRhrmmdDP4RJy
KrwnFHNK8bqeO5IYKQdN0gDjel0nm0r7beo/WqREYO2+e1tUWdy/qg==
=6Isz
-----END PGP SIGNATURE-----



Reply to: