Many thanks, Jeff, Stephen, and spacefrogg. It's clear that AFSDB records aren't going to buy us anything, and in any case, I'm certain that there are a bunch of 1.4 clients out there which would need various degrees of handholding. So we'll fall back to our original plan, which is to migrate the entire subnet that contains the afsdb servers to the new data center.
Thanks, Steve Simmons ITS Unix Support/SCS Admins On Fri, Jul 19, 2019 at 11:52 PM Jeffrey E Altman <[email protected]> wrote: > I'm moving this discussion to [email protected] because its > subject isn't about new or on-going development of OpenAFS. > > OpenAFS 1.6 and later clients support both DNS AFSDB and SRV records. > AFSDB records have been deprecated by the IETF and are often unsupported > by SOHO routers that implement DNS proxies. DNS SRV records are widely > supported and should be used. There is no harm in publishing both types > but the clients will search for SRV records first. > > OpenAFS clients will obtain the DNS response TTL and will use it to > expire the list of cell vlservers provided that the list was obtained > from DNS. If the list is obtained from a CellServDB or from use of "fs > newcell" the cell's vlserver list will never expire. > > Note that for OpenAFS the contents of the client's CellServDB file takes > precedence over DNS. As long as there is a umich.edu entry in the > CellServDB the DNS records will be ignored. > > OpenAFS currently ships with the following obtained from grand.central.org > : > > >umich.edu #University of Michigan - Campus > 141.211.1.32 #fear.ifs.umich.edu > 141.211.1.33 #surprise.ifs.umich.edu > 141.211.1.34 #ruthless.ifs.umich.edu > > A further note. The OpenAFS Unix cache managers use the IP addresses as > specified in the CellServDB file. They ignore the hostnames which for > OpenAFS were only ever used by the Windows client. > > The AuriStorFS client behavior is quite different. The cell vlserver > configuration that ships for umich.edu is secondary to DNS. It is only > used when DNS SRV and DNS AFSDB queries fail. AuriStor decided that we > never wanted to ship configuration information that would restrict a > cell's administrator from re-deploying the cell's infrastructure when > necessary. > > Good luck. > > Jeffrey Altman > > On 7/19/2019 9:39 AM, Steve Simmons wrote: > > We're working a project to migrate our afsdb servers to a new data > > center in a manner that minimizes downtime for clients. As part of this, > > we're going to convert all the clients we control to use afsdb records > > in hopes of eliminating downtime completely. There are some edge > > conditions we didn't immediately see an answer for, mostly relating to > > what a client does when the DNS AFSDB records change. We're looking at > > this w/r/t 1.6 and 1.8 clients. The questions we have - > > > > - does the client time out the records in accordance with the TTLs and > > re-fetch them? > > - whether it does or not, is there a way to force the client to refetch > > without having to restart the client service or the entire client? > > > > Advance thanks, > > > > Steve Simmons > > ITS Unix Support/SCS Admins >
