[OpenAFS] 1.4.1-rc2 build question

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

--------------ms070804020609060806000509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Terry McCoy wrote:
> On Thu, 1 Dec 2005, Neulinger, Nathan wrote:
> 
>> Would it be worth considering having byte range lock support in the
>> code, but enabled with a flag or option of some sort so that code could
>> be staged in without fully implementing it?
>>
>> i.e. similar to fs setcrypt?
>>
> 
> That would be a suitable.

But to what extent is it beneficial?   Here is the current situation.
The 1.4.0 and previous clients attempt to obtain a full file lock and
fail and then ignore the error.  Or they obtain the lock but do not
attempt to ensure that it continues to be held and if it is lost, they
make no attempt to prevent further file access.

The end result is that user's of applications such as Microsoft Office
which make extensive use of byte range locks as a form of signaling
not to mention to ensure data integrity lose.   Users don't realize
there is a problem until they close the data file and attempt to re-open
it again.  By that point in time it is too late.

Therefore, your users are already in a situation in which they cannot
safely use AFS as a place for active editing of documents in public
shared spaces.   By implementing Byte Range Locking and you failing
to add 'k' to the ACLs for the shared spaces, the users are not losing
functionality but are being prevented from doing something dangerous.

At some point in time we are going to have to make the difficult 
transition to the use of byte range locks.  In the past, the Windows
AFS client was not stable enough to do long term work.  Now it is and
it needs to be safe enough to use as well.   It must provide the same
level of functionality that a user would get from a Windows File Share.

Now is the time to make the transition before there is wide spread
deployment of 1.4.0.  Once there is a widely used stable OpenAFS client
on Windows it is going to be much harder to get your organization to
upgrade let alone any others.

At what point in time will it become easier?

If I provide a way to turn it off, how will you ensure that it gets
turned back on in the future?

The benefits of locking will only be ensured when all of the users
accessing a file are using clients that enforce the locks.  The longer
we wait, the longer and harder it will be to make the transition.

>> I don't know if the impact described below is legitimate or not, but
>> having it in the code but optional is at least a more gradual step-in to
>> the support.
>>
>> Does the new byte range support change it from:
>>
>> 	Ignore request, pretend it was granted, don't do any lock
>> to
>> 	Grant request based on client side decision, with read or write
>> lock on server
>>
>> In that case, a lot more read locks would suddenly be getting obtained
>> by those clients on the server than were getting obtained previously.
>> Not that this should be a problem, but it might expose other locking
>> issues elsewhere that would cause hesitancy in adoption of 1.4.1 as a
>> whole if the feature were forcibly on.
>>
> 
> good point

There is very little overhead on the servers for keeping track of locks.
The servers make no effort at the current time to keep track of who has
locks.   Read locks on a file are simply a counter of granted locks that
have not been returned.  The write lock is maintained as a single value
of -1.  The lock values are maintained as long as one request to renew
the lock is received within five minutes of the last grant or renewal
from any client.  (Including a client that did not ask for a lock in the
first place.)

>> I'm not referring so much to the locks on the client that wants byte
>> range locks, but on the person who doesn't care, and suddenly can't get
>> a lock on the file at all because someone else has a lock on it. (Not
>> that this is a good thing, but it's a noticable change in behavior.)
>>
>> -- Nathan
>>
> 
> I think you also need to consider the interaction within the file system
> between pre 1.4.1 Windows clients (no locking) and 1.4.1 Windows
> clients (with locking).

The use of old clients vs new clients will exactly the same as if you
were to access a file with two different applications that used 
different locking semantics.  For example, you can edit a Word document
file with Word or Wordpad.  Wordpad does not use locks whereas Word 
does.  If you open first with Wordpad, Word can open the file afterwards
and there are no complaints.  If you open with Word first, Wordpad will
be prevented from opening it.

There is going to be a transition period.   The question is whether it
happens now or at some point in the very near future.

Please keep in mind that read-only volumes do not use locking at all.
Any data you are publishing via read-only volumes such as applications
will be unaffected.  Also, any home directories that you have given to
end users more than likely already have the 'k' privilege and if they
do not, the user's can add it since they most likely have 'a' on their
own volumes.

The place where there will be a transition is simply the set of volumes
in which there is shared use and where people have already granted 
partial permissions.   A user that wants to access a Word document in
a friend's volume for which they have 'rl' can still do so.   They just
won't be able to do so using an application that insists on locking it
unless they first copy it to a local disk or to somewhere that they can
obtain a lock.

I am very well aware that the education process is not going to be
limited to any one organization.   I am going to have to come up with a
method of educating the user when the software is installed.  That will
probably involve the creation of a run-once per user application that
provides the user with a lesson on AFS ACLs.

Jeffrey Altman




--------------ms070804020609060806000509
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC
AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3
WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k
cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/
bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM
S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm
RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX
wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD
6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs
dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L
IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G
y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB
BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w
NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE
KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI
hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa
bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE
APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q
IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj
qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25
XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK
i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt
9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/
MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD
VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv
bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5
WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk
LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2
vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9
A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw
EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R
BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ
Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN
d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG
A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEyMDIwNTAwNTlaMCMGCSqG
SIb3DQEJBDEWBBQsT+8EFuTt7AvSodEXCVViHQV2HjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC
AQB8IqODr0WQ8DNBC1Rk+80QM0Am2i7y7UPSEDS5FDQIpYvIerUsvwn68k5x3ulS0xcrMQ89
gSIJRnda6L7kGnclM0j7yo/yanhsssduXl72YOQZGs4eIclqBpXeP9g+2fUVlYkVvkAfogm9
vFJra4MP46fGmDVd2UPiN9BMtGrK0PrvTuA7sd0sp7uHHbIW7rwSxl9yx4H3EnMeYybxNYwb
RMpx+cLsVl6ZPqsEHw6AB6hoks3XrSVNXAr2C65ecPDSGlP6ya2jghbCptsEgfBDFFF47IWW
NIEfEtsX/v82UBt3FaaAg2ah72bG47NHkURA/hj4ICoBAD8XzAywWFpLAAAAAAAA
--------------ms070804020609060806000509--