On Thu, Feb 16, 2012 at 10:13:26AM +0100, Bernd Zeimetz wrote:
> On 02/16/2012 12:22 AM, Serafeim Zanikolas wrote:
> > hi Goswin,
> >
> > On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote
> > [edited]:
> >> One thing though: Can I add my own local fragments? Is there a fragment
On Thu, Feb 16, 2012 at 09:41:40AM +0100, Goswin von Brederlow wrote [edited]:
[..]
> Putting local config into /usr/share is wrong though.
the answer to all local policy questions is: like you always did; you edit
inetd.conf.
/usr/share/reconf-inetd fragments are input to a *maintainer* tool. yo
On 02/16/2012 12:22 AM, Serafeim Zanikolas wrote:
> hi Goswin,
>
> On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote [edited]:
>> One thing though: Can I add my own local fragments? Is there a fragment
>> dir in /etc for that?
>
> you can, and they should also go to /usr/share/
Serafeim Zanikolas writes:
> hi Goswin,
>
> On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote [edited]:
>> One thing though: Can I add my own local fragments? Is there a fragment
>> dir in /etc for that?
>
> you can, and they should also go to /usr/share/reconf-inetd (as long a
hi Goswin,
On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote [edited]:
> One thing though: Can I add my own local fragments? Is there a fragment
> dir in /etc for that?
you can, and they should also go to /usr/share/reconf-inetd (as long as the
filenames don't conflict with any
Ian Jackson writes:
> Serafeim Zanikolas writes ("Re: [DEP9] call for testing of reconf-inetd
> (update-inetd replacement)"):
>> Any local sysadmin changes must be done in inetd.conf, as always.
>>
>> The choice of /usr/share/ follows from two of the r
Serafeim Zanikolas writes ("Re: [DEP9] call for testing of reconf-inetd
(update-inetd replacement)"):
> Any local sysadmin changes must be done in inetd.conf, as always.
>
> The choice of /usr/share/ follows from two of the requirements I
> have set from the beginning fo
Hi Ian,
First of all, thanks for the feedback.
On Mon, Feb 13, 2012 at 12:36:40PM +, Ian Jackson wrote:
> Serafeim Zanikolas writes ("[DEP9] call for testing of reconf-inetd
> (update-inetd replacement)"):
> > To test it, in a nutshell:
> >
> > - make
Serafeim Zanikolas writes ("[DEP9] call for testing of reconf-inetd
(update-inetd replacement)"):
> To test it, in a nutshell:
>
> - make your package install xinetd.conf(5) fragment files in
> /usr/share/reconf-inetd/, one file per service that needs an entry
Hi,
reconf-inetd is the replacement of update-inetd, as per DEP9. Unlike past
proposals for replacing update-inetd, this one is actually implemented and
available in experimental.
This should be of interest for services that
- require separate inetd.conf entries for ipv4/ipv6 versions
2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > > > but the primary benefits are making inetd support in maintainer scripts
> > > > both robust and idempotent.
>
> > > update-inetd in its present form can already be used to achieve this.
>
> > I beg t
]] Guillem Jover
| The other one I can offer is update-exim4.conf, which is the default
| from several ways to handle the exim4 configuration. But something I've
| always found pretty confusing and always switched my boxes to use the
| monolithic configuration file in /etc/exim4/exim4.conf. I'd w
On Mon, 2009-09-07 at 13:59:48 -0700, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > There are many obvious examples of update-foo scripts which behave in
> > this manner. The requirement to run a script to update the working
> > configuration is nothing n
any
> > > manual
> > > changes will be made effective by running update-inetd
> >
> > I think this violates the principle of least surprise (restarting the daemon
> > after making your changes has been enough to make those changes take effect
> > since the
scripts
> > > both robust and idempotent.
> > update-inetd in its present form can already be used to achieve this.
> I beg to differ. update-inetd assumes that a service name (``ftp'') is
> sufficient to enable, disable and remove a service, whereas to be
On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > but the primary benefits are making inetd support in maintainer scripts
> > both robust and idempotent.
>
> update-inetd in its presen
On Mon, Sep 07, 2009 at 11:19:02PM +0200, Julien Cristau wrote:
> > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > > * document that local policy will live in /etc/inetd.conf.d/ and any
> > > manual
> > > changes will be made effecti
On Fri, Sep 4, 2009 at 22:02:21 -0700, Steve Langasek wrote:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > * document that local policy will live in /etc/inetd.conf.d/ and any manual
> > changes will be made effective by running update-inetd
&g
On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> > proposal below to migrate it to dpkg triggers [0]
>
ting inetds?), but the primary benefits are making inetd support
> in maintainer scripts both robust and idempotent.
update-inetd in its present form can already be used to achieve this.
Unfortunately, the runes to accomplish it are rather underdocumented; but
I think the right way to ad
On Sun, Sep 06, 2009 at 11:30:25PM +0200, Marco d'Itri wrote:
> On Sep 04, Serafeim Zanikolas wrote:
>
> > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> > proposal below to migrate it to dpkg triggers [0]
> Maybe you could ha
ainer
> (which is another reason why you should have discussed this first with
> the other maintainers involved).
> /etc/inetd.conf is a well known UNIX interface and it must continue to
> be supported, at least for locally-configured services.
Actually, my initial goal was to just cl
On Sep 04, Serafeim Zanikolas wrote:
> As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> proposal below to migrate it to dpkg triggers [0]
Maybe you could have discussed it with the former maintainer, so I could
have explained why I never implemented the
On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote [edited]:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> Invocations of update-inetd that lead to local policy overrides are bugs in
> the caller, not in update-inetd. There is an explicitly reserve
On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> proposal below to migrate it to dpkg triggers [0]
> The Current Messy State of Affairs
> update-inetd script is problematic (maint
Hello world,
As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
proposal below to migrate it to dpkg triggers [0]
The Current Messy State of Affairs
update-inetd script is problematic (maintainer scripts use it to update the
/etc/inetd.conf conffile leading to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serafeim Zanikolas schrieb:
> Hi,
>
> Is it OK to reduce update-inetd's priority to optional, to agree with the
> archive admin's override? (It should be, as all its rdepends are at most
> optional)
>
> It should be Priority: standard only if people
Hi,
Is it OK to reduce update-inetd's priority to optional, to agree with the
archive admin's override? (It should be, as all its rdepends are at most
optional)
It should be Priority: standard only if people use it interactively, and
expect it to be part of a standard installation (but I'm guessi
On Tue, 2008-10-21 at 14:39 +0200, Lucas Nussbaum wrote:
> I'm not sure that filing lots of bugs about missing Depends on
> update-inetd really delays the release. Chris Lamb is fixing those bugs
> faster than I file them anyway ;)
You mean like this one?
http://bugs.debi
Package: wnpp
Severity: normal
I request assistance with maintaining the update-inetd package.
I've quite recently taken over the maintainership of update-inetd. Any
help on bug triage and/or co-maintainership would be welcomed.
The package description is:
This package provides a program
ot that good and my spare time not that much that I can read any mail
> in the list; sorry.
>
> However:
>
>>> be installed too. Xinetd do disable such a inetd in postinstall script.
>> Yes, the xinetd package needs to be integrated with the rest of Debian.
>
> I
[EMAIL PROTECTED] (Marco d'Itri) writes:
> So far this case has not been handled automatically and I do not think
> it is worth supporting because it would require creating stand-alone
> update-inetd packages for each kind of inetd.
I'm not at all surprised if there's so
On Aug 01, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Again, the update-inetd interface is formally provided by
> > inet-superserver and not by update-inetd.
> So there's no allowance for a package that wants to interface with inetd if
> it's installed,
On Sun, Jul 29, 2007 at 12:42:02PM +0200, Marco d'Itri wrote:
> > The rationale for samba depending on update-inetd was that samba does *not*
> > depend on the availability of an inet superserver; it only depends on the
> > availability of the update-inetd interface, in o
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Jul 31, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> I'm at a bit of a loss now as to whether to change lintian's checks or
>> not, although I did update the long description of that tag to not push
>> depending
On Jul 31, Russ Allbery <[EMAIL PROTECTED]> wrote:
> > FWIW, presently the only inet-superserver package that doesn't depend on
> > update-inetd is rlinetd, and it diverts /usr/sbin/update-inetd rather
> > than conflicting.
> That seems wrong to me, too, although i
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sat, Jul 28, 2007 at 10:46:30PM -0700, Russ Allbery wrote:
>> Couldn't any inet-superserver package that provides its own
>> update-inetd also Provide: update-inetd? Wouldn't that fix the
>> problem? It has
On Sat, Jul 28, 2007 at 10:46:30PM -0700, Russ Allbery wrote:
> Couldn't any inet-superserver package that provides its own update-inetd
> also Provide: update-inetd? Wouldn't that fix the problem? It has to
> Conflict with update-inetd anyway.
FWIW, presently the only inet-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Mo den 30. Jul 2007 um 13:34 schrieb Marco d'Itri:
> > Hmmm, Wrong in my opinion. If xinetd would have its own update-inetd and
> > software is installed in xinetd and $ADMIN decides to switch back to
> > traditional ine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 30, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
> Hmmm, Wrong in my opinion. If xinetd would have its own update-inetd and
> software is installed in xinetd and $ADMIN decides to switch back to
> traditional inetd the configuration
il
in the list; sorry.
However:
> > be installed too. Xinetd do disable such a inetd in postinstall script.
> Yes, the xinetd package needs to be integrated with the rest of Debian.
I agree.
> > However. What I did explain is that xinetd do not need to have a
> >
On Sun, 2007-07-29 at 16:22 +0200, Magnus Holmgren wrote:
>
> But: AFAIU, /etc/inetd.conf is now owned by any package, because it's
> used by
> several packages and updated by update-inetd. I think it makes sense
> for
> service packages, like samba, to update inetd.conf
On Sunday 29 July 2007 16:22, Magnus Holmgren wrote:
> But: AFAIU, /etc/inetd.conf is now owned by any package, because it's used
Just to make myself clear: s/now/not/
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
"Exim is better at bei
quot; inetd completely. But today the traditional inetd has to
> be installed too. Xinetd do disable such a inetd in postinstall script.
Yes, the xinetd package needs to be integrated with the rest of Debian.
> However. What I did explain is that xinetd do not need to have a
> update
On Jul 29, Magnus Holmgren <[EMAIL PROTECTED]> wrote:
> So you're saying that inet-superservers that use the traditional inetd.conf
> should depend on update-inetd as their way of implementing the update-inetd
> interface. Packages that provide services to be served
Magnus Holmgren <[EMAIL PROTECTED]> writes:
> But: AFAIU, /etc/inetd.conf is now owned by any package, because it's
> used by several packages and updated by update-inetd. I think it makes
> sense for service packages, like samba, to update inetd.conf even though
>
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Jul 29, Anthony Towns <[EMAIL PROTECTED]> wrote:
>> Isn't openbsd-inetd priority:standard? That's enough to make the
>> real-package unnecessary, afaik (and that lets the default inetd be
>> changed simply by changing the priorities of the packages, ra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Marco,
Am So den 29. Jul 2007 um 13:57 schrieb Marco d'Itri:
> > The update-inetd package is finally a good way to have a system with no
> > inetd installed (or the ill situation that two (inetd and xinetd) are
> >
On Sunday 29 July 2007 12:42, Marco d'Itri wrote:
> On Jul 29, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > The rationale for samba depending on update-inetd was that samba does
> > *not* depend on the availability of an inet superserver; it only depends
> > o
> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.
Are you asking for a flamewar? I really don't see any justification for
beeing attacked b
On Jul 29, Christian Perrier <[EMAIL PROTECTED]> wrote:
> It would even be more helpful if this could be summarized *and* filed
> as bugs with a clear suggestion of what should be done. I'm maybe a
Depend/Recommend/Suggest just "inet-superserver" or "openbsd-inet |
inet-superserver" (depending if
On Jul 29, Anthony Towns <[EMAIL PROTECTED]> wrote:
> Isn't openbsd-inetd priority:standard? That's enough to make the
> real-package unnecessary, afaik (and that lets the default inetd be
> changed simply by changing the priorities of the packages, rather than
> the dependencies of lots of packag
On Jul 29, Steve Langasek <[EMAIL PROTECTED]> wrote:
> The rationale for samba depending on update-inetd was that samba does *not*
> depend on the availability of an inet superserver; it only depends on the
> availability of the update-inetd interface, in order for its maintainer
&
On Sun, 29 Jul 2007 02:31:10 +0200, [EMAIL PROTECTED] (Marco d'Itri) wrote:
>Probably not, but in this case common sense would have been enough since
>update-inetd does not depend on anything else.
Common sense? Is that the thing one cannot commonly expect?
Gre
On Sun, Jul 29, 2007 at 03:59:13AM +0200, Marco d'Itri wrote:
> On Jul 29, Russ Allbery <[EMAIL PROTECTED]> wrote:
> > So is anything ever valid other than openbsd-inetd | inet-superserver as a
> > dependency? I keep getting confused on the rules around using virtual
> > packages. Would rlinetd |
Steve Langasek <[EMAIL PROTECTED]> writes:
> The rationale for samba depending on update-inetd was that samba does
> *not* depend on the availability of an inet superserver; it only depends
> on the availability of the update-inetd interface, in order for its
> maintainer script
On Sun, Jul 29, 2007 at 12:57:03AM +0200, Marco d'Itri wrote:
> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.
> This is *TOTALLY WRONG*
> It might be helpful if you could summarise what packages are supposed to
> be doing here - this may even affect enough packages to warrant a mail
> to debian-devel-announce. I don't recall ever seeing an announcement
> about this and I imagine that even among those maintainers who read this
> li
On Jul 29, Russ Allbery <[EMAIL PROTECTED]> wrote:
> So is anything ever valid other than openbsd-inetd | inet-superserver as a
> dependency? I keep getting confused on the rules around using virtual
> packages. Would rlinetd | inet-superserver be okay? Would
Formally yes, but I do not think th
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Jul 29, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> Currently, lintian allows any combination of dependencies on the
>> following packages to satisfy the dependency requirement from calling
>> update-inetd in maintainer
ian-devel
> discussions (as is clear from the fact that I apparently got the lintian
> check wrong). Is this documented somewhere that anyone could expect to
> find it?
Probably not, but in this case common sense would have been enough since
update-inetd does not depend on anything el
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 o
On Sun, Jul 29, 2007 at 12:57:03AM +0200, Marco d'Itri wrote:
> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.
> This is *TOTALLY WRONG*
[EMAIL PROTECTED] (Marco d'Itri) writes:
> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.
> This is *TOTALLY WRONG* because the /usr/sbin/
I don't know exactly how it happened, but a large number of maintainers
apparently ignored the discussions on this list and added to their
packages a dependency on update-inetd.
This is *TOTALLY WRONG* because the /usr/sbin/update-inetd interface is
guaranteed to be provided by whatever imple
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
is appealing IMHO. Russ: May I ask why you don't like xinetd?
> > xinetd, and update-inetd can use the information, which is a superset
> > (right?) of that used by other inetd's, to update the old-school
> > inetd.conf.
>
> A simpler fix is to create an update-inetd
s proposal is that every package using a super
server would have to be updated, but OTOH that is not a big number of
packages:
$ grep-dctrl -s Package -FDepends netkit-inetd -o -FDepends inet-superserver
-o -FDepends update-inetd \
/var/lib/apt/lists/mad_debian_dists_sid_main_binary-amd64
> 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
ot something
important enough to justify it.
> xinetd, and update-inetd can use the information, which is a superset
> (right?) of that used by other inetd's, to update the old-school inetd.conf.
A simpler fix is to create an update-inetd program which will update the
xinetd configuration
bout what people think of your solution.
Personally, I dislike xinetd and don't want to use it, but I don't have a
problem using its format as the input format (it's better than what
update-inetd uses now). However, any replacement update-inetd also has to
support the old form
work with
xinetd, and update-inetd can use the information, which is a superset
(right?) of that used by other inetd's, to update the old-school inetd.conf.
I think the situation is similar to the Debian menu .menu vs .desktop debate,
where the .desktop files contain a superset of the informat
grade, and then reenable the entries after upgrade
> > > > is complete?
>
> > > No, they shouldn't, because this loses local modifications to the
> > > inetd.conf
> > > line.
>
> > Actually it doesn't.
>
> > If you call update-i
gt; is complete?
> > No, they shouldn't, because this loses local modifications to the inetd.conf
> > line.
> Actually it doesn't.
> If you call update-inetd with --disable in prerm it just prepends
> "## " to your line (if the service is enabled), and when you c
-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 accid
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 fro
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
ions to the inetd.conf
> line.
Actually it doesn't.
If you call update-inetd with --disable in prerm it just prepends
"## " to your line (if the service is enabled), and when you call
it in postinst with --enable it will remove the "## ".
Running --enable will not touch
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
>&g
-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-
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
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
hat is the
> maintainer has decided the majority of users will not need it?
I'm installing entries disabled by default, and although my current
approach feels a bit dirty, seems to work. For example the snippets
for inetutils-telnetd:
,--- postinst
if [ "$1" = "configure"
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 is
at about entries that should be disabled by default? That is the
> maintainer has decided the majority of users will not need it?
>
> * is solving this worthy of etch?
> --
> Brian May <[EMAIL PROTECTED]>
I used to have proftpd in inetd.conf but with a increase connection
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.org/cgi-bin/bugreport.cgi?bug=401258;msg=98
It seems t
> "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
Hello,
Are there any good examples on the "correct way" of maintaining
inetd.conf entries in Debian maintainer scripts?
It appears Heimdal gets this wrong:
http://bugs.debian.org/401258
I strongly suspect the problem is the code (I copied elsewhere) that
disables the service on upgrades and the
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 mi
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
> finishe
-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 SIGNED MESSAGE-
Hash: SHA1
Hello,
I use the xinetd and like it much if the compatibility mode is switched
off.
However it whould be great if update-inetd could create a file in
/etc/xinetd.d with "disabled = yes". Moreover it whould be nice if
update-inetd co
96 matches
Mail list logo
