On Jul 24, Magnus Holmgren <[EMAIL PROTECTED]> wrote:
> Anyway, you have proposed that all superserver packages provide their own
> update-inetd implementation, which is fine and simple enough, except that
> it's not clear how the configuration would be transferred when one
> superserver is rep
Magnus Holmgren <[EMAIL PROTECTED]> writes:
> Perhaps not, but the possibility to just drop a configuration snippet in
> a ".d" directory, instead of having to mess with a single configuration
> file, is appealing IMHO. Russ: May I ask why you don't like xinetd?
A bad taste left over from Red Hat
On Monday 23 July 2007 18:47, Marco d'Itri wrote:
> On Jul 23, Magnus Holmgren <[EMAIL PROTECTED]> wrote:
> > Packages containing servers that can be started from inetd should all
> > provide an xinetd configuration file in /etc/xinetd.d. They will
> > instantly work with
>
> Way too much work, and
On Mon, Jul 23, 2007 at 05:45:31PM +0200, Magnus Holmgren wrote:
> A legitimate question is whether the xinetd configuration format is a good
> format. Are there, or will there be, even more "extended" inetd:s?
apt-cache search shows at least:
inetutils-inetd - Internet super server
micro-inet
> However, even more importantly than the discussion of possible solutions,
> we need an implementation. If you have a solution, please *implement* it
> (and in a way that doesn't make large parts of Debian buggy, which means
> being backwardly compatible) and I bet you'll be able to build a cons
On Jul 23, Magnus Holmgren <[EMAIL PROTECTED]> wrote:
> Packages containing servers that can be started from inetd should all provide
> an xinetd configuration file in /etc/xinetd.d. They will instantly work with
Way too much work, and "better support for xinetd" is not something
important enoug
Magnus Holmgren <[EMAIL PROTECTED]> writes:
> Boy, what an old bug!
> This has been discussed some times[1], but no conclusion reached. I'd
> like to suggest (again, probably) the following:
As near as I can tell, the reason why no conclusion has been reached is
because no one has written the co
Boy, what an old bug!
This has been discussed some times[1], but no conclusion reached. I'd like to
suggest (again, probably) the following:
Packages containing servers that can be started from inetd should all provide
an xinetd configuration file in /etc/xinetd.d. They will instantly work with
On Sun, 14 Jan 2007, Steve Langasek wrote:
> On Sat, Jan 13, 2007 at 10:21:35PM +0100, Peter Palfrader wrote:
> > On Sat, 13 Jan 2007, Steve Langasek wrote:
>
> > > > * should packages disable inetd config entries on removal and in
> > > > preparation for upgrade, and then reenable the entries af
On Sat, Jan 13, 2007 at 10:21:35PM +0100, Peter Palfrader wrote:
> On Sat, 13 Jan 2007, Steve Langasek wrote:
> > > * should packages disable inetd config entries on removal and in
> > > preparation for upgrade, and then reenable the entries after upgrade
> > > is complete?
> > No, they shouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
Am Sa den 13. Jan 2007 um 1:18 schrieb Roger Leigh:
> > c) update-inetd should default to creating none unless explicitly told
> >to. This has the advantage of staying secure if a dau admin install a
> >package accidentally.
>
> This wou
On Jan 13, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> I think this has a rather simple solution (for lenny?).
It does not, since there are multiple inet superserver daemons with
incompatible configuration file formats.
Now that I finally have been allowed to split update-inetd from netbase
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Thu, Jan 11, 2007 at 01:40:21PM +1100, Brian May wrote:
>> We really need a constant way of dealing with this in package updates.
>
>> Currently I have two very opposing views, and not entirely convinced
>> in either of them.
>
>> http://lists.debian
On Sat, 13 Jan 2007, Steve Langasek wrote:
> > * should packages disable inetd config entries on removal and in
> > preparation for upgrade, and then reenable the entries after upgrade
> > is complete?
>
> No, they shouldn't, because this loses local modifications to the inetd.conf
> line.
Actua
On Thu, Jan 11, 2007 at 01:40:21PM +1100, Brian May wrote:
> We really need a constant way of dealing with this in package updates.
> Currently I have two very opposing views, and not entirely convinced
> in either of them.
> http://lists.debian.org/debian-devel/2006/12/msg00279.html
> vs
> htt
Klaus Ethgen <[EMAIL PROTECTED]> writes:
> I have a another:
>
> Am Do den 11. Jan 2007 um 23:14 schrieb Roger Leigh:
>> a) Every package calling update-inetd should call it twice; once for
>>IPv4, and again for IPv6. This would require all packages to be
>>updated.
>> b) update-inetd sho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a another:
Am Do den 11. Jan 2007 um 23:14 schrieb Roger Leigh:
> a) Every package calling update-inetd should call it twice; once for
>IPv4, and again for IPv6. This would require all packages to be
>updated.
> b) update-inetd should
On Jan 11, Roger Leigh <[EMAIL PROTECTED]> wrote:
> The solution to this could be
> a) Every package calling update-inetd should call it twice; once for
>IPv4, and again for IPv6. This would require all packages to be
>updated.
> b) update-inetd should default to creating both unless expl
On Fri, 12 Jan 2007, Guillem Jover wrote:
> Hi,
>
> On Thu, 2007-01-11 at 13:40:21 +1100, Brian May wrote:
> > We really need a constant way of dealing with this in package updates.
> >
> > It seems to boil down to:
> >
> > * should packages disable inetd config entries on removal and in
> > pr
Hi,
On Thu, 2007-01-11 at 13:40:21 +1100, Brian May wrote:
> We really need a constant way of dealing with this in package updates.
>
> It seems to boil down to:
>
> * should packages disable inetd config entries on removal and in
> preparation for upgrade, and then reenable the entries after up
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> I used to have proftpd in inetd.conf but with a increase connection
> limit value and on every update the update-inetd would complain that
> the entry it expects differs from the one found.
>
> That should be fixed if it isn't already.
Another is
Brian May <[EMAIL PROTECTED]> writes:
> We really need a constant way of dealing with this in package updates.
>
> Currently I have two very opposing views, and not entirely convinced
> in either of them.
>
> http://lists.debian.org/debian-devel/2006/12/msg00279.html
>
> vs
>
> http://bugs.debian.
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
> "Andreas" == Andreas Barth <[EMAIL PROTECTED]> writes:
OBAndreas> I don't think one needs to touch inetd.conf at all (or
Andreas> any other service description) during upgrades, at least
Andreas> not as long as not changes to
> "Andreas" == Andreas Barth <[EMAIL PROTECTED]> writes:
Andreas> I don't think one needs to touch inetd.conf at all (or
Andreas> any other service description) during upgrades, at least
Andreas> not as long as not changes to the service are
Andreas> necessary. I would rather r
* Brian May ([EMAIL PROTECTED]) [061211 15:54]:
> I strongly suspect the problem is the code (I copied elsewhere) that
> disables the service on upgrades and then re-enables it again after
> the upgrade is finished (hmmm seems broken just thinking about
> it).
>
> Anyway, in this case, the ser
On Tue, Feb 14, 2006 at 08:37:26AM +1000, Andrew Pollock wrote:
> I realise that update-inetd needs to be more flexible than just servicing
> xinetd and netkit-inetd style configurations though...
What do you mean by "more flexible"? IMHO update-inetd should implement
just the minimum needed for
On Feb 13, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> I've been wanting to see netkit-inetd gone from base for many many years
> now. Once, aj told me what needed to be done, and I think I even wrote it
> down. Somewhere. I just have to find it again...
This follows the usual pattern: I explain w
On Mon, Feb 13, 2006 at 05:09:32PM +0100, Marco d'Itri wrote:
> On Feb 13, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
>
> > However it whould be great if update-inetd could create a file in
> Many new features in update-inetd would be great, but nobody ever
> finished implementing them.
>
I've been
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 13, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
> However it whould be great if update-inetd could create a file in
Many new features in update-inetd would be great, but nobody ever
finished implementing them.
- --
ciao,
Marco
-BEGIN PGP SIGN
29 matches
Mail list logo
