Re: xinetd is a viable inet-superserver
[EMAIL PROTECTED] (Marco d'Itri) writes: On Nov 29, Roger Leigh [EMAIL PROTECTED] wrote: - create a /etc/inetd.d directory Wrong approach. Write an update-inetd replacement which can maintain its own database and can compare it to an existing configuration to know if the local admin changed something. I don't see a great difference here, to be honest, since both achieve the same end. - Your approach is opaque to the user, allowing direct editing of the non-conffile /etc/inetd.conf with rather complex parsing and comparison code. - My approach is non-opaque to the user, requiring editing of a inet.d/service file for each service, but with a trivial parser which will be both understandable and maintainable. The former approach is nicer in theory, but I do have to wonder why we haven't done so already. My guess is that it's rather difficult and no one cared enough to devote the effort. But, we do need to do something--the current approach is not good enough IMO. IIRC I did mention something along these lines for consideration So I probably already told you that you were wrong. A detailed explanation of why would be helpful. I'd like to understand your rationale. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpKmpo47cR5y.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Nov 29, 2007 at 10:17:22PM +, Roger Leigh wrote: The main problem (as I see it) is that the current update-inetd is too complex, and can't migrate configurations between different inetd config file formats. Why should that be the job of the current update-inetd? My opinion here is that one should be able to install any package Providing inet-superserver and expect the configuration to be carried over in some working form and get a working system. The Provides should be indicating some basic level of equivalence in functionality between the packages. And every maintainer script has to call update-inetd to make it write package-specific information, which is fragile Fragile in what sense? You can break the configuration of packages registering their services with update-inetd depending upon the specific order of installation and removal, particularly when combined with the replacement of one inet-superserver package with another. it only gets done when you install the package, and if you screw up inetd.conf, too bad. Er? Screw it up how? Why would it not be fixable with dpkg-reconfigure $package? Usually, yes. But, it shouldn't need that in the first place. One major issue I have is how packages are using update-inetd: [ /var/lib/dpkg/info/leafnode.postinst ] update-inetd --comment-chars #disabled# --disable nntp update-inetd --group MAIL --add --comment-chars #disabled# \ nntp stream tcp nowait news/usr/sbin/tcpd /usr/sbin/leafnode We are hardcoding a particular inetd.conf format as an argument, rather than specifying the fields separately. Additionally, we are not supporting IPv6--tcp4 is hardcoded, and this requires either adding a second entry or amending the existing one. For proper IPv6 support we need to get inetd services using IPv6 services out of the box. Why don't we take a leaf out of how other packages manage things and do this: - create a /etc/inetd.d directory - each package providing an inetd service can contain a /etc/inetd.d/package file containing all the information about the service; it could be a superset of the information xinetd and all the other inet daemons require, and have a parameter to enable/disable the service. This should be a conffile. - update-inetd takes no arguments, it just reads all the files in /etc/inetd.d/ and then writes out an inetd.conf, or xinetd configs, whatever the daemon requires. This has the big advantage of - allowing the user-customisable bits to be in conffiles for preservation across upgrades - makes the whole thing much simpler, maintainable and extensible - each inetd can provide a *trivial* update-inetd to read through the config files Using conffiles is a big *DIS*advantage. Conffiles are only minimally appropriate when there's a stock config which is expected to work for most users, and in the best of cases are annoying for users who diverge even minimally. When we're potentially talking about a config file format that contains the information about whether a service is enabled or disabled, that's a Bad Idea. But, the existing format is *already* doing this--with specially marked up comment lines (as shown above, yech!). And in most cases the user won't need to modify it; IMO each service as a conffile makes as much sense as /etc/pam.d and similar. It also makes updating by the package easier--currently update-inetd either preserves the user modification or it does not; the user can't later merge would /would/ have been updated as can be done with .dpkg-new and friends--it's lost unless you dig through maintainer scripts. You're also talking about a totally new config format that nothing actually *reads* today, so now instead of doing the right thing and teaching a tool to parse output the existing formats, we instead have a tool that parses one format and outputs another with the result that there are two copies of the information stored on the system - one in the place where existing users expect to find it which is *not* authoritative, and one in a totally new format that is authoritative. This is also a Bad Idea. Well, my implication was that a format such as the xinetd format would itself be such a superset--we don't need to invent a new format. And, incidentally, it also already has a disable parameter to do exactly the above. update-inetd then need only translate one format. And, this format supports global defaults such as IPv6 settings which the existing scheme will never do; this can be translated into multiple lines for the traditional inetd.conf, something the maintainer scripts can not do currently. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Re: xinetd is a viable inet-superserver
On Nov 29, Roger Leigh [EMAIL PROTECTED] wrote: - create a /etc/inetd.d directory Wrong approach. Write an update-inetd replacement which can maintain its own database and can compare it to an existing configuration to know if the local admin changed something. IIRC I did mention something along these lines for consideration So I probably already told you that you were wrong. -- ciao, Marco signature.asc Description: Digital signature
Re: xinetd is a viable inet-superserver
On Thu, Nov 29, 2007 at 01:16:04AM +, Steve Langasek wrote: On Wed, Nov 28, 2007 at 12:34:47PM +0100, Pierre Habouzit wrote: [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. This is at odds with many years of discussion on this mailing list, where the consensus was that xinetd should have its own update-inetd that supports the xinetd config format natively. Well, as a recent adopter of xinetd (which gives me some kind of tiny voice in the discussion) I believe that here is what should be done, and can be done with the _less_ hassle: packages that use update-inetd _could_ provide an /etc/xinetd.d/service or have a default one generated by update-inetd if none provided. And then update-inetd would search for services in /etc/inetd.conf _and_ in every /etc/xinetd.d/files. This would for example allow bitlbee to listen on localhost by default if used with xinetd (which you cannot tell in /etc/inetd.conf afaik and is the main reason why I use xinetd in the first place ;p). Though, I hate perl, like in despise and pukes the language, and despite my (timid) tries, I've not been able to come up with anything workable yet. I believe we should do that, because this way you can change your inetd and still have _some_ workeable configuration (with some drawbacks when you used to use xinetd with extensions and fallback to a stock inetd of course). With this approach, -inetd_compat can be disabled indeed. Until that point, that's the easiest way, and I believe it's a satisfying enough middle ground for now. And again, anyone that has enough perl skills can mail me in private so that we can sort this out. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpHsTOhsXaja.pgp Description: PGP signature
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 Ethgenhttp://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]
Re: xinetd is a viable inet-superserver
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Nov 28, 2007 at 12:34:47PM +0100, Pierre Habouzit wrote: [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. This is at odds with many years of discussion on this mailing list, where the consensus was that xinetd should have its own update-inetd that supports the xinetd config format natively. The main problem (as I see it) is that the current update-inetd is too complex, and can't migrate configurations between different inetd config file formats. And every maintainer script has to call update-inetd to make it write package-specific information, which is fragile; it only gets done when you install the package, and if you screw up inetd.conf, too bad. Why don't we take a leaf out of how other packages manage things and do this: - create a /etc/inetd.d directory - each package providing an inetd service can contain a /etc/inetd.d/package file containing all the information about the service; it could be a superset of the information xinetd and all the other inet daemons require, and have a parameter to enable/disable the service. This should be a conffile. - update-inetd takes no arguments, it just reads all the files in /etc/inetd.d/ and then writes out an inetd.conf, or xinetd configs, whatever the daemon requires. This has the big advantage of - allowing the user-customisable bits to be in conffiles for preservation across upgrades - makes the whole thing much simpler, maintainable and extensible - each inetd can provide a *trivial* update-inetd to read through the config files There will be a complication about preserving /existing/ configurations, but it shouldn't be difficult to handle this as a one-time task on initial upgrade, especially considering that the number of inetd-using packages is reasonably small. IIRC I did mention something along these lines for consideration post-etch last year or so, but I've been busy in the meantime. However, such a migration should be doable for Lenny; it would just need coordination to update all packages using update-inetd. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpGE2tPqAPBB.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
On Thu, Nov 29, 2007 at 10:17:22PM +, Roger Leigh wrote: The main problem (as I see it) is that the current update-inetd is too complex, and can't migrate configurations between different inetd config file formats. Why should that be the job of the current update-inetd? And every maintainer script has to call update-inetd to make it write package-specific information, which is fragile Fragile in what sense? it only gets done when you install the package, and if you screw up inetd.conf, too bad. Er? Screw it up how? Why would it not be fixable with dpkg-reconfigure $package? Why don't we take a leaf out of how other packages manage things and do this: - create a /etc/inetd.d directory - each package providing an inetd service can contain a /etc/inetd.d/package file containing all the information about the service; it could be a superset of the information xinetd and all the other inet daemons require, and have a parameter to enable/disable the service. This should be a conffile. - update-inetd takes no arguments, it just reads all the files in /etc/inetd.d/ and then writes out an inetd.conf, or xinetd configs, whatever the daemon requires. This has the big advantage of - allowing the user-customisable bits to be in conffiles for preservation across upgrades - makes the whole thing much simpler, maintainable and extensible - each inetd can provide a *trivial* update-inetd to read through the config files Using conffiles is a big *DIS*advantage. Conffiles are only minimally appropriate when there's a stock config which is expected to work for most users, and in the best of cases are annoying for users who diverge even minimally. When we're potentially talking about a config file format that contains the information about whether a service is enabled or disabled, that's a Bad Idea. You're also talking about a totally new config format that nothing actually *reads* today, so now instead of doing the right thing and teaching a tool to parse output the existing formats, we instead have a tool that parses one format and outputs another with the result that there are two copies of the information stored on the system - one in the place where existing users expect to find it which is *not* authoritative, and one in a totally new format that is authoritative. This is also a Bad Idea. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On 28-Nov-07, 13:01 (CST), Michael Biebl [EMAIL PROTECTED] wrote: Steve Greenland schrieb: On 28-Nov-07, 05:25 (CST), Michael Biebl [EMAIL PROTECTED] wrote: Pierre Habouzit schrieb: 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. I don't think this reasoning is correct. Take the existing implementations of system-log-daemon/linux-kernel-log-daemon, like rsyslog, syslog-ng or metalog. All use a different config file than /etc/syslog.conf. The difference is that other packages don't manipulate log file configuration. Well, packages shouldn't manipulate the inetd.conf file directly anyway but use the update-inetd interface. I wasn't sufficiently clear. The various -log-daemon packages don't provide *any* way other packages to manipulate the configuration, nor do any packages (to my knowledge/experious) attempt to change the log configuration. Therefore, the fact that the various -log-daemons use different config files is irrelevant to the inet-superserver discussion. As with many virtual packages, the inet-superserver is under-specified. Yes, you should use update-inetd, but since that is only run on package installation/upgrade, it doesn't do any good when changing to a different inetd. I believe that the general consensus would be that the best/safest way to manage these things is the individual-file-per-package model, rather than tools that manipulate a big flat file. But that would be a big change. Letting xinetd support /etc/inetd.conf seems like the smallest disruption. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Tue, Nov 27, 2007 at 05:42:43PM +, Klaus Ethgen wrote: Hello, Am Di den 27. Nov 2007 um 16:13 schrieb Pierre Habouzit: (1) xinetd reads and honours /etc/inetd.conf ; As long as this is default switched of this might be ok. No it's on by default, and easy to change in /etc/default/xinetd. But I do believe (and there was an RC open on xinetd for that, and I agree about it) that it being off by default is wrong, because xinetd cannot document it's a proper inet-superserver without doing that. If as an administrator you disagree, you can change that anytime. (2) if a service is configured through /etc/xinetd.d/ own configuration files _and_ inetd.conf then the former wins, which sounds like a reasonable thing. And what if a service is intentional _not_ configured for xinetd and the inetd.conf is ignored? Since xinetd conflicts with inet-superserver it's the sole one that can honour /etc/inetd.conf. The final plan is to let update-inetd work on both the xinetd configuration and /etc/inetd.conf. This way, here are the possible scenarios and administrator can use: (1) only honour /etc/xinetd* files, by disabling compat mode altogether. (2) work in compat mode, with the (probable, I did not checked but it's likely) drawback that a service disabled in the /etc/xinetd* and enabled in /etc/inetd.conf will probably be run. There are 2 ways of not falling in the (2) trap: - either always use update-inetd to enable or disable services (once it'll support xinetd configuration files btw) - or me patching xinetd if it behaves like I fear it does to ignore services from /etc/inetd.conf that are filed under the same name than in /etc/xinetd*. I believe it to be the proper approach, I'll try to write a patch asap. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdEJMBOsgLl.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Pierre, Am Mi den 28. Nov 2007 um 9:45 schrieb Pierre Habouzit: As long as this is default switched of this might be ok. No it's on by default, and easy to change in /etc/default/xinetd. So it is easy switchable. (May there are a debconf question?) But I do believe (and there was an RC open on xinetd for that, and I agree about it) that it being off by default is wrong, because xinetd cannot document it's a proper inet-superserver without doing that. If as an administrator you disagree, you can change that anytime. Well the problem is that this change the expected and desired way on existing installations. If you are a admin and didn't (want to) care about /etc/inetd.conf and with a update your xinetd will use it silently (and may open big, big security hole in your server) this is a very big issue! (And a security bug I think!) The only solutions would be eider: 1. Implement a debconf question and explain that there is a problem or 2. Switch it of by default for updates and maybe on by default on new installs. 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_. (1) only honour /etc/xinetd* files, by disabling compat mode altogether. Would be the best in my understanding. (2) work in compat mode, with the (probable, I did not checked but it's likely) drawback that a service disabled in the /etc/xinetd* and enabled in /etc/inetd.conf will probably be run. Disabled can also mean that the respective file is not created or deleted. There are 2 ways of not falling in the (2) trap: - either always use update-inetd to enable or disable services (once it'll support xinetd configuration files btw) Only if it provides the full functionality of xinetd (like ie. only allow specified ip range or only few connection at once). - or me patching xinetd if it behaves like I fear it does to ignore services from /etc/inetd.conf that are filed under the same name than in /etc/xinetd*. I believe it to be the proper approach, I'll try to write a patch asap. Why using the name of the service? In inetd.conf the name has to be the same than the port in /etc/services (and even some service might have multiple names). In xinetd the name can be any if you specify the service port in the config. So why not using the port to decide if the service is enabled or not? Regards Klaus Ethgen - -- Klaus Ethgenhttp://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) iQEVAwUBR00xmZ+OKpjRpO3lAQLGXwf9HtZwVqWrWuEEPGAVZoWxksc0hQWLMWF+ c1AGgzYCNw/0Nx0DbLIf8gXbdCVBmjblFWgQAEGqBvpMAA5ccvj+u3U+OWF3jFA3 Ru5LkwuwfdoF6KEh0BwDd1jOsABcps1altX41zPkAX/kHMjU3nx2XwdO+UKc7POs sUTJl8LgCf7XxQGIjoa8SrU6WNqaHV3JwKsoPg+PQ+9ithkTLgQVYiVz4hFHv1sK PjoyU8BtwLdY13qvuYieD9ZhgUfKkq++ADWQIX360gwEb/42biH6c5LlXVg/p6Bb qvYB3GEii+gyTq7gHFV5Hxz8eeN6FZgc6q3Gz4mzc4O5rXuLPag4yg== =0VQF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 09:15:05AM +, Klaus Ethgen wrote: Hi Pierre, Am Mi den 28. Nov 2007 um 9:45 schrieb Pierre Habouzit: As long as this is default switched of this might be ok. No it's on by default, and easy to change in /etc/default/xinetd. So it is easy switchable. Yes. (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 But I do believe (and there was an RC open on xinetd for that, and I agree about it) that it being off by default is wrong, because xinetd cannot document it's a proper inet-superserver without doing that. If as an administrator you disagree, you can change that anytime. Well the problem is that this change the expected and desired way on existing installations. If you are a admin and didn't (want to) care about /etc/inetd.conf and with a update your xinetd will use it silently (and may open big, big security hole in your server) this is a very big issue! (And a security bug I think!) It won't do that because new defaults /etc/inetd.conf are empty. And it's documented in NEWS.Debian properly, which administrators are supposed to read. apt-listchanges does that for you. The only solutions would be eider: 1. Implement a debconf question and explain that there is a problem or I don't want to use debconf. It's an overkill. Though I may force the setting to No instead of Yes if upgrading from an existing install. That's safer indeed. Will do that. 2. Switch it of by default for updates and maybe on by default on new installs. 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. (1) only honour /etc/xinetd* files, by disabling compat mode altogether. Would be the best in my understanding. You can do that, it's up to you as an administrator. (2) work in compat mode, with the (probable, I did not checked but it's likely) drawback that a service disabled in the /etc/xinetd* and enabled in /etc/inetd.conf will probably be run. 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. There are 2 ways of not falling in the (2) trap: - either always use update-inetd to enable or disable services (once it'll support xinetd configuration files btw) 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. - or me patching xinetd if it behaves like I fear it does to ignore services from /etc/inetd.conf that are filed under the same name than in /etc/xinetd*. I believe it to be the proper approach, I'll try to write a patch asap. Why using the name of the service? In inetd.conf the name has to be the same than the port in /etc/services (and even some service might have multiple names). In xinetd the name can be any if you specify the service port in the config. So why not using the port to decide if the service is enabled or not? 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. I don't expect administrators to be dumb enough to configure mutual exclusive services in their /etc/inetd.conf _and_ xinetd.conf. Or if they do, then I'm sure they already have plenty of rope and I don't mind giving them some more. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4mX6hG96VE.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote: 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. Where is that documented? Watching the progression of inetd packages in Debian has been dizzying, I don't have the sense that there's any sort of central plan that everyone's following. This virtual package's semantics certainly aren't documented in policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 11:08:27AM +, Steve Langasek wrote: On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote: 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. Where is that documented? Watching the progression of inetd packages in Debian has been dizzying, I don't have the sense that there's any sort of central plan that everyone's following. This virtual package's semantics certainly aren't documented in policy. Well I'd say that it's what common sense would expect[0], and with the -4 I just uploaded, the issues about -inetd_compat are discussed in NEWS.Debian, README.Debian and the changelog. 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. [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. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpziVHgfNNe2.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
Pierre Habouzit schrieb: On Wed, Nov 28, 2007 at 09:15:05AM +, Klaus Ethgen wrote: 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. I don't think this reasoning is correct. Take the existing implementations of system-log-daemon/linux-kernel-log-daemon, like rsyslog, syslog-ng or metalog. All use a different config file than /etc/syslog.conf. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: xinetd is a viable inet-superserver
On 28-Nov-07, 05:25 (CST), Michael Biebl [EMAIL PROTECTED] wrote: Pierre Habouzit schrieb: 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. I don't think this reasoning is correct. Take the existing implementations of system-log-daemon/linux-kernel-log-daemon, like rsyslog, syslog-ng or metalog. All use a different config file than /etc/syslog.conf. The difference is that other packages don't manipulate log file configuration. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Nov 28, Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote: 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. No, not really. Providing inet-superserver means that a package supports the /usr/sbin/update-inetd API. Where is that documented? Watching the progression of inetd packages in Debian has been dizzying, I don't have the sense that there's any sort of central plan that everyone's following. This virtual package's semantics I made one a long time ago, but people keep ignoring it. -- ciao, Marco signature.asc Description: Digital signature
Re: xinetd is a viable inet-superserver
Steve Greenland schrieb: On 28-Nov-07, 05:25 (CST), Michael Biebl [EMAIL PROTECTED] wrote: Pierre Habouzit schrieb: 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. I don't think this reasoning is correct. Take the existing implementations of system-log-daemon/linux-kernel-log-daemon, like rsyslog, syslog-ng or metalog. All use a different config file than /etc/syslog.conf. The difference is that other packages don't manipulate log file configuration. Well, packages shouldn't manipulate the inetd.conf file directly anyway but use the update-inetd interface. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
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 Ethgenhttp://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]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 07:01:13PM +, Michael Biebl wrote: Steve Greenland schrieb: On 28-Nov-07, 05:25 (CST), Michael Biebl [EMAIL PROTECTED] wrote: Pierre Habouzit schrieb: 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. I don't think this reasoning is correct. Take the existing implementations of system-log-daemon/linux-kernel-log-daemon, like rsyslog, syslog-ng or metalog. All use a different config file than /etc/syslog.conf. The difference is that other packages don't manipulate log file configuration. Well, packages shouldn't manipulate the inetd.conf file directly anyway but use the update-inetd interface. I'd be glad if you provide a patch to let it modify xinetd configurations. Until that, I'll let the inetd compat mode enabled by default, with a trivial way to remove it for the admin. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGCps8ZPQ7S.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 07:06:13PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8v7Rka3zKy.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 08:06:13PM +0100, Klaus Ethgen wrote: 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. There are three principal cases in which debconf is useful: - you have a setting to configure for which there is no reasonable default - you have a setting to configure that it's useful to allow preseeding for on initial install - you have an error message to display *conditionally* on upgrade. I don't think any of these apply to xinetd. Debconf should not be used as a substitute for either NEWS.Debian or for doing the hard work of figuring out the correct reasonable default. Doing so wastes translators' time and users' disk space. 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. Well, no, the other benefit is that you actually get integration with update-inetd, which is how packages declare themselves to the inet-superserver. But I'm not overly happy with this implementation, xinetd ought to be providing its own update-inetd script instead. But even in that case, there would be an upgrade issue on account of the fact that pre-existing entries in /etc/inetd.conf corresponding to packages that have previously called update-inetd would not be handled automatically upon installation of xinetd; or that they would at best suddenly become active when those packages are upgraded, rather than when xinetd is upgraded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 12:34:47PM +0100, Pierre Habouzit wrote: [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. This is at odds with many years of discussion on this mailing list, where the consensus was that xinetd should have its own update-inetd that supports the xinetd config format natively. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Am Di den 27. Nov 2007 um 16:13 schrieb Pierre Habouzit: (1) xinetd reads and honours /etc/inetd.conf ; As long as this is default switched of this might be ok. (2) if a service is configured through /etc/xinetd.d/ own configuration files _and_ inetd.conf then the former wins, which sounds like a reasonable thing. And what if a service is intentional _not_ configured for xinetd and the inetd.conf is ignored? Best wishes Klaus Ethgen - -- Klaus Ethgenhttp://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) iQEVAwUBR0xXE5+OKpjRpO3lAQK26Af+MBcnYCsLwnzfe60useU9ARzPBq2EKHf3 7x7CD1TvCel9/MJOnYGrxQEAOosy57mjQxCo5zViz096kW9QdBr1UVjWZb26kTUe 95OLOwwVqc+47/G9QZXmLIu6Xj9r/hFhTPpGTkAVG7u3SHERhgYPN5A0C8622+By VQpOjZ0kuIxma2p5/BxcNbgSnW/tE3BzgQDecnQiSEKzb3pCjZFjAvoZHxMQRUg/ bgUP9i/bbTw0725dqg6BRIzujPDaqQNAkCTCAWRNJCOK455R+Ig34/kPHd8K2l2/ +vbg58AasQrep4UFfPNOqJcqaNA0wap4GpBma7Yih5QDrEgdyi7kpQ== =VpFv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
