[Tollef Fog Heen]
It seems quite inappropriate to limit this information to just a
single init system when we have more than one in Debian. We should
strive to move that information into a init-agnostic place, and I
don't see why it would be wrong to just have the relevant init
scripts
On Thu, 2010-10-21 at 20:27 +0200, Tollef Fog Heen wrote:
| Besides, I believe $named is a existing and fitting virtual facility
| for this use.
Indeed, it seems quite appropriate.
It would at least simplify things for my nslcd package which provides
name lookups (user, group, hosts, etc)
]] Petter Reinholdtsen
| [Tollef Fog Heen]
| It seems quite inappropriate to limit this information to just a
| single init system when we have more than one in Debian. We should
| strive to move that information into a init-agnostic place, and I
| don't see why it would be wrong to just
[Tollef Fog Heen]
Sounds like a bug in insserv, then.
As far as I can tell it is a design decision.
Did they provide any reasoning for this?
See URL: http://thread.gmane.org/gmane.comp.init.sysv.devel/66 for
the thread. :)
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email
]] Petter Reinholdtsen
| [Goswin von Brederlow]
| That way nfs-kernel-server is started after the name resolvers but
| none of them is required. Does that look right?
|
| Nope. Virtual facilities (like $named and $local_fs) provided by
| several scripts should not be listed in the Provides
Enrico Weigelt weig...@metux.de writes:
* Jesús M. Navarro jesus.nava...@undominio.net schrieb:
I imagine that in many cases if there's a locally installed
authoritative nameserver it will be used by the local resolver too.
That's just an assumption. In the last decade I had enough
[Goswin von Brederlow]
That way nfs-kernel-server is started after the name resolvers but
none of them is required. Does that look right?
Nope. Virtual facilities (like $named and $local_fs) provided by
several scripts should not be listed in the Provides line of
individual init.d scripts. So
* Jesús M. Navarro jesus.nava...@undominio.net schrieb:
I imagine that in many cases if there's a locally installed
authoritative nameserver it will be used by the local resolver too.
That's just an assumption. In the last decade I had enough systems
where this was not the case. Authorative
* Ben Hutchings b...@decadent.org.uk schrieb:
On Fri, 2010-10-15 at 04:15 +0200, Enrico Weigelt wrote:
* Ben Hutchings b...@decadent.org.uk schrieb:
Clearly any installed name server should be started before
nfs-kernel-server, but that might not be bind9. I don't know how and
where
* Enrico Weigelt weig...@metux.de schrieb:
No, the userland code that interprets the exports file does.
So why that artificial dependency ?
More precisely: where's the dependency between a local resolver
and an authorative nameserver ?
cu
--
Hi, Enrico:
On Friday 15 October 2010 13:39:13 Enrico Weigelt wrote:
* Enrico Weigelt weig...@metux.de schrieb:
No, the userland code that interprets the exports file does.
So why that artificial dependency ?
More precisely: where's the dependency between a local resolver
and an
On Thu, 2010-10-14 at 15:56 +0200, Oliver Joa wrote:
Hi,
On 29.09.2010 17:45, Bastian Blank wrote:
On Wed, Sep 29, 2010 at 03:09:58PM +0200, Oliver Joa wrote:
On 29.09.2010 15:04, Bastian Blank wrote:
What is the content of /etc/exports?
/export gutemine(fsid=0,rw,no_subtree_check)
* Ben Hutchings b...@decadent.org.uk schrieb:
Clearly any installed name server should be started before
nfs-kernel-server, but that might not be bind9. I don't know how and
where the dependency should be specified.
Does the kernel-nfsd do local dns lookups ?
cu
--
On Fri, 2010-10-15 at 04:15 +0200, Enrico Weigelt wrote:
* Ben Hutchings b...@decadent.org.uk schrieb:
Clearly any installed name server should be started before
nfs-kernel-server, but that might not be bind9. I don't know how and
where the dependency should be specified.
Does the
14 matches
Mail list logo
