Date: Tue, 20 Feb 2001 01:22:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@earth.backplane.com (Matt Dillon) Cc: bright@wintelcom.net (Alfred Perlstein), tlambert@primenet.com (Terry Lambert), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <200102200122.SAA04466@usr05.primenet.com> In-Reply-To: <200102191829.f1JIT6l37371@earth.backplane.com> from "Matt Dillon" at Feb 19, 2001 10:29:06 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> :> cached state data is inherently bad everywhere, not just in DNS > :> servers. > : > :You scare me, I was thinking just the same thing about mountd > :earlier today. Only problem is that it violates POLA(* heh), one > :could offer an command line option to have it watch the file. > > I was thinking just having a 'mountd -reload'. I don't like the > idea of programs polling configuration files. I actually used a > similar mechanism in Diablo and wound up having to add hacks to, > for example, try to avoid catching a configuration file in the middle > of being written out by an editor. > > A better way would be to take the 'vipw' concept and write a general > system utility to edit configuration files that does the right thing > when you write the config file out (heh heh... based on.... another > config file!). You could close the file in between polls, and reopen it O_EXCL; or your vipw suggestion would also work, using a two stage commit to ensure that it was all or nothing for changes. Really, the program wants to sit on the file as part of its select loop, and when the file is closed so that it's the sole opener again, get an "exceptional condition" flagged in the select. Barring that, the next best thing is a signal, and the next best after that is a poll. The problem that needs to be addressed is the cached state which is no longer valid, but which has been cached on the basis of having read the configuration file. Sendmail has areas where there are similar problems on configuration changes (for example, it caches the name that it believes it is on startup, so if you change the host name in the DNS, it claims to be the old name, until it is restarted; similarly, it must be HUP'ed for a number of configuration file changes. Some of these can be worked around by using text files instead of databases, some can't). The inetd problem isn't isolated, it's just pretty glaring; the mountd one is too, but it's really hard to deal with, since there are ugly hooks for the FS exporting down in the VFS code, and managed per FS in the per FS mount code. This is really broken in BSD; SunOS, a long time ago, fixed this with the "exportfs" utility, and communicated the data to the kernel NFS server directly. In an ideal system, you would change the host name one place (for an example of commonly cached information), and everything would "just know" and "just do the right thing". Having an external program watching the configuration file changes is really a very poor approach, since it doesn't address the underlying problem very well. Windows tried to handle this for the most part by putting their registry interface into their kernel (the registry, the cache, and the dynamic portion of the registry tree are all wrapped up in a VXD). Unfortunately, they ended up doing a vast thing in a half-vast way (8-)), and still kept config.sys, autoexec.bat, and a bunch of .INI files, at the same time. A registry-like configuration store, which was cached by the OS, and was referenced directly each time the data was needed, instead of allowing the programs to cache data which might change would really be the best approach, but I rather think that it would be rejected because Microsoft had the idea. Heh. A new way to screw over your competitors: make them so hateful that they refuse to learn from your good ideas, and have to come up with something gratuitously different (and probably more complicated) just to be able to say that they aren't like you... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102200122.SAA04466>