-----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 <[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) iQEVAwUBR028JZ+OKpjRpO3lAQLrjAf7B6erOuJ+yKJdaCvdwlQqC9LSz8XuhLsj P4KoPy8M+FpswpdyaIVdhqAnavs7TY4228eFhT8MDtK5r2f4zQYKUwZhCxunNFNk HyOg7Sz2uml8ZH+Erjv0nTBvGckh56xaReGlXFvNewEMIH+Xf+T0NatNOFUY61Ek BeH1BJyumFyhFFkrSnpqchHLV+FHc3AYI3Fq6YcYz2aOsh+nxZ3dEewHi+o18btj K9r7QdqaZBZ/ebChXdntE8UNdncWC/tKpyjti9ksggmp0LykvbCLpJ9sGH11gRLw mYosNbLuYkfBhQzfUNmqMiX4S1JY1hiL8/0OnYVnkAuJwevqtkPUMA== =B9iW -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]