-----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 <[EMAIL PROTECTED]> 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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]