From owner-freebsd-arch Thu Feb 22 20:50:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 57AAB37B401 for ; Thu, 22 Feb 2001 20:50:26 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14VQDJ-0000Gz-00; Tue, 20 Feb 2001 20:45:13 -0700 Message-ID: <3A9339C9.C23CBC04@softweyr.com> Date: Tue, 20 Feb 2001 20:45:13 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Jonathan Lemon , arch@freebsd.org Subject: Re: DJBDNS vs. BIND References: <200102202116.OAA27627@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > It would be fairly trivial to monitor a configuration file with kevent, > > which would generate a notice whenever the file is changed/copied/renamed, > > etc. I believe that John-Mark Gurney had patches somewhere to implement > > exactly this for inetd. > > > > The problem is that under our current model, the administrators do not > > expect writes to the file to take immediate effect, and this immediately > > breaks POLA. So while it could be done, it may not be a good idea. At > > the very least, I would argue that it should be hidden behind a flag option. > > This is what makes something with an API a better bet, since > you can define it to be a semantic of the API. That prevents > a POLA violation. > > I like that people are willing to at least discuss using a new > API that isn't implemented everywhere; many of the system calls > we have today started out that way, too, and it was use, which > proved their utility, which propelled them to the level of a > standard. Given that we have kqueue monitoring for files, I'd suggested an otherwise unused file flag and a chflags command to twiddle it. A daemon could monitor for changes to the "config" flag and re-read the file upon this event; the administrator could simple "chflags config /etc/inetd.conf" to notify anyone interested that inetd.conf has been changed and should now work. > Lets not hamstring ourselves over having to hide such a fundamental > improvement behind a flag, before we even know the shapes it might > take. We'll have the rest of time to be self limiting, after we > figure out what it should look like. 8-). Or, rather than hiding them behind a change in an otherwise unrelated flag, put one up there that means exactly what we're asking for. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message