From m.richter@tu-berlin.de Wed Feb 1 10:08:42 2017 From: m.richter@tu-berlin.de (Richter, Michael) Date: Wed, 1 Feb 2017 10:08:42 +0000 Subject: [OpenAFS] Check free space on AFS share before login Message-ID: --_000_f4d7c42795534042b2bd2ad49933414fEXMBX02tubitwintuberlin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we are using OpenAFS for the home drive. /home/users is a symlink to the A= FS path with all the home shares. The users home is for example /home/users= /username. The users only have 1 GB of space available in that share. It often happens= that the quota is reached and they are unable to login. Ubuntu doesn't giv= e a meaningful error message. I think, Ubuntu doesn't know what's the probl= em, because it sees only "/" as mountpoint, which has enough free space ava= ilable. Is there a way to check the free space of the user on login and give the us= er a good error message if there is not enough free space available in the = AFS share? I think about using pam-script to run a script that checks it but I can't s= ee a way to bring back that message to the user. Also pam-afs-session seems= not to have some option for that. Is there some other solution? Greetings Michael -- Michael Richter Technische Universit=E4t Berlin Universit=E4tsbibliothek IT-Service Fasanenstra=DFe 88, 10623 Berlin Telefon: +49 (0)30 314-76310 m.richter@tu-berlin.de www.ub.tu-berlin.de --_000_f4d7c42795534042b2bd2ad49933414fEXMBX02tubitwintuberlin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

we are using  OpenAFS for = the home drive. /home/users is a symlink to the AFS path with all the home = shares. The users home is for example /home/users/username.

 

The users only have 1 GB of spa= ce available in that share. It often happens that the quota is reached and = they are unable to login. Ubuntu doesn’t give a meaningful error mess= age. I think, Ubuntu doesn’t know what’s the problem, because it sees only “/” as mountpoint, which has eno= ugh free space available.

 

Is there a way to check the fre= e space of the user on login and give the user a good error message if ther= e is not enough free space available in the AFS share?

 

I think about using pam-script = to run a script that checks it but I can’t see a way to bring back th= at message to the user. Also pam-afs-session seems not to have some option = for that. Is there some other solution?

 

Greetings

Michael

 

--

Mi= chael Richter

 

Te= chnische Universit=E4t Berlin

Un= iversit=E4tsbibliothek=

IT-Service

 =

Fasanenstra=DFe 8= 8, 10623 Berlin

Telefon: +49 = (0)30 314-76310

m.richter@tu-berl= in.de

 =

www.ub.tu-berlin.= de

 

--_000_f4d7c42795534042b2bd2ad49933414fEXMBX02tubitwintuberlin_-- From stephan.wiesand@desy.de Wed Feb 1 12:07:30 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 1 Feb 2017 13:07:30 +0100 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: References: Message-ID: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> Hi Michael, > On 1 Feb 2017, at 11:08, Richter, Michael = wrote: >=20 > Hi, > we are using OpenAFS for the home drive. /home/users is a symlink to = the AFS path with all the home shares. The users home is for example = /home/users/username. > =20 > The users only have 1 GB of space available in that share. It often = happens that the quota is reached and they are unable to login. Ubuntu = doesn=E2=80=99t give a meaningful error message. I think, Ubuntu = doesn=E2=80=99t know what=E2=80=99s the problem, because it sees only = =E2=80=9C/=E2=80=9D as mountpoint, which has enough free space = available. > =20 > Is there a way to check the free space of the user on login and give = the user a good error message if there is not enough free space = available in the AFS share? nice idea... I should probably implement that here. Something like auth required pam_exec.so stdout /bin/check_home_space should work well enough at least with lightdm. Just make the script = print a short message to stdout and exit 1 in the failure case. Hth Stephan > =20 > I think about using pam-script to run a script that checks it but I = can=E2=80=99t see a way to bring back that message to the user. Also = pam-afs-session seems not to have some option for that. Is there some = other solution? > =20 > Greetings > Michael --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany From haba@kth.se Wed Feb 1 12:15:31 2017 From: haba@kth.se (Harald Barth) Date: Wed, 01 Feb 2017 13:15:31 +0100 (CET) Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: References: Message-ID: <20170201.131531.2027807535983930266.haba@habook.pdc.kth.se> I think the problem is well known and what one would need to do is to make (at every travesal of an AFS mount point) the OS aware of that the AFS volume in question is a seperate "device". Then make the statfs syscall on that path return the quota info from AFS. This has of course to happen dynamically as you make your way through the AFS space. This would make every volume look as a seperate file system. There are pros and cons in that approach. I think noone has written the code (for Unix/Linux) yet, but the Windows client might do this, but I'm by no means someone who knows something about AFS on Windows ;-) At our site, so far, is has been cheaper to multiply all quotas by 2 whenever the problem arose again. Und Tschüß, Harald. From stephan.wiesand@desy.de Wed Feb 1 12:29:29 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 1 Feb 2017 13:29:29 +0100 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: <20170201.131531.2027807535983930266.haba@habook.pdc.kth.se> References: <20170201.131531.2027807535983930266.haba@habook.pdc.kth.se> Message-ID: > On 1 Feb 2017, at 13:15, Harald Barth wrote: >=20 > I think the problem is well known and what one would need to do is to > make (at every travesal of an AFS mount point) the OS aware of that > the AFS volume in question is a seperate "device". Then make the > statfs syscall on that path return the quota info from AFS. This has > of course to happen dynamically as you make your way through the AFS > space. >=20 > This would make every volume look as a seperate file system. There > are pros and cons in that approach. I think this is what the in-kernel client does. It's probably the only way to make AFS compatible with Linux's firm beliefs regarding = filesystems (like that there's only one path to an object in them). > I think noone has written the code (for Unix/Linux) yet, but the Andrew Deason whipped up some proof of concept code a while ago. I have no idea how close this is to something one would consider using, and it wasn't pursued further. But it's still available: = https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-= stable-1_6_x+topic:linux-mtpt-bindmount If anyone wants to take off from there... > Windows client might do this, but I'm by no means someone who knows > something about AFS on Windows ;-) >=20 > At our site, so far, is has been cheaper to multiply all quotas by 2 > whenever the problem arose again. --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany From jsbillin@umich.edu Wed Feb 1 14:42:04 2017 From: jsbillin@umich.edu (Jonathan Billings) Date: Wed, 1 Feb 2017 09:42:04 -0500 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> Message-ID: <20170201144203.GD3874@caen-tethys.engin.umich.edu> On Wed, Feb 01, 2017 at 01:07:30PM +0100, Stephan Wiesand wrote: > nice idea... I should probably implement that here. Something like > > auth required pam_exec.so stdout /bin/check_home_space > > should work well enough at least with lightdm. Just make the script > print a short message to stdout and exit 1 in the failure case. You really shouldn't have PAM generate standard output for successful logins. You will break things like SSH's SFTP. We do something like this on our RHEL7 workstations, and we have zenity pop up with a warning when they log in if their home directory's quota is greater than 95% full. It runs as an script launched from a .desktop file in /etc/xdg/autostart/. For console logins, I'd probably use a script in /etc/profile.d/ that detected that it was a console login and generate all the output to stderr, just in case. But considering that people don't read the MOTD I doubt they'd read warnings like that. -- Jonathan Billings From stephan.wiesand@desy.de Wed Feb 1 16:34:06 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 1 Feb 2017 17:34:06 +0100 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: <20170201144203.GD3874@caen-tethys.engin.umich.edu> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <20170201144203.GD3874@caen-tethys.engin.umich.edu> Message-ID: On Feb 1, 2017, at 15:42 , Jonathan Billings wrote: > On Wed, Feb 01, 2017 at 01:07:30PM +0100, Stephan Wiesand wrote: >> nice idea... I should probably implement that here. Something like >> >> auth required pam_exec.so stdout /bin/check_home_space >> >> should work well enough at least with lightdm. Just make the script >> print a short message to stdout and exit 1 in the failure case. > > You really shouldn't have PAM generate standard output for successful > logins. You will break things like SSH's SFTP. I wasn't suggesting that, sorry for being unclear. I think this should be added to the lightdm pam config only (will login through ssh or on a VT even fail if there's no space left in ~ ?). And on success, the check script clearly shouldn't print anything to stdout and exit 0. > We do something like this on our RHEL7 workstations, and we have > zenity pop up with a warning when they log in if their home > directory's quota is greater than 95% full. It runs as an script > launched from a .desktop file in /etc/xdg/autostart/. Makes sense, but I think none of this will work if ~ is already 100% full. You'll just be thrown back to the display manager's login screen w/o a meaningful error message (maybe that "your session was suspiciously short" dialog, but I'm not sure that's still present in EL7). > For console logins, I'd probably use a script in /etc/profile.d/ that > detected that it was a console login and generate all the output to > stderr, just in case. But considering that people don't read the MOTD > I doubt they'd read warnings like that. -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From jaltman@auristor.com Wed Feb 1 17:29:53 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Wed, 1 Feb 2017 12:29:53 -0500 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: References: Message-ID: <42e690d6-130e-adf6-df19-2876565128e9@auristor.com> This is a cryptographically signed message in MIME format. --------------ms050309060505070105000008 Content-Type: multipart/mixed; boundary="------------1415EAFECEC315483B51826E" This is a multi-part message in MIME format. --------------1415EAFECEC315483B51826E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/1/2017 5:08 AM, Richter, Michael wrote: > Hi, >=20 > we are using OpenAFS for the home drive. /home/users is a symlink to > the AFS path with all the home shares. The users home is for example > /home/users/username. >=20 > The users only have 1 GB of space available in that share. It often > happens that the quota is reached and they are unable to login. Ubuntu > doesn=E2=80=99t give a meaningful error message. I think, Ubuntu doesn=E2= =80=99t know > what=E2=80=99s the problem, because it sees only =E2=80=9C/=E2=80=9D as= mountpoint, which has > enough free space available. The OpenAFS Unix cache manager exposes AFS mount points as directories not as symlinks and not as mount points. From the perspective of applications all of /afs is a single device consisting of every AFS volume in the world. In addition, while the file server offers the RXAFS_GetVolumeStatus RPC which returns . the size of the partition . the amount of free space on the partition . the size of the volume quota (if any) . the remaining free volume quota (if any) the OpenAFS Unix cache manager never queries it. As a result, the application only finds out that partition is full or the quota exceeded during the close() system call. If the quota is 2MB and an application opens a file and writes 100MB and then closes the file without checking the error code, the data is lost and the application believes the data was written to the file server successfully. As others have indicated, this is not how the Windows cache manager works. The Windows cache manager is aware of how much free space the volume has and returns an error to the application as soon as the free space reaches zero. In addition, because the Windows cache manager exposes each AFS volume as a separate device, it is possible to: . report some volumes as readonly and others as read/write . return accurate volume size and free space info for each path . report accurate quota information for each path . return out of space and out of quota errors on one path without causing the VFS to report those same errors on other paths David Howell's kafs, the Linux in-tree AFS client, behaves in a manner similar to the Windows client. https://www.infradead.org/~dhowells/kafs/ kafs requires testing, it requires that end user organizations inform their preferred Linux distributions that building and distributing kafs is important. AuriStor, Inc. supports David Howells' development of kafs. Others should as well. Jeffrey Altman --------------1415EAFECEC315483B51826E Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------1415EAFECEC315483B51826E-- --------------ms050309060505070105000008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIwMTE3Mjk1M1owLwYJKoZIhvcNAQkEMSIEIBlPY6xQ2ql2xkHzdgxI en4SBb5r2RUsa4A80xaCkyXzMF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEArLZfUX00ZPRkjuHJT8h+LGvALx6r2AlhpWc7vWkOGRYLG6y75YqH mfcsmtYJUsJVm/PT8vYJT7qxT4P2FoxQ0sg/HNAHZyCSlM96dDLTCUCgC7Jn58OyEwGQyF7I dluUi40eb4jGEb7U3leywTM8Uo5zfgnHGP4ogxiQyZhDn5oYgFc/FJj6rPZ7bvRhkHVEUwRu Pc1hx/jJBQjFFrhPd65v5LdS7kQb7E6Pd5fmoJsrd10YwHQyyzgdYdbtatta5WPa0GipG2HJ gSnZ20gqw4o1w0EOuOQkvdZcX/PwroHwbZl4xyR40UNtrsdgrRf8L8bb3IIwkx7KkdF6nyhL rQAAAAAAAA== --------------ms050309060505070105000008-- From drosih@rpi.edu Wed Feb 1 23:48:54 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Wed, 01 Feb 2017 18:48:54 -0500 Subject: [OpenAFS] LDAP searches for AFS-services via ancient names Message-ID: Just a trivial observation we noticed here at RPI. This is just for your amusement. There is nothing important about it. This past weekend we (RPI) had some odd problem pop up. The problem itself has no connection to OpenAFS, but while investigating that problem the guy who runs our LDAP servers noticed ldap queries of: (&(objectClass=ipService)(cn=afskauth)) or (&(objectClass=ipService)(cn=afsprot)) We were often seeing about 30 of those in a second. It wasn't every second, but these bursts happened many times per hour. And on rare occasions we'd also see a lot of: (&(objectClass=ipService)(cn=afsvldb)) Like maybe 60/second for 30-45 minutes, and then none of these afsvldb searches will show up for days. None of this is a problem for us or our LDAP servers (and they have nothing to do with the problem we actually care about), but we got to wondering where these requests might be coming from. It turns out the culprits were two very old linux machines we have, running a very old (2004!) version of OpenAFS. And someone on our staff had an automatic process which monitored those machines by doing many 'ssh' commands into them. 10-15 different commands, done via separate 'ssh' connections, and all done at once. And then repeated every 5-10 minutes. Apparently this ancient version of OpenAFS will first search for AFS services via the original names of afskauth and afsprot, even though /etc/services on those machines had the newer and official names of afs3-kaserver and afs3-prserver. Those ancient names are so old that I didn't even recognize them! I eventually found them in listed in: http://www.mit.edu/afs.new/athena/system/pmax_ul4/srvd/etc/services along with afscb and afsvol. And to top it off, these ancient linux machines had /etc/nsswitch.conf configured so that "services" would be looked up in both "files" and "ldap". I have no idea why /etc/nsswitch.conf was set up that way on these machines. I deleted "ldap" from that line, rebooted, and it seems like everything is still working fine. So openafs must just look for the new service names after failing on the ancient names. (note that our LDAP server certainly never had the ancient names!) And based on https://tools.ietf.org/html/rfc1340 , it looks like the "new" service names were officially added between 1990 and 1992. I have no "to-do" request here. I just thought this was amusing. And the final irony is that these two ancient linux machines are already scheduled to be replaced this month, or maybe March at the latest. So these LDAP searches have been going on for 13 years without anyone noticing them, and then they were finally noticed just weeks before the problem would have disappeared. I'm hoping that this writeup might help someone in the future who comes across LDAP queries like these at their own site, and tries to google for "ipService" and "afskauth" to figure out what is going on! -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From kaduk@mit.edu Thu Feb 2 06:25:09 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Thu, 2 Feb 2017 00:25:09 -0600 Subject: [OpenAFS] LDAP searches for AFS-services via ancient names In-Reply-To: References: Message-ID: <20170202062508.GT8460@kduck.kaduk.org> Hi Garance, On Wed, Feb 01, 2017 at 06:48:54PM -0500, Garance A Drosehn wrote: > Just a trivial observation we noticed here at RPI. This is just > for your amusement. There is nothing important about it. [...] > I'm hoping that this writeup might help someone in the future who > comes across LDAP queries like these at their own site, and tries to > google for "ipService" and "afskauth" to figure out what is going on! That is an amusing story, and it does seem likely that it will help someone in the future -- thanks for taking the time to write it up! -Ben From m.richter@tu-berlin.de Thu Feb 2 07:36:12 2017 From: m.richter@tu-berlin.de (Richter, Michael) Date: Thu, 2 Feb 2017 07:36:12 +0000 Subject: AW: [OpenAFS] Check free space on AFS share before login In-Reply-To: <20170201144203.GD3874@caen-tethys.engin.umich.edu> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <20170201144203.GD3874@caen-tethys.engin.umich.edu> Message-ID: <34b76ac02c354f059aa5f0dda032d6bd@EX-MBX-02.tubit.win.tu-berlin.de> This is a good one BEFORE the home drive is full. For this situation I thou= ght about an interval. Because, if the user logs in and he downloads someth= ing and then the home share is full, the user will not get any message. --=20 Michael Richter Technische Universit=E4t Berlin Universit=E4tsbibliothek IT-Service Fasanenstra=DFe 88, 10623 Berlin Telefon: +49 (0)30 314-76310 m.richter@tu-berlin.de www.ub.tu-berlin.de -----Urspr=FCngliche Nachricht----- Von: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]= Im Auftrag von Jonathan Billings Gesendet: Mittwoch, 1. Februar 2017 15:42 An: openafs-info@openafs.org Betreff: Re: [OpenAFS] Check free space on AFS share before login On Wed, Feb 01, 2017 at 01:07:30PM +0100, Stephan Wiesand wrote: > nice idea... I should probably implement that here. Something like >=20 > auth required pam_exec.so stdout /bin/check_home_space >=20 > should work well enough at least with lightdm. Just make the script > print a short message to stdout and exit 1 in the failure case.=20 You really shouldn't have PAM generate standard output for successful logins. You will break things like SSH's SFTP. We do something like this on our RHEL7 workstations, and we have zenity pop up with a warning when they log in if their home directory's quota is greater than 95% full. It runs as an script launched from a .desktop file in /etc/xdg/autostart/. For console logins, I'd probably use a script in /etc/profile.d/ that detected that it was a console login and generate all the output to stderr, just in case. But considering that people don't read the MOTD I doubt they'd read warnings like that. --=20 Jonathan Billings _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From m.richter@tu-berlin.de Thu Feb 2 07:37:53 2017 From: m.richter@tu-berlin.de (Richter, Michael) Date: Thu, 2 Feb 2017 07:37:53 +0000 Subject: AW: [OpenAFS] Check free space on AFS share before login In-Reply-To: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> Message-ID: QW5kIHRoZSBvdXRwdXQgd2lsbCBiZSBzaG93biBpbiBMaWdodERNPyBJJ2xsIGdpdmUgdGhhdCBh IHRyeS4gDQoNCi0tIA0KTWljaGFlbCBSaWNodGVyDQoNClRlY2huaXNjaGUgVW5pdmVyc2l0w6R0 IEJlcmxpbg0KVW5pdmVyc2l0w6R0c2JpYmxpb3RoZWsNCklULVNlcnZpY2UNCg0KRmFzYW5lbnN0 cmHDn2UgODgsIDEwNjIzIEJlcmxpbg0KVGVsZWZvbjogKzQ5ICgwKTMwIDMxNC03NjMxMA0KbS5y aWNodGVyQHR1LWJlcmxpbi5kZQ0KDQp3d3cudWIudHUtYmVybGluLmRlDQoNCg0KLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBTdGVwaGFuIFdpZXNhbmQgW21haWx0bzpz dGVwaGFuLndpZXNhbmRAZGVzeS5kZV0gDQpHZXNlbmRldDogTWl0dHdvY2gsIDEuIEZlYnJ1YXIg MjAxNyAxMzowOA0KQW46IG9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZw0KQ2M6IFJpY2h0ZXIsIE1p Y2hhZWwNCkJldHJlZmY6IFJlOiBbT3BlbkFGU10gQ2hlY2sgZnJlZSBzcGFjZSBvbiBBRlMgc2hh cmUgYmVmb3JlIGxvZ2luDQoNCkhpIE1pY2hhZWwsDQoNCj4gT24gMSBGZWIgMjAxNywgYXQgMTE6 MDgsIFJpY2h0ZXIsIE1pY2hhZWwgPG0ucmljaHRlckB0dS1iZXJsaW4uZGU+IHdyb3RlOg0KPiAN Cj4gSGksDQo+IHdlIGFyZSB1c2luZyAgT3BlbkFGUyBmb3IgdGhlIGhvbWUgZHJpdmUuIC9ob21l L3VzZXJzIGlzIGEgc3ltbGluayB0byB0aGUgQUZTIHBhdGggd2l0aCBhbGwgdGhlIGhvbWUgc2hh cmVzLiBUaGUgdXNlcnMgaG9tZSBpcyBmb3IgZXhhbXBsZSAvaG9tZS91c2Vycy91c2VybmFtZS4N Cj4gIA0KPiBUaGUgdXNlcnMgb25seSBoYXZlIDEgR0Igb2Ygc3BhY2UgYXZhaWxhYmxlIGluIHRo YXQgc2hhcmUuIEl0IG9mdGVuIGhhcHBlbnMgdGhhdCB0aGUgcXVvdGEgaXMgcmVhY2hlZCBhbmQg dGhleSBhcmUgdW5hYmxlIHRvIGxvZ2luLiBVYnVudHUgZG9lc27igJl0IGdpdmUgYSBtZWFuaW5n ZnVsIGVycm9yIG1lc3NhZ2UuIEkgdGhpbmssIFVidW50dSBkb2VzbuKAmXQga25vdyB3aGF04oCZ cyB0aGUgcHJvYmxlbSwgYmVjYXVzZSBpdCBzZWVzIG9ubHkg4oCcL+KAnSBhcyBtb3VudHBvaW50 LCB3aGljaCBoYXMgZW5vdWdoIGZyZWUgc3BhY2UgYXZhaWxhYmxlLg0KPiAgDQo+IElzIHRoZXJl IGEgd2F5IHRvIGNoZWNrIHRoZSBmcmVlIHNwYWNlIG9mIHRoZSB1c2VyIG9uIGxvZ2luIGFuZCBn aXZlIHRoZSB1c2VyIGEgZ29vZCBlcnJvciBtZXNzYWdlIGlmIHRoZXJlIGlzIG5vdCBlbm91Z2gg ZnJlZSBzcGFjZSBhdmFpbGFibGUgaW4gdGhlIEFGUyBzaGFyZT8NCg0KbmljZSBpZGVhLi4uIEkg c2hvdWxkIHByb2JhYmx5IGltcGxlbWVudCB0aGF0IGhlcmUuIFNvbWV0aGluZyBsaWtlDQoNCmF1 dGggcmVxdWlyZWQgcGFtX2V4ZWMuc28gc3Rkb3V0IC9iaW4vY2hlY2tfaG9tZV9zcGFjZQ0KDQpz aG91bGQgd29yayB3ZWxsIGVub3VnaCBhdCBsZWFzdCB3aXRoIGxpZ2h0ZG0uIEp1c3QgbWFrZSB0 aGUgc2NyaXB0IHByaW50IGEgc2hvcnQgbWVzc2FnZSB0byBzdGRvdXQgYW5kIGV4aXQgMSBpbiB0 aGUgZmFpbHVyZSBjYXNlLg0KDQpIdGgNCglTdGVwaGFuDQoNCj4gIA0KPiBJIHRoaW5rIGFib3V0 IHVzaW5nIHBhbS1zY3JpcHQgdG8gcnVuIGEgc2NyaXB0IHRoYXQgY2hlY2tzIGl0IGJ1dCBJIGNh buKAmXQgc2VlIGEgd2F5IHRvIGJyaW5nIGJhY2sgdGhhdCBtZXNzYWdlIHRvIHRoZSB1c2VyLiBB bHNvIHBhbS1hZnMtc2Vzc2lvbiBzZWVtcyBub3QgdG8gaGF2ZSBzb21lIG9wdGlvbiBmb3IgdGhh dC4gSXMgdGhlcmUgc29tZSBvdGhlciBzb2x1dGlvbj8NCj4gIA0KPiBHcmVldGluZ3MNCj4gTWlj aGFlbA0KDQotLSANClN0ZXBoYW4gV2llc2FuZA0KREVTWSAtRFYtDQpQbGF0YW5lbmFsbGVlIDYN CjE1NzM4IFpldXRoZW4sIEdlcm1hbnkNCg0KDQoNCg== From stephan.wiesand@desy.de Thu Feb 2 08:43:14 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Thu, 2 Feb 2017 09:43:14 +0100 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> Message-ID: <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> > On 2 Feb 2017, at 08:37, Richter, Michael = wrote: >=20 > And the output will be shown in LightDM? I'll give that a try. Better yet, something like this just works as one would hope: echo WARNING: Your home directory is almost full. echo Hit Enter to try to log in, but it may fail. echo If it does, press Ctrl-Alt-F2, log in on the echo text screen and free some space. Then log out echo and press Alt-F7 to get back here. exit 0 - Stephan > -----Urspr=C4=82=C5=BAngliche Nachricht----- > Von: Stephan Wiesand [mailto:stephan.wiesand@desy.de]=20 > Gesendet: Mittwoch, 1. Februar 2017 13:08 > An: openafs-info@openafs.org > Cc: Richter, Michael > Betreff: Re: [OpenAFS] Check free space on AFS share before login >=20 > Hi Michael, >=20 >> On 1 Feb 2017, at 11:08, Richter, Michael = wrote: >>=20 >> Hi, >> we are using OpenAFS for the home drive. /home/users is a symlink to = the AFS path with all the home shares. The users home is for example = /home/users/username. >>=20 >> The users only have 1 GB of space available in that share. It often = happens that the quota is reached and they are unable to login. Ubuntu = doesn=C3=A2=C2=80=C2=99t give a meaningful error message. I think, = Ubuntu doesn=C3=A2=C2=80=C2=99t know what=C3=A2=C2=80=C2=99s the = problem, because it sees only =C3=A2=C2=80=C2=9C/=C3=A2=C2=80=C2=9D as = mountpoint, which has enough free space available. >>=20 >> Is there a way to check the free space of the user on login and give = the user a good error message if there is not enough free space = available in the AFS share? >=20 > nice idea... I should probably implement that here. Something like >=20 > auth required pam_exec.so stdout /bin/check_home_space >=20 > should work well enough at least with lightdm. Just make the script = print a short message to stdout and exit 1 in the failure case. >=20 > Hth > Stephan >=20 >>=20 >> I think about using pam-script to run a script that checks it but I = can=C3=A2=C2=80=C2=99t see a way to bring back that message to the user. = Also pam-afs-session seems not to have some option for that. Is there = some other solution? >>=20 >> Greetings >> Michael --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany From m.richter@tu-berlin.de Thu Feb 2 11:43:28 2017 From: m.richter@tu-berlin.de (Richter, Michael) Date: Thu, 2 Feb 2017 11:43:28 +0000 Subject: AW: [OpenAFS] Check free space on AFS share before login In-Reply-To: <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> Message-ID: QWN0dWFsbHkgdHJ5aW5nLi4uIFRoZSBtZXNzYWdlIGNvbWVzIHRvIHRoZSB1c2VyIGluIExpZ2h0 RE0uIEJ1dCBJIGRvbid0IGhhdmUgYWNjZXNzIHRvIHRoZSBBRlMgc2hhcmUgb2YgdGhlIHVzZXIu IEkgYXNzdW1lIGl0J3MgYmVjYXVzZSBwYW1fZXhlYyBydW5zIGJlZm9yZSBwYW1fYWZzX3Nlc3Np b246DQoNCi0tIC9ldGMvcGFtLmQvY29tbW9uLWF1dGgNCn5+fg0KYXV0aCAgICBbc3VjY2Vzcz0z IGRlZmF1bHQ9aWdub3JlXSAgICAgIHBhbV9rcmI1LnNvIG1pbmltdW1fdWlkPTEwMDANCmF1dGgg ICAgW3N1Y2Nlc3M9MiBkZWZhdWx0PWlnbm9yZV0gICAgICBwYW1fdW5peC5zbyBudWxsb2tfc2Vj dXJlIHRyeV9maXJzdF9wYXNzDQoNCiMgYXV0aCBhZ2FpbnN0IHR3byBkb21haW5zIHZpYSBMREFQ DQphdXRoICAgIFtzdWNjZXNzPTEgZGVmYXVsdD1pZ25vcmVdICAgICAgcGFtX3Nzcy5zbyB1c2Vf Zmlyc3RfcGFzcyANCg0KYXV0aCAgICByZXF1aXNpdGUgICAgICAgICAgICAgICAgICAgICAgIHBh bV9kZW55LnNvDQphdXRoICAgIHJlcXVpcmVkICAgICAgICAgICAgICAgICAgICAgICAgcGFtX3Bl cm1pdC5zbw0KDQojIG1vdW50IE93bkNsb3VkIHZpYSB3ZWJkYXYNCmF1dGggICAgb3B0aW9uYWwg ICAgICAgIHBhbV9tb3VudC5zbyANCg0KYXV0aCAgICBvcHRpb25hbCAgICAgICAgICAgICAgICAg ICAgICAgIHBhbV9hZnNfc2Vzc2lvbi5zbw0KYXV0aCAgICBvcHRpb25hbCAgICAgICAgICAgICAg ICAgICAgICAgIHBhbV9jYXAuc28NCg0KIyBjaGVjayBmcmVlIHNwYWNlIGluIEFGUw0KYXV0aCAg ICByZXF1aXNpdGUgICBwYW1fZXhlYy5zbyBzdGRvdXQgc2V0ZXVpZCAvb3B0L2NoZWNrX2ZyZWUu c2gNCn5+fg0KDQpwYW1fYWZzX3Nlc3Npb24gaXMgb3B0aW9uYWwgYmVjYXVzZSB0aGVyZSBhcmUg dXNlcnMgZnJvbSBhbm90aGVyIGRvbWFpbiB3aXRob3V0IGFuIEFGUyBzaGFyZS4gVGhlIGNoZWNr X2ZyZWUgc2NyaXB0IGNoZWNrcyB0aGlzIGJ5IGl0c2VsZi4gSSd2ZSBzZXQgaXQgdG8gcmVxdWly ZWQgdG9vLiBCdXQgc3RpbGwgdGhlIHNhbWUuIFRoZSBzY3JpcHQgZG9lc24ndCBoYXZlIGFjY2Vz cyB0byB0aGUgQUZTIHNoYXJlLiBBY2NvcmRpbmcgdG8gdGhlIG1hbnVhbCBvZiBQQU0gdGhlcmUg aXMgbm8gd2F5IHRvIHNldCBhbiBvcmRlci4NCg0KTWF5YmUgdGhpcyBkb2Vzbid0IHdvcmsgYmVj YXVzZSBpdCdzIGluIHRoZSBQQU0gcHJvY2Vzcz8NCg0KQW55IGhpbnRzPw0KDQotLSANCk1pY2hh ZWwgUmljaHRlcg0KDQpUZWNobmlzY2hlIFVuaXZlcnNpdMOkdCBCZXJsaW4NClVuaXZlcnNpdMOk dHNiaWJsaW90aGVrDQpJVC1TZXJ2aWNlDQoNCkZhc2FuZW5zdHJhw59lIDg4LCAxMDYyMyBCZXJs aW4NClRlbGVmb246ICs0OSAoMCkzMCAzMTQtNzYzMTANCm0ucmljaHRlckB0dS1iZXJsaW4uZGUN Cg0Kd3d3LnViLnR1LWJlcmxpbi5kZQ0KDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0 LS0tLS0NClZvbjogU3RlcGhhbiBXaWVzYW5kIFttYWlsdG86c3RlcGhhbi53aWVzYW5kQGRlc3ku ZGVdIA0KR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDIuIEZlYnJ1YXIgMjAxNyAwOTo0Mw0KQW46IG9w ZW5hZnMtaW5mb0BvcGVuYWZzLm9yZw0KQ2M6IFJpY2h0ZXIsIE1pY2hhZWwNCkJldHJlZmY6IFJl OiBbT3BlbkFGU10gQ2hlY2sgZnJlZSBzcGFjZSBvbiBBRlMgc2hhcmUgYmVmb3JlIGxvZ2luDQoN Cg0KPiBPbiAyIEZlYiAyMDE3LCBhdCAwODozNywgUmljaHRlciwgTWljaGFlbCA8bS5yaWNodGVy QHR1LWJlcmxpbi5kZT4gd3JvdGU6DQo+IA0KPiBBbmQgdGhlIG91dHB1dCB3aWxsIGJlIHNob3du IGluIExpZ2h0RE0/IEknbGwgZ2l2ZSB0aGF0IGEgdHJ5Lg0KDQpCZXR0ZXIgeWV0LCBzb21ldGhp bmcgbGlrZSB0aGlzIGp1c3Qgd29ya3MgYXMgb25lIHdvdWxkIGhvcGU6DQoNCmVjaG8gV0FSTklO RzogWW91ciBob21lIGRpcmVjdG9yeSBpcyBhbG1vc3QgZnVsbC4NCmVjaG8gSGl0IEVudGVyIHRv IHRyeSB0byBsb2cgaW4sIGJ1dCBpdCBtYXkgZmFpbC4NCmVjaG8gSWYgaXQgZG9lcywgcHJlc3Mg Q3RybC1BbHQtRjIsIGxvZyBpbiBvbiB0aGUNCmVjaG8gdGV4dCBzY3JlZW4gYW5kIGZyZWUgc29t ZSBzcGFjZS4gVGhlbiBsb2cgb3V0DQplY2hvIGFuZCBwcmVzcyBBbHQtRjcgdG8gZ2V0IGJhY2sg aGVyZS4NCmV4aXQgMA0KDQotIFN0ZXBoYW4NCg0KPiAtLS0tLVVyc3ByxILFum5nbGljaGUgTmFj aHJpY2h0LS0tLS0NCj4gVm9uOiBTdGVwaGFuIFdpZXNhbmQgW21haWx0bzpzdGVwaGFuLndpZXNh bmRAZGVzeS5kZV0gDQo+IEdlc2VuZGV0OiBNaXR0d29jaCwgMS4gRmVicnVhciAyMDE3IDEzOjA4 DQo+IEFuOiBvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmcNCj4gQ2M6IFJpY2h0ZXIsIE1pY2hhZWwN Cj4gQmV0cmVmZjogUmU6IFtPcGVuQUZTXSBDaGVjayBmcmVlIHNwYWNlIG9uIEFGUyBzaGFyZSBi ZWZvcmUgbG9naW4NCj4gDQo+IEhpIE1pY2hhZWwsDQo+IA0KPj4gT24gMSBGZWIgMjAxNywgYXQg MTE6MDgsIFJpY2h0ZXIsIE1pY2hhZWwgPG0ucmljaHRlckB0dS1iZXJsaW4uZGU+IHdyb3RlOg0K Pj4gDQo+PiBIaSwNCj4+IHdlIGFyZSB1c2luZyAgT3BlbkFGUyBmb3IgdGhlIGhvbWUgZHJpdmUu IC9ob21lL3VzZXJzIGlzIGEgc3ltbGluayB0byB0aGUgQUZTIHBhdGggd2l0aCBhbGwgdGhlIGhv bWUgc2hhcmVzLiBUaGUgdXNlcnMgaG9tZSBpcyBmb3IgZXhhbXBsZSAvaG9tZS91c2Vycy91c2Vy bmFtZS4NCj4+IA0KPj4gVGhlIHVzZXJzIG9ubHkgaGF2ZSAxIEdCIG9mIHNwYWNlIGF2YWlsYWJs ZSBpbiB0aGF0IHNoYXJlLiBJdCBvZnRlbiBoYXBwZW5zIHRoYXQgdGhlIHF1b3RhIGlzIHJlYWNo ZWQgYW5kIHRoZXkgYXJlIHVuYWJsZSB0byBsb2dpbi4gVWJ1bnR1IGRvZXNuw6LCgMKZdCBnaXZl IGEgbWVhbmluZ2Z1bCBlcnJvciBtZXNzYWdlLiBJIHRoaW5rLCBVYnVudHUgZG9lc27DosKAwpl0 IGtub3cgd2hhdMOiwoDCmXMgdGhlIHByb2JsZW0sIGJlY2F1c2UgaXQgc2VlcyBvbmx5IMOiwoDC nC/DosKAwp0gYXMgbW91bnRwb2ludCwgd2hpY2ggaGFzIGVub3VnaCBmcmVlIHNwYWNlIGF2YWls YWJsZS4NCj4+IA0KPj4gSXMgdGhlcmUgYSB3YXkgdG8gY2hlY2sgdGhlIGZyZWUgc3BhY2Ugb2Yg dGhlIHVzZXIgb24gbG9naW4gYW5kIGdpdmUgdGhlIHVzZXIgYSBnb29kIGVycm9yIG1lc3NhZ2Ug aWYgdGhlcmUgaXMgbm90IGVub3VnaCBmcmVlIHNwYWNlIGF2YWlsYWJsZSBpbiB0aGUgQUZTIHNo YXJlPw0KPiANCj4gbmljZSBpZGVhLi4uIEkgc2hvdWxkIHByb2JhYmx5IGltcGxlbWVudCB0aGF0 IGhlcmUuIFNvbWV0aGluZyBsaWtlDQo+IA0KPiBhdXRoIHJlcXVpcmVkIHBhbV9leGVjLnNvIHN0 ZG91dCAvYmluL2NoZWNrX2hvbWVfc3BhY2UNCj4gDQo+IHNob3VsZCB3b3JrIHdlbGwgZW5vdWdo IGF0IGxlYXN0IHdpdGggbGlnaHRkbS4gSnVzdCBtYWtlIHRoZSBzY3JpcHQgcHJpbnQgYSBzaG9y dCBtZXNzYWdlIHRvIHN0ZG91dCBhbmQgZXhpdCAxIGluIHRoZSBmYWlsdXJlIGNhc2UuDQo+IA0K PiBIdGgNCj4gCVN0ZXBoYW4NCj4gDQo+PiANCj4+IEkgdGhpbmsgYWJvdXQgdXNpbmcgcGFtLXNj cmlwdCB0byBydW4gYSBzY3JpcHQgdGhhdCBjaGVja3MgaXQgYnV0IEkgY2Fuw6LCgMKZdCBzZWUg YSB3YXkgdG8gYnJpbmcgYmFjayB0aGF0IG1lc3NhZ2UgdG8gdGhlIHVzZXIuIEFsc28gcGFtLWFm cy1zZXNzaW9uIHNlZW1zIG5vdCB0byBoYXZlIHNvbWUgb3B0aW9uIGZvciB0aGF0LiBJcyB0aGVy ZSBzb21lIG90aGVyIHNvbHV0aW9uPw0KPj4gDQo+PiBHcmVldGluZ3MNCj4+IE1pY2hhZWwNCg0K LS0gDQpTdGVwaGFuIFdpZXNhbmQNCkRFU1kgLURWLQ0KUGxhdGFuZW5hbGxlZSA2DQoxNTczOCBa ZXV0aGVuLCBHZXJtYW55DQoNCg0KDQo= From stephan.wiesand@desy.de Thu Feb 2 12:00:39 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Thu, 2 Feb 2017 13:00:39 +0100 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> Message-ID: <35A9A6F1-3EFE-4062-97DF-BE3219650484@desy.de> > On 2 Feb 2017, at 12:43, Richter, Michael = wrote: >=20 > Actually trying... The message comes to the user in LightDM. But I = don't have access to the AFS share of the user. I assume it's because = pam_exec runs before pam_afs_session: >=20 > -- /etc/pam.d/common-auth > ~~~ > auth [success=3D3 default=3Dignore] pam_krb5.so = minimum_uid=3D1000 > auth [success=3D2 default=3Dignore] pam_unix.so nullok_secure = try_first_pass >=20 > # auth against two domains via LDAP > auth [success=3D1 default=3Dignore] pam_sss.so use_first_pass=20= >=20 > auth requisite pam_deny.so > auth required pam_permit.so >=20 > # mount OwnCloud via webdav > auth optional pam_mount.so=20 >=20 > auth optional pam_afs_session.so > auth optional pam_cap.so >=20 > # check free space in AFS > auth requisite pam_exec.so stdout seteuid /opt/check_free.sh > ~~~ >=20 > pam_afs_session is optional because there are users from another = domain without an AFS share. The check_free script checks this by = itself. I've set it to required too. But still the same. The script = doesn't have access to the AFS share. According to the manual of PAM = there is no way to set an order. >=20 > Maybe this doesn't work because it's in the PAM process? >=20 > Any hints? First, let me second Jonathan's objection to produce any output in the = common pam stack. I'd really really put it into /etc/pam.d/lightdm = (right after the @include common-auth). And you don't need read access to the volume root in order to find out. = Parsing the output of "vos examine -format" should be simple enough. =20 --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany From m.richter@tu-berlin.de Thu Feb 2 13:42:18 2017 From: m.richter@tu-berlin.de (Richter, Michael) Date: Thu, 2 Feb 2017 13:42:18 +0000 Subject: AW: [OpenAFS] Check free space on AFS share before login In-Reply-To: <35A9A6F1-3EFE-4062-97DF-BE3219650484@desy.de> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> <35A9A6F1-3EFE-4062-97DF-BE3219650484@desy.de> Message-ID: <01fd4ea4f89945a2a2acdf0deb431f6f@EX-MBX-02.tubit.win.tu-berlin.de> OK, did so. But: running "vos examine" in a shell works. If I put the same = line into a script and call this script on the same shell, it doesn't work = and gives me this error: vsu_ClientInit: Could not get afs tokens, running unauthenticated. --=20 Michael Richter Technische Universit=E4t Berlin Universit=E4tsbibliothek IT-Service Fasanenstra=DFe 88, 10623 Berlin Telefon: +49 (0)30 314-76310 m.richter@tu-berlin.de www.ub.tu-berlin.de -----Urspr=FCngliche Nachricht----- Von: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]= Im Auftrag von Stephan Wiesand Gesendet: Donnerstag, 2. Februar 2017 13:01 An: openafs-info@openafs.org Betreff: Re: [OpenAFS] Check free space on AFS share before login > On 2 Feb 2017, at 12:43, Richter, Michael wrote: >=20 > Actually trying... The message comes to the user in LightDM. But I don't = have access to the AFS share of the user. I assume it's because pam_exec ru= ns before pam_afs_session: >=20 > -- /etc/pam.d/common-auth > ~~~ > auth [success=3D3 default=3Dignore] pam_krb5.so minimum_uid=3D100= 0 > auth [success=3D2 default=3Dignore] pam_unix.so nullok_secure try= _first_pass >=20 > # auth against two domains via LDAP > auth [success=3D1 default=3Dignore] pam_sss.so use_first_pass=20 >=20 > auth requisite pam_deny.so > auth required pam_permit.so >=20 > # mount OwnCloud via webdav > auth optional pam_mount.so=20 >=20 > auth optional pam_afs_session.so > auth optional pam_cap.so >=20 > # check free space in AFS > auth requisite pam_exec.so stdout seteuid /opt/check_free.sh > ~~~ >=20 > pam_afs_session is optional because there are users from another domain w= ithout an AFS share. The check_free script checks this by itself. I've set = it to required too. But still the same. The script doesn't have access to t= he AFS share. According to the manual of PAM there is no way to set an orde= r. >=20 > Maybe this doesn't work because it's in the PAM process? >=20 > Any hints? First, let me second Jonathan's objection to produce any output in the comm= on pam stack. I'd really really put it into /etc/pam.d/lightdm (right after= the @include common-auth). And you don't need read access to the volume root in order to find out. Par= sing the output of "vos examine -format" should be simple enough. =20 --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From stephan.wiesand@desy.de Thu Feb 2 13:46:08 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Thu, 2 Feb 2017 14:46:08 +0100 Subject: [OpenAFS] Check free space on AFS share before login In-Reply-To: <01fd4ea4f89945a2a2acdf0deb431f6f@EX-MBX-02.tubit.win.tu-berlin.de> References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> <35A9A6F1-3EFE-4062-97DF-BE3219650484@desy.de> <01fd4ea4f89945a2a2acdf0deb431f6f@EX-MBX-02.tubit.win.tu-berlin.de> Message-ID: Hmm, it should work in any case. The message can be suppressed with the = -noauth option for vos. > On 2 Feb 2017, at 14:42, Richter, Michael = wrote: >=20 > OK, did so. But: running "vos examine" in a shell works. If I put the = same line into a script and call this script on the same shell, it = doesn't work and gives me this error: >=20 > vsu_ClientInit: Could not get afs tokens, running unauthenticated. --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany From pascal.salet@wu.ac.at Thu Feb 2 14:46:39 2017 From: pascal.salet@wu.ac.at (Pascal Salet) Date: Thu, 2 Feb 2017 15:46:39 +0100 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 Message-ID: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> Hello all, we used OpenAFS on AIX 6.1, and upgraded to AIX 7.1. openafs-1.6.20.1 compiles on AIX 7.1, but fails to install. I'd like to kindly ask if OpenAFS is known to install on AIX 7.1, and which would be the appropriate AFS-source-code-version to use. excerpt from config.log: =========================================================== it was created by OpenAFS configure 1.6.20.1, which was generated by GNU Autoconf 2.63. Invocation command line was $ ./configure --with-afs-sysname=rs_aix61 -- --enable-transarc-paths --disable-pam --includedir=/usr/include ## --------- ## ## Platform. ## ## --------- ## ... uname -r = 1 uname -s = AIX uname -v = 7 ... /usr/bin/uname -p = powerpc ... /usr/bin/oslevel = 7.1.0.0 ... =========================================================== I would be very grateful for any advice on this matter. -- Pascal Salet IT-Services Vienna University of Economics and Business / Austria pascal.salet@wu.ac.at / +43-1-31336-5375 From m.richter@tu-berlin.de Thu Feb 2 15:26:48 2017 From: m.richter@tu-berlin.de (Richter, Michael) Date: Thu, 2 Feb 2017 15:26:48 +0000 Subject: AW: [OpenAFS] Check free space on AFS share before login In-Reply-To: References: <7F7F896A-78BE-42BB-8197-52854E757407@desy.de> <653F6676-7213-40B9-85DE-FCC666A28838@desy.de> <35A9A6F1-3EFE-4062-97DF-BE3219650484@desy.de> <01fd4ea4f89945a2a2acdf0deb431f6f@EX-MBX-02.tubit.win.tu-berlin.de> Message-ID: <9a678b5cf2fc4d1ea7e54a7cd644d316@EX-MBX-02.tubit.win.tu-berlin.de> I got it working now. If someone wants it too: This is the interesting part of the script: ~~~ # limit in kbyte LIMIT=3D1000 uid=3D$(getent passwd "$PAM_USER" | cut -d ":" -f 3) quota=3D$(vos examine "user.$uid" -format -noauth) total=3D$(echo "$quota" | grep maxquota | awk '{print $2}') usage=3D$(echo "$quota" | grep diskused | awk '{print $2}') if [ $(($total - $usage)) -lt $LIMIT ] then # quota nearly reached echo Sie haben weniger als $LIMIT KByte echo Speicher frei. Bitte melden Sie sich echo unter Windows an und entfernen Sie Daten echo von Laufwerk Z: um sich wieder unter echo Ubuntu anmelden zu k=F6nnen. exit 1 fi exit 0 ~~~ Is called by /etc/pam.d/lightdm: ~~~ auth requisite pam_exec.so stdout type=3Dauth /opt/check_afs_free.= sh ~~~ And the second script notifies the user when he is logged in and the free s= pace is nearly reached (mostly the same script): ~~~ uid=3D$(id -u) quota=3D$(vos examine "user.$uid" -format -noauth) total=3D$(echo "$quota" | grep maxquota | awk '{print $2}') usage=3D$(echo "$quota" | grep diskused | awk '{print $2}') if [ $(($total - $usage)) -lt $LIMIT ] then # quota nearly reached # height doesn't work correct but it's ok # zenity is shorter but makes an extremly wide dialog yad --width=3D700 \ --height=3D200 \ --center \ --image=3D"gtk-dialog-warning" \ --button=3Dgtk-ok \ --buttons-layout=3Dcenter \ --title=3D"Speicher fast voll" \ --text=3D"Sie haben weniger als $LIMIT KByte Speicher frei.= Wenn der Speicher voll ist, k=F6nnen Sie sich nicht mehr unter Ubuntu anme= lden. Bitte entfernen Sie unn=F6tige Dateien aus Ihrem Pers=F6nlichen Ordne= r." fi exit 0 ~~~ Called after login via /etc/xdg/autostart/notify-afs-free.desktop Thanks for your help! --=20 Michael Richter Technische Universit=E4t Berlin Universit=E4tsbibliothek IT-Service Fasanenstra=DFe 88, 10623 Berlin Telefon: +49 (0)30 314-76310 m.richter@tu-berlin.de www.ub.tu-berlin.de -----Urspr=FCngliche Nachricht----- Von: Stephan Wiesand [mailto:stephan.wiesand@desy.de]=20 Gesendet: Donnerstag, 2. Februar 2017 14:46 An: openafs-info@openafs.org Cc: Richter, Michael Betreff: Re: [OpenAFS] Check free space on AFS share before login Hmm, it should work in any case. The message can be suppressed with the -no= auth option for vos. > On 2 Feb 2017, at 14:42, Richter, Michael wrote: >=20 > OK, did so. But: running "vos examine" in a shell works. If I put the sam= e line into a script and call this script on the same shell, it doesn't wor= k and gives me this error: >=20 > vsu_ClientInit: Could not get afs tokens, running unauthenticated. --=20 Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany From jaltman@auristor.com Thu Feb 2 20:42:01 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Thu, 2 Feb 2017 15:42:01 -0500 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> Message-ID: <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> This is a cryptographically signed message in MIME format. --------------ms040301030407080004050209 Content-Type: multipart/mixed; boundary="------------0967111C348570338A6179A9" This is a multi-part message in MIME format. --------------0967111C348570338A6179A9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/2/2017 9:46 AM, Pascal Salet wrote: > Hello all, >=20 > we used OpenAFS on AIX 6.1, and upgraded to AIX 7.1. >=20 > openafs-1.6.20.1 compiles on AIX 7.1, but fails to install. >=20 > I'd like to kindly ask if OpenAFS is known to install on AIX 7.1, and > which would be the appropriate AFS-source-code-version to use. >=20 > excerpt from config.log: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > it was created by OpenAFS configure 1.6.20.1, which was > generated by GNU Autoconf 2.63. Invocation command line was >=20 > $ ./configure --with-afs-sysname=3Drs_aix61 -- --enable-transarc-path= s > --disable-pam --includedir=3D/usr/include >=20 > ## --------- ## > ## Platform. ## > ## --------- ## > ... > uname -r =3D 1 > uname -s =3D AIX > uname -v =3D 7 > ... > /usr/bin/uname -p =3D powerpc > ... > /usr/bin/oslevel =3D 7.1.0.0 > ... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I would be very grateful for any advice on this matter. Pascal, To the best of my knowledge there has been no active development of OpenAFS on any AIX release since January 2015. At that time the AIX 6 build machine was removed from the build farm because the organization that provided it for many years could no longer afford to do so. It does not surprise me if over the last two years there has been drift between OpenAFS and AIX; especially a new major release of AIX. To answer your question, I am unaware of anyone that has installed OpenAFS on AIX 7.1. If you can provide more details on the failure, perhaps the community can assist? If the ability to use OpenAFS on AIX 7.1 is important to your institution, perhaps it would be willing to provide a build host for use by the developer community. Jeffrey Altman AuriStor, Inc. --------------0967111C348570338A6179A9 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------0967111C348570338A6179A9-- --------------ms040301030407080004050209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIwMjIwNDIwMVowLwYJKoZIhvcNAQkEMSIEIKGTdD9EpFJ6EeY1sNrm vHn8BCR9ROoPqwg//fyTBqyHMF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAIC79oTZ8Zqk/d5RBNVxJ9U5BG1twQ3SVz/Qs1DLABmXWhWYx6+gu o78kitwSh8pbhhVK2naNvOn/4ONhoaI1nDoCCicxlJSCP4l2AYCCSkskrcZmlrwlizGxGVO1 kUKyo6dZkauXMn95TcnreXBF8XVeIFAtbadHcqMckB0HX+llUnDmU6/JNduPEOlTG9RnKrIT mM8qhGNWjMgjxqntZ/E1cVHOjJEFEBEHKLSu0aOtlvM+qnQQCjX2i09FWCvVu9DJvODDiK4p icMwrFFIaao8PyDXDrPwtWEq+LiuUOTT+6YHawZAOI0ms7YFFejzPRQXgf/X9EhkhsfLI4Bg RAAAAAAAAA== --------------ms040301030407080004050209-- From pascal.salet@wu.ac.at Mon Feb 6 13:07:11 2017 From: pascal.salet@wu.ac.at (Pascal Salet) Date: Mon, 6 Feb 2017 14:07:11 +0100 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> Message-ID: <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> >> I would be very grateful for any advice on this matter. > > Pascal, > > To the best of my knowledge there has been no active development of > OpenAFS on any AIX release since January 2015. At that time the AIX 6 > build machine was removed from the build farm because the organization > that provided it for many years could no longer afford to do so. > > It does not surprise me if over the last two years there has been > drift between OpenAFS and AIX; especially a new major release of AIX. > > To answer your question, I am unaware of anyone that has installed > OpenAFS on AIX 7.1. > > If you can provide more details on the failure, perhaps the community > can assist? > > If the ability to use OpenAFS on AIX 7.1 is important to your > institution, perhaps it would be willing to provide a build host for use > by the developer community. > > Jeffrey Altman Jeffrey, thank you very much for clarifying this. I will inquire if the university can provide a build-host with AIX7 on our former PowerPC-server. This may or may not be feasible, according to administrative policies or product licenses. The options used are ## ./configure -with-afs-sysname=rs_aix61 --enable-tivoli-tsm \\ --enable-transarc-paths --disable-pam --includedir=/usr/include ## After copying the binaries manually to /usr/afs/ and /usr/vice/etc/ according to https://wiki.openafs.org/archive/HowToBuildOpenAFSFromSource/ and executing rc.afs, the server freezes and reboots. Pascal From tcreedon@easystreet.net Mon Feb 6 17:34:53 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Mon, 6 Feb 2017 17:34:53 +0000 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com>,<10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> Message-ID: why not use vm's for all non linux builds? ________________________________________ From: openafs-info-admin@openafs.org on be= half of Pascal Salet Sent: Monday, February 6, 2017 5:07 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 >> I would be very grateful for any advice on this matter. > > Pascal, > > To the best of my knowledge there has been no active development of > OpenAFS on any AIX release since January 2015. At that time the AIX 6 > build machine was removed from the build farm because the organization > that provided it for many years could no longer afford to do so. > > It does not surprise me if over the last two years there has been > drift between OpenAFS and AIX; especially a new major release of AIX. > > To answer your question, I am unaware of anyone that has installed > OpenAFS on AIX 7.1. > > If you can provide more details on the failure, perhaps the community > can assist? > > If the ability to use OpenAFS on AIX 7.1 is important to your > institution, perhaps it would be willing to provide a build host for use > by the developer community. > > Jeffrey Altman Jeffrey, thank you very much for clarifying this. I will inquire if the university can provide a build-host with AIX7 on our former PowerPC-server. This may or may not be feasible, according to administrative policies or product licenses. The options used are ## ./configure -with-afs-sysname=3Drs_aix61 --enable-tivoli-tsm \\ --enable-transarc-paths --disable-pam --includedir=3D/usr/include ## After copying the binaries manually to /usr/afs/ and /usr/vice/etc/ according to https://wiki.openafs.org/archive/HowToBuildOpenAFSFromSource/ and executing rc.afs, the server freezes and reboots. Pascal _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From stephan.wiesand@desy.de Mon Feb 6 18:14:42 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Mon, 6 Feb 2017 19:14:42 +0100 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com>,<10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> Message-ID: <5CF68577-5203-449D-A1BB-3118A599A8A5@desy.de> On Feb 6, 2017, at 18:34 , Ted Creedon wrote: > why not use vm's for all non linux builds? Because it will be just about as hard to find a system capable of = hosting those VMs? Most, if not all, Linux build slaves are VMs. So were the Windows ones. Looks like it has largely been forgotten already that virtualizing = anything not x86[_64] still isn't quite as trivial? - Stephan > ________________________________________ > From: openafs-info-admin@openafs.org = on behalf of Pascal Salet > Sent: Monday, February 6, 2017 5:07 AM > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 >=20 >>> I would be very grateful for any advice on this matter. >>=20 >> Pascal, >>=20 >> To the best of my knowledge there has been no active development of >> OpenAFS on any AIX release since January 2015. At that time the AIX = 6 >> build machine was removed from the build farm because the = organization >> that provided it for many years could no longer afford to do so. >>=20 >> It does not surprise me if over the last two years there has been >> drift between OpenAFS and AIX; especially a new major release of AIX. >>=20 >> To answer your question, I am unaware of anyone that has installed >> OpenAFS on AIX 7.1. >>=20 >> If you can provide more details on the failure, perhaps the community >> can assist? >>=20 >> If the ability to use OpenAFS on AIX 7.1 is important to your >> institution, perhaps it would be willing to provide a build host for = use >> by the developer community. >>=20 >> Jeffrey Altman >=20 > Jeffrey, >=20 > thank you very much for clarifying this. >=20 > I will inquire if the university can provide a build-host with AIX7 on > our former PowerPC-server. This may or may not be feasible, according = to > administrative policies or product licenses. >=20 > The options used are > ## > ./configure -with-afs-sysname=3Drs_aix61 --enable-tivoli-tsm \\ > --enable-transarc-paths --disable-pam --includedir=3D/usr/include > ## >=20 > After copying the binaries manually to /usr/afs/ and /usr/vice/etc/ > according to > https://wiki.openafs.org/archive/HowToBuildOpenAFSFromSource/ > and executing rc.afs, the server freezes and reboots. >=20 > Pascal > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From tcreedon@easystreet.net Mon Feb 6 21:25:35 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Mon, 6 Feb 2017 21:25:35 +0000 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> , Message-ID: I just happen to have a spare dual xeon 64gb linux box that could be made a= vailable. and smaller MAC w/ parallels on it. I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K with a little effort... IBM generally waives license fees for non profits. tedc ________________________________________ From: Gary Buhrmaster Sent: Monday, February 6, 2017 10:24 AM To: Ted Creedon Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 On Mon, Feb 6, 2017 at 5:34 PM, Ted Creedon wrote= : > why not use vm's for all non linux builds? If what you meant was for the foundation itself to pay for virtual build servers, all that takes if for the foundation to decide to spend real money. I presume they have considered that, but it might be worth asking the question explicitly if it has not been explicitly answered (I really have not been following the foundations activities). It might not even cost a lot (as I recall, there are various on-demand builder spin-up capabilities in at least some SCMs so it is free until the commit), but it is all work someone would have to research. I would not be at all surprised if the commercial companies providing support have not already moved in the direction of cloud based virtual builders (makes little sense to own a $10K server for occasional builds), but that is for their own customers. If you mean architecture emulation, it can be very slow (although might be acceptable), but the bigger problem may be licensing of the OS and the compilers. Last I knew AIX (where this started) is licensed software, and so is XLC (if using the IBM compiler is required for kernel modules). From tcreedon@easystreet.net Mon Feb 6 22:43:48 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Mon, 6 Feb 2017 22:43:48 +0000 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> ,, Message-ID: can you fix this error? [This sender failed our fraud detection checks and = may not be who they appear to be. Learn about spoofing at http://aka.ms/Lea= rnAboutSpoofing] ________________________________________ From: openafs-info-admin@openafs.org on be= half of Ted Creedon Sent: Monday, February 6, 2017 1:25 PM To: openafs-info@openafs.org Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 [This sender failed our fraud detection checks and may not be who they appe= ar to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] I just happen to have a spare dual xeon 64gb linux box that could be made a= vailable. and smaller MAC w/ parallels on it. I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K with a little effort... IBM generally waives license fees for non profits. tedc ________________________________________ From: Gary Buhrmaster Sent: Monday, February 6, 2017 10:24 AM To: Ted Creedon Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 On Mon, Feb 6, 2017 at 5:34 PM, Ted Creedon wrote= : > why not use vm's for all non linux builds? If what you meant was for the foundation itself to pay for virtual build servers, all that takes if for the foundation to decide to spend real money. I presume they have considered that, but it might be worth asking the question explicitly if it has not been explicitly answered (I really have not been following the foundations activities). It might not even cost a lot (as I recall, there are various on-demand builder spin-up capabilities in at least some SCMs so it is free until the commit), but it is all work someone would have to research. I would not be at all surprised if the commercial companies providing support have not already moved in the direction of cloud based virtual builders (makes little sense to own a $10K server for occasional builds), but that is for their own customers. If you mean architecture emulation, it can be very slow (although might be acceptable), but the bigger problem may be licensing of the OS and the compilers. Last I knew AIX (where this started) is licensed software, and so is XLC (if using the IBM compiler is required for kernel modules). _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From kaduk@mit.edu Tue Feb 7 03:47:21 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 6 Feb 2017 21:47:21 -0600 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: <5CF68577-5203-449D-A1BB-3118A599A8A5@desy.de> Message-ID: <20170207034721.GH8460@kduck.kaduk.org> On Mon, Feb 06, 2017 at 07:14:42PM +0100, Stephan Wiesand wrote: > > On Feb 6, 2017, at 18:34 , Ted Creedon wrote: > > > why not use vm's for all non linux builds? > > Because it will be just about as hard to find a system capable of hosting those VMs? > > Most, if not all, Linux build slaves are VMs. So were the Windows ones. > > Looks like it has largely been forgotten already that virtualizing anything not x86[_64] still isn't quite as trivial? It's also worth noting that without someone actively using and/or caring about a platform, it is unlikely to receive the attention it would need in order to remain viable. I.e., not necessarily just hosting a build machine, but also noticing when builds fail and following up to get issues fixed. Even if we could do cross-architecture emulation and get a free license for the OS, we'd still need someone to care about having it working. -Ben From ballbery@sinenomine.net Tue Feb 7 19:39:55 2017 From: ballbery@sinenomine.net (Brandon Allbery) Date: Tue, 7 Feb 2017 19:39:55 +0000 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> , Message-ID: WW91IGNhbid0IHNlbnNpYmx5IHZpcnR1YWxpemUgSUJNIFBPV0VSIC8gUG93ZXJQQyBhcmNoaXRl Y3R1cmUgb24gSW50ZWwgQ1BVcy4gKE9yIGV2ZW4gImF0IGFsbCI7IEkgdGhpbmsgdGhlIGNsb3Nl c3QgeW91IGdldCBpcyBxZW11J3MgUHJFUCB3aGljaCB3aWxsIG5vdCBib290IEFJWC4pDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcGVuYWZzLWluZm8tYWRtaW5Ab3BlbmFm cy5vcmcgW21haWx0bzpvcGVuYWZzLWluZm8tYWRtaW5Ab3BlbmFmcy5vcmddIE9uIEJlaGFsZiBP ZiBUZWQgQ3JlZWRvbg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA2LCAyMDE3IDQ6MjYgUE0NClRv OiBvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmcNClN1YmplY3Q6IFJlOiBbT3BlbkFGU10gT3BlbkFG UyAxLjYuMjAuMSBvbiBBSVggNy4xDQoNCkkganVzdCBoYXBwZW4gdG8gaGF2ZSBhIHNwYXJlIGR1 YWwgeGVvbiA2NGdiIGxpbnV4IGJveCB0aGF0IGNvdWxkIGJlIG1hZGUgYXZhaWxhYmxlLg0KYW5k IHNtYWxsZXIgTUFDIHcvIHBhcmFsbGVscyBvbiBpdC4NCg0KSSBhbHNvIGhhdmUgYSBkdWFsIDY0 Z2IgeGVvbiB3LyBhIHhlb24gcGhpIGNhcmQgaW4gaXQgdG9vLiBjb3N0IH4kM0sNCg0Kd2l0aCBh IGxpdHRsZSBlZmZvcnQuLi4NCg0KSUJNIGdlbmVyYWxseSAgd2FpdmVzIGxpY2Vuc2UgZmVlcyBm b3Igbm9uIHByb2ZpdHMuDQp0ZWRjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IEdhcnkgQnVocm1hc3RlciA8Z2FyeS5idWhybWFzdGVyQGdtYWlsLmNv bT4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNiwgMjAxNyAxMDoyNCBBTQ0KVG86IFRlZCBDcmVl ZG9uDQpTdWJqZWN0OiBSZTogW09wZW5BRlNdIE9wZW5BRlMgMS42LjIwLjEgb24gQUlYIDcuMQ0K DQpPbiBNb24sIEZlYiA2LCAyMDE3IGF0IDU6MzQgUE0sIFRlZCBDcmVlZG9uIDx0Y3JlZWRvbkBl YXN5c3RyZWV0Lm5ldD4gd3JvdGU6DQo+IHdoeSBub3QgdXNlIHZtJ3MgZm9yIGFsbCBub24gbGlu dXggYnVpbGRzPw0KDQpJZiB3aGF0IHlvdSBtZWFudCB3YXMgZm9yIHRoZSBmb3VuZGF0aW9uIGl0 c2VsZiB0byBwYXkgZm9yIHZpcnR1YWwgYnVpbGQgc2VydmVycywgYWxsIHRoYXQgdGFrZXMgaWYg Zm9yIHRoZSBmb3VuZGF0aW9uIHRvIGRlY2lkZSB0byBzcGVuZCByZWFsIG1vbmV5LiAgSSBwcmVz dW1lIHRoZXkgaGF2ZSBjb25zaWRlcmVkIHRoYXQsIGJ1dCBpdCBtaWdodCBiZSB3b3J0aCBhc2tp bmcgdGhlIHF1ZXN0aW9uIGV4cGxpY2l0bHkgaWYgaXQgaGFzIG5vdCBiZWVuIGV4cGxpY2l0bHkg YW5zd2VyZWQgKEkgcmVhbGx5IGhhdmUgbm90IGJlZW4gZm9sbG93aW5nIHRoZSBmb3VuZGF0aW9u cyBhY3Rpdml0aWVzKS4NCg0KSXQgbWlnaHQgbm90IGV2ZW4gY29zdCBhIGxvdCAoYXMgSSByZWNh bGwsIHRoZXJlIGFyZSB2YXJpb3VzIG9uLWRlbWFuZCBidWlsZGVyIHNwaW4tdXAgY2FwYWJpbGl0 aWVzIGluIGF0IGxlYXN0IHNvbWUgU0NNcyBzbyBpdCBpcyBmcmVlIHVudGlsIHRoZSBjb21taXQp LCBidXQgaXQgaXMgYWxsIHdvcmsgc29tZW9uZSB3b3VsZCBoYXZlIHRvIHJlc2VhcmNoLg0KDQpJ IHdvdWxkIG5vdCBiZSBhdCBhbGwgc3VycHJpc2VkIGlmIHRoZQ0KY29tbWVyY2lhbCBjb21wYW5p ZXMgcHJvdmlkaW5nIHN1cHBvcnQNCmhhdmUgbm90IGFscmVhZHkgbW92ZWQgaW4gdGhlIGRpcmVj dGlvbg0Kb2YgY2xvdWQgYmFzZWQgdmlydHVhbCBidWlsZGVycyAobWFrZXMNCmxpdHRsZSBzZW5z ZSB0byBvd24gYSAkMTBLIHNlcnZlciBmb3INCm9jY2FzaW9uYWwgYnVpbGRzKSwgYnV0IHRoYXQg aXMgZm9yIHRoZWlyIG93biBjdXN0b21lcnMuDQoNCklmIHlvdSBtZWFuIGFyY2hpdGVjdHVyZSBl bXVsYXRpb24sIGl0IGNhbiBiZSB2ZXJ5IHNsb3cgKGFsdGhvdWdoIG1pZ2h0IGJlIGFjY2VwdGFi bGUpLCBidXQgdGhlIGJpZ2dlciBwcm9ibGVtIG1heSBiZSBsaWNlbnNpbmcgb2YgdGhlIE9TIGFu ZCB0aGUgY29tcGlsZXJzLiAgTGFzdCBJIGtuZXcgQUlYICh3aGVyZSB0aGlzIHN0YXJ0ZWQpIGlz IGxpY2Vuc2VkIHNvZnR3YXJlLCBhbmQgc28gaXMgWExDIChpZiB1c2luZyB0aGUgSUJNIGNvbXBp bGVyIGlzIHJlcXVpcmVkIGZvciBrZXJuZWwgbW9kdWxlcykuDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT3BlbkFGUy1pbmZvIG1haWxpbmcgbGlzdA0K T3BlbkFGUy1pbmZvQG9wZW5hZnMub3JnDQpodHRwczovL2xpc3RzLm9wZW5hZnMub3JnL21haWxt YW4vbGlzdGluZm8vb3BlbmFmcy1pbmZvDQo= From stephan.wiesand@desy.de Tue Feb 7 19:56:01 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Tue, 7 Feb 2017 20:56:01 +0100 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> , Message-ID: On Feb 7, 2017, at 20:39 , Brandon Allbery wrote: > You can't sensibly virtualize IBM POWER / PowerPC architecture on = Intel CPUs. (Or even "at all"; I think the closest you get is qemu's = PrEP which will not boot AIX.) Thank you Brandon! =46rom what I read, Power-VM would probably do the trick. Alas, it seems = to require a POWER host and be a proprietary product. Which is just what = I meant when writing "just as hard to find". I'm not aware of any other = solution. Well, supposedly you can rent AIX VMs in some clouds. But ultimately, Ben's got the killer argument. If we had the human = resources, anything else could probably be sorted out. - Stephan >=20 > -----Original Message----- > From: openafs-info-admin@openafs.org = [mailto:openafs-info-admin@openafs.org] On Behalf Of Ted Creedon > Sent: Monday, February 6, 2017 4:26 PM > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 >=20 > I just happen to have a spare dual xeon 64gb linux box that could be = made available. > and smaller MAC w/ parallels on it. >=20 > I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K >=20 > with a little effort... >=20 > IBM generally waives license fees for non profits. > tedc >=20 > ________________________________________ > From: Gary Buhrmaster > Sent: Monday, February 6, 2017 10:24 AM > To: Ted Creedon > Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 >=20 > On Mon, Feb 6, 2017 at 5:34 PM, Ted Creedon = wrote: >> why not use vm's for all non linux builds? >=20 > If what you meant was for the foundation itself to pay for virtual = build servers, all that takes if for the foundation to decide to spend = real money. I presume they have considered that, but it might be worth = asking the question explicitly if it has not been explicitly answered (I = really have not been following the foundations activities). >=20 > It might not even cost a lot (as I recall, there are various on-demand = builder spin-up capabilities in at least some SCMs so it is free until = the commit), but it is all work someone would have to research. >=20 > I would not be at all surprised if the > commercial companies providing support > have not already moved in the direction > of cloud based virtual builders (makes > little sense to own a $10K server for > occasional builds), but that is for their own customers. >=20 > If you mean architecture emulation, it can be very slow (although = might be acceptable), but the bigger problem may be licensing of the OS = and the compilers. Last I knew AIX (where this started) is licensed = software, and so is XLC (if using the IBM compiler is required for = kernel modules). From botsch@cnf.cornell.edu Wed Feb 8 18:22:54 2017 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 8 Feb 2017 13:22:54 -0500 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> Message-ID: <20170208182254.GZ7875@cnf.cornell.edu> Hi, Ted et al. Please see below... On Mon, Feb 06, 2017 at 09:25:35PM +0000, Ted Creedon wrote: > I just happen to have a spare dual xeon 64gb linux box that could be made available. > and smaller MAC w/ parallels on it. > > I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K > > with a little effort... > > IBM generally waives license fees for non profits. > tedc > If you are willing to host on the HW mentioned above, as a non-profit, the Foundation can certainly make the ask of IBM. We would just need a bit more detail on the exact ask. > If what you meant was for the foundation > itself to pay for virtual build servers, > all that takes if for the foundation to > decide to spend real money. I presume > they have considered that, but it might > be worth asking the question explicitly > if it has not been explicitly answered > (I really have not been following the > foundations activities). > W.r.t. build hosts, we've been working with folk on attempting to get a Windows build host or two up. Now that we are into Feb 2017, I need to follow up on those efforts. If there's an ask for the Foundation to spend $$ on something particular, be it build hosts, or even hiring someone to work on, say, the AIX port, please submit a formal ask to foundation@openafs.org . Contigent on funds, we will really consider it. And, donating any type of funding towards this (for example, your org donates a $10K stipend towards us hiring an independant contractor to work on AIX would go a long way). Thanks. > It might not even cost a lot (as I recall, > there are various on-demand builder > spin-up capabilities in at least some > SCMs so it is free until the commit), > but it is all work someone would have > to research. -- ******************************** David William Botsch OpenAFS Foundation Board botsch@cnf.cornell.edu ******************************** From tcreedon@easystreet.net Wed Feb 8 23:04:51 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Wed, 8 Feb 2017 23:04:51 +0000 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: <20170208182254.GZ7875@cnf.cornell.edu> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> ,<20170208182254.GZ7875@cnf.cornell.edu> Message-ID: 1. I'l be willing to plead our case w/IBM, any shortcut names/emails? 2. What is the desired configuration (hw & sw)? 3. N.b I'm on a comcast dhcp line, fast & stable as long as there are no 24= hr shutdowns, I use dyndns to host my domain creedon.biz. 4. I have several boxen on an 3KVA UPS - works fine, lots of power avail. 5. My shop has A/C so servers run continuously 24/7 year 'round. 6. After Russ's comments is it all going to be worthwhile? 7. I have 3 afs servers on line (well as soon as I can get afs re-installe= d) 8. I have geronimo.creedon.biz as a spare build machine. time nice make -j500 takes 30 sec. Its a duplicate of ookpik.creedon.biz d= ual xeon 64Gig, etc). (ookpik has a xeon phi board installed if anyone wants to play). 9. I built/maintain all my own servers (since 1967). 10. Backups are the user's resp. although my servers could easily host anot= her afs domain. ________________________________________ From: openafs-info-admin@openafs.org on be= half of Dave Botsch Sent: Wednesday, February 8, 2017 10:22:54 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 Hi, Ted et al. Please see below... On Mon, Feb 06, 2017 at 09:25:35PM +0000, Ted Creedon wrote: > I just happen to have a spare dual xeon 64gb linux box that could be made= available. > and smaller MAC w/ parallels on it. > > I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K > > with a little effort... > > IBM generally waives license fees for non profits. > tedc > If you are willing to host on the HW mentioned above, as a non-profit, the Foundation can certainly make the ask of IBM. We would just need a bit more detail on the exact ask. > If what you meant was for the foundation > itself to pay for virtual build servers, > all that takes if for the foundation to > decide to spend real money. I presume > they have considered that, but it might > be worth asking the question explicitly > if it has not been explicitly answered > (I really have not been following the > foundations activities). > W.r.t. build hosts, we've been working with folk on attempting to get a Windows build host or two up. Now that we are into Feb 2017, I need to follow up on those efforts. If there's an ask for the Foundation to spend $$ on something particular, be it build hosts, or even hiring someone to work on, say, the AIX port, please submit a formal ask to foundation@openafs.org . Contigent on funds, we will really consider it. And, donating any type of funding towards this (for example, your org donates a $10K stipend towards us hiring an independant contractor to work on AIX would go a long way). Thanks. > It might not even cost a lot (as I recall, > there are various on-demand builder > spin-up capabilities in at least some > SCMs so it is free until the commit), > but it is all work someone would have > to research. -- ******************************** David William Botsch OpenAFS Foundation Board botsch@cnf.cornell.edu ******************************** _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From botsch@cnf.cornell.edu Fri Feb 10 17:24:08 2017 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Fri, 10 Feb 2017 12:24:08 -0500 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> Message-ID: <20170210172408.GS7875@cnf.cornell.edu> Hi, Tedd. As I understand it, the ask from IBM would be for the donation of one AIX license for the purposes of an OpenAFS buildbot? I'm not finding anything from Russ in this thread. Thanks. On Wed, Feb 08, 2017 at 11:04:51PM +0000, Ted Creedon wrote: > 1. I'l be willing to plead our case w/IBM, any shortcut names/emails? > 2. What is the desired configuration (hw & sw)? > 3. N.b I'm on a comcast dhcp line, fast & stable as long as there are no 24 hr shutdowns, I use dyndns to host my domain creedon.biz. > 4. I have several boxen on an 3KVA UPS - works fine, lots of power avail. > 5. My shop has A/C so servers run continuously 24/7 year 'round. > 6. After Russ's comments is it all going to be worthwhile? > 7. I have 3 afs servers on line (well as soon as I can get afs re-installed) > 8. I have geronimo.creedon.biz as a spare build machine. > time nice make -j500 takes 30 sec. Its a duplicate of ookpik.creedon.biz dual xeon 64Gig, etc). > (ookpik has a xeon phi board installed if anyone wants to play). > 9. I built/maintain all my own servers (since 1967). > 10. Backups are the user's resp. although my servers could easily host another afs domain. > > ________________________________________ > From: openafs-info-admin@openafs.org on behalf of Dave Botsch > Sent: Wednesday, February 8, 2017 10:22:54 AM > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 > > Hi, Ted et al. > > Please see below... > > On Mon, Feb 06, 2017 at 09:25:35PM +0000, Ted Creedon wrote: > > I just happen to have a spare dual xeon 64gb linux box that could be made available. > > and smaller MAC w/ parallels on it. > > > > I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K > > > > with a little effort... > > > > IBM generally waives license fees for non profits. > > tedc > > > > If you are willing to host on the HW mentioned above, as a non-profit, > the Foundation can certainly make the ask of IBM. We would just need a > bit more detail on the exact ask. > > > > If what you meant was for the foundation > > itself to pay for virtual build servers, > > all that takes if for the foundation to > > decide to spend real money. I presume > > they have considered that, but it might > > be worth asking the question explicitly > > if it has not been explicitly answered > > (I really have not been following the > > foundations activities). > > > > W.r.t. build hosts, we've been working with folk on attempting to get a > Windows build host or two up. Now that we are into Feb 2017, I need to > follow up on those efforts. > > If there's an ask for the Foundation to spend $$ on something > particular, be it build hosts, or even hiring someone to work on, say, > the AIX port, please submit a formal ask to foundation@openafs.org . > Contigent on funds, we will really consider it. And, donating any type > of funding towards this (for example, your org donates a $10K stipend > towards us hiring an independant contractor to work on AIX would go a > long way). > > Thanks. > > > It might not even cost a lot (as I recall, > > there are various on-demand builder > > spin-up capabilities in at least some > > SCMs so it is free until the commit), > > but it is all work someone would have > > to research. > -- > ******************************** > David William Botsch > OpenAFS Foundation Board > botsch@cnf.cornell.edu > ******************************** > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > _______________________________________________ > 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 tcreedon@easystreet.net Fri Feb 10 20:28:58 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Fri, 10 Feb 2017 20:28:58 +0000 Subject: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 In-Reply-To: <20170210172408.GS7875@cnf.cornell.edu> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> ,<20170210172408.GS7875@cnf.cornell.edu> Message-ID: Hardware + software Russ stated that the PPC arch. would be best . Tedc ________________________________________ From: openafs-info-admin@openafs.org on be= half of Dave Botsch Sent: Friday, February 10, 2017 9:24:08 AM To: openafs-info@openafs.org Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 Hi, Tedd. As I understand it, the ask from IBM would be for the donation of one AIX license for the purposes of an OpenAFS buildbot? I'm not finding anything from Russ in this thread. Thanks. On Wed, Feb 08, 2017 at 11:04:51PM +0000, Ted Creedon wrote: > 1. I'l be willing to plead our case w/IBM, any shortcut names/emails? > 2. What is the desired configuration (hw & sw)? > 3. N.b I'm on a comcast dhcp line, fast & stable as long as there are no = 24 hr shutdowns, I use dyndns to host my domain creedon.biz. > 4. I have several boxen on an 3KVA UPS - works fine, lots of power avail. > 5. My shop has A/C so servers run continuously 24/7 year 'round. > 6. After Russ's comments is it all going to be worthwhile? > 7. I have 3 afs servers on line (well as soon as I can get afs re-instal= led) > 8. I have geronimo.creedon.biz as a spare build machine. > time nice make -j500 takes 30 sec. Its a duplicate of ookpik.creedon.biz= dual xeon 64Gig, etc). > (ookpik has a xeon phi board installed if anyone wants to play). > 9. I built/maintain all my own servers (since 1967). > 10. Backups are the user's resp. although my servers could easily host an= other afs domain. > > ________________________________________ > From: openafs-info-admin@openafs.org on = behalf of Dave Botsch > Sent: Wednesday, February 8, 2017 10:22:54 AM > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1 > > Hi, Ted et al. > > Please see below... > > On Mon, Feb 06, 2017 at 09:25:35PM +0000, Ted Creedon wrote: > > I just happen to have a spare dual xeon 64gb linux box that could be ma= de available. > > and smaller MAC w/ parallels on it. > > > > I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K > > > > with a little effort... > > > > IBM generally waives license fees for non profits. > > tedc > > > > If you are willing to host on the HW mentioned above, as a non-profit, > the Foundation can certainly make the ask of IBM. We would just need a > bit more detail on the exact ask. > > > > If what you meant was for the foundation > > itself to pay for virtual build servers, > > all that takes if for the foundation to > > decide to spend real money. I presume > > they have considered that, but it might > > be worth asking the question explicitly > > if it has not been explicitly answered > > (I really have not been following the > > foundations activities). > > > > W.r.t. build hosts, we've been working with folk on attempting to get a > Windows build host or two up. Now that we are into Feb 2017, I need to > follow up on those efforts. > > If there's an ask for the Foundation to spend $$ on something > particular, be it build hosts, or even hiring someone to work on, say, > the AIX port, please submit a formal ask to foundation@openafs.org . > Contigent on funds, we will really consider it. And, donating any type > of funding towards this (for example, your org donates a $10K stipend > towards us hiring an independant contractor to work on AIX would go a > long way). > > Thanks. > > > It might not even cost a lot (as I recall, > > there are various on-demand builder > > spin-up capabilities in at least some > > SCMs so it is free until the commit), > > but it is all work someone would have > > to research. > -- > ******************************** > David William Botsch > OpenAFS Foundation Board > botsch@cnf.cornell.edu > ******************************** > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > _______________________________________________ > 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 ******************************** _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From kostas@physics.auth.gr Mon Feb 13 20:58:28 2017 From: kostas@physics.auth.gr (Kostas Liakakis) Date: Mon, 13 Feb 2017 22:58:28 +0200 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: <20170210172408.GS7875@cnf.cornell.edu> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms050409040402050602030605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I 've decided (again) to take the plunge and attempt to create a build bot slave for OpenAFS on Windows platform. We use OpenAFS on our Windows PC labs and would like to continue to do so. I have been following the guide found here: http://git.openafs.org/?p=3Dopenafs.git;a=3Dblob;f=3DREADME-WINDOWS;h=3D4= f9af252f51677dd49e32c4af4411bd96eed53c9;hb=3DHEAD The guide itself admits it might be a bit outdated at it really is... First things first, it is stated that only VS 2005 or 2008 is supported. The earliest VS I can have a valid license for is 2012. And that license would be through our University's Microsoft Imagine (ex Dreamspark) subscription. As I believe the binaries produced on a buildbot aren't the actual ones distributed I suppose a license can be used for this purpose. If not, I hope somebody can give some more insight on this. But since, VS 2012 is a big step forward, for the time being I settled for the 90day trial of VS2008 I found available for download from MS. According to the guide, Secure Endpoints Inc were building distributed binaries using VS2008. I decided to target an AMD64 build on Windows 7 x64 for starters. Soon I found out that NTbuild.bat alters PATH and the equivalent of Windows LIBPATH. Specifically, these lines set AFSDEV_LIB=3D%MSSDKDIR%\lib;%MSVCDIR%\lib; set AFSDEV_BIN=3D%MSSDKDIR%\bin;%MSVCDIR%\bin;%PERL%\bin;%CYGWINDIR%\bin;= %WIX% cause the 32bit flavors of VS compiler and libraries to be used, even if an AMD64 build is requested according to the guide linked above. The correct settings should be: set AFSDEV_LIB=3D%MSSDKDIR%\lib\x64;%MSVCDIR%\lib\amd64; set AFSDEV_BIN=3D%MSSDKDIR%\bin;%MSVCDIR%\bin\amd64;%PERL%\bin;%CYGWINDIR%\bi= n;%WIX% With that out of the way, the build continues up until Microsoft IDN APIs headers are required. For the life of me I couldn't locate any place where this is available. All Google links I found are a dead-end. Is there anybody who has a source for IDN APIs 1.1 ? And then the next problem is that apparently WiX 2.0.5805.0 will not recognize VS2008 Professional and refuse to install. Some digging around revealed forum posts stating that WiX 2.0 is too old to support VS2008. But then the guide states that all newer versions WiX are a no-no... which leads to a chicken and egg situation... Does anybody have any knowledge of what version of WiX did Secure Endpoints used in their builds, provided the information that they had been using VS2008 is correct? Thanks for reading so far down! -K. =20 --------------ms050409040402050602030605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DR0wggYjMIIFC6ADAgECAggY3YeuH0u2eTANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlv bnMgQ2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVz ZWFyY2ggSW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMB4XDTE1MDUwNTEzMzU1NFoXDTIzMDUw MzEzMzU1NFoweTELMAkGA1UEBhMCR1IxLTArBgNVBAoMJEFyaXN0b3RsZSBVbml2ZXJzaXR5 IG9mIFRoZXNzYWxvbmlraTE7MDkGA1UEAwwyQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhl c3NhbG9uaWtpIENlbnRyYWwgQ0EgUjUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjvOiWJ9gvog6JHKxxfC/CfailKSpypKBn62M8M3SjzKWJ8V08gPHqsGC8jpnNkC5w+IpF CJDczTeOTVADmJZayrP3ezTcJQv2h7aPJZ6lreph+GzXSc5lpvGkb8+tc0DLogyYNRytQquc R7Z8DAhZB+3rS28zFLOk4Yw/8Sod41RFU5scv4d0bTzktjvsAcGUkWlXY2rp4QP5ZgSNaH6R HrLLbSjSot2qHVIYQozDWTPJG0MiKySLy2D7njLsWquAGbuXpNnriJx7I7Ix6vrNvxye7jV6 M7qczQ1sJ8QTP60u7FkDgjFtydA3WTctGalGp0WVMIba8m/Ez/KY13IpAgMBAAGjggKQMIIC jDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUdJGEzY+bxcj7 PqN08k50u/ma7kYwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybHYxLmhhcmljYS5nci9I YXJpY2FSb290Q0EyMDExL2NybHYxLmRlci5jcmwwHwYDVR0jBBgwFoAUppFC/RNhSiOeCKQp 5dgTBCPuQSUwbgYIKwYBBQUHAQEEYjBgMCEGCCsGAQUFBzABhhVodHRwOi8vb2NzcC5oYXJp Y2EuZ3IwOwYIKwYBBQUHMAKGL2h0dHA6Ly93d3cuaGFyaWNhLmdyL2NlcnRzL0hhcmljYVJv b3RDQTIwMTEuY3J0MIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEEAbwdAgADBjCCAR4wNAYI KwYBBQUHAgEWKGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvZG9jdW1lbnRzL0NQUy5waHAwgeUG CCsGAQUFBwICMIHYMEoWQ0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1 dGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUg aXMgc3ViamVjdCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRl IG11c3Qgb25seSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9u YWwgcHVycG9zZXMuMC0GA1UdHgQmMCSgIjAJggdhdXRoLmdyMAmBB2F1dGguZ3IwCoEILmF1 dGguZ3IwDQYJKoZIhvcNAQELBQADggEBAKZLw+h67xvMUXpl7pQ+cH5yB7aklIen3Eicb8rw GZVGX67JRowYdic3SSHhj3QfVUrqY+PQ4DwUKiPhm8PCr0rlBS/+uY3yNYT+/+ipSjVku5f9 /Aa+4Fl/kyP5VK0RDcMTJRcaQOoa/xRu94MsvCD1vMzltOfsbraCuYyunr8Zw1BfrcgjE3cu Pp19XWe1qIkeo76jtuT+b5AcByK+o5Dt7kTLrs8M1BCMfd01EqAN2WgOW2cFRFpy0ncN4W7B w4Vvbn0EphssMyK9WPs4xSQ+dU5AA2qnARa8+MM5RENY23e6rfj46cHj0lhBTO2x/fiyaiCq Hq6tA/k7OBJg3fEwggbyMIIF2qADAgECAggUEcgnyrBkEzANBgkqhkiG9w0BAQsFADB5MQsw CQYDVQQGEwJHUjEtMCsGA1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9u aWtpMTswOQYDVQQDDDJBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2Vu dHJhbCBDQSBSNTAeFw0xNTExMTMwMDAwMDBaFw0xNzExMTIwODQ2NTVaMIHxMQswCQYDVQQG EwJHUjEVMBMGA1UEBwwMVGhlc3NhbG9uaWtpMS0wKwYDVQQKDCRBcmlzdG90bGUgVW5pdmVy c2l0eSBvZiBUaGVzc2Fsb25pa2kxGjAYBgNVBAsMEVNjaG9vbCBvZiBQaHlzaWNzMUEwPwYD VQQLDDhDbGFzcyBBIC0gUHJpdmF0ZSBLZXkgY3JlYXRlZCBhbmQgc3RvcmVkIGluIGhhcmR3 YXJlIENTUDEeMBwGA1UEAwwVS29uc3RhbnRpbm9zIExpYWtha2lzMR0wGwYJKoZIhvcNAQkB Fg5rb3N0YXNAYXV0aC5ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP4J7lPp oN8ZwYwnOj/44g9jGaS05OJy23il4M/z1DdbizDhKYwvm4fL+BjjUabPjDfVg9ltCkaXSrmM T743VVK7zdiojxGDKDP6z1J/JJfKzBXOJC0AjYZHHB9anYiDeu4ItBFzz77sCWYg2qA0I0kG eHhx9Ziswg4bIQEwi1Zcn+jjAUc+4YxCwwBzMT56wR7l7bpG8gMN/jjnkrsE7Mbmdf1gOcr9 gfULvUjtRxT9HezUKnHl8dpXPi6nWGxTr+bj05Qo4i/BsvH/H2JCB4N9EOgd3xQGgAAARvgD lVdUE9Yhu3nTT+f3+4m8xjz3Z9vQR7D6Yg0r8kSQ3B1U4ZUCAwEAAaOCAwMwggL/MAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYD VR0OBBYEFJKuQo2V8Bqi9E6simGPn/+fjQRGMB8GA1UdIwQYMBaAFHSRhM2Pm8XI+z6jdPJO dLv5mu5GMHEGCCsGAQUFBwEBBGUwYzAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AucGtpLmF1 dGguZ3IwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvY2VydHMvQXV0aENl bnRyYWxDQVI1LmNydDBHBgNVHR8EQDA+MDygOqA4hjZodHRwOi8vY3JsdjEucGtpLmF1dGgu Z3IvQXV0aENlbnRyYWxDQVI1L2NybHYxLmRlci5jcmwwggEqBgNVHSAEggEhMIIBHTCCAQ8G CysGAQQBvB0CAAMFMIH/MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnBraS5hdXRoLmdyL2Rv Y3VtZW50cy9DUFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlzdG90bGUgVW5pdmVyc2l0 eSBvZiBUaGVzc2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3ViamVjdCB0 byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3Qgb25seSBi ZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVycG9zZXMu MAgGBgQAizABATAiBggrBgEFBQcBAwQWMBQwCAYGBACORgEBMAgGBgQAjkYBBDBMBgNVHREE RTBDgRZrb3N0YXNAcGh5c2ljcy5hdXRoLmdyoCkGCisGAQQBgjcUAgOgGwwZa29zdGFzQHBj bGFicy5pdGMuYXV0aC5ncjApBgkrBgEEAYI3FAIEHB4aAFMAbQBhAHIAdABjAGEAcgBkAFUA cwBlAHIwDQYJKoZIhvcNAQELBQADggEBAFvzyrVJEj7AmTbPe7qtOtEMoQ3wsMj0TLW9o2ED /C0Z2o5rN7QnAkJEJ5DM5r4SQq9pezgOvFFBeUqj3cdPqL2II7XDy7r9BXFbjp+uk9rm3ltl T5kD4aaIWvQKVj67XnyG1L5EfUZy40uG+Z6PjgHQqq4hGDU0Vdn3k0di5caC97Do1u6VO81/ fFeEtKnTHKr+KU6xeBVG73imfo9F5fLy1F9l7+i+cNipA9EwxsocO8pKLY3Hn5Ju+u9fNNuE cnl11eN/nh8FuCqgBtRkmOGRQltaU+p/TPj5VWBKwvdvUmxYElmC9TR+oa6q4sB+deyyuDlG mugeTNLKtIMOb9gxggPAMIIDvAIBATCBhTB5MQswCQYDVQQGEwJHUjEtMCsGA1UECgwkQXJp c3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJBcmlzdG90bGUg VW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHIJ8qwZBMwDQYJ YIZIAWUDBAIBBQCgggILMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE3MDIxMzIwNTgyOFowLwYJKoZIhvcNAQkEMSIEIOpXzT/2v04+znYhvfZhofyRnwe4 +tkx5odHnrumq4CUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgZYGCSsGAQQBgjcQBDGBiDCBhTB5MQswCQYDVQQGEwJHUjEtMCsG A1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHI J8qwZBMwgZgGCyqGSIb3DQEJEAILMYGIoIGFMHkxCzAJBgNVBAYTAkdSMS0wKwYDVQQKDCRB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kxOzA5BgNVBAMMMkFyaXN0b3Rs ZSBVbml2ZXJzaXR5IG9mIFRoZXNzYWxvbmlraSBDZW50cmFsIENBIFI1AggUEcgnyrBkEzAN BgkqhkiG9w0BAQEFAASCAQBo6+qLicirITtsfobyzyS4WOLqmiCNAcnmajqt5NT7i0piXtLH k0ke3hDvZdJUOPvt4rGL2aOYcG5+FvwooUYnrC/Kegu7zWMMGZWaaVpmtTaWpqkJmU7MmoFU Zqk/WQ5OWTXez/T3O8oBUTO+UM7HND4SDJzZsuU6bxElNyx10dTauzY2elpMH3uwwxve0OuN thI61tBY1u61CdFdDzTRyx4EMlaWwNRzvoKFhnzaIjibQEV4IR5iZhjKp3l1W3CIiR5kr5zm 0N610PHmFXgxha33qTtx1k8XuB5dDaGTUSeUuaE4y9jMpm2yYW9jYSFTaZsEIYUBOsPJDg3a M2rKAAAAAAAA --------------ms050409040402050602030605-- From jaltman@auristor.com Tue Feb 14 01:53:38 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Mon, 13 Feb 2017 20:53:38 -0500 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms080108000903010404050708 Content-Type: multipart/mixed; boundary="------------4FD274A8EE15952164BFD582" This is a multi-part message in MIME format. --------------4FD274A8EE15952164BFD582 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/13/2017 3:58 PM, Kostas Liakakis wrote: > Does anybody have any knowledge of what version of WiX did Secure > Endpoints used in their builds, provided the information that they had > been using VS2008 is correct? Kostas, The OpenAFS 1.7.3301 installers distributed by AuriStor, Inc. are built from OpenAFS sources but they do not use the OpenAFS WiX 2.0 scripts for the installation packages. They are built with WiX 3.9 scripts. The installation packaging in the OpenAFS tree can no longer be used. As a reminder, the 1.7.3301 installers that AuriStor, Inc. distributes https://www.auristor.com/openafs/client-installer/ can be installed on Windows 10 and Windows Server 2016 because they are grand-fathered. If the same sources were built today they would not produce a working file system. Jeffrey Altman --------------4FD274A8EE15952164BFD582 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------4FD274A8EE15952164BFD582-- --------------ms080108000903010404050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIxNDAxNTMzOFowLwYJKoZIhvcNAQkEMSIEIBqn/W0BjhLqoSAkugRB N+hU4C+TDRCdCHrC39xvUiLdMF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAZPEF/HnWVrrL27sXM5q1HZJ9G/TcYV8QfwbdDtaLo8UaBsTvdYb5 pPl+XtijmvtM1PI+IrX6CXsMVTbR2JXhGCGnFGXEgGazy8xQbdyGU+61rHPRET67VZbXr0kS 1fCfsCeY8XUxt/i/OBSF4rV/4JvogH2lOaJOsgl+oSRHOtq0YdG68TUy/8LxqzZPD2niQju3 /WVr9bLnflJuM0+AbxmKSoG7WCVjF3uT/lwY0Ey11kHM6CQ0wpzvrEKD9che4bs8s5fT1pSF UPnggZ7z0b6LLnOV3FNCnI34hAavxaBfS/OXbGJ4v6Y83YK9cUKwxqB7qc7d8+N+q4G2dvCM TgAAAAAAAA== --------------ms080108000903010404050708-- From kaduk@mit.edu Tue Feb 14 05:45:53 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 13 Feb 2017 23:45:53 -0600 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> Message-ID: <20170214054552.GD30306@kduck.kaduk.org> On Mon, Feb 13, 2017 at 10:58:28PM +0200, Kostas Liakakis wrote: > > I 've decided (again) to take the plunge and attempt to create a build > bot slave for OpenAFS on Windows platform. We use OpenAFS on our Windows > PC labs and would like to continue to do so. Thank you for stepping forward to help! It is good to have more people who are familiar with the windows setup. (FWIW, there is currently a windows builder that was set up by Alejandro Sedeno on a VM donated by MIT: https://buildbot.openafs.org/buildslaves/win7-amd64 . But there is probably still value in continuing your attempts -- for one, we are limited to only two builds at a time on that machine, and there are potentially four that are worth doing -- only two are in the set of builds that are triggered for each submitted change.) > I have been following the guide found here: > http://git.openafs.org/?p=openafs.git;a=blob;f=README-WINDOWS;h=4f9af252f51677dd49e32c4af4411bd96eed53c9;hb=HEAD > > The guide itself admits it might be a bit outdated at it really is... Yes ... and it is not entirely sure even how outdated it is (I say, having made the most recent overhaul to it.) > First things first, it is stated that only VS 2005 or 2008 is supported. > The earliest VS I can have a valid license for is 2012. And that license > would be through our University's Microsoft Imagine (ex Dreamspark) > subscription. As I believe the binaries produced on a buildbot aren't > the actual ones distributed I suppose a license can be used for this > purpose. If not, I hope somebody can give some more insight on this. The binaries produced on the buildbots are not distributed, yes. > But since, VS 2012 is a big step forward, for the time being I settled > for the 90day trial of VS2008 I found available for download from MS. > According to the guide, Secure Endpoints Inc were building distributed > binaries using VS2008. In my attempts (several years ago, now), I do not think I actually succeeded in getting a build with VS2008 to work (only VS2005). But that was a long time ago, and my notes are incomplete, so it's hard to be sure. > I decided to target an AMD64 build on Windows 7 x64 for starters. Soon I > found out that NTbuild.bat alters PATH and the equivalent of Windows > LIBPATH. Specifically, these lines > > set AFSDEV_LIB=%MSSDKDIR%\lib;%MSVCDIR%\lib; > set AFSDEV_BIN=%MSSDKDIR%\bin;%MSVCDIR%\bin;%PERL%\bin;%CYGWINDIR%\bin;%WIX% > > cause the 32bit flavors of VS compiler and libraries to be used, even if > an AMD64 build is requested according to the guide linked above. > > The correct settings should be: > > set AFSDEV_LIB=%MSSDKDIR%\lib\x64;%MSVCDIR%\lib\amd64; > set > AFSDEV_BIN=%MSSDKDIR%\bin;%MSVCDIR%\bin\amd64;%PERL%\bin;%CYGWINDIR%\bin;%WIX% It seems that at least sometimes, the historical usage has been to have a different ntbuild.bat for each of the four combinations of 32/64-bit and debug/release builds (sometimes called free/checked). But it probably doesn't matter which one you start off with. > With that out of the way, the build continues up until Microsoft IDN > APIs headers are required. For the life of me I couldn't locate any > place where this is available. All Google links I found are a dead-end. > Is there anybody who has a source for IDN APIs 1.1 ? That one may be a bit harder to find. (I don't even know what the redistributable status of such a thing would be even if someone did have a copy sitting around...) > And then the next problem is that apparently WiX 2.0.5805.0 will not > recognize VS2008 Professional and refuse to install. Some digging around > revealed forum posts stating that WiX 2.0 is too old to support VS2008. > But then the guide states that all newer versions WiX are a no-no... > which leads to a chicken and egg situation... IIRC the WiX issue is what drove me off of VS2008 in my experimentation so long ago. But, ultimately, our dependence on outdated/unsupported/no-longer-available tools will become unsustainable, and we will be forced to upgrade. It would be better to pay the burden of that upgrade now, when it can be done at our leisure, than have to do it in a hurry. So, maybe it is the time to ignore the documented requirements and see what breaks when using a newer WiX. (Obviously, start off with the oldest WiX that is compatible with the old VS2008 -- don't try to jump straight to the latest!) And, of course, WiX is only needed for building installers; just compiling the code can be done without any WiX at all. > Does anybody have any knowledge of what version of WiX did Secure > Endpoints used in their builds, provided the information that they had > been using VS2008 is correct? I think Jeffrey has already answered that one. If you are not doing so already, I recommend keeping a "lab notebook" that records what tools you installed, what commands you used to (attempt to) build, etc., which could eventually be used to make the above README actually resemble reality. Thanks again, Ben From kostas@physics.auth.gr Tue Feb 14 12:37:01 2017 From: kostas@physics.auth.gr (Kostas Liakakis) Date: Tue, 14 Feb 2017 14:37:01 +0200 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms030308070504090404020506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jeffrey, Thanks for taking the time to answer. Please read below inline. On 2017-02-14 03:53, Jeffrey Altman wrote: > They are built with WiX 3.9 scripts. The > installation packaging in the OpenAFS tree can no longer be used. I see. So I'll switch to a later version as Ben suggested and see what happens. Hopefully we won't have to reinvent the wheel. > As a reminder, the 1.7.3301 installers that AuriStor, Inc. distributes > > https://www.auristor.com/openafs/client-installer/ > > can be installed on Windows 10 and Windows Server 2016 because they are= > grand-fathered. If the same sources were built today they would not > produce a working file system. This statement is a bit distrurbing. Do you mean that given the state of things, even if Windows buildbots start springing back to life and binaries for current OpenAFS versions become availble, no later version than the already built and signed 1.7.3301 can be installed on Win10 and later? Will Win7 be ok at least? Do you consider the whole effort to revive the Windows port is in vain? Or is there something the the Foundation is planning to do in order to move forward again on the Windows platform? Thanks, -K. --------------ms030308070504090404020506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DR0wggYjMIIFC6ADAgECAggY3YeuH0u2eTANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlv bnMgQ2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVz ZWFyY2ggSW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMB4XDTE1MDUwNTEzMzU1NFoXDTIzMDUw MzEzMzU1NFoweTELMAkGA1UEBhMCR1IxLTArBgNVBAoMJEFyaXN0b3RsZSBVbml2ZXJzaXR5 IG9mIFRoZXNzYWxvbmlraTE7MDkGA1UEAwwyQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhl c3NhbG9uaWtpIENlbnRyYWwgQ0EgUjUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjvOiWJ9gvog6JHKxxfC/CfailKSpypKBn62M8M3SjzKWJ8V08gPHqsGC8jpnNkC5w+IpF CJDczTeOTVADmJZayrP3ezTcJQv2h7aPJZ6lreph+GzXSc5lpvGkb8+tc0DLogyYNRytQquc R7Z8DAhZB+3rS28zFLOk4Yw/8Sod41RFU5scv4d0bTzktjvsAcGUkWlXY2rp4QP5ZgSNaH6R HrLLbSjSot2qHVIYQozDWTPJG0MiKySLy2D7njLsWquAGbuXpNnriJx7I7Ix6vrNvxye7jV6 M7qczQ1sJ8QTP60u7FkDgjFtydA3WTctGalGp0WVMIba8m/Ez/KY13IpAgMBAAGjggKQMIIC jDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUdJGEzY+bxcj7 PqN08k50u/ma7kYwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybHYxLmhhcmljYS5nci9I YXJpY2FSb290Q0EyMDExL2NybHYxLmRlci5jcmwwHwYDVR0jBBgwFoAUppFC/RNhSiOeCKQp 5dgTBCPuQSUwbgYIKwYBBQUHAQEEYjBgMCEGCCsGAQUFBzABhhVodHRwOi8vb2NzcC5oYXJp Y2EuZ3IwOwYIKwYBBQUHMAKGL2h0dHA6Ly93d3cuaGFyaWNhLmdyL2NlcnRzL0hhcmljYVJv b3RDQTIwMTEuY3J0MIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEEAbwdAgADBjCCAR4wNAYI KwYBBQUHAgEWKGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvZG9jdW1lbnRzL0NQUy5waHAwgeUG CCsGAQUFBwICMIHYMEoWQ0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1 dGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUg aXMgc3ViamVjdCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRl IG11c3Qgb25seSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9u YWwgcHVycG9zZXMuMC0GA1UdHgQmMCSgIjAJggdhdXRoLmdyMAmBB2F1dGguZ3IwCoEILmF1 dGguZ3IwDQYJKoZIhvcNAQELBQADggEBAKZLw+h67xvMUXpl7pQ+cH5yB7aklIen3Eicb8rw GZVGX67JRowYdic3SSHhj3QfVUrqY+PQ4DwUKiPhm8PCr0rlBS/+uY3yNYT+/+ipSjVku5f9 /Aa+4Fl/kyP5VK0RDcMTJRcaQOoa/xRu94MsvCD1vMzltOfsbraCuYyunr8Zw1BfrcgjE3cu Pp19XWe1qIkeo76jtuT+b5AcByK+o5Dt7kTLrs8M1BCMfd01EqAN2WgOW2cFRFpy0ncN4W7B w4Vvbn0EphssMyK9WPs4xSQ+dU5AA2qnARa8+MM5RENY23e6rfj46cHj0lhBTO2x/fiyaiCq Hq6tA/k7OBJg3fEwggbyMIIF2qADAgECAggUEcgnyrBkEzANBgkqhkiG9w0BAQsFADB5MQsw CQYDVQQGEwJHUjEtMCsGA1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9u aWtpMTswOQYDVQQDDDJBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2Vu dHJhbCBDQSBSNTAeFw0xNTExMTMwMDAwMDBaFw0xNzExMTIwODQ2NTVaMIHxMQswCQYDVQQG EwJHUjEVMBMGA1UEBwwMVGhlc3NhbG9uaWtpMS0wKwYDVQQKDCRBcmlzdG90bGUgVW5pdmVy c2l0eSBvZiBUaGVzc2Fsb25pa2kxGjAYBgNVBAsMEVNjaG9vbCBvZiBQaHlzaWNzMUEwPwYD VQQLDDhDbGFzcyBBIC0gUHJpdmF0ZSBLZXkgY3JlYXRlZCBhbmQgc3RvcmVkIGluIGhhcmR3 YXJlIENTUDEeMBwGA1UEAwwVS29uc3RhbnRpbm9zIExpYWtha2lzMR0wGwYJKoZIhvcNAQkB Fg5rb3N0YXNAYXV0aC5ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP4J7lPp oN8ZwYwnOj/44g9jGaS05OJy23il4M/z1DdbizDhKYwvm4fL+BjjUabPjDfVg9ltCkaXSrmM T743VVK7zdiojxGDKDP6z1J/JJfKzBXOJC0AjYZHHB9anYiDeu4ItBFzz77sCWYg2qA0I0kG eHhx9Ziswg4bIQEwi1Zcn+jjAUc+4YxCwwBzMT56wR7l7bpG8gMN/jjnkrsE7Mbmdf1gOcr9 gfULvUjtRxT9HezUKnHl8dpXPi6nWGxTr+bj05Qo4i/BsvH/H2JCB4N9EOgd3xQGgAAARvgD lVdUE9Yhu3nTT+f3+4m8xjz3Z9vQR7D6Yg0r8kSQ3B1U4ZUCAwEAAaOCAwMwggL/MAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYD VR0OBBYEFJKuQo2V8Bqi9E6simGPn/+fjQRGMB8GA1UdIwQYMBaAFHSRhM2Pm8XI+z6jdPJO dLv5mu5GMHEGCCsGAQUFBwEBBGUwYzAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AucGtpLmF1 dGguZ3IwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvY2VydHMvQXV0aENl bnRyYWxDQVI1LmNydDBHBgNVHR8EQDA+MDygOqA4hjZodHRwOi8vY3JsdjEucGtpLmF1dGgu Z3IvQXV0aENlbnRyYWxDQVI1L2NybHYxLmRlci5jcmwwggEqBgNVHSAEggEhMIIBHTCCAQ8G CysGAQQBvB0CAAMFMIH/MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnBraS5hdXRoLmdyL2Rv Y3VtZW50cy9DUFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlzdG90bGUgVW5pdmVyc2l0 eSBvZiBUaGVzc2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3ViamVjdCB0 byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3Qgb25seSBi ZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVycG9zZXMu MAgGBgQAizABATAiBggrBgEFBQcBAwQWMBQwCAYGBACORgEBMAgGBgQAjkYBBDBMBgNVHREE RTBDgRZrb3N0YXNAcGh5c2ljcy5hdXRoLmdyoCkGCisGAQQBgjcUAgOgGwwZa29zdGFzQHBj bGFicy5pdGMuYXV0aC5ncjApBgkrBgEEAYI3FAIEHB4aAFMAbQBhAHIAdABjAGEAcgBkAFUA cwBlAHIwDQYJKoZIhvcNAQELBQADggEBAFvzyrVJEj7AmTbPe7qtOtEMoQ3wsMj0TLW9o2ED /C0Z2o5rN7QnAkJEJ5DM5r4SQq9pezgOvFFBeUqj3cdPqL2II7XDy7r9BXFbjp+uk9rm3ltl T5kD4aaIWvQKVj67XnyG1L5EfUZy40uG+Z6PjgHQqq4hGDU0Vdn3k0di5caC97Do1u6VO81/ fFeEtKnTHKr+KU6xeBVG73imfo9F5fLy1F9l7+i+cNipA9EwxsocO8pKLY3Hn5Ju+u9fNNuE cnl11eN/nh8FuCqgBtRkmOGRQltaU+p/TPj5VWBKwvdvUmxYElmC9TR+oa6q4sB+deyyuDlG mugeTNLKtIMOb9gxggPAMIIDvAIBATCBhTB5MQswCQYDVQQGEwJHUjEtMCsGA1UECgwkQXJp c3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJBcmlzdG90bGUg VW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHIJ8qwZBMwDQYJ YIZIAWUDBAIBBQCgggILMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE3MDIxNDEyMzcwMVowLwYJKoZIhvcNAQkEMSIEIBNjZwGEzUitREYi5ScaNR4W3gqg fjidFKFLkZpCxr4DMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgZYGCSsGAQQBgjcQBDGBiDCBhTB5MQswCQYDVQQGEwJHUjEtMCsG A1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHI J8qwZBMwgZgGCyqGSIb3DQEJEAILMYGIoIGFMHkxCzAJBgNVBAYTAkdSMS0wKwYDVQQKDCRB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kxOzA5BgNVBAMMMkFyaXN0b3Rs ZSBVbml2ZXJzaXR5IG9mIFRoZXNzYWxvbmlraSBDZW50cmFsIENBIFI1AggUEcgnyrBkEzAN BgkqhkiG9w0BAQEFAASCAQArYn+FdjHSpU7tLnjUap5kPtUPPZUf64ImxnTrWgTuk9a4Ryaz UBzsEsl9r6P89/vZtGbghzS7R9X7SzwrgDKoZ0AnnupWmMmfdYFHDN/cf1gzC+Zk23oHzpBn kywWK1bBBN2dX4zCY1BZ5X2S2BXJ+CU2FxAQjKpSWf17idBbrC+buDyi6wrm2vfJENHLtiRz ZMERsJ63zb8rvFdBihI58AZuhL9nr8Se/BOYgCh/gL953ZuG8J/4AGOcLPDDkNE7JTvKza6w Iw4mWM/+dBE8vpfiv5DkdZ+rjoXVUB5asb3jM0xNfn6bv61pI/t31fKAHRdWm0r6ySUMKjrm DyFJAAAAAAAA --------------ms030308070504090404020506-- From kostas@physics.auth.gr Tue Feb 14 13:14:30 2017 From: kostas@physics.auth.gr (Kostas Liakakis) Date: Tue, 14 Feb 2017 15:14:30 +0200 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: <20170214054552.GD30306@kduck.kaduk.org> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> <20170214054552.GD30306@kduck.kaduk.org> Message-ID: This is a cryptographically signed message in MIME format. --------------ms010708030902010302090001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Ben, On 2017-02-14 07:45, Benjamin Kaduk wrote: > (FWIW, there is > currently a windows builder that was set up by Alejandro Sedeno > on a VM donated by MIT: > https://buildbot.openafs.org/buildslaves/win7-amd64 . But there is It would be nice to know what software versions Alejandro used for his slave. Taking a quick look in his build log I can imagine he has VS2005 and Platform SDK 7.0 installed. In contrast, I went with VS2008 and Platform SDK 6.0a, trying to be as close to the Secure Endpoints mentioned setup as possible and work from there. > The binaries produced on the buildbots are not distributed, yes. Good :) > It seems that at least sometimes, the historical usage has been to > have a different ntbuild.bat for each of the four combinations of > 32/64-bit and debug/release builds (sometimes called free/checked). > But it probably doesn't matter which one you start off with. At least for the 32/64 bit variation it seems that a separate ntbuild.bat should be used, or the current one be coded better. For the debug/release one there seems to be a command line parameter supported: free/checked > > That one may be a bit harder to find. (I don't even know what the > redistributable status of such a thing would be even if someone did > have a copy sitting around...) Well, I gave up on it :) Instead commented the #include in cm_nls.c and added a typedef for _NORM_FORM enum copied out of the MS documentation. Amazingingly, this was enough for the build to proceed and end in success. Well, at least my openafs/dest directory is now populated and I could at least run "pts help" and "fs help". Haven't bother installing the tools for building the doc tree. I don't think Alejandro is either... So, where to now? Is there a way to actually test the resulting binaries as they are? Try a newer WiX version and see where it bombs? Upload the build result somewhere for you to check it? Cheers, -K. --------------ms010708030902010302090001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DR0wggYjMIIFC6ADAgECAggY3YeuH0u2eTANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlv bnMgQ2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVz ZWFyY2ggSW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMB4XDTE1MDUwNTEzMzU1NFoXDTIzMDUw MzEzMzU1NFoweTELMAkGA1UEBhMCR1IxLTArBgNVBAoMJEFyaXN0b3RsZSBVbml2ZXJzaXR5 IG9mIFRoZXNzYWxvbmlraTE7MDkGA1UEAwwyQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhl c3NhbG9uaWtpIENlbnRyYWwgQ0EgUjUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjvOiWJ9gvog6JHKxxfC/CfailKSpypKBn62M8M3SjzKWJ8V08gPHqsGC8jpnNkC5w+IpF CJDczTeOTVADmJZayrP3ezTcJQv2h7aPJZ6lreph+GzXSc5lpvGkb8+tc0DLogyYNRytQquc R7Z8DAhZB+3rS28zFLOk4Yw/8Sod41RFU5scv4d0bTzktjvsAcGUkWlXY2rp4QP5ZgSNaH6R HrLLbSjSot2qHVIYQozDWTPJG0MiKySLy2D7njLsWquAGbuXpNnriJx7I7Ix6vrNvxye7jV6 M7qczQ1sJ8QTP60u7FkDgjFtydA3WTctGalGp0WVMIba8m/Ez/KY13IpAgMBAAGjggKQMIIC jDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUdJGEzY+bxcj7 PqN08k50u/ma7kYwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybHYxLmhhcmljYS5nci9I YXJpY2FSb290Q0EyMDExL2NybHYxLmRlci5jcmwwHwYDVR0jBBgwFoAUppFC/RNhSiOeCKQp 5dgTBCPuQSUwbgYIKwYBBQUHAQEEYjBgMCEGCCsGAQUFBzABhhVodHRwOi8vb2NzcC5oYXJp Y2EuZ3IwOwYIKwYBBQUHMAKGL2h0dHA6Ly93d3cuaGFyaWNhLmdyL2NlcnRzL0hhcmljYVJv b3RDQTIwMTEuY3J0MIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEEAbwdAgADBjCCAR4wNAYI KwYBBQUHAgEWKGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvZG9jdW1lbnRzL0NQUy5waHAwgeUG CCsGAQUFBwICMIHYMEoWQ0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1 dGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUg aXMgc3ViamVjdCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRl IG11c3Qgb25seSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9u YWwgcHVycG9zZXMuMC0GA1UdHgQmMCSgIjAJggdhdXRoLmdyMAmBB2F1dGguZ3IwCoEILmF1 dGguZ3IwDQYJKoZIhvcNAQELBQADggEBAKZLw+h67xvMUXpl7pQ+cH5yB7aklIen3Eicb8rw GZVGX67JRowYdic3SSHhj3QfVUrqY+PQ4DwUKiPhm8PCr0rlBS/+uY3yNYT+/+ipSjVku5f9 /Aa+4Fl/kyP5VK0RDcMTJRcaQOoa/xRu94MsvCD1vMzltOfsbraCuYyunr8Zw1BfrcgjE3cu Pp19XWe1qIkeo76jtuT+b5AcByK+o5Dt7kTLrs8M1BCMfd01EqAN2WgOW2cFRFpy0ncN4W7B w4Vvbn0EphssMyK9WPs4xSQ+dU5AA2qnARa8+MM5RENY23e6rfj46cHj0lhBTO2x/fiyaiCq Hq6tA/k7OBJg3fEwggbyMIIF2qADAgECAggUEcgnyrBkEzANBgkqhkiG9w0BAQsFADB5MQsw CQYDVQQGEwJHUjEtMCsGA1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9u aWtpMTswOQYDVQQDDDJBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2Vu dHJhbCBDQSBSNTAeFw0xNTExMTMwMDAwMDBaFw0xNzExMTIwODQ2NTVaMIHxMQswCQYDVQQG EwJHUjEVMBMGA1UEBwwMVGhlc3NhbG9uaWtpMS0wKwYDVQQKDCRBcmlzdG90bGUgVW5pdmVy c2l0eSBvZiBUaGVzc2Fsb25pa2kxGjAYBgNVBAsMEVNjaG9vbCBvZiBQaHlzaWNzMUEwPwYD VQQLDDhDbGFzcyBBIC0gUHJpdmF0ZSBLZXkgY3JlYXRlZCBhbmQgc3RvcmVkIGluIGhhcmR3 YXJlIENTUDEeMBwGA1UEAwwVS29uc3RhbnRpbm9zIExpYWtha2lzMR0wGwYJKoZIhvcNAQkB Fg5rb3N0YXNAYXV0aC5ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP4J7lPp oN8ZwYwnOj/44g9jGaS05OJy23il4M/z1DdbizDhKYwvm4fL+BjjUabPjDfVg9ltCkaXSrmM T743VVK7zdiojxGDKDP6z1J/JJfKzBXOJC0AjYZHHB9anYiDeu4ItBFzz77sCWYg2qA0I0kG eHhx9Ziswg4bIQEwi1Zcn+jjAUc+4YxCwwBzMT56wR7l7bpG8gMN/jjnkrsE7Mbmdf1gOcr9 gfULvUjtRxT9HezUKnHl8dpXPi6nWGxTr+bj05Qo4i/BsvH/H2JCB4N9EOgd3xQGgAAARvgD lVdUE9Yhu3nTT+f3+4m8xjz3Z9vQR7D6Yg0r8kSQ3B1U4ZUCAwEAAaOCAwMwggL/MAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYD VR0OBBYEFJKuQo2V8Bqi9E6simGPn/+fjQRGMB8GA1UdIwQYMBaAFHSRhM2Pm8XI+z6jdPJO dLv5mu5GMHEGCCsGAQUFBwEBBGUwYzAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AucGtpLmF1 dGguZ3IwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvY2VydHMvQXV0aENl bnRyYWxDQVI1LmNydDBHBgNVHR8EQDA+MDygOqA4hjZodHRwOi8vY3JsdjEucGtpLmF1dGgu Z3IvQXV0aENlbnRyYWxDQVI1L2NybHYxLmRlci5jcmwwggEqBgNVHSAEggEhMIIBHTCCAQ8G CysGAQQBvB0CAAMFMIH/MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnBraS5hdXRoLmdyL2Rv Y3VtZW50cy9DUFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlzdG90bGUgVW5pdmVyc2l0 eSBvZiBUaGVzc2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3ViamVjdCB0 byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3Qgb25seSBi ZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVycG9zZXMu MAgGBgQAizABATAiBggrBgEFBQcBAwQWMBQwCAYGBACORgEBMAgGBgQAjkYBBDBMBgNVHREE RTBDgRZrb3N0YXNAcGh5c2ljcy5hdXRoLmdyoCkGCisGAQQBgjcUAgOgGwwZa29zdGFzQHBj bGFicy5pdGMuYXV0aC5ncjApBgkrBgEEAYI3FAIEHB4aAFMAbQBhAHIAdABjAGEAcgBkAFUA cwBlAHIwDQYJKoZIhvcNAQELBQADggEBAFvzyrVJEj7AmTbPe7qtOtEMoQ3wsMj0TLW9o2ED /C0Z2o5rN7QnAkJEJ5DM5r4SQq9pezgOvFFBeUqj3cdPqL2II7XDy7r9BXFbjp+uk9rm3ltl T5kD4aaIWvQKVj67XnyG1L5EfUZy40uG+Z6PjgHQqq4hGDU0Vdn3k0di5caC97Do1u6VO81/ fFeEtKnTHKr+KU6xeBVG73imfo9F5fLy1F9l7+i+cNipA9EwxsocO8pKLY3Hn5Ju+u9fNNuE cnl11eN/nh8FuCqgBtRkmOGRQltaU+p/TPj5VWBKwvdvUmxYElmC9TR+oa6q4sB+deyyuDlG mugeTNLKtIMOb9gxggPAMIIDvAIBATCBhTB5MQswCQYDVQQGEwJHUjEtMCsGA1UECgwkQXJp c3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJBcmlzdG90bGUg VW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHIJ8qwZBMwDQYJ YIZIAWUDBAIBBQCgggILMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE3MDIxNDEzMTQzMFowLwYJKoZIhvcNAQkEMSIEIAbPdW3pr/QT9vQpTTJWTCEjRP5y T5RWPrkaCFgsHm5GMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgZYGCSsGAQQBgjcQBDGBiDCBhTB5MQswCQYDVQQGEwJHUjEtMCsG A1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHI J8qwZBMwgZgGCyqGSIb3DQEJEAILMYGIoIGFMHkxCzAJBgNVBAYTAkdSMS0wKwYDVQQKDCRB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kxOzA5BgNVBAMMMkFyaXN0b3Rs ZSBVbml2ZXJzaXR5IG9mIFRoZXNzYWxvbmlraSBDZW50cmFsIENBIFI1AggUEcgnyrBkEzAN BgkqhkiG9w0BAQEFAASCAQA8nyX8Q974vRBbCo4vyoPy4T/vkDI0/tSAcLqOVwEcgYxI0h7z EyqIRBjk6J3mopYIqmhCz2dztgXW+b44wWErA/Q2r07PeFsUTsileCkXaA2YAGsmqlMYMa5+ ucCVuTsT7rz7dBBbGnYRF/lWqQsbCvdMCqsEgaJC4Z5MpY7PfJNE4I7uWE9FBBzaGH7iEM+C bXokso/ZLBNUBJr7B/+ufeZOfah7yJmjfOsfB5OOgidrFIi5L7DI0WKn4py6uYq31HH+RGso bJgJ3eT1QfT6CqChlu5naZhLSKpFKp3Z3VgeoJsUryQieLvn8Xp2o2ZXN4LrHyD9/OvMcHdm /IBqAAAAAAAA --------------ms010708030902010302090001-- From jaltman@auristor.com Tue Feb 14 14:56:19 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Tue, 14 Feb 2017 09:56:19 -0500 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> <20170214054552.GD30306@kduck.kaduk.org> Message-ID: <814221ba-033a-d396-3e7d-99e9ff8cbed0@auristor.com> This is a cryptographically signed message in MIME format. --------------ms000500080503030407090003 Content-Type: multipart/mixed; boundary="------------1D00D72206BDEA2B880ABD14" This is a multi-part message in MIME format. --------------1D00D72206BDEA2B880ABD14 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/14/2017 8:14 AM, Kostas Liakakis wrote: > Well, I gave up on it :) > Instead commented the #include in cm_nls.c and added a typedef for > _NORM_FORM enum copied out of the MS documentation. The NORM_FORM enum is defined in the Windows SDK. The normalization.h include is protected by a conditional #if (_WIN32_WINNT < 0x0600) /* This is part of the Microsoft Internationalized Domain Name Mitigation APIs. */ # include #endif which matches the conditional in the SDK headers: #if (WINVER >=3D 0x0600) // // Normalization forms // typedef enum _NORM_FORM { ... } NORM_FORM; > Amazingingly, this was enough for the build to proceed and end in > success.=20 The cm_nls.c uses run-time loading of the functions so that the code can be compiled for versions of Windows that do not ship with the NormalizeString() and IsNormalizedString() functions. The IDN is required when building for pre-Vista because you have to install the normaliz.dll library as part of the installer. > Well, at least my openafs/dest directory is now populated and I > could at least run "pts help" and "fs help". Neither pts nor fs use the normalization routines directly. Jeffrey Altman --------------1D00D72206BDEA2B880ABD14 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------1D00D72206BDEA2B880ABD14-- --------------ms000500080503030407090003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIxNDE0NTYxOVowLwYJKoZIhvcNAQkEMSIEIF3a9CzEW+BQRVPlcxIL scy4IcQVzjJBpH6DeRqxLqAPMF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEApqE+jjstxIAPUXoji8EM2QaaeZQDTYb4V/xqp1POaAfCYWYLVMZH o23WX1bYiRZLFXIALSjhPBGWCAwTYkXJeXEePaYm7nT+xyUY+276e/hs7KxYqszveog4h4dK iUSoyQCMySbawtbWWo2Go3QBIIzktefv2sJJ+cBSOSq1+xhXhN2Q4dfQJj34SnA1HO0QjKMK Ulad1bxQsXRXVFPcl4k+N1A3X190j4uVwUPGWYitGaEBjy5oV2CInmuM2rmRD2jzkCPHrHgi 75RH9WKXdOvN0VP2n5j16CSuUaVLvUN3dnj6Gst+wiBAw4NCnxnUMum/bCVZC6eWKR/ipJdS NwAAAAAAAA== --------------ms000500080503030407090003-- From jaltman@auristor.com Tue Feb 14 16:51:19 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Tue, 14 Feb 2017 11:51:19 -0500 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms060405060000020402060101 Content-Type: multipart/mixed; boundary="------------B3EDA65E96ACCFB19039CC71" This is a multi-part message in MIME format. --------------B3EDA65E96ACCFB19039CC71 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/14/2017 7:37 AM, Kostas Liakakis wrote: >=20 > Hi Jeffrey, >=20 > Thanks for taking the time to answer. Please read below inline. >=20 >=20 > On 2017-02-14 03:53, Jeffrey Altman wrote: >> They are built with WiX 3.9 scripts. The >> installation packaging in the OpenAFS tree can no longer be used. > I see. So I'll switch to a later version as Ben suggested and see what > happens. Hopefully we won't have to reinvent the wheel. The WiX 2.0 scripts cannot be used. Someone will have to write a new installer. >> As a reminder, the 1.7.3301 installers that AuriStor, Inc. distributes= >> >> https://www.auristor.com/openafs/client-installer/ >> >> can be installed on Windows 10 and Windows Server 2016 because they ar= e >> grand-fathered. If the same sources were built today they would not >> produce a working file system. > > This statement is a bit disturbing. But should not be surprising since I gave the community plenty of warning= : https://lists.openafs.org/pipermail/openafs-info/2015-March/041324.html https://lists.openafs.org/pipermail/openafs-info/2015-April/041325.html https://lists.openafs.org/pipermail/openafs-info/2015-April/041328.html https://lists.openafs.org/pipermail/openafs-info/2015-April/041330.html https://lists.openafs.org/pipermail/openafs-info/2015-April/041332.html https://lists.openafs.org/pipermail/openafs-info/2015-June/041392.html https://lists.openafs.org/pipermail/openafs-info/2015-July/041449.html http://workshop.openafs.org/afsbpw15/talks/thursday/AFS-on-Windows-AFSBPW= 15.pdf http://workshop.openafs.org/afsbpw15/talks/friday/Securing_The_OS.pdf > Do you mean that given the state of things, even if Windows buildbots > start springing back to life and binaries for current OpenAFS versions > become available, no later version than the already built and signed > 1.7.3301 can be installed on Win10 and later? Will Win7 be ok at least?= I've answered these questions in the e-mails and presentations listed abo= ve. > Do you consider the whole effort to revive the Windows port is in vain?= In April 2015 I provided estimates of what I believe the on-going costs are for obtaining and maintaining a Microsoft signature for a file system. (Second link above.) Last week I attended IFS PlugFest 29. Microsoft is serious about improving the reliability of Windows and its resistance to root kits, ransomeware, and other forms of malware. Each year the requirements that driver vendors must satisfy become more demanding. * Mandatory to implement functionality * Mandatory to use build chains * Mandatory to submit testing reports for each OS variant on which the driver might be installed * Mandatory use of EV code signing certificates The challenge for the OpenAFS community is that the requirements cannot be satisfied simply by compiling the Windows client with the latest tool chains. The mandatory to implement functionality requires support from AFS (VL, FILE, RX, ...) that simply does not exist today. With the release of Windows 10 Creators Update the bar will be raised once again. > Or is there something the the Foundation is planning to do in order to > move forward again on the Windows platform? I am not a member of the Foundation Board. Their minutes can be reviewed at http://www.openafsfoundation.org/about/minutes/ Perhaps a board member could comment on their plans. Jeffrey Altman --------------B3EDA65E96ACCFB19039CC71 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------B3EDA65E96ACCFB19039CC71-- --------------ms060405060000020402060101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIxNDE2NTExOVowLwYJKoZIhvcNAQkEMSIEIL3hDoOjXHf84Nd+gUS/ Ga918GxKytT1lqgYxskLMpQGMF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAo3w6uvwjNRBMuZw60O72HaDYPRkJzrAfgTRJWDeNvOtBcomqfk5A ktIZgK+63v7L20ILPLIgMaQUUZVaqmOlaY79AVEG0+eoh4M7jEY34h98jxzNYEkolwyxBEKU PXGICsagYSrD/lyIs60vJVoNoVLBXnbe8gpvQbFXytNIOo3e11zBdy1CuW5I7nsvnFZd1KgB xh5h3R6RLv3Zvm//4R9iO6SHGlhNLa8vKWkfuIs4KYcnjQlWuO/Ewykv6aArxKapxz3KPbzJ dLIVipCG1o62chcetb0I/IFFpXbQrcki+r09bwFP8++6pyX72dPdp+ChZ3Yh4L/SY77crUo0 KgAAAAAAAA== --------------ms060405060000020402060101-- From kostas@physics.auth.gr Tue Feb 14 17:15:24 2017 From: kostas@physics.auth.gr (Kostas Liakakis) Date: Tue, 14 Feb 2017 19:15:24 +0200 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: <814221ba-033a-d396-3e7d-99e9ff8cbed0@auristor.com> References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> <20170214054552.GD30306@kduck.kaduk.org> <814221ba-033a-d396-3e7d-99e9ff8cbed0@auristor.com> Message-ID: This is a cryptographically signed message in MIME format. --------------ms040904040205060203060508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-02-14 16:56, Jeffrey Altman wrote: > On 2/14/2017 8:14 AM, Kostas Liakakis wrote: >> Well, I gave up on it :) >> Instead commented the #include in cm_nls.c and added a typedef for >> _NORM_FORM enum copied out of the MS documentation. > The NORM_FORM enum is defined in the Windows SDK. The normalization.h > include is protected by a conditional > > #if (_WIN32_WINNT < 0x0600) > /* This is part of the Microsoft Internationalized Domain Name > Mitigation APIs. */ > # include > #endif > > which matches the conditional in the SDK headers: > > #if (WINVER >=3D 0x0600) > // > // Normalization forms > // > > typedef enum _NORM_FORM { > ... > } NORM_FORM; What version of the OpenAFS source tree and Windows Platform SDK are you quotting from? Even in 1.8.0pre1 tarball the normalize.h inclusion in cm_nls.c is unconditional and in Platform SDK 6.0a a quick search comes back empty for NORM_FORM. I started with a "known good" source tree and tried to replicate a known good build environment as suggested in the guide I was pointed at as a starting point. So I picked 1.7.32 and tried to match all the toolchain versions as much as possible. Should I have cloned the git tree instead? And maybe, since you probably have a solid and current build environment already setup, could you please share your tool and SDK versions so I can match them instead of trying to solve problems already dealt with? >> Amazingingly, this was enough for the build to proceed and end in >> success.=20 > The cm_nls.c uses run-time loading of the functions so that the code ca= n > be compiled for versions of Windows that do not ship with the > NormalizeString() and IsNormalizedString() functions. > > The IDN is required when building for pre-Vista because you have > to install the normaliz.dll library as part of the installer. > >> Well, at least my openafs/dest directory is now populated and I >> could at least run "pts help" and "fs help". > Neither pts nor fs use the normalization routines directly. Oh, I see. But anyway, what I wanted to say is that in the end I did manage to get executables that execute... to some extent at least. -K. --------------ms040904040205060203060508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DR0wggYjMIIFC6ADAgECAggY3YeuH0u2eTANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlv bnMgQ2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVz ZWFyY2ggSW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMB4XDTE1MDUwNTEzMzU1NFoXDTIzMDUw MzEzMzU1NFoweTELMAkGA1UEBhMCR1IxLTArBgNVBAoMJEFyaXN0b3RsZSBVbml2ZXJzaXR5 IG9mIFRoZXNzYWxvbmlraTE7MDkGA1UEAwwyQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhl c3NhbG9uaWtpIENlbnRyYWwgQ0EgUjUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjvOiWJ9gvog6JHKxxfC/CfailKSpypKBn62M8M3SjzKWJ8V08gPHqsGC8jpnNkC5w+IpF CJDczTeOTVADmJZayrP3ezTcJQv2h7aPJZ6lreph+GzXSc5lpvGkb8+tc0DLogyYNRytQquc R7Z8DAhZB+3rS28zFLOk4Yw/8Sod41RFU5scv4d0bTzktjvsAcGUkWlXY2rp4QP5ZgSNaH6R HrLLbSjSot2qHVIYQozDWTPJG0MiKySLy2D7njLsWquAGbuXpNnriJx7I7Ix6vrNvxye7jV6 M7qczQ1sJ8QTP60u7FkDgjFtydA3WTctGalGp0WVMIba8m/Ez/KY13IpAgMBAAGjggKQMIIC jDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUdJGEzY+bxcj7 PqN08k50u/ma7kYwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybHYxLmhhcmljYS5nci9I YXJpY2FSb290Q0EyMDExL2NybHYxLmRlci5jcmwwHwYDVR0jBBgwFoAUppFC/RNhSiOeCKQp 5dgTBCPuQSUwbgYIKwYBBQUHAQEEYjBgMCEGCCsGAQUFBzABhhVodHRwOi8vb2NzcC5oYXJp Y2EuZ3IwOwYIKwYBBQUHMAKGL2h0dHA6Ly93d3cuaGFyaWNhLmdyL2NlcnRzL0hhcmljYVJv b3RDQTIwMTEuY3J0MIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEEAbwdAgADBjCCAR4wNAYI KwYBBQUHAgEWKGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvZG9jdW1lbnRzL0NQUy5waHAwgeUG CCsGAQUFBwICMIHYMEoWQ0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1 dGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUg aXMgc3ViamVjdCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRl IG11c3Qgb25seSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9u YWwgcHVycG9zZXMuMC0GA1UdHgQmMCSgIjAJggdhdXRoLmdyMAmBB2F1dGguZ3IwCoEILmF1 dGguZ3IwDQYJKoZIhvcNAQELBQADggEBAKZLw+h67xvMUXpl7pQ+cH5yB7aklIen3Eicb8rw GZVGX67JRowYdic3SSHhj3QfVUrqY+PQ4DwUKiPhm8PCr0rlBS/+uY3yNYT+/+ipSjVku5f9 /Aa+4Fl/kyP5VK0RDcMTJRcaQOoa/xRu94MsvCD1vMzltOfsbraCuYyunr8Zw1BfrcgjE3cu Pp19XWe1qIkeo76jtuT+b5AcByK+o5Dt7kTLrs8M1BCMfd01EqAN2WgOW2cFRFpy0ncN4W7B w4Vvbn0EphssMyK9WPs4xSQ+dU5AA2qnARa8+MM5RENY23e6rfj46cHj0lhBTO2x/fiyaiCq Hq6tA/k7OBJg3fEwggbyMIIF2qADAgECAggUEcgnyrBkEzANBgkqhkiG9w0BAQsFADB5MQsw CQYDVQQGEwJHUjEtMCsGA1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9u aWtpMTswOQYDVQQDDDJBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2Vu dHJhbCBDQSBSNTAeFw0xNTExMTMwMDAwMDBaFw0xNzExMTIwODQ2NTVaMIHxMQswCQYDVQQG EwJHUjEVMBMGA1UEBwwMVGhlc3NhbG9uaWtpMS0wKwYDVQQKDCRBcmlzdG90bGUgVW5pdmVy c2l0eSBvZiBUaGVzc2Fsb25pa2kxGjAYBgNVBAsMEVNjaG9vbCBvZiBQaHlzaWNzMUEwPwYD VQQLDDhDbGFzcyBBIC0gUHJpdmF0ZSBLZXkgY3JlYXRlZCBhbmQgc3RvcmVkIGluIGhhcmR3 YXJlIENTUDEeMBwGA1UEAwwVS29uc3RhbnRpbm9zIExpYWtha2lzMR0wGwYJKoZIhvcNAQkB Fg5rb3N0YXNAYXV0aC5ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP4J7lPp oN8ZwYwnOj/44g9jGaS05OJy23il4M/z1DdbizDhKYwvm4fL+BjjUabPjDfVg9ltCkaXSrmM T743VVK7zdiojxGDKDP6z1J/JJfKzBXOJC0AjYZHHB9anYiDeu4ItBFzz77sCWYg2qA0I0kG eHhx9Ziswg4bIQEwi1Zcn+jjAUc+4YxCwwBzMT56wR7l7bpG8gMN/jjnkrsE7Mbmdf1gOcr9 gfULvUjtRxT9HezUKnHl8dpXPi6nWGxTr+bj05Qo4i/BsvH/H2JCB4N9EOgd3xQGgAAARvgD lVdUE9Yhu3nTT+f3+4m8xjz3Z9vQR7D6Yg0r8kSQ3B1U4ZUCAwEAAaOCAwMwggL/MAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYD VR0OBBYEFJKuQo2V8Bqi9E6simGPn/+fjQRGMB8GA1UdIwQYMBaAFHSRhM2Pm8XI+z6jdPJO dLv5mu5GMHEGCCsGAQUFBwEBBGUwYzAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AucGtpLmF1 dGguZ3IwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cucGtpLmF1dGguZ3IvY2VydHMvQXV0aENl bnRyYWxDQVI1LmNydDBHBgNVHR8EQDA+MDygOqA4hjZodHRwOi8vY3JsdjEucGtpLmF1dGgu Z3IvQXV0aENlbnRyYWxDQVI1L2NybHYxLmRlci5jcmwwggEqBgNVHSAEggEhMIIBHTCCAQ8G CysGAQQBvB0CAAMFMIH/MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnBraS5hdXRoLmdyL2Rv Y3VtZW50cy9DUFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlzdG90bGUgVW5pdmVyc2l0 eSBvZiBUaGVzc2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3ViamVjdCB0 byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3Qgb25seSBi ZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVycG9zZXMu MAgGBgQAizABATAiBggrBgEFBQcBAwQWMBQwCAYGBACORgEBMAgGBgQAjkYBBDBMBgNVHREE RTBDgRZrb3N0YXNAcGh5c2ljcy5hdXRoLmdyoCkGCisGAQQBgjcUAgOgGwwZa29zdGFzQHBj bGFicy5pdGMuYXV0aC5ncjApBgkrBgEEAYI3FAIEHB4aAFMAbQBhAHIAdABjAGEAcgBkAFUA cwBlAHIwDQYJKoZIhvcNAQELBQADggEBAFvzyrVJEj7AmTbPe7qtOtEMoQ3wsMj0TLW9o2ED /C0Z2o5rN7QnAkJEJ5DM5r4SQq9pezgOvFFBeUqj3cdPqL2II7XDy7r9BXFbjp+uk9rm3ltl T5kD4aaIWvQKVj67XnyG1L5EfUZy40uG+Z6PjgHQqq4hGDU0Vdn3k0di5caC97Do1u6VO81/ fFeEtKnTHKr+KU6xeBVG73imfo9F5fLy1F9l7+i+cNipA9EwxsocO8pKLY3Hn5Ju+u9fNNuE cnl11eN/nh8FuCqgBtRkmOGRQltaU+p/TPj5VWBKwvdvUmxYElmC9TR+oa6q4sB+deyyuDlG mugeTNLKtIMOb9gxggPAMIIDvAIBATCBhTB5MQswCQYDVQQGEwJHUjEtMCsGA1UECgwkQXJp c3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJBcmlzdG90bGUg VW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHIJ8qwZBMwDQYJ YIZIAWUDBAIBBQCgggILMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE3MDIxNDE3MTUyNFowLwYJKoZIhvcNAQkEMSIEIFZTpi+BSSs8mUMy6OC9PkoQPnU7 aSc4aySn3OjeONu4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgZYGCSsGAQQBgjcQBDGBiDCBhTB5MQswCQYDVQQGEwJHUjEtMCsG A1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMTswOQYDVQQDDDJB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBSNQIIFBHI J8qwZBMwgZgGCyqGSIb3DQEJEAILMYGIoIGFMHkxCzAJBgNVBAYTAkdSMS0wKwYDVQQKDCRB cmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kxOzA5BgNVBAMMMkFyaXN0b3Rs ZSBVbml2ZXJzaXR5IG9mIFRoZXNzYWxvbmlraSBDZW50cmFsIENBIFI1AggUEcgnyrBkEzAN BgkqhkiG9w0BAQEFAASCAQAVSYkDaFMQxOH1h6eAgqCaNV8p4mNehH5Xul7+D11QO/QmnE1d b6/rxooYUAV7OMGHNmNLFjQzYZkb0Fjt8G8g4q8lhjg2B3LCWV+uCClN1CE6L0m4P9IU7kAo g6rfk7t2zQCk41cAhA2Bdlcjo6mqpMwQqoCANcYwR2ySaCZ4iRP5BbcQaapMPcyi8gWUKPjx /K0GTZvClyY4oBtNfo14X+dDmILUW2ZNYyC3+d99RSmga8CDbiqanJrgTJT65X+OrXpjNJVU 5nS0O/pslTUkgB8SgPh+3dejNt38N/vwTOpdhK5oOh+IBCMFgOdkmQrambBQ4PHlONktKZCo F21/AAAAAAAA --------------ms040904040205060203060508-- From jaltman@auristor.com Tue Feb 14 18:09:34 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Tue, 14 Feb 2017 13:09:34 -0500 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <509efd41-c8cd-54ae-ea1f-3cd2e1b8b8d5@wu.ac.at> <3d2d293d-046b-f792-39fe-46a8cec6f54b@auristor.com> <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> <20170214054552.GD30306@kduck.kaduk.org> <814221ba-033a-d396-3e7d-99e9ff8cbed0@auristor.com> Message-ID: <295b2ae8-4c6c-7bd8-19fe-5b239d2cda92@auristor.com> This is a cryptographically signed message in MIME format. --------------ms060400000705010305040508 Content-Type: multipart/mixed; boundary="------------CE885AEE6647A0987EB390F5" This is a multi-part message in MIME format. --------------CE885AEE6647A0987EB390F5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/14/2017 12:15 PM, Kostas Liakakis wrote: > Even in 1.8.0pre1 tarball the normalize.h inclusion in cm_nls.c is > unconditional and in Platform SDK 6.0a a quick search comes back empty > for NORM_FORM. [C:\Program Files\Microsoft SDKs\Windows\v6.0\Include]grep _NORM_ * WinNls.h:typedef enum _NORM_FORM { [C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include]grep _NORM_ * WinNls.h:typedef enum _NORM_FORM { [C:\Program Files\Microsoft SDKs\Windows\v7.0\Include]grep _NORM_ * WinNls.h:typedef enum _NORM_FORM { [C:\Program Files\Microsoft SDKs\Windows\v8.1\Include\um]grep _NORM_ * WinNls.h:typedef enum _NORM_FORM { etc... > And maybe, since you probably > have a solid and current build environment already setup, could you > please share your tool and SDK versions so I can match them instead of > trying to solve problems already dealt with? If I thought there was benefit in maintaining an out of date tool chain I would not have shutdown the prior builders. Jeffrey Altman --------------CE885AEE6647A0987EB390F5 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------CE885AEE6647A0987EB390F5-- --------------ms060400000705010305040508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIxNDE4MDkzNFowLwYJKoZIhvcNAQkEMSIEIFj/Bc7kyi4jDx4jofgw 0yvGWGTiAg1+UmZOCNjLbZEOMF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEARWGnv8MqDNiR2BzgsKbtNNNFCeYVoR6qpv+aPlFihjI3RQoqtqGN cgIAhjCtccHqrDHuIhSH7aBCzmRHqAX52Oq+jTG5bZGtHrHr+UDT/BzPWNMYPuTGdylkMQyv Sh1f48TXZG8txAXwcylNkhy0lEwEFDrviyc1S7DZ3PnBVgYJNVZ05LohaTVE3/iUco8aXtjh jFU/kOFpPSHehrvZK74HfAFo06zD5t1rKmT7YmXzSiuQ0RP5h7D/9XHTeR2b+EE+j4PgscEn cD8yzlEs50heTtj0uMiR5bFYRlDFg09R41P9g7eMmqPa6Ogkv33T34yJo+GQzywZzfXAG5EG 1AAAAAAAAA== --------------ms060400000705010305040508-- From kaduk@mit.edu Wed Feb 15 03:00:08 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 14 Feb 2017 21:00:08 -0600 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: <814221ba-033a-d396-3e7d-99e9ff8cbed0@auristor.com> References: <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> <20170214054552.GD30306@kduck.kaduk.org> <814221ba-033a-d396-3e7d-99e9ff8cbed0@auristor.com> Message-ID: <20170215030007.GH30306@kduck.kaduk.org> On Tue, Feb 14, 2017 at 09:56:19AM -0500, Jeffrey Altman wrote: > On 2/14/2017 8:14 AM, Kostas Liakakis wrote: > > The IDN is required when building for pre-Vista because you have > to install the normaliz.dll library as part of the installer. I would posit that we should not attempt to support pre-Vista, given the difficulty and our available manpower. (Also, probably not Vista itself, either.) -Ben From kaduk@mit.edu Wed Feb 15 04:53:56 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 14 Feb 2017 22:53:56 -0600 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> Message-ID: <20170215045355.GJ30306@kduck.kaduk.org> On Tue, Feb 14, 2017 at 11:51:19AM -0500, Jeffrey Altman wrote: > On 2/14/2017 7:37 AM, Kostas Liakakis wrote: > > > > Hi Jeffrey, > > > > On 2017-02-14 03:53, Jeffrey Altman wrote: > >> They are built with WiX 3.9 scripts. The > >> installation packaging in the OpenAFS tree can no longer be used. > > I see. So I'll switch to a later version as Ben suggested and see what > > happens. Hopefully we won't have to reinvent the wheel. > > The WiX 2.0 scripts cannot be used. Someone will have to write a new > installer. Well, perhaps there is something of a ship of Theseus when "new" is used...someone will certainly need to read up on WiX and understand what is going on, at least. It's a little strange coming from my background, but IIRC the documentation was fairly reasonable. -Ben From kaduk@mit.edu Wed Feb 15 05:04:20 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 14 Feb 2017 23:04:20 -0600 Subject: [OpenAFS] OpenAFS Windows build environment In-Reply-To: References: <10f59b43-06a1-f6df-a8d0-1444485b70e1@wu.ac.at> <20170208182254.GZ7875@cnf.cornell.edu> <20170210172408.GS7875@cnf.cornell.edu> <20170214054552.GD30306@kduck.kaduk.org> Message-ID: <20170215050419.GK30306@kduck.kaduk.org> On Tue, Feb 14, 2017 at 03:14:30PM +0200, Kostas Liakakis wrote: > Hello Ben, > > > So, where to now? Is there a way to actually test the resulting binaries > as they are? Try a newer WiX version and see where it bombs? Upload the > build result somewhere for you to check it? It may be easiest to test the resulting binaries "in-place", or perhaps on a separate scratch VM that can be wiped clean easily (as opposed to the build VM itself, which may require effort to replace, depending on the state of snapshotting available, etc.). E.g., on win7 you can boot into developer mode that does not require any signatures on the kernel modules at all, which suffices to test functionality of the build. Of course, openafs in general is lacking in automated test coverage, so the first step might just be manual testing. (Writing automated testing would be a great second step!) I have no interest in trying out the build results myself, so don't upload them just for my benefit. (Maybe there are other volunteers, though? They should feel free to speak up if there is interest.) I also have little interest in rewriting the installer with only email feedback on how things work. So, trying out the build with a newer WiX is probably only worth it if you (or someone you know) is interested in learning WiX and working through the needed changes. http://wixtoolset.org/documentation/manual/v3/ would probably be the relevant documentation landing point, alongside reading through some existing installer XML to see what is used in practice. (That is not necessarily the existing openafs installer XML, which as we have established is essentially unmaintained and unlikely to be a great example. I don't have a great sense for how many open-source projects are using WiX, but maybe one of the Kerberos distributions would be a useful example. MIT's installer would be around https://github.com/krb5/krb5/tree/master/src/windows/installer/wix ... maybe Jeffrey has a link handy to the Heimdal equivalent?) -Ben From drosih@rpi.edu Wed Feb 15 18:48:52 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Wed, 15 Feb 2017 13:48:52 -0500 Subject: [OpenAFS] Security Advisory 2016-003 and 'bos salvage' questions Message-ID: <3B2B0FEC-EDF0-4018-8B55-39C33F97C358@rpi.edu> I had an odd situation pop up when upgrading to OpenAFS 1.6.20.1. The description of the security advisory at http://www.openafs.org/pages/security/OPENAFS-SA-2016-003.txt says: > We further recommend that administrators salvage all volumes with > the -salvagedirs option, in order to remove existing leaks. I'm upgrading our file servers from OpenAFS 1.6.14 to 1.6.20.1 (and also upgrading our RHEL 7.3 kernel from version 3.10.0-327.el7 to version 3.10.0-514.6.1.el7 on those machines). We had some other changes going on as part of this, and I wanted to minimize how much disruption might occur if something went wrong with any of the changes. So I: 1) created a small-capacity file server with the new OpenAFS and newer kernel. 2) 'vos move'-ed some of the busier non-replicated volumes from an existing file server to the new file server. 3) upgraded that existing file server. 4) moved volumes back. ... wait a few days, and repeat for a different file server. There's no step there where I did a 'bos salvage -salvagedirs'. I had forgotten about that advice in the advisory. I did all these steps for a few file servers with no problems at all. On my most-recent server, my script which does step #4 moved 26 volumes, and then hit this error on the 27th one: > Failed to move data for the volume 53.....75 > VOLSER: Problems encountered in doing the dump ! > Recovery:Failed to start transaction on 53.....75 > Volume needs to be salvaged Is this simply that 'vos move' in version 1.6.20.1 is doing more consistency checks than version 1.6.14 did? The last-update time for that volume is in Oct 2008, so it's not like it has been changed recently. And the new fileserver for temp-storage hasn't even restarted since I've started this upgrade. The volume is still on-line for AFS users, and at the user level it seems to be in fine shape. From what little I can tell, I can access all 47,000 files without any errors. Is it reasonable for me to just do the 'bos salvage' for this specific volume, then do the 'bos salvage -salvagedirs' for the entire partition on the temp-space fileserver, and then do that on the existing (newly-upgraded) fileserver, and then restart my vos-moves? Also, can I do the 'bos salvage -salvagedirs' while the 'fs' process is running, or do I need to stop and restart 'fs' around that salvage command? I did a 'bos salvage -help', and see a number of interesting options are available which I don't see in the man page or the documentation. I'm inclined to go with '-orphans ignore' for a first-run, and then see what is listed for orphans. I'm also curious about the '-nowrite' option. Will that do a thorough check of what 'salvage' would need to do, but without making any modifications to the volume? -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From drosih@rpi.edu Fri Feb 17 04:52:47 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Thu, 16 Feb 2017 23:52:47 -0500 Subject: [OpenAFS] Re: Security Advisory 2016-003 and 'bos salvage' questions In-Reply-To: <3B2B0FEC-EDF0-4018-8B55-39C33F97C358@rpi.edu> References: <3B2B0FEC-EDF0-4018-8B55-39C33F97C358@rpi.edu> Message-ID: <1E22BF5A-7C0E-443B-B8DB-5163E0CBE0B2@rpi.edu> On 15 Feb 2017, at 13:48, Garance A Drosehn wrote: > I had an odd situation pop up when upgrading to OpenAFS 1.6.20.1. > On my most-recent server, my script which does step #4 moved 26 > volumes, and then hit this error on the 27th one: > >> Failed to move data for the volume 53.....75 >> VOLSER: Problems encountered in doing the dump ! >> Recovery:Failed to start transaction on 53.....75 >> Volume needs to be salvaged Here's a short follow-up on this, although no one else has commented on it. FWIW, I did do the 'bos salvage -salvagedirs', and it automatically stops and starts the 'fs' process around the salvaging step. It took 2m17.62s on a file server which has used up 40.96-gig out of 153.53-gig on the server. And it took 24m19.27s on a file server which has used 145.46-gig of the 255.88-gig on the server. However, there's definitely something odd going on with the step where I 'vos move' volumes from my temp-server back to the file server they were originally on. I'm seeing 'core' files under /usr/afs/logs on the destination of that 'vos move'. Also, after a failed 'vos move' a 'vos examine' of the volume will display an volume-ID for a read-only instance of the volume, even though the volume did not have a read-only instance before the move. It isn't that there *is* a read-only instance, just that the RDOnly field is filled in whereas it used to be 0. I've had three different volumes fail when I tried to move them, and all had a volume-id appear for the read-only instance. For the initial 26 volumes which were successfully moved, they still show a RDOnly volume-id of 0. Obviously I need to do some more investigation, but I thought I'd mention these bits. I guess I might need to learn what to do with the afs core files! -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From drosih@rpi.edu Fri Feb 17 21:49:19 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Fri, 17 Feb 2017 16:49:19 -0500 Subject: [OpenAFS] Re: Security Advisory 2016-003 and 'bos salvage' questions In-Reply-To: <3B2B0FEC-EDF0-4018-8B55-39C33F97C358@rpi.edu> References: <3B2B0FEC-EDF0-4018-8B55-39C33F97C358@rpi.edu> Message-ID: On 15 Feb 2017, at 13:48, Garance A Drosehn wrote: > I had an odd situation pop up when upgrading to OpenAFS 1.6.20.1. > On my most-recent server, my script which does step #4 moved 26 > volumes, and then hit this error on the 27th one: > >> Failed to move data for the volume 53.....75 >> VOLSER: Problems encountered in doing the dump ! >> Recovery:Failed to start transaction on 53.....75 >> Volume needs to be salvaged I won't flood people with lots of blow-by-blow details, but at the moment I strongly suspect it is something wrong with the specific machine I'm trying to move volumes back to. I just moved over 500 volumes from the "temp" file server to a different file server which was already upgraded to OpenAFS 1.6.20.1, and there were no problems. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From drosih@rpi.edu Sun Feb 19 16:19:21 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Sun, 19 Feb 2017 11:19:21 -0500 Subject: [OpenAFS] Is the OpenAFS-info mailing list still working? Message-ID: <4D5ECD89-5573-4C92-9060-DE942C7C4B4F@rpi.edu> Hi. On the last few messages I've sent to openafs-info@, the mailing list does not send me a copy of the email that I sent. Looking back at older emails, the mailing list did always send me a copy. I do see that my messages show up at: https://lists.openafs.org/pipermail/openafs-info/2017-February/date.html so the mailing list isn't completely broken. But is there something odd going on with it? -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From jaltman@auristor.com Sun Feb 19 16:33:51 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Sun, 19 Feb 2017 11:33:51 -0500 Subject: [OpenAFS] Is the OpenAFS-info mailing list still working? In-Reply-To: <4D5ECD89-5573-4C92-9060-DE942C7C4B4F@rpi.edu> References: <4D5ECD89-5573-4C92-9060-DE942C7C4B4F@rpi.edu> Message-ID: <0e136c10-ca5d-f9a9-a418-f9e141de92b7@auristor.com> This is a cryptographically signed message in MIME format. --------------ms040309020800030702060701 Content-Type: multipart/mixed; boundary="------------48A4CE54C690D7022464367D" This is a multi-part message in MIME format. --------------48A4CE54C690D7022464367D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/19/2017 11:19 AM, Garance A Drosehn wrote: > Hi. On the last few messages I've sent to openafs-info@, the mailing > list does not send me a copy of the email that I sent. Looking back > at older emails, the mailing list did always send me a copy. >=20 > I do see that my messages show up at: > https://lists.openafs.org/pipermail/openafs-info/2017-February/date.h= tml >=20 > so the mailing list isn't completely broken. But is there something > odd going on with it? >=20 Most likely the rpi.edu mail server is blocking mail that has an rpi.edu from address but was not sent from one of the approved rpi.edu mail servers as listed in the rpi.edu TXT record "v=3Dspf1 ip4:128.113.2.225/29 ip4:128.113.2.231 ip4:128.113.2.232 ip4:128.113.2.233 ip4:128.113.26.109 -all" Since the mailing list mail does not originate from one of the approved mail servers it is blocked. The mailing list is not broken. Jeffrey Altman --------------48A4CE54C690D7022464367D Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------48A4CE54C690D7022464367D-- --------------ms040309020800030702060701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIxOTE2MzM1MVowLwYJKoZIhvcNAQkEMSIEIFKhFLmNz6y0Uuoh0HiM 2gaHMEBr8Y6EHp2a6FrDZuE4MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAOH7oqua6AS6g1wcWemCDpoZybHExIZaBZhsp/EILaARQv3DKVVBL +cm4mVF7KzzQ529dAioKTtRiv7NvmjKYRQZU/DW2lm+B8Xm9l+Hj10WtZ8iVRuzSYkr0yyMK WQxQaVmUAShXtHazcxc0RhkBtBNV3ZMCU7DEP/EAYq0ZHbl/dtLcnZLcSP/NS2TNRMk9kREI gcZMC9TVsrmU3l2Gh9kO62/itcD8yn1AWiAa/QQgyVdXwt5GmTpAL1p1hbXL3mQ8a9/Co1XA IRy9l7SvQwORjWCFn/R3LiWLEI/zNaTJuhzjYrU1cBs7D08eGjmrXS5tq2cme1mGmY68FQFG RgAAAAAAAA== --------------ms040309020800030702060701-- From drosih@rpi.edu Sun Feb 19 16:49:40 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Sun, 19 Feb 2017 11:49:40 -0500 Subject: [OpenAFS] Weirdness after 'vos move's - core files? Message-ID: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu> I'm not sure this mailing list is still working, but if it is, here is some more info on some weird issues I'm seeing on one of our file servers after upgrading to openafs 1.6.20-1. Note that I upgraded three other file servers to openafs 1.6.20-1 without any trouble. To recap, I first moved the busiest volumes off the file server (in case the upgrade would take a long time). I then installed a new redhat kernel and the new version of openafs as compiled for that kernel (which was done on a different file server). This is the same process I've followed on other file servers. I then went to move volumes back to the now-upgraded file server. 26 volumes transferred fine, and then the 27th failed. So did three other volumes that I tried to move back. I then picked up *all* the remaining volumes (including the four that failed), and successfully moved them to a different file server which had already been upgraded to openafs 1.6.20-1. And that went without any problems. On the file server which I couldn't move volumes to, a 'listvol' command showed four "**** Could not attach volume ****" messages, one for each volume that had failed. I tried doing a "vos syncvldb" for each one those volumes on all of our file servers, followed by a "vos syncserv" on all our file servers. This didn't get rid of the "Could not attach" messages. I rebooted the file server, which also didn't change anything. I then did a "bos salvage", which took 30 minutes and finished okay. After it finished, the "Could not attach" messages were gone from "listvol". So I tried to "vos move" another volume from a different file server to the problematic one. And this "vos move" failed again, leaving behind two core files in /usr/afs/logs. I'm doing another "bos salvage" command, just because those "Could not attach" messages annoy me. Is there something I could do with those core files which would help to figure out what the problem is with this file server? I also have plenty of log files, if those would provide some clues. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From drosih@rpi.edu Sun Feb 19 16:55:10 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Sun, 19 Feb 2017 11:55:10 -0500 Subject: [OpenAFS] Is the OpenAFS-info mailing list still working? In-Reply-To: <0e136c10-ca5d-f9a9-a418-f9e141de92b7@auristor.com> References: <4D5ECD89-5573-4C92-9060-DE942C7C4B4F@rpi.edu> <0e136c10-ca5d-f9a9-a418-f9e141de92b7@auristor.com> Message-ID: On 19 Feb 2017, at 11:33, Jeffrey Altman wrote: > On 2/19/2017 11:19 AM, Garance A Drosehn wrote: >> Hi. On the last few messages I've sent to openafs-info@, the mailing >> list does not send me a copy of the email that I sent. Looking back >> at older emails, the mailing list did always send me a copy. >> >> I do see that my messages show up at: >> https://lists.openafs.org/pipermail/openafs-info/2017-February/date.html >> >> so the mailing list isn't completely broken. But is there something >> odd going on with it? >> > > Most likely the rpi.edu mail server is blocking mail that has an rpi.edu > from address but was not sent from one of the approved rpi.edu mail > servers as listed in the rpi.edu TXT record > > "v=spf1 ip4:128.113.2.225/29 ip4:128.113.2.231 ip4:128.113.2.232 > ip4:128.113.2.233 ip4:128.113.26.109 -all" > > Since the mailing list mail does not originate from one of the approved > mail servers it is blocked. > > The mailing list is not broken. Okay, that seems likely. I believe we have made changes on our mail server in the last two months. It's pretty likely that this the first time I've sent a message to this list since those changes. Thanks! -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From tcreedon@easystreet.net Sun Feb 19 21:08:22 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Sun, 19 Feb 2017 21:08:22 +0000 Subject: [OpenAFS] Is the OpenAFS-info mailing list still working? In-Reply-To: References: <4D5ECD89-5573-4C92-9060-DE942C7C4B4F@rpi.edu> <0e136c10-ca5d-f9a9-a418-f9e141de92b7@auristor.com>, Message-ID: worse than that, something is marking my messages to openafs-info as spam. this is the only website that this occurs on. tedc ________________________________________ From: openafs-info-admin@openafs.org on be= half of Garance A Drosehn Sent: Sunday, February 19, 2017 8:55:10 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] Is the OpenAFS-info mailing list still working? On 19 Feb 2017, at 11:33, Jeffrey Altman wrote: > On 2/19/2017 11:19 AM, Garance A Drosehn wrote: >> Hi. On the last few messages I've sent to openafs-info@, the mailing >> list does not send me a copy of the email that I sent. Looking back >> at older emails, the mailing list did always send me a copy. >> >> I do see that my messages show up at: >> https://lists.openafs.org/pipermail/openafs-info/2017-February/date.ht= ml >> >> so the mailing list isn't completely broken. But is there something >> odd going on with it? >> > > Most likely the rpi.edu mail server is blocking mail that has an rpi.edu > from address but was not sent from one of the approved rpi.edu mail > servers as listed in the rpi.edu TXT record > > "v=3Dspf1 ip4:128.113.2.225/29 ip4:128.113.2.231 ip4:128.113.2.232 > ip4:128.113.2.233 ip4:128.113.26.109 -all" > > Since the mailing list mail does not originate from one of the approved > mail servers it is blocked. > > The mailing list is not broken. Okay, that seems likely. I believe we have made changes on our mail server in the last two months. It's pretty likely that this the first time I've sent a message to this list since those changes. Thanks! -- Garance Alistair Drosehn =3D drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From kaduk@mit.edu Mon Feb 20 05:25:24 2017 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sun, 19 Feb 2017 23:25:24 -0600 Subject: [OpenAFS] Weirdness after 'vos move's - core files? In-Reply-To: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu> References: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu> Message-ID: <20170220052523.GZ30306@kduck.kaduk.org> On Sun, Feb 19, 2017 at 11:49:40AM -0500, Garance A Drosehn wrote: > > Is there something I could do with those core files which would help to > figure out what the problem is with this file server? I also have > plenty of log files, if those would provide some clues. Well, it's not entirely clear. One could of course load them up in gdb and see what the backtrace looks like, of course, but given the described behavior, if I was in this situation, I would be looking at hardware diagnostics on this machine (memtest86, SMART output, bonnie++, etc.). I do not believe that openafs is expected to be particularly robust against failing hardware... -Ben From tcreedon@easystreet.net Mon Feb 20 15:41:19 2017 From: tcreedon@easystreet.net (Ted Creedon) Date: Mon, 20 Feb 2017 15:41:19 +0000 Subject: [OpenAFS] Weirdness after 'vos move's - core files? In-Reply-To: <20170220052523.GZ30306@kduck.kaduk.org> References: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu>,<20170220052523.GZ30306@kduck.kaduk.org> Message-ID: Why not set it up in IBM's Eclipse CDT & debug it? ________________________________________ From: openafs-info-admin@openafs.org on be= half of Benjamin Kaduk Sent: Sunday, February 19, 2017 9:25:24 PM To: Garance A Drosehn Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Weirdness after 'vos move's - core files? On Sun, Feb 19, 2017 at 11:49:40AM -0500, Garance A Drosehn wrote: > > Is there something I could do with those core files which would help to > figure out what the problem is with this file server? I also have > plenty of log files, if those would provide some clues. Well, it's not entirely clear. One could of course load them up in gdb and see what the backtrace looks like, of course, but given the described behavior, if I was in this situation, I would be looking at hardware diagnostics on this machine (memtest86, SMART output, bonnie++, etc.). I do not believe that openafs is expected to be particularly robust against failing hardware... -Ben _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From drosih@rpi.edu Mon Feb 20 18:56:39 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Mon, 20 Feb 2017 13:56:39 -0500 Subject: [OpenAFS] Weirdness after 'vos move's - core files? In-Reply-To: <20170220052523.GZ30306@kduck.kaduk.org> References: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu> <20170220052523.GZ30306@kduck.kaduk.org> Message-ID: On 20 Feb 2017, at 0:25, Benjamin Kaduk wrote: > On Sun, Feb 19, 2017 at 11:49:40AM -0500, Garance A Drosehn wrote: >> >> Is there something I could do with those core files which would help >> to figure out what the problem is with this file server? I also >> have plenty of log files, if those would provide some clues. > > Well, it's not entirely clear. One could of course load them up in > gdb and see what the backtrace looks like, of course, but given the > described behavior, if I was in this situation, I would be looking > at hardware diagnostics on this machine (memtest86, SMART output, > bonnie++, etc.). I do not believe that openafs is expected to be > particularly robust against failing hardware... > > -Ben This file server is a virtual machine on hardware and disk-storage that is being shared with several other virtual machines. I realize the main culprit could certainly be hardware, but if it is then I won't be the only sysadmin who is will be unhappy about that! :) That also makes it harder to run true HW-level diagnostics. It has been awhile since I've tried to use gdb to investigate a core file, so right now I'm trying to resurrect those ancient corners of my brain. FWIW, here's an anonymized version of the log-file entry of the last vos-move which worked. This is from the Volser log file on the (just-upgraded) destination file server, which is the one I'm claiming is the broken one: - 12:14:24 - VReadVolumeDiskHeader: Couldn't open header for volume 53...561 (errno 2). - 12:14:24 - admin_gad on gads_mac.rpi.edu is executing CreateVolume 'c._worked_.i41' - 12:14:24 - 1 Volser: CreateVolume: volume 53...561 (c._worked_.i41) created - 12:14:24 - on fs_src.rpi.edu is executing Restore 53...561 - 12:14:26 - RestoreVolume Cleanup: Removed 0 inodes for volume 53...561 - 12:14:26 - RestoreVolume Cleanup: Removed 0 inodes for volume 53...561 - 12:14:26 - on fs_src.rpi.edu is executing Restore 53...561 - 12:14:26 - RestoreVolume Cleanup: Removed 0 inodes for volume 53...561 - 12:14:26 - RestoreVolume Cleanup: Removed 0 inodes for volume 53...561 - 12:14:27 - VReadVolumeDiskHeader: Couldn't open header for volume 53...563 (errno 2). - 12:14:27 - admin_gad on gads_mac.rpi.edu is executing Clone Volume new name=c._worked_.i41.backup - 12:14:27 - 1 Volser: Clone: Cloning volume 53...561 to new volume 53...563 And here's the info for the first vos-move which failed: - 12:14:28 - VReadVolumeDiskHeader: Couldn't open header for volume 53...175 (errno 2). - 12:14:28 - admin_gad on gads_mac.rpi.edu is executing CreateVolume 'c._failed_.2006a' - 12:14:28 - 1 Volser: CreateVolume: volume 53...175 (c._failed_.2006a) created - 12:14:28 - on fs_src.rpi.edu is executing Restore 53...175 - 12:14:28 - 1 Volser: ReadVnodes: IH_CREATE: Structure needs cleaning - restore aborted - 12:14:28 - SYNC_ask: negative response on circuit 'FSSYNC' - 12:14:28 - FSYNC_askfs: FSSYNC request denied for reason=101 - 12:14:28 - SYNC_ask: negative response on circuit 'FSSYNC' - 12:14:28 - FSYNC_askfs: FSSYNC request denied for reason=101 - 12:17:26 - 1 Volser: GetVolInfo: Could not attach volume 53...175 (/vicepa:V053...175.vol) error=101 Does that suggest hardware issues? (I have no idea if it does...) Looking at the log files, I can also see some 'vos release's, where an RO-instance of the replicated volume is on this broken server. If I do a 'vos examine' of the volume, the RO-instance on this server is the "old release" while the instances on other file servers are the "new release". I'm going to guess that this is NotGood(tm). -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From drosih@rpi.edu Mon Feb 20 21:07:49 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Mon, 20 Feb 2017 16:07:49 -0500 Subject: [OpenAFS] Weirdness after 'vos move's - core files? In-Reply-To: <20170220052523.GZ30306@kduck.kaduk.org> References: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu> <20170220052523.GZ30306@kduck.kaduk.org> Message-ID: <18DF0300-C59A-4077-B25F-D7CBDFEF3283@rpi.edu> On 20 Feb 2017, at 0:25, Benjamin Kaduk wrote: > On Sun, Feb 19, 2017, Garance A Drosehn wrote: >> >> Is there something I could do with those core files which would help >> to >> figure out what the problem is with this file server? I also have >> plenty of log files, if those would provide some clues. > > Well, it's not entirely clear. One could of course load them up in > gdb and see what the backtrace looks like, of course, but given the > described behavior, if I was in this situation, I would be looking > at hardware diagnostics on this machine (memtest86, SMART output, > bonnie++, etc.). I do not believe that openafs is expected to be > particularly robust against failing hardware... I skipped over some pretty significant info in my few messages to this mailing list. Back on Jan 6th, this file server (and several other VM's, including two other file servers) were running on a different hypervisor. That hypervisor crashed Jan 6th due to the motherboard failing (!). Parts were replaced, and we were back up. We intended to move all these VM's to a newer VMware cluster, but that took a little while to setup. Then on Feb 8th, a "minor config change" to the hypervisor which had died on Jan 6th caused that hypervisor to crash again. Ugh! But we brought everything back up again. We then moved each of the file servers, one at a time, and on separate days. We'd completely shut down a file-server, move all the data, and then bring it back up in the cluster. The first two of these moves went perfectly fine. The move of the third file-server also went fine, done on Feb 14th. I didn't notice any problems until I started moving AFS volumes back to that file server, on the 16th. So the *current* hardware and disk storage should be fine, but there *were* two very abrupt crashes on the previous hardware, and those could have corrupted data structure(s) on the file server. The salvager process ran automatically when the file-server came back up on both Jan 6th and Feb 8th. No interesting messages in the SalvageLog on Jan 6th, but I now notice that the log for Feb 8th includes the (wrapped) line: - namei_ListAFSSubDirs: warning: VG 536877708 does not \ have a link table; salvager will recreate it.". That seems mighty suspicious given that the full-salvage done on Jan 6th did not report that problem. And there's also a SalvageLog from the 16th, which is when I did the "bos salvage -all -salvagedirs". That file has over 225,000 lines in it, and at the time I had only looked at the first few hundred and the last few hundred. Nothing exciting there. But I now see that in the middle of the log there are many lines such as: - Salvaging directory 263... - Checking the results of the directory salvage... - dir vnode 263: invalid entry deleted: ./toolbox/..etc.. (vnode 23654, unique 12858) I am guessing that is also "not good". Sigh. While I have upgraded five of our servers to OpenAFS 1.6.20.1, I have only done the "bos salvage -all -salvagedirs" step on three of those five. But for those three, this is the only server which has any complaints about "invalid entry deleted". In any case, it now seems almost certain that the crash on Feb 8th is the primary cause for all the problems we're seeing. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From drosih@rpi.edu Mon Feb 20 22:21:22 2017 From: drosih@rpi.edu (Garance A Drosehn) Date: Mon, 20 Feb 2017 17:21:22 -0500 Subject: [OpenAFS] Weirdness after 'vos move's - core files? In-Reply-To: <18DF0300-C59A-4077-B25F-D7CBDFEF3283@rpi.edu> References: <1494C40A-69F9-404F-BC13-B7A5C0B5105C@rpi.edu> <20170220052523.GZ30306@kduck.kaduk.org> <18DF0300-C59A-4077-B25F-D7CBDFEF3283@rpi.edu> Message-ID: <74F3FF8B-7972-47C5-81B7-171ABCF55534@rpi.edu> On 20 Feb 2017, at 16:07, Garance A Drosehn wrote: > On 20 Feb 2017, at 0:25, Benjamin Kaduk wrote: > >> [...] if I was in this situation, I would be looking at >> hardware diagnostics on this machine (memtest86, SMART output, >> bonnie++, etc.). I do not believe that openafs is expected to be >> particularly robust against failing hardware... > > I skipped over some pretty significant info in my few messages to > this mailing list. [...skipping...] > In any case, it now seems almost certain that the crash on > Feb 8th is the primary cause for all the problems we're seeing. Btw, thanks to Benjamin for mentioning the hardware angle, which got me thinking of all the details I had skipped over. I have been bouncing between several different (and completely unrelated) crises here, and have completely lost track of which events happened when. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From jjbyers@andrew.cmu.edu Mon Feb 20 21:55:43 2017 From: jjbyers@andrew.cmu.edu (Joshua Byers) Date: Mon, 20 Feb 2017 21:55:43 +0000 Subject: [OpenAFS] OpenAFS preference pane error Message-ID: --_000_B040A91920364B38BEB8A481DF9B2A08andrewcmuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgYW0gd29uZGVyaW5nIGlmIGFueW9uZSBoYXMgc2VlbiB0aGUgZm9sbG93aW5n IGVycm9yIHdoZW4gbG9hZGluZyB0aGUgT3BlbkFGUyBwcmVmZXJlbmNlIHBhbmUgaW4gT3BlbkFG UyBjb21waWxlZCBieSBTaW5lIE5vbWluZSAxLjYuMjAgZm9yIEVsIENhcGl0YW4/DQoNCiJJbnZh bGlkIHBhcmFtZXRlciBub3Qgc2F0aXNmeWluZzogYVN0cmluZyAhPSBuaWzigIsiDQoNCkkgY2Fu IGdldCB0aWNrZXRzIGFuZCB0b2tlbnMgYXQgdGhlIGNvbW1hbmQgbGluZSBmaW5lLiAgSG93ZXZl ciwgdGhlIHByZWZlcmVuY2UgcGFuZSBpcyB1bnJlbGlhYmxlIGF0IGJlc3QuDQoNClRoYW5rcyBp biBhZHZhbmNlLA0KDQpKb3NodWEgQnllcnMNClN5c3RlbXMgQWRtaW5pc3RyYXRvcg0KQ2FybmVn aWUgTWVsbG9uIFVuaXZlcnNpdHkNCmpqYnllcnNAYW5kcmV3LmNtdS5lZHU8bWFpbHRvOmpqYnll cnNAYW5kcmV3LmNtdS5lZHU+DQoNCg== --_000_B040A91920364B38BEB8A481DF9B2A08andrewcmuedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIHdvbmRlcmluZyBpZiBh bnlvbmUgaGFzIHNlZW4gdGhlIGZvbGxvd2luZyBlcnJvciB3aGVuIGxvYWRpbmcgdGhlIE9wZW5B RlMgcHJlZmVyZW5jZSBwYW5lIGluIE9wZW5BRlMgY29tcGlsZWQgYnkgU2luZSBOb21pbmUgMS42 LjIwIGZvciBFbCBDYXBpdGFuPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+JnF1b3Q7SW52YWxpZCBwYXJhbWV0ZXIgbm90IHNhdGlzZnlp bmc6IGFTdHJpbmcgIT0gbmls4oCLJnF1b3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGNhbiBnZXQgdGlja2V0cyBhbmQgdG9rZW5z IGF0IHRoZSBjb21tYW5kIGxpbmUgZmluZS4gJm5ic3A7SG93ZXZlciwgdGhlIHByZWZlcmVuY2Ug cGFuZSBpcyB1bnJlbGlhYmxlIGF0IGJlc3QuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MgaW4gYWR2YW5jZSw8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkpvc2h1YSBC eWVyczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TeXN0ZW1zIEFkbWluaXN0cmF0b3I8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Q2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHk8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGEgaHJlZj0ibWFpbHRvOmpqYnllcnNAYW5kcmV3LmNtdS5lZHUiIGNsYXNzPSIiPmpqYnll cnNAYW5kcmV3LmNtdS5lZHU8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B040A91920364B38BEB8A481DF9B2A08andrewcmuedu_-- From stephan.wiesand@desy.de Wed Feb 22 14:47:52 2017 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Wed, 22 Feb 2017 15:47:52 +0100 Subject: [OpenAFS] OpenAFS preference pane error In-Reply-To: References: Message-ID: Hello, On Feb 20, 2017, at 22:55 , Joshua Byers wrote: > Hello, >=20 > I am wondering if anyone has seen the following error when loading the = OpenAFS preference pane in OpenAFS compiled by Sine Nomine 1.6.20 for El = Capitan? >=20 > "Invalid parameter not satisfying: aString !=3D nil=E2=80=8B" >=20 > I can get tickets and tokens at the command line fine. However, the = preference pane is unreliable at best. we have a prefpane fix in https://gerrit.openafs.org/#/c/12512/ . It = will be in the next stable release. I'm not sure whether it will fix = your issue though. Anyone? > Thanks in advance, >=20 > Joshua Byers --=20 Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From mbarbosa@sinenomine.net Thu Feb 23 17:31:47 2017 From: mbarbosa@sinenomine.net (Marcio Barbosa) Date: Thu, 23 Feb 2017 17:31:47 +0000 Subject: [OpenAFS] OpenAFS preference pane error Message-ID: <88DABE04-1272-48E9-8B88-32158C1D1F65@sinenomine.net> --_000_88DABE04127248E98B8832158C1D1F65sinenominenet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > we have a prefpane fix in https://gerrit.openafs.org/#/c/12512/ . It =3D > will be in the next stable release. I'm not sure whether it will fix =3D > your issue though. Anyone? Yes. This patch will fix this problem. Thank you. Marcio Barbosa. --_000_88DABE04127248E98B8832158C1D1F65sinenominenet_ Content-Type: text/html; charset="us-ascii" Content-ID: <3CF553F8F1DB72429E3599C687895380@mex09.mlsrvr.com> Content-Transfer-Encoding: quoted-printable 
> we have a prefpane fi=
x in https://g=
errit.openafs.org/#/c/12512/ . It =3D
> will be in the next stable release. I'm not sure whether it will fix =
=3D
> your issue though. Anyone?

Yes. This patch will fix t=
his problem.
Thank you.
Marcio Barbosa.

--_000_88DABE04127248E98B8832158C1D1F65sinenominenet_-- From Walter.Tienken@asu.edu Mon Feb 27 18:50:32 2017 From: Walter.Tienken@asu.edu (Walter Tienken) Date: Mon, 27 Feb 2017 18:50:32 +0000 Subject: [OpenAFS] vos dumps to S3 via S3 Storage Gateway? Message-ID: --_000_CY4PR06MB3016CCC69C8C12601130E88386570CY4PR06MB3016namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, We currently perform nightly dumps to an on-prem NFS mount. I was curious i= f anyone has had any experience with using an Amazon S3 Storage Gateway for= similar purpose? With much of the focus of "to the cloud" with many leader= ship members/organization administrators, I figured it is a good question t= o ask here. If yes, what has been your experience so far? Do you pass throu= gh the public internet or perhaps use Amazon Direct Connect? Thanks in advance for your input! Walter Tienken walter.tienken@asu.edu UTO OPS Systems and Security --_000_CY4PR06MB3016CCC69C8C12601130E88386570CY4PR06MB3016namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

We currently perform nightly dumps to an on-prem NFS= mount. I was curious if anyone has had any experience with using an Amazon= S3 Storage Gateway for similar purpose? With much of the focus of “t= o the cloud” with many leadership members/organization administrators, I figured it is a good question to ask here. If yes, what = has been your experience so far? Do you pass through the public internet or= perhaps use Amazon Direct Connect?

 

Thanks in advance for your input!

 

Walter Tienken

walter.tienken@asu.edu

UTO OPS Systems and Security

 

--_000_CY4PR06MB3016CCC69C8C12601130E88386570CY4PR06MB3016namp_-- From shane.warner@gmail.com Mon Feb 27 19:42:40 2017 From: shane.warner@gmail.com (Shane) Date: Mon, 27 Feb 2017 11:42:40 -0800 Subject: [OpenAFS] vos dumps to S3 via S3 Storage Gateway? In-Reply-To: References: Message-ID: --001a1134f9ac48394205498848f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have a legacy EC2 environment setup in which vos dumps are pulled in by Zmanda backup, using a custom tar wrapper. These are stored on s3 via Zmanda's virtual tape devices. We have a lifecycle setup to migrate the vos dumps to Glacier after some time. Looks like a feature was added to the AWS CLI that allows for dumping via a stream which looks interesting though: https://github.com/aws/aws-cli/pull/903 On Mon, Feb 27, 2017 at 10:50 AM, Walter Tienken wrote: > Hello all, > > > > We currently perform nightly dumps to an on-prem NFS mount. I was curious > if anyone has had any experience with using an Amazon S3 Storage Gateway > for similar purpose? With much of the focus of =E2=80=9Cto the cloud=E2= =80=9D with many > leadership members/organization administrators, I figured it is a good > question to ask here. If yes, what has been your experience so far? Do yo= u > pass through the public internet or perhaps use Amazon Direct Connect? > > > > Thanks in advance for your input! > > > > Walter Tienken > > walter.tienken@asu.edu > > UTO OPS Systems and Security > > > --001a1134f9ac48394205498848f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have a legacy EC2 environment setup in which vos dumps = are pulled in by Zmanda backup, using a custom tar wrapper. These are store= d on s3 via Zmanda's virtual tape devices. We have a lifecycle setup to= migrate the vos dumps to Glacier after some time.=C2=A0

Looks like a feature was added to the AWS CLI that allows for dumping via = a stream which looks interesting though:=C2=A0https://github.com/aws/aws-cli/pull/903

On Mon, Feb 27= , 2017 at 10:50 AM, Walter Tienken <Walter.Tienken@asu.edu> wrote:

Hello all,

=C2=A0

We currently perform nightly dumps to an on-prem NFS= mount. I was curious if anyone has had any experience with using an Amazon= S3 Storage Gateway for similar purpose? With much of the focus of =E2=80= =9Cto the cloud=E2=80=9D with many leadership members/organization administrators, I figured it is a good question to ask here. If yes, what = has been your experience so far? Do you pass through the public internet or= perhaps use Amazon Direct Connect?

=C2=A0

Thanks in advance for your input!

=C2=A0

Walter Tienken

walter.tienken@asu.edu

UTO OPS Systems and Security

=C2=A0


--001a1134f9ac48394205498848f8-- From jaltman@auristor.com Tue Feb 28 04:02:05 2017 From: jaltman@auristor.com (Jeffrey Altman) Date: Mon, 27 Feb 2017 23:02:05 -0500 Subject: [OpenAFS] vos dumps to S3 via S3 Storage Gateway? In-Reply-To: References: Message-ID: This is a cryptographically signed message in MIME format. --------------ms050708080705050008090004 Content-Type: multipart/mixed; boundary="------------0C2233827DBF75AB978E46DA" This is a multi-part message in MIME format. --------------0C2233827DBF75AB978E46DA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Few are aware that OpenAFS can be built to support IBM TSM as a virtual tape controller via the XBSA API. AWS S3 could be added in a similar manner. The primary thing that I would want to add whenever storing backups off-site is encryption. AFS3 volume dumps are unencrypted. I would pipe the dump stream through a block cipher before passing it into the AWS CLI. Jeffrey Altman On 2/27/2017 2:42 PM, Shane wrote: > We have a legacy EC2 environment setup in which vos dumps are pulled in= > by Zmanda backup, using a custom tar wrapper. These are stored on s3 vi= a > Zmanda's virtual tape devices. We have a lifecycle setup to migrate the= > vos dumps to Glacier after some time.=20 >=20 > Looks like a feature was added to the AWS CLI that allows for dumping > via a stream which looks interesting > though: https://github.com/aws/aws-cli/pull/903 >=20 > On Mon, Feb 27, 2017 at 10:50 AM, Walter Tienken > wrote: >=20 > Hello all,____ >=20 > __ __ >=20 > We currently perform nightly dumps to an on-prem NFS mount. I was > curious if anyone has had any experience with using an Amazon S3 > Storage Gateway for similar purpose? With much of the focus of =E2=80= =9Cto > the cloud=E2=80=9D with many leadership members/organization admini= strators, > I figured it is a good question to ask here. If yes, what has been > your experience so far? Do you pass through the public internet or > perhaps use Amazon Direct Connect?____ >=20 > __ __ >=20 > Thanks in advance for your input!____ >=20 > __ __ >=20 > Walter Tienken____ >=20 > walter.tienken@asu.edu ____ >=20 > UTO OPS Systems and Security____ >=20 > __ __ >=20 >=20 --------------0C2233827DBF75AB978E46DA Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------0C2233827DBF75AB978E46DA-- --------------ms050708080705050008090004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIMwggXqMIIE0qADAgECAhBAAVgjDHzXCy5hFo6GsQuLMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMTkzMFoXDTE3MTEwMjAzMTkzMFowgYYxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xMDAuBgoJkiaJk/IsZAEBEyA3RjAwMDAwMTAwMDAwMTU4MjMwQzdDQTcw MDAwMDdCMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtO/7veyX1tdA4aDvsO c0gS/fICCTPlhS34dpRNmZYs2mvWb/xGRCKeflva8uZLFqsCE6ybMgz2IaB9rpowRcGSr/R7 CyY6HEBl3Rw0OkkslV7HQTxgp1fBXbGGoS8gOp6/ML64d5UJsMUM6NM59SzC77v8bi0sYkaT q31SoiJrCcPiI0F2wZiESf1tguQONl3Emt9fhEokmlLRHAlv1DkRw2XeUOyUwVHIVgF1wnzR 4Ao86aYmym62Z669a6NPla3hqLmYk9w+ydTnzcWj0X6nhvaMxb7fhOUyj06Y5Mxhqye+dJg4 bPj/G+8OoNVY9l5h/qbJaWpSbDog4I0LxaUCAwEAAaOCAp0wggKZMA4GA1UdDwEB/wQEAwIF oDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8vY29tbWVyY2lhbC5vY3Nw LmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVz dC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAWgBSkc9rvaTWKdcygGXsI MvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEbBgtghkgBhvkvAAYLATCC AQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNh dGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCBrhqBq1RoaXMgVHJ1c3RJ RCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIApJZGVu VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3Nl Y3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBF BgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90 cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1Ud DgQWBBT6okll+NyYQTyBKCigoq5jFBzw3DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBABF9+YNU05P6tFiN8wvh52K+dgiUsQijFqN/tmwxqWHj 3TKxLwl8ZtK0F44FYcfeRXgE59bAxG8tZVRYBD7jY3qYEreri0x2DgJcA0oPfV1NHxM51t6h ST09jpXEcthB4FJu3xWg8O6pB7Oq9Q9kkTjHfVLLru9B3BxrY+1NKZaSkaTBb0JGw6kCN2MM rXrwPAdLlAWn5ywPRMqTIlgvhxtIQMv+dxpXhco9O5+ckMIdp1uBMJ82Hslfy3K9KCZvm6Cr BG8C/fBo5TefVGuxKyOwROvup2gx1/KZWoIO0hyMNGzFPrijNZD5fAlZ11FcAJ9Why+pd5FY mmJwln/BGPcwggaRMIIEeaADAgECAhEA+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsF ADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1 c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5 WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrU JWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5z giMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7A e5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4w TsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RH V7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9 MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBH BggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21t ZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYD VR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEF BQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhh cyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBD ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNv bS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5 aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv0 62MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+ vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a 7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8x LcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbS j1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRb JnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/ o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0Jfq UfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqx AXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcS SSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEWjoax C4swDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE3MDIyODA0MDIwNlowLwYJKoZIhvcNAQkEMSIEIKEznvBwYJqf3Ygwrj2G 6rUeYQwH+lxRPQFC7s8dvM87MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQ BgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABWCMMfNcLLmEW joaxC4swXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAVgjDHzXCy5hFo6GsQuLMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAWHTGulY6Yi5MnCj8qwU/ovT9sFHCWSfUL5/7lfzg4FP7JlIEcCnz pBMKFkLfvbMbKUzglb7RCC1WRJRA2qTkWS6bXeEfyKYGemDLkGhIqMlTGoVO4CgBNKVYxP4A DhEotc58cFsTrmADiUnvmtLiTsSzRcN3zJmmsX3PM1mMLLM4UrI0kFJnMwkq6+O7P/er4R9Y /7yvQpYNAVwLQt7oLN0KWm/x4dR1DYJZyw4WZw2h+Wm8AmR4IjWcDXveq4UyPT7DkiVtJbaO 5U2SJ1bYTkwjWv/NZrTuST6jbr0NKtGhGjXyqEZ1jFZn2bo/By/R2df08tFD8IsRg3YRzZg5 PgAAAAAAAA== --------------ms050708080705050008090004--