[OpenAFS] Re: AFSDB record changes and pre-existing clients
Steve Simmons
scs@umich.edu
Mon, 22 Jul 2019 10:43:27 -0400
--000000000000f697ae058e461958
Content-Type: text/plain; charset="UTF-8"
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 <jaltman@auristor.com>
wrote:
> I'm moving this discussion to openafs-info@openafs.org 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
>
--000000000000f697ae058e461958
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Many thanks, Jeff, Stephen, and spacefrogg. It's cl=
ear 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 wou=
ld need various degrees of handholding. So we'll fall back to our origi=
nal plan, which is to migrate the entire subnet that contains the afsdb ser=
vers to the new data center.=C2=A0</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif">Thanks,</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><b=
r></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"g=
mail_signature"><div dir=3D"ltr"><div>Steve Simmons<br>ITS Unix Support/SCS=
Admins<br></div></div></div></div><br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 19, 2019 at 11:52 PM Jef=
frey E Altman <<a href=3D"mailto:jaltman@auristor.com">jaltman@auristor.=
com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">I'm moving this discussion to <a href=3D"mailto:openafs-info@openafs=
.org" target=3D"_blank">openafs-info@openafs.org</a> because its<br>
subject isn't about new or on-going development of OpenAFS.<br>
<br>
OpenAFS 1.6 and later clients support both DNS AFSDB and SRV records.<br>
AFSDB records have been deprecated by the IETF and are often unsupported<br=
>
by SOHO routers that implement DNS proxies. DNS SRV records are widely<br>
supported and should be used. There is no harm in publishing both types<br>
but the clients will search for SRV records first.<br>
<br>
OpenAFS clients will obtain the DNS response TTL and will use it to<br>
expire the list of cell vlservers provided that the list was obtained<br>
from DNS.=C2=A0 If the list is obtained from a CellServDB or from use of &q=
uot;fs<br>
newcell" the cell's vlserver list will never expire.<br>
<br>
Note that for OpenAFS the contents of the client's CellServDB file take=
s<br>
precedence over DNS.=C2=A0 As long as there is a <a href=3D"http://umich.ed=
u" rel=3D"noreferrer" target=3D"_blank">umich.edu</a> entry in the<br>
CellServDB the DNS records will be ignored.<br>
<br>
OpenAFS currently ships with the following obtained from <a href=3D"http://=
grand.central.org" rel=3D"noreferrer" target=3D"_blank">grand.central.org</=
a>:<br>
<br>
=C2=A0 ><a href=3D"http://umich.edu" rel=3D"noreferrer" target=3D"_blank=
">umich.edu</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 #University=
of Michigan - Campus<br>
=C2=A0 141.211.1.32=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 #<a href=3D"http://fear.ifs.umich.edu" rel=3D"noreferrer" tar=
get=3D"_blank">fear.ifs.umich.edu</a><br>
=C2=A0 141.211.1.33=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 #<a href=3D"http://surprise.ifs.umich.edu" rel=3D"noreferrer"=
target=3D"_blank">surprise.ifs.umich.edu</a><br>
=C2=A0 141.211.1.34=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 #<a href=3D"http://ruthless.ifs.umich.edu" rel=3D"noreferrer"=
target=3D"_blank">ruthless.ifs.umich.edu</a><br>
<br>
A further note.=C2=A0 The OpenAFS Unix cache managers use the IP addresses =
as<br>
specified in the CellServDB file.=C2=A0 They ignore the hostnames which for=
<br>
OpenAFS were only ever used by the Windows client.<br>
<br>
The AuriStorFS client behavior is quite different. The cell vlserver<br>
configuration that ships for <a href=3D"http://umich.edu" rel=3D"noreferrer=
" target=3D"_blank">umich.edu</a> is secondary to DNS.=C2=A0 It is only<br>
used when DNS SRV and DNS AFSDB queries fail.=C2=A0 AuriStor decided that w=
e<br>
never wanted to ship configuration information that would restrict a<br>
cell's administrator from re-deploying the cell's infrastructure wh=
en<br>
necessary.<br>
<br>
Good luck.<br>
<br>
Jeffrey Altman<br>
<br>
On 7/19/2019 9:39 AM, Steve Simmons wrote:<br>
> We're working a project to migrate our afsdb servers to a new data=
<br>
> center in a manner that minimizes downtime for clients. As part of thi=
s,<br>
> we're going to convert all the clients we control to use afsdb rec=
ords<br>
> in hopes of eliminating downtime completely. There are some edge<br>
> conditions we didn't immediately see an answer for,=C2=A0 mostly r=
elating to<br>
> what a client does when the DNS AFSDB records change. We're lookin=
g at<br>
> this w/r/t 1.6 and 1.8 clients. The questions we have -<br>
> <br>
> - does the client time out=C2=A0 the records in accordance with the TT=
Ls and=C2=A0<br>
> re-fetch them?<br>
> - whether it does or not, is there=C2=A0 a way to force the client to =
refetch<br>
> without having to restart the client service or the entire client?<br>
> <br>
> Advance=C2=A0 thanks,<br>
> <br>
> Steve Simmons<br>
> ITS Unix Support/SCS Admins<br>
</blockquote></div>
--000000000000f697ae058e461958--