|
Home > Archive > Debian Developers > December 2007 > xinetd is a viable inet-superserver
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
xinetd is a viable inet-superserver
|
|
| Pierre Habouzit 2007-11-27, 7:22 pm |
| | |
| Klaus Ethgen 2007-11-28, 1:45 am |
| -----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 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)
iQEVAwUBR0xXE5+OKpjRpO3lAQK26Af+MBcnYCsL
wnzfe60useU9ARzPBq2EKHf3
7x7CD1TvCel9/ MJOnYGrxQEAOosy57mjQxCo5zViz096kW9QdBr1U
VjWZb26kTUe
95OLOwwVqc+47/G9QZXmLIu6Xj9r/hFhTPpGTkAVG7u3SHERhgYPN5A0C8622+By
VQpOjZ0kuIxma2p5/BxcNbgSnW/tE3BzgQDecnQiSEKzb3pCjZFjAvoZHxMQRUg/
bgUP9i/ bbTw0725dqg6BRIzujPDaqQNAkCTCAWRNJCOK455
R+Ig34/kPHd8K2l2/
+vbg58AasQrep4UFfPNOqJcqaNA0wap4GpBma7Yi
h5QDrEgdyi7kpQ==
=VpFv
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pierre Habouzit 2007-11-28, 7:39 am |
| | |
| Klaus Ethgen 2007-11-28, 7:39 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Pierre,
Am Mi den 28. Nov 2007 um 9:45 schrieb Pierre Habouzit:
>
> 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 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)
iQEVAwUBR00xmZ+OKpjRpO3lAQLGXwf9HtZwVqWr
WuEEPGAVZoWxksc0hQWLMWF+
c1AGgzYCNw/ 0Nx0DbLIf8gXbdCVBmjblFWgQAEGqBvpMAA5ccvj
+u3U+OWF3jFA3
Ru5LkwuwfdoF6KEh0BwDd1jOsABcps1altX41zPk
AX/kHMjU3nx2XwdO+UKc7POs
sUTJl8LgCf7XxQGIjoa8SrU6WNqaHV3JwKsoPg+P
Q+9ithkTLgQVYiVz4hFHv1sK
PjoyU8BtwLdY13qvuYieD9ZhgUfKkq++ADWQIX36
0gwEb/42biH6c5LlXVg/p6Bb
qvYB3GEii+gyTq7gHFV5Hxz8eeN6FZgc6q3Gz4mz
c4O5rXuLPag4yg==
=0VQF
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pierre Habouzit 2007-11-28, 7:39 am |
| | |
| Steve Langasek 2007-11-28, 7:39 am |
| On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote:
[vbcol=seagreen]
> 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pierre Habouzit 2007-11-28, 7:39 am |
| | |
| Michael Biebl 2007-11-28, 7:39 am |
| Pierre Habouzit schrieb:
> On Wed, Nov 28, 2007 at 09:15:05AM +0000, Klaus Ethgen 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.
>
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?
| |
| Steve Greenland 2007-11-28, 1:26 pm |
| On 28-Nov-07, 05:25 (CST), Michael Biebl <biebl@debian.org> wrote:
> Pierre Habouzit schrieb:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2007-11-28, 1:26 pm |
| On Nov 28, Steve Langasek <vorlon@debian.org> wrote:
> On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote:
No, not really. Providing inet-superserver means that a package supports
the /usr/sbin/update-inetd API.
[vbcol=seagreen]
> 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
| |
| Michael Biebl 2007-11-28, 7:36 pm |
| Steve Greenland schrieb:
> On 28-Nov-07, 05:25 (CST), Michael Biebl <biebl@debian.org> wrote:
>
> 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?
| |
| Klaus Ethgen 2007-11-28, 7:36 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit:
>
> 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.
>
> 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.
>
> 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.
>
> 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 <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)
iQEVAwUBR028JZ+OKpjRpO3lAQLrjAf7B6erOuJ+
yKJdaCvdwlQqC9LSz8XuhLsj
P4KoPy8M+FpswpdyaIVdhqAnavs7TY4228eFhT8M
DtK5r2f4zQYKUwZhCxunNFNk
HyOg7Sz2uml8ZH+Erjv0nTBvGckh56xaReGlXFvN
ewEMIH+Xf+T0NatNOFUY61Ek
BeH1BJyumFyhFFkrSnpqchHLV+FHc3AYI3Fq6YcY
z2aOsh+nxZ3dEewHi+o18btj
K9r7QdqaZBZ/ebChXdntE8UNdncWC/tKpyjti9ksggmp0LykvbCLpJ9sGH11gRLw
mYosNbLuYkfBhQzfUNmqMiX4S1JY1hiL8/0OnYVnkAuJwevqtkPUMA==
=B9iW
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pierre Habouzit 2007-11-28, 7:36 pm |
| | |
| Pierre Habouzit 2007-11-28, 7:36 pm |
| | |
| Steve Langasek 2007-11-28, 7:36 pm |
| 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:
[vbcol=seagreen]
> [...]
[vbcol=seagreen]
> 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2007-11-28, 7:36 pm |
| 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pierre Habouzit 2007-11-29, 7:37 am |
| | |
| Klaus Ethgen 2007-11-29, 7:37 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Am Mi den 28. Nov 2007 um 22:05 schrieb Pierre Habouzit:
>
> 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.)
>
> 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.
>
> 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+jIuSGhwz
39HTc7wIhqp94ri
kYIM7Yr57zlkFRMZxd3DfEDYIYB+6FiA218wCbnL
rB8Cct3C/JPuor/56LhMtGk2
dW0jE5tzylqxGcXeJIFocAaomw0AjkfW3S1QmvQB
M89GoSLUAb+HUA/UNcJHEmS1
FWByM4zwembqNkr3+09ygiagLdm7Rjk6TTSW5lZ6
2ZFkapF8j5JqRhrmmdDP4RJy
KrwnFHNK8bqeO5IYKQdN0gDjel0nm0r7beo/WqREYO2+e1tUWdy/qg==
=6Isz
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2007-11-30, 7:37 am |
| | |
| Steve Greenland 2007-11-30, 7:37 am |
| On 28-Nov-07, 13:01 (CST), Michael Biebl <biebl@debian.org> wrote:
> Steve Greenland schrieb:
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2007-11-30, 7:37 am |
| On Thu, Nov 29, 2007 at 10:17:22PM +0000, 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2007-11-30, 7:37 am |
| On Nov 29, Roger Leigh <rleigh@whinlatter.ukfsn.org> 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
| |
| Roger Leigh 2007-12-01, 1:23 pm |
| | |
| Roger Leigh 2007-12-01, 1:23 pm |
| |
|
|
|
|