Date: Tue, 29 Aug 2006 09:02:19 -0500 From: Brooks Davis <brooks@one-eyed-alien.net> To: freebsd-net@freebsd.org, julian@elischer.org Subject: Re: possible patch for implementing split DNS Message-ID: <20060829140218.GA13054@lor.one-eyed-alien.net> In-Reply-To: <200608291202.k7TC2MnX012960@lurza.secnetix.de> References: <44EF6E18.6090905@elischer.org> <200608291202.k7TC2MnX012960@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 29, 2006 at 02:02:22PM +0200, Oliver Fromme wrote:
> Julian Elischer wrote:
> > I need some processes to look elsewhere for DNS information from where=
=20
> > the rest
> > of the system looks.. This patch seems to me a simple solution.
> > We over-ride where the resolver looks for resolv.conf using an=20
> > environment variable.
> > This would allow me to reset this to an application specific config fi=
le=20
> > that
> > specifies a different server.
>=20
> I think that could be useful indeed. In fact it could have
> been very helpful to me recently when I had to debug a very
> strange resolver problem (it turned out that the DSL modem
> dropped SOA and ANY requests).
>=20
> In theory, there would be a different (and maybe better)
> solution to the problem. On the "FreeBSD Ideas" web page
> there is an entry to port variant symlinks from DragonFly
> (but as far as I know, nobody is actually working on it).
> Using variant symlinks, the problem could easily be solved:
>=20
> $ ls -l /etc/resolv*
> -r--r--r-- 1 root wheel ... /etc/resolv.conf -> resolv-${RES}.conf
> -r--r--r-- 1 root wheel ... /etc/resolv-default.conf
> -r--r--r-- 1 root wheel ... /etc/resolv-special.conf
> $ varsym RES
> RES=3Ddefault
> $ cat /etc/resolv.conf
> nameserver 11.22.33.44
> $ varsym RES=3Dspecial
> $ cat /etc/resolv.conf
> nameserver 55.66.77.88
>=20
> It also has the advantage that the admin still has some
> control over it, because the symlink can only point to
> existing files under /etc in this case. By the way, the
> varsym variables can be set globally, per-user and per-
> process.
>=20
> However, I'm aware that variant symlinks are probably not
> going to be available in FreeBSD anytime soon. Therefore
> I think your patch to libc/net/res_init.c would be useful.
Actually there's a patch floating around. I don't remember what the
most recent status is, but it does work and I've got it in the branch I
run on my laptop. There's some diagreement about the order of
evaluation of the various tables with the patch implementing a pid
overrides user which overrides global and rwatson arguing for the
opposite (which is what AFS does). I think I'd like to see the AFS
version plus a "default" table since I find Robert's arguments
compelling, but have applications where a default is needed.
Alternativly ${varname-default_value} syntax could be implemented
alongside AFS semantics.
-- Brooks
P.S. The motivating application in my case is making /tmp a varsym which
points to storage with the ordinary semantics for ordinary processes,
but is overriden to point to a managed directory for processes within a
batch job under Sun Grid Engine.
--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFE9EjqXY6L6fI4GtQRAqR3AJ9r5YQwPsRoxBHRET7S3y3u+qKlAwCbBB9k
Liz5w8cMVbvhsh1ZJTdnNj4=
=s652
-----END PGP SIGNATURE-----
--rwEMma7ioTxnRzrJ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060829140218.GA13054>