[OpenAFS] Graphical file managers get stuck

[jukka.tuominen@finndesign.fi]

Hi Brandon and others,

I am by no means an administrator, rather a UX designer building a concept
design as easy as possible for the end users. So, I take it, it is
possible to build an afs client without static pointers to afs servers. I
hope this applies to the home cell as well, since the users' homedirs are
there.

A major part of this concept design is to make these awesome systems more
approachable and accessible to mortals like me. It's a shame, so few can
enjoy them. I try to contribute my 20c.

As mentioned earlier, due to the server's IP change, I had to manually
tweak the otherwise read-only client image. Sorry when I intentionally (to
prove my point) misinterpret your "learning ahead" as a "less usable"
system :) . I am definitely willing to learn more so that the users
wouldn't have to. Even more, I'd really appreciate more direct
instructions about the needed steps to achieve the goal (dynamic, yet
read-only client image). It would save time and ensure it is done right.

BTW, I only recently added (restored) the foreign cells to CellServDB, in
order to
1) ease interoperability within afs (the point of afs, I suppose)
2) to highlight how cool afs really is!

Keep up the good work, everybody!


br, jukka



> On Mon, Dec 10, 2012 at 5:12 PM, <jukka.tuominen@finndesign.fi> wrote:
>
>> What do you mean by publishing DNS SRV records? The server has a FQDN
>> but
>> do you mean something else?
>>
>
> Modern AFS autodiscovers the servers for a cell via DNS, much like other
> modern services.  See
>
> http://tools.ietf.org/html/draft-allbery-afs-srv-records-05
>
> for information about the AFS-specific parts of it.  (There are also TXT
> and SRV records for the Kerberos part; see the documentation for the
> Kerberos implementation you're using.)  This replaces the older AFSDB DNS
> records that were used for autodiscovery; service-specific DNS record
> types
> such as AFSDB have been deprecated in favor of the more general SRV
> mechanism (except for mail, which is far too entrenched at this point
> although I bet they'd love to make MX records go away too).
>
> If you don't understand this and are not the cell administrator, then
> forward this to the cell administrator.  If you *are* the cell
> administrator, well, you have some learning ahead of you.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b@gmail.com
> ballbery@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>