On 1/29/2015 10:44 AM, Dave Botsch wrote: > Hi, Jeff. > > We can certainly move the pref pane portion over to openafs-info. > > See below... > > >> The OSX client has a couple of huge holes in it at the moment: >> >> 1. The packaging is no longer current for Xcode that supports >> Mavericks or Yosemite. >> > > Can you clarify what you mean? As far as I know, the only thing required > to build is an old packagebuilder script.
While it is possible to build an installer with the old packagebuilder
tool chain doing so comes with compromises. Notably;
1. it is not possible to sign the resulting package
2. it is not possible to do so using the standard development
toolchain as distributed by Apple which is a maintenance
issue for development teams.
>> 2. Parts of the pref pane functionality no longer work because
>> of changes in Mavericks and Yosemite.
>>
>
> The preference pane, to my knowledge, has never worked for cross realm
> authentication. So, that also needs to be fixed to call it "working".
Cross-realm acquisition of AFS tokens is not required for the majority
of end-users who are able to obtain AFS tokens from the realm in which
their client principal is issued.
The Windows AFSCreds tool and Network Identity Manager AFS token
provider both support cross-realm token acquisition because a
substantial amount of configuration logic was added to support that use
case. Doing so was personally important to me at the time.
The lack of cross-realm token acquisition functionality in AFSCommander
is likely to be due to the fact that Claudio had no need to implement it
for his organization and no one raised the subject back in 2009.
It would be great if someone added this functionality to OpenAFS. An
organization that requires it can either allocate developer staff time
or hire someone.
>> 3. There is no support for Bulk Status RPCs which cause the
>> OSX client (especially when used through Finder) to be
>> extremely slow when evaluating directories with large
>> numbers of entries over high latency links.
>>
>> This same lack of support for Bulk Status RPCs also triggers
>> the file server throttling of clients when many of the objects
>> in the directory are unreadable by the user.
>
> Interesting. What would you consider "large numbers" out of curiosity?
> Is there a plan to fix this?
How painful the issue is depends on the round trip time of the link, the
performance of the file server, and whether there are entries in the
directory that trigger throttling. With no throttling and no delays
within the file server a 100ms RTT and 50 entries would require 5
seconds to fetch the status info. If the RTT is increased to 250ms that
grows to 12.5 seconds. 100 entries becomes 25 seconds. If throttling
is triggered, it could take minutes. Of course the OpenAFS file servers
cannot process a call in 0ms and often experience significant contention
so these numbers are likely to be higher.
The reason that the OSX client does not implement BulkStat support is
because of limitations in OSX KPI. Daria and I spoke in person with
Apple's file system team 8 or 9 years ago. For Apple its a trade off of
file system stability from release to release or adding functionality
that most likely only OpenAFS would use. I understand and appreciate
why they would prefer stability in the KPI
There are potential workarounds but they involve significant complexity
and a redesign of the UNIX cache manager locking model. Substantial
development resources would be required. Scope of effort two to four
developer months of an engineer intimately familiar with both the UNIX
cache manager and the Darwin KPI.
>>
>> 4. There is no support for PAGs.
>>
>
> Always been that way. PAGs have their plusses and minuses (on our SunRay
> linux systems, I've actually disabled PAGs since certain processes get
> stuck in PAGs without authN).
The lack of PAGs prevents the use of OSX for certain use cases.
>> 5. Code signing for the installer, the userland binaries and
>> the kernel extension are necessary for improved firewall
>> access and installation behavior.
>
> Yeah, this sucks. It is workable aroundable pretty easily, but not
> something we want the end user to have to do.
Unless someone is extremely knowledgeable about what takes place behind
the scenes it is impossible for the user to do anything but throw their
hands up in the air in frustration. Even knowledgeable users often bang
their heads against their desk in frustration.
>> Of these, the easiest to address is fixing the Preference Pane.
>>
>
> Is there a plan in place to fix this? It'd be nice to have this fully
> working :)
Changes in the behavior of software are the result of one or more
developers writing code, hopefully adding documentation and test suites,
and then having that code be reviewed and accepted by the community.
Developers write code for one of two reasons:
1. They have a personal interest in implementing the functionality.
For example, an individual that uses OpenAFS on OSX and requires
cross-realm authentication to work in order to obtain tokens for
the cell they wish to access.
2. They are paid to do so. Either as a side effect of their day
job instructing them to perform the work or as a result of an
organization hiring them to do so.
There is a significant lack of developers that work on OpenAFS for
personal interest. The majority of the developers are employed by
commercial support and development organizations. To obtain their
services their employers must be hired either via a support contract or
on a work for hire development contract.
Is there a plan to fix this? No, there is a "wish". You (and perhaps
others) wish that this change in behavior would be implemented. A plan
requires resources to assign to the task of satisfying the wish. If you
have the necessary resources, you can make the wish come true.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
