Has anyone built this on AIX recently? I see in the code that there i= s support for AIX 6.1, and 7.2. I was hoping to get it working on 7.1= so I figured I'd start with a build on AIX 6.1 to make sure it was in work= ing order before attempting to port it to 7.1. I'm using XLC 13.1.3 and my AIX level is 6100-09-12-1846.<= /div>

I checked out the code from git and am using the master branch. I am = using the following config options:

CC=3Dxlc_r ./configure --prefix=3D/opt/openafs --enable-tivoli-tsm --enable= -kauth --disable-fuse-client --with-gssapi=3D/opt/freeware --with-krb5=3D/o= pt/freeware

Are those appropriate/reasonable under AIX? Currently, I'm getting th= e following error:

cc -I. -I.. -I../nfs -I/project/op= enafs/src/crypto/hcrypto/kernel -I/project/openafs/src -I/proje= ct/openafs/src/afs -I/project/openafs/src/afs/AIX -I/project/op= enafs/src/config -I/project/openafs/src/rx/AIX -I/project/opena= fs/src/external/heimdal -I/project/openafs/src -I/project/openafs/src/afs -I/pro= ject/openafs/src/afs/AIX -I/project/openafs/src/config -I/proje= ct/openafs/src/fsint -I/project/openafs/src/vlserver -I/project= /openafs/src/auth -I/project/openafs/include -I/project/openafs= /include/afs -I. -I.. -I/project/openafs/src/config -U_IBMR2 -D_POWER -D_A= IX -DNLS -D_NLS -DMSG -D__STR31__ -Daiws -D_POWER_RS -D_POWER_PC -D_P= OWER_RS1 -D_POWER_RS2 -D_POWER_RSC -D_POWER_601 -D_POWER_603 -D_POWER= _604 -D_THREADS -M -D_KERNEL -D_POWER_MP -UKOFF -DAFSDEBUG -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -H8 -DAFS -DAFS_COMMON = -D_VOPS -D_SUN -DKERNEL -q64 -DAFS_64BIT_KERNEL -D__64BIT_KERNEL -g -I/proj= ect/openafs/src/rxkad -I/project/openafs/src/rxkad -o rxkad_common.o -c /pr= oject/openafs/src/rxkad/rxkad_common.c

"/project/openafs/src/afs/AIX/osi_machdep.h", line 90.12: 15= 06-007 (S) "struct timestruc_t" is undefined.

"../sys/time.h", line 587.17: 1506-343 (S) Redeclaration of = curtime differs from previous declaration on line 91 of "/project/open= afs/src/afs/AIX/osi_machdep.h".

"../sys/time.h", line 587.17: 1506-050 (I) Return type "= ;void" in redeclaration is not compatible with the previous return typ= e "int".

make: 1254-004 The error code from the last command is 1.

Has anyone seen this? Certainly that struct is defined in /usr/i= nclude/sys/time.h, but this seems like it's probably something obvious and = I'm willing to bet it's on my end and not a problem with the code.

Thank you so much for any suggestions!

-Ben

--_000_MWHPR0701MB367453B12D887A131C55A6DBA7679MWHPR0701MB3674_-- From ben@huntsmans.net Fri Aug 12 17:50:54 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Fri, 12 Aug 2022 16:50:54 +0000 Subject: [OpenAFS] OpenAFS vs IBM AFS Message-ID: --_000_MWHPR0701MB36742051C6F9A41653E985ACA7679MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- So I know IBM released the AFS code to the community at the beginning an= d that is what became OpenAFS. But from various release notes on the IBM s= ite, it would seem that IBM continued (and continues) to develop its own AF= S internally as well. Does anyone know how far the IBM vs OpenAFS code bases have diverged? I= know they at least have more AIX ports than the OpenAFS code currently doe= s... Does anyone know anyone at IBM that could be asked if IBM would be willi= ng to re-contribute it's current codebase? Thanks in advance! -Ben --_000_MWHPR0701MB36742051C6F9A41653E985ACA7679MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

So I know IBM released the AFS code to the community at the be= ginning and that is what became OpenAFS. But from various release not= es on the IBM site, it would seem that IBM continued (and continues) to dev= elop its own AFS internally as well.

Does anyone know how far the IBM vs OpenAFS code bases have di= verged? I know they at least have more AIX ports than the OpenAFS cod= e currently does...

Does anyone know anyone at IBM that could be asked if IBM woul= d be willing to re-contribute it's current codebase?

Thanks in advance!

-Ben

--_000_MWHPR0701MB36742051C6F9A41653E985ACA7679MWHPR0701MB3674_-- From kaduk@mit.edu Fri Aug 12 17:55:32 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Fri, 12 Aug 2022 09:55:32 -0700 Subject: [OpenAFS] Building on AIX In-Reply-To: References: Message-ID: <20220812165532.GI24514@kduck.mit.edu> Hi Ben, On Fri, Aug 12, 2022 at 04:41:04PM +0000, Ben Huntsman wrote: > Hi guys! >=20 > Has anyone built this on AIX recently? I see in the code that there is s= upport for AIX 6.1, and 7.2. I was hoping to get it working on 7.1 so I fi= gured I'd start with a build on AIX 6.1 to make sure it was in working orde= r before attempting to port it to 7.1. I'm using XLC 13.1.3 and my AIX lev= el is 6100-09-12-1846. It looks like we lost our regular AIX buildbot worker in early 2017, so any builds since then have been ad hoc/infrequent. That said, I think we're happy to help work through any issues that have arisen since then and get things back into a usable state on AIX. > I checked out the code from git and am using the master branch. I am usi= ng the following config options: >=20 > CC=3Dxlc_r ./configure --prefix=3D/opt/openafs --enable-tivoli-tsm --enab= le-kauth --disable-fuse-client --with-gssapi=3D/opt/freeware --with-krb5=3D= /opt/freeware [obligatory note that kauth is woefully insecure and should only be used if you have compatibility requirements with legacy systems that cannot be upgraded] > Are those appropriate/reasonable under AIX? Currently, I'm getting the f= ollowing error: >=20 > cc -I. -I.. -I../nfs -I/project/openafs/src/crypto/hcrypto/ker= nel -I/project/openafs/src -I/project/openafs/src/afs -I/project/openafs= /src/afs/AIX -I/project/openafs/src/config -I/project/openafs/src/rx/AIX = -I/project/openafs/src/external/heimdal -I/project/openafs/src -I/projec= t/openafs/src/afs -I/project/openafs/src/afs/AIX -I/project/openafs/src/c= onfig -I/project/openafs/src/fsint -I/project/openafs/src/vlserver -I/pr= oject/openafs/src/auth -I/project/openafs/include -I/project/openafs/incl= ude/afs -I. -I.. -I/project/openafs/src/config -U_IBMR2 -D_POWER -D_AIX = -DNLS -D_NLS -DMSG -D__STR31__ -Daiws -D_POWER_RS -D_POWER_PC -D_POWER_RS1= -D_POWER_RS2 -D_POWER_RSC -D_POWER_601 -D_POWER_603 -D_POWER_604 -D_THREA= DS -M -D_KERNEL -D_POWER_MP -UKOFF -DAFSDEBUG -DVICE -DNFS -DUFS -DINET -= DQUOTA -DGETMOUNT -H8 -DAFS -DAFS_COMMON -D_VOPS -D_SUN -DKERNEL -q64 -DAF= S_64BIT_KERNEL -D__64BIT_KERNEL -g -I/project/openafs/src/rxkad -I/project/= openafs/src/rxkad -o rxkad_common.o -c /project/openafs/src/rxkad/rxkad_com= mon.c > "/project/openafs/src/afs/AIX/osi_machdep.h", line 90.12: 1506-007 (S) "s= truct timestruc_t" is undefined. > "../sys/time.h", line 587.17: 1506-343 (S) Redeclaration of curtime diffe= rs from previous declaration on line 91 of "/project/openafs/src/afs/AIX/os= i_machdep.h". > "../sys/time.h", line 587.17: 1506-050 (I) Return type "void" in redeclar= ation is not compatible with the previous return type "int". > make: 1254-004 The error code from the last command is 1. >=20 >=20 > Has anyone seen this? Certainly that struct is defined in /usr/include/s= ys/time.h, but this seems like it's probably something obvious and I'm will= ing to bet it's on my end and not a problem with the code. That looks like some fallout from https://gerrit.openafs.org/#/c/14238/ and given the lack of any remark about testing on AIX in the review notes, I'm more inclined to think it's an issue with the OpenAFS code than your setup. What does curtime() look like on your system? We just need a way to get the current time in seconds+microseconds precision (converting from, e.g., nanoseconds if needed). We may have just typo'd something in the src/afs/AIX/osi_machdep.h chunk, for all I know. Thanks, Ben P.S. If you think you might be able to contribute some resources to have a regular AIX buildbot worker again, we'd be delighted to talk about that! From jaltman@auristor.com Fri Aug 12 18:32:35 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Fri, 12 Aug 2022 13:32:35 -0400 Subject: [OpenAFS] OpenAFS vs IBM AFS In-Reply-To: References: Message-ID: This is a cryptographically signed message in MIME format. --------------ms070108000902020209020102 Content-Type: multipart/alternative; boundary="------------KjHZ81doSjQCrBnYa49hb009" --------------KjHZ81doSjQCrBnYa49hb009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/12/2022 12:50 PM, Ben Huntsman (ben@huntsmans.net) wrote: > Hi guys- > > So I know IBM released the AFS code to the community at the > beginning and that is what became OpenAFS. But from various release > notes on the IBM site, it would seem that IBM continued (and > continues) to develop its own AFS internally as well. > > Does anyone know how far the IBM vs OpenAFS code bases have > diverged? I know they at least have more AIX ports than the OpenAFS > code currently does... IBM released OpenAFS 1.0 on 31 Oct 2000. That release was a fork from IBM AFS 3.6. The fork itself at this point was substantial. IBM had to clean the code base before it could be released. The diff stat between these releases was not inconsequential. IBM has continued development of IBM AFS 3.6. There has been no effort to synchronize with OpenAFS. They are very much independent creatures at this point. Since the openafs-ibm-1_0 release OpenAFS has undergone substantial change 6127 files changed, 1308387 insertions(+), 567306 deletions(-) > > Does anyone know anyone at IBM that could be asked if IBM would be > willing to re-contribute it's current codebase? > Yes we know people and they know us. It wouldn't be worth asking. There is simply too much churn to merge code changes. At best, concepts and features added to IBM AFS 3.6pXXX could be re-implemented in OpenAFS. Jeffrey Altman --------------KjHZ81doSjQCrBnYa49hb009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/12/2022 12:50 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Hi guys-

So I know IBM released the AFS code to the community at the beginning and that is what became OpenAFS. But from various release notes on the IBM site, it would seem that IBM continued (and continues) to develop its own AFS internally as well.

Does anyone know how far the IBM vs OpenAFS code bases have diverged? I know they at least have more AIX ports than the OpenAFS code currently does...

IBM released OpenAFS 1.0 on 31 Oct 2000. That release was a fork from IBM AFS 3.6. The fork itself at this point was substantial. IBM had to clean the code base before it could be released. The diff stat between these releases was not inconsequential.

IBM has continued development of IBM AFS 3.6. There has been no effort to synchronize with OpenAFS. They are very much independent creatures at this point. Since the openafs-ibm-1_0 release OpenAFS has undergone substantial change

6127 files changed, 1308387 insertions(+), 567306 deletions(-)

Does anyone know anyone at IBM that could be asked if IBM would be willing to re-contribute it's current codebase?

Yes we know people and they know us. It wouldn't be worth asking. There is simply too much churn to merge code changes.

At best, concepts and features added to IBM AFS 3.6pXXX could be re-implemented in OpenAFS.

Jeffrey Altman

--------------KjHZ81doSjQCrBnYa49hb009-- --------------ms070108000902020209020102 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxMjE3 MzIzNVowLwYJKoZIhvcNAQkEMSIEIDCLB3YyWkVNgsg+75tCK0wsmtIBWpCGpQkbEMHUSvTY MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAEVtY 52g1cJwX4biO1Jct8CrZSg8biK/Mt9kUexV4Xu+fPSIZ2gphrAwW4PDFU8sXz3O1ubIB5Ogl X9F+tInjnOCVcgMo/keKbknXR9g6IU2bODOUND143h17YugCry0nH5zqgZPuHPBq50e7YOVv UDTQZHG/L75yOiG3UgsCxENtC5OalGtH2RqagkIRWgQ5ckP3duC5EMN6LoucwtHUFjPsIoyD U9FVEqKA5ZEDlOv63jUjmfOc8TFWaqEklIvDdvqAdtqXN8QZeptn132tsQL0Rqh4k1WpPXO0 TqIhnaay99DJtGevCn0dunnX0cjD1KrnknkFOAsoqvjSWUhFLgAAAAAAAA== --------------ms070108000902020209020102-- From ben@huntsmans.net Fri Aug 12 19:01:54 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Fri, 12 Aug 2022 18:01:54 +0000 Subject: [OpenAFS] OpenAFS vs IBM AFS Message-ID: --_000_MWHPR0701MB3674EA70EADDD74EB2A315DAA7679MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeffrey- Thanks for the reply! That is about what I thought. I guess I ask because for those of us who= work more with AIX than the other platforms, it would be interesting and v= aluable to be able to track the IBM code base as well, even if that were ke= pt in a separate repository from OpenAFS. I'm also very interested in what it took to clean the code base to achie= ve the 1.0 release. I know some things were removed such as that washtool = thing, and the special version of AIX's fsck that is AFS-aware. But that w= as a long time ago. I wonder if times have changed and if there would be f= ewer legal and technical hurdles to releasing some of those things? The AI= X AFS-aware fsck would be worthwhile even now. Anyway, thanks again! -Ben ________________________________ From: Jeffrey E Altman Sent: Friday, August 12, 2022 10:32 AM To: Ben Huntsman; openafs-info@openafs.org Subject: Re: [OpenAFS] OpenAFS vs IBM AFS On 8/12/2022 12:50 PM, Ben Huntsman (ben@huntsmans.net) wrote: Hi guys- So I know IBM released the AFS code to the community at the beginning an= d that is what became OpenAFS. But from various release notes on the IBM s= ite, it would seem that IBM continued (and continues) to develop its own AF= S internally as well. Does anyone know how far the IBM vs OpenAFS code bases have diverged? I= know they at least have more AIX ports than the OpenAFS code currently doe= s... IBM released OpenAFS 1.0 on 31 Oct 2000. That release was a fork from IBM= AFS 3.6. The fork itself at this point was substantial. IBM had to clean= the code base before it could be released. The diff stat between these r= eleases was not inconsequential. IBM has continued development of IBM AFS 3.6. There has been no effort to = synchronize with OpenAFS. They are very much independent creatures at this= point. Since the openafs-ibm-1_0 release OpenAFS has undergone substantia= l change 6127 files changed, 1308387 insertions(+), 567306 deletions(-) Does anyone know anyone at IBM that could be asked if IBM would be willi= ng to re-contribute it's current codebase? Yes we know people and they know us. It wouldn't be worth asking. There= is simply too much churn to merge code changes. At best, concepts and features added to IBM AFS 3.6pXXX could be re-impleme= nted in OpenAFS. Jeffrey Altman --_000_MWHPR0701MB3674EA70EADDD74EB2A315DAA7679MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jeffrey-

Thanks for the reply!

That is about what I thought. I guess I ask because for = those of us who work more with AIX than the other platforms, it would be in= teresting and valuable to be able to track the IBM code base as well, even = if that were kept in a separate repository from OpenAFS.

I'm also very interested in what it took to clean the code bas= e to achieve the 1.0 release. I know some things were removed such as= that washtool thing, and the special version of AIX's fsck that is AFS-awa= re. But that was a long time ago. I wonder if times have changed and if there would be fewer legal and technical hurdles= to releasing some of those things? The AIX AFS-aware fsck would be w= orthwhile even now.

Anyway, thanks again!

-Ben

From: Jeffrey E Altman
Sent: Friday, August 12, 2022 10:32 AM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] OpenAFS vs IBM AFS

On 8/12/2022 12:50 PM, Ben Huntsman (ben@hun= tsmans.net) wrote:

Hi guys-

So I know IBM released the AFS code to the community at the be= ginning and that is what became OpenAFS. But from various release not= es on the IBM site, it would seem that IBM continued (and continues) to dev= elop its own AFS internally as well.

Does anyone know how far the IBM vs OpenAFS code bases have di= verged? I know they at least have more AIX ports than the OpenAFS cod= e currently does...

IBM released OpenAFS 1.0 = on 31 Oct 2000. That release was a fork from IBM AFS 3.6. = The fork itself at this point was substantial. IBM had to clean the = code base before it could be released. The diff stat between these releases was not inconsequential.

IBM has continued develop= ment of IBM AFS 3.6. There has been no effort to synchronize with Ope= nAFS. They are very much independent creatures at this point. S= ince the openafs-ibm-1_0 release OpenAFS has undergone substantial change

6127 files changed= , 1308387 insertions(+), 567306 deletions(-)

Does anyone know anyone at IBM that could be asked if IBM woul= d be willing to re-contribute it's current codebase?

Yes we know people and th= ey know us. It wouldn't be worth asking. There is s= imply too much churn to merge code changes.

At best, concepts and fea= tures added to IBM AFS 3.6pXXX could be re-implemented in OpenAFS.

Jeffrey Altman

--_000_MWHPR0701MB3674EA70EADDD74EB2A315DAA7679MWHPR0701MB3674_-- From ben@huntsmans.net Fri Aug 12 19:12:00 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Fri, 12 Aug 2022 18:12:00 +0000 Subject: [OpenAFS] Building on AIX In-Reply-To: <20220812165532.GI24514@kduck.mit.edu> References: <20220812165532.GI24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674B3FC0FA5B9C3F7E676E7A7679MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ah, interesting! Thank you for pointing that out! Just to test a sloppy fix, I added an include of to src/afs/AI= X/osi_machdep.h, and that allowed the compile to continue. It stops at src= /afs/AIX/osi_sleep.c, but I'll treat that as a separate thread. I'm not sure if including from src/afs/AIX/osi_machdep.h is th= e best way to resolve it, but if so maybe that should be put in a patch? P= erhaps it should go in src/afs/sysincudes.h? Thank you! -Ben ________________________________ From: Benjamin Kaduk Sent: Friday, August 12, 2022 9:55 AM To: Ben Huntsman Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Building on AIX Hi Ben, On Fri, Aug 12, 2022 at 04:41:04PM +0000, Ben Huntsman wrote: > Hi guys! > > Has anyone built this on AIX recently? I see in the code that there is s= upport for AIX 6.1, and 7.2. I was hoping to get it working on 7.1 so I fi= gured I'd start with a build on AIX 6.1 to make sure it was in working orde= r before attempting to port it to 7.1. I'm using XLC 13.1.3 and my AIX lev= el is 6100-09-12-1846. It looks like we lost our regular AIX buildbot worker in early 2017, so any builds since then have been ad hoc/infrequent. That said, I think we're happy to help work through any issues that have arisen since then and get things back into a usable state on AIX. > I checked out the code from git and am using the master branch. I am usi= ng the following config options: > > CC=3Dxlc_r ./configure --prefix=3D/opt/openafs --enable-tivoli-tsm --enab= le-kauth --disable-fuse-client --with-gssapi=3D/opt/freeware --with-krb5=3D= /opt/freeware [obligatory note that kauth is woefully insecure and should only be used if you have compatibility requirements with legacy systems that cannot be upgraded] > Are those appropriate/reasonable under AIX? Currently, I'm getting the f= ollowing error: > > cc -I. -I.. -I../nfs -I/project/openafs/src/crypto/hcrypto/ker= nel -I/project/openafs/src -I/project/openafs/src/afs -I/project/openafs= /src/afs/AIX -I/project/openafs/src/config -I/project/openafs/src/rx/AIX = -I/project/openafs/src/external/heimdal -I/project/openafs/src -I/projec= t/openafs/src/afs -I/project/openafs/src/afs/AIX -I/project/openafs/src/c= onfig -I/project/openafs/src/fsint -I/project/openafs/src/vlserver -I/pr= oject/openafs/src/auth -I/project/openafs/include -I/project/openafs/incl= ude/afs -I. -I.. -I/project/openafs/src/config -U_IBMR2 -D_POWER -D_AIX = -DNLS -D_NLS -DMSG -D__STR31__ -Daiws -D_POWER_RS -D_POWER_PC -D_POWER_RS1= -D_POWER_RS2 -D_POWER_RSC -D_POWER_601 -D_POWER_603 -D_POWER_604 -D_THREA= DS -M -D_KERNEL -D_POWER_MP -UKOFF -DAFSDEBUG -DVICE -DNFS -DUFS -DINET -= DQUOTA -DGETMOUNT -H8 -DAFS -DAFS_COMMON -D_VOPS -D_SUN -DKERNEL -q64 -DAF= S_64BIT_KERNEL -D__64BIT_KERNEL -g -I/project/openafs/src/rxkad -I/project/= openafs/src/rxkad -o rxkad_common.o -c /project/openafs/src/rxkad/rxkad_com= mon.c > "/project/openafs/src/afs/AIX/osi_machdep.h", line 90.12: 1506-007 (S) "s= truct timestruc_t" is undefined. > "../sys/time.h", line 587.17: 1506-343 (S) Redeclaration of curtime diffe= rs from previous declaration on line 91 of "/project/openafs/src/afs/AIX/os= i_machdep.h". > "../sys/time.h", line 587.17: 1506-050 (I) Return type "void" in redeclar= ation is not compatible with the previous return type "int". > make: 1254-004 The error code from the last command is 1. > > > Has anyone seen this? Certainly that struct is defined in /usr/include/s= ys/time.h, but this seems like it's probably something obvious and I'm will= ing to bet it's on my end and not a problem with the code. That looks like some fallout from https://gerrit.openafs.org/#/c/14238/ and given the lack of any remark about testing on AIX in the review notes, I'm more inclined to think it's an issue with the OpenAFS code than your setup. What does curtime() look like on your system? We just need a way to get the current time in seconds+microseconds precision (converting from, e.g., nanoseconds if needed). We may have just typo'd something in the src/afs/AIX/osi_machdep.h chunk, for all I know. Thanks, Ben P.S. If you think you might be able to contribute some resources to have a regular AIX buildbot worker again, we'd be delighted to talk about that! --_000_MWHPR0701MB3674B3FC0FA5B9C3F7E676E7A7679MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ah, interesting! Thank you for pointing that out!

Just to test a sloppy fix, I added an include of <sys/time.h> to = ;src/afs/AIX/osi_machdep.h, and that allowed the compile to continue. = It stops at src/afs/AIX/osi_sleep.c, but I'll treat that as a separate thr= ead.

I'm not sure if including <sys/time.h> from src/afs/AIX/osi_machdep.h= is the best way to resolve it, but if so maybe that should be put in a pat= ch? Perhaps it should go in src/afs/sysincudes.h?

Thank you!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Friday, August 12, 2022 9:55 AM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-info@openafs.org <openafs-info@openafs.org>
Subject: Re: [OpenAFS] Building on AIX

Hi Ben,

On Fri, Aug 12, 2022 at 04:41:04PM +0000, Ben Huntsman wrote:
> Hi guys!
>
> Has anyone built this on AIX recently? I see in the code that th= ere is support for AIX 6.1, and 7.2. I was hoping to get it working o= n 7.1 so I figured I'd start with a build on AIX 6.1 to make sure it was in= working order before attempting to port it to 7.1. I'm using XLC 13.1.3 and my AIX level is 6100-09-12-1846.

It looks like we lost our regular AIX buildbot worker in early 2017, so any=
builds since then have been ad hoc/infrequent.
That said, I think we're happy to help work through any issues that have arisen since then and get things back into a usable state on AIX.

> I checked out the code from git and am using the master branch. = I am using the following config options:
>
> CC=3Dxlc_r ./configure --prefix=3D/opt/openafs --enable-tivoli-tsm --e= nable-kauth --disable-fuse-client --with-gssapi=3D/opt/freeware --with-krb5= =3D/opt/freeware

[obligatory note that kauth is woefully insecure and should only be used if=
you have compatibility requirements with legacy systems that cannot be
upgraded]

> Are those appropriate/reasonable under AIX? Currently, I'm getti= ng the following error:
>
> cc -I. -I.= . -I../nfs -I/project/openafs/src/crypto/hcrypto/kernel -I/proj= ect/openafs/src -I/project/openafs/src/afs -I/project/openafs/s= rc/afs/AIX -I/project/openafs/src/config -I/project/openafs/src= /rx/AIX -I/project/openafs/src/external/heimdal -I/project/openafs/src -I/project/openafs/src/afs -I/project/o= penafs/src/afs/AIX -I/project/openafs/src/config -I/project/ope= nafs/src/fsint -I/project/openafs/src/vlserver -I/project/opena= fs/src/auth -I/project/openafs/include -I/project/openafs/inclu= de/afs -I. -I.. -I/project/openafs/src/config -U_IBMR2 -D_POWER -D_AIX -DNL= S -D_NLS -DMSG -D__STR31__ -Daiws -D_POWER_RS -D_POWER_PC -D_POWER_RS= 1 -D_POWER_RS2 -D_POWER_RSC -D_POWER_601 -D_POWER_603 -D_POWER_604 -D= _THREADS -M -D_KERNEL -D_POWER_MP -UKOFF -DAFSDEBUG -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -H8 -DAFS -DAFS_COMMON = -D_VOPS -D_SUN -DKERNEL -q64 -DAFS_64BIT_KERNEL -D__64BIT_KERNEL -g -I/proj= ect/openafs/src/rxkad -I/project/openafs/src/rxkad -o rxkad_common.o -c /pr= oject/openafs/src/rxkad/rxkad_common.c
> "/project/openafs/src/afs/AIX/osi_machdep.h", line 90.12: 15= 06-007 (S) "struct timestruc_t" is undefined.
> "../sys/time.h", line 587.17: 1506-343 (S) Redeclaration of = curtime differs from previous declaration on line 91 of "/project/open= afs/src/afs/AIX/osi_machdep.h".
> "../sys/time.h", line 587.17: 1506-050 (I) Return type "= ;void" in redeclaration is not compatible with the previous return typ= e "int".
> make: 1254-004 The error code from the last command is 1.
>
>
> Has anyone seen this? Certainly that struct is defined in /usr/i= nclude/sys/time.h, but this seems like it's probably something obvious and = I'm willing to bet it's on my end and not a problem with the code.

That looks like some fallout from https://gerrit.openafs.org/#/c/14238/ and
given the lack of any remark about testing on AIX in the review notes, I'm<= br> more inclined to think it's an issue with the OpenAFS code than your setup.=

What does curtime() look like on your system?
We just need a way to get the current time in seconds+microseconds
precision (converting from, e.g., nanoseconds if needed). We may have= just
typo'd something in the src/afs/AIX/osi_machdep.h chunk, for all I know.
Thanks,

Ben

P.S. If you think you might be able to contribute some resources to have a<= br> regular AIX buildbot worker again, we'd be delighted to talk about that!

--_000_MWHPR0701MB3674B3FC0FA5B9C3F7E676E7A7679MWHPR0701MB3674_-- From kaduk@mit.edu Fri Aug 12 19:16:54 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Fri, 12 Aug 2022 11:16:54 -0700 Subject: [OpenAFS] Building on AIX In-Reply-To: References: <20220812165532.GI24514@kduck.mit.edu> Message-ID: <20220812181654.GJ24514@kduck.mit.edu> On Fri, Aug 12, 2022 at 06:12:00PM +0000, Ben Huntsman wrote: > Ah, interesting! Thank you for pointing that out! > > Just to test a sloppy fix, I added an include of to src/afs/AIX/osi_machdep.h, and that allowed the compile to continue. It stops at src/afs/AIX/osi_sleep.c, but I'll treat that as a separate thread. > > I'm not sure if including from src/afs/AIX/osi_machdep.h is the best way to resolve it, but if so maybe that should be put in a patch? Perhaps it should go in src/afs/sysincudes.h? sysincludes.h sounds better to me, yes. If you're able, please go ahead and make a patch and submit it to our gerrit instance for review! The entry point for the documentation on how to do that would be https://wiki.openafs.org/devel/GitDevelopers/ , which probably covers a bit more than is needed to just submit this one patch (but I guess it sounds like there will be more coming later...). We also have the openafs-devel@openafs.org list and a not-very-active jabber room openafs@conference.openafs.org, plus a general IRC channel #openafs on Libera. Thanks! -Ben From jaltman@auristor.com Fri Aug 12 19:23:24 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Fri, 12 Aug 2022 14:23:24 -0400 Subject: [OpenAFS] OpenAFS vs IBM AFS In-Reply-To: References: Message-ID: <31b20788-19e1-b1e6-47e2-67e9d7833c8e@auristor.com> This is a cryptographically signed message in MIME format. --------------ms020406040206060609040702 Content-Type: multipart/alternative; boundary="------------duOsJDWD3J3rvaM8H2guj6vk" --------------duOsJDWD3J3rvaM8H2guj6vk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/12/2022 2:01 PM, Ben Huntsman (ben@huntsmans.net) wrote: > That is about what I thought. I guess I ask because for those of > us who work more with AIX than the other platforms, it would be > interesting and valuable to be able to track the IBM code base as > well, even if that were kept in a separate repository from OpenAFS. I'm not sure how tracking the IBM code base is all that helpful. The IBM AFS client does not support new RPCs added to OpenAFS nor does it include the most of the other changes. In the end its the developer time and access to AIX systems and development tools that are required to support an AFS client and server. If there is an end user community for an AIX AFS client, then it would be helpful if that community would provide resources to OpenAFS to make it happen. > > I'm also very interested in what it took to clean the code base to > achieve the 1.0 release. I know some things were removed such as that > washtool thing, and the special version of AIX's fsck that is AFS-aware. The primary changes were to remove code that IBM didn't have permission to re-license, comments that referenced customers, or functionality that was specific to certain private builds, and any references to individuals by name. There was more but that was the practical work. Reviewing a million line code base so legal can sign off on things is a lot of work. > But that was a long time ago. I wonder if times have changed and if > there would be fewer legal and technical hurdles to releasing some of > those things? I doubt it. All of the original work would need to be repeated. > The AIX AFS-aware fsck would be worthwhile even now. I disagree. In OpenAFS any validation of the contents of the Volume Group object stores located in the vice partition file systems should be performed by the on-demand salvager. There should be no need to run an external tool while the services are shutdown. Jeffrey Altman --------------duOsJDWD3J3rvaM8H2guj6vk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/12/2022 2:01 PM, Ben Huntsman (ben@huntsmans.net) wrote:

That is about what I thought. I guess I ask because for those of us who work more with AIX than the other platforms, it would be interesting and valuable to be able to track the IBM code base as well, even if that were kept in a separate repository from OpenAFS.

I'm not sure how tracking the IBM code base is all that helpful. The IBM AFS client does not support new RPCs added to OpenAFS nor does it include the most of the other changes. In the end its the developer time and access to AIX systems and development tools that are required to support an AFS client and server. If there is an end user community for an AIX AFS client, then it would be helpful if that community would provide resources to OpenAFS to make it happen.

I'm also very interested in what it took to clean the code base to achieve the 1.0 release. I know some things were removed such as that washtool thing, and the special version of AIX's fsck that is AFS-aware.

The primary changes were to remove code that IBM didn't have permission to re-license, comments that referenced customers, or functionality that was specific to certain private builds, and any references to individuals by name. There was more but that was the practical work. Reviewing a million line code base so legal can sign off on things is a lot of work.

But that was a long time ago. I wonder if times have changed and if there would be fewer legal and technical hurdles to releasing some of those things?

I doubt it. All of the original work would need to be repeated.

The AIX AFS-aware fsck would be worthwhile even now.

I disagree. In OpenAFS any validation of the contents of the Volume Group object stores located in the vice partition file systems should be performed by the on-demand salvager. There should be no need to run an external tool while the services are shutdown.

Jeffrey Altman

--------------duOsJDWD3J3rvaM8H2guj6vk-- --------------ms020406040206060609040702 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxMjE4 MjMyNFowLwYJKoZIhvcNAQkEMSIEIMLhzd2GmSilJS/RwPQAZc1c8fYwdiJwDdhQfq7LF1bJ MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAP3vo VbhEs/Ry1fu9TaIbdzYohJonq1IrnCF4G5yhbh9ZzFJAeuseZ3XAX2iKI5vtLgj5rMw8CgIu eAnnvKSTjKzQ5rb67RQd545Vbg4jCkbqqi1S4x7iY8lLAfhPXGIokHwN8MG+3RZYyc3gLvc8 /f/ODV4dhF5F+1TankmAGpJa6EcjQbtO2PBJDM9E/WYLv7xVqJ5hgsVU6EoPsFVczOwf04WR F631mbZimjCqxtpvtVIcaMQmTM5wjkszRf5lBtTEMNwMyg6RXx9YJV2wJgzmXy5ZIUGJ7qMD TEY2D45i2xBVW0Dzzx8fdwPnJ3OWL1mjr7y4j0Zjqmq51CsMEwAAAAAAAA== --------------ms020406040206060609040702-- From ben@huntsmans.net Sat Aug 13 06:57:41 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sat, 13 Aug 2022 05:57:41 +0000 Subject: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol vprintf Message-ID: --_000_MWHPR0701MB3674039C4659C58B11EF9213A7669MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After a few tweaks to some of the source files (which I will submit later),= I have all the code for afs.ext.64 compiling, but it fails to link due to = a missing symbol .vprintf. The AIX man pages show that this is included in= /lib/libc.a, and nm confirms it. Here is the error: /usr/bin/ld -b"binder:/usr/lib/bind glink:/usr/lib/glink64.o" -bnoe= ntry -b h:4 -D0 -T512 -b64 -bloadmap:afs.ext.64.loadmap -bmap:afs.ext.64.= map -o afs.ext.64 sha256-kernel.o rand-timer-kernel.o afs_atomlist.o af= s_lhash.o afs_analyze.o afs_axscache.o afs_buffer.o afs_bypassc= ache.o afs_callback.o afs_cbqueue.o afs_cell.o afs_chunk.o = afs_conn.o afs_daemons.o afs_dcache.o afs_dir.o = afs_disconnected.o afs_dynroot.o afs_error.o afs_icl= .o afs_init.o afs_lock.o afs_mariner.o afs_memcache.o afs_fetchstore.= o afs_osi.o afs_osidnlc.o afs_osi_alloc.o af= s_osi_pag.o afs_osi_uio.o afs_osi_vget.o afs_osi_vm.o afs_segments.o a= fs_server.o afs_stat.o afs_syscall.o afs_tokens.o afs_user.o afs_util.= o afs_vcache.o afs_vnop_access.o afs_vnop_attrs.o afs_vnop_create.o af= s_vnop_dirops.o afs_vnop_fid.o afs_vnop_flock.o afs_vnop_link.o afs_vno= p_lookup.o afs_vnop_open.o afs_vnop_read.o afs_vnop_readdir.o afs_vnop_= remove.o afs_vnop_rename.o afs_vnop_strategy.o afs_vnop_symlink.o afs_v= nop_write.o afs_volume.o afs_warn.o xdr_update.o xdr_refernce.o = Kvice.xdr.o xdr_arrayn.o xdr_array.o xdr_int32.o xdr_int64.= o Kvice.cs.o fcrypt.o rx.o rx_call.o = rx_conn.o rx_peer.o rx_rdwr.o rx_clock.o rx_event= .o rx_globals.o rx_identity.o rx_kmutex.o rx_knet.o rx_= kcommon.o rx_misc.o rx_null.o rx_opaque.o rx_getaddr.o = rx_packet.o rx_multi.o rx_stats.o opr_rbtree.o xdr_rx.o = xdr_mem.o xdr_len.o Kvldbint.cs.o Kvldbint.xdr.o Kcal= lback.ss.o Krxstat.ss.o Krxstat.xdr.o rxstat.o crypt_conn.o = AFS_component_version_number.o afs_exporter.o rxkad_client.o rxkad_comm= on.o xdr_afsuuid.o xdr.o Ktoken.xdr.o md5.o evp.o= evp-algs.o rand-kernel.o alloc-kernel.o aes.o = rijndael-alg-fst.o sha.o n-fold.o crypto.o = crypto-algs.o crypto-aes.o crypto-context.o crypto-copy.o = crypto-ct.o crypto-evp.o crypto-data.o crypto-keyblock.o crypto= -store-int.o crypto-random.o afs_uuid.o osi_assem.o osi_config.o osi_gc= pags.o osi_groups.o osi_file.o osi_inode.o osi_misc.o osi_sleep.o osi= _timeout.o osi_vcache.o osi_vm.o rand-fortuna-kernel.o afs_call.o afs_p= ioctl.o osi_vfsops.o osi_vnodeops.o -m -eafs_config -bexport:/project/o= penafs/lib/afs.exp -bI:/lib/kernex.exp -bI:/lib/syscalls.exp -bI:/lib/socke= ts.exp -bI:/lib/netinet.exp -bI:/project/openafs/lib/extras.exp -lsys -= lcsys -b64 -bI:/project/openafs/lib/export64.exp ld: 0711-224 WARNING: Duplicate symbol: vnodefops ld: 0711-224 WARNING: Duplicate symbol: .___memmove64 ld: 0711-224 WARNING: Duplicate symbol: ___memmove64 ld: 0711-224 WARNING: Duplicate symbol: .___memset64 ld: 0711-224 WARNING: Duplicate symbol: ___memset64 ld: 0711-224 WARNING: Duplicate symbol: .ip_stripoptions ld: 0711-224 WARNING: Duplicate symbol: .soclose ld: 0711-224 WARNING: Duplicate symbol: soclose ld: 0711-224 WARNING: Duplicate symbol: Trconflag ld: 0711-224 WARNING: Duplicate symbol: .sounlock ld: 0711-224 WARNING: Duplicate symbol: sounlock ld: 0711-224 WARNING: Duplicate symbol: .close ld: 0711-224 WARNING: Duplicate symbol: close ld: 0711-224 WARNING: Duplicate symbol: .___memcmp64 ld: 0711-224 WARNING: Duplicate symbol: ___memcmp64 ld: 0711-224 WARNING: Duplicate symbol: .kioctl ld: 0711-224 WARNING: Duplicate symbol: .lookupname ld: 0711-224 WARNING: Duplicate symbol: lookupname ld: 0711-224 WARNING: Duplicate symbol: .socreate ld: 0711-224 WARNING: Duplicate symbol: socreate ld: 0711-224 WARNING: Duplicate symbol: .soreserve ld: 0711-224 WARNING: Duplicate symbol: soreserve ld: 0711-224 WARNING: Duplicate symbol: .sobind ld: 0711-224 WARNING: Duplicate symbol: sobind ld: 0711-344 See the loadmap file afs.ext.64.loadmap for more information. ld: 0711-319 WARNING: Exported symbol not defined: afs_setTimeHost ld: 0711-319 WARNING: Exported symbol not defined: rxevent_nFree ld: 0711-319 WARNING: Exported symbol not defined: rxevent_nPosted ld: 0711-319 WARNING: Exported symbol not defined: freeSQEList_lock ld: 0711-319 WARNING: Exported symbol not defined: rxevent_lock ld: 0711-317 ERROR: Undefined symbol: .vprintf make: 1254-004 The error code from the last command is 8. The reference is from src/rx/rx_kcommon.c: void osi_Msg(const char *fmt, ...) { va_list ap; va_start(ap, fmt); #if defined(AFS_LINUX_ENV) vprintk(fmt, ap); #else vprintf(fmt, ap); #endif va_end(ap); } Just as another sloppy fix I tried several variants of print functions that= could substitute on AIX, but they all fail with a missing symbol. How did= this work on AIX in the past? Thank you! -Ben --_000_MWHPR0701MB3674039C4659C58B11EF9213A7669MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

After a few tweaks to some of the source files (which I will submit later),= I have all the code for afs.ext.64 compiling, but it fails to link due to = a missing symbol .vprintf. The AIX man pages show that this is includ= ed in /lib/libc.a, and nm confirms it. Here is the error:

/usr/bin/ld -b"binder:/usr/lib/bind glink:= /usr/lib/glink64.o" -bnoentry -b h:4 -D0 -T512 -b64 -bloadmap:af= s.ext.64.loadmap -bmap:afs.ext.64.map -o afs.ext.64 sha256-kern= el.o rand-timer-kernel.o afs_atomlist.o afs_lhash.o = ;afs_analyze.o afs_axscache.o afs_buffer.o afs_bypasscache.o af= s_callback.o afs_cbqueue.o afs_cell.o &n= bsp;afs_chunk.o afs_conn.o= afs_daemons.o afs_dcache.o afs_dir.o &nbs= p; afs_disconnected.o &nbs= p; afs_dynroot.o afs_error.= o afs_icl.o afs_init.o afs_lock.o afs_mariner.o afs_memcache.o= afs_fetchstore.o afs_osi.o = afs_osidnlc.o afs_osi_alloc.o &n= bsp; afs_osi_pag.o afs_osi_uio.o afs_osi_v= get.o afs_osi_vm.o afs_segments.o afs_server.o afs_= stat.o afs_syscall.o afs_tokens.o afs_user.o afs_util.o afs_vcache.o &n= bsp;afs_vnop_access.o afs_vnop_attrs.o afs_vnop_create.o = afs_vnop_dirops.o afs_vnop_fid.o afs_vnop_flock.o afs_vno= p_link.o afs_vnop_lookup.o afs_vnop_open.o afs_vnop_read.= o afs_vnop_readdir.o afs_vnop_remove.o afs_vnop_rename.o afs_vnop_strategy.o afs_vnop_symlink.o= afs_vnop_write.o afs_volume.o afs_warn.o xdr_updat= e.o xdr_refernce.o Kvice.xdr.o &nb= sp; xdr_arrayn.o xdr_array.o xdr_int32.o = xdr_int64.o Kvice.cs.o fcrypt.o &n= bsp; rx.o rx_call.= o rx_conn.o rx_peer.o &nbs= p; rx_rdwr.o rx_clock.o rx_= event.o rx_globals.o rx_identity.o = rx_kmutex.o rx_knet.o rx_kcommon.o = ; rx_misc.o rx_null.o rx_op= aque.o rx_getaddr.o rx_packet.o rx_multi.o rx_s= tats.o opr_rbtree.o xdr_rx.o = xdr_mem.o xdr_len.o = Kvldbint.cs.o Kvldbint.xdr.o Kcallback.ss.o Krxstat.ss.= o Krxstat.xdr.o rxstat.o cry= pt_conn.o AFS_component_version_number.o afs_exporter.o rxkad_client.o rxkad_common.o xdr_afsuui= d.o xdr.o Ktoken.xdr.o &nb= sp;md5.o evp.o &nbs= p; evp-algs.o rand-kernel.o alloc-k= ernel.o aes.o = ; rijndael-alg-fst.o sha.o = n-fold.o crypto.o crypto-algs.o crypt= o-aes.o crypto-context.o crypto-copy.o &n= bsp; crypto-ct.o crypto-evp.o crypto-data.o &nbs= p; crypto-keyblock.o crypto-store-int.o crypto-random.o a= fs_uuid.o osi_assem.o osi_config.o osi_gcpags.o osi_group= s.o osi_file.o osi_inode.o osi_misc.o osi_sleep.o &nbs= p;osi_timeout.o osi_vcache.o osi_vm.o rand-fortuna-kernel= .o afs_call.o afs_pioctl.o osi_vfsops.o osi_vnodeops.o &n= bsp; -m -eafs_config -bexport:/project/openafs/lib/afs.exp -bI:/lib/kernex.= exp -bI:/lib/syscalls.exp -bI:/lib/sockets.exp -bI:/lib/netinet.exp -bI:/project/openafs= /lib/extras.exp -lsys -lcsys -b64 -bI:/project/openafs/lib/exp= ort64.exp

ld: 0711-224 WARNING: Duplicate symbol: vnodefops

ld: 0711-224 WARNING: Duplicate symbol: .___memmove64

ld: 0711-224 WARNING: Duplicate symbol: ___memmove64

ld: 0711-224 WARNING: Duplicate symbol: .___memset64

ld: 0711-224 WARNING: Duplicate symbol: ___memset64

ld: 0711-224 WARNING: Duplicate symbol: .ip_stripoptions

ld: 0711-224 WARNING: Duplicate symbol: .soclose

ld: 0711-224 WARNING: Duplicate symbol: soclose

ld: 0711-224 WARNING: Duplicate symbol: Trconflag

ld: 0711-224 WARNING: Duplicate symbol: .sounlock

ld: 0711-224 WARNING: Duplicate symbol: sounlock

ld: 0711-224 WARNING: Duplicate symbol: .close

ld: 0711-224 WARNING: Duplicate symbol: close

ld: 0711-224 WARNING: Duplicate symbol: .___memcmp64

ld: 0711-224 WARNING: Duplicate symbol: ___memcmp64

ld: 0711-224 WARNING: Duplicate symbol: .kioctl

ld: 0711-224 WARNING: Duplicate symbol: .lookupname

ld: 0711-224 WARNING: Duplicate symbol: lookupname

ld: 0711-224 WARNING: Duplicate symbol: .socreate

ld: 0711-224 WARNING: Duplicate symbol: socreate

ld: 0711-224 WARNING: Duplicate symbol: .soreserve

ld: 0711-224 WARNING: Duplicate symbol: soreserve

ld: 0711-224 WARNING: Duplicate symbol: .sobind

ld: 0711-224 WARNING: Duplicate symbol: sobind

ld: 0711-344 See the loadmap file afs.ext.64.loadmap for more informat= ion.

ld: 0711-319 WARNING: Exported symbol not defined: afs_setTimeHost

ld: 0711-319 WARNING: Exported symbol not defined: rxevent_nFree

ld: 0711-319 WARNING: Exported symbol not defined: rxevent_nPosted

ld: 0711-319 WARNING: Exported symbol not defined: freeSQEList_lock

ld: 0711-319 WARNING: Exported symbol not defined: rxevent_lock

ld: 0711-317 ERROR: Undefined symbol: .vprintf

make: 1254-004 The error code from the last command is 8.

The reference is from src/rx/rx_kcommon.c:

void

osi_Msg(const char *fmt, ...)

{

va_list ap;

va_start(ap, fmt);

#if defined(AFS_LINUX_ENV)

vprintk(fmt, ap);

#else

vprintf(fmt, ap);

#endif

va_end(ap);

}

Just as another sloppy fix I tried several variants of print functions that= could substitute on AIX, but they all fail with a missing symbol. Ho= w did this work on AIX in the past?

Thank you!

-Ben

--_000_MWHPR0701MB3674039C4659C58B11EF9213A7669MWHPR0701MB3674_-- From jaltman@auristor.com Sat Aug 13 10:23:44 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sat, 13 Aug 2022 05:23:44 -0400 Subject: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol vprintf In-Reply-To: References: Message-ID: <3ca2722a-9965-9bfe-7e05-f2de3cfbe4f6@auristor.com> This is a cryptographically signed message in MIME format. --------------ms070105090206060102090309 Content-Type: multipart/alternative; boundary="------------gdh5fbR86AU2biDLXnnEslaL" --------------gdh5fbR86AU2biDLXnnEslaL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/13/2022 1:57 AM, Ben Huntsman (ben@huntsmans.net) wrote: > After a few tweaks to some of the source files (which I will submit > later), I have all the code for afs.ext.64 compiling, but it fails to > link due to a missing symbol .vprintf. The AIX man pages show that > this is included in /lib/libc.a, and nm confirms it. > libc is a userspace library. The failure is when linking the kernel module and there is no vprintf in the kernel. > The reference is from src/rx/rx_kcommon.c: > > void > osi_Msg(const char *fmt, ...) > { > va_list ap; > va_start(ap, fmt); > #if defined(AFS_LINUX_ENV) > vprintk(fmt, ap); > #else > vprintf(fmt, ap); > #endif > va_end(ap); > } > > > Just as another sloppy fix I tried several variants of print functions > that could substitute on AIX, but they all fail with a missing > symbol. How did this work on AIX in the past? > The vprintf usage in kernel on AIX was introduced by https://gerrit.openafs.org/14791 --------------gdh5fbR86AU2biDLXnnEslaL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/13/2022 1:57 AM, Ben Huntsman (ben@huntsmans.net) wrote:

After a few tweaks to some of the source files (which I will submit later), I have all the code for afs.ext.64 compiling, but it fails to link due to a missing symbol .vprintf. The AIX man pages show that this is included in /lib/libc.a, and nm confirms it.

libc is a userspace library. The failure is when linking the kernel module and there is no vprintf in the kernel.

The reference is from src/rx/rx_kcommon.c:

void
osi_Msg(const char *fmt, ...)

{

va_list ap;

va_start(ap, fmt);

#if defined(AFS_LINUX_ENV)

vprintk(fmt, ap);

#else

vprintf(fmt, ap);

#endif

va_end(ap);

}

Just as another sloppy fix I tried several variants of print functions that could substitute on AIX, but they all fail with a missing symbol. How did this work on AIX in the past?

The vprintf usage in kernel on AIX was introduced by

https://gerrit.openafs.org/14791

--------------gdh5fbR86AU2biDLXnnEslaL-- --------------ms070105090206060102090309 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxMzA5 MjM0NFowLwYJKoZIhvcNAQkEMSIEIHZcV1VVb6yAfbqkSmHkk5bLY4pkBNGmXz92gMN+0TRN MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEADsJI hFsm7kCZqlZS6ku/If1niGkxS81mrnAhzIeE9fHIzMtZOZuKx+UgwXY4MENATEk6t06IZLaC cqEpGE/2/nw0hcmiZM1qyKVCVjPt8mVK2visCU079ypRT7hucke75qbe7FmL9h4OSjl7pzEh Y/dYQKNu8/pXNuPNpx6hQ1WYLxU6xRVO0C25A8WmhBDlvDi+rCl1B2C9QIU4IcAxQS03mJS1 6PnkPEo8MmMG00kvhtk5TmtfVz74l1CdLna+ZgFQ1/Qm+i7Uj7KJ34uadJnnJfF6aKI7zvev zeJ5fD3Dh2p/LNE5MOQPTpQOshmpzXnNjuy4TF0HVHyG3M/G9wAAAAAAAA== --------------ms070105090206060102090309-- From ben@huntsmans.net Sat Aug 13 17:20:27 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sat, 13 Aug 2022 16:20:27 +0000 Subject: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol vprintf Message-ID: --_000_MWHPR0701MB367420F72B076B1AC707CF35A7669MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ah, yes, that is what I thought. The problem is that AIX's kernel doesn't = have vprintf. Only printf. However, the change set you linked indicates t= hat previously, osi_Msg used fprintf, and indeed that goes all the way back= to the beginning. That's why I wonder how it worked on AIX in the past. = With no vprintf in the kernel, what alternative should we use here? Thank you! -Ben ________________________________ From: Jeffrey E Altman Sent: Saturday, August 13, 2022 2:23 AM To: Ben Huntsman; openafs-info@openafs.org Subject: Re: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol = vprintf On 8/13/2022 1:57 AM, Ben Huntsman (ben@huntsmans.net) wrote: After a few tweaks to some of the source files (which I will submit later),= I have all the code for afs.ext.64 compiling, but it fails to link due to = a missing symbol .vprintf. The AIX man pages show that this is included in= /lib/libc.a, and nm confirms it. libc is a userspace library. The failure is when linking the kernel modul= e and there is no vprintf in the kernel. The reference is from src/rx/rx_kcommon.c: void osi_Msg(const char *fmt, ...) { va_list ap; va_start(ap, fmt); #if defined(AFS_LINUX_ENV) vprintk(fmt, ap); #else vprintf(fmt, ap); #endif va_end(ap); } Just as another sloppy fix I tried several variants of print functions that= could substitute on AIX, but they all fail with a missing symbol. How did= this work on AIX in the past? The vprintf usage in kernel on AIX was introduced by https://gerrit.openafs.org/14791 --_000_MWHPR0701MB367420F72B076B1AC707CF35A7669MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ah, yes, that is what I thought. The problem is that AIX's kernel doe= sn't have vprintf. Only printf. However, the change set you lin= ked indicates that previously, osi_Msg used fprintf, and indeed that goes a= ll the way back to the beginning. That's why I wonder how it worked on AIX in the past. With no vprintf in the kern= el, what alternative should we use here?

Thank you!

-Ben

From: Jeffrey E Altman
Sent: Saturday, August 13, 2022 2:23 AM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] linking afs.ext.64 on AIX fails with missing = symbol vprintf

On 8/13/2022 1:57 AM, Ben Huntsman (ben@hunt= smans.net) wrote:

After a few tweaks to some of the source files (which I will submit later),= I have all the code for afs.ext.64 compiling, but it fails to link due to = a missing symbol .vprintf. The AIX man pages show that this is includ= ed in /lib/libc.a, and nm confirms it.

libc is a userspace libra= ry. The failure is when linking the kernel module and there is = no vprintf in the kernel.

The reference is from src/rx/rx_kcommon.c:

void
osi_Msg(const char *fmt, ...)

{

va_list ap;

va_start(ap, fmt);

#if defined(AFS_LINUX_ENV)

vprintk(fmt, ap);

#else

vprintf(fmt, ap);

#endif

va_end(ap);

}

Just as another sloppy fix I tried several variants of print functions that= could substitute on AIX, but they all fail with a missing symbol. Ho= w did this work on AIX in the past?

The vprintf usage in kern= el on AIX was introduced by

https://gerrit.openafs.org/14791

--_000_MWHPR0701MB367420F72B076B1AC707CF35A7669MWHPR0701MB3674_-- From jaltman@auristor.com Sat Aug 13 18:25:30 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sat, 13 Aug 2022 13:25:30 -0400 Subject: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol vprintf In-Reply-To: References: Message-ID: This is a cryptographically signed message in MIME format. --------------ms060106040705050009040804 Content-Type: multipart/alternative; boundary="------------PWkrZ8aFWRb9AWnRxoU81Gut" --------------PWkrZ8aFWRb9AWnRxoU81Gut Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/13/2022 12:20 PM, Ben Huntsman (ben@huntsmans.net) wrote: > Ah, yes, that is what I thought. The problem is that AIX's kernel > doesn't have vprintf. Only printf. However, the change set you > linked indicates that previously, osi_Msg used fprintf, and indeed > that goes all the way back to the beginning. That's why I wonder how > it worked on AIX in the past. With no vprintf in the kernel, what > alternative should we use here? > The prior change had osi_Msg as a macro not a function. That means that the fprintf reference would have been substituted for wherever osi_Msg was used. Assuming that osi_Msg was defined for AIX at all. The referenced change was intended to fix a problem specific to Linux. You might want to revert the change and see whether or not you make further progress. As an aside, development discussions such as this are not of general interest to the end user community and are more appropriate to be held on openafs-devel@openafs.org instead. --------------PWkrZ8aFWRb9AWnRxoU81Gut Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/13/2022 12:20 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Ah, yes, that is what I thought. The problem is that AIX's kernel doesn't have vprintf. Only printf. However, the change set you linked indicates that previously, osi_Msg used fprintf, and indeed that goes all the way back to the beginning. That's why I wonder how it worked on AIX in the past. With no vprintf in the kernel, what alternative should we use here?

The prior change had osi_Msg as a macro not a function. That means that the fprintf reference would have been substituted for wherever osi_Msg was used. Assuming that osi_Msg was defined for AIX at all.

The referenced change was intended to fix a problem specific to Linux. You might want to revert the change and see whether or not you make further progress.

As an aside, development discussions such as this are not of general interest to the end user community and are more appropriate to be held on openafs-devel@openafs.org instead.

--------------PWkrZ8aFWRb9AWnRxoU81Gut-- --------------ms060106040705050009040804 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxMzE3 MjUzMFowLwYJKoZIhvcNAQkEMSIEID5LdyKNB0CDrbO/QM8s14vSBNUQnm1c5cGHU4lqnkgi MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAKVoj GvAQSA9JosLqWFidReXzXZRsPCJsIAUfZatFS7YmPZuJzDxMKN6I3RgbT0Q8ScBaeQ6ZBs+E EECZFBMiZz9SkMbjQ0yn1/sDBYW7KPipY5L8jGLNHwWSNzAjK5zhrZps+XdU9SG3E42IAJpz biusp7oxn8SegzwkPobMNezjvcbrq/Vm1vogzjQok6PfuOAdQADsQVjIaiK7BkGJfDniJUMn EEMxxkGOXpDV41tJxPQEl7185nsdEqZZ5QG3Fhyji1lsO2nG6kZhGISJ2gRZnWOxPPzSi3YY neviCcyo+3LW0ZJxz1v6Lukkqp0Djz/h5C2W2/3889dfF+hBbgAAAAAAAA== --------------ms060106040705050009040804-- From ben@huntsmans.net Sat Aug 13 21:04:21 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sat, 13 Aug 2022 20:04:21 +0000 Subject: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol vprintf Message-ID: --_000_MWHPR0701MB367479A7FE82383960E639EFA7669MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to tie off, yes, reverting that change worked. Other problems down th= e line, but I will continue in the openafs-devel list. Thank you. -Ben ________________________________ From: Jeffrey E Altman Sent: Saturday, August 13, 2022 10:25 AM To: Ben Huntsman; openafs-info@openafs.org Subject: Re: [OpenAFS] linking afs.ext.64 on AIX fails with missing symbol = vprintf On 8/13/2022 12:20 PM, Ben Huntsman (ben@huntsmans.net) wrote: Ah, yes, that is what I thought. The problem is that AIX's kernel doesn't = have vprintf. Only printf. However, the change set you linked indicates t= hat previously, osi_Msg used fprintf, and indeed that goes all the way back= to the beginning. That's why I wonder how it worked on AIX in the past. = With no vprintf in the kernel, what alternative should we use here? The prior change had osi_Msg as a macro not a function. That means that th= e fprintf reference would have been substituted for wherever osi_Msg was us= ed. Assuming that osi_Msg was defined for AIX at all. The referenced change was intended to fix a problem specific to Linux. You= might want to revert the change and see whether or not you make further pr= ogress. As an aside, development discussions such as this are not of general intere= st to the end user community and are more appropriate to be held on openafs= -devel@openafs.org instead. --_000_MWHPR0701MB367479A7FE82383960E639EFA7669MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just to tie off, yes, reverting that change worked. Other problems do= wn the line, but I will continue in the openafs-devel list.

Thank you.

-Ben

From: Jeffrey E Altman
Sent: Saturday, August 13, 2022 10:25 AM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] linking afs.ext.64 on AIX fails with missing = symbol vprintf

On 8/13/2022 12:20 PM, Ben Huntsman (ben@hun= tsmans.net) wrote:

Ah, yes, that is what I thought. The problem is that AIX's kernel doe= sn't have vprintf. Only printf. However, the change set you lin= ked indicates that previously, osi_Msg used fprintf, and indeed that goes a= ll the way back to the beginning. That's why I wonder how it worked on AIX in the past. With no vprintf in the kern= el, what alternative should we use here?

The prior change had osi_= Msg as a macro not a function. That means that the fprintf reference = would have been substituted for wherever osi_Msg was used. Assuming t= hat osi_Msg was defined for AIX at all.

The referenced change was= intended to fix a problem specific to Linux. You might want to rever= t the change and see whether or not you make further progress.

As an aside, development = discussions such as this are not of general interest to the end user commun= ity and are more appropriate to be held on openafs-devel@openafs.org instead.

--_000_MWHPR0701MB367479A7FE82383960E639EFA7669MWHPR0701MB3674_-- From ben@huntsmans.net Tue Aug 16 05:43:19 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 16 Aug 2022 04:43:19 +0000 Subject: [OpenAFS] Kerberos + Windows Message-ID: --_000_MWHPR0701MB36745C9A8A555D39E0680EC4A76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- Does anyone have a recipe for making OpenAFS work with AD 2012 R2 or 201= 6 as a KDC? I've seen a few articles on using it with 2008 R2, which mostly involve = re-enabling des-cbc-crc on the AD side... Does OpenAFS support the current= schemes like aes256-cts-hmac-sha1-96, and has anyone gotten that to work? Or is one better off by setting up their own Kerbreos just for OpenAFS? Thank you! -Ben --_000_MWHPR0701MB36745C9A8A555D39E0680EC4A76B9MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

Does anyone have a recipe for making OpenAFS work with AD 2012= R2 or 2016 as a KDC?

I've seen a few articles on using it with 2008 R2, which mostl= y involve re-enabling des-cbc-crc on the AD side... Does OpenAFS= support the current schemes like aes256-cts-hmac-sha1-96, and has any= one gotten that to work?

Or is one better off by setting up their own Kerbreos just for= OpenAFS?

Thank you!

-Ben

--_000_MWHPR0701MB36745C9A8A555D39E0680EC4A76B9MWHPR0701MB3674_-- From kaduk@mit.edu Tue Aug 16 06:11:06 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 15 Aug 2022 22:11:06 -0700 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: References: Message-ID: <20220816051044.GR24514@kduck.mit.edu> On Tue, Aug 16, 2022 at 04:43:19AM +0000, Ben Huntsman wrote: > Hi guys- > Does anyone have a recipe for making OpenAFS work with AD 2012 R2 or 2016 as a KDC? > > I've seen a few articles on using it with 2008 R2, which mostly involve re-enabling des-cbc-crc on the AD side... Does OpenAFS support the current schemes like aes256-cts-hmac-sha1-96, and has anyone gotten that to work? > > Or is one better off by setting up their own Kerbreos just for OpenAFS? In the aftermath of https://www.openafs.org/pages/security/OPENAFS-SA-2013-003.txt the state of the art became using current kerberos enctypes for the service principal, with the KDF to get back to fcrypt keys contained within the AFS boundary. The main thing that has come up with using Windows as the KDC is the possible need to disable or trim down the PACs issued for AFS principals ... though in the wake of some of the more recent AD/Kerberos vulnerabilities maybe that is less advisable, I have forgotten the details. https://datatracker.ietf.org/doc/html/draft-kaduk-afs3-rxkad-k5-kdf-00 discuss the protocol details, https://www.openafs.org/pages/security/install-rxkad-k5-1.6.txt talks about the process of converting an existing cell to use the new mechanisms, and http://docs.openafs.org/QuickStartUnix/ has (IIRC) been updated to cover installing with rxkad-k5 from scratch. Hopefully others can chime in if there are more AD-specific bits than just rxkad-k5; I don't actually run any such environments myself. -Ben From ben@huntsmans.net Wed Aug 24 02:24:19 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 24 Aug 2022 01:24:19 +0000 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: <20220816051044.GR24514@kduck.mit.edu> References: <20220816051044.GR24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674E86D1857DA967F874412A7739MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- Does anyone have a working krb5.conf that works with Windows 2012 R2 or = newer? The docs do show how to set up using the new scheme but assume Kerberos,= not AD. I've tried a few different things but I can't seem to get default= _tkt_enctypes and default_tks_enctypes set correctly. Thank you in advance! -Ben --_000_MWHPR0701MB3674E86D1857DA967F874412A7739MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

Does anyone have a working krb5.conf that works with Windows 2= 012 R2 or newer?

The docs do show how to set up using the new scheme but assume= Kerberos, not AD. I've tried a few different things but I can't seem= to get default_tkt_enctypes and default_tks_enctypes set correct= ly.

Thank you in advance!

-Ben

--_000_MWHPR0701MB3674E86D1857DA967F874412A7739MWHPR0701MB3674_-- From kenh@cmf.nrl.navy.mil Wed Aug 24 12:15:52 2022 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 24 Aug 2022 07:15:52 -0400 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: References: <20220816051044.GR24514@kduck.mit.edu> Message-ID: <202208241115.27OBFrcc010141@hedwig.cmf.nrl.navy.mil> >The docs do show how to set up using the new scheme but assume >Kerberos, not AD. I've tried a few different things but I can't seem >to get default_tkt_enctypes and default_tks_enctypes set correctly. In the normal course of things you never, ever want to put any entries for default_tkt_enctypes and default_tgs_enctypes (I'm assuming that's what you meant for the second one). Just remove them from your krb5.conf and take the defaults. The circumstances where you'd ever want to specify those are very very rare. If there is documentation somewhere that says you SHOULD put something for those entries, let me know and I will personally hunt it down and kill it (we had a problem where people in my larger organization thought it was a good idea to put entries in for those configuration file entries; caused us problems for YEARS). --Ken From jaltman@auristor.com Wed Aug 24 13:02:54 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Wed, 24 Aug 2022 08:02:54 -0400 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: References: <20220816051044.GR24514@kduck.mit.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms030404080008040106060109 Content-Type: multipart/alternative; boundary="------------bVlbIaZRgTd0bvsCDxMns5Vt" --------------bVlbIaZRgTd0bvsCDxMns5Vt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/23/2022 9:24 PM, Ben Huntsman (ben@huntsmans.net) wrote: > Hi guys- > Does anyone have a working krb5.conf that works with Windows 2012 > R2 or newer? > > The docs do show how to set up using the new scheme but assume > Kerberos, not AD. I've tried a few different things but I can't seem > to get default_tkt_enctypes and default_tks_enctypes set correctly. > Ben, A krb5.conf is configuration for an MIT or Heimdal Kerberos client but not for a Microsoft Windows Kerberos client. Please clarify which Kerberos client implementation you are configuring. I agree with Ken that default_tkt_enctypes and default_tks_enctypes should never be configured on clients. Jeffrey Altman --------------bVlbIaZRgTd0bvsCDxMns5Vt Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/23/2022 9:24 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Hi guys-

Does anyone have a working krb5.conf that works with Windows 2012 R2 or newer?

The docs do show how to set up using the new scheme but assume Kerberos, not AD. I've tried a few different things but I can't seem to get default_tkt_enctypes and default_tks_enctypes set correctly.

Ben,

A krb5.conf is configuration for an MIT or Heimdal Kerberos client but not for a Microsoft Windows Kerberos client.

Please clarify which Kerberos client implementation you are configuring.

I agree with Ken that default_tkt_enctypes and default_tks_enctypes should never be configured on clients.

Jeffrey Altman

--------------bVlbIaZRgTd0bvsCDxMns5Vt-- --------------ms030404080008040106060109 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgyNDEy MDI1NFowLwYJKoZIhvcNAQkEMSIEINBRuSrmiyrBqQW86cuWxTiyLMh04sQMyiQosmCQiKGG MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAGjzf xF8iDmdYGvGlMsZPOivroiD5ZUOv4DJhVmIhs5G2YdXreVYXQuRfDYMzcIVqwAvrtAHZrtJ2 lruh8dR/063C+s3F3KUbSiSBSUIW7RNfgwl3mslaFMNpGouONZ385IgbPc5HfHHSkHEXU+h4 nF8Fx0EiKzNY1JM4QxQ+MSVcH30ISXKLdwydh9FlYL5ujCkvFtss3NWmqjgVsaHPgaueJExs yKh2LVe7OPpFbU3Es6KFpooKBgxsajpxfRV/wMw/qHXgjuKFlPqQ20oqyT79OnQHKrrRz+kb /IdeBRHXoddLwrTfnd2W/nuULloySL8jMs6Vb6p6qh3A2KnM8gAAAAAAAA== --------------ms030404080008040106060109-- From ben@huntsmans.net Wed Aug 24 17:53:11 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 24 Aug 2022 16:53:11 +0000 Subject: [OpenAFS] Kerberos + Windows Message-ID: --_000_MWHPR0701MB367402C828251E2A551932D5A7739MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there! Thanks for the replies! Removing the encryption types lines helped, and= I got further. This is MIT Kerberos. Here's some configuration info: Let's say my cell is going to be mydomain.com. My Active Directory is a= d.mydomain.com, and my AFS service account is srvAFS. Here's my krb5.conf: [libdefaults] default_realm =3D AD.MYDOMAIN.COM default_keytab_name =3D FILE:/etc/krb5/krb5.keytab dns_lookup_realm =3D true dns_lookup_kdc =3D true forwardable =3D true [realms] AD.MYDOMAIN.COM =3D { kdc =3D ad.mydomain.com:88 admin_server =3D ad.mydomain.com:749 default_domain =3D ad.mydomain.com } [domain_realm] .ad.mydomain.com =3D AD.MYDOMAIN.COM ad.mydomain.com =3D AD.MYDOMAIN.COM [logging] kdc =3D FILE:/var/krb5/log/krb5kdc.log admin_server =3D FILE:/var/krb5/log/kadmin.log kadmin_local =3D FILE:/var/krb5/log/kadmin_local.log default =3D FILE:/var/krb5/log/krb5lib.log I then created the service account srvAFS, and extracted a keytab on the Do= main Controller using the following command: ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop add /= out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt I verified that the account did not have the "Use only Kerberos DES encrypt= ion types for this account" box checked. I then copied the rxkad.keytab ov= er to the UNIX host. I built OpenAFS with a prefix of /opt/openafs, so I p= ut the keytab in /opt/openafs/etc/openafs/server I used ktutil to delete the two des entries in the keytab. ktutil indicate= s that the KVNO is 5. I then added the keys to OpenAFS using the command: asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com Now I add an AD user to OpenAFS: pts createuser -name adUser -id 204 -localauth pts adduser adUser system:administrators -localauth And I try to authenticate: kinit adUser That gives me a password prompt, and it's accepted. Then I run: aklog Also accepted: # tokens Tokens held by the Cache Manager: User's (AFS ID 204) rxkad tokens for mydomain.com [Expires Aug 24 18:27] --End of list-- But things aren't quite working: # ls /afs afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded (rxk= ad error=3D19270408, server 192.168.0.114) ls: /afs: The file access permissions do not allow the specified action. # kvno adUser@AD.MYDOMAIN.COM kvno: Server not found in Kerberos database while getting credentials for a= dUser@AD.MYDOMAIN.COM # vos listvol myserver Could not fetch the list of partitions from the server rxk: ticket contained unknown key version number Error in vos listvol command. rxk: ticket contained unknown key version number # kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab kinit: Cannot determine realm for host (principal host/myserver.mydomain.co= m@) # kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com@A= D.MYDOMAIN.COM # kvno afs/mydomain.com@AD.MYDOMAIN.COM afs/mydomain.com@AD.MYDOMAIN.COM: kvno =3D 5 Did I miss something, or make a mistake along the way somewhere? Thank you so much!! -Ben ________________________________ From: Jeffrey E Altman Sent: Wednesday, August 24, 2022 5:02 AM To: Ben Huntsman; openafs-info@openafs.org Subject: Re: [OpenAFS] Kerberos + Windows On 8/23/2022 9:24 PM, Ben Huntsman (ben@huntsmans.net) wrote: Hi guys- Does anyone have a working krb5.conf that works with Windows 2012 R2 or = newer? The docs do show how to set up using the new scheme but assume Kerberos,= not AD. I've tried a few different things but I can't seem to get default= _tkt_enctypes and default_tks_enctypes set correctly. Ben, A krb5.conf is configuration for an MIT or Heimdal Kerberos client but not = for a Microsoft Windows Kerberos client. Please clarify which Kerberos client implementation you are configuring. I agree with Ken that default_tkt_enctypes and default_tks_enctypes should = never be configured on clients. Jeffrey Altman --_000_MWHPR0701MB367402C828251E2A551932D5A7739MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there!

Thanks for the replies! Removing the encryption types li= nes helped, and I got further. This is MIT Kerberos.

Here's some configuration info:

Let's say my cell is going to be mydomain.com. My Active= Directory is ad.mydomain.com, and my AFS service account is srvAFS. = Here's my krb5.conf:

[libdefaults]

default_realm =3D AD.MYDOMAIN.COM

default_keytab_name =3D FILE:/etc/krb5/krb= 5.keytab

dns_lookup_realm =3D true

dns_lookup_kdc =3D true

forwardable =3D true

[realms]

AD.MYDOMAIN.COM =3D {

kdc =3D ad.myd= omain.com:88

admin_server = =3D ad.mydomain.com:749

default_domain= =3D ad.mydomain.com

}

[domain_realm]

.ad.mydomain.com =3D AD.MYDOMAIN.COM

ad.mydomain.com =3D AD.MYDOMAIN.COM

[logging]

kdc =3D FILE:/var/krb5/log/krb5kdc.log

admin_server =3D FILE:/var/krb5/log/kadmin= .log

kadmin_local =3D FILE:/var/krb5/log/kadmin= _local.log

default =3D FILE:/var/krb5/log/krb5lib.log=

I then created the service account srvAFS, and extracted a keytab on the Do= main Controller using the following command:

ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop add /= out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt

I verified that the account did not have the "Use only Kerberos DES en= cryption types for this account" box checked. I then copied the = rxkad.keytab over to the UNIX host. I built OpenAFS with a prefix of = /opt/openafs, so I put the keytab in /opt/openafs/etc/openafs/server

I used ktutil to delete the two des entries in the keytab. ktutil ind= icates that the KVNO is 5.

I then added the keys to OpenAFS using the command:

asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com

asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com

Now I add an AD user to OpenAFS:

pts createuser -name adUser -id 204 -localauth

pts adduser adUser system:administrators -localauth

And I try to authenticate:

kinit adUser

That gives me a password prompt, and it's accepted. Then I run:

aklog

Also accepted:

# tokens

Tokens held by the Cache Manager:

User's (AFS ID 204) rxkad tokens for mydomain.com [Expires Aug 24 18:2= 7]

--End of list--

But things aren't quite working:

# ls /afs

afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded= (rxkad error=3D19270408, server 192.168.0.114)

ls: /afs: The file access permissions do not allow the specified actio= n.

# kvno adUser@AD.MYDOMAIN.COM
kvno: Server not found in Kerberos database while getting credentials for a= dUser@AD.MYDOMAIN.COM

# vos listvol myserver

Could not fetch the list of partitions from the server

rxk: ticket contained unknown key version number

Error in vos listvol command.

rxk: ticket contained unknown key version number

# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab

kinit: Cannot determine realm for host (principal host/myserver.mydoma= in.com@)

# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.= com@AD.MYDOMAIN.COM

# kvno afs/mydomain.com@AD.MYDOMAIN.COM

afs/mydomain.com@AD.MYDOMAIN.COM: kvno =3D 5

Did I miss something, or make a mistake along the way somewhere?

Thank you so much!!

-Ben

From: Jeffrey E Altman
Sent: Wednesday, August 24, 2022 5:02 AM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] Kerberos + Windows

On 8/23/2022 9:24 PM, Ben Huntsman (ben@hunt= smans.net) wrote:

Hi guys-

Does anyone have a working krb5.conf that works with Windows 2= 012 R2 or newer?

The docs do show how to set up using the new scheme but assume= Kerberos, not AD. I've tried a few different things but I can't seem= to get default_tkt_enctypes and default_tks_enctypes set correct= ly.

Ben,

A krb5.conf is configurat= ion for an MIT or Heimdal Kerberos client but not for a Microsoft Windows K= erberos client.

Please clarify which Kerb= eros client implementation you are configuring.

I agree with Ken that def= ault_tkt_enctypes and default_tks_enctypes should never be configured = on clients.

Jeffrey Altman

--_000_MWHPR0701MB367402C828251E2A551932D5A7739MWHPR0701MB3674_-- From kenh@cmf.nrl.navy.mil Wed Aug 24 19:42:48 2022 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 24 Aug 2022 14:42:48 -0400 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: References: Message-ID: <202208241842.27OIgm7t013258@hedwig.cmf.nrl.navy.mil> >I then created the service account srvAFS, and extracted a keytab on the >Domain Controller using the following command: So I'm not the expert on how AD works, so I can't speak for what happens if you create a service account called _one_ thing and then have a different principal name. Like, what name ends up in the service ticket? But, moving on ... ># kvno adUser@AD.MYDOMAIN.COM >kvno: Server not found in Kerberos database while getting credentials for= adUser@AD.MYDOMAIN.COM kvno is used when you already have a Kerberos ticket (with kinit) and you'= re getting a service ticket for what you give on the command line. I think what you want "kinit adUser" and the "kvno afs/mydomain.com". Although aklog should do the same thing. It would be interesting to see what the output of "klist" is after you do that kinit/kvno command sequence. There is some magic that asetkey does in terms of key version numbering for rxkad_krb5 but it escapes me now and I suspect that's not your real problem. I am assuming you've distributed the KeyFile to _all_ of your AFS servers. --Ken From ben@huntsmans.net Wed Aug 24 21:19:28 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 24 Aug 2022 20:19:28 +0000 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: <202208241842.27OIgm7t013258@hedwig.cmf.nrl.navy.mil> References: <202208241842.27OIgm7t013258@hedwig.cmf.nrl.navy.mil> Message-ID: --_000_MWHPR0701MB3674AAE92C3BA88F0F9CB809A7739MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the reply! > So I'm not the expert on how AD works, so I can't speak for what happens > if you create a service account called _one_ thing and then have a > different principal name. Like, what name ends up in the service > ticket? But, moving on ... I was a little fuzzy on that, but I was under the impression that in my cas= e the serivce principal for AFS has to be called "afs/mydomain.com". Is th= at not so? Therefore, one could either create an AD account literally call= ed "afs", or, let the ktpass command create a SPN for the account, and let = it's name conform to local naming standards. Indeed we can see that the SP= N is created, by running setspn on Windows: C:\>setspn -L srvAFS Registered ServicePrincipalNames for CN=3DsrvAFS,OU=3DUsers,DC=3Dad,DC=3Dmy= domain,DC=3Dcom: afs/mydomain.com > kvno is used when you already have a Kerberos ticket (with kinit) and you= 're > getting a service ticket for what you give on the command line. I think > what you want "kinit adUser" and the "kvno afs/mydomain.com". Although > aklog should do the same thing. > > It would be interesting to see what the output of "klist" is after you > do that kinit/kvno command sequence. $ kinit adUser Password for adUser@AD.MYDOMAIN.COM: $ kvno afs/mydomain.com afs/mydomain.com@AD.MYDOMAIN.COM: kvno =3D 5 $ aklog -d Authenticating to cell mydomain.com (server myserver). Trying to authenticate to user's realm AD.MYDOMAIN.COM. Getting tickets: afs/mydomain.com@AD.MYDOMAIN.COM Using Kerberos V5 ticket natively About to resolve name adUser to id in cell mydomain.com. Id 204 Setting tokens. adUser @ mydomain.com $ klist Ticket cache: FILE:/var/krb5/security/creds/krb5cc_204 Default principal: adUser@AD.MYDOMAIN.COM Valid starting Expires Service principal 08/24/22 12:28:35 08/24/22 22:28:35 krbtgt/AD.MYDOMAIN.COM@AD.MYDOMAIN.CO= M renew until 08/25/22 12:28:30 08/24/22 12:28:51 08/24/22 22:28:35 afs/mydomain.com@AD.MYDOMAIN.COM renew until 08/25/22 12:28:30 > There is some magic that asetkey does in terms of key version numbering > for rxkad_krb5 but it escapes me now and I suspect that's not your real > problem. I am assuming you've distributed the KeyFile to _all_ of your > AFS servers. This is the first AFS server, so there's no other servers to distribute it = to yet. # asetkey list rxkad_krb5 kvno 5 enctype 17; key is: blahblahblah rxkad_krb5 kvno 5 enctype 18; key is: blahblahblahblahblahblah All done. It seems like it's close but I'm just missing one thing... not quite sure w= hat though. Thank you so much! -Ben ________________________________ From: Ken Hornstein Sent: Wednesday, August 24, 2022 11:42 AM To: Ben Huntsman Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Kerberos + Windows >I then created the service account srvAFS, and extracted a keytab on the >Domain Controller using the following command: So I'm not the expert on how AD works, so I can't speak for what happens if you create a service account called _one_ thing and then have a different principal name. Like, what name ends up in the service ticket? But, moving on ... ># kvno adUser@AD.MYDOMAIN.COM >kvno: Server not found in Kerberos database while getting credentials for = adUser@AD.MYDOMAIN.COM kvno is used when you already have a Kerberos ticket (with kinit) and you'r= e getting a service ticket for what you give on the command line. I think what you want "kinit adUser" and the "kvno afs/mydomain.com". Although aklog should do the same thing. It would be interesting to see what the output of "klist" is after you do that kinit/kvno command sequence. There is some magic that asetkey does in terms of key version numbering for rxkad_krb5 but it escapes me now and I suspect that's not your real problem. I am assuming you've distributed the KeyFile to _all_ of your AFS servers. --Ken --_000_MWHPR0701MB3674AAE92C3BA88F0F9CB809A7739MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the reply!

> So I'm not the expert on how AD works, so I can't speak for what happe= ns

> if you create a service account called _one_ thing and then have = a

> different principal name. Like, what name ends up in the se= rvice

> ticket? But, moving on ...

I was a little fuzzy on that, but I was under the impression that in my cas= e the serivce principal for AFS has to be called "afs/mydomain.com&quo= t;. Is that not so? Therefore, one could either create an AD ac= count literally called "afs", or, let the ktpass command create a SPN for the account, and let it's name conform to local naming st= andards. Indeed we can see that the SPN is created, by running setspn= on Windows:

C:\>setspn -L srvAFS

Registered ServicePrincipalNames for CN=3DsrvAFS,OU=3DUsers,DC=3Dad,DC= =3Dmydomain,DC=3Dcom:

afs/mydomain.com

> kvno is used when you already have a Kerberos ticket (with kinit) and = you're

> getting a service ticket for what you give on the command line. &= nbsp;I think

> what you want "kinit adUser" and the "kvno afs/myd= omain.com". Although

> aklog should do the same thing.

> It would be interesting to see what the output of "klist&quo= t; is after you

> do that kinit/kvno command sequence.

$ kinit adUser

Password for adUser@AD.MYDOMAIN.COM:

$ kvno afs/mydomain.com

afs/mydomain.com@AD.MYDOMAIN.COM: kvno =3D 5

$ aklog -d

Authenticating to cell mydomain.com (server myserver).

Trying to authenticate to user's realm AD.MYDOMAIN.COM.

Getting tickets: afs/mydomain.com@AD.MYDOMAIN.COM

Using Kerberos V5 ticket natively

About to resolve name adUser to id in cell mydomain.com.

Id 204

Setting tokens. adUser @ mydomain.com

$ klist

Ticket cache: FILE:/var/krb5/security/creds/krb5cc_204

Default principal: adUser@AD.MYDOMAIN.COM

Valid starting Expires = ; Service principal

08/24/22 12:28:35 08/24/22 22:28:35 krbtgt/AD.MYDOMAIN.COM= @AD.MYDOMAIN.COM

renew until 08/25/22 12:28:30

08/24/22 12:28:51 08/24/22 22:28:35 afs/mydomain.com@AD.MY= DOMAIN.COM

renew until 08/25/22 12:28:30

> There is some magic that asetkey does in terms of key version numberin= g

> for rxkad_krb5 but it escapes me now and I suspect that's not you= r real

> problem. I am assuming you've distributed the KeyFile to _a= ll_ of your

> AFS servers.

This is the first AFS server, so there's no other servers to distribute it = to yet.

# asetkey list

rxkad_krb5 kvno 5 enctype 17; key is:= blahblahblah

rxkad_krb5 kvno 5 enctype 18; key is:= blahblahblahblahblahblah

All done.

It seems like it's close but I'm just missing one thing... not quite sure w= hat though.

Thank you so much!

-Ben

From: Ken Hornstein <ken= h@cmf.nrl.navy.mil>
Sent: Wednesday, August 24, 2022 11:42 AM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-info@openafs.org <openafs-info@openafs.org>
Subject: Re: [OpenAFS] Kerberos + Windows

>I then created the service acco= unt srvAFS, and extracted a keytab on the
>Domain Controller using the following command:

So I'm not the expert on how AD works, so I can't speak for what happens if you create a service account called _one_ thing and then have a
different principal name. Like, what name ends up in the service
ticket? But, moving on ...

># kvno adUser@AD.MYDOMAIN.COM
>kvno: Server not found in Kerberos database while getting credentials f= or adUser@AD.MYDOMAIN.COM

kvno is used when you already have a Kerberos ticket (with kinit) and you'r= e
getting a service ticket for what you give on the command line. I thi= nk
what you want "kinit adUser" and the "kvno afs/mydomain.com&= quot;. Although
aklog should do the same thing.

It would be interesting to see what the output of "klist" is afte= r you
do that kinit/kvno command sequence.

There is some magic that asetkey does in terms of key version numbering
for rxkad_krb5 but it escapes me now and I suspect that's not your real
problem. I am assuming you've distributed the KeyFile to _all_ of you= r
AFS servers.

--Ken

--_000_MWHPR0701MB3674AAE92C3BA88F0F9CB809A7739MWHPR0701MB3674_-- From kaduk@mit.edu Thu Aug 25 01:59:49 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Wed, 24 Aug 2022 17:59:49 -0700 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: References: Message-ID: <20220825005949.GN24514@kduck.mit.edu> On Wed, Aug 24, 2022 at 04:53:11PM +0000, Ben Huntsman wrote: > ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop add /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt When the name of the AFS cell does not match the name of the kerberos realm, the OpenAFS configuration needs to include a krb.conf file to specify the realm the AFS servers use for authentication. Note that this is completely different from the kerberos krb5.conf file and lives in a different location. -Ben sent from mobile From kenh@cmf.nrl.navy.mil Thu Aug 25 02:22:25 2022 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 24 Aug 2022 21:22:25 -0400 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: <20220825005949.GN24514@kduck.mit.edu> References: <20220825005949.GN24514@kduck.mit.edu> Message-ID: <202208250122.27P1MOWm021841@hedwig.cmf.nrl.navy.mil> >On Wed, Aug 24, 2022 at 04:53:11PM +0000, Ben Huntsman wrote: >> ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop a= dd /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsa= lt > >When the name of the AFS cell does not match the name of the kerberos >realm, the OpenAFS configuration needs to include a krb.conf file to >specify the realm the AFS servers use for authentication. Note that this >is completely different from the kerberos krb5.conf file and lives in a >different location. Ooof, I totally missed that. Yes, that would do it. --Ken From jaltman@auristor.com Thu Aug 25 02:49:32 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Wed, 24 Aug 2022 21:49:32 -0400 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: References: Message-ID: <887587db-c3ac-5f78-670e-e19d62fc3b48@auristor.com> This is a cryptographically signed message in MIME format. --------------ms020905080500060005060002 Content-Type: multipart/alternative; boundary="------------W2oh18fWsCn7SjCHLfotxtb0" --------------W2oh18fWsCn7SjCHLfotxtb0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/24/2022 12:53 PM, Ben Huntsman (ben@huntsmans.net) wrote: > > Here's some configuration info: > > Let's say my cell is going to be mydomain.com. My Active Directory > is ad.mydomain.com, and my AFS service account is srvAFS. When installing Active Directory for a domain "mydomain.com" it is best if the Active Directory domain is "MYDOMAIN.COM" instead of "AD.MYDOMAIN.COM". This is because Kerberos clients will attempt to use the DNS name of the host as the Kerberos realm name. The use of "AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM" naming is common only in cases where there is a pre-existing Kerberos realm for "MYDOMAIN.COM". > Here's my krb5.conf: > > [libdefaults] > default_realm = AD.MYDOMAIN.COM > default_keytab_name = FILE:/etc/krb5/krb5.keytab > dns_lookup_realm = true > dns_lookup_kdc = true > forwardable = true > > [realms] > AD.MYDOMAIN.COM = { > kdc = ad.mydomain.com:88 > admin_server = ad.mydomain.com:749 > default_domain = ad.mydomain.com > } > > [domain_realm] > .ad.mydomain.com = AD.MYDOMAIN.COM > ad.mydomain.com = AD.MYDOMAIN.COM You also need to add .mydomain.com = AD.MYDOMAIN.COM mydomain.com = AD.MYDOMAIN.COM since the Kerberos realm is not the same as the DNS domain name used for the AFS service principal. > > [logging] > kdc = FILE:/var/krb5/log/krb5kdc.log > admin_server = FILE:/var/krb5/log/kadmin.log > kadmin_local = FILE:/var/krb5/log/kadmin_local.log > default = FILE:/var/krb5/log/krb5lib.log > > > I then created the service account srvAFS, and extracted a keytab on > the Domain Controller using the following command: > > ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop > add /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL > +dumpsalt The use of "afs/mydomain.com@AD.MYDOMAIN.COM" is correct. The "afs@AD.MYDOMAIN.COM" service principal name should no longer be used and must never be used with Active Directory. > > I verified that the account did not have the "Use only Kerberos DES > encryption types for this account" box checked. I then copied the > rxkad.keytab over to the UNIX host. I built OpenAFS with a prefix of > /opt/openafs, so I put the keytab in /opt/openafs/etc/openafs/server > > I used ktutil to delete the two des entries in the keytab. ktutil > indicates that the KVNO is 5. > > I then added the keys to OpenAFS using the command: > > asetkey add rxkad_krb5 5 17 > /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com > asetkey add rxkad_krb5 5 18 > /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com For an Active Directory realm you most likely also need to add rc4-hmac, enctype 23. Did the above "asetkey" commands succeed? Since the cell is named "mydomain.com" I would expect asetkey to expand "afs/mydomain.com" to "afs/mydomain.com@MYDOMAIN.COM" which is not going to be present in the rxkad.keytab file. What is the output of "asetkey list" after the above commands were executed? > > But things aren't quite working: > > # ls /afs > afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded > (rxkad error=19270408, server 192.168.0.114) > ls: /afs: The file access permissions do not allow the specified action. > > # kvno adUser@AD.MYDOMAIN.COM > kvno: Server not found in Kerberos database while getting credentials > for adUser@AD.MYDOMAIN.COM This is not expected to work. > > # vos listvol myserver > Could not fetch the list of partitions from the server > rxk: ticket contained unknown key version number > Error in vos listvol command. > rxk: ticket contained unknown key version number 19270408 = rxk: ticket contained unknown key version number It means the OpenAFS servers are not finding the expected key entry. There is not a match for the combination of enctype and key version number and name. > # kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab > afs/mydomain.com@AD.MYDOMAIN.COM > The above command is using the afs/mydomain.com@AD.MYDOMAIN.COM keytab entry to obtain a client Ticket Granting Ticket. I doubt that is what you intended. Instead you wanted to "kinit" using a client principal and then execute the kvno command below. > # kvno afs/mydomain.com@AD.MYDOMAIN.COM > afs/mydomain.com@AD.MYDOMAIN.COM: kvno = 5 In addition to the key version number you also need to know the encryption type used to encrypt the service private portion of the afs/mydomain.com@AD.MYDOMAIN.COM service ticket. It is that encryption type which does not need to match either the encryption type used to encrypt the client private portion of the ticket or the session key which needs to match the keys added via asetkey. After adding the keys via "asetkey" did you install KeyFileExt on every server in the cell? Did you restart the services or touch the server instance of the CellServDB file to force the new keys to be loaded? > > Did I miss something, or make a mistake along the way somewhere? Ben mentions in a separate reply that the OpenAFS krb.conf file needs to be created and specify the local authentication realm as "AD.MYDOMAIN.COM". Failure to do so will prevent authorization from succeeding but would not result in a key version not found error. Jeffrey Altman --------------W2oh18fWsCn7SjCHLfotxtb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/24/2022 12:53 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Here's some configuration info:

Let's say my cell is going to be mydomain.com. My Active Directory is ad.mydomain.com, and my AFS service account is srvAFS.

When installing Active Directory for a domain "mydomain.com" it is best if the Active Directory domain is "MYDOMAIN.COM" instead of "AD.MYDOMAIN.COM". This is because Kerberos clients will attempt to use the DNS name of the host as the Kerberos realm name. The use of "AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM" naming is common only in cases where there is a pre-existing Kerberos realm for "MYDOMAIN.COM".

Here's my krb5.conf:

[libdefaults]
default_realm = AD.MYDOMAIN.COM

default_keytab_name = FILE:/etc/krb5/krb5.keytab

dns_lookup_realm = true

dns_lookup_kdc = true

forwardable = true

[realms]

AD.MYDOMAIN.COM = {

kdc = ad.mydomain.com:88

admin_server = ad.mydomain.com:749

default_domain = ad.mydomain.com

}

[domain_realm]

.ad.mydomain.com = AD.MYDOMAIN.COM

ad.mydomain.com = AD.MYDOMAIN.COM

You also need to add

.mydomain.com = AD.MYDOMAIN.COM

mydomain.com = AD.MYDOMAIN.COM

since the Kerberos realm is not the same as the DNS domain name used for the AFS service principal.

[logging]

kdc = FILE:/var/krb5/log/krb5kdc.log

admin_server = FILE:/var/krb5/log/kadmin.log

kadmin_local = FILE:/var/krb5/log/kadmin_local.log

default = FILE:/var/krb5/log/krb5lib.log

I then created the service account srvAFS, and extracted a keytab on the Domain Controller using the following command:

ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop add /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt

The use of "afs/mydomain.com@AD.MYDOMAIN.COM" is correct. The "afs@AD.MYDOMAIN.COM" service principal name should no longer be used and must never be used with Active Directory.

I verified that the account did not have the "Use only Kerberos DES encryption types for this account" box checked. I then copied the rxkad.keytab over to the UNIX host. I built OpenAFS with a prefix of /opt/openafs, so I put the keytab in /opt/openafs/etc/openafs/server

I used ktutil to delete the two des entries in the keytab. ktutil indicates that the KVNO is 5.

I then added the keys to OpenAFS using the command:

asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com

asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com

For an Active Directory realm you most likely also need to add rc4-hmac, enctype 23.

Did the above "asetkey" commands succeed? Since the cell is named "mydomain.com" I would expect asetkey to expand "afs/mydomain.com" to "afs/mydomain.com@MYDOMAIN.COM" which is not going to be present in the rxkad.keytab file.

What is the output of "asetkey list" after the above commands were executed?

But things aren't quite working:

# ls /afs
afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded (rxkad error=19270408, server 192.168.0.114)

ls: /afs: The file access permissions do not allow the specified action.

# kvno adUser@AD.MYDOMAIN.COM
kvno: Server not found in Kerberos database while getting credentials for adUser@AD.MYDOMAIN.COM

This is not expected to work.

# vos listvol myserver
Could not fetch the list of partitions from the server

rxk: ticket contained unknown key version number

Error in vos listvol command.

rxk: ticket contained unknown key version number

19270408 = rxk: ticket contained unknown key version number

It means the OpenAFS servers are not finding the expected key entry. There is not a match for the combination of enctype and key version number and name.

# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com@AD.MYDOMAIN.COM

The above command is using the afs/mydomain.com@AD.MYDOMAIN.COM keytab entry to obtain a client Ticket Granting Ticket. I doubt that is what you intended.

Instead you wanted to "kinit" using a client principal and then execute the kvno command below.

# kvno afs/mydomain.com@AD.MYDOMAIN.COM
afs/mydomain.com@AD.MYDOMAIN.COM: kvno = 5

In addition to the key version number you also need to know the encryption type used to encrypt the service private portion of the afs/mydomain.com@AD.MYDOMAIN.COM service ticket. It is that encryption type which does not need to match either the encryption type used to encrypt the client private portion of the ticket or the session key which needs to match the keys added via asetkey.

After adding the keys via "asetkey" did you install KeyFileExt on every server in the cell?

Did you restart the services or touch the server instance of the CellServDB file to force the new keys to be loaded?

Did I miss something, or make a mistake along the way somewhere?

Ben mentions in a separate reply that the OpenAFS krb.conf file needs to be created and specify the local authentication realm as "AD.MYDOMAIN.COM". Failure to do so will prevent authorization from succeeding but would not result in a key version not found error.

Jeffrey Altman

--------------W2oh18fWsCn7SjCHLfotxtb0-- --------------ms020905080500060005060002 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgyNTAx NDkzMlowLwYJKoZIhvcNAQkEMSIEINSdCJXRlMms1dG+CkIC5rnZSAUS+h8djb+jVLmzRWKD MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAGWMv M9EuUQAnpzYFRBg89GYJMtgdWJd0/F3w3CiKv82aFrEgmtuFhnSZzE+0UnkZmZV2x2nD1Dzx gIPkpYW7jSa7E4URtLXqsoTmXbV7qGZgC2DHdJd5TbDKHF+IpfZxYIiMQ1redGuhV0eWEwQm /ht+dBaTRYsNZ/fvYImSTibI4Yf9HUgkgmcozNKVTtBbcSvNoBH/JaHdcKeMqvrNBXRZk+QR Z46Q6NymNlFh0Z4BFaKSHyFc+OzMwXla3lrBc2gKBG1BnHRNfQSVFBWoor/K5GYesyKim2Du wZlNhfpnCbtqX14SFmDDbFkSIOcXPybTnwec53kZunbTHpkalQAAAAAAAA== --------------ms020905080500060005060002-- From ben@huntsmans.net Thu Aug 25 06:06:03 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Thu, 25 Aug 2022 05:06:03 +0000 Subject: [OpenAFS] Kerberos + Windows Message-ID: --_000_MWHPR0701MB3674968F973D7319C9AD3C3FA7729MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there! Thanks for the replies! I got it working!!! > In addition to the key version number you also need to know the encryptio= n type used to > encrypt the service private portion of the afs/mydomain.com@AD.MYDOMAIN.C= OM service > ticket. It is that encryption type which does not need to match either t= he encryption type > used to encrypt the client private portion of the ticket or the session k= ey which needs to > match the keys added via asetkey. Ah! This is interesting: # kinit adUser Password for adUser@AD.MYDOMAIN.COM: # klist -e Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: adUser@AD.MYDOMAIN.COM Valid starting Expires Service principal 08/24/22 21:49:12 08/25/22 07:49:12 krbtgt/AD.MYDOMAIN.COM@AD.MYDOMAIN.CO= M renew until 08/25/22 21:49:10, Etype (skey, tkt): aes256-cts-hmac-s= ha1-96, aes256-cts-hmac-sha1-96 # aklog # klist -e Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: adUser@AD.MYDOMAIN.COM Valid starting Expires Service principal 08/24/22 21:49:12 08/25/22 07:49:12 krbtgt/AD.MYDOMAIN.COM@AD.MYDOMAIN.CO= M renew until 08/25/22 21:49:10, Etype (skey, tkt): aes256-cts-hmac-s= ha1-96, aes256-cts-hmac-sha1-96 08/24/22 21:49:26 08/25/22 07:49:12 afs/mydomain.com@AD.MYDOMAIN.COM renew until 08/25/22 21:49:10, Etype (skey, tkt): arcfour-hmac, arc= four-hmac After running aklog I have one that is using arcfour-hmac. Didn't expect t= hat. I had only the AES types in my keytab, and hadn't run an asetkey for that o= ne. I had the original keytab pre-edits to remove all but the AES types, and I = brought that back over and removed only DES, leaving the arcfour-hmac one, = and then ran asetkey for it using the encryption type 23, bounced the serve= r, and it worked!! I also did end up adding in the "mydomain.com" and ".mydomain.com" entries = in krb5.conf, and I put in a file /opt/openafs/etc/openafs/server/krb.conf = with only one line that says "AD.MYDOMAIN.COM". I'm glad this all working now!! Thank you all so much for the help!! -Ben ________________________________ From: Jeffrey E Altman Sent: Wednesday, August 24, 2022 6:49 PM To: Ben Huntsman; openafs-info@openafs.org Subject: Re: [OpenAFS] Kerberos + Windows On 8/24/2022 12:53 PM, Ben Huntsman (ben@huntsmans.net) wrote: Here's some configuration info: Let's say my cell is going to be mydomain.com. My Active Directory is a= d.mydomain.com, and my AFS service account is srvAFS. When installing Active Directory for a domain "mydomain.com" it is best if = the Active Directory domain is "MYDOMAIN.COM" instead of "AD.MYDOMAIN.COM".= This is because Kerberos clients will attempt to use the DNS name of the = host as the Kerberos realm name. The use of "AD.MYDOMAIN.COM" or "WIN.MYD= OMAIN.COM" naming is common only in cases where there is a pre-existing Ker= beros realm for "MYDOMAIN.COM". Here's my krb5.conf: [libdefaults] default_realm =3D AD.MYDOMAIN.COM default_keytab_name =3D [FILE:/etc/krb5/krb5.keytab]FILE:/etc/krb5/= krb5.keytab dns_lookup_realm =3D true dns_lookup_kdc =3D true forwardable =3D true [realms] AD.MYDOMAIN.COM =3D { kdc =3D ad.mydomain.com:88 admin_server =3D ad.mydomain.com:749 default_domain =3D ad.mydomain.com } [domain_realm] .ad.mydomain.com =3D AD.MYDOMAIN.COM ad.mydomain.com =3D AD.MYDOMAIN.COM You also need to add .mydomain.com =3D AD.MYDOMAIN.COM mydomain.com =3D AD.MYDOMAIN.COM since the Kerberos realm is not the same as the DNS domain name used for th= e AFS service principal. [logging] kdc =3D [FILE:/var/krb5/log/krb5kdc.log]FILE:/var/krb5/log/krb5kdc.= log admin_server =3D [FILE:/var/krb5/log/kadmin.log]FILE:/var/krb5/log/= kadmin.log kadmin_local =3D [FILE:/var/krb5/log/kadmin_local.log]FILE:/var/krb= 5/log/kadmin_local.log default =3D [FILE:/var/krb5/log/krb5lib.log]FILE:/var/krb5/log/krb5= lib.log I then created the service account srvAFS, and extracted a keytab on the Do= main Controller using the following command: ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop add /out rxkad.keytab +rndpass /crypto = all /ptype KRB5_NT_PRINCIPAL +dumpsalt The use of "afs/mydomain.com@AD.MYDOMAIN.COM" is correct. The "afs@AD.MYDOMAIN.COM" service principal name should no longer be used and must never be us= ed with Active Directory. I verified that the account did not have the "Use only Kerberos DES encrypt= ion types for this account" box checked. I then copied the rxkad.keytab ov= er to the UNIX host. I built OpenAFS with a prefix of /opt/openafs, so I p= ut the keytab in /opt/openafs/etc/openafs/server I used ktutil to delete the two des entries in the keytab. ktutil indicate= s that the KVNO is 5. I then added the keys to OpenAFS using the command: asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com For an Active Directory realm you most likely also need to add rc4-hmac, en= ctype 23. Did the above "asetkey" commands succeed? Since the cell is named "mydoma= in.com" I would expect asetkey to expand "afs/mydomain.com" to "afs/mydomai= n.com@MYDOMAIN.COM" which is not goin= g to be present in the rxkad.keytab file. What is the output of "asetkey list" after the above commands were executed= ? But things aren't quite working: # ls /afs afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded (rxk= ad error=3D19270408, server 192.168.0.114) ls: /afs: The file access permissions do not allow the specified action. # kvno adUser@AD.MYDOMAIN.COM kvno: Server not found in Kerberos database while getting credentials for a= dUser@AD.MYDOMAIN.COM This is not expected to work. # vos listvol myserver Could not fetch the list of partitions from the server rxk: ticket contained unknown key version number Error in vos listvol command. rxk: ticket contained unknown key version number 19270408 =3D rxk: ticket contained unknown key version number It means the OpenAFS servers are not finding the expected key entry. Ther= e is not a match for the combination of enctype and key version number and = name. # kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com@A= D.MYDOMAIN.COM The above command is using the afs/mydomain.com@AD.MYDOMAIN.COM keytab entry to obtain a client Ticket Granti= ng Ticket. I doubt that is what you intended. Instead you wanted to "kinit" using a client principal and then execute the= kvno command below. # kvno afs/mydomain.com@AD.MYDOMAIN.COM afs/mydomain.com@AD.MYDOMAIN.COM: = kvno =3D 5 In addition to the key version number you also need to know the encryption = type used to encrypt the service private portion of the afs/mydomain.com@AD= .MYDOMAIN.COM service ticket. It = is that encryption type which does not need to match either the encryption = type used to encrypt the client private portion of the ticket or the sessio= n key which needs to match the keys added via asetkey. After adding the keys via "asetkey" did you install KeyFileExt on every ser= ver in the cell? Did you restart the services or touch the server instance of the CellServDB= file to force the new keys to be loaded? Did I miss something, or make a mistake along the way somewhere? Ben mentions in a separate reply that the OpenAFS krb.conf file needs to be= created and specify the local authentication realm as "AD.MYDOMAIN.COM". = Failure to do so will prevent authorization from succeeding but would not r= esult in a key version not found error. Jeffrey Altman --_000_MWHPR0701MB3674968F973D7319C9AD3C3FA7729MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there!

Thanks for the replies!

I got it working!!!

> In addition to the key version number you also need to know th= e encryption type used to

to encrypt the client private portion of the ticket or the session key w= hich needs to

> match the keys added via asetkey.<= /div>

Ah! This is interesting:

# kinit adUser

Password for adUser@AD.MYDOMAIN.COM:

# klist -e

Ticket cache: FILE:/var/krb5/security/creds/krb5c= c_0

Default principal: adUser@AD.MYDOMAIN.COM

Valid starting Expires = ; Service principal

08/24/22 21:49:12 08/25/22 07:49:12 k= rbtgt/AD.MYDOMAIN.COM@AD.MYDOMAIN.COM

renew until 08/25/22 = 21:49:10, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-= 96

# aklog

# klist -e

Ticket cache: FILE:/var/krb5/security/creds/krb5c= c_0

Default principal: adUser@AD.MYDOMAIN.COM

Valid starting Expires = ; Service principal

08/24/22 21:49:12 08/25/22 07:49:12 k= rbtgt/AD.MYDOMAIN.COM@AD.MYDOMAIN.COM

renew until 08/25/22 = 21:49:10, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-= 96

08/24/22 21:49:26 08/25/22 07:49:12 a= fs/mydomain.com@AD.MYDOMAIN.COM

renew until 08/25/22 = 21:49:10, Etype (skey, tkt): arcfour-hmac, arcfour-hmac

After running aklog I have one that is using = arcfour-hmac. Didn't expect that.

I had only the AES types in my keytab, and ha= dn't run an asetkey for that one.

I had the original keytab pre-edits to remove= all but the AES types, and I brought that back over and removed only DES, = leaving the arcfour-hmac one, and then ran asetkey for it using the encryption type 23, bounced the server, and i= t worked!!

I also did end up adding in the "mydomai= n.com" and ".mydomain.com" entries in krb5.conf, and I put i= n a file /opt/openafs/etc/openafs/server/krb.conf with only one line that says "AD.MYDOMAIN.COM". <= /div>

I'm glad this all working now!! Thank y= ou all so much for the help!!

-Ben

From: Jeffrey E Altman
Sent: Wednesday, August 24, 2022 6:49 PM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] Kerberos + Windows

On 8/24/2022 12:53 PM, Ben Huntsman (ben@hun= tsmans.net) wrote:

Here's some configuration info:

Let's say my cell is going to be mydomain.com. My Active= Directory is ad.mydomain.com, and my AFS service account is srvAFS.

= When installing Active Directory for a domain "mydomain.com" it i= s best if the Active Directory domain is "MYDOMAIN.COM" instead o= f "AD.MYDOMAIN.COM". This is because Kerberos clients will attempt to use the DNS name of the host as the Kerberos realm name. &= nbsp; The use of "AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM"= ; naming is common only in cases where there is a pre-existing Kerberos rea= lm for "MYDOMAIN.COM".

Here's my krb5.conf:

[libdefaults]
default_realm =3D AD.MYDOMAIN.COM

default_keytab_name =3D [FILE:/etc/krb5/kr= b5.keytab]FILE:/etc/krb5/krb5.keytab

dns_lookup_realm =3D true

dns_lookup_kdc =3D true

forwardable =3D true

[realms]

AD.MYDOMAIN.COM =3D {

kdc =3D ad.myd= omain.com:88

admin_server = =3D ad.mydomain.com:749

default_domain= =3D ad.mydomain.com

}

[domain_realm]

.ad.mydomain.com =3D AD.MYDOMAIN.COM

ad.mydomain.com =3D AD.MYDOMAIN.COM

You also need to add

.mydom= ain.com =3D AD.MYDOMAIN.COM

mydoma= in.com =3D AD.MYDOMAIN.COM

since the Kerberos realm = is not the same as the DNS domain name used for the AFS service principal.<= br>

[logging]

kdc =3D [FILE:/var/krb5/log/krb5kdc.log]FI= LE:/var/krb5/log/krb5kdc.log

admin_server =3D [FILE:/var/krb5/log/kadmi= n.log]FILE:/var/krb5/log/kadmin.log

kadmin_local =3D [FILE:/var/krb5/log/kadmi= n_local.log]FILE:/var/krb5/log/kadmin_local.log

default =3D [FILE:/var/krb5/log/krb5lib.lo= g]FILE:/var/krb5/log/krb5lib.log

I then created the service account srvAFS, and extracted a keytab on the Do= main Controller using the following command:

ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop add /out rxkad.= keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt

The use of "afs/mydomain.com@AD.MYDOMAIN.COM" is correct. &nb= sp; The "afs@AD.MYDOMAIN.COM" service principal name should no longer= be used and must never be used with Active Directory.

I verified that the account did not have the "Use only Kerberos DES en= cryption types for this account" box checked. I then copied the = rxkad.keytab over to the UNIX host. I built OpenAFS with a prefix of = /opt/openafs, so I put the keytab in /opt/openafs/etc/openafs/server

I used ktutil to delete the two des entries in the keytab. ktutil ind= icates that the KVNO is 5.

I then added the keys to OpenAFS using the command:

asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com

asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab af= s/mydomain.com

= For an Active Directory realm you most likely also need to add rc4-hmac, en= ctype 23.

= Did the above "asetkey" commands succeed? Since the c= ell is named "mydomain.com" I would expect asetkey to expand &quo= t;afs/mydomain.com" to "afs/mydomain.com@MYDOMAIN.COM" which is not going to be pres= ent in the rxkad.keytab file.

= What is the output of "asetkey list" after the above commands wer= e executed?

But things aren't quite working:

# ls /afs
afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded= (rxkad error=3D19270408, server 192.168.0.114)

ls: /afs: The file access permissions do not allow the specified actio= n.

# kvno adUser@AD.MYDOMAIN.COM
kvno: Server not found in Kerberos database while getting credentials for <= a href=3D"mailto:adUser@AD.MYDOMAIN.COM" target=3D"_blank" rel=3D"noopener = noreferrer" data-auth=3D"NotApplicable" class=3D"x_moz-txt-link-abbreviated= "> adUser@AD.MYDOMAIN.COM

This is not expected to work.

# vos listvol myserver
Could not fetch the list of partitions from the server

rxk: ticket contained unknown key version number

Error in vos listvol command.

rxk: ticket contained unknown key version number

19270408 =3D rxk: ticket = contained unknown key version number

It means the OpenAFS serv= ers are not finding the expected key entry. There is not a matc= h for the combination of enctype and key version number and name.

# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com@AD.MYDOMAIN.COM

The above command is usin= g the afs/mydomain.com@AD.MYDOMAIN.COM keytab entry to obtain a client Ticket= Granting Ticket. I doubt that is what you intended.

Instead you wanted to &qu= ot;kinit" using a client principal and then execute the kvno command b= elow.

# kvno afs/mydomain.com@AD.MYDOMAIN.COM
afs/mydomain.com@AD.MYDOMAIN.COM: kvno =3D 5

= In addition to the key version number you also need to know the encryption = type used to encrypt the service private portion of the afs/mydomain.com@AD.MYDOMAIN.COM service ticket. It is that encry= ption type which does not need to match either the encryption type used to = encrypt the client private portion of the ticket or the session key which n= eeds to match the keys added via asetkey.

= After adding the keys via "asetkey" did you install KeyFileExt on= every server in the cell?

= Did you restart the services or touch the server instance of the CellServDB= file to force the new keys to be loaded?

Did I miss something, or make a mistake along the way somewhere?

= Ben mentions in a separate reply that the OpenAFS krb.conf file needs to be= created and specify the local authentication realm as "AD.MYDOMAIN.CO= M". Failure to do so will prevent authorization from succeeding but would not result in a key version not found error.

Jeffrey Altman

--_000_MWHPR0701MB3674968F973D7319C9AD3C3FA7729MWHPR0701MB3674_-- From Richard.Brittain@dartmouth.edu Fri Aug 26 16:11:26 2022 From: Richard.Brittain@dartmouth.edu (Richard Brittain) Date: Fri, 26 Aug 2022 15:11:26 +0000 Subject: [OpenAFS] Kerberos + Windows In-Reply-To: <202208250122.27P1MOWm021841@hedwig.cmf.nrl.navy.mil> References: <20220825005949.GN24514@kduck.mit.edu> <202208250122.27P1MOWm021841@hedwig.cmf.nrl.navy.mil> Message-ID: --_000_BL1PR03MB619813EA18BF8581F216C1D39E759BL1PR03MB6198namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The service principal details are fuzzy now =96 we haven=92t touched them i= n a long time =96 but we use a krb.conf to specify two authentication realm= s, neither of which matches the cell name. MIT KDC and Active Directory, w= ith non-overlapping principal names. It works great, and the only issue ge= tting it set up was explaining to the AD Domain admins why we needed this s= trange afs/mydomain.com@AD.MYDOMAIN.COM entry, and get them to promise not to expire it like other special se= rvice accounts we have. Richard From: openafs-info-admin@openafs.org on be= half of Ken Hornstein Date: Wednesday, August 24, 2022 at 9:22 PM To: Benjamin Kaduk Cc: Ben Huntsman , openafs-info@openafs.org Subject: Re: [OpenAFS] Kerberos + Windows >On Wed, Aug 24, 2022 at 04:53:11PM +0000, Ben Huntsman wrote: >> ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop ad= d /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt > >When the name of the AFS cell does not match the name of the kerberos >realm, the OpenAFS configuration needs to include a krb.conf file to >specify the realm the AFS servers use for authentication. Note that this >is completely different from the kerberos krb5.conf file and lives in a >different location. Ooof, I totally missed that. Yes, that would do it. --Ken _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info --_000_BL1PR03MB619813EA18BF8581F216C1D39E759BL1PR03MB6198namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The service princip= al details are fuzzy now =96 we haven=92t touched them in a long time =96 b= ut we use a krb.conf to specify two authentication realms, neither of which= matches the cell name. MIT KDC and Active Directory, with non-overlapping principal names. It works great, and= the only issue getting it set up was explaining to the AD Domain admins wh= y we needed this strange afs/mydomain.com@AD.MYDOMAIN.COM entry, and get them t= o promise not to expire it like other special service accounts we have.

Richard

From: openafs-info-admin@= openafs.org <openafs-info-admin@openafs.org> on behalf of Ken Hornste= in <kenh@cmf.nrl.navy.mil>
Date: Wednesday, August 24, 2022 at 9:22 PM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Ben Huntsman <ben@huntsmans.net>, openafs-info@openafs.org= <openafs-info@openafs.org>
Subject: Re: [OpenAFS] Kerberos + Windows

>On Wed, Aug 24,= 2022 at 04:53:11PM +0000, Ben Huntsman wrote:
>> ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /ma= pop add /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +du= mpsalt
>
>When the name of the AFS cell does not match the name of the kerberos >realm, the OpenAFS configuration needs to include a krb.conf file to >specify the realm the AFS servers use for authentication. Note th= at this
>is completely different from the kerberos krb5.conf file and lives in a=
>different location.

Ooof, I totally missed that. Yes, that would do it.

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

--_000_BL1PR03MB619813EA18BF8581F216C1D39E759BL1PR03MB6198namp_-- From inguin@gmx.de Fri Aug 26 22:13:40 2022 From: inguin@gmx.de (Ingo van Lil) Date: Fri, 26 Aug 2022 23:13:40 +0200 Subject: [OpenAFS] Limiting mount point to known cells Message-ID: Hello OpenAFS experts, is there any way to run an AFS client with both the -dynroot and -afsdb options, but still limit the /afs mount point to known cells (specifically: only my home cell)? Longer explanation of my problem: When I run "git status" somewhere inside the AFS hierarchy it freezes for a minute or two. git tries to access the directory /afs/.git, and I see that afsd sends multiple DNS requests to the loopback address 127.0.0.53. Not sure why it does that, it seems to be somehow related to systemd-resolved in Fedora Linux. Running without -dynroot solves the issue, but according to the manual it will keep my machine from booting in case my home cell can't be contacted. Not very attractive. Running without -afsdb solves the issue. That's what I do now, but it requires to manually specify the servers for my home cell in CellServDB. Ideally I'd like to get that info from DNS. Thanks in advance for any advice you can give! Regards, Ingo From jaltman@auristor.com Sat Aug 27 03:13:53 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Fri, 26 Aug 2022 22:13:53 -0400 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: References: Message-ID: <703060a1-3052-7ef2-e926-97af472ae710@auristor.com> This is a cryptographically signed message in MIME format. --------------ms080700060202060509000703 Content-Type: multipart/alternative; boundary="------------P0k01Cv2W0aprnLJHufecRMN" --------------P0k01Cv2W0aprnLJHufecRMN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/26/2022 5:13 PM, Ingo van Lil (inguin@gmx.de) wrote: > Hello OpenAFS experts, > > is there any way to run an AFS client with both the -dynroot and -afsdb > options, but still limit the /afs mount point to known cells > (specifically: only my home cell)? There is no explicit support for this behavior in OpenAFS but you might be able to approximate it by * enabling -dynroot * disabling -afsdb * removing the OpenAFS distributed CellServDB file * creating a CellServDB file contain only one line for the cell and no servers >my.cell # My personal cell A cell entry with no servers is an implicit request to lookup the servers via DNS. I do not remember if this works with -afsdb disabled but it might. > > Longer explanation of my problem: > > When I run "git status" somewhere inside the AFS hierarchy it freezes > for a minute or two. git tries to access the directory /afs/.git, and I > see that afsd sends multiple DNS requests to the loopback address > 127.0.0.53. Not sure why it does that, it seems to be somehow related to > systemd-resolved in Fedora Linux. > > Running without -dynroot solves the issue, but according to the manual > it will keep my machine from booting in case my home cell can't be > contacted. Not very attractive. > > Running without -afsdb solves the issue. That's what I do now, but it > requires to manually specify the servers for my home cell in CellServDB. > Ideally I'd like to get that info from DNS. > > Thanks in advance for any advice you can give! > > Regards, > Ingo > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------P0k01Cv2W0aprnLJHufecRMN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/26/2022 5:13 PM, Ingo van Lil (inguin@gmx.de) wrote:

Hello OpenAFS experts,

is there any way to run an AFS client with both the -dynroot and -afsdb
options, but still limit the /afs mount point to known cells
(specifically: only my home cell)?

There is no explicit support for this behavior in OpenAFS but you might be
able to approximate it by

enabling -dynroot
disabling -afsdb
removing the OpenAFS distributed CellServDB file
creating a CellServDB file contain only one line for the cell and no servers
>my.cell # My personal cell

A cell entry with no servers is an implicit request to lookup the servers via DNS.
I do not remember if this works with -afsdb disabled but it might.

Longer explanation of my problem:

When I run "git status" somewhere inside the AFS hierarchy it freezes
for a minute or two. git tries to access the directory /afs/.git, and I
see that afsd sends multiple DNS requests to the loopback address
127.0.0.53. Not sure why it does that, it seems to be somehow related to
systemd-resolved in Fedora Linux.

Running without -dynroot solves the issue, but according to the manual
it will keep my machine from booting in case my home cell can't be
contacted. Not very attractive.

Running without -afsdb solves the issue. That's what I do now, but it
requires to manually specify the servers for my home cell in CellServDB.
Ideally I'd like to get that info from DNS.

Thanks in advance for any advice you can give!

Regards,
Ingo

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

--------------P0k01Cv2W0aprnLJHufecRMN-- --------------ms080700060202060509000703 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgyNzAy MTM1M1owLwYJKoZIhvcNAQkEMSIEIOyacGn4dWTnUHVYI7dUp8VTN6cbF/aUzNECQXAFwYGj MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAD0G4 jyh6i5j1GSh7XugLnjUmzsiUEjrjqoaw+8kM/xpHyvCQ8BagyFkrl+pWGoT116uFz3dZ5qTb WTo6wCs6K+VyM/a9hr5tvzYBmV1ZhlwYhbsdPG1Wqqdh0PVtaiVhmz3Rlf2enX/01DVbbbA1 zLtzGygoJbTnN6ly1mk1Raiq77q/HhRNz2/aVqxC+HBTKL4oZiaPOZrqq3iZWe9jhWvOq6vy Q9OzAFppefe3sa0dzdbrY1AM9uhkfg2b8ulBABPjYTCBkFASltNP7p+SeqFagklpONd15Lpv MwJmX+8igJxXKTCRJyzDZnCFiL2gc8IVKn2OTjQvlYyd8A7pPQAAAAAAAA== --------------ms080700060202060509000703-- From kostas@physics.auth.gr Sat Aug 27 06:56:32 2022 From: kostas@physics.auth.gr (Kostas Liakakis) Date: Sat, 27 Aug 2022 08:56:32 +0300 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: References: Message-ID: <3189a164-b1f7-6ffc-c2cc-5c516c4ac3d5@physics.auth.gr> Hi, There was a thread about /afs/.git hanging back in 2014 which ended up with a work around from Jonathan Billings: https://lists.openafs.org/pipermail/openafs-info/2014-August/040888.html Basically, he suggested setting GIT_CEILING_DIRECTORIES ( https://git-scm.com/docs/git/2.35.2#Documentation/git.txt-codeGITCEILINGDIRECTORIEScode ) environmental variable and limit git's search. In the same thread, a blacklist (or whitelist) of cell names was suggested to prevent afsdb queries for troublesome domains but it seems it never got implemented. -K. On 27/08/2022 00.13, Ingo van Lil wrote: > Hello OpenAFS experts, > > is there any way to run an AFS client with both the -dynroot and -afsdb > options, but still limit the /afs mount point to known cells > (specifically: only my home cell)? > > Longer explanation of my problem: > > When I run "git status" somewhere inside the AFS hierarchy it freezes > for a minute or two. git tries to access the directory /afs/.git, and I > see that afsd sends multiple DNS requests to the loopback address > 127.0.0.53. Not sure why it does that, it seems to be somehow related to > systemd-resolved in Fedora Linux. > > Running without -dynroot solves the issue, but according to the manual > it will keep my machine from booting in case my home cell can't be > contacted. Not very attractive. > > Running without -afsdb solves the issue. That's what I do now, but it > requires to manually specify the servers for my home cell in CellServDB. > Ideally I'd like to get that info from DNS. > > Thanks in advance for any advice you can give! > > Regards, > Ingo > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From haba@kth.se Sat Aug 27 09:34:07 2022 From: haba@kth.se (Harald Barth) Date: Sat, 27 Aug 2022 10:34:07 +0200 (CEST) Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: <3189a164-b1f7-6ffc-c2cc-5c516c4ac3d5@physics.auth.gr> References: <3189a164-b1f7-6ffc-c2cc-5c516c4ac3d5@physics.auth.gr> Message-ID: <20220827.103407.479232719070754180.haba@habil.stacken.kth.se> > In the same thread, a blacklist (or whitelist) of cell names was > suggested to prevent afsdb queries for troublesome domains but it > seems it never got implemented. If the blacklist specification is visible and not hidden in some new magic file, I think that would be good. My suggestion would be to add the possibility to specify this in CellServDB. >git BLACKLIST or something like that. Because then anyone who wants a cell named "git" (you never know the users' wishes) would see this when looking through CellServDB to determine why it does not work as expected. I am normally not for blacklists, but what can you do? But wait a moment... Can't we assume that all cell names that we ask in DNS contain at least one dot "." in the middle? I doubt that there are AFS cells named without dot that we need to resolve with DNS. What do you think about that? Harald. From erude1@umbc.edu Sat Aug 27 16:46:34 2022 From: erude1@umbc.edu (Ed Rude) Date: Sat, 27 Aug 2022 11:46:34 -0400 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: <703060a1-3052-7ef2-e926-97af472ae710@auristor.com> References: <703060a1-3052-7ef2-e926-97af472ae710@auristor.com> Message-ID: --0000000000000b6ca205e73af085 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have faced similar issues at times. If you like everything about the current behavior of AFS aside from the impact it can have on git you might attack it from the git side. Maybe there is a way to stop git from recursing all the way to /afs/ ? Similar solutions have worked for me with things other than git. You probably don=E2=80=99t want git to check that di= rectory anyway, even if you can make it happen much faster. Ed On Fri, Aug 26, 2022 at 22:14 Jeffrey E Altman wrote= : > On 8/26/2022 5:13 PM, Ingo van Lil (inguin@gmx.de) wrote: > > Hello OpenAFS experts, > > is there any way to run an AFS client with both the -dynroot and -afsdb > options, but still limit the /afs mount point to known cells > (specifically: only my home cell)? > > There is no explicit support for this behavior in OpenAFS but you might b= e > able to approximate it by > > - enabling -dynroot > - disabling -afsdb > - removing the OpenAFS distributed CellServDB file > - creating a CellServDB file contain only one line for the cell and no > servers > >my.cell # My personal cell > > A cell entry with no servers is an implicit request to lookup the servers > via DNS. > I do not remember if this works with -afsdb disabled but it might. > > > Longer explanation of my problem: > > When I run "git status" somewhere inside the AFS hierarchy it freezes > for a minute or two. git tries to access the directory /afs/.git, and I > see that afsd sends multiple DNS requests to the loopback address > 127.0.0.53. Not sure why it does that, it seems to be somehow related to > systemd-resolved in Fedora Linux. > > Running without -dynroot solves the issue, but according to the manual > it will keep my machine from booting in case my home cell can't be > contacted. Not very attractive. > > Running without -afsdb solves the issue. That's what I do now, but it > requires to manually specify the servers for my home cell in CellServDB. > Ideally I'd like to get that info from DNS. > > Thanks in advance for any advice you can give! > > Regards, > Ingo > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Edward A. Rude Systems Administrator - Unix Systems Division of Information Technology --0000000000000b6ca205e73af085 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have faced similar issues at times. If you like everyth= ing about the current behavior of AFS aside from the impact it can have on = git you might attack it from the git side. Maybe there is a way to stop git= from recursing all the way to /afs/ ? Similar solutions have worked for me= with things other than git. You probably don=E2=80=99t want git to check t= hat directory anyway, even if you can make it happen much faster.=C2=A0

Ed=C2=A0

On Fri, Au= g 26, 2022 at 22:14 Jeffrey E Altman <jaltman@auristor.com> wrote:

=20 =20 =20

On 8/26/2022 5:13 PM, Ingo van Lil (inguin@gmx.de) wrote:

Hello OpenAFS experts,

is there any way to run an AFS client with both the -dynroot and -afsdb
options, but still limit the /afs mount point to known cells
(specifically: only my home cell)?

There is no explicit support for this behavior in OpenAFS but you might be
able to approximate it by

enabling -dynroot

disabling -afsdb

removing the OpenAFS distributed CellServDB file

creating a CellServDB file contain only one line for the cell and no servers
>my.cell # My personal cell

A cell entry with no servers is an implicit request to lookup the servers via DNS.=C2=A0
I do not remember if this works with -afsdb disabled but it might.

Longer explanation of my problem:

When I run "git status" somewhere inside the AFS hierarchy = it freezes
for a minute or two. git tries to access the directory /afs/.git, and I
see that afsd sends multiple DNS requests to the loopback address
127.0.0.53. Not sure why it does that, it seems to be somehow related to
systemd-resolved in Fedora Linux.

Running without -dynroot solves the issue, but according to the manual
it will keep my machine from booting in case my home cell can't b= e
contacted. Not very attractive.

Running without -afsdb solves the issue. That's what I do now, bu= t it
requires to manually specify the servers for my home cell in CellServDB.
Ideally I'd like to get that info from DNS.

Thanks in advance for any advice you can give!

Regards,
Ingo

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

Edward A. Rude
Syste= ms Administrator - Unix Systems
Division of Information Technology

<= img src=3D"https://docs.google.com/uc?export=3Ddownload&id=3D1sDR2npAzb= Dyq-hkIWpERgZfXnS4NUNno&revid=3D0B0sQLLgSRdtncmxTRHBKVU4vZmJHT2c2dHZRRU= 8vTldsZmlJPQ" width=3D"96" height=3D"20" style=3D"color:rgb(136,136,136)"><= /div>

--0000000000000b6ca205e73af085-- From jaltman@auristor.com Sun Aug 28 03:59:49 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sat, 27 Aug 2022 22:59:49 -0400 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: <20220827.103407.479232719070754180.haba@habil.stacken.kth.se> References: <3189a164-b1f7-6ffc-c2cc-5c516c4ac3d5@physics.auth.gr> <20220827.103407.479232719070754180.haba@habil.stacken.kth.se> Message-ID: This is a cryptographically signed message in MIME format. --------------ms020309090404020507040704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/27/2022 4:34 AM, Harald Barth (haba@kth.se) wrote: > > But wait a moment... Can't we assume that all cell names that we > ask in DNS contain at least one dot "." in the middle? I doubt > that there are AFS cells named without dot that we need to > resolve with DNS. What do you think about that? Please keep in mind that /afs/.git might be a cell whose alias is "git" or that "git" is to be combined with a domain in the DNS search list. I seem to remember seeing many paths of the form /afs/cs/ or /afs/ece/ where the full cell names were cs.cmu.edu or ece.cmu.edu. A question for the original poster is "what are the DNS queries that are being issued to the DNS resolver at 127.0.0.53? Jeffrey Altman --------------ms020309090404020507040704 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgyODAy NTk0OVowLwYJKoZIhvcNAQkEMSIEIAKnZwxx9v6Qd30qviiUZiacSwdhMuhTiD5c74vMlN7y MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAZALW NQJyYX8IuaZ+QuWDMlUjCbiwYWyTqhH22wJUS1uE7Vb85oY82Yx2/q8Eup1wawa1n1q0OKH4 7uA64vyrseW6qN5qauS4yO4u2FxZUzFIy8FLc8WxN6mVmDSKcdP4OavDUUTBLSccI582EqaM QjbpCAyVNC+voOCNDg6mfm4U0Y0M+nnPGU7o2sKNEBYsXAN8EVHu1EnC2l88kyrFnRD0ikME +6eA+hs8IFXqggmK87OFHfWE+ikJJ6jDMfkAHbrt2KN0BGhPOSxjcCb4A9RhD/Y67Elnmosh bPFImWrBA/+8GDfY9Nuh8P0eqHsMm2vA9AsIW0lq6EXXrYMhwgAAAAAAAA== --------------ms020309090404020507040704-- From jukka.tuominen@finndesign.fi Sun Aug 28 08:14:14 2022 From: jukka.tuominen@finndesign.fi (jukka.tuominen@finndesign.fi) Date: Sun, 28 Aug 2022 10:14:14 +0300 Subject: [OpenAFS] OpenAFS with GDM in Ubuntu 22.04 (or 20.04)? Message-ID: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> Hi all, I wonder if anybody has OpenAFS client working with GDM in Ubuntu 22.04 (or 20.04)? That is, allowing users to log into their homedirs graphically. I have an old virtualised setup that still works beautifully, however, several OS-version upgrades breaks it and I haven't been able to build one from a new installation either. I've spent so much time googling and tweaking without luck. And in addition to have it convenient for the users, I'd very much like it to safe and secure from the administrator's point of view. Having the pam settings all over the place doesn't seem to be the right path. I would very much appreciate any pointers to installation steps and/or working configurations etc. br, jukka From dirk.heinrichs@altum.de Sun Aug 28 08:54:04 2022 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Sun, 28 Aug 2022 09:54:04 +0200 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: References: Message-ID: <279e31f3-5870-8f91-0e32-44b2618598e0@altum.de> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------EAtxpJrwCHKaAOO0nvQIQJb6 Content-Type: multipart/mixed; boundary="------------rX68inXEojmTsDEHFLn9CpNT"; protected-headers="v1" From: Dirk Heinrichs To: openafs-info@openafs.org Message-ID: <279e31f3-5870-8f91-0e32-44b2618598e0@altum.de> Subject: Re: [OpenAFS] Limiting mount point to known cells References: In-Reply-To: --------------rX68inXEojmTsDEHFLn9CpNT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SW5nbyB2YW4gTGlsOg0KDQo+IGdpdCB0cmllcyB0byBhY2Nlc3MgdGhlIGRpcmVjdG9yeSAv YWZzLy5naXQsIGFuZCBJDQo+IHNlZSB0aGF0IGFmc2Qgc2VuZHMgbXVsdGlwbGUgRE5TIHJl cXVlc3RzIHRvIHRoZSBsb29wYmFjayBhZGRyZXNzDQo+IDEyNy4wLjAuNTMuIE5vdCBzdXJl IHdoeSBpdCBkb2VzIHRoYXQsIGl0IHNlZW1zIHRvIGJlIHNvbWVob3cgcmVsYXRlZCB0bw0K PiBzeXN0ZW1kLXJlc29sdmVkIGluIEZlZG9yYSBMaW51eC4NCg0KWWVzLCBzeXN0ZW1kLXJl c29sdmVkIHByb3ZpZGVzIGEgbG9jYWwgY2FjaGluZyBETlMgc2VydmVyIG9uIHRoYXQgDQph ZGRyZXNzIGFuZCBjb25maWd1cmVzIC9ldGMvcmVzb2x2LmNvbmYgKGJ5IHN5bWxpbmtpbmcg aXQgdG8gaXRzIG93biANCmZpbGUgaW4gL3J1bikgdG8gdXNlIGl0Lg0KDQpIVEguLi4NCg0K IMKgwqDCoCBEaXJrDQoNCi0tIA0KRGlyayBIZWlucmljaHMgPGRpcmsuaGVpbnJpY2hzQGFs dHVtLmRlPg0KTWF0cml4LUFkcmVzc2U6IEBoZWluaTpjaGF0LmFsdHVtLmRlDQpHUEcgUHVi bGljIEtleTogODBGMTU0MEUwM0EzOTY4RjNENzlDMzgyODUzQzMyQzQyN0I0ODA0OQ0KUHJp dmFjeSBIYW5kYnVjaDogaHR0cHM6Ly93d3cucHJpdmFjeS1oYW5kYnVjaC5kZQ0KDQo= --------------rX68inXEojmTsDEHFLn9CpNT-- --------------EAtxpJrwCHKaAOO0nvQIQJb6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQBbRZ091iOtChJXdXJlzdNRFS0TAUCYwsfHQAKCRDJlzdNRFS0 TMS8AP46NGegu22MymSvVwmF4rQjXBjx3bE5LSBcxWQ51rRqfgD/fNxrTfdXmfT1 o/FmuPazJlGzquEEcqfpGeZhU2nnSAc= =KCxj -----END PGP SIGNATURE----- --------------EAtxpJrwCHKaAOO0nvQIQJb6-- From dirk.heinrichs@altum.de Sun Aug 28 08:59:59 2022 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Sun, 28 Aug 2022 09:59:59 +0200 Subject: [OpenAFS] OpenAFS with GDM in Ubuntu 22.04 (or 20.04)? In-Reply-To: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> References: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> Message-ID: <07739e00-d435-5d1b-e763-652c3d58cc15@altum.de> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------v0eAI0KxYU0W5BUbAF5IZ00p Content-Type: multipart/mixed; boundary="------------ldLt0PI0Z94iioE9jXsi4xjT"; protected-headers="v1" From: Dirk Heinrichs To: openafs-info@openafs.org Message-ID: <07739e00-d435-5d1b-e763-652c3d58cc15@altum.de> Subject: Re: [OpenAFS] OpenAFS with GDM in Ubuntu 22.04 (or 20.04)? References: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> In-Reply-To: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> --------------ldLt0PI0Z94iioE9jXsi4xjT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 anVra2EudHVvbWluZW5AZmlubmRlc2lnbi5maToNCg0KPiBJIHdvbmRlciBpZiBhbnlib2R5 IGhhcyBPcGVuQUZTIGNsaWVudCB3b3JraW5nIHdpdGggR0RNIGluIFVidW50dSANCj4gMjIu MDQgKG9yIDIwLjA0KT8gVGhhdCBpcywgYWxsb3dpbmcgdXNlcnMgdG8gbG9nIGludG8gdGhl aXIgaG9tZWRpcnMgDQo+IGdyYXBoaWNhbGx5Lg0KDQpZb3UgY2FuJ3QuIE1vc3Qgb2YgdGhl IEdub21lIHN0dWZmIG5vd2FkYXlzIGhlYXZpbHkgZGVwZW5kcyBvbiBzeXN0ZW1jdGwgDQot LXVzZXIgd2hpY2ggZG9lc24ndCB3b3JrIHdoZW4gJEhPTUUgaXMgaW4gL2FmcyAoYmVjYXVz ZSBzeXN0ZW1kIHN0YXJ0cyANCnRoZSBzeXN0ZW1jdGwgLS11c2VyIHNlcGFyYXRlIGZyb20g dGhlIHVzZXIgc2Vzc2lvbiBhbmQgdGh1cyBpdCBkb2Vzbid0IA0KZ2V0IGEgdG9rZW4gYXQg bG9naW4pLiBVbmZvcnR1bmF0ZWx5LCBzeXN0ZW1kIGZvbGtzIGFyZSBub3Qgd2lsbGluZyB0 byANCmZpeCB0aGlzIG5vbnNlbnNlLg0KDQpTRERNIHdvcmtzIGZpbmUsIHRob3VnaC4NCg0K SFRILi4uDQoNCiDCoMKgwqAgRGlyaw0KDQotLSANCkRpcmsgSGVpbnJpY2hzIDxkaXJrLmhl aW5yaWNoc0BhbHR1bS5kZT4NCk1hdHJpeC1BZHJlc3NlOiBAaGVpbmk6Y2hhdC5hbHR1bS5k ZQ0KR1BHIFB1YmxpYyBLZXk6IDgwRjE1NDBFMDNBMzk2OEYzRDc5QzM4Mjg1M0MzMkM0MjdC NDgwNDkNClByaXZhY3kgSGFuZGJ1Y2g6IGh0dHBzOi8vd3d3LnByaXZhY3ktaGFuZGJ1Y2gu ZGUNCg0K --------------ldLt0PI0Z94iioE9jXsi4xjT-- --------------v0eAI0KxYU0W5BUbAF5IZ00p Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQBbRZ091iOtChJXdXJlzdNRFS0TAUCYwsgfwAKCRDJlzdNRFS0 TKrgAP9xsrIxY5bbIg3oGzSqB7xIDap36AA86fSz5jsmqPtNfwEAn255YXpx9Lj6 3JLsd6s2L8lwl/3mAP413D6e60ghUQ8= =GKMy -----END PGP SIGNATURE----- --------------v0eAI0KxYU0W5BUbAF5IZ00p-- From jukka.tuominen@finndesign.fi Sun Aug 28 13:47:59 2022 From: jukka.tuominen@finndesign.fi (jukka.tuominen@finndesign.fi) Date: Sun, 28 Aug 2022 15:47:59 +0300 Subject: [OpenAFS] OpenAFS with GDM in Ubuntu 22.04 (or 20.04)? In-Reply-To: <07739e00-d435-5d1b-e763-652c3d58cc15@altum.de> References: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> <07739e00-d435-5d1b-e763-652c3d58cc15@altum.de> Message-ID: Thank you Dirk, sad to hear, but at least I know now not to waste more time banging my head against the wall. SDDM is new to me, I'll look into it. br, jukka Dirk Heinrichs kirjoitti 2022-08-28 10:59: > jukka.tuominen@finndesign.fi: > >> I wonder if anybody has OpenAFS client working with GDM in Ubuntu >> 22.04 (or 20.04)? That is, allowing users to log into their homedirs >> graphically. > > You can't. Most of the Gnome stuff nowadays heavily depends on > systemctl --user which doesn't work when $HOME is in /afs (because > systemd starts the systemctl --user separate from the user session and > thus it doesn't get a token at login). Unfortunately, systemd folks > are not willing to fix this nonsense. > > SDDM works fine, though. > > HTH... > > Dirk From jaltman@auristor.com Mon Aug 29 01:05:20 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sun, 28 Aug 2022 20:05:20 -0400 Subject: [OpenAFS] OpenAFS with GDM in Ubuntu 22.04 (or 20.04)? In-Reply-To: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> References: <1e5422a892a5b8d6ebc15ac230aedd46@finndesign.fi> Message-ID: <50b7762c-bdd6-acf3-016c-644f8f5ae383@auristor.com> This is a cryptographically signed message in MIME format. --------------ms050109050505000008080807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/28/2022 3:14 AM, jukka.tuominen@finndesign.fi wrote: > Hi all, > > I wonder if anybody has OpenAFS client working with GDM in Ubuntu > 22.04 (or 20.04)? That is, allowing users to log into their homedirs > graphically. The underlying problem is that GDM heavily relies upon processes launched as children of "systemd --user" services. As a result they do not share the same session keyring as the child processes of login. The "systemd --user" expectation is that all processes executing as a "uid" have access to the same authentication credentials whether they be local or remote. In such an environment, AFS Process Authentication Groups (PAGs) cannot be created as a side-effect of login. Modify the pam configuration to disable PAG creation for GDM logins. If the expectation is that "sshd" logins should be separate from the desktop, then "sshd" logins can continue to create a PAG. Sincerely, Jeffrey Altman --------------ms050109050505000008080807 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 ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgyOTAw MDUyMFowLwYJKoZIhvcNAQkEMSIEIPXNdxdx2vrsf/ehjC2WxMB/qeZupxm4mkqR68fRMJMX MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAh7kG A6MZ8PBos7qOvhynvhlG+I5wLBanhqWmAkRqvjLosXi6WBmjwfO6PCw3NYQgt1CQDAW6yrlK yQD1Y/fgleuhZDSIhluypXosUMF6fQIHfNjoERuC8htR7dLEGGMoV4Noh3gk3jkUQ1YlKsYu vWzhTIkF2eqRodahQFA1vPr5xwFVh0bA4iDx5/EymmHo7DUYViB1nKjY8rOQQbaOyJR7D0/i l9lcYx0iPqOekCjYMumVi/DDS6i/YJjeFIBBEDRfCTf/0MLtZbasRdOUrqaMUL8AMExJaehJ TIT/GcP++nv81UHbl2TQL02GHy4kbvZcOInEGBIJg9y4e3uytwAAAAAAAA== --------------ms050109050505000008080807-- From haba@kth.se Mon Aug 29 09:41:53 2022 From: haba@kth.se (Harald Barth) Date: Mon, 29 Aug 2022 10:41:53 +0200 (CEST) Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: References: <3189a164-b1f7-6ffc-c2cc-5c516c4ac3d5@physics.auth.gr> <20220827.103407.479232719070754180.haba@habil.stacken.kth.se> Message-ID: <20220829.104153.1024746009520907996.haba@habil.stacken.kth.se> > I seem to remember seeing many paths of the form /afs/cs/ or /afs/ece/ > where the full cell names were cs.cmu.edu or ece.cmu.edu. But probably "ece" was entered into CellServDB and not into DNS. Harald. From inguin@gmx.de Mon Aug 29 09:59:18 2022 From: inguin@gmx.de (Ingo van Lil) Date: Mon, 29 Aug 2022 10:59:18 +0200 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: References: <703060a1-3052-7ef2-e926-97af472ae710@auristor.com> Message-ID: On 8/27/22 17:46, Ed Rude wrote: > I have faced similar issues at times. If you like everything about the > current behavior of AFS aside from the impact it can have on git you > might attack it from the git side. Maybe there is a way to stop git from > recursing all the way to /afs/ ? As Kostas suggested (thanks!), setting GIT_CEILING_DIRECTORIES=3D/afs will stop git from trying to access /afs/.git. That clearly seems like a good idea. But then I'd need to find similar solutions for Mercurial (looking for /afs/.hg), Bazaar (/afs/.bzr) and Subversion (/afs/.svn). I'm using one of those fancy shell prompts that tries to display VCS information whenever I'm inside a working copy. Regards, Ingo From inguin@gmx.de Mon Aug 29 10:24:11 2022 From: inguin@gmx.de (Ingo van Lil) Date: Mon, 29 Aug 2022 11:24:11 +0200 Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: <279e31f3-5870-8f91-0e32-44b2618598e0@altum.de> References: <279e31f3-5870-8f91-0e32-44b2618598e0@altum.de> Message-ID: <43cb28f4-a879-1914-9081-cde90d5ab7ee@gmx.de> On 8/28/22 09:54, Dirk Heinrichs wrote: > Yes, systemd-resolved provides a local caching DNS server on that > address and configures /etc/resolv.conf (by symlinking it to its own > file in /run) to use it. Yep, that's it. Still not sure where the delay comes from, though. With tcpdump I see that most requests are immediately answered with "no such domain". The only exception are AFSDB? requests for top-level domains -- those seem to take up to four seconds: 10:45:43.637524 IP localhost.58442 > localhost.domain: 57292+ [1au] AFSDB? git. (32) 10:45:47.131635 IP localhost.domain > localhost.58442: 57292 NXDomain* 0/0/1 (32) Multiply that with retries and other VCS and the whole delay blows up to a minute. Regards, Ingo From haba@kth.se Mon Aug 29 12:43:00 2022 From: haba@kth.se (Harald Barth) Date: Mon, 29 Aug 2022 13:43:00 +0200 (CEST) Subject: [OpenAFS] Limiting mount point to known cells In-Reply-To: <43cb28f4-a879-1914-9081-cde90d5ab7ee@gmx.de> References: <279e31f3-5870-8f91-0e32-44b2618598e0@altum.de> <43cb28f4-a879-1914-9081-cde90d5ab7ee@gmx.de> Message-ID: <20220829.134300.719246118027964576.haba@habil.stacken.kth.se> I would look for the AFSDB RR DNS lookup in the code and somehow prevent that names without dot in the middle are looked up - just fail it. But there are folks who are much more familiar with the code that me. Harald.