AFSDB lookups w/ djb's dnscache

[Love]

Nickolai Zeldovich <kolya at mit.edu> writes:

> Sorry for the long delay; the new AFSDB code in the CVS version
> of arlad seems to work fine with djb's dnscache.

Good.

> Probably unrelated to dnscache, it does complain about not being
> able to write to the CellServDB when I access a cell that's not
> in CellServDB but has an AFSDB record:
> 
>   2000-11-26 16:46:35: arlad: Cannot open CellServDB for writing
> 
> (in this case, the machine is homed in a cell not in CellServDB,
> and arlad writes that cell to /usr/arla/etc/CellServDB, but trying
> to access another AFSDB-configured cell gives the above error.)

This is since we chroot() to the cache directory to avoid deadlocks that
otherwise will occur on some situations.

Typically what happens is that many processes do lookup at the same time
and then the whole chain of directories will be locked up to the root. At
this point some error happens (what else) and we do a strerror(), but since
there are l10n, libc will try to open the "C" locale error message file,
but since the root is locked...

We have talked about keeping a fd to the CellServD file or a fhandle (for
getfh/fhopen). But neither of them is a good solution, we have choose not
to solve the problem yet.

Really AFSDB only solves two of the problems with CellServDB, namly that a
cell can change their AFS-databaseservers willout telling the whole world.

The other problem, how to find the cells is much harder till solve. We have
seen proposals like automount-like resolving, having a CellServDB with just
the cells (the > line), or reverse the tree
(/afs/se/kth/stacken/home/...). This last solution make most sense but is
very incompatible with the current solution.

Love