[OpenAFS] Request for Assistance with OpenAFS

Jeffrey Altman jaltman@auristor.com
Sun, 8 May 2016 22:49:29 -0400


This is a cryptographically signed message in MIME format.

--------------ms040100030701030405040401
Content-Type: multipart/mixed;
 boundary="------------5FC61DA7F3C3FD24EA7D502D"

This is a multi-part message in MIME format.
--------------5FC61DA7F3C3FD24EA7D502D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 5/4/2016 10:29 PM, Benjamin Kaduk wrote:
> On Wed, 16 Mar 2016, Nicolas Melot wrote:
>=20
>> Hi,
>>
>> I'm trying to setup and use openafs for mobile nodes, not always havin=
g a
>> connection to the openAFS server. I would like to use the openAFS cach=
ing
>> mechanism as an offline disk that synchronizes everything once online =
again.
>>
>> I installed an openAFS 1.6.9 server and client, together with a kerber=
os
>> server on debian jessie. Everything works great, including offline ope=
rations
>> and synch after the client is back online. However, I fail of open a a=
fs
>> session on the client machine while it is offline. To rule out a lack =
of
>> kerberos ticket, I installed a kerberos replica on the client machine =
and I
>> can get a ticket offline. However, even with a valid ticket, AFS's cac=
he
>> manager doesn't give access to the files.
>>
>> Investigating more and reading the doc, my understanding is that the c=
ache
>> manager doesn't look for anything to confirm the authorization granted=
 by the
>> kerberos ticket presented. However, I still fail to open an AFS sessio=
n with
>> an offline machine. I think this is because the cache manager requests=

>> information from the protection database (I guess some kind of ACLs) a=
nd since
>> it can't contact it, then it doesn't give access to files at all.
>=20
> This is not exactly true; in normal operation, it is the fileserver tha=
t
> consults the protection database and determines whether a user is
> authorized to access a given resource.

More to the point.   The cache manager doesn't have any access to the
Access Control List data.  All the cache manager has is the set of
permissions that were granted to a particular AFS token.  If that token
was associated with a particular local uid then the cache manager in the
absence of an AFS token or connectivity to a file server *might* be
configured to continue to offer access to the data by that particular
uid.  If the token was obtained with an arbitrary Process Authentication
Group and that PAG no longer exists, there is nothing for the cache
manager to use in deciding what permissions to grant.

>> In a desperate attempt to reach my goal, I started to set up at protec=
tion
>> database replication into the client and see what happens.. well, it l=
ooks
>> like I need to identify protection database server (including the repl=
ication
>> installed in my client machine) with ip addresses. The problem is that=
 both
>> databases (the original and replica) check if the ip address  of machi=
nes are
>> the same in both ends before allowing a replication to happen. That me=
ans I
>> can't configure the client so it connects to 127.0.0.1, which would be=
 the
>> only way t contact the local protection database when offline, so this=

>> solution doesn't seem to work either.
>=20
> I don't think that having a local protection database is a fruitful are=
a
> of research; the ubik database synchronization protocol is not really
> scalable, and is generally used with only 3 or 5 peers.  (There is also=
 a
> hard cap in the current implementation, which might be 16; I forget the=

> exact number.)

The protection database contains the memberships of groups and the
mapping of user names and group names to ID numbers that are stored in
the Access Control Entries.  The protection database doesn't store any
of the ACL data.  The ACL data is private metadata stored on the file
server and is not exposed to the cache manager.  Therefore, there is no
benefit to local copies of this data.

>> Then, finally my question (s): is it possible at all to have openafs w=
orking
>> in offline mode, including opening a session, even if I need to run a =
Kerberos
>> and a protection database replica on the client for it (even if that s=
ounds
>> like a bad idea). Is it possible to prevent the original and the repli=
ca
>> protection databases from checking if the ip addresses are the same, s=
o that I
>> can have the client machine to contact its local replica of the protec=
tion
>> database on 127.0.0.1 and the original protection database server to c=
ontact
>> the replica through its ip address on the network; better: through its=
 dns
>> name only.
>=20
> I think what you want would require further development on the offline
> mode, which in its current state remains an experimental feature but ha=
s
> not seen any significant resources invested in it for several years.
>=20
> I do not have an estimate for the amount of work that would be necessar=
y,
> but will say that I expect it to be measured in man-years.

There are two broad sets of problems that must be designed for before
disconnected mode can be truly functional:

1. What are the access control semantics of offline usage?

The Windows offline mode for CIFS provides a local disk per user cache
of the files and directories that are to be available offline.  As long
as the local copy is being used the user has full permissions on the
file regardless of what the network permissions were.  The network
permissions only matter when an attempt to sync changes back to the
network occurs.

The cloud file services (Dropbox, OneDrive, ...) also work on whole
files and do not worry about the network permissions except when storing
changes back to the network.

This model is inconsistent with the present day behavior of the AFS
cache manager which caches partial file ranges and assumes file system
semantics and not whole file copy & sync semantics.

2. User interface issues

There must be some mechanism for deciding when sets of files,
directories, directory trees, and/or whole volumes should be pinned to
the cache.  This mechanism will require some form of interaction with
the OS file browser/explorer.  There will also need to be some user
interface to decide what should be done when a merge conflict occurs.

I agree with the person-years estimate.

Jeffrey Altman


--------------5FC61DA7F3C3FD24EA7D502D
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------5FC61DA7F3C3FD24EA7D502D--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DEkwggYFMIIE7aADAgECAhAxSdDYnMC0s7K+ddH7ywANMA0GCSqGSIb3DQEBCwUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5
bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3
MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
NTAeFw0xNTExMDEwMDAwMDBaFw0xNjExMDEyMzU5NTlaMIGnMS4wLAYDVQQDDCVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQgLSAxNDQ2NDA0MDI1NjI1MSMwIQYJKoZIhvcNAQkBFhRqYWx0bWFu
QGF1cmlzdG9yLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmswggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC2cv6bENZULsb1FNyEBI47G2kA7Rogocg5u0qnQuDMCCNH
DnXkI62H2z/464AS8AGp4FcZIdvCPYp0POFlOl2XEiyA59FEDi+s3b33nLrnVOa4esw2NFBi
ZvwHvniUjgwWSUcS5V5+VhXeIKBL1U1NtMtB2XEVnc72RiQZB3KqzlS9GUvtSTdmCc6ULD/t
P009yCsBqY6NR/nug5NtUja2N+xUC2l8coYU1ingj/M4+fT8KcSq5t8laj0E+3X9ZPYlN9in
L364hXB1b+EHfxp0F0wZdsCapkEKV2VN16S1Ee5rccJIMaAJxrybK7NdI36Es/XqWlQzSeVN
wUYdwejrAgMBAAGjggIqMIICJjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAgBgNV
HSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFInhroYG7TrlBeOJmwRc
a0rfA3jtMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMGwGA1UdIARlMGMwYQYL
YIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMw
KAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwXQYDVR0fBFYwVDBS
oFCgToZMaHR0cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfNTdkZTdhMjM4ZDQ1ZDhkNGZj
NzFmOGE1YzZiODFjOTMvTGF0ZXN0Q1JMLmNybDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUH
MAKGMmh0dHA6Ly9jYWNlci5zeW1hdXRoLmNvbS9tcGtpL3N5bWNjMWluZHN1YmNhZzUuY3J0
MB8GA1UdIwQYMBaAFGcZtj2lebszYNgtU9OMCT0HrBhwMCsGCmCGSAGG+EUBEAMEHTAbBhJg
hkgBhvhFARABAgIEAa3ukhMWBTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hN
Nkx5OXdhMmt0Y21FdWMzbHRZWFYwYUM1amIyMD0wDQYJKoZIhvcNAQELBQADggEBAHhpoe3z
j0uxbWFz4Q7F2KyRJTgREbQ+imVv3ibbd2uvnckJ+vTNJuFoaORXKTt3B8TUT8rBTwXm35D5
K4DOrKMVS0iyR9PDobLpjQM8FcIGUdbGWeZZq/1zoWhi3RtFNzZaSKXjwiQUUWYTZUE7rUmj
qu7fiACksPAAdyG12FJtk1pdVByqmaFC75/z2Qs/jVjyySpy2SRg8wlpqM2h8tl9SGska/BT
gXLHJMhKrHQvBi+9Xo3MrmJA5Z3f5vcheoOAoM5/ScHBUXWDG0+NnEIb340By0adU823pF9c
K4gxI0ZJNID+eaT0XCqg47QFOZYZUlm3s4rDi1l1iPIHekwwggY8MIIFJKADAgECAhAHAqIa
hbhLZZ4YCm7m9aNlMA0GCSqGSIb3DQEBCwUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO
VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNV
BAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx
RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgLSBHMzAeFw0xNTEwMDEwMDAwMDBaFw0yNTA5MzAyMzU5NTlaMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5
bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3
MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
NTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANb7DTFJIsAMuu9OLRe4tDDlNNKs
Ce7JiQBd9K4TEbMTjlXPIhioIAam/SXLaJS0oIKQDm6WkkTuFbm07PrPeT1p1Jwf3CCaDijV
DbXGnjrx1GUZwIQzTY7aivHWJ7kDoNH6KJyCk2z3DYV9W+lOmWL+k0LS7j6zcVeGl0bL3w3h
xoRasw2P9fQQigVdn2hG7AiwWEKC9r4tEEamJAsn/pgUU4OTgtvqwD9PolhhtUtyaRJfM1n2
+bNMAGTOhcWGkgxuHOsoz3GpkKl0mXQk60jhDl1oEqgBZujumrIv+D3Nt3gkzqVgfOgWPUnx
B7ozvjIrwmejFsdvwNJalATCa0UCAwEAAaOCAj4wggI6MDcGCCsGAQUFBwEBBCswKTAnBggr
BgEFBQcwAYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMBIGA1UdEwEB/wQIMAYBAf8C
AQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3
LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t
L3JwYTAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vcy5zeW1jYi5jb20vcGNhMS1nMy5jcmww
DgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0y
LTIxNzAdBgNVHQ4EFgQUZxm2PaV5uzNg2C1T04wJPQesGHAwgfEGA1UdIwSB6TCB5qGB0KSB
zTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5j
LiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSF
CwDPrzhIzrGkMA0GCSqGSIb3DQEBCwUAA4IBAQBGGeQndTu+r+LaohRgjx5EkIFpK2NJNY3p
drqfmI8TgdfL/GUb+A5j3pQodPvjb9jJKnoOVKaDrilK9itR/T04ErvdY0X7ZMw+VIZ/TkJt
I7cdC/36zA2OkzXK5UX5zy9/eT1jGMdHI0r2qRQArX5ZVRqJJ9uUoJE4xv5AlaNg9l24yMUW
7ZxmaRRGEErKcCpv0VDgJhrTUrRHcotF0r0DuaXc2QjzkKt0cKvKoE7wwE7k4L5PkBFgJwwr
HN/nbMp1tCXnkUiqkrRRdV8pm0cXHL3J6s91rXUjz/LF31qrt2vKu7heq9WjcNRo8xd6mwug
FDz76IFWaOjPXXxzuC68MYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQK
ExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y
azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhAxSdDYnMC0s7K+ddH7ywAN
MA0GCWCGSAFlAwQCAQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xNjA1MDkwMjQ5MjlaMC8GCSqGSIb3DQEJBDEiBCBpn9aIYGAh0ZHu2MtqXosa
PlEFNcMqexYQtUPMvRKcPTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB
ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVT
MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1
c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhAxSdDYnMC0
s7K+ddH7ywANMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV
BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3
b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj
IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzUCEDFJ0NicwLSzsr510fvL
AA0wDQYJKoZIhvcNAQEBBQAEggEACzvaE7jSEx1/YBGIkRJSF+9wxlQiddTtMFk5wamntoHe
IXvDVMPcs6rpt2WUVVKzSxMsBfnZt1QvImbExL4+VyVHRabapFO6rp+yYwGccjDH3EzLgjGJ
dEUYwaw110D45ahja0NEjcDdj5bYGHznMUBYwK9/nu+FW3kvab3Fyt+5Kf0HuG23+dGdBglN
N1W/mwp8I8oBeNADW4lJlXtmctMqKjZHusMNewzaJ/+VZD6+OUoDxxQurkiSDRuyrt4Wm1zW
GdXBEFVGgFztsVj/l+2oTYGxdHXUzO9/NDjfToMWjkRlQvMZuBLMNBGP3WZpwYO8qms1gtA4
dGB4jX9qmwAAAAAAAA==
--------------ms040100030701030405040401--