$ df -k

Filesystem 1024-blocks Free = %Used Iused %Iused Mounted on

/dev/hd4 425984 &nb= sp;193972 55% 12152 21% /

/dev/hd2 3768320 &nb= sp; 84288 98% 58696 59% /usr

/dev/hd9var 655360 21= 8032 67% 6893 12% /var

/dev/hd3 163840 &nb= sp;134072 19% 239 1% /tmp

/dev/hd1 6291456 &nb= sp;706136 89% 1378 1% /home

/dev/hd11admin 131072 130692= 1% 5 1% /admin

/proc = - - - = - - /proc

/dev/hd10opt 3145728 1651220 = ; 48% 33565 9% /opt

/dev/livedump 262144 261776 = 1% 4 1% /var/adm/ras/= livedump

/dev/projectlv 31457280 29760568 &n= bsp;6% 47824 1% /project

/dev/cachelv 65536 4= 9008 26% 1583 2% /usr/vice/cache<= /div>

$ cat /opt/opena= fs/etc/openafs/cacheinfo

/afs:/usr/vice/cache:50000

I feel like I'm missing something simple...

Thank you.

-Ben

From: Jeffrey E Altman
Sent: Wednesday, May 3, 2023 9:38 AM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] More Kerberos + Windows issues

On 5/3/2023 11:45 AM, Ben Huntsman (ben@huntsmans.net) wrote:

Setting tokens. adUser @ mydomain.com

aklog: a pioctl failed whi= le setting tokens for cell mydomain.com

pioctl issue usually mean= s no cache manager is running

--_000_MWHPR0701MB36746D8625C6CB48C27D159AA76C9MWHPR0701MB3674_-- From richard@unixboxen.net Thu May 11 11:20:48 2023 From: richard@unixboxen.net (Richard Feltstykket) Date: Thu, 11 May 2023 10:20:48 +0000 Subject: [OpenAFS] OpenAFS access at login time on MacOS Message-ID: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> Hello Everyone, Perhaps it is widely known already, but I just wanted to share a process that I have worked out to get a kerberos ticket and an afs token at login time on MacOS. It seems to work fine for MacOS Ventura and Monterey; I have not tested on other versions. 1) copy a valid krb5.conf file for your realm to /etc/krb5.conf 2) install the Auristor client which is found here: https://www.auristor.com/openafs/client-installer/. 3) Make sure to allow the Auristor system extension in the security and privacy settings. This will require a reboot of the system. For all of the systems I have tried it on, you will see a message with something like "rebuilding the extension cache". 4) After the reboot make sure that you can successfully kinit and get a ticket, followed by aklog to get a token. 5) create a user (I always make it an admin) with the same name as your kerberos principal. 6) log into the machine and issue kinit --keychain principal_name . This stores your password in the keychain, after this, you will get your ticket on login time. 7) in the Auristor preferences, check the boxes: Use aklog Get credential at login time. 8) reboot the computer. Upon login I get prompted for my username and password twice usually. My cell takes FOREVER to log in for some reason, but after aklog completes in the background, I have a token and can access volumes in the cell. There is a program in the app store called 'kerberos ticket autorewnewal'. I have installed it but haven't confirmed its operation. Thanks, Richard From jaltman@auristor.com Sat May 13 16:44:11 2023 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sat, 13 May 2023 11:44:11 -0400 Subject: [OpenAFS] OpenAFS access at login time on MacOS In-Reply-To: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> References: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> Message-ID: This is a cryptographically signed message in MIME format. --------------ms090702020307050307090002 Content-Type: multipart/alternative; boundary="------------K8I4spbZqmiXGqggpSBn2Rrj" --------------K8I4spbZqmiXGqggpSBn2Rrj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote: > Hello Everyone, > > Perhaps it is widely known already, but I just wanted to share a > process that I have worked out to get a kerberos ticket and an afs > token at login time on MacOS. It seems to work fine for MacOS Ventura > and Monterey; I have not tested on other versions. Thanks for posting. > > My cell takes FOREVER to log in for some reason, but after aklog > completes in the background, I have a token and can access volumes in > the cell. Negative DNS lookups impose an unnecessary time delay. Assuming the name of your domain example.net is also the name of your cell and Kerberos realm (in upper case), and assuming the following hostnames for your kdc and afsdb servers kdc1.example.net afsdb1.example.net create the following DNS entries _kerberos.example.net. IN TXT "EXAMPLE.NET" _kerberos._afs.example.net. IN TXT "EXAMPLE.NET" _kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net. _kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net. _kerberos._http.example.net. IN SRV 0 0 0 . _kerberos._kkdcp.example.net. IN SRV 0 0 0 . _afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net. _afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net. If you are using the AFS backup service: _afs3-budbserver._udp.example.net. IN SRV 10 0 7021 afsdb1.example.net. If you are not using the AFS backup service: _afs3-budbserver._udp.example.net. IN SRV 0 0 0 . If there are more than one KDC or AFSDB server, then create one _kerberos* SRV record for each KDC and one _afs3-* entry for each AFSDB server. Note that the hostname specified in a SRV record must not be a CNAME; it must be A or AAAA records. For the _afs3-* SRV records for an OpenAFS cell which does not support IPv6 the specified hostname should not have a AAAA record. The AuriStorFS cache managers and Linux kernel afs (kafs) clients will attempt to contact the location servers via IPv6 if there is a AAAA record specified. A SRV record whose hostname is "." indicates that the service is unavailable. The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and rxkad_k5 tokens. An OpenAFS cell does not support yfs-rxgk but aklog doesn't know that until it is explicitly told by the Kerberos realm that there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET service principal. This requires that GSS-KRB5 be able to quickly resolve the Kerberos realm for the name "_afs.unixboxen.net". The SRV record specified above for _kerberos._afs.unixboxen.net is intended to speed up the resolution of the hostname to realm mapping if the client is configured to do so. For rxkad_k5 tokens the resolution of which Kerberos realm to use is performed by enumerating the hostnames of the location servers, performing an A/AAAA DNS query to obtain the IP addresses, then performing a PTR record lookup on the IP addresses. For example afsdb1.example.net A -> 192.0.2.23 129.0.2.23 PTR -> host.example.net _kerberos.host.example.net TXT -> "EXAMPLE.NET" _kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the _kerberos.host.example.net entry is not present) If there are more than one location service address, then the one that is used for resolution of the Kerberos realm can appear to be random because whichever is first in the list will be used. Issuing a "kinit user@EXAMPLE.NET" against your realm took a little more than six seconds to perform the DNS lookups for the kdc on a macOS Ventura 13.4 system. It then took approximately 180ms to receive the expected principal unknown response to the AS-REQ. I cannot measure the time to perform the aklog operations because I cannot obtain a TGT to test with. The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to "ls -l /afs/example.net" anonymously was * 470ms to resolve the location service via DNS (3 RPCs) * 330ms to resolve the location of the "root.cell" volume (2 RPCs + reachability test) * 850ms for the fileserver response to the first RPC including the fileserver->client callback service TellMeAboutYourself queries (3 RPCs + reachability tests) * 600ms to read the contents of the root directory and obtain status info for each entry (3 RPCs) The ICMP ping rtt from my test system to the location server averages 115ms. If the vlserver and fileserver connections were authenticated using rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX connection would be replaced by a CHALLENGE|RESPONSE exchange. If the cache manage to fileserver connection was authenticated using yfs-rxgk, then the fileserver TellMeAboutYourself query to the cache manager would not be performed. I suspect you can reduce some of the time by adding the DNS records that are not present in your domain. You can observe the DNS, Kerberos and AFS queries using wireshark https://www.wireshark.org/download.html. Start a capture and set a filter rule of "dns or rx or kerberos or icmp or icmpv6". Feel free to reply privately if you wish to discuss details of your actual network configuration. Jeffrey Altman --------------K8I4spbZqmiXGqggpSBn2Rrj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote:

Hello Everyone,

Perhaps it is widely known already, but I just wanted to share a process that I have worked out to get a kerberos ticket and an afs token at login time on MacOS. It seems to work fine for MacOS Ventura and Monterey; I have not tested on other versions.

Thanks for posting.

My cell takes FOREVER to log in for some reason, but after aklog completes in the background, I have a token and can access volumes in the cell.

Negative DNS lookups impose an unnecessary time delay.

Assuming the name of your domain example.net is also the name of your cell and Kerberos realm (in upper case), and assuming the following hostnames for your kdc and afsdb servers

kdc1.example.net

afsdb1.example.net

create the following DNS entries

_kerberos.example.net. IN TXT "EXAMPLE.NET"

_kerberos._afs.example.net. IN TXT "EXAMPLE.NET"

_kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.

_kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.

_kerberos._http.example.net. IN SRV 0 0 0 .

_kerberos._kkdcp.example.net. IN SRV 0 0 0 .

_afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net.

_afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net.

If you are using the AFS backup service:

_afs3-budbserver._udp.example.net. IN SRV 10 0 7021 afsdb1.example.net.

If you are not using the AFS backup service:

_afs3-budbserver._udp.example.net. IN SRV 0 0 0 .

If there are more than one KDC or AFSDB server, then create one _kerberos* SRV record for each KDC and one _afs3-* entry for each AFSDB server.

Note that the hostname specified in a SRV record must not be a CNAME; it must be A or AAAA records. For the _afs3-* SRV records for an OpenAFS cell which does not support IPv6 the specified hostname should not have a AAAA record. The AuriStorFS cache managers and Linux kernel afs (kafs) clients will attempt to contact the location servers via IPv6 if there is a AAAA record specified.

A SRV record whose hostname is "." indicates that the service is unavailable.

The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and rxkad_k5 tokens. An OpenAFS cell does not support yfs-rxgk but aklog doesn't know that until it is explicitly told by the Kerberos realm that there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET service principal. This requires that GSS-KRB5 be able to quickly resolve the Kerberos realm for the name "_afs.unixboxen.net". The SRV record specified above for _kerberos._afs.unixboxen.net is intended to speed up the resolution of the hostname to realm mapping if the client is configured to do so.

For rxkad_k5 tokens the resolution of which Kerberos realm to use is performed by enumerating the hostnames of the location servers, performing an A/AAAA DNS query to obtain the IP addresses, then performing a PTR record lookup on the IP addresses. For example

afsdb1.example.net A -> 192.0.2.23

129.0.2.23 PTR -> host.example.net

_kerberos.host.example.net TXT -> "EXAMPLE.NET"

_kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the _kerberos.host.example.net entry is not present)

If there are more than one location service address, then the one that is used for resolution of the Kerberos realm can appear to be random because whichever is first in the list will be used.

Issuing a "kinit user@EXAMPLE.NET" against your realm took a little more than six seconds to perform the DNS lookups for the kdc on a macOS Ventura 13.4 system. It then took approximately 180ms to receive the expected principal unknown response to the AS-REQ. I cannot measure the time to perform the aklog operations because I cannot obtain a TGT to test with.

The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to "ls -l /afs/example.net" anonymously was

470ms to resolve the location service via DNS (3 RPCs)
330ms to resolve the location of the "root.cell" volume (2 RPCs + reachability test)
850ms for the fileserver response to the first RPC including the fileserver->client callback service TellMeAboutYourself queries (3 RPCs + reachability tests)
600ms to read the contents of the root directory and obtain status info for each entry (3 RPCs)

The ICMP ping rtt from my test system to the location server averages 115ms.

If the vlserver and fileserver connections were authenticated using rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX connection would be replaced by a CHALLENGE|RESPONSE exchange. If the cache manage to fileserver connection was authenticated using yfs-rxgk, then the fileserver TellMeAboutYourself query to the cache manager would not be performed.

I suspect you can reduce some of the time by adding the DNS records that are not present in your domain. You can observe the DNS, Kerberos and AFS queries using wireshark https://www.wireshark.org/download.html. Start a capture and set a filter rule of "dns or rx or kerberos or icmp or icmpv6".

Feel free to reply privately if you wish to discuss details of your actual network configuration.

Jeffrey Altman

--------------K8I4spbZqmiXGqggpSBn2Rrj-- --------------ms090702020307050307090002 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 DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDUxMzE1 NDQxMVowLwYJKoZIhvcNAQkEMSIEIORYbRDygElCsrpzspsfKuJOVVuRbnx/UtXL9ghCoVb4 MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAXaSd CwEV8p+jeuA0rgSO2uB69mE9Y6VWZT7ZCQnRvA7srd2yIgMO48gi9r+gRBDUiaPpNZbl7Vav dWDTiUcz8084Gn06zNkS4nsT2I8/sstFjlWhQFjIRMYYEyAiBDlj0oluvvQA+rMUmS34sTip LGfhwxwvOkVlQ3dT/Kaeld4A4eEhlPvv5QX4pJHjd3ObQWjORGUUZxqj/jhPqKLzqzuf1Euo Qv5FQmvwoNq8QHaDjd0agnIOhTp88vzN2lE5DOiJixnEyNWVGG5fwwcOF3k3trJQkkl/ieO4 vBuhAhO7CjH+UF+PWlr8HJavybktlG3uM4lbkt9iwGunDKMMrQAAAAAAAA== --------------ms090702020307050307090002-- From jaltman@auristor.com Sat May 13 17:21:45 2023 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sat, 13 May 2023 12:21:45 -0400 Subject: [OpenAFS] OpenAFS access at login time on MacOS In-Reply-To: References: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> Message-ID: <487059b1-3501-9932-6649-be53a4a4bdf6@auristor.com> This is a cryptographically signed message in MIME format. --------------ms090400060802040604030109 Content-Type: multipart/alternative; boundary="------------1902mjX8mLpHkialJTFJlxse" --------------1902mjX8mLpHkialJTFJlxse Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/13/2023 11:44 AM, Jeffrey E Altman (jaltman@auristor.com) wrote: > On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote: >> Hello Everyone, >> >> Perhaps it is widely known already, but I just wanted to share a >> process that I have worked out to get a kerberos ticket and an afs >> token at login time on MacOS. It seems to work fine for MacOS >> Ventura and Monterey; I have not tested on other versions. > Thanks for posting. >> >> My cell takes FOREVER to log in for some reason, but after aklog >> completes in the background, I have a token and can access volumes in >> the cell. > > Negative DNS lookups impose an unnecessary time delay. > > Assuming the name of your domain example.net is also the name of your > cell and Kerberos realm (in upper case), and assuming the following > hostnames for your kdc and afsdb servers > > kdc1.example.net > > afsdb1.example.net > > create the following DNS entries > > _kerberos.example.net. IN TXT "EXAMPLE.NET" > > _kerberos._afs.example.net. IN TXT "EXAMPLE.NET" > > _kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net. > > _kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net. > > _kerberos._http.example.net. IN SRV 0 0 0 . > > _kerberos._kkdcp.example.net. IN SRV 0 0 0 . > > _afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net. > > _afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net. > > If you are using the AFS backup service: > > _afs3-budbserver._udp.example.net. IN SRV 10 0 7021 > afsdb1.example.net. > > If you are not using the AFS backup service: > > _afs3-budbserver._udp.example.net. IN SRV 0 0 0 . > > If there are more than one KDC or AFSDB server, then create one > _kerberos* SRV record for each KDC and one _afs3-* entry for each > AFSDB server. > > Note that the hostname specified in a SRV record must not be a CNAME; > it must be A or AAAA records. For the _afs3-* SRV records for an > OpenAFS cell which does not support IPv6 the specified hostname should > not have a AAAA record. The AuriStorFS cache managers and Linux > kernel afs (kafs) clients will attempt to contact the location servers > via IPv6 if there is a AAAA record specified. > > A SRV record whose hostname is "." indicates that the service is > unavailable. > > The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and > rxkad_k5 tokens. An OpenAFS cell does not support yfs-rxgk but aklog > doesn't know that until it is explicitly told by the Kerberos realm > that there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET service > principal. This requires that GSS-KRB5 be able to quickly resolve > the Kerberos realm for the name "_afs.unixboxen.net". The SRV record > specified above for _kerberos._afs.unixboxen.net is intended to speed > up the resolution of the hostname to realm mapping if the client is > configured to do so. > One thing I forgot to mention. The service principal for yfs-rxgk is yfs-rxgk/_afs.example.net@EXAMPLE.NET instead of afs/example.net@EXAMPLE.NET as is used for rxkad_k5. The reason that _afs.example.net is used is because of how GSS-API Kerberos v5 implementations resolve the Kerberos realm of a service where the second component is a hostname. GSS-API will fallback to using the DNS domain of the hostname as the realm if there is no other information available. However, many implementations including macOS and MIT will try to validate the second component as a valid DNS hostname as part of the lookup process. Therefore it issues a DNS A and AAAA query for "_afs.example.net" even though a DNS hostname is not permitted to begin with an underscore. In hindsight specifying the service principal in https://datatracker.ietf.org/doc/html/draft-wilkinson-afs3-rxgk-afs with an underscore based hostname was a poor idea. That said, DNS resolvers and most Kerberos libraries do not perform validation on the query string and most DNS servers will happily respond to the out of specification request if there is an entry present. I therefore suggest creating DNS A and AAAA records for _afs.example.net to avoid the negative lookup. The address doesn't matter since the DNS response will not be used to contact any host. Specifying one of the location servers is reasonable. > For rxkad_k5 tokens the resolution of which Kerberos realm to use is > performed by enumerating the hostnames of the location servers, > performing an A/AAAA DNS query to obtain the IP addresses, then > performing a PTR record lookup on the IP addresses. For example > > afsdb1.example.net A -> 192.0.2.23 > > 129.0.2.23 PTR -> host.example.net > > _kerberos.host.example.net TXT -> "EXAMPLE.NET" > > _kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the > _kerberos.host.example.net entry is not present) > > If there are more than one location service address, then the one that > is used for resolution of the Kerberos realm can appear to be random > because whichever is first in the list will be used. > > Issuing a "kinit user@EXAMPLE.NET" against your realm took a little > more than six seconds to perform the DNS lookups for the kdc on a > macOS Ventura 13.4 system. It then took approximately 180ms to > receive the expected principal unknown response to the AS-REQ. I > cannot measure the time to perform the aklog operations because I > cannot obtain a TGT to test with. > > The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to > "ls -l /afs/example.net" anonymously was > > * 470ms to resolve the location service via DNS (3 RPCs) > * 330ms to resolve the location of the "root.cell" volume (2 RPCs + > reachability test) > * 850ms for the fileserver response to the first RPC including the > fileserver->client callback service TellMeAboutYourself queries (3 > RPCs + reachability tests) > * 600ms to read the contents of the root directory and obtain status > info for each entry (3 RPCs) > > The ICMP ping rtt from my test system to the location server averages > 115ms. > > If the vlserver and fileserver connections were authenticated using > rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX > connection would be replaced by a CHALLENGE|RESPONSE exchange. If > the cache manage to fileserver connection was authenticated using > yfs-rxgk, then the fileserver TellMeAboutYourself query to the cache > manager would not be performed. > > I suspect you can reduce some of the time by adding the DNS records > that are not present in your domain. You can observe the DNS, > Kerberos and AFS queries using wireshark > https://www.wireshark.org/download.html. Start a capture and set a > filter rule of "dns or rx or kerberos or icmp or icmpv6". > > Feel free to reply privately if you wish to discuss details of your > actual network configuration. > > Jeffrey Altman > --------------1902mjX8mLpHkialJTFJlxse Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 5/13/2023 11:44 AM, Jeffrey E Altman (jaltman@auristor.com) wrote:

On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote:

Hello Everyone,

Perhaps it is widely known already, but I just wanted to share a process that I have worked out to get a kerberos ticket and an afs token at login time on MacOS. It seems to work fine for MacOS Ventura and Monterey; I have not tested on other versions.

Thanks for posting.

My cell takes FOREVER to log in for some reason, but after aklog completes in the background, I have a token and can access volumes in the cell.

Negative DNS lookups impose an unnecessary time delay.

Assuming the name of your domain example.net is also the name of your cell and Kerberos realm (in upper case), and assuming the following hostnames for your kdc and afsdb servers

kdc1.example.net

afsdb1.example.net

create the following DNS entries

_kerberos.example.net. IN TXT   "EXAMPLE.NET"

_kerberos._afs.example.net. IN TXT "EXAMPLE.NET"

_kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.

_kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.

_kerberos._http.example.net. IN SRV 0 0 0 .

_kerberos._kkdcp.example.net. IN SRV 0 0 0 .

_afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net.

_afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net.

If you are using the AFS backup service:

_afs3-budbserver._udp.example.net. IN SRV 10 0 7021 afsdb1.example.net.

If you are not using the AFS backup service:

_afs3-budbserver._udp.example.net. IN SRV 0 0 0 .

If there are more than one KDC or AFSDB server, then create one _kerberos* SRV record for each KDC and one _afs3-* entry for each AFSDB server.

Note that the hostname specified in a SRV record must not be a CNAME; it must be A or AAAA records.    For the _afs3-* SRV records for an OpenAFS cell which does not support IPv6 the specified hostname should not have a AAAA record.   The AuriStorFS cache managers and Linux kernel afs (kafs) clients will attempt to contact the location servers via IPv6 if there is a AAAA record specified.

A SRV record whose hostname is "." indicates that the service is unavailable.

The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and rxkad_k5 tokens.   An OpenAFS cell does not support yfs-rxgk but aklog doesn't know that until it is explicitly told by the Kerberos realm that there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET service principal.   This requires that GSS-KRB5 be able to quickly resolve the Kerberos realm for the name "_afs.unixboxen.net".   The SRV record specified above for _kerberos._afs.unixboxen.net is intended to speed up the resolution of the hostname to realm mapping if the client is configured to do so.

One thing I forgot to mention.

The service principal for yfs-rxgk is yfs-rxgk/_afs.example.net@EXAMPLE.NET instead of afs/example.net@EXAMPLE.NET as is used for rxkad_k5. The reason that _afs.example.net is used is because of how GSS-API Kerberos v5 implementations resolve the Kerberos realm of a service where the second component is a hostname. GSS-API will fallback to using the DNS domain of the hostname as the realm if there is no other information available. However, many implementations including macOS and MIT will try to validate the second component as a valid DNS hostname as part of the lookup process. Therefore it issues a DNS A and AAAA query for "_afs.example.net" even though a DNS hostname is not permitted to begin with an underscore. In hindsight specifying the service principal in https://datatracker.ietf.org/doc/html/draft-wilkinson-afs3-rxgk-afs with an underscore based hostname was a poor idea. That said, DNS resolvers and most Kerberos libraries do not perform validation on the query string and most DNS servers will happily respond to the out of specification request if there is an entry present. I therefore suggest creating DNS A and AAAA records for _afs.example.net to avoid the negative lookup. The address doesn't matter since the DNS response will not be used to contact any host. Specifying one of the location servers is reasonable.

For rxkad_k5 tokens the resolution of which Kerberos realm to use is performed by enumerating the hostnames of the location servers, performing an A/AAAA DNS query to obtain the IP addresses, then performing a PTR record lookup on the IP addresses. For example

afsdb1.example.net A -> 192.0.2.23

129.0.2.23 PTR -> host.example.net

_kerberos.host.example.net TXT -> "EXAMPLE.NET"

_kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the _kerberos.host.example.net entry is not present)

If there are more than one location service address, then the one that is used for resolution of the Kerberos realm can appear to be random because whichever is first in the list will be used.

Issuing a "kinit user@EXAMPLE.NET" against your realm took a little more than six seconds to perform the DNS lookups for the kdc on a macOS Ventura 13.4 system. It then took approximately 180ms to receive the expected principal unknown response to the AS-REQ.    I cannot measure the time to perform the aklog operations because I cannot obtain a TGT to test with.

The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to "ls -l /afs/example.net" anonymously was

470ms to resolve the location service via DNS (3 RPCs)

330ms to resolve the location of the "root.cell" volume (2 RPCs + reachability test)

850ms for the fileserver response to the first RPC including the fileserver->client callback service TellMeAboutYourself queries (3 RPCs + reachability tests)

600ms to read the contents of the root directory and obtain status info for each entry (3 RPCs)

The ICMP ping rtt from my test system to the location server averages 115ms.

If the vlserver and fileserver connections were authenticated using rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX connection would be replaced by a CHALLENGE|RESPONSE exchange.   If the cache manage to fileserver connection was authenticated using yfs-rxgk, then the fileserver TellMeAboutYourself query to the cache manager would not be performed.

I suspect you can reduce some of the time by adding the DNS records that are not present in your domain.   You can observe the DNS, Kerberos and AFS queries using wireshark https://www.wireshark.org/download.html.   Start a capture and set a filter rule of "dns or rx or kerberos or icmp or icmpv6".

Feel free to reply privately if you wish to discuss details of your actual network configuration.

Jeffrey Altman

--------------1902mjX8mLpHkialJTFJlxse-- --------------ms090400060802040604030109 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 DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDUxMzE2 MjE0NVowLwYJKoZIhvcNAQkEMSIEIMzHUfkCJsZM+TGBUOymWwRB0Jrf7JbRllP2Kiob6QBL MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVLyI W5F/X1Iei2sLrC/iv6Q1Kcj9LP/KBBbxMnBZZdQzAif/aJ0S/itwAExjyxjMROAZilsAJjcF ICq0zAjIkgPwxzYyita3q/s5WbcDnirjHVoq/S6OTlsEd3TnN1ZgGo6KBl3xNdgG3jehlWiL BdFtZxDNAk3cHs3WlBJRM3IFkz2Y6rWXSyVYjbwLjA7XJRNtKHLh2uOo4z9gG8elFlCBRXmX XzQNJwwykWSPV+GfSvjL9XsNjrEmo6LmGeNGCeUTYL2uQ+mX1RfWcFRPW4UUCUPphbhJ6rD3 JG1pHXjJNtOx8TVmW4phwfrd1c+koz6qT9DkaqfVkKzXCP1BcgAAAAAAAA== --------------ms090400060802040604030109-- From richard@unixboxen.net Sat May 13 18:32:45 2023 From: richard@unixboxen.net (Richard Feltstykket) Date: Sat, 13 May 2023 17:32:45 +0000 Subject: [OpenAFS] OpenAFS access at login time on MacOS In-Reply-To: <487059b1-3501-9932-6649-be53a4a4bdf6@auristor.com> References: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> <487059b1-3501-9932-6649-be53a4a4bdf6@auristor.com> Message-ID: <20230513173245.f3ux3ic223wjdpuu@tilt.unixboxen.net> On Sat, May 13, 2023 at 12:21:45PM -0400, Jeffrey E Altman wrote: >On 5/13/2023 11:44 AM, Jeffrey E Altman (jaltman@auristor.com) wrote: >>On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote: >>>Hello Everyone, >>> >>>Perhaps it is widely known already, but I just wanted to share a >>>process that I have worked out to get a kerberos ticket and an afs >>>token at login time on MacOS.� It seems to work fine for MacOS >>>Ventura and Monterey;� I have not tested on other versions. >>Thanks for posting. >>> >>>My cell takes FOREVER to log in for some reason, but after aklog >>>completes in the background, I have a token and can access volumes >>>in the cell. Awesome! Thank you for all of these great troubleshooting tips! This is a new cell with both Debian based systems running the OpenAFS server/client, as well as MacOS systems running the Auristor client. All systems (except for the sole administrative server on the zone) have the slow token acquisition issue, so the error is definitely in that list. >> >>Negative DNS lookups impose an unnecessary time delay. >> >>Assuming the name of your domain example.net is also the name of >>your cell and Kerberos realm (in upper case), and assuming the >>following hostnames for your kdc and afsdb servers >> >> kdc1.example.net >> >> afsdb1.example.net >> >>create the following DNS entries >> >> _kerberos.example.net.� IN TXT�� "EXAMPLE.NET" >> >> _kerberos._afs.example.net. IN TXT "EXAMPLE.NET" >> >> _kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net. >> >> _kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net. >> >> _kerberos._http.example.net. IN SRV 0� 0� 0 . >> >> _kerberos._kkdcp.example.net. IN SRV 0 0 0 . >> >> _afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net. >> >> _afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net. >> >>If you are using the AFS backup service: >> >> _afs3-budbserver._udp.example.net. IN SRV 10 0 7021 >> afsdb1.example.net. >> >>If you are not using the AFS backup service: >> >> _afs3-budbserver._udp.example.net. IN SRV 0 0 0 . >> >>If there are more than one KDC or AFSDB server, then create one >>_kerberos* SRV record for each KDC and one _afs3-* entry for each >>AFSDB server. >> >>Note that the hostname specified in a SRV record must not be a >>CNAME; it must be A or AAAA records.�� For the _afs3-* SRV records >>for an OpenAFS cell which does not support IPv6 the specified >>hostname should not have a AAAA record.�� The AuriStorFS cache >>managers and Linux kernel afs (kafs) clients will attempt to contact >>the location servers via IPv6 if there is a AAAA record specified. >> >>A SRV record whose hostname is "." indicates that the service is >>unavailable. >> >>The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens >>and rxkad_k5 tokens.�� An OpenAFS cell does not support yfs-rxgk but >>aklog doesn't know that until it is explicitly told by the Kerberos >>realm that there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET >>service principal.�� This requires that GSS-KRB5 be able to quickly >>resolve the Kerberos realm for the name "_afs.unixboxen.net".�� The >>SRV record specified above for _kerberos._afs.unixboxen.net is >>intended to speed up the resolution of the hostname to realm mapping >>if the client is configured to do so. >> >One thing I forgot to mention. > >The service principal for yfs-rxgk is >yfs-rxgk/_afs.example.net@EXAMPLE.NET instead of >afs/example.net@EXAMPLE.NET as is used for rxkad_k5.�� The reason that >_afs.example.net is used is because of how GSS-API Kerberos v5 >implementations resolve the Kerberos realm of a service where the >second component is a hostname.�� GSS-API will fallback to using the >DNS domain of the hostname as the realm if there is no other >information available.�� However, many implementations including macOS >and MIT will try to validate the second component as a valid DNS >hostname as part of the lookup process.�� Therefore it issues a DNS A >and AAAA query for "_afs.example.net" even though a DNS hostname is >not permitted to begin with an underscore.� In hindsight specifying >the service principal in >https://datatracker.ietf.org/doc/html/draft-wilkinson-afs3-rxgk-afs >with an underscore based hostname was a poor idea.�� That said, DNS >resolvers and most Kerberos libraries do not perform validation on the >query string and most DNS servers will happily respond to the out of >specification request if there is an entry present.� I therefore >suggest creating DNS A and AAAA records for _afs.example.net to avoid >the negative lookup.�� The address doesn't matter since the DNS >response will not be used to contact any host.�� Specifying one of the >location servers is reasonable. > >>For rxkad_k5 tokens the resolution of which Kerberos realm to use is >>performed by enumerating the hostnames of the location servers, >>performing an A/AAAA DNS query to obtain the IP addresses, then >>performing a PTR record lookup on the IP addresses.� For example >> >> afsdb1.example.net� A� ->� 192.0.2.23 >> >> 129.0.2.23 PTR -> host.example.net >> >> _kerberos.host.example.net TXT -> "EXAMPLE.NET" >> >> _kerberos.example.net TXT -> "EXAMPLE.NET"� (queried if the >> _kerberos.host.example.net entry is not present) >> >>If there are more than one location service address, then the one >>that is used for resolution of the Kerberos realm can appear to be >>random because whichever is first in the list will be used. >> >>Issuing a "kinit user@EXAMPLE.NET" against your realm took a little >>more than six seconds to perform the DNS lookups for the kdc on a >>macOS Ventura 13.4 system.� It then took approximately 180ms to >>receive the expected principal unknown response to the AS-REQ.�� I >>cannot measure the time to perform the aklog operations because I >>cannot obtain a TGT to test with. >> >>The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 >>to "ls -l /afs/example.net" anonymously was >> >> * 470ms to resolve the location service via DNS (3 RPCs) >> * 330ms to resolve the location of the "root.cell" volume� (2 RPCs + >> reachability test) >> * 850ms for the fileserver response to the first RPC including the >> fileserver->client callback service TellMeAboutYourself queries (3 >> RPCs + reachability tests) >> * 600ms to read the contents of the root directory and obtain status >> info for each entry (3 RPCs) >> >>The ICMP ping rtt from my test system to the location server >>averages 115ms. >> >>If the vlserver and fileserver connections were authenticated using >>rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each >>RX connection would be replaced by a CHALLENGE|RESPONSE exchange.�� >>If the cache manage to fileserver connection was authenticated using >>yfs-rxgk, then the fileserver TellMeAboutYourself query to the cache >>manager would not be performed. >> >>I suspect you can reduce some of the time by adding the DNS records >>that are not present in your domain.�� You can observe the DNS, >>Kerberos and AFS queries using wireshark >>https://www.wireshark.org/download.html. Start a capture and set a >>filter rule of "dns or rx or kerberos or icmp or icmpv6". >> >>Feel free to reply privately if you wish to discuss details of your >>actual network configuration. >> >>Jeffrey Altman >> Thanks, Richard From diogo.castro@cern.ch Mon May 15 23:48:13 2023 From: diogo.castro@cern.ch (Diogo Castro) Date: Mon, 15 May 2023 22:48:13 +0000 Subject: [OpenAFS] Client for latest kernel Message-ID: --_000_GV0P278MB033724E2B754A307E5B5922099789GV0P278MB0337CHEP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi everyone, I believe I haven=92t seen this being mentioned before in the mailing list,= I apologize if otherwise. We need to have a client built for Centos Stream 9, which is already runnin= g the kernel 5.14.0-307. In the past, to support CS, we cherry picked Gerrit 15199 on top of 1.8.9 and now we tried to do the same with G= errit 15417 but so far we didn=92t ma= nage to make it compile. Is there any other patch we=92re missing? Or any build flag? (Any plans to release a new version with this support? The minutes from the= latest meeting doesn=92t mention it.) Thank you for your help! Diogo --_000_GV0P278MB033724E2B754A307E5B5922099789GV0P278MB0337CHEP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi everyone,<= /p>

I believe I haven=92t seen this= being mentioned before in the mailing list, I apologize if otherwise.=

We need to have a client built = for Centos Stream 9, which is already running the kernel 5.14.0-307.

In the past, to support CS, we = cherry picked Gerrit 15199 on top of= 1.8.9 and now we tried to do the same with Gerrit 15417 but so fa= r we didn=92t manage to make it compile.

Is there any other patch we=92r= e missing? Or any build flag?

(Any plans to release a new ver= sion with this support? The minutes from the latest meeting doesn=92t menti= on it.)

Thank you for your help!

Diogo

--_000_GV0P278MB033724E2B754A307E5B5922099789GV0P278MB0337CHEP_-- From kaduk@mit.edu Tue May 16 00:43:40 2023 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 15 May 2023 16:43:40 -0700 Subject: [OpenAFS] Client for latest kernel In-Reply-To: References: Message-ID: On Mon, May 15, 2023 at 10:48:13PM +0000, Diogo Castro wrote: > Hi everyone, > > I believe I haven’t seen this being mentioned before in the mailing list, I apologize if otherwise. > We need to have a client built for Centos Stream 9, which is already running the kernel 5.14.0-307. > In the past, to support CS, we cherry picked Gerrit 15199 on top of 1.8.9 and now we tried to do the same with Gerrit 15417 but so far we didn’t manage to make it compile. > Is there any other patch we’re missing? Or any build flag? > > (Any plans to release a new version with this support? The minutes from the latest meeting doesn’t mention it.) Yes, we're pretty close to putting out a 1.8.10pre1; the relevant linux-support commits are already in the openafs-stable-1_8_x git branch. -Ben From cwseys@physics.wisc.edu Tue May 16 16:22:31 2023 From: cwseys@physics.wisc.edu (Chad W Seys) Date: Tue, 16 May 2023 15:22:31 +0000 Subject: [OpenAFS] writeable /afs bind mount inside a podman container Message-ID: Hi all,=0A= I'm using podman to run a container with a non-root user ("rootless") and= trying to bind mount /afs into the container such that it is writeable.=0A= The user already has tokens, so in principle processes in container can w= rite to the bind mounted /afs inside the container. Instead inside the con= tainer /afs appears to be writeable, but any attempts to write result in "P= ermission denied".=0A= In fact, using apptainer to create a container from the same image and bi= nd mounting /afs into the container does result in a writeable /afs, so I k= now it's possible! (I've thought of switching to apptainer instead of podm= an, but it has other problems.)=0A= =0A= If anyone has gotten this to work let me know!=0A= C.= From spacefrogg-openafs@spacefrogg.net Tue May 16 19:54:15 2023 From: spacefrogg-openafs@spacefrogg.net (spacefrogg-openafs@spacefrogg.net) Date: Tue, 16 May 2023 20:54:15 +0200 (GMT+02:00) Subject: [OpenAFS] writeable /afs bind mount inside a podman container In-Reply-To: References: Message-ID: I can only speculate, because I don't use podman. With unprivileged LXC con= tainers, it works for me under the condition that the user's token does not= use a PAG but is bound to the user id only. So, my speculation would be that apptainer is able to run inside an establi= shed PAG and podman is not. =E2=80=93Michael From nemesis@icequake.net Tue May 16 22:43:07 2023 From: nemesis@icequake.net (Ryan C. Underwood) Date: Tue, 16 May 2023 16:43:07 -0500 Subject: [OpenAFS] Perl AFS module updated for 1.8.x Message-ID: --2mlUULIRm1p7ZWIZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi openafs-info, Norbert hasn't been heard from for a long time and I had a server that needed upgrading, so I hacked up the Perl AFS distribution to get dependent code going again. My site's code mainly uses the VLDB and VOS modules so the rest of the stuff is mostly only compile-tested. https://github.com/runderwo/AFS I don't expect this fork to work anywhere except with OpenAFS 1.8.x libraries on Linux. If there's any interest in reviving it to get more modules working and/or improve portability, backwards compatibility, etc, feel free to send your pull requests. (Disclaimer: for greenfield Perl code it's better to use the CLI wrappers at https://github.com/openafs-contrib/afs-command) --=20 Ryan C. Underwood, --2mlUULIRm1p7ZWIZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSqqegowG2kcGXAAAMiiceeH7ruOQUCZGP46QAKCRAiiceeH7ru OW9cAKCRwxErERgYKT5uWE+ENeOtkV6OzACcDRqxCwm2WAcn01G9dJ15HBgq2Co= =2Soi -----END PGP SIGNATURE----- --2mlUULIRm1p7ZWIZ-- From cwseys@physics.wisc.edu Wed May 17 17:24:44 2023 From: cwseys@physics.wisc.edu (Chad W Seys) Date: Wed, 17 May 2023 16:24:44 +0000 Subject: [OpenAFS] Re: writeable /afs bind mount inside a podman container In-Reply-To: <20230517160100.43B638D@grand.central.org> References: <20230517160100.43B638D@grand.central.org> Message-ID: Hi Michael,=0A= =0A= > I can only speculate, because I don't use podman. With unprivileged LXC c= on=0A= > tainers, it works for me under the condition that the user's token does n= ot=3D=0A= > use a PAG but is bound to the user id only.=0A= =0A= That sounds likely.=0A= =0A= > So, my speculation would be that apptainer is able to run inside an estab= li=3D=0A= > shed PAG and podman is not.=0A= =0A= Do you know of a way to bind the token to the user id instead of PAG? Alte= rnatively, podman might be doing something to leave the PAG of the parent t= hat can be disabled. (Probably for security purposes.)=0A= =0A= Thanks for those ideas!=0A= C.= From sur5r@sur5r.net Wed May 17 21:40:54 2023 From: sur5r@sur5r.net (Jakob Haufe) Date: Wed, 17 May 2023 22:40:54 +0200 Subject: [OpenAFS] Perl AFS module updated for 1.8.x In-Reply-To: References: Message-ID: <20230517224054.76ea9ac8@tizio.sur5r.net> --Sig_/TPMeGp.pOu=ZMokwIBWrRy4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 16 May 2023 16:43:07 -0500 "Ryan C. Underwood" wrote: > https://github.com/runderwo/AFS >=20 > I don't expect this fork to work anywhere except with OpenAFS 1.8.x > libraries on Linux. If there's any interest in reviving it to get > more modules working and/or improve portability, backwards > compatibility, etc, feel free to send your pull requests. >=20 > (Disclaimer: for greenfield Perl code it's better to use the CLI > wrappers at https://github.com/openafs-contrib/afs-command) Wouldn't it nonetheless make sense to have a clone of this somewhere under openafs-contrib for easier discoverability? --=20 ceterum censeo microsoftem esse delendam. --Sig_/TPMeGp.pOu=ZMokwIBWrRy4 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEe/X2rDZDH11A3BN6TPKyGPVNrj0FAmRlO9YACgkQTPKyGPVN rj0qeBAAwCxOgUar4/zMI2XGbu8IaAIh9U+xJ2ObY/4PYlfbpO7zY2ceytdHstdp 9mBiJk+SF1JxX2JHa2Unzf3PTQfAr4xmhIs+VVCyWn35v16GxzKfGMe8Fui5ohZn 9zcG2FPMcfxi0uNPqutP4G2W6HQ/4pQ6PTGIRRO3zseNvS1MzTMFEIgm7UeXerFu 1b5rxFUakvlpH1MRdVE8rA5H/D4q+FS9zAx2u0/ve7flF5LxWGI4KYdj2xeepjzA AtO+TrRcXedd2kXN8bihhkgviiZTmJgiYsmdOUOjv74TFvfXLprH8qWfRZ9ajkwY aJSpLcQSxCvPqaSPVOpbVBETpLHwtJq1B0i0xq5sEiWFGTOWaIte0W6fd5viSjVn hQA5x94eFiH8uCugU1O9xu4qgehS0gJK9LdKFh2J3mm4MAgZHQ5hGbBkz3z2tJCR ce9fgCbKODps70H1VjyQKDwn1LJ+zVvb4K94O/bw5TI4ajbGWg7vtamXYpyMojgR usjYHbrVPUixxn4Z2QFQgCpBdDA6EWuGIMtCL81ujwVI2Y23TRsXZ2pFxmQRJYCM oBRoLN515NBrJmBhaRrzO0h1cUX9Foz1aWpyd8K/wAS27wZzKnUAEu+cHVfelMOz X2m1JmXieDS3vux8AqB67/7SwwbW24FzLn3tS3SnMa4LVicSEdE= =4M0n -----END PGP SIGNATURE----- --Sig_/TPMeGp.pOu=ZMokwIBWrRy4-- From Richard.Brittain@dartmouth.edu Mon May 22 19:24:01 2023 From: Richard.Brittain@dartmouth.edu (Richard Brittain) Date: Mon, 22 May 2023 18:24:01 +0000 Subject: [OpenAFS] OpenAFS access at login time on MacOS In-Reply-To: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> References: <20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net> Message-ID: --_000_BL1PR03MB61989116E34C52E59588BD4F9E439BL1PR03MB6198namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: openafs-info-admin@openafs.org on be= half of Richard Feltstykket Date: Thursday, May 11, 2023 at 6:22 AM To: openafs-info@openafs.org Subject: [OpenAFS] OpenAFS access at login time on MacOS =85 There is a program in the app store called 'kerberos ticket autorewnewal'. = I have installed it but haven't confirmed its operation. =85 I got excited when you posted that. That utility appears to only acquire new tickets using a stored password, a= nd not actually perform a renewal in the sense of =91kinit -R=92, even when= the ticket is renewable. I=92ve tried (and failed) to make Russ Allbery= =92s krenew, function on MacOS, but have cobbled together a simple launchag= ent to periodically run krenew and aklog. It mostly does the trick _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info --_000_BL1PR03MB61989116E34C52E59588BD4F9E439BL1PR03MB6198namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

From: openafs-info-admin@= openafs.org <openafs-info-admin@openafs.org> on behalf of Richard Fel= tstykket <richard@unixboxen.net>
Date: Thursday, May 11, 2023 at 6:22 AM
To: openafs-info@openafs.org <openafs-info@openafs.org>
Subject: [OpenAFS] OpenAFS access at login time on MacOS<= /span>

=85

There is a program = in the app store called 'kerberos ticket autorewnewal'. I have instal= led it but haven't confirmed its operation.

=85

I got excited when = you posted that.

That utility appear= s to only acquire new tickets using a stored password, and not actually per= form a renewal in the sense of =91kinit -R=92, even when the ticket is rene= wable. I=92ve tried (and failed) to make Russ Allbery=92s krenew, function on MacOS, but have cobbled together a si= mple launchagent to periodically run krenew and aklog. It mostly does= the trick

___________________= ____________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https:/= /lists.openafs.org/mailman/listinfo/openafs-info

--_000_BL1PR03MB61989116E34C52E59588BD4F9E439BL1PR03MB6198namp_-- From Tracy.DiMarcoWhite@gs.com Wed May 24 15:09:31 2023 From: Tracy.DiMarcoWhite@gs.com (Di Marco White, Tracy J) Date: Wed, 24 May 2023 14:09:31 +0000 Subject: [OpenAFS] 2023 AFS Technologies Workshop - virtual Message-ID: Hi all, I'd like to invite anyone interested in AFS to consider registering for the= 2023 AFS Technologies Workshop on June 12th, 13th, & 14th. The workshop is= again this year being hosted on Zoom, and registration is open at https://= events.zoom.us/e/view/vqOro4A_RfGeHNSVWD4Yvw with the list of talks and tim= ings listed there as well. I will work to also have the schedule on the wor= kshop website as soon as I can. The main talks will run from 9:30am until 3= pm Eastern time, with themed community discussion or social time for an hou= r before the start each day, and an hour after the talks end each day.. If you have any questions, please let us know. Tracy Di Marco White On behalf of the 2023 Workshop organizers ________________________________ Your Personal Data: We may collect and process information about you that m= ay be subject to data protection laws. For more information about how we us= e and disclose your personal data, how we protect your information, our leg= al basis to use your information, your rights and who you can contact, plea= se refer to: www.gs.com/privacy-notices