From t_granat@hotmail.com Sun Jun 1 11:59:25 2014 From: t_granat@hotmail.com (Tomas Granat) Date: Sun, 1 Jun 2014 10:59:25 +0000 Subject: [OpenAFS] windows get tokens for 2 cells on logon Message-ID: --_abd778c1-6407-4768-ab88-885fd937f226_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C We use openafs on windows with kerberos for authentication. We use Network = identity manager to handle all our kerberos and afs credentials.=20 Now the problem. One user has a configuration =2Cin Network identity manage= r=2C to get tokens for two afs cell on windows logon but this dont work and= he only gets tokens for the main afs cell. So he need to manually obtain n= ew credentials in "Network identity manager" to get tokens for both cells a= nd this works with no problems. Why wont this work on windows logon? The user says that this has worked bef= ore on his computer.=20 Best regards/Tomas = --_abd778c1-6407-4768-ab88-885fd937f226_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=2C

We use = openafs on windows with kerberos for authentication. We use Network identit= y manager to handle all our kerberos and afs credentials. =3B

Now the problem. One user has a configuration =2Cin Network= identity manager=2C to get tokens for two afs cell on windows logon but th= is dont work and he only gets tokens for the main afs cell. So he need to m= anually obtain new credentials in "Network identity manager" to get tokens = for both cells and this works with no problems.

Wh= y wont this work on windows logon? The user says that this has worked befor= e on his computer. =3B

Best regards
= /Tomas
= --_abd778c1-6407-4768-ab88-885fd937f226_-- From jaltman@your-file-system.com Sun Jun 1 15:02:37 2014 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sun, 01 Jun 2014 10:02:37 -0400 Subject: [OpenAFS] windows get tokens for 2 cells on logon In-Reply-To: References: Message-ID: <538B327D.5080108@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms070409040602090603070504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/1/2014 6:59 AM, Tomas Granat wrote: > Hi, >=20 > We use openafs on windows with kerberos for authentication. We use > Network identity manager to handle all our kerberos and afs credentials= =2E=20 >=20 > Now the problem. One user has a configuration ,in Network identity > manager, to get tokens for two afs cell on windows logon but this dont > work and he only gets tokens for the main afs cell. So he need to > manually obtain new credentials in "Network identity manager" to get > tokens for both cells and this works with no problems. >=20 > Why wont this work on windows logon? The user says that this has worked= > before on his computer.=20 >=20 > Best regards > /Tomas The Network Identity Manager configuration is independent of the Windows Authentication Provider (aka Integrated Logon) configuration. Whereas NetIdMgr provides a nice GUI for specifying the bindings between AFS cells and Kerberos principals (aka identities) there is no such GUI for the Authentication Provider configuration. The Authentication Provider configuration registry keys are specified und= er HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider and are documented in the release notes which are installed on the local machine and can also be accessed via http://www.openafs.org/windows.html or http://docs.openafs.org See Section A.2.1 on Domain configuration and look for the "TheseCells" parameter. If this is not enough to point you in the correct direction, paid support is available. Jeffrey Altman --------------ms070409040602090603070504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhB4 sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSrqYUguvbguthxGNq M15noPYGLMnpjRKT2VS88MxNAZ7RaplB8Azrk8vOH+q+IWnXCrap+BevY27PZW6UgNAPcETG FTi/qdYAukHwnCV7fvjXXJEOw3jg+eK/06bhr0uThvmrjT+jWHlpzK3mSDPtEBSkgXDbLkL/ LQfYvay0Ia7n65l5Ry4zHlrg6uJ+UqvWJZwXazXjo2H4EksGCM4nrKHTeVoj5oSquvqs3tSf BytXLGVqSOHqjXb+lri1gtlovX7AjMT2gdONRrjR3wun6tjHvoqjUNZ2mUs0XXh0vI0GyTKd taz26xY+iKboxFO2atDbb1Gm8KdUXqO/UivlAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAEUyacJvoRfQdglYgnUwaTMsRRg0YeAljbnb8M5E vBSo3u/LhvbXtvu+9uE8R6UOE4GvKH382I27vjuM28oHqfii04URAB1icmA8b7rxYQo9Ob2I /NkkQRBwbA3HGLWXFjupODWbP5WylyySAAI7HxG2xbE4X+8+hMJVOKfxJb6J0SUOBlnmMkmg nAxgOM4venSmli6U3o0nADHNLZEJjqym2QstkeYPhDZ6sSO3t/yv+JyYbfb01hiOdhGsDBif oPTqcWRvA+lqbWMHJG3p9uL/kI4jbLj9/ZkMfdRDHpQNVAuGxxyj7b1pxM0jBuTP0Jmrcz3U wUwT5kjCCDt2gGAxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHiwwaDblI88SsZkARSRB5MwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwNjAxMTQwMjM3WjAjBgkqhkiG9w0BCQQxFgQUad8kgtCdT/wdYVmUaY320I6u/ZAwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQeLDBoNuUjzxKxmQBFJEHkzCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhB4sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBAQUABIIB AIncwJc/5YDwqxrrZytzGIbhVlcOarbtcFjd//Rgqc0xTV62dFyU0IcwCZrgi90vmoz5XQm2 XmlOpdZnymPsdXGVXJZ6SWsuhrdS8DcaRtIMB9VCpFNkN9/fpPGAEHjIKx+M49740nW3CsgO Vh2mjJAYgK0n1UgsUIzkuKQyqKWa/TqOGjQ9snbqRbZA94lYNT8R1SvaH+yc61u2v73Rs0OQ UUnQHddy4L20+07oY9vQ1ZHbkreTjkPW6Y1uggv33s8g55RGTPv8vK5+qASVwrxihy0+uTt4 Z7+EToffMVRIZUqKNO+UeLaVHHD90C3wetnJFK3rD4TFDgfj8eJ9zbkAAAAAAAA= --------------ms070409040602090603070504-- From jwinius@umrk.nl Tue Jun 3 21:56:02 2014 From: jwinius@umrk.nl (Jaap Winius) Date: Tue, 03 Jun 2014 22:56:02 +0200 Subject: [OpenAFS] X11 logout script Message-ID: <20140603225602.75072p56grmgcmsi@bitis.umrk.nl> Hi folks, Some of the the sites that I maintain use an elaborate logout script, located in /etc/X11/Xreset.d/, that runs as root and contains many sudo commands to make changes to each user's home directory. It works because these directories are made available via NFSv3 (another story), but what if I was using AFS for them (or even NFSv4 with Kerberos)? Is there some way to run an X11 logout script as an unprivileged user, similar to /etc/bash.bash_logout? Thanks, Jaap From adeason@sinenomine.net Wed Jun 4 02:33:44 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 3 Jun 2014 20:33:44 -0500 Subject: [OpenAFS] Re: X11 logout script References: <20140603225602.75072p56grmgcmsi@bitis.umrk.nl> Message-ID: <20140603203344.9c1f3772003324ea40628314@sinenomine.net> On Tue, 03 Jun 2014 22:56:02 +0200 Jaap Winius wrote: > Some of the the sites that I maintain use an elaborate logout script, > located in /etc/X11/Xreset.d/, that runs as root and contains many > sudo commands to make changes to each user's home directory. It works > because these directories are made available via NFSv3 (another > story), but what if I was using AFS for them (or even NFSv4 with > Kerberos)? Is there some way to run an X11 logout script as an > unprivileged user, similar to /etc/bash.bash_logout? It's been a while since I've dealt with anything like this, but it sounds like you could handle this via Xsession.d instead. Normally that's for starting session-handling programs in the user's context (e.g. gpg-agent, ssh-agent, dbus; or krenew I think at some places), but since you're just waiting for the user's session to end, it could be used for this. Something like: $ cat /etc/X11/Xsession.d/51user-logout if [ -x /usr/local/bin/userlogoutscript ] ; then STARTUP="sh -c '$STARTUP ; /usr/local/bin/userlogoutscript'" fi Or something like that. The quoting/spacing/etc may get confused with other STARTUP modifiers, so you may just want to wrap it in a script so you can specify that like a normal STARTUP command (e.g. STARTUP="/usr/local/bin/wraplogout $STARTUP"). And obviously I haven't tested that or used something like that before; just an idea. Of course, to do anything like that you'd need to divide the "elaborate logout script" into things that need to actually run as root (which go in Xreset.d) and things that need to run as the user (which go in Xsession.d). Alternatively, it may also be possible to do this with some PAM modules that could run scripts when the user's session is destroyed, but I've never done that. -- Andrew Deason adeason@sinenomine.net From ktdreyer@ktdreyer.com Fri Jun 6 00:30:12 2014 From: ktdreyer@ktdreyer.com (Ken Dreyer) Date: Thu, 5 Jun 2014 17:30:12 -0600 Subject: [OpenAFS] Recent Fedora kmod issues In-Reply-To: References: Message-ID: On Sun, May 4, 2014 at 11:23 AM, Jon Stanley wrote: > A simple change to have those lines reference /usr/sbin/depmod worked. > I think that the logic probably needs to be conditionalized such that > on RHEL6 and below, we use /sbin/depmod, and Fedora >=17 and RHEL >=7 > we use /usr/sbin/depmod. Stephan's solution in Gerrit is to implement the conditonal as you proposed. This is the least invasive approach and the one that is likely to make it into OpenAFS 1.6. In an ideal world OpenAFS could stop bundling a custom openafs-kmodtool and rely on one provided by the distro. Red Hat does continue to ship /usr/lib/rpm/redhat/kmodtool as a part of RHEL and Fedora. Unfortunately the kmodtool script in Fedora has fallen into disrepair and is even older than the one that currently ships on RHEL 5.10. Fedora's kmodtool is currently missing features that we simply must have for OpenAFS (UsrMove being one). RPM Fusion has been shipping their own kmodtool fork which they patched for UsrMove long ago, and I suspect that when ELRepo starts shipping kmods for RHEL 7 they're going to implement the same change as well. So as you can see there's a lot of duplicated effort going on here. I suspect that the lack of updates in Fedora may have been a contributing factor for the proliferance of kmodtool forks. I'm trying to sort this out with the Fedora guys here: https://bugzilla.redhat.com/1094384 . Please feel free to add yourself to the CC on that bug if you're interested. - Ken From rich@nd.edu Mon Jun 9 17:18:07 2014 From: rich@nd.edu (Rich Sudlow) Date: Mon, 09 Jun 2014 12:18:07 -0400 Subject: [OpenAFS] afs: Lost contact with file server Message-ID: <5395DE3F.90906@nd.edu> Where can I find the codes for afs: Lost contact with file server? I'm seeing code -1 and -9 Thanks, Rich -- Rich Sudlow University of Notre Dame Center for Research Computing - Union Station 506 W. South St South Bend, In 46601 (574) 631-7258 (office) (574) 807-1046 (cell) From jaltman@your-file-system.com Mon Jun 9 18:08:33 2014 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Mon, 09 Jun 2014 13:08:33 -0400 Subject: [OpenAFS] afs: Lost contact with file server In-Reply-To: <5395DE3F.90906@nd.edu> References: <5395DE3F.90906@nd.edu> Message-ID: <5395EA11.1080307@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms040607010108090800020906 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/2014 12:18 PM, Rich Sudlow wrote: > Where can I find the codes for afs: Lost contact with file server? > I'm seeing code -1 and -9 >=20 > Thanks, >=20 > Rich They would be RX error codes from src/rx/rx.h /* Something bad happened to the connection; temporary loss of communication */ #define RX_CALL_DEAD (-1) /* * An invalid operation, such as a client attempting to send data * after having received the beginning of a reply from the server. */ #define RX_INVALID_OPERATION (-2) /* An optional timeout per call may be specified */ #define RX_CALL_TIMEOUT (-3) /* End of data on a read. Not currently in use. */ #define RX_EOF (-4) /* Some sort of low-level protocol error. */ #define RX_PROTOCOL_ERROR (-5) /* * Generic user abort code; used when no more specific error code needs to be * communicated. For example, multi rx clients use this code to abort a multi- * rx call. */ #define RX_USER_ABORT (-6) /* Port already in use (from rx_Init). This error is never sent on the wire. */ #define RX_ADDRINUSE (-7) /* EMSGSIZE returned from network. Packet too big, must fragment */ #define RX_MSGSIZE (-8) /* * Idle dead timeout error. This error is never sent on the wire. * rxi_SendCallAbort() translates RX_CALL_IDLE to RX_CALL_TIMEOUT. */ #define RX_CALL_IDLE (-9) --------------ms040607010108090800020906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhB4 sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSrqYUguvbguthxGNq M15noPYGLMnpjRKT2VS88MxNAZ7RaplB8Azrk8vOH+q+IWnXCrap+BevY27PZW6UgNAPcETG FTi/qdYAukHwnCV7fvjXXJEOw3jg+eK/06bhr0uThvmrjT+jWHlpzK3mSDPtEBSkgXDbLkL/ LQfYvay0Ia7n65l5Ry4zHlrg6uJ+UqvWJZwXazXjo2H4EksGCM4nrKHTeVoj5oSquvqs3tSf BytXLGVqSOHqjXb+lri1gtlovX7AjMT2gdONRrjR3wun6tjHvoqjUNZ2mUs0XXh0vI0GyTKd taz26xY+iKboxFO2atDbb1Gm8KdUXqO/UivlAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAEUyacJvoRfQdglYgnUwaTMsRRg0YeAljbnb8M5E vBSo3u/LhvbXtvu+9uE8R6UOE4GvKH382I27vjuM28oHqfii04URAB1icmA8b7rxYQo9Ob2I /NkkQRBwbA3HGLWXFjupODWbP5WylyySAAI7HxG2xbE4X+8+hMJVOKfxJb6J0SUOBlnmMkmg nAxgOM4venSmli6U3o0nADHNLZEJjqym2QstkeYPhDZ6sSO3t/yv+JyYbfb01hiOdhGsDBif oPTqcWRvA+lqbWMHJG3p9uL/kI4jbLj9/ZkMfdRDHpQNVAuGxxyj7b1pxM0jBuTP0Jmrcz3U wUwT5kjCCDt2gGAxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHiwwaDblI88SsZkARSRB5MwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwNjA5MTcwODMzWjAjBgkqhkiG9w0BCQQxFgQUoIZ1zniKkWpWIu3BGNWWx/vko+AwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQeLDBoNuUjzxKxmQBFJEHkzCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhB4sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBAQUABIIB AHwSjJsZUDKg9biIkQuHCd1RF3TKWWm+zsV+Hf1I6yyB+GPTONBcXBTQX3n7Lq0MXH/S9JSq MKAeuGvIqU+rG6h43dCQPvQixkTTdSc85DncRfizLpzCF4YadNS28avNsSiLe1Ns3QL4+isP j8UZOZu3Y1l9bhqOv4pEBrQ9KuXXEiTx7Cc5+8QsjpFcqxWPHeJxmMUpyJAs1pcNRC5DWinf cNNxieiX4fpA1Sw+cOVe9EiV9US/eBjP+Xq4EmWgPOCi9N72RAk2yQLCbb75bzo/26S3ev/U PW0K0IqO4jZ8GqfH/elxESKR4gjyLuRl9KabxXhBC4VEbLffauiRpy0AAAAAAAA= --------------ms040607010108090800020906-- From stephen@physics.unc.edu Tue Jun 10 18:02:51 2014 From: stephen@physics.unc.edu (stephen@physics.unc.edu) Date: Tue, 10 Jun 2014 13:02:51 -0400 (EDT) Subject: [OpenAFS] fs listquota with > 2TB /vicepx Message-ID: Is the partition %used of "fs listquota" expected to be correct when the volume resides on a partition of greater than 2TB? I looked in the archives, but couldn't find an answer to this specific question; the closest I found was an old discussion from 2013. A few list regulars indicated that volume quotas over 2TB were still broken, but that with 1.6.2 or newer and 2TB+ partitions "...everything works." I'm running DA binaries version 1.6.7-1 (ubuntu package) with 4TB partitions and the %used of the partitions are always 0. I've tried fs binaries from 1.6.1-2+ubuntu2.2 and 1.6.7-1. If this isn't a known problem, I can provide additional information. "vos partinfo" output looks correct; I've only noticed this 0% issue on "fs listquota". PS. Definitely not a show-stopper issue, especially now that I'm aware of it. It just surprised me enough to ask. Cheers, Stephen From jaltman@your-file-system.com Tue Jun 10 19:10:57 2014 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Tue, 10 Jun 2014 14:10:57 -0400 Subject: [OpenAFS] fs listquota with > 2TB /vicepx In-Reply-To: References: Message-ID: <53974A31.1050001@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms010901090506020708040806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/10/2014 1:02 PM, stephen@physics.unc.edu wrote: > Is the partition %used of "fs listquota" expected to be correct when th= e > volume resides on a partition of greater than 2TB? >=20 > I looked in the archives, but couldn't find an answer to this specific > question; the closest I found was an old discussion from 2013. A few > list regulars indicated that volume quotas over 2TB were still broken, > but that with 1.6.2 or newer and 2TB+ partitions "...everything works."= >=20 > I'm running DA binaries version 1.6.7-1 (ubuntu package) with 4TB > partitions and the %used of the partitions are always 0. I've tried fs > binaries from 1.6.1-2+ubuntu2.2 and 1.6.7-1. If this isn't a known > problem, I can provide additional information. >=20 > "vos partinfo" output looks correct; I've only noticed this 0% issue on= > "fs listquota". >=20 > PS. Definitely not a show-stopper issue, especially now that I'm aware > of it. It just surprised me enough to ask. >=20 > Cheers, > Stephen In OpenAFS, the fs listquota command relies upon struct AFSFetchVolumeStatus { afs_int32 Vid; afs_int32 ParentId; char Online; char InService; char Blessed; char NeedsSalvage; afs_int32 Type; afs_int32 MinQuota; afs_int32 MaxQuota; afs_int32 BlocksInUse; afs_int32 PartBlocksAvail; afs_int32 PartMaxBlocks; }; which cannot represent volume quota or partition details for partitions larger than 2TB. The values reported by the file server will be truncated to fit. Jeffrey Altman --------------ms010901090506020708040806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhB4 sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSrqYUguvbguthxGNq M15noPYGLMnpjRKT2VS88MxNAZ7RaplB8Azrk8vOH+q+IWnXCrap+BevY27PZW6UgNAPcETG FTi/qdYAukHwnCV7fvjXXJEOw3jg+eK/06bhr0uThvmrjT+jWHlpzK3mSDPtEBSkgXDbLkL/ LQfYvay0Ia7n65l5Ry4zHlrg6uJ+UqvWJZwXazXjo2H4EksGCM4nrKHTeVoj5oSquvqs3tSf BytXLGVqSOHqjXb+lri1gtlovX7AjMT2gdONRrjR3wun6tjHvoqjUNZ2mUs0XXh0vI0GyTKd taz26xY+iKboxFO2atDbb1Gm8KdUXqO/UivlAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAEUyacJvoRfQdglYgnUwaTMsRRg0YeAljbnb8M5E vBSo3u/LhvbXtvu+9uE8R6UOE4GvKH382I27vjuM28oHqfii04URAB1icmA8b7rxYQo9Ob2I /NkkQRBwbA3HGLWXFjupODWbP5WylyySAAI7HxG2xbE4X+8+hMJVOKfxJb6J0SUOBlnmMkmg nAxgOM4venSmli6U3o0nADHNLZEJjqym2QstkeYPhDZ6sSO3t/yv+JyYbfb01hiOdhGsDBif oPTqcWRvA+lqbWMHJG3p9uL/kI4jbLj9/ZkMfdRDHpQNVAuGxxyj7b1pxM0jBuTP0Jmrcz3U wUwT5kjCCDt2gGAxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHiwwaDblI88SsZkARSRB5MwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwNjEwMTgxMDU3WjAjBgkqhkiG9w0BCQQxFgQUEhYW1hyVFIj+4YMUMcGQoiXWNYMwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQeLDBoNuUjzxKxmQBFJEHkzCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhB4sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBAQUABIIB AJrRMljFn+wz8Tp9eCXPPiZbbupDMe/WG4iMy7Gygnejq7wX3WKok6jpErZCxwZnALX+qPOG zn8BGhO6zmeHraf3hREADTohNKayHaKuq4HRCRPFo399OJ38/KAtKtCvLqQiEn8K7c2Xj2kq XXxYHANIKufXzLf0kNcdylqFlfblhvJVRgOqxgHY0EPlv1giE5LRZrWxJuJQQCa6vGPU0y5a vmdRDKZ3Dxln/qzuUnIsx7Uea0QddDKtNQxZHxRk5+HcEDVhkE+ChO6SFOHg7mz1WklkFo5W Q/8DeMl4zWc5J+xN7ScUDADgAwGbxQ6b4C2zul2+yR/nhIyxaz6wifsAAAAAAAA= --------------ms010901090506020708040806-- From adeason@sinenomine.net Tue Jun 10 20:40:27 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 10 Jun 2014 14:40:27 -0500 Subject: [OpenAFS] Re: fs listquota with > 2TB /vicepx References: Message-ID: <20140610144027.7e5d5cead3bbb49d821f527e@sinenomine.net> On Tue, 10 Jun 2014 13:02:51 -0400 (EDT) stephen@physics.unc.edu wrote: > I'm running DA binaries version 1.6.7-1 (ubuntu package) with 4TB > partitions and the %used of the partitions are always 0. I've tried fs > binaries from 1.6.1-2+ubuntu2.2 and 1.6.7-1. If this isn't a known > problem, I can provide additional information. The fileserver reports partition space usage in terms of how much space is free (not by how much space is used), which makes this a little counterintuitive. If you have 4TB, I think you'll see 0% used until you have less than 2TB free. For example, say you have a 4TB partition, and you're using 1TB (3TB free). Since values over 2TB are clamped, you might expect this to be reported as 1TB used (not clamped), 2TB total (clamped), for a usage of 50%. But that's not what happens. Instead, since the server responds with the 'free' value, not the 'used' value, the server will respond with 2TB free (clamped), 2TB total (clamped), so the usage is calculated as 0%. Individual volumes, on the other hand, are reported as 'space used' instead of 'space free'. But you can't have a finite volume quota over 2TB anyway, so this issue doesn't apply there. This is indeed a bit confusing, and should probably be clarified in the documentation. Maybe I'll go do that now. -- Andrew Deason adeason@sinenomine.net From stephan.wiesand@desy.de Fri Jun 13 19:28:20 2014 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Fri, 13 Jun 2014 20:28:20 +0200 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.6.9 release available In-Reply-To: <5DECEF3A-BFAE-4545-B0B6-3E9018059997@desy.de> References: <5DECEF3A-BFAE-4545-B0B6-3E9018059997@desy.de> Message-ID: On Jun 12, 2014, at 19:44 , Stephan Wiesand wrote: > The OpenAFS Release Team is pleased to announce the availability of > OpenAFS version 1.6.9. Source files can be accessed via the web at: > > http://www.openafs.org/dl/openafs/1.6.9/ > > or via AFS at: > > /afs/grand.central.org/software/openafs/1.6.9/ > \\afs\grand.central.org\software\openafs\1.6.9\ > > OpenAFS 1.6.9 is the next in the current series of stable releases > of OpenAFS for all platforms except Microsoft Windows. The only > change since the 1.6.8 release is: > > * Fix for OpenAFS-SA-2014-002 > > Bug reports should be filed to openafs-bugs@openafs.org . > > No binaries are available at the time of release, but they will > be uploaded and accessible through the web link given above as > they are built. Thanks to the efforts of Ben Kaduk, Andrew Deason and Christof Hanke, binaries for FreeBSD, Solaris and SUSE Linux are now available. -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From haba@kth.se Tue Jun 17 06:34:51 2014 From: haba@kth.se (Harald Barth) Date: Tue, 17 Jun 2014 07:34:51 +0200 (CEST) Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump Message-ID: <20140617.073451.1246867853302685727.haba@habook> Is this a known bug of openafs-fileserver 1.6.1-3+deb7u1 (Debian)? 06/16/2014 23:42:11 dispatching child to salvage volume 536904480... 06/16/2014 23:42:23 SYNC_getCom: error receiving command 06/16/2014 23:42:23 SALVSYNC_com: read failed; dropping connection (cnt=190) 06/16/2014 23:42:23 "salvageserver" core dumped! 06/16/2014 23:42:23 "salvageserver" (pid=3622) terminated abnormally! 06/16/2014 23:42:12 2 nVolumesInInodeFile 64 06/16/2014 23:42:12 CHECKING CLONED VOLUME 536904573. 06/16/2014 23:42:12 home.maxz.backup (536904573) updated 11/20/2013 09:20 06/16/2014 23:42:12 SALVAGING VOLUME 536904480. 06/16/2014 23:42:12 home.maxz (536904480) updated 11/20/2013 09:20 06/16/2014 23:42:12 totalInodes 1238 06/16/2014 23:42:13 dir vnode 47: invalid entry deleted: ??/.. (vnode 249, unique 38300) 06/16/2014 23:42:13 dir vnode 51: invalid entry deleted: ??/.. (vnode 249, unique 38300) Harald. From haba@kth.se Tue Jun 17 09:25:21 2014 From: haba@kth.se (Harald Barth) Date: Tue, 17 Jun 2014 10:25:21 +0200 (CEST) Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140617.073451.1246867853302685727.haba@habook> References: <20140617.073451.1246867853302685727.haba@habook> Message-ID: <20140617.102521.2164204618261589272.haba@habook> More from the core: (gdb) bt #0 0x00007fbe95040475 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fbe950436f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x000000000042f162 in osi_Panic ( msg=msg@entry=0x4635f0 "assertion failed: %s, file: %s, line: %d\n") at ./../rx/rx_user.c:251 #3 0x000000000042f17d in osi_AssertFailU ( expr=expr@entry=0x4586bb "Delete(&dh, \"..\") == 0", file=file@entry=0x458337 "../vol/vol-salvage.c", line=line@entry=3997) at ./../rx/rx_user.c:261 #4 0x0000000000408078 in SalvageVolume ( salvinfo=salvinfo@entry=0x7fff12474f80, rwIsp=rwIsp@entry=0x1bd68b0, alinkH=0x1bd44a0) at ../vol/vol-salvage.c:3997 #5 0x000000000040af8d in DoSalvageVolumeGroup (salvinfo=salvinfo@entry=0x0, isp=0x1bd68b0, nVols=nVols@entry=2) at ../vol/vol-salvage.c:2092 #6 0x000000000040c391 in SalvageFileSys1 (partP=partP@entry=0x1bca880, singleVolumeNumber=536904480) at ../vol/vol-salvage.c:937 #7 0x00000000004041a9 in DoSalvageVolume (slot=, node=0x1bd4030) at ../vol/salvaged.c:640 #8 SalvageServer (argv=, argc=) at ../vol/salvaged.c:574 #9 handleit (as=, arock=) at ../vol/salvaged.c:299 #10 0x00000000004572a4 in cmd_Dispatch (argc=7, argc@entry=6, argv=0x1bc1c20, argv@entry=0x7fff12475768) at cmd.c:905 #11 0x0000000000404c67 in main (argc=6, argv=0x7fff12475768) at ../vol/salvaged.c:418 So this is bailing out at vol_salvage.c opr_Verify(afs_dir_Delete(&dh, "..") == 0) which looks a lot like http://git.openafs.org/?p=openafs.git;a=commitdiff;h=e8faeae6dcae0e566de2b21d53d3f78f3cc44e3f > Improve JudgeEntry() detection of orphaned directories to > prevent unintentional deletion of their '.' and '..' entries. > This in turn prevents a later assert (opr_Verify) when we try to > delete and re-add '..' in order to attach the orphan. > ... So well, now I "only" need to find something that contains that patch (1.6.9 I suppose) for wheezy, correct? Harald. From stephan.wiesand@desy.de Tue Jun 17 09:37:42 2014 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Tue, 17 Jun 2014 10:37:42 +0200 Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140617.102521.2164204618261589272.haba@habook> References: <20140617.073451.1246867853302685727.haba@habook> <20140617.102521.2164204618261589272.haba@habook> Message-ID: <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> On 2014-06-17, at 10:25, Harald Barth wrote: > More from the core: >=20 > (gdb) bt > #0 0x00007fbe95040475 in raise () from = /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007fbe950436f0 in abort () from = /lib/x86_64-linux-gnu/libc.so.6 > #2 0x000000000042f162 in osi_Panic ( > msg=3Dmsg@entry=3D0x4635f0 "assertion failed: %s, file: %s, line: = %d\n") > at ./../rx/rx_user.c:251 > #3 0x000000000042f17d in osi_AssertFailU ( > expr=3Dexpr@entry=3D0x4586bb "Delete(&dh, \"..\") =3D=3D 0",=20 > file=3Dfile@entry=3D0x458337 "../vol/vol-salvage.c", = line=3Dline@entry=3D3997) > at ./../rx/rx_user.c:261 > #4 0x0000000000408078 in SalvageVolume ( > salvinfo=3Dsalvinfo@entry=3D0x7fff12474f80, = rwIsp=3DrwIsp@entry=3D0x1bd68b0,=20 > alinkH=3D0x1bd44a0) at ../vol/vol-salvage.c:3997 > #5 0x000000000040af8d in DoSalvageVolumeGroup = (salvinfo=3Dsalvinfo@entry=3D0x0,=20 > isp=3D0x1bd68b0, nVols=3DnVols@entry=3D2) at = ../vol/vol-salvage.c:2092 > #6 0x000000000040c391 in SalvageFileSys1 = (partP=3DpartP@entry=3D0x1bca880,=20 > singleVolumeNumber=3D536904480) at ../vol/vol-salvage.c:937 > #7 0x00000000004041a9 in DoSalvageVolume (slot=3D,=20 > node=3D0x1bd4030) at ../vol/salvaged.c:640 > #8 SalvageServer (argv=3D, argc=3D) > at ../vol/salvaged.c:574 > #9 handleit (as=3D, arock=3D) > at ../vol/salvaged.c:299 > #10 0x00000000004572a4 in cmd_Dispatch (argc=3D7, argc@entry=3D6, = argv=3D0x1bc1c20,=20 > argv@entry=3D0x7fff12475768) at cmd.c:905 > #11 0x0000000000404c67 in main (argc=3D6, argv=3D0x7fff12475768) > at ../vol/salvaged.c:418 >=20 > So this is bailing out at=20 > vol_salvage.c opr_Verify(afs_dir_Delete(&dh, "..") =3D=3D 0) > which looks a lot like=20 >=20 > = http://git.openafs.org/?p=3Dopenafs.git;a=3Dcommitdiff;h=3De8faeae6dcae0e5= 66de2b21d53d3f78f3cc44e3f >=20 >> Improve JudgeEntry() detection of orphaned directories to >> prevent unintentional deletion of their '.' and '..' entries. >> This in turn prevents a later assert (opr_Verify) when we try to >> delete and re-add '..' in order to attach the orphan. >> ... >=20 > So well, now I "only" need to find something that contains that patch > (1.6.9 I suppose) for wheezy, correct? This change went into 1.6.6, so 1.6.7 would do as well. --=20 Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany From haba@kth.se Tue Jun 17 10:03:00 2014 From: haba@kth.se (Harald Barth) Date: Tue, 17 Jun 2014 11:03:00 +0200 (CEST) Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> References: <20140617.073451.1246867853302685727.haba@habook> <20140617.102521.2164204618261589272.haba@habook> <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> Message-ID: <20140617.110300.911747264340771049.haba@habook> > This change went into 1.6.6, so 1.6.7 would do as well. Thanks. Built myself a 1.6.9 from the source deb from unstable. But unfortunately, the volume in question breaks the 1.6.9 salvageserver as well :( Gdb tells me: (gdb) up #1 0x00007f82c1a436f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) up #2 0x00007f82c2424bb8 in osi_Panic ( msg=msg@entry=0x7f82c245c1d0 "assertion failed: %s, file: %s, line: %d\n") at ./../rx/rx_user.c:251 251 afs_abort(); (gdb) up #3 0x00007f82c2424bd5 in osi_AssertFailU ( expr=expr@entry=0x7f82c2450c13 "Delete(&dh, \"..\") == 0", file=file@entry=0x7f82c245088f "../vol/vol-salvage.c", line=line@entry=4127) at ./../rx/rx_user.c:261 261 osi_Panic("assertion failed: %s, file: %s, line: %d\n", expr, (gdb) up #4 0x00007f82c23f97b7 in SalvageVolume ( salvinfo=salvinfo@entry=0x7fffcf109530, rwIsp=rwIsp@entry=0x7f82c2dba290, alinkH=0x7f82c2db7e80) at ../vol/vol-salvage.c:4127 4127 osi_Assert(Delete(&dh, "..") == 0); (gdb) list 4122 SetSalvageDirHandle(&dh, vid, salvinfo->fileSysDevice, 4123 salvinfo->vnodeInfo[class].inodes[v], 4124 &salvinfo->VolumeChanged); 4125 pa.Vnode = LFVnode; 4126 pa.Unique = LFUnique; 4127 osi_Assert(Delete(&dh, "..") == 0); 4128 osi_Assert(Create(&dh, "..", &pa) == 0); 4129 4130 /* The original parent's link count was decremented above. 4131 * Here we increment the new parent's link count. (gdb) p dh $1 = {dirh_volume = 536904480, dirh_device = 0, dirh_inode = 173619825082415, dirh_handle = 0x7f82c2db8980, dirh_cacheCheck = 44, volumeChanged = 0x7fffcf109570} (gdb) p &dh $2 = (DirHandle *) 0x7fffcf108c00 (gdb) p pa $3 = {Volume = 4294967295, Vnode = 1, Unique = 1} Should we not just make a ".." in this situation? And now lunch. Harald. From chas@cmf.nrl.navy.mil Tue Jun 17 13:41:52 2014 From: chas@cmf.nrl.navy.mil (chas williams - CONTRACTOR) Date: Tue, 17 Jun 2014 08:41:52 -0400 Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140617.102521.2164204618261589272.haba@habook> References: <20140617.073451.1246867853302685727.haba@habook> <20140617.102521.2164204618261589272.haba@habook> Message-ID: <20140617084152.266ff030@thirdoffive.cmf.nrl.navy.mil> On Tue, 17 Jun 2014 10:25:21 +0200 (CEST) Harald Barth wrote: > > http://git.openafs.org/?p=openafs.git;a=commitdiff;h=e8faeae6dcae0e566de2b21d53d3f78f3cc44e3f > > > Improve JudgeEntry() detection of orphaned directories to > > prevent unintentional deletion of their '.' and '..' entries. > > This in turn prevents a later assert (opr_Verify) when we try to > > delete and re-add '..' in order to attach the orphan. > > ... > > So well, now I "only" need to find something that contains that patch > (1.6.9 I suppose) for wheezy, correct? I don't think this patch will help at this point. Your 1.6.1 salvager (which doesn't have this patch) has already run and deleted the '..' directory in what is apparently an orphaned directory.\ >Should we not just make a ".." in this situation? That seems reasonable to me. Failing to delete the .. in an orphaned directory probably shouldn't be an assertion (just a warning). From haba@kth.se Tue Jun 17 14:01:42 2014 From: haba@kth.se (Harald Barth) Date: Tue, 17 Jun 2014 15:01:42 +0200 (CEST) Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140617.110300.911747264340771049.haba@habook> References: <20140617.102521.2164204618261589272.haba@habook> <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> <20140617.110300.911747264340771049.haba@habook> Message-ID: <20140617.150142.3129020045934937.haba@habook> Well, I did add a patch like: Index: openafs-1.6.9/src/vol/vol-salvage.c =================================================================== --- openafs-1.6.9.orig/src/vol/vol-salvage.c 2014-06-12 08:30:48.000000000 +0000 +++ openafs-1.6.9/src/vol/vol-salvage.c 2014-06-17 10:34:23.857444175 +0000 @@ -4124,7 +4124,8 @@ &salvinfo->VolumeChanged); pa.Vnode = LFVnode; pa.Unique = LFUnique; - osi_Assert(Delete(&dh, "..") == 0); + if(Delete(&dh, "..") != 0) + Log("Delete of .. failed, but will try to recreate it anyway\n"); osi_Assert(Create(&dh, "..", &pa) == 0); /* The original parent's link count was decremented above. Which created two empty __ORPHANDIR__* in the volume. Then I have the following logs from my backup script which tried a vos backup home.katy Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Could not start a transaction on the volume 536904474 Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Volume needs to be salvaged Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Error in vos backup command. Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Volume needs to be salvaged However, my salvage log says, that the volume was salvaged OK: 06/16/2014 23:39:37 Salvaged home.katy (536904474): 23897 files, 732753 blocks and that the salvage ended 06/16/2014 23:57:23 which is several hours before. When I did a vos backup home.katy recently, everything went good. What's going on here? Followup question: Should I now run a salvage over all volumes? How do I do that with as little impact as possible manually? Harald. From chas@cmf.nrl.navy.mil Tue Jun 17 16:15:26 2014 From: chas@cmf.nrl.navy.mil (chas williams - CONTRACTOR) Date: Tue, 17 Jun 2014 11:15:26 -0400 Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140617.150142.3129020045934937.haba@habook> References: <20140617.102521.2164204618261589272.haba@habook> <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> <20140617.110300.911747264340771049.haba@habook> <20140617.150142.3129020045934937.haba@habook> Message-ID: <20140617111526.1f8939f2@thirdoffive.cmf.nrl.navy.mil> On Tue, 17 Jun 2014 15:01:42 +0200 (CEST) Harald Barth wrote: > > > Well, I did add a patch like: > > > Index: openafs-1.6.9/src/vol/vol-salvage.c > =================================================================== > --- openafs-1.6.9.orig/src/vol/vol-salvage.c 2014-06-12 08:30:48.000000000 +0000 > +++ openafs-1.6.9/src/vol/vol-salvage.c 2014-06-17 10:34:23.857444175 +0000 > @@ -4124,7 +4124,8 @@ > &salvinfo->VolumeChanged); > pa.Vnode = LFVnode; > pa.Unique = LFUnique; > - osi_Assert(Delete(&dh, "..") == 0); > + if(Delete(&dh, "..") != 0) > + Log("Delete of .. failed, but will try to recreate it anyway\n"); > osi_Assert(Create(&dh, "..", &pa) == 0); > > /* The original parent's link count was decremented above. > > > Which created two empty __ORPHANDIR__* in the volume. You did get two 'Delete of .. failed' right? > Then I have the following logs from my backup script which tried a vos backup home.katy After your new salvager created the orphan directories? > Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Could not start a transaction on the volume 536904474 > Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Volume needs to be salvaged > Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Error in vos backup command. > Tue Jun 17 01:39:36 2014 beef.stacken.kth.se : Volume needs to be salvaged > > However, my salvage log says, that the volume was salvaged OK: > > 06/16/2014 23:39:37 Salvaged home.katy (536904474): 23897 files, 732753 blocks > > and that the salvage ended 06/16/2014 23:57:23 which is several hours before. Salvage again using the 1.6.1 salvager. There shouldn't be any broken orphans anymore. > When I did a vos backup home.katy recently, everything went good. What's going on here? > > Followup question: Should I now run a salvage over all volumes? How do > I do that with as little impact as possible manually? I wouldn't salvage anything unless you know there is something wrong with the volumes. To reduce impact, I would write a small script to salvage the volumes one at a time. From adeason@sinenomine.net Tue Jun 17 19:57:08 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 17 Jun 2014 13:57:08 -0500 Subject: [OpenAFS] Re: Salvageserver 1.6.1-3+deb7u1 core dump References: <20140617.073451.1246867853302685727.haba@habook> <20140617.102521.2164204618261589272.haba@habook> <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> <20140617.110300.911747264340771049.haba@habook> Message-ID: <20140617135708.14510f06432aa9253afafd05@sinenomine.net> On Tue, 17 Jun 2014 11:03:00 +0200 (CEST) Harald Barth wrote: > Should we not just make a ".." in this situation? I'm not sure if making that just a warning is a good idea or not, but that shouldn't happen on just missing a ".." entry. You might want to salvage the volume with -salvagedirs, since apparently we're not properly detecting invalid directories in the volume. This is supposed to fixed by salvaging the dir; DirOK will fail and we'll rebuild the directory in CopyAndSalvage. Did you see anything mentioned like "Directory bad" or "Salvaging directory" in the salvage log messages for any of these runs? -- Andrew Deason adeason@sinenomine.net From stephan.wiesand@desy.de Wed Jun 18 18:52:20 2014 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 18 Jun 2014 19:52:20 +0200 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available Message-ID: Thanks to Stephen Quinney, RPMs for Fedora 18/19/20 and Red Hat = Enterprise Linux 5/6 (and clones) are now available. Note that there are no RHEL7 binaries. The release team feels that we = should not continue to provide packages using the old transarc paths for new = Linux platforms, and that we should leave packaging for those to downstream = projects rather than creating FHS compliant packages ourselves. This would mean = that we'd no longer provide any binaries for RHEL7+ and Fedora 21+. Your feedback on this plan is most welcome. --=20 Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From jsbillin@umich.edu Wed Jun 18 19:07:06 2014 From: jsbillin@umich.edu (Jonathan Billings) Date: Wed, 18 Jun 2014 14:07:06 -0400 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available In-Reply-To: References: Message-ID: --047d7b6763b2d313e504fc202090 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 18, 2014 at 1:52 PM, Stephan Wiesand wrote: > Note that there are no RHEL7 binaries. The release team feels that we > should > not continue to provide packages using the old transarc paths for new Linux > platforms, and that we should leave packaging for those to downstream > projects > rather than creating FHS compliant packages ourselves. This would mean that > we'd no longer provide any binaries for RHEL7+ and Fedora 21+. > Do we want to continue development of the RPM spec file in the OpenAFS git tree? Split off a RHEL7/Fedora version? -- Jonathan Billings College of Engineering - CAEN - Unix and Linux Support --047d7b6763b2d313e504fc202090 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 18, 2014 at 1:52 PM, Stephan Wiesand <stephan.wiesand@desy.= de> wrote:
Note that there are no RHEL7 binaries. The release team feels = that we should
not continue to provide packages using the old transarc paths for new Linux=
platforms, and that we should leave packaging for those to downstream proje= cts
rather than creating FHS compliant packages ourselves. This would mean that=
we'd no longer provide any binaries for RHEL7+ and Fedora 21+.

Do we want to cont= inue development of the RPM spec file in the OpenAFS git tree? =C2=A0Split = off a RHEL7/Fedora version?



--
Jonathan Billings <jsbillin@umich.edu>=
College of Engineering - CAEN - Unix and Linux Support

--047d7b6763b2d313e504fc202090-- From jaltman@your-file-system.com Wed Jun 18 19:24:41 2014 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 18 Jun 2014 14:24:41 -0400 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available In-Reply-To: References: Message-ID: <53A1D969.1060101@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms080602080603080603020308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/18/2014 2:07 PM, Jonathan Billings wrote: > On Wed, Jun 18, 2014 at 1:52 PM, Stephan Wiesand > > wrote: >=20 > Note that there are no RHEL7 binaries. The release team feels that > we should > not continue to provide packages using the old transarc paths for > new Linux > platforms, and that we should leave packaging for those to > downstream projects > rather than creating FHS compliant packages ourselves. This would > mean that > we'd no longer provide any binaries for RHEL7+ and Fedora 21+. >=20 >=20 > Do we want to continue development of the RPM spec file in the OpenAFS > git tree? Split off a RHEL7/Fedora version? The consensus of the release team is that we would like some downstream packaging organization to be responsible for deciding how to package OpenAFS for their distribution. Eventually we would like there not to be packaging maintained in the OpenAFS tree. However, we will not cut off users from packaging they are already obtaining from OpenAFS.org for existing major OS revisions. Jeffrey Altman --------------ms080602080603080603020308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhB4 sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSrqYUguvbguthxGNq M15noPYGLMnpjRKT2VS88MxNAZ7RaplB8Azrk8vOH+q+IWnXCrap+BevY27PZW6UgNAPcETG FTi/qdYAukHwnCV7fvjXXJEOw3jg+eK/06bhr0uThvmrjT+jWHlpzK3mSDPtEBSkgXDbLkL/ LQfYvay0Ia7n65l5Ry4zHlrg6uJ+UqvWJZwXazXjo2H4EksGCM4nrKHTeVoj5oSquvqs3tSf BytXLGVqSOHqjXb+lri1gtlovX7AjMT2gdONRrjR3wun6tjHvoqjUNZ2mUs0XXh0vI0GyTKd taz26xY+iKboxFO2atDbb1Gm8KdUXqO/UivlAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAEUyacJvoRfQdglYgnUwaTMsRRg0YeAljbnb8M5E vBSo3u/LhvbXtvu+9uE8R6UOE4GvKH382I27vjuM28oHqfii04URAB1icmA8b7rxYQo9Ob2I /NkkQRBwbA3HGLWXFjupODWbP5WylyySAAI7HxG2xbE4X+8+hMJVOKfxJb6J0SUOBlnmMkmg nAxgOM4venSmli6U3o0nADHNLZEJjqym2QstkeYPhDZ6sSO3t/yv+JyYbfb01hiOdhGsDBif oPTqcWRvA+lqbWMHJG3p9uL/kI4jbLj9/ZkMfdRDHpQNVAuGxxyj7b1pxM0jBuTP0Jmrcz3U wUwT5kjCCDt2gGAxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHiwwaDblI88SsZkARSRB5MwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwNjE4MTgyNDQxWjAjBgkqhkiG9w0BCQQxFgQURPYpVMjOV1m6wRqokZoQhAzn0hswbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQeLDBoNuUjzxKxmQBFJEHkzCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhB4sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBAQUABIIB AHIBpYN/CO6mAZ6VGPF8j1FvhnbEZkVAll2SEaJBGcTT9nbJfvfSRIlEx79QfCXRboSrPriw fnYkJcx3Fp+CqsSWUFt4s+ozoBSDlN8jx+zi7HWnXgEaM+XX7EcKV7zAbKlABvEwbdEnY8Nr CnViw5TLCPgJx8twashEqAVB8VDoNTK2LJJ6Zic3Ry34NrDlqBtQta/JBPN/Jvw7jbh22UCg /+cOfS0pXQnBYcspvmG8Nou1JxtPxVHco4KcX1euA3wrjAd8HzT8AWBSU7DF/bDvW9gaA4kr G/eMmPFXeLGGATAgs+3AIH4lCOpN5d99btcPbe/EOIp2KitzanX5Z7MAAAAAAAA= --------------ms080602080603080603020308-- From stephan.wiesand@desy.de Wed Jun 18 19:32:56 2014 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 18 Jun 2014 20:32:56 +0200 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available In-Reply-To: References: Message-ID: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> On Jun 18, 2014, at 20:07 , Jonathan Billings wrote: > On Wed, Jun 18, 2014 at 1:52 PM, Stephan Wiesand = > wrote: >=20 >> Note that there are no RHEL7 binaries. The release team feels that we >> should >> not continue to provide packages using the old transarc paths for new = Linux >> platforms, and that we should leave packaging for those to downstream >> projects >> rather than creating FHS compliant packages ourselves. This would = mean that >> we'd no longer provide any binaries for RHEL7+ and Fedora 21+. >>=20 >=20 > Do we want to continue development of the RPM spec file in the OpenAFS = git > tree? Split off a RHEL7/Fedora version? Interesting question. My personal opinion is that if we do it at all, = yes we should forge a new spec for RHEL 7+ and Fedora 21+ which does away = with all the legacy. And that it would bitrot quickly unless we actually use = it. And that maintaining the spec is the bigger problem than providing the builds. Thus, probably: "No." --=20 Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From adeason@sinenomine.net Thu Jun 19 00:57:30 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 18 Jun 2014 18:57:30 -0500 Subject: [OpenAFS] Re: additional OpenAFS 1.6.9 binaries available References: Message-ID: <20140618185730.98e386b6dd87c462a6b43f07@sinenomine.net> On Wed, 18 Jun 2014 14:07:06 -0400 Jonathan Billings wrote: > Do we want to continue development of the RPM spec file in the OpenAFS > git tree? Split off a RHEL7/Fedora version? Jeffrey and Stephan have answered this in a couple of different ways, since think there are a few different ways to interpret this question. My opinions: If you're asking "will we continue to develop and support the existing openafs.org RPM packaging for RHEL6 and earlier?" then I think the answer is "yes". This wasn't really brought up in the release-team discussion; I just assumed we would definitely be doing this. If you're asking "will we continue to develop RPM packaging for RHEL7+ in the OpenAFS git tree?" then the answer (so far) is "no". The idea is that the development and coordination of the red hat RPM packaging is done entirely by "rpmfusion" or some other place, and openafs.org is not officially involved with it. While maybe a copy of the packaging could exist in the openafs git tree in some fashion, it would not be the canonical source of the packaging files, and not the place where packagers collaborate with each other on it. The Debian packaging is like this, and I don't think there's been any harm in it existing like that, but I'm also not really sure if it's been helpful. Also, I want to note that while in my mind "openafs.org" is not involved in the packaging in this approach... I mean, at least some of the same people are still going to be involved in one way or another. It just means that the packaging "lives" somewhere else, and the packaging is not tied to openafs release cycles. So, changing the packaging or adding an RHEL-specific patch or something doesn't involve a new version of "openafs". -- Andrew Deason adeason@sinenomine.net From eagle@eyrie.org Thu Jun 19 01:16:25 2014 From: eagle@eyrie.org (Russ Allbery) Date: Wed, 18 Jun 2014 17:16:25 -0700 Subject: [OpenAFS] Re: additional OpenAFS 1.6.9 binaries available In-Reply-To: <20140618185730.98e386b6dd87c462a6b43f07@sinenomine.net> (Andrew Deason's message of "Wed, 18 Jun 2014 18:57:30 -0500") References: <20140618185730.98e386b6dd87c462a6b43f07@sinenomine.net> Message-ID: <87mwd9ah46.fsf@windlord.stanford.edu> Andrew Deason writes: > If you're asking "will we continue to develop RPM packaging for RHEL7+ > in the OpenAFS git tree?" then the answer (so far) is "no". The idea is > that the development and coordination of the red hat RPM packaging is > done entirely by "rpmfusion" or some other place, and openafs.org is not > officially involved with it. While maybe a copy of the packaging could > exist in the openafs git tree in some fashion, it would not be the > canonical source of the packaging files, and not the place where > packagers collaborate with each other on it. The Debian packaging is > like this, and I don't think there's been any harm in it existing like > that, but I'm also not really sure if it's been helpful. > Also, I want to note that while in my mind "openafs.org" is not involved > in the packaging in this approach... I mean, at least some of the same > people are still going to be involved in one way or another. It just > means that the packaging "lives" somewhere else, and the packaging is > not tied to openafs release cycles. So, changing the packaging or adding > an RHEL-specific patch or something doesn't involve a new version of > "openafs". I've always preferred to maintain the Debian packages this way, so I think this is a good decision and will make things somewhat easier for the people doing the packaging. -- Russ Allbery (eagle@eyrie.org) From haba@kth.se Thu Jun 19 11:04:47 2014 From: haba@kth.se (Harald Barth) Date: Thu, 19 Jun 2014 12:04:47 +0200 (CEST) Subject: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140617.150142.3129020045934937.haba@habook> References: <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> <20140617.110300.911747264340771049.haba@habook> <20140617.150142.3129020045934937.haba@habook> Message-ID: <20140619.120447.238832363065635387.haba@habook> On master, this looks like opr_Verify(afs_dir_Delete(&dh, "..") == 0); opr_Verify(afs_dir_Create(&dh, "..", &pa) == 0); I guess that opr_Verify is some new fancy name for Assert? Same patch for master as for 1.6.9 needed? Harald. From adeason@sinenomine.net Thu Jun 19 17:12:55 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 19 Jun 2014 11:12:55 -0500 Subject: [OpenAFS] Re: Salvageserver 1.6.1-3+deb7u1 core dump References: <84FAB404-D9C0-4E47-A33B-0AD70A6C3EAA@desy.de> <20140617.110300.911747264340771049.haba@habook> <20140617.150142.3129020045934937.haba@habook> <20140619.120447.238832363065635387.haba@habook> Message-ID: <20140619111255.d3e31d3e566aee945e66145d@sinenomine.net> On Thu, 19 Jun 2014 12:04:47 +0200 (CEST) Harald Barth wrote: > On master, this looks like > > opr_Verify(afs_dir_Delete(&dh, "..") == 0); > opr_Verify(afs_dir_Create(&dh, "..", &pa) == 0); > > I guess that opr_Verify is some new fancy name for Assert? > Same patch for master as for 1.6.9 needed? Yes, opr_Verify is supposed to mean "assert, but if asserts are turned off still run the code". But if you just remove the assert here, you are not fixing the problem. All directories are supposed to have a .. entry by this point; if you mask the problem and never investigate what's going on here, we lose all hope of identifying and fixing the actual bug. -- Andrew Deason adeason@sinenomine.net From haba@kth.se Thu Jun 19 18:05:02 2014 From: haba@kth.se (Harald Barth) Date: Thu, 19 Jun 2014 19:05:02 +0200 (CEST) Subject: [OpenAFS] Re: Salvageserver 1.6.1-3+deb7u1 core dump In-Reply-To: <20140619111255.d3e31d3e566aee945e66145d@sinenomine.net> References: <20140617.150142.3129020045934937.haba@habook> <20140619.120447.238832363065635387.haba@habook> <20140619111255.d3e31d3e566aee945e66145d@sinenomine.net> Message-ID: <20140619.190502.2250681970103144931.haba@habook> > All directories are supposed to have a .. entry by this point I disagree. Not if something has removed "..". For example a buggy salvager like 1.6.1. Or bitrot. Or whatever. As this is a salvage program, that should not core dump even if unexpected things happen, I think it is very very very hard to justify such a assert in production code for the salvager. Especially because the next layer that does call the salvager does not handle that the salvager asserts. Harald. From adeason@sinenomine.net Thu Jun 19 19:18:08 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 19 Jun 2014 13:18:08 -0500 Subject: [OpenAFS] Re: Salvageserver 1.6.1-3+deb7u1 core dump References: <20140617.150142.3129020045934937.haba@habook> <20140619.120447.238832363065635387.haba@habook> <20140619111255.d3e31d3e566aee945e66145d@sinenomine.net> <20140619.190502.2250681970103144931.haba@habook> Message-ID: <20140619131808.065f54275f5e0ffe5c17fe33@sinenomine.net> On Thu, 19 Jun 2014 19:05:02 +0200 (CEST) Harald Barth wrote: > > All directories are supposed to have a .. entry by this point > > I disagree. Not if something has removed "..". For example a buggy > salvager like 1.6.1. If the directory on disk is missing a ".." entry for any reason, the salvager is supposed to detect that and rebuild the directory, adding a ".." entry. If we are not doing that, something is wrong in the processing, possibly also leading to any number of additional problems. I already mentioned this, how DirOK should fail and CopyAndSalvage will fix the dir. I do not know how to make this more clear. (I could be wrong, of course, if you think this conclusion is incorrect.) > Or bitrot. Or whatever. As this is a salvage program, that should not > core dump even if unexpected things happen, I think it is very very > very hard to justify such a assert in production code for the > salvager. Especially because the next layer that does call the > salvager does not handle that the salvager asserts. Well, maybe. I'm not necessarily saying to keep the assert; just that removing it must not be the _only_ thing you do. There is another bug here (probably), and ignoring it will just make it worse. Aside from that, I think there is an argument to be made for not just ignoring an ENOENT error there. If there is any unexpected inconsistency in the salvager that we ignore, we risk giving corrupted data to users. Without an option to let the user decide one way or the other, the danger of serving corrupted data is much more grave than the danger of keeping a volume offline. I'm not sure if I would argue against ignoring that error in this particular case, but that side of the argument needs to not be lost. -- Andrew Deason adeason@sinenomine.net From andreas.lehner@verdi.de Fri Jun 20 11:35:26 2014 From: andreas.lehner@verdi.de (Andreas Lehner) Date: Fri, 20 Jun 2014 12:35:26 +0200 Subject: [OpenAFS] OpenAFS 1.6.9 EL5 repository metadata Message-ID: <20140620103526.GA89683@triton.guardian.de> Hello. The OpenAFS 1.6.9 binaries provided for Red Hat Enterprise Linux 5[0] carry a defective repomd.xml[1]. EL5 provides versions of yum and hashing libraries that are incapable of computing sha256 checksums. Previous OpenAFS releases were created using sha checksums[2]. The packages seem to have been built on EL6 or current Fedora. Newer versions of createrepo on EL6 use sha256 by default as opposed to sha in previous versions. Passing "--checksum sha" to createrepo should remedy the issue. Best regards Andreas Lehner [0] https://lists.openafs.org/pipermail/openafs-info/2014-June/040734.html [1] http://dl.openafs.org/dl/openafs/1.6.9/rhel5/i386/repodata/repomd.xml [2] http://dl.openafs.org/dl/openafs/1.6.8/rhel5/i386/repodata/repomd.xml -- ver.di - Vereinte Dienstleistungsgewerkschaft Bundesverwaltung Ressort 1 Infrastrukturmanagement Paula-Thiede-Ufer 10 10179 Berlin V +49 30 6956-1027 E andreas.lehner@verdi.de From stephen@jadevine.org.uk Fri Jun 20 11:55:20 2014 From: stephen@jadevine.org.uk (Stephen Quinney) Date: Fri, 20 Jun 2014 11:55:20 +0100 Subject: [OpenAFS] OpenAFS 1.6.9 EL5 repository metadata In-Reply-To: <20140620103526.GA89683@triton.guardian.de> References: <20140620103526.GA89683@triton.guardian.de> Message-ID: --bcaec51ba27b66730004fc42547a Content-Type: text/plain; charset=UTF-8 Apologies, that was caused by me manually regenerating the repodata for EL5 from an EL6 machine without using checksum option. I'll fix the repodata now, it will take a little while before it reaches the public repository. Stephen On 20 June 2014 11:35, Andreas Lehner wrote: > Hello. > > The OpenAFS 1.6.9 binaries provided for Red Hat Enterprise Linux 5[0] > carry a defective repomd.xml[1]. EL5 provides versions of yum and > hashing libraries that are incapable of computing sha256 checksums. > Previous OpenAFS releases were created using sha checksums[2]. > > The packages seem to have been built on EL6 or current Fedora. Newer > versions of createrepo on EL6 use sha256 by default as opposed to sha in > previous versions. Passing "--checksum sha" to createrepo should remedy > the issue. > > Best regards > Andreas Lehner > > [0] > https://lists.openafs.org/pipermail/openafs-info/2014-June/040734.html > [1] > http://dl.openafs.org/dl/openafs/1.6.9/rhel5/i386/repodata/repomd.xml > [2] > http://dl.openafs.org/dl/openafs/1.6.8/rhel5/i386/repodata/repomd.xml > -- > ver.di - Vereinte Dienstleistungsgewerkschaft > Bundesverwaltung Ressort 1 > Infrastrukturmanagement > Paula-Thiede-Ufer 10 > 10179 Berlin > V +49 30 6956-1027 > E andreas.lehner@verdi.de > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --bcaec51ba27b66730004fc42547a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies, that was caused by me manually regeneratin= g the repodata for EL5 from an EL6 machine without using checksum option. I= 'll fix the repodata now, it will take a little while before it reaches= the public repository.

Stephen


On 20 June 2014 11:35, Andreas Lehner <<= a href=3D"mailto:andreas.lehner@verdi.de" target=3D"_blank">andreas.lehner@= verdi.de> wrote:
Hello.

The OpenAFS 1.6.9 binaries provided for Red Hat Enterprise Linux 5[0]
carry a defective repomd.xml[1]. EL5 provides versions of yum and
hashing libraries that are incapable of computing sha256 checksums.
Previous OpenAFS releases were created using sha checksums[2].

The packages seem to have been built on EL6 or current Fedora. Newer
versions of createrepo on EL6 use sha256 by default as opposed to sha in previous versions. Passing "--checksum sha" to createrepo should = remedy
the issue.

Best regards
=C2=A0 Andreas Lehner

[0]
https://lists.openafs.org/pipermail/openafs-info/= 2014-June/040734.html
[1]
http://dl.openafs.org/dl/openafs/1.6.9/rhel5/i386/= repodata/repomd.xml
[2]
http://dl.openafs.org/dl/openafs/1.6.8/rhel5/i386/= repodata/repomd.xml
--
ver.di - Vereinte Dienstleistungsgewerkschaft
Bundesverwaltung Ressort 1
Infrastrukturmanagement
Paula-Thiede-Ufer 10
10179 Berlin
V +49 30 6956-1027
E andreas.lehner@verdi.de _______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info

--bcaec51ba27b66730004fc42547a-- From stephan.wiesand@desy.de Fri Jun 20 12:06:49 2014 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Fri, 20 Jun 2014 13:06:49 +0200 Subject: [OpenAFS] OpenAFS 1.6.9 EL5 repository metadata In-Reply-To: References: <20140620103526.GA89683@triton.guardian.de> Message-ID: <75DBA1E4-2BB6-456C-BA05-EF8BFA37D3AB@desy.de> Uploaded. Thanks for the report and the quick reaction. Stephan On 2014-06-20, at 12:55, Stephen Quinney = wrote: > Apologies, that was caused by me manually regenerating the repodata = for EL5 from an EL6 machine without using checksum option. I'll fix the = repodata now, it will take a little while before it reaches the public = repository. >=20 > Stephen >=20 >=20 > On 20 June 2014 11:35, Andreas Lehner wrote: > Hello. >=20 > The OpenAFS 1.6.9 binaries provided for Red Hat Enterprise Linux 5[0] > carry a defective repomd.xml[1]. EL5 provides versions of yum and > hashing libraries that are incapable of computing sha256 checksums. > Previous OpenAFS releases were created using sha checksums[2]. >=20 > The packages seem to have been built on EL6 or current Fedora. Newer > versions of createrepo on EL6 use sha256 by default as opposed to sha = in > previous versions. Passing "--checksum sha" to createrepo should = remedy > the issue. >=20 > Best regards > Andreas Lehner >=20 > [0] > https://lists.openafs.org/pipermail/openafs-info/2014-June/040734.html > [1] > http://dl.openafs.org/dl/openafs/1.6.9/rhel5/i386/repodata/repomd.xml > [2] > http://dl.openafs.org/dl/openafs/1.6.8/rhel5/i386/repodata/repomd.xml --=20 Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany From erik.braun@uni-jena.de Fri Jun 20 14:55:05 2014 From: erik.braun@uni-jena.de (Erik Braun) Date: Fri, 20 Jun 2014 15:55:05 +0200 (CEST) Subject: [OpenAFS] (stackable file system) aufs stalls on some operations over OpenAFS Message-ID: Hi, I discussed this topic almost 3 months ago on the aufs mailing list, but had at this time other things to do. Now I can look at this problem again, since it is still present in Debian Testing with OpenAFS 1.6.9 and the shipped Linux kernel 3.14.7. In short, the computer stalls on some file operations when stacking an aufs directory above an OpenAFS directory, no matter, if the OpenAFS is writable or not. The author of aufs sees the problem (specifically from his point of view as not an expert for OpenAFS) in lock operations in OpenAFS and suggested to ask the OpenAFS maintainers. For more information, please see the entire thread here: http://sourceforge.net/p/aufs/mailman/aufs-users/thread/23314.1396280308%40jrobl/ Please tell me, when you need more information. with best regards. Erik From adeason@sinenomine.net Fri Jun 20 16:41:31 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 20 Jun 2014 10:41:31 -0500 Subject: [OpenAFS] Re: (stackable file system) aufs stalls on some operations over OpenAFS In-Reply-To: References: Message-ID: <20140620104131.bdc85e47a41ec35d1b100eaa@sinenomine.net> On Fri, 20 Jun 2014 15:55:05 +0200 (CEST) Erik Braun wrote: > In short, the computer stalls on some file operations when stacking an > aufs directory above an OpenAFS directory, no matter, if the OpenAFS > is writable or not. > > The author of aufs sees the problem (specifically from his point of > view as not an expert for OpenAFS) in lock operations in OpenAFS and > suggested to ask the OpenAFS maintainers. > > For more information, please see the entire thread here: > http://sourceforge.net/p/aufs/mailman/aufs-users/thread/23314.1396280308%40jrobl/ [Moving to -devel, from -info] To help anyone to not have to read through all that, a summary: - aufs tries to copy a file from AFS into a local fs - In order to prevent the source file from changing while being copied, aufs locks i_mutex on the file, and then calls dentry_open - In openafs, dentry_open goes afs_linux_open -> afs_open -> osi_FlushPages -> osi_VM_FlushPages -> afs_linux_lock_inode, which of course also locks i_mutex. So we deadlock. And Erik posted an example strace here: with some kernel logs and backtraces here: That lock in osi_VM_FlushPages was added in b0ed5a7facb1951f2f4ef8ed3da29a6a80cb7d49, but we're supposed to lock the inode there; we can't just get rid of that. The aufs developer thinks that us locking i_mutex in .open is unusual, and that we shouldn't do that. I assume the other option is to flush pages in all of the other relevant entry points (mmap, read, etc) instead, which it seems like we already do. So maybe we do not need to FlushPages in .open on Linux? But I'm not sure if that's a behavior change or there's some other problem. I am also not sure why aufs doesn't just lock i_mutex after dentry_open'ing; I don't immediately see what it would be protecting before the dentry_open. -- Andrew Deason adeason@sinenomine.net From botsch@cnf.cornell.edu Wed Jun 25 16:39:12 2014 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 25 Jun 2014 11:39:12 -0400 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available In-Reply-To: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> References: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> Message-ID: <20140625153912.GA14020@cnf.cornell.edu> At the very least, I'd like to see a spec included in the source so that one can rebuild on one's own the binaries from the source (on at least the base RHEL and current Fedora). IMHO, not offering binaries and telling users to go someplace else is not perceived as friendly to the users... UNLESS.. there is a direct pointer to said trusted 3rd party binary builder. Especially if binaries are available for Mac and Windows... it comes off as a "screw you" to linux users. On Wed, Jun 18, 2014 at 08:32:56PM +0200, Stephan Wiesand wrote: > > On Jun 18, 2014, at 20:07 , Jonathan Billings wrote: > > > On Wed, Jun 18, 2014 at 1:52 PM, Stephan Wiesand > > wrote: > > > >> Note that there are no RHEL7 binaries. The release team feels that we > >> should > >> not continue to provide packages using the old transarc paths for new Linux > >> platforms, and that we should leave packaging for those to downstream > >> projects > >> rather than creating FHS compliant packages ourselves. This would mean that > >> we'd no longer provide any binaries for RHEL7+ and Fedora 21+. > >> > > > > Do we want to continue development of the RPM spec file in the OpenAFS git > > tree? Split off a RHEL7/Fedora version? > > > Interesting question. My personal opinion is that if we do it at all, yes > we should forge a new spec for RHEL 7+ and Fedora 21+ which does away with > all the legacy. And that it would bitrot quickly unless we actually use it. > And that maintaining the spec is the bigger problem than providing the > builds. > > Thus, probably: "No." > > -- > Stephan Wiesand > DESY -DV- > Platanenenallee 6 > 15738 Zeuthen, Germany > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- ******************************** David William Botsch Programmer/Analyst @CNFComputing botsch@cnf.cornell.edu ******************************** From jaltman@your-file-system.com Wed Jun 25 17:16:00 2014 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 25 Jun 2014 12:16:00 -0400 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available In-Reply-To: <20140625153912.GA14020@cnf.cornell.edu> References: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> <20140625153912.GA14020@cnf.cornell.edu> Message-ID: <53AAF5C0.6020502@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms030500080509040102020002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/25/2014 11:39 AM, Dave Botsch wrote: > At the very least, I'd like to see a spec included in the source so > that one can rebuild on one's own the binaries from the source (on at > least the base RHEL and current Fedora). The underlying issue is what should be in the spec file and who is going to maintain it? Its not like there is a single distribution of Linux. Each distribution has its own requirements and preferences for how applications, daemons, and kernel modules should be installed and configured. The spec file currently in the OpenAFS tree is in violation of many of the Fedora and RHEL guidelines. For starters, the use of transarc paths instead of FHS is a big issue. For RHEL7 there is significant work that needs to be done to produce compliant packaging. For Fedora, the rpm fusion packaging is much closer to what the community wants to see. For RHEL, the ElRepo packaging is much closer to what is required for RHEL7. It is our view that given available resources that downstream distributions should package OpenAFS and end users should work with the downstream distributions to determine how those packages should function. One of the primary benefits of this approach is that downstream packagers do not need to wait for new OpenAFS releases to distribute packages that support new kernel releases or address other distribution specific functionality. > IMHO, not offering binaries and telling users to go someplace else is > not perceived as friendly to the users... UNLESS.. there is a direct > pointer to said trusted 3rd party binary builder. Especially if binarie= s > are available for Mac and Windows... it comes off as a "screw you" to > linux users. Funny you should bring up OSX and Windows. For OSX the packaging is now two OS revisions out of date. Installers cannot be built for Mavericks or Yosemite with current build tools. The installers can only be built using the development tool chain for Mountain Lion. On Windows, the packaging scripts have not been updated in almost six years. They cannot be built using current versions of the WiX tool chain. They do not support merge modules and do not support installing 32-bit and 64-bit components in the same msi. Installation packaging is hard. In some ways it is harder than writing the file system. Both the OSX and Windows installation packaging requires a total rewrite. If there was a downstream source that could take responsibility for doing that work, we would ask them to do so. The way things are at present OSX and Windows are simply limping along. Jeffrey Altman --------------ms030500080509040102020002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhB4 sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSrqYUguvbguthxGNq M15noPYGLMnpjRKT2VS88MxNAZ7RaplB8Azrk8vOH+q+IWnXCrap+BevY27PZW6UgNAPcETG FTi/qdYAukHwnCV7fvjXXJEOw3jg+eK/06bhr0uThvmrjT+jWHlpzK3mSDPtEBSkgXDbLkL/ LQfYvay0Ia7n65l5Ry4zHlrg6uJ+UqvWJZwXazXjo2H4EksGCM4nrKHTeVoj5oSquvqs3tSf BytXLGVqSOHqjXb+lri1gtlovX7AjMT2gdONRrjR3wun6tjHvoqjUNZ2mUs0XXh0vI0GyTKd taz26xY+iKboxFO2atDbb1Gm8KdUXqO/UivlAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAEUyacJvoRfQdglYgnUwaTMsRRg0YeAljbnb8M5E vBSo3u/LhvbXtvu+9uE8R6UOE4GvKH382I27vjuM28oHqfii04URAB1icmA8b7rxYQo9Ob2I /NkkQRBwbA3HGLWXFjupODWbP5WylyySAAI7HxG2xbE4X+8+hMJVOKfxJb6J0SUOBlnmMkmg nAxgOM4venSmli6U3o0nADHNLZEJjqym2QstkeYPhDZ6sSO3t/yv+JyYbfb01hiOdhGsDBif oPTqcWRvA+lqbWMHJG3p9uL/kI4jbLj9/ZkMfdRDHpQNVAuGxxyj7b1pxM0jBuTP0Jmrcz3U wUwT5kjCCDt2gGAxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHiwwaDblI88SsZkARSRB5MwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwNjI1MTYxNjAwWjAjBgkqhkiG9w0BCQQxFgQURdM4qh0K/MXS4toaZtWyDv1ogHUwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQeLDBoNuUjzxKxmQBFJEHkzCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhB4sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBAQUABIIB AI5SuB+miRf9jdC3UmEgTYxRx4QKCqtAbcIMX/RCi5OrOg3ckRb6B4e0Srd1uYeZZ5DL7fGw W5LzZpTWg0tp/r4p2JGVRHNJR753vK9S9hTsp/tYs/YG23nc5WlPXdAsrlTywA++BPvR09FU XoCESlyBw1GW3/SWMs/X8MX6hhRrleQHTfJf665VMdx38h/3JUQBCbz6GPAn+tWUdBdKq/WZ hFrkOKYOdTb3Fi8U4XixnUC6OqmqxTsm4S+bSfJUtJboCn+mTd72Bt4GZXjkm0guuFY5Icrt /Oe1/LlrCgOSiDHMP5FxfuMtpgenA4hqyOkyw1hDC0gZhv36Uacg4dMAAAAAAAA= --------------ms030500080509040102020002-- From stephan.wiesand@desy.de Wed Jun 25 18:28:29 2014 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 25 Jun 2014 19:28:29 +0200 Subject: [OpenAFS] additional OpenAFS 1.6.9 binaries available In-Reply-To: <53AAF5C0.6020502@your-file-system.com> References: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> <20140625153912.GA14020@cnf.cornell.edu> <53AAF5C0.6020502@your-file-system.com> Message-ID: <18F57A0B-B1F9-4CA9-AD42-EFC4418A3EF0@desy.de> On Jun 25, 2014, at 18:16 , Jeffrey Altman wrote: > On 6/25/2014 11:39 AM, Dave Botsch wrote: >> At the very least, I'd like to see a spec included in the source so >> that one can rebuild on one's own the binaries from the source (on at >> least the base RHEL and current Fedora). > > The underlying issue is what should be in the spec file and who is going > to maintain it? Its not like there is a single distribution of Linux. > Each distribution has its own requirements and preferences for how > applications, daemons, and kernel modules should be installed and > configured. Having a reference spec for one platform in the tree would still be good. I do share your concern regarding its maintenance though. > The spec file currently in the OpenAFS tree is in violation of many of > the Fedora and RHEL guidelines. For starters, the use of transarc paths > instead of FHS is a big issue. For RHEL7 there is significant work that > needs to be done to produce compliant packaging. Strictly speaking, the FHS "violation" is not an actual issue unless /usr is immutable. And that's only just begun to be a concern with "atomic" deployment / rpm-ostree. And that's in its infancy. And at least for client systems, a workaround seems feasible. But I agree that that's not the way forward in the long run. > For Fedora, the rpm fusion packaging is much closer to what the > community wants to see. I'm not sure. Significant parts of the existing community may still be using transarc paths and not keen on this change. Attracting new community members with transarc paths is probably difficult though. > For RHEL, the ElRepo packaging is much closer > to what is required for RHEL7. RHEL7 itself doesn't require anything special. It's rather us saying that on a new platform (with 10 years of support life) we don't want to continue with something that's already looking baroque. But yes, it would be good to leave the packaging to downstream. Alas, the ELRepo packaging handles the kernel modules in a way the OpenAFS developers clearly disapprove of, and I'm not sure that's fixable. > It is our view that given available > resources that downstream distributions should package OpenAFS and end > users should work with the downstream distributions to determine how > those packages should function. > > One of the primary benefits of this approach is that downstream > packagers do not need to wait for new OpenAFS releases to distribute > packages that support new kernel releases or address other distribution > specific functionality. > >> IMHO, not offering binaries and telling users to go someplace else is >> not perceived as friendly to the users... UNLESS.. there is a direct >> pointer to said trusted 3rd party binary builder. Especially if binaries >> are available for Mac and Windows... it comes off as a "screw you" to >> linux users. If that's what my previous message conveyed, I'm really sorry. But note that we only ever provided a spec for EL/Fedora, and uploaded binaries for those built from that spec - and for SUSE built from something entirely different. Debian/Ubuntu packaging has been done downstream for a long time, and the same holds for other distributions. On the other hand, "configure; make; make install" is still supposed to work on any Linux distribution. And that's all several other platforms ever had. > Funny you should bring up OSX and Windows. For OSX the packaging is > now two OS revisions out of date. Installers cannot be built for > Mavericks or Yosemite with current build tools. The installers can > only be built using the development tool chain for Mountain Lion. And no more volunteers for doing it either. I'm really glad Ken H. helped us out with such an installer so we have something that can be installed "easily" on Mavericks when I approached him. But that's hardly a sustainable model. > On Windows, the packaging scripts have not been updated in almost six > years. They cannot be built using current versions of the WiX tool > chain. They do not support merge modules and do not support installing > 32-bit and 64-bit components in the same msi. > > Installation packaging is hard. In some ways it is harder than writing > the file system. Both the OSX and Windows installation packaging > requires a total rewrite. If there was a downstream source that could > take responsibility for doing that work, we would ask them to do so. > The way things are at present OSX and Windows are simply limping along. > > Jeffrey Altman -- Stephan Wiesand From jm130794@gmail.com Wed Jun 25 20:55:59 2014 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Wed, 25 Jun 2014 21:55:59 +0200 Subject: [OpenAFS] Cannot create directory with Nautilus Message-ID: <53AB294F.1070706@gmail.com> Hello, At work, I can create a directory in my $HOME with Nautilus (Debian Wheezy). My problem is with my personal computer (Ubuntu 12.04). I can't create a directory in my $HOME on the same OpenAFS server. Menus are disabled. I must create directory with mkdir. And you, how do you do ? Thanks, Jean-Marc From haba@kth.se Thu Jun 26 08:53:48 2014 From: haba@kth.se (Harald Barth) Date: Thu, 26 Jun 2014 09:53:48 +0200 (CEST) Subject: [OpenAFS] Cannot create directory with Nautilus In-Reply-To: <53AB294F.1070706@gmail.com> References: <53AB294F.1070706@gmail.com> Message-ID: <20140626.095348.1094714794581146387.haba@habook> > At work, I can create a directory in my $HOME with Nautilus (Debian > Wheezy). My problem is with my personal computer (Ubuntu 12.04). I > can't create a directory in my $HOME on the same OpenAFS server. Menus > are disabled. I must create directory with mkdir. And you, how do you > do ? I think Nautilus is to blame who thinks it can not do it because of UID and Unix permissions and therefore does not even try. What is your UID at work? (guess: not 1000) What is your UID on your home computer? (guess: 1000) I would change the UID on the home computer to match the UID on the work computer to work around the problem. I think we had this discussion before, a long time ago. Did we get any feedback from the Nautilus folks? Harald. From adeason@sinenomine.net Thu Jun 26 16:19:47 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 26 Jun 2014 08:19:47 -0700 Subject: [OpenAFS] Re: additional OpenAFS 1.6.9 binaries available References: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> <20140625153912.GA14020@cnf.cornell.edu> Message-ID: <20140626081947.01004586148d059b2383b02f@sinenomine.net> On Wed, 25 Jun 2014 11:39:12 -0400 Dave Botsch wrote: > IMHO, not offering binaries and telling users to go someplace else is > not perceived as friendly to the users... UNLESS.. Well, this is what some users have asked for. (Maybe not this specifically, but complaining about how the current model of RPM distribution is awkward and AFS-specific.) It seems to me rather unfriendly and strange on Linux to ask users to keep going to the upstream website for a piece of software. That would be infeasible if I had to do that for every piece of software that I use. OpenAFS is currently a bit of a special case here, and making it act like all other open/free software would be an improvement. And yeah, there would/should be a pointer like "RHEL/whatever users get your binaries from " or "... from ". Just like it often says on various upstreams' "download" page to just "apt-get install foo" or "yum intall foo". I think there is an article or something that I saw on some Debian-ish site explaining the benefits of separating upstream source from downstream packaging, but I'm not sure where it is. > Especially if binaries are available for Mac and Windows... I wish OS X and Windows worked this way, too; the OS X and Windows binaries are being provided because we cannot do it the other way. (At least, that's why I am not arguing for it there.) With Windows, I don't think any such "downstream" exists that is useable to us. And in general the historical practice/culture on Windows that end-users are used to is indeed just googling for the software, and clicking on and installing the first thing that comes up. Which is satisfied by the current approach. OS X has a few things like fink, macports, and brew, but that would be an extra big "thing" you'd have to install, which is pretty terrible to ask of users. I also don't know if those work with kernel modules at all, and some have had some questionable robustness in the past. And of course, there is currently not enough effort put into the OS X packaging right now to do any such migration. The other platforms are largely like this, too. Solaris doesn't have an appropriate downstream: Illumos/oi we could probably do, but that only helps for Illumos. Relying on OpenCSW means we'd have an extra pre-requisite that is just not practical at many sites. AIX I think has some common 3rd-party software repository that I forget the name of, but I haven't cared enough about AIX recently to look into it more. I'm not sure if it's useful. The *BSDs have their ports, and we are using that for FreeBSD. I'm honestly not sure why we are not relying on that for binaries. SuSE I think doesn't have a repository for software that they won't include in openSuSE itself. -- Andrew Deason adeason@sinenomine.net From ballbery@sinenomine.net Thu Jun 26 16:29:14 2014 From: ballbery@sinenomine.net (Brandon Allbery) Date: Thu, 26 Jun 2014 15:29:14 +0000 Subject: [OpenAFS] Re: additional OpenAFS 1.6.9 binaries available In-Reply-To: <20140626081947.01004586148d059b2383b02f@sinenomine.net> References: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> <20140625153912.GA14020@cnf.cornell.edu> <20140626081947.01004586148d059b2383b02f@sinenomine.net> Message-ID: <1403796554.42189.21.camel@vikktakkht.oh3.sinenomine.net> T24gVGh1LCAyMDE0LTA2LTI2IGF0IDA4OjE5IC0wNzAwLCBBbmRyZXcgRGVhc29uIHdyb3RlOg0K PiBPUyBYIGhhcyBhIGZldyB0aGluZ3MgbGlrZSBmaW5rLCBtYWNwb3J0cywgYW5kIGJyZXcsIGJ1 dCB0aGF0IHdvdWxkIGJlDQo+IGFuIGV4dHJhIGJpZyAidGhpbmciIHlvdSdkIGhhdmUgdG8gaW5z dGFsbCwgd2hpY2ggaXMgcHJldHR5IHRlcnJpYmxlIHRvDQo+IGFzayBvZiB1c2Vycy4gSSBhbHNv IGRvbid0IGtub3cgaWYgdGhvc2Ugd29yayB3aXRoIGtlcm5lbCBtb2R1bGVzIGF0DQo+IGFsbCwg YW5kIHNvbWUgaGF2ZSBoYWQgc29tZSBxdWVzdGlvbmFibGUgcm9idXN0bmVzcyBpbiB0aGUgcGFz dC4gQW5kIG9mDQo+IGNvdXJzZSwgdGhlcmUgaXMgY3VycmVudGx5IG5vdCBlbm91Z2ggZWZmb3J0 IHB1dCBpbnRvIHRoZSBPUyBYIHBhY2thZ2luZw0KPiByaWdodCBub3cgdG8gZG8gYW55IHN1Y2gg bWlncmF0aW9uLg0KDQpNYWNQb3J0cyBjYW4gY2VydGFpbmx5IGRvIGl0IC0tLSBidXQgSSBhdCBs ZWFzdCBhbSB0b28gdW5mYW1pbGlhciB3aXRoDQp3aGF0IGl0IHRha2VzIHRvIGdldCBPcGVuQUZT IGluc3RhbGxlZCBhbmQgd29ya2luZyBvbiBPUyBYIHRvIHRyeSB0bw0Kd2hpcCB1cCBQb3J0Zmls ZXMuDQoNCj4gU3VTRSBJIHRoaW5rIGRvZXNuJ3QgaGF2ZSBhIHJlcG9zaXRvcnkgZm9yIHNvZnR3 YXJlIHRoYXQgdGhleSB3b24ndA0KPiBpbmNsdWRlIGluIG9wZW5TdVNFIGl0c2VsZi4NCg0KaHR0 cHM6Ly9lbi5vcGVuc3VzZS5vcmcvQWRkaXRpb25hbF9wYWNrYWdlX3JlcG9zaXRvcmllcw0KaW4g cGFydGljdWxhciB0aGV5IGhhdmUgYSBCdWlsZCBTZXJ2aWNlIHdoaWNoIGNyZWF0ZXMgbm90IG9u bHkgcGFja2FnZXMNCmJ1dCBhbHNvIHBhY2thZ2UgcmVwb3MuDQoNCi0tIA0KYnJhbmRvbiBzIGFs bGJlcnkga2Y4bmggICAgICAgICAgICAgICAgICAgICAgICAgICBzaW5lIG5vbWluZSBhc3NvY2lh dGVzDQphbGxiZXJ5LmJAZ21haWwuY29tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFs bGJlcnlAc2luZW5vbWluZS5uZXQNCnVuaXgsIG9wZW5hZnMsIGtlcmJlcm9zLCBpbmZyYXN0cnVj dHVyZSwgeG1vbmFkICAgIGh0dHA6Ly9zaW5lbm9taW5lLm5ldA0KDQo= From adeason@sinenomine.net Thu Jun 26 16:53:37 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 26 Jun 2014 08:53:37 -0700 Subject: [OpenAFS] Re: Cannot create directory with Nautilus References: <53AB294F.1070706@gmail.com> <20140626.095348.1094714794581146387.haba@habook> Message-ID: <20140626085337.b0914e31040a20c0c8542de4@sinenomine.net> On Thu, 26 Jun 2014 09:53:48 +0200 (CEST) Harald Barth wrote: > > At work, I can create a directory in my $HOME with Nautilus (Debian > > Wheezy). My problem is with my personal computer (Ubuntu 12.04). I > > can't create a directory in my $HOME on the same OpenAFS server. Menus > > are disabled. I must create directory with mkdir. And you, how do you > > do ? > > I think Nautilus is to blame who thinks it can not do it because of > UID and Unix permissions and therefore does not even try. > > What is your UID at work? (guess: not 1000) > What is your UID on your home computer? (guess: 1000) > > I would change the UID on the home computer to match the UID on the > work computer to work around the problem. Or you could 'chmod $HOME o+rwx', if it's just looking at unix permissions. That might break some other software, though, that thinks the permissions are too broad. I'd suggest at least trying one of these, at least temporarily, to see if that's what nautilus is indeed checking. A brief look into the code makes it look like nautilus 3.4.1 is getting the writeability from glib, and glib 2.32.1 is indeed properly using access(), so it may be something else. But gnome is complex, so maybe I got that wrong. -- Andrew Deason adeason@sinenomine.net From christof.hanke@rzg.mpg.de Fri Jun 27 08:24:44 2014 From: christof.hanke@rzg.mpg.de (Christof Hanke) Date: Fri, 27 Jun 2014 09:24:44 +0200 Subject: [OpenAFS] Re: additional OpenAFS 1.6.9 binaries available In-Reply-To: <1403796554.42189.21.camel@vikktakkht.oh3.sinenomine.net> References: <3B3984CB-44D6-4C93-AD47-5B9B94887008@desy.de> <20140625153912.GA14020@cnf.cornell.edu> <20140626081947.01004586148d059b2383b02f@sinenomine.net> <1403796554.42189.21.camel@vikktakkht.oh3.sinenomine.net> Message-ID: <20140627092444.38df5c78@dijon.rzg.mpg.de> LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUaHUs IDI2IEp1biAyMDE0IDE1OjI5OjE0ICswMDAwDQpCcmFuZG9uIEFsbGJlcnkgPGJhbGxiZXJ5QHNp bmVub21pbmUubmV0PiB3cm90ZToNCg0KPiBPbiBUaHUsIDIwMTQtMDYtMjYgYXQgMDg6MTkgLTA3 MDAsIEFuZHJldyBEZWFzb24gd3JvdGU6DQo+ID4gT1MgWCBoYXMgYSBmZXcgdGhpbmdzIGxpa2Ug ZmluaywgbWFjcG9ydHMsIGFuZCBicmV3LCBidXQgdGhhdCB3b3VsZCBiZQ0KPiA+IGFuIGV4dHJh IGJpZyAidGhpbmciIHlvdSdkIGhhdmUgdG8gaW5zdGFsbCwgd2hpY2ggaXMgcHJldHR5IHRlcnJp YmxlIHRvDQo+ID4gYXNrIG9mIHVzZXJzLiBJIGFsc28gZG9uJ3Qga25vdyBpZiB0aG9zZSB3b3Jr IHdpdGgga2VybmVsIG1vZHVsZXMgYXQNCj4gPiBhbGwsIGFuZCBzb21lIGhhdmUgaGFkIHNvbWUg cXVlc3Rpb25hYmxlIHJvYnVzdG5lc3MgaW4gdGhlIHBhc3QuIEFuZCBvZg0KPiA+IGNvdXJzZSwg dGhlcmUgaXMgY3VycmVudGx5IG5vdCBlbm91Z2ggZWZmb3J0IHB1dCBpbnRvIHRoZSBPUyBYIHBh Y2thZ2luZw0KPiA+IHJpZ2h0IG5vdyB0byBkbyBhbnkgc3VjaCBtaWdyYXRpb24uDQo+IA0KPiBN YWNQb3J0cyBjYW4gY2VydGFpbmx5IGRvIGl0IC0tLSBidXQgSSBhdCBsZWFzdCBhbSB0b28gdW5m YW1pbGlhciB3aXRoDQo+IHdoYXQgaXQgdGFrZXMgdG8gZ2V0IE9wZW5BRlMgaW5zdGFsbGVkIGFu ZCB3b3JraW5nIG9uIE9TIFggdG8gdHJ5IHRvDQo+IHdoaXAgdXAgUG9ydGZpbGVzLg0KPiANCj4g PiBTdVNFIEkgdGhpbmsgZG9lc24ndCBoYXZlIGEgcmVwb3NpdG9yeSBmb3Igc29mdHdhcmUgdGhh dCB0aGV5IHdvbid0DQo+ID4gaW5jbHVkZSBpbiBvcGVuU3VTRSBpdHNlbGYuDQo+IA0KPiBodHRw czovL2VuLm9wZW5zdXNlLm9yZy9BZGRpdGlvbmFsX3BhY2thZ2VfcmVwb3NpdG9yaWVzDQo+IGlu IHBhcnRpY3VsYXIgdGhleSBoYXZlIGEgQnVpbGQgU2VydmljZSB3aGljaCBjcmVhdGVzIG5vdCBv bmx5IHBhY2thZ2VzDQo+IGJ1dCBhbHNvIHBhY2thZ2UgcmVwb3MuDQo+IA0KDQpUaGlzIGlzIHRy dWUuIEFsbCBTdVNFIHBhY2thZ2VzIGFyZSBhbHNvIGluc3RhbGxhYmxlL3VwZGF0ZWFibGUgdmlh IHp5cHBlcg0KaWYgeW91IGltcG9ydCB0aGUgcmVwb3NpdG9yeSBodHRwOi8vZG93bmxvYWQub3Bl bnN1c2Uub3JnL3JlcG9zaXRvcmllcy9maWxlc3lzdGVtLzx2ZXJzaW9uPg0KDQoNCi0tLS0tQkVH SU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mi4wLjIyIChHTlUvTGludXgp DQoNCmlRRWNCQUVCQWdBR0JRSlRyUnc4QUFvSkVIT0FrZVI4RktrK3JqOElBTUlIVEF5Z3BzaWNM ZCtveXNqWW9NckQNCjBkL2tZSVFlS3VFYk96d2pBUEtsWWNlUHMyS2RVQzZwNUQrejRXV3pYK29r VW1aclZLZHltb0NvNHByU3lYT3cNCllKQmdpTWlZQmhZNVVnWmxwS2VkcW5xWEh0TnM5U2dWMDdO d1d4eHAzWGNrcS92bXNSbnl2SG02T1JOcTRDY3ANCnhiYkplWjc2MlZUOEZlNkRKM283NEMwYTR1 aEc2d29GVlJ2TGtCM09CejJ1UVNWdmtvdHV2Y2c1aFVXbnJvREgNCjMzRmZLTEE4QytNM0JkWmZB YUhKaEZOemZScXJON1hFZEd0dWRyNGZKYkRzZHVaYW1UYkkyOHFRcEI3T0lMUTUNCmZwZTJWaXZx OWdTYU5uSnIzTSsvUE5MRmZVeVF4VE0yL3YyNnZEUWFPU01jWHBCOElSc1JSOVR3NVFjazBBaz0N Cj1ncTdEDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From tcreedon@easystreet.net Fri Jun 27 09:02:12 2014 From: tcreedon@easystreet.net (Ted Creedon) Date: Fri, 27 Jun 2014 01:02:12 -0700 Subject: [OpenAFS] Recommended version for XP SP3 Message-ID: --047d7beb9ff41aed0c04fcccba41 Content-Type: text/plain; charset=UTF-8 Somehow MS update clobbered my long running AFS client. Upgrading KFW to 4.x doesn't seem to work with Netidmgr What are the latest compatible versions of KFW, Netidmgr & OpenAFS for windows XP3 and links to same? What is the recommended install sequence? Thanks. Tedc --047d7beb9ff41aed0c04fcccba41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Somehow MS update clobbered my long running= AFS client.

Upgrading KFW to 4.x doesn't seem to work wit= h Netidmgr

What are the latest compatible versions of KFW, Net= idmgr & OpenAFS for windows XP3 and links to same? What is the recommen= ded install sequence?

Thanks.

Tedc

=
--047d7beb9ff41aed0c04fcccba41-- From eric@ericfrost.org Sun Jun 29 01:20:59 2014 From: eric@ericfrost.org (Eric Frost) Date: Sat, 28 Jun 2014 19:20:59 -0500 Subject: [OpenAFS] OpenAFS kernel module compilation problems Message-ID: <53AF5BEB.6000308@ericfrost.org> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2ax8LXxUqrjkenkBP4nSQ1HAbkKaTbt4k Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, I've been using AFS on my home network for fun and decided to try to set up a Raspberry Pi to use it. I've run into some issues compiling the module with dkms. It seems the latest version is 1.6.1-3+deb7u2 in the repository. I know this isn't the latest source but for the experiment it'd suffice. I have a few kernels and sources on the machine, 3.2.51, 3.6.9, 3.10.11, and 3.12.22. On all versions but 3.2 the compile fails: CC [M] /var/lib/dkms/openafs/1.6.1/build/src/libafs/MODLOAD-3.10-3-rpi-SP/rx_kmu= tex.o In file included from /var/lib/dkms/openafs/1.6.1/build/src/afs/sysincludes.h:131:0, from /var/lib/dkms/openafs/1.6.1/build/src/rx/rx_kcommon.h:145, from /var/lib/dkms/openafs/1.6.1/build/src/libafs/MODLOAD-3.10-3-rpi-SP/rx_kmu= tex.c:20: /usr/src/linux-headers-3.10-3-common/include/linux/backing-dev.h:117:3: warning: =91printk=92 is an unrecognized format function type [-Wformat] In file included from /var/lib/dkms/openafs/1.6.1/build/src/libafs/MODLOAD-3.10-3-rpi-SP/rx_kmu= tex.c:24:0: /var/lib/dkms/openafs/1.6.1/build/src/afs/LINUX/osi_compat.h: In function =91afs_linux_search_keyring=92: /var/lib/dkms/openafs/1.6.1/build/src/afs/LINUX/osi_compat.h:184:13: error: =91afs_ucred_t=92 has no member named =91tgcred=92 /var/lib/dkms/openafs/1.6.1/build/src/afs/LINUX/osi_compat.h:186:26: error: =91afs_ucred_t=92 has no member named =91tgcred=92 /var/lib/dkms/openafs/1.6.1/build/src/afs/LINUX/osi_compat.h: In function =91afs_get_fh_from_dentry=92: /var/lib/dkms/openafs/1.6.1/build/src/afs/LINUX/osi_compat.h:336:9: warning: passing argument 1 of =91dp->d_sb->s_export_op->encode_fh=92 fro= m incompatible pointer type [enabled by default] /var/lib/dkms/openafs/1.6.1/build/src/afs/LINUX/osi_compat.h:336:9: note: expected =91struct inode *=92 but argument is of type =91struct den= try *=92 make[6]: *** [/var/lib/dkms/openafs/1.6.1/build/src/libafs/MODLOAD-3.10-3-rpi-SP/rx_km= utex.o] Error 1 make[5]: *** [_module_/var/lib/dkms/openafs/1.6.1/build/src/libafs/MODLOAD-3.10-3-rpi-= SP] Error 2 make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-3.10-3-rpi' make[2]: *** [openafs.ko] Error 2 make[2]: Leaving directory `/var/lib/dkms/openafs/1.6.1/build/src/libafs/MODLOAD-3.10-3-rpi-SP' make[1]: *** [linux_compdirs] Error 2 make[1]: Leaving directory `/var/lib/dkms/openafs/1.6.1/build/src/libafs'= make: *** [all] Error 2 I can't seem to find in the documentation where openafs-1.6.whatever will work with whatever kernel. Is there some information on this? I don't mind compiling the source but in order to avoid conflicts it'd be helpful to have it be a debianized package and that's way out of scope for me. Any help would be appreciated. Thanks, Eric --2ax8LXxUqrjkenkBP4nSQ1HAbkKaTbt4k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlOvW+sACgkQ56qpdArkhRDVagCfSkc6veh1kPTKwRCzbnnE98MP vJ0An0X8J6h4CQb8vi3OtHnKQZWYfKNF =+zcH -----END PGP SIGNATURE----- --2ax8LXxUqrjkenkBP4nSQ1HAbkKaTbt4k-- From eagle@eyrie.org Sun Jun 29 01:30:47 2014 From: eagle@eyrie.org (Russ Allbery) Date: Sat, 28 Jun 2014 17:30:47 -0700 Subject: [OpenAFS] OpenAFS kernel module compilation problems In-Reply-To: <53AF5BEB.6000308@ericfrost.org> (Eric Frost's message of "Sat, 28 Jun 2014 19:20:59 -0500") References: <53AF5BEB.6000308@ericfrost.org> Message-ID: <87zjgwzhe0.fsf@windlord.stanford.edu> Eric Frost writes: > I've been using AFS on my home network for fun and decided to try to set > up a Raspberry Pi to use it. I've run into some issues compiling the > module with dkms. > It seems the latest version is 1.6.1-3+deb7u2 in the repository. I know > this isn't the latest source but for the experiment it'd suffice. I have > a few kernels and sources on the machine, 3.2.51, 3.6.9, 3.10.11, and > 3.12.22. > On all versions but 3.2 the compile fails: I assume this is Debian. For newer kernels, use the OpenAFS packages from wheezy-backports instead of the ones in wheezy. (Or use testing or unstable.) -- Russ Allbery (eagle@eyrie.org) From adeason@sinenomine.net Sun Jun 29 06:40:46 2014 From: adeason@sinenomine.net (Andrew Deason) Date: Sat, 28 Jun 2014 22:40:46 -0700 Subject: [OpenAFS] Re: OpenAFS kernel module compilation problems References: <53AF5BEB.6000308@ericfrost.org> Message-ID: <20140628224046.e97195e4980f377d48c3bbc8@sinenomine.net> On Sat, 28 Jun 2014 19:20:59 -0500 Eric Frost wrote: > It seems the latest version is 1.6.1-3+deb7u2 in the repository. I know > this isn't the latest source but for the experiment it'd suffice. I have > a few kernels and sources on the machine, 3.2.51, 3.6.9, 3.10.11, and > 3.12.22. > > On all versions but 3.2 the compile fails: [...] > I can't seem to find in the documentation where openafs-1.6.whatever > will work with whatever kernel. Is there some information on this? I don't think there's a simple chart or table of this that anyone's put together, but you can look in the release notes for this information, e.g. . 1.6.1 supported up through Linux 3.4, 1.6.2 supported 3.7, 1.6.4 supported 3.10, and 1.6.6 supported 3.13 (and I think everything beyond 3.13 that's been released as of now). Of course, in any Debian or other packaging there may be patches that add some more kernel support, but the vanilla versions can be a helpful guideline. -- Andrew Deason adeason@sinenomine.net From eagle@eyrie.org Sun Jun 29 07:04:25 2014 From: eagle@eyrie.org (Russ Allbery) Date: Sat, 28 Jun 2014 23:04:25 -0700 Subject: [OpenAFS] Re: OpenAFS kernel module compilation problems In-Reply-To: <20140628224046.e97195e4980f377d48c3bbc8@sinenomine.net> (Andrew Deason's message of "Sat, 28 Jun 2014 22:40:46 -0700") References: <53AF5BEB.6000308@ericfrost.org> <20140628224046.e97195e4980f377d48c3bbc8@sinenomine.net> Message-ID: <8761jkw8t2.fsf@windlord.stanford.edu> Andrew Deason writes: > I don't think there's a simple chart or table of this that anyone's put > together, but you can look in the release notes for this information, > e.g. . > 1.6.1 supported up through Linux 3.4, 1.6.2 supported 3.7, 1.6.4 > supported 3.10, and 1.6.6 supported 3.13 (and I think everything beyond > 3.13 that's been released as of now). Of course, in any Debian or other > packaging there may be patches that add some more kernel support, but > the vanilla versions can be a helpful guideline. While I had pulled up kernel support patches in the past, for all of the 1.6 versions I've been able to just package the new upstream version except for a few cases with security patches. So the Debian packages should match the upstream kernel support. -- Russ Allbery (eagle@eyrie.org)