On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote:
> On Thu, Oct 04, 2001 at 01:19:15PM -0700, Crist J. Clark wrote:
> > That wouldn't work. The whole point of /var/run/named is to set the
> > permissions on the directory such that a non-root user (the 'bind'
> > user in FreeBSD typically) can write files in the directory. In order
> > to create the named directory in /var/run, you need root privs. Give
> > that to the program, and we are back where we started, no point in
> > using /var/run/named, just use /var/run.
> Named is startet under root rights and drop these later.
> It has to be so otherwise it's not possible to open port 53 for listen.
> So there is no great magic in creating the pid file in /var/run.
> If that's a problem I consider it as a bug in named.
You've never 'HUPped' a named running as non-root then. It will
complain about not being able to write the pid file (not that it is
a fatal problem). This is the reason for /var/run/named.
> > It is not that big of a deal to hack this support for named into the
> > rc scripts. It is a hassle when considering the "correct" way to
> > handle this to make it extensible to other daemons we may wish to run
> > in such a manner.
> The question is what is the correct way.
It happens I've just been hacking around in /etc/rc where the clean-up
of /var/run is done, and someone else mentioned mtree(8) in this
thread (but in a different context). I think it would be easy enough
to run mtree(8) right after /var/run is cleaned (and long after it would
be mounted as an md(4)) to get it into good form. The problem reduces
to maintaining the map file for this purpose.
Crist J. Clark [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message