From andreas.ladanyi@kit.edu Thu Jun 18 13:43:14 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Thu, 18 Jun 2015 14:43:14 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install Message-ID: <5582BCE2.5080903@kit.edu> Hi, i cant see a make uninstall / remove target to uninstall OpenAFS after make install procedure. Is there a script or something other secret how the removing of installed files is possible ? iam using Centos 7 and openafs 1.6.11.1 from source tarball. Andy From m.richter@tu-berlin.de Fri Jun 19 11:58:48 2015 From: m.richter@tu-berlin.de (Richter, Michael) Date: Fri, 19 Jun 2015 10:58:48 +0000 Subject: [OpenAFS] OpenAFS still in development? Message-ID: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> --_000_5b5b0d891f8041ba902b35e35d532802EXMBX04tubitwintuberlin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I noticed that there were no new releases of OpenAFS for Windows since a lo= ng time. So I started some research and found a info on secureendpoints.com= telling "2014-10-04: OpenAFS for Windows Release 1.7.32 is now available." and "2015-02-25: OpenAFS client installers are now available fr= om Your File System Inc." On yfs I've found installers called "yfs-openafs-en_US-AMD64-1_7_3202.msi" = for exampe. Is it a special version or what is going on? I know that the OpenAFS main developer, J. Altman, is behind SecureEndpoint= s and Your-File-System.com. So I'm wondering - maybe I missed some announce= ment or so. Is OpenAFS development gone down for Auristor? Mit freundlichen Gr=FC=DFen Michael Richter -- 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_5b5b0d891f8041ba902b35e35d532802EXMBX04tubitwintuberlin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I noticed that there were no new releases of OpenAFS= for Windows since a long time. So I started some research and found a info= on secureendpoints.com telling

„2014-10-04: = ; OpenAFS for Windows Release 1.7.32 is now available.“

and

        &nbs= p;       „2015-02-25: OpenAFS client in= stallers are now available from Your File System Inc.“

 

On yfs I’ve found installers called „yfs= -openafs-en_US-AMD64-1_7_3202.msi“ for exampe. Is it a special versio= n or what is going on?

 

I know that the OpenAFS main developer, J. Altman, i= s behind SecureEndpoints and Your-File-System.com. So I’m wondering &= #8211; maybe I missed some announcement or so. Is OpenAFS development gone = down for Auristor?

 

Mit freundli= chen Gr=FC=DFen

Michael Rich= ter

 <= /o:p>

--

Michael Richter

 

Technische Universit=E4t Berl= in

Universit=E4tsbibliothek=

IT-Service<= /p>

 

Fasanenstra=DFe 88, 10623 Ber= lin

Telefon: +49 (0)30 314-76= 310

m.richter@tu-berlin.de

 

www.ub.tu-berlin.de

 

--_000_5b5b0d891f8041ba902b35e35d532802EXMBX04tubitwintuberlin_-- From jaltman@your-file-system.com Sat Jun 20 16:38:57 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sat, 20 Jun 2015 11:38:57 -0400 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> References: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> Message-ID: <55858911.4040207@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms000803080308010300020606 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael, First a correction. I am a developer who has contributed work to OpenAFS(R) that I have written and funded work that has been contributed by others. I continue to serve as a Gatekeeper for the OpenAFS project. However, I would not describe myself as "the OpenAFS main developer"; I am one among a dwindling number of active contributors. I am going to rephrase your questions as follows so I can answer them: 1. Is the OpenAFS project dead? 2. Why is Secure Endpoints(R) no longer distributing OpenAFS for Windows? 3. Why is Your File System(TM) distributing digitally signed installers for Microsoft Windows and OSX from its web site? 4. Is AuriStor(TM) a replacement for OpenAFS? 5. Has development of OpenAFS for Windows stopped? 1. Is the OpenAFS project dead? OpenAFS is an open source project that is supported by the community. Over the course of the last two years there has been a significant decrease in the rate of contributions but OpenAFS is still under development. https://www.openhub.net/p/openafs/commits/summary The second OpenAFS 1.6.12 pre-release candidate was released on 3 June and the release team is very eager to receive feedback from the community= =2E http://lists.openafs.org/pipermail/openafs-announce/2015/000484.html The next major stable series of OpenAFS, 1.8.x, continues to be developed. Code contributors and reviewers are welcome and activity can be observed at http://gerrit.openafs.org/ The next AFS and Kerberos Best Practices Workshop will be held in Pittsburgh PA USA the week of 17 August http://workshop.openafs.org/afsbpw15/ All are encouraged to attend. Especially those with families who are looking for some place to take a vacation. http://workshop.openafs.org/afsbpw15/family.php 2. Why is Secure Endpoints, Inc. no longer distributing OpenAFS for Windo= ws? Secure Endpoints, Inc. exited the OpenAFS support business at the end of 2014. Secure Endpoints, Inc. continues to sell commercial support for Heimdal Kerberos. Secure Endpoints is no longer listed as a support provider on the OpenAFS web site https://www.openafs.org/support.html 3. Why is Your File System, Inc. distributing digitally signed installers for Microsoft Windows and OSX from its web site? OpenAFS.org does not distribute an OSX Yosemite installer and the latest Mavericks installer is 1.6.6. For Windows the latest installation package is 1.7.31. It is also worth pointing out that OpenAFS.org is not distributing RHEL7 rpms but continues to do so for RHEL5 and RHEL6. At the European AFS and Kerberos Conference at CERN the Gatekeepers discussed the growing difficulties associated with providing packaging for OSX and Windows given the increasingly stringent requirements from OS vendors for digital signatures and more modern "store friendly" packaging formats. These requirements hit OpenAFS particularly hard because of the kernel modules (Windows drivers and OSX extensions). Kernel modules have access to everything on the system and OS vendors restrict who has the ability to sign them and what commitments vendors have to agree to in order to maintain that capability. There will be a talk at the upcoming Pittsburgh Workshop exclusively on this topic. In late March and April of this year I wrote to this mailing list about the requirements that have been put in place by Microsoft for the forthcoming Windows 10 and Server 2016 releases. To summarize, the requirements are: . 90 days after Windows 10 RTM all kernel drivers will have to be signed by Microsoft and not the software vendor. These signatures will use SHA-2 hashes that are incompatible with most older Windows platforms. . Microsoft will only sign drivers that are developed using VS2015 (VC19) tool chain. OpenAFS currently builds with VS2005 (VC14). . Each release must pass agreed to certification tests. There is no standard set of certification tests for file systems. Each vendor must negotiate with Microsoft for an applicable set of tests. . For Server 2016 all configuration and command line operation must be performed using PowerShell Cmdlets or WMI. This is required because by default Server 2016 will be headless and for the Nano option there will not even be a command prompt. As a result aklog.exe, bos.exe, cmdebug.exe, fs.exe, pts.exe, rxdebug.exe, symlink.exe, tokens.exe, udebug.exe, unlog.exe, vos.exe, etc must be replaced. Apple through its OSX developer program has long encouraged vendors to sign all binaries and command scripts. Starting with Mavericks, Apple mandated the use of a new packaging format that could also be digitally signed. An unsigned DMG package forces users to jump through hoops to install the product. With the release of Yosemite, Apple now requires that all kernel extensions be signed with an Apple issued certificate that is exclusively used for kernel extensions. Unsigned kernel extensions can only be loaded if the OS kernel signature checks are disabled using a boot argument. Disabling signature checks is not advised. For the OSX El Capitan release the OS will be locked down even further. Your File System, Inc. has all of the necessary contracts in place with Apple and Microsoft to sign binaries, kernel modules and installation packages. YFSI has also developed all of the necessary packaging for its AuriStor File System product line. As a service to its Commercial Support Customers and the broader end user community YFSI distributes OpenAFS using its AuriStor packaging and YFSI digital signatures. These installers, 1.6.11 for OSX and 1.7.3202 for Windows are available f= rom https://www.your-file-system.com/openafs/client-download and not from OpenAFS.org for two reasons: . The digital signatures include the your-file-system.com URL which matches the https://www.your-file-system.com/ TLS certificate. As a result the OS can mark the download as trusted providing that is permitted by local security policy. . By obtaining the downloads from https://www.your-file-system.com/ it is clear which legal entity is responsible for the distribution. The AuriStor packaging for Windows bundles the 32-bit and 64-bit components into one MSI and includes a private Heimdal assembly and command line tool suite. 4. Is AuriStor a replacement for OpenAFS? AuriStor is designed to be a general purpose, platform independent, secure, distributed file system that can be successfully deployed internally, across the Internet, and within public cloud services. AuriStor is an IBM AFS(R) and OpenAFS compatible file system that permits organizations to preserve the /afs file namespace while migrating to a faster, more scalable, highly secure cross-platform file system. https://www.your-file-system.com/openafs/migrate-to-auristor But, AuriStor is not free and OpenAFS satisfies the needs of organizations that desire a free solution and do not require: . the level of security and privacy provided by AuriStor . IPv6 and Microsoft Direct Access support . the ability to deploy dozens of DB servers within a cell . file servers that scale to the full capabilities of the hardware (all cores, multiple 10gbit NICs, etc) . larger name spaces (volumes, vnodes, protection ids, quotas, etc) . OS Vendor certification - Microsoft certification for Windows 10 and Server 2016 - Red Hat Enterprise Linux . and more To be very clear, AuriStor uses its own protocols and does not use proprietary extensions to the AFS3 protocol suites. OpenAFS can and will continue to add functionality over time. The choices the OpenAFS community makes are likely to be different from those that YFSI makes for AuriStor. 5. Has development of OpenAFS for Windows stopped? Development of OpenAFS on Windows has not stopped but it has slowed considerably. From 2007 to 2012 there was significant activity as a result of the conversion from the SMB Gateway implementation (<=3D 1.6.x)= to a native Windows IFS Redirector driver (>=3D 1.7.x). The AFS Redirector is stable across all of the Windows operating system releases.= YFSI continues to bring OpenAFS to the Microsoft IFS Plug Fests for testing. It has been many years since a significant issue was uncovered in the AFS Redirector. Although the AFS Redirector has uncovered many bugs in drivers from other vendors. Overall there has not been much to do that has been requested and funded by support customers. You can view the handful of changes that I'm working on at the moment at: http://gerrit.openafs.org/#q,status:open+project:openafs+branch:master+to= pic:windows-updates,n,z It is true that the AuriStor client is receiving much more attention. The AuriStor protocols support enhanced functionality that can take advantage of further integration with Windows including but not limited to IPv6, Direct Access, UNC Hardening, Server-to-Server Copy, Cache Bypass and on-demand token acquisition. That being said I do not see a viable path at the moment to an OpenAFS release for Windows 10 and Server 2016. There is simply too much work that must be completed to obtain certification. The AuriStor Windows client will be certified and it is compatible with IBM AFS and OpenAFS servers. One possibility is that YFSI will permit the AuriStor redirector to be packaged with the OpenAFS userland components. This would permit an OpenAFS package to be deployed on Windows 10 but not Server 2016. Whether there is demand for such an option from YFSI's commercial support customers is yet to be seen. I hope this response answers your questions. Jeffrey Altman On 6/19/2015 6:58 AM, Richter, Michael wrote: > Hi, >=20 > =20 >=20 > I noticed that there were no new releases of OpenAFS for Windows since = a > long time. So I started some research and found a info on > https://www.secure-endpoints.com telling >=20 > =E2=80=9E2014-10-04: OpenAFS for Windows Release 1.7.32 is now availab= le.=E2=80=9C >=20 > and >=20 > =E2=80=9E2015-02-25: OpenAFS client installers are now = available > from Your File System Inc.=E2=80=9C >=20 > =20 >=20 > On yfs I=E2=80=99ve found installers called > =E2=80=9Eyfs-openafs-en_US-AMD64-1_7_3202.msi=E2=80=9C for example. Is = it a special > version or what is going on? >=20 > =20 >=20 > I know that the OpenAFS main developer, J. Altman, is behind > SecureEndpoints and Your-File-System.com. So I=E2=80=99m wondering =E2=80= =93 maybe I > missed some announcement or so. Is OpenAFS development gone down for > Auristor? >=20 > =20 >=20 > Mit freundlichen Gr=C3=BC=C3=9Fen >=20 > Michael Richter >=20 > =20 >=20 > --=20 >=20 > Michael Richter >=20 > =20 >=20 > Technische Universit=C3=A4t Berlin >=20 > Universit=C3=A4tsbibliothek >=20 > IT-Service >=20 > =20 >=20 > Fasanenstra=C3=9Fe 88, 10623 Berlin >=20 > Telefon: +49 (0)30 314-76310 >=20 > m.richter@tu-berlin.de >=20 > =20 >=20 > www.ub.tu-berlin.de >=20 > =20 >=20 --------------ms000803080308010300020606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNjIwMTUzODU3WjAjBgkqhkiG9w0BCQQxFgQUB8HWYnIthgX2m8vLPeu8oNox CbcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBADsD831amEmEu2GXCKcTJI+TaK7msAFjTlsY4YH3PymV16uvgsGquDWobyDQah4h iRl3TNxALqFRxXiHM3gqjelZpSJHSaOQ9Fn0cxRzfiH9s88r9m6hTxCKa7oVG3f5GESdC62u 3TzNR760Bw9K6E4x58MPiT8eAkviSdeo5caLX/GUqhlhVocngDFTIiqfUod7juxWXGl6fzr0 eJ+WHYo+45cqO9JY8cS0S87Bn13kLF/c3bC9Wm2QSYRHVeBffb4TpjVav981qOw2KxYESRRx Zfudw/97n35jgufXwszEYwqxPZhMbkx0rV1bRW/cANKBP5fDPj/MBhb9CbU0yh4AAAAAAAA= --------------ms000803080308010300020606-- From kaduk@MIT.EDU Sun Jun 21 02:17:04 2015 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Sat, 20 Jun 2015 21:17:04 -0400 (EDT) Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: <5582BCE2.5080903@kit.edu> References: <5582BCE2.5080903@kit.edu> Message-ID: On Thu, 18 Jun 2015, Andreas Ladanyi wrote: > Hi, > > i cant see a make uninstall / remove target to uninstall OpenAFS after make > install procedure. Is there a script or something other secret how the > removing of installed files is possible ? There is no script or secret. You might get some help from touch /build-stamp; sleep 61; make install; find / -newer /build-stamp but that is easiest on an idle system and still prone to false positives. > iam using Centos 7 and openafs 1.6.11.1 from source tarball. In general when a packaged version of something is available, it should be preferred over a source build, since the packaging system tracks which files are installed by the package and should allow for cleaner uninstalls. http://openafs.org/dl/openafs/1.6.11.1/openafs-1.6.11.1-1.src.rpm is the 1.6.11 srpm, which ought to be buildable into binary rpms with, e.g., mock. -Ben Kaduk From haba@kth.se Sun Jun 21 09:55:38 2015 From: haba@kth.se (Harald Barth) Date: Sun, 21 Jun 2015 10:55:38 +0200 (CEST) Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <55858911.4040207@your-file-system.com> References: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> <55858911.4040207@your-file-system.com> Message-ID: <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> > 4. Is AuriStor a replacement for OpenAFS? > > AuriStor is designed to be a general purpose, platform independent, > secure, distributed file system that can be successfully deployed > internally, across the Internet, and within public cloud services. > AuriStor is an IBM AFS(R) and OpenAFS compatible file system that > (...) > . and more On https://www.your-file-system.com/openafs/auristor-comparison I have not found a list of supported platforms (client and server) comparison for OpenAFS and AuriStor. Because if it does not run on the platform, it's not a replacement. I have not found a price list of the products and what they contain. However, there is much "we are better" advertisement. That's not something that works well in all cultures. My conclusion of the current "landscape" is that if you have chosen a closed source operating system that you pay money for, in the future you'll have to pay money for a decent file system as well, either directly to the OS vendor or to a third party. That will in the future be necessary for any other function enhancement as well. That trend will continue and sooner or later include every app(lication) that you want to run on that platform. Harald. From jaltman@your-file-system.com Sun Jun 21 17:38:12 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sun, 21 Jun 2015 12:38:12 -0400 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> References: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> Message-ID: <5586E874.2090606@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms090004050607080208010601 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Harald, I do not believe that the OpenAFS mailing lists are an appropriate forum to discuss AuriStor. My response to Michael provided details on AuriStor because I felt it was necessary in order to properly answer the implied questions. I encourage anyone that has questions about AuriStor to send them to contact us via https://www.your-file-system.com/openafs/contact On 6/21/2015 4:55 AM, Harald Barth wrote: >=20 >> 4. Is AuriStor a replacement for OpenAFS? >> >> AuriStor is designed to be a general purpose, platform independent, >> secure, distributed file system that can be successfully deployed >> internally, across the Internet, and within public cloud services. >> AuriStor is an IBM AFS(R) and OpenAFS compatible file system that >> (...) >> . and more >=20 > On=20 >=20 > https://www.your-file-system.com/openafs/auristor-comparison >=20 > I have not found a list of supported platforms (client and server) > comparison for OpenAFS and AuriStor. Because if it does not > run on the platform, it's not a replacement.=20 The question of "supported platforms" is an interesting one because it is very unclear what it means for OpenAFS to "support" a platform. What are the criteria? Is it sufficient to say that if you can build OpenAFS on the OS and hardware architecture that it is "supported"? Or are there other requirements such as * there must be packaging available for the platform * there must be binaries distributed . from openafs.org . from the OS distribution . from a third party (including commercial support vendors) * there must be an extensive test suite that is passed * for OS vendors that require digital signatures there must be a signed distribution be present * technical support must be available I am quite sure there are other criteria that could be added to the mix. At the AFS and Kerberos Best Practice Workshops and the European AFS Conferences the Gatekeepers have often included a list of OSes as part of the OpenAFS Status Report. Inclusion in the list has in general meant that the referenced stable branch of OpenAFS builds on the listed major version of the OS. Inclusion of an OS in the list has not implied much more than that because OpenAFS does not have an extensive test suite to run and because binaries have not always been consistently available. For AuriStor to be "supported" requires the availability of tested, signed (where applicable) and certified (where applicable) binaries. The current list of OS families that YFSI is committed to supporting includes * Linux . Red Hat Enterprise Linux (YFSI is a Red Hat Technology Partner) . Fedora . Debian . Ubuntu * Microsoft Windows * Apple OSX and iOS * Oracle Solaris * IBM AIX * Android Servers are supported everywhere but on Windows, iOS and Android but the performance varies significantly based upon the OS release, processor architecture, and underlying hardware so there are combinations that we recommend and those we do not. The failure to list an OS family or Linux distribution does not imply that YFSI will not support AuriStor on that platform. It only implies that there has been insufficient customer interest to this point for YFSI to expend the necessary resources on development, testing and certification (where applicable.) > I have not found a price list of the products and what they contain. You are correct. YFSI performed a survey of various Enterprise class software product web sites and found that very few included a price schedule. Please contact us. > However, there is much "we are better" advertisement. That's not > something that works well in all cultures. If you have suggestions on what should be included on the web site we are interested in hearing them. Please contact us off the OpenAFS mailing lists. > My conclusion of the current "landscape" is that if you have chosen a > closed source operating system that you pay money for, in the future > you'll have to pay money for a decent file system as well, either > directly to the OS vendor or to a third party. That will in the future > be necessary for any other function enhancement as well. That trend > will continue and sooner or later include every app(lication) that you > want to run on that platform. It is certainly possible to view the landscape as FOSS platforms are better because you do not have to pay money and because there are fewer requirements in place that are intended to enforce quality. I have spoken with many Microsoft Program Managers and Developers. Their reasons for enforcing the new digital signing and certification requirements are reasonable given their goals. They are tired of end user systems being exploited or made unstable because of third party products that integrate with the OS with full trust and which are not sufficiently designed against attack or with quality and privacy in mind. Microsoft is committed to providing their enterprise customers with trusted platforms whether those are hosted on physical machines owned by the enterprise or whether they are virtual machines hosted on HyperV or Azure. Microsoft's staff believes they have no choice but to impose new requirements because of the actions of various government entities from multiple countries and the persistent attacks from crime related organizations. Microsoft has finally followed Apple's lead by defining an application model that permits applications to be distributed, installed, upgraded, and removed without altering the underlying OS footprint. In the long run this is going to be a big win for consumers because of the increased stability it will bring. However, it is also true that this new model of software development and deployment is going to be very expensive to transition to because there are many assumptions embedded in existing Windows software that are no longer true when a well-defined and enforced application model is imposed. For Apple the goal is to sell consumer products that are as easy to use and maintain as a toaster. That goal is supported by improving the security footprint of the OS. Doing so requires limiting the ability to install arbitrary kernel extensions to trusted parties. As for the argument that FOSS operating systems are better because you do not have to pay money for them. I do not buy into that argument. Quality software is developed by talented humans that require housing, food, and health care, that raise families, and that deserve the opportunity to learn, vacation and retire. If you want quality software you need people, and paying people requires money. I have yet to find a money tree nor has a leprechaun offered me a pot of gold. The cost of developing OpenAFS or AuriStor is no different for a FOSS operating system such as Linux or a closed source file system such as Oracle Solaris. In many regards the FOSS platform has proven to be more expensive to develop for because of the lack of stable ABIs and the large degree of variability between distributions. In the end, if you need a quality file system it is going to cost someone something. Either upfront as grants, or on the back-end through the sales of license fees, services, acceptance of advertising and/or loss of privacy. Or it will come out of the quality of life of the developers. We have all seen what our friends that spent 15 years sacrificing to support OpenSSL have gone through. My life experience has taught me that it is unfair to expect people to work for free or to work at a discount simply because a cause is worthy. It is fair for someone to volunteer to do something for free because they want to but the moment that the same person is asked to do it they should be paid for their time and expertise. Recently the Freakonomics podcast had a relevant piece titled "Should We Really Behave Like Economists Say We Do?" http://freakonomics.com/2015/06/04/should-we-really-behave-like-economist= s-say-we-do-a-new-freakonomics-radio-podcast/ Its the story of Homo Economicus, https://en.wikipedia.org/wiki/Homo_economicus a human being that is a rational and self-interested actor that always chooses the most optimal path through life. The podcast analyzes in a funny manner how Home Economicus would live life whether it be selecting a mate, or choosing entertainment, or supporting public activities and works such as voting or the arts. I bring up this podcast because in many regards the funding or lack of funding of FOSS is the process of rational and self-interested actions at work. A rational organization is not going to pay money for something that is freely available nor are they going to fund developers to build something that others will get to use for free. That is the challenge for OpenAFS. The challenge for AuriStor is that because a large sum of money was invested in its development those funds must be recouped from those organizations that will benefit from its use. In the end software development has to be a partnership between those that build and those that deploy. If those that deploy do not fund those that build there will not be sufficient development hours and talent to build the solutions those that deploy require. The choice between FOSS, commercial open source for customers and commercial closed source is a business model. The choice of business model is often dictated by economic circumstances and the economic landscape. Up until Feb 2012 YFSI gave everything it developed to OpenAFS. I stopped doing so for much the same reason that Oracle restricted access to Solaris source code. Distributing source code before the product ships and begins to generate revenues undermines the ability to fund the R&D that produces the software in the first place. My goal is to develop software that enables our end users to deploy applications and distribute information both within and without their private networks using a common file namespace for all networked devices and best of breed network security. One of the strengths of /afs is that it has already survived three decades. I want it to continue to exist a century from now. Please direct all future questions about AuriStor to Your File System Inc= =2E Please join the OpenAFS Foundation Discuss mailing list to discuss funding models for OpenAFS http://lists.openafs.org/mailman/listinfo/foundation-discuss Jeffrey Altman P.S. My apologies for the long reply. --------------ms090004050607080208010601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNjIxMTYzODEyWjAjBgkqhkiG9w0BCQQxFgQUQ896zd94JyBXxkYD8xGwlxBi TYYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAEpkfm2WDDOIN7HWtduWjBQHvzVzplG0T+22PUdtW6ifaL3G40S1bTnJPTYEPgQO 4ACRxhYanN6bqfB64oenQz2OQBX4sMs8eCkLC9XDuW+wEFUmH5gedkOUDv7aliAuuhl3UAG+ VrtVAUEaAzc7l1wjtIfzqMjXuPHUzipxKpsDncdFeMrAfmt90CxskB7VNFgX9etjE43MEK8U dBvvCsJ/ArPSTA+oUIa6tgpcn/Wy8dzhSkYgaaxrfuwfXcncJEymfCs6RKJd49Uy24CN6BKb JcqVhzE0Q0cZWCUAIK+9Q/gNBdkXE8c7uOPwVvnzgri0qCnzdbCRISIlCuMrDxwAAAAAAAA= --------------ms090004050607080208010601-- From tcreedon@easystreet.net Sun Jun 21 18:04:35 2015 From: tcreedon@easystreet.net (Ted Creedon) Date: Sun, 21 Jun 2015 10:04:35 -0700 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> References: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> Message-ID: --001a11381322d02daa05190a2686 Content-Type: text/plain; charset=UTF-8 It might be best to run older OS's like XP and Yosemite as virtual machines under Linux, and rely on older but functional AFS versions. That's what i'm doing. If there is a business case for additional functions then Win 10, etc with all its add on costs must be paid for. Sad to say but maintenance of AFS/YFS requires effort/money and Apple & Microsoft are busy locking up their OS's because they won't compete with Linux et al. Just like ATT did with Unix . (Remember the $1,500 per box license fee from ATT&Berkley for SVR5 R4?). That gave MS the entry point for DOS. One has to ask why the need for fancy features when an 8K Data General NOVA 1200 was perfectly adequate for the majority of small business needs. Answer: Unless one needs encryption & security, which makes the case for the biggest & best. Then software complexity becomes an issue. There's just too darn much code to maintain. My observation is when written code gets to a certain size the number of monthly critical bugs remains constant. Hence the need for "approved" drivers, Istores, etc. Which won't change the constant number of bugs! Tedc On Sun, Jun 21, 2015 at 1:55 AM, Harald Barth wrote: > > > 4. Is AuriStor a replacement for OpenAFS? > > > > AuriStor is designed to be a general purpose, platform independent, > > secure, distributed file system that can be successfully deployed > > internally, across the Internet, and within public cloud services. > > AuriStor is an IBM AFS(R) and OpenAFS compatible file system that > > (...) > > . and more > > On > > https://www.your-file-system.com/openafs/auristor-comparison > > I have not found a list of supported platforms (client and server) > comparison for OpenAFS and AuriStor. Because if it does not > run on the platform, it's not a replacement. > > I have not found a price list of the products and what they contain. > > However, there is much "we are better" advertisement. That's not > something that works well in all cultures. > > My conclusion of the current "landscape" is that if you have chosen a > closed source operating system that you pay money for, in the future > you'll have to pay money for a decent file system as well, either > directly to the OS vendor or to a third party. That will in the future > be necessary for any other function enhancement as well. That trend > will continue and sooner or later include every app(lication) that you > want to run on that platform. > > Harald. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --001a11381322d02daa05190a2686 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It might be best to run= older OS's like XP and Yosemite as virtual machines under Linux, and r= ely on older but functional AFS versions. That's what i'm doing.
If there is a business case for additional functions then Win 10= , etc with all its add on costs must be paid for.=C2=A0

Sad t= o say but maintenance of AFS/YFS requires effort/money and Apple & Micr= osoft are busy locking up their OS's because they won't compete wit= h Linux et al.

Just like ATT did with Unix .=C2=A0 (Remember t= he $1,500 per box=C2=A0 license fee from ATT&Berkley for SVR5 R4?). Tha= t gave MS the entry point for DOS.

One has to ask why the need= for fancy features when an 8K Data General NOVA 1200 was perfectly adequat= e for the majority of small business needs.

Answer: Unless one= needs encryption & security, which makes the case for the biggest &= ; best. Then software complexity becomes an issue.

There'= s just too darn much code to maintain.=C2=A0 My observation is when written= code gets to a certain size the number of monthly critical bugs remains co= nstant. Hence the need for "approved" drivers, Istores, etc.
=
Which won't change the constant number of bugs!

Tedc



On Sun, Jun 21, 2015 at 1:55 AM,= Harald Barth <haba@kth.se> wrote:

> 4. Is AuriStor a replacement for OpenAFS?
>
> AuriStor is designed to be a general purpose, platform independent, > secure, distributed file system that can be successfully deployed
> internally, across the Internet, and within public cloud services.
> AuriStor is an IBM AFS(R) and OpenAFS compatible file system that
> (...)
>=C2=A0 . and more

On

https://www.your-file-system.com/openafs= /auristor-comparison

I have not found a list of supported platforms (client and server)
comparison for OpenAFS and AuriStor. Because if it does not
run on the platform, it's not a replacement.

I have not found a price list of the products and what they contain.

However, there is much "we are better" advertisement. That's = not
something that works well in all cultures.

My conclusion of the current "landscape" is that if you have chos= en a
closed source operating system that you pay money for, in the future
you'll have to pay money for a decent file system as well, either
directly to the OS vendor or to a third party. That will in the future
be necessary for any other function enhancement as well. That trend
will continue and sooner or later include every app(lication) that you
want to run on that platform.

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

--001a11381322d02daa05190a2686-- From tcreedon@easystreet.net Sun Jun 21 18:56:20 2015 From: tcreedon@easystreet.net (Ted Creedon) Date: Sun, 21 Jun 2015 10:56:20 -0700 Subject: [OpenAFS] Criteria for platform support Message-ID: --047d7b5d519eeaedb505190adf6d Content-Type: text/plain; charset=UTF-8 My observation is that a platform is supported when the software operates in conformance with the: Use's manual Users Reference Manual System Administrator's Manual System Administrator's Reference Manual And interfaces that use published C++ header files that compile & link Otherwise the 1:10:100 ratio applies. (1 to fix in design, 10 in coding, 100 after release) The IBM docs hash all this together. Tedc --047d7b5d519eeaedb505190adf6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My observation is that = a platform is supported when the software operates in conformance with the:=

Use's manual
Users Reference Manual
Sys= tem Administrator's Manual
System Administrator's Reference Manu= al

And interfaces that use published C++ header files that com= pile & link

Otherwise the 1:10:100 ratio applies. (1 to fi= x in design, 10 in coding, 100 after release)

The IBM docs has= h all this together.

Tedc


--047d7b5d519eeaedb505190adf6d-- From shadow@gmail.com Mon Jun 22 00:31:02 2015 From: shadow@gmail.com (Daria Brashear) Date: Sun, 21 Jun 2015 19:31:02 -0400 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: References: <5b5b0d891f8041ba902b35e35d532802@EX-MBX04.tubit.win.tu-berlin.de> <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> Message-ID: --001a11c30f9ee216d305190f8c8b Content-Type: text/plain; charset=UTF-8 On Sunday, June 21, 2015, Ted Creedon wrote: > It might be best to run older OS's like XP and Yosemite as virtual > machines under Linux, and rely on older but functional AFS versions. That's > what i'm doing. > > If there is a business case for additional functions then Win 10, etc with > all its add on costs must be paid for. > > Sad to say but maintenance of AFS/YFS requires effort/money and Apple & > Microsoft are busy locking up their OS's because they won't compete with > Linux et al. > > Just like ATT did with Unix . (Remember the $1,500 per box license fee > from ATT&Berkley for SVR5 R4?). That gave MS the entry point for DOS. > > One has to ask why the need for fancy features when an 8K Data General > NOVA 1200 was perfectly adequate for the majority of small business needs. > > Answer: Unless one needs encryption & security, which makes the case for > the biggest & best. Then software complexity becomes an issue. > > There's just too darn much code to maintain. My observation is when > written code gets to a certain size the number of monthly critical bugs > remains constant. Hence the need for "approved" drivers, Istores, etc. > > Which won't change the constant number of bugs! > > Tedc > Far from locking up, I've found that Apple has been good, if not perfect, about providing and publishing stable, usable interfaces. Usable includes the legal right to do so. In that regard, Linux, rather than Windows and MacOS, is the platform continually locking up more functionality. Daria -- D --001a11c30f9ee216d305190f8c8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, June 21, 2015, Ted Creedon <tcreedon@easystreet.net> wrote:
It migh= t be best to run older OS's like XP and Yosemite as virtual machines un= der Linux, and rely on older but functional AFS versions. That's what i= 'm doing.

If there is a business case for additional funct= ions then Win 10, etc with all its add on costs must be paid for.=C2=A0
Sad to say but maintenance of AFS/YFS requires effort/money and = Apple & Microsoft are busy locking up their OS's because they won&#= 39;t compete with Linux et al.

Just like ATT did with Unix .= =C2=A0 (Remember the $1,500 per box=C2=A0 license fee from ATT&Berkley = for SVR5 R4?). That gave MS the entry point for DOS.

One has t= o ask why the need for fancy features when an 8K Data General NOVA 1200 was= perfectly adequate for the majority of small business needs.

= Answer: Unless one needs encryption & security, which makes the case fo= r the biggest & best. Then software complexity becomes an issue.
There's just too darn much code to maintain.=C2=A0 My observati= on is when written code gets to a certain size the number of monthly critic= al bugs remains constant. Hence the need for "approved" drivers, = Istores, etc.

Which won't change the constant number of bugs!
Tedc

Far from locking up,= I've found that Apple has been good, if not perfect, about providing a= nd publishing stable, usable interfaces. Usable includes the legal right to= do so. In that regard, Linux, rather than Windows and MacOS, is the platfo= rm continually locking up more functionality.

Dari= a


--
D

--001a11c30f9ee216d305190f8c8b-- From haba@kth.se Mon Jun 22 05:02:09 2015 From: haba@kth.se (Harald Barth) Date: Mon, 22 Jun 2015 06:02:09 +0200 (CEST) Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <5586E874.2090606@your-file-system.com> References: <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> <5586E874.2090606@your-file-system.com> Message-ID: <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> > I do not believe that the OpenAFS mailing lists are an appropriate forum > to discuss AuriStor. My response to Michael provided details on > AuriStor because I felt it was necessary in order to properly answer the > implied questions. What I've learned so far from AuriStor it looks like it could be a replacement for OpenAFS on the platforms it's available. And it can more as Jeff tells us. If that strategy is good advertising depends on "cultural background". > The question of "supported platforms" is an interesting one because it > is very unclear what it means for OpenAFS to "support" a platform. What > are the criteria? Is it sufficient to say that if you can build OpenAFS > on the OS and hardware architecture that it is "supported"? Sorry, "supported" was probably a bad choice of word. But I don't know if "availabe" or "runable" or "it builds it ships" would be better. > I am quite sure there are other criteria that could be added to the mix. I know that you take "supported" very seriously. I would be happy if other software vendors (which are not into file systems) would do that as well. > * Linux > . Red Hat Enterprise Linux > (YFSI is a Red Hat Technology Partner) > . Fedora > . Debian > . Ubuntu > * Microsoft Windows > * Apple OSX and iOS > * Oracle Solaris > * IBM AIX > * Android > > Servers are supported everywhere but on Windows, iOS and Android but the > performance varies significantly based upon the OS release, processor > architecture, and underlying hardware so there are combinations that we > recommend and those we do not. > > The failure to list an OS family or Linux distribution does not imply > that YFSI will not support AuriStor on that platform. It only implies > that there has been insufficient customer interest to this point for > YFSI to expend the necessary resources on development, testing and > certification (where applicable.) Thanks for the list. I guess on "the main HW" which is amd64 for most of the OSes above. Both at work and privately I run OpenAFS on platforms that are not on the list and even in the future will not have much "customer interest". > In the end software development has to be a partnership between those > that build and those that deploy. If those that deploy do not fund > those that build there will not be sufficient development hours and > talent to build the solutions those that deploy require. I see that this partnership has stopped working in many places. It makes me sad. > P.S. My apologies for the long reply. You don't need to apologise. Harald. From andreas.ladanyi@kit.edu Mon Jun 22 08:40:20 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Mon, 22 Jun 2015 09:40:20 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: References: <5582BCE2.5080903@kit.edu> Message-ID: <5587BBE4.9090705@kit.edu> This is a cryptographically signed message in MIME format. --------------ms000509010908000103010609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ben, >> iam using Centos 7 and openafs 1.6.11.1 from source tarball. > In general when a packaged version of something is available, it should= > be preferred over a source build, since the packaging system tracks whi= ch > files are installed by the package and should allow for cleaner > uninstalls. > > http://openafs.org/dl/openafs/1.6.11.1/openafs-1.6.11.1-1.src.rpm is th= e > 1.6.11 srpm, which ought to be buildable into binary rpms with, e.g., > mock. I used this now, but an yum-builddep of this srpm package tells me that the package: kernel-devel-x86_64 =3D 2.6.18-404.el5 is needed but not found on centos 7. centos 7 ist working with 3.10. I found out that centos 5 is working with kernel 2.6.18. But its interesting to see that for RHEL 7 there are packages on the openafs webseite for release 1.6.8. > > -Ben Kaduk regards, Andy --------------ms000509010908000103010609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP+jCC BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9 YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs 6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2 LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23 NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF hTCCBG2gAwIBAgIHGG3Jfo2QSjANBgkqhkiG9w0BAQsFADCBvzELMAkGA1UEBhMCREUxGzAZ BgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQK EyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVj aCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkB FgpjYUBraXQuZWR1MB4XDTE0MTAyNzEzNDMxMFoXDTE3MTAyNjEzNDMxMFowUzELMAkGA1UE BhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEYMBYG A1UEAxMPQW5kcmVhcyBMYWRhbnlpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tL0UuEE0MQWYP5MZOt+SBBDmGHZDf99xUzsFwyxvBaoS3TBZC/hul8ylNsOTrOvNbdJFOPTB izqfYQGf+JIxAgPomyG4jomQvMXhKXcf/obhf5lj2eBN0np/wLktMvFvj+HIEBh38/1o3ZXE SV4aMhvNW9VO116K0fh3/7TElksZ95zNj77js/JoEMQB8mGw27hw5u8VOKrDEWuzTBu4M7Vg MdzNrYi+m3AiYv1m110i6rJ4otbThGRfcEbDHwqfONfminidzyS4aHpNyO7U98xmn360m8qs q3smEn7XRGRgVlpzu7lNuJ8AvKZGPrM4OJ1Rhgxo5enuS1XVw29IBwIDAQABo4IB7zCCAesw QAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwIwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsG AQQBga0hgiwBAQQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRSBxcWWTqn7d35eE0sUlWSXfPOizAfBgNVHSMEGDAW gBQfdGX0mh169jHp32EbcysNbdAzSTAiBgNVHREEGzAZgRdhbmRyZWFzLmxhZGFueWlAa2l0 LmVkdTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2Ev cHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYB BQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDANBgkqhkiG9w0BAQsFAAOCAQEALmsJ+qKYuD1TTYxYAYcOUc7Pw3SBI+PX941ze1n2 coAeuXY2Ldd2lrjyirS8eHuPCZihmbVlMe/26WqBwDLN/vk7FC5c0aatidQz6MoquWJWnHSj 1XlB/AOv9aD4tKLHURw7ejFvY3imott/vrLJrt2WjYvPaMvwAoZKgTY2bXEZQjWYnGJRthuK 1OG4CFJlQphREiewuqzjCxABnC3Rmo7BWy/yGeMGSkMsTg+uhOwv8568KtJE3z4uTWtN1w0d T1uI1/uJ5jrsyoodUg/q31lGGgtrmElCwrHJSk+6Hp6KCXilzY9d/N/CQXkHnNLu6aDgc8gX n9Y/cLepRKKZvzCCBZQwggR8oAMCAQICBxev928jIukwDQYJKoZIhvcNAQELBQAwWjELMAkG A1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA4MzFaFw0xOTA3 MDkyMzU5MDBaMIG/MQswCQYDVQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJn MRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2Yg VGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5idWNoIENlbnRyZSBmb3IgQ29tcHV0aW5nMQ8w DQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEWCmNhQGtpdC5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDMsqiKiaKAQVEpL20dPB0IejTRPrajRK7mwwXpqBo/APNN 8IPtcb16pITtb5wQAaeVPvu8YA+bi5U3Dm/xeFBayQQcvUAp04cwm/nqhvveCMOpvC41qgiq K/ZSsDQlIre78zQDgndK9IjQmFdv8XCvLR0h8N5hl4L8H2NBfY9eJ1BIPZ3eZD6tAMPYkBw7 mJzs9wPDVU6V6Uws4kEwmSUGBEw7Avp8p0DdrLwJgFd1dRyUXvwA+oncv+hzdBLQCDj5RNac deDRUuEmalJPxeLw/KcUs/2FMGwhiuCB9+1fW3G0JgPDTTSgbRS6l9faL7kJ99pUcElvws9x 4/s0kT9zAgMBAAGjggH3MIIB8zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIB BjARBgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFB90ZfSaHXr2MenfYRtzKw1t0DNJMB8G A1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCmNhQGtpdC5lZHUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggr BgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNl cnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9i YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBADoW Jv/UVyB9nfsoym9xKp8a7sOLa4XSPU/xrKF4Dp3UdlKdzDK2JvzCziF50SiH54ZuKbsKUa6Y XwHiWHO7tsUW2+r6cnbf6FGcvylyeOtetQsoKvB2bMhEG0fn1B4+9k5IuXJpcQSHiKZhRa/l qNWO95hKHvhtUO8dlTYtlTaSEmv6RAcfw2JcYKiB2GC97h3YpwimDC15sfzwYdnhTdSXF54C VPgwHPL85cR/YI7KlQtjvI6yz14mma7ffYN6W7UBDPPc/5emiYIgxbwEBFZ5orfkvPtfeJUu T3FI7RBmE8mPl/betefdZzqF1F357emrpuGH9gZbJp98SgruQqgxggSCMIIEfgIBATCByzCB vzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJ S2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kx JzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lU LUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMAkGBSsOAwIaBQCgggKL MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyMjA3NDAy MFowIwYJKoZIhvcNAQkEMRYEFCDUMfLsOgCKo3vPBFm/+3KkQ29hMGwGCSqGSIb3DQEJDzFf MF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdwGCSsGAQQBgjcQ BDGBzjCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzES MBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRl Y2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0G A1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMIHeBgsq hkiG9w0BCRACCzGBzqCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0 dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1 dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+ jZBKMA0GCSqGSIb3DQEBAQUABIIBAJ9gi/UmICR5by6gzeIIReOFUwTNHi/C0N3e+BU+Ecl/ S2T4iJ103C1CVh30Cfqq18G6jyCiKdJCRjelpCxOw27ZvR51Vc5vZthP4Ktmgx5TnmEKc5e7 5+vExi3Z4uHoTsYLJqCUeI2c7dkNRTYD1GxoEwfANV/sdvRDn4E4+asUz5Egb+btbRtTgoX3 z6Yd+aHvQn+6p5DxfA+TzJdpy9U2d81Ag6M3zhOH7pgFNIbPFE2P27s3gi2BcJVEBzCWsXNn UXjuKppbDvZhALS1K0mp6YkANBiOnNqv2IOai8Id4/vJWdTHTQhk0NcD9arO+Q6ZzrVWeiGu vlMCRKW27u0AAAAAAAA= --------------ms000509010908000103010609-- From stephan.wiesand@desy.de Mon Jun 22 12:41:26 2015 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Mon, 22 Jun 2015 13:41:26 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: <5587BBE4.9090705@kit.edu> References: <5582BCE2.5080903@kit.edu> <5587BBE4.9090705@kit.edu> Message-ID: <3F611F2E-DB53-40E9-85C1-30FA9DC9DEBD@desy.de> > On 22 Jun 2015, at 09:40, Andreas Ladanyi = wrote: >=20 >>> iam using Centos 7 and openafs 1.6.11.1 from source tarball. >> In general when a packaged version of something is available, it = should >> be preferred over a source build, since the packaging system tracks = which >> files are installed by the package and should allow for cleaner >> uninstalls. >>=20 >> http://openafs.org/dl/openafs/1.6.11.1/openafs-1.6.11.1-1.src.rpm is = the >> 1.6.11 srpm, which ought to be buildable into binary rpms with, e.g., >> mock. > I used this now, but an yum-builddep of this srpm package tells me = that > the package: >=20 > kernel-devel-x86_64 =3D 2.6.18-404.el5 is needed but not found on = centos > 7. centos 7 ist working with 3.10. yum-builddep is looking at the wrong info when used on srpms. Install or = unpack the srpm and run "yum-builddep openafs.spec" instead. > I found out that centos 5 is working with kernel 2.6.18. Indeed, the srpm was built on en EL5 system. > But its > interesting to see that for RHEL 7 there are packages on the openafs > webseite for release 1.6.8. That's by accident only. It was decided that packaging OpenAFS has to = happen "downstream" and thus the project should not provide Linux = packages for new major OpenAFS releases (1.8+) or new major distribution = releases (F21+, EL7+).=20 That decision should probably be revisited since the anticipated = downstream packaging for EL7 hasn't happened (AFAIK) and the once = existing packaging for Fedora seems not to have made it past the early = days of F20. Binary packages for those distributions are still being built and can be = found in /afs/inf.ed.ac.uk/group/afsbuild , they're just no longer = uploaded. Which seems kind of silly, given the lack of alternatives. Best, Stephan From stephan.wiesand@desy.de Mon Jun 22 14:35:00 2015 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Mon, 22 Jun 2015 15:35:00 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> References: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> Message-ID: > On 22 Jun 2015, at 15:15, ladanyi@ira.uka.de wrote: >=20 >>> I used this now, but an yum-builddep of this srpm package tells me = that >>> the package: kernel-devel-x86_64 =3D 2.6.18-404.el5 is needed but = not >>> found on centos 7. centos 7 ist working with 3.10. >>=20 >> yum-builddep is looking at the wrong info when used on srpms. Install = or >> unpack the srpm and run "yum-builddep openafs.spec" instead. >=20 > On Centos 7: > yum-builddep openafs.spec works. > rpmbuild -ba openafs.spec exits with 0. I got my rpm packages. >=20 > On Fedora 20: > I add a yum repository file which points to the 1.6.10 rpm Fedora 20 = packages at openafs.org >=20 > yum install produce the following output with some errors and bad = exit: 1.6.10 is too old for that kernel, you need at least 1.6.11. NB F20 is = EOL. Best, Stephan > Running transaction > Installing : openafs-1.6.10-2.fc20.x86_64 = = 1/5 > Installing : openafs-client-1.6.10-2.fc20.x86_64 = = 2/5 > Installing : dkms-openafs-1.6.10-2.fc20.x86_64 = = 3/5 > Error! DKMS tree already contains: openafs-1.6.10-2.fc20 > You cannot add the same module/version combo more than once. >=20 > Kernel preparation unnecessary for this kernel. Skipping... >=20 > Building module: > cleaning build area...(bad exit status: 2) > ./configure = --with-linux-kernel-headers=3D/lib/modules/3.19.8-100.fc20.x86_64/build = --with-linux-kernel-packaging && make && case 3.19.8-100.fc20.x86_64 in = 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv = src/libafs/MODLOAD-*/openafs.ko . ;; = esac....................................................(bad exit = status: 2) > Error! Bad return status for module build on kernel: = 3.19.8-100.fc20.x86_64 (x86_64) > Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more = information. >=20 > Kernel preparation unnecessary for this kernel. Skipping... >=20 > Building module: > cleaning build area...(bad exit status: 2) > ./configure = --with-linux-kernel-headers=3D/lib/modules/3.19.8-100.fc20.x86_64/build = --with-linux-kernel-packaging && make && case 3.19.8-100.fc20.x86_64 in = 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv = src/libafs/MODLOAD-*/openafs.ko . ;; = esac.....................................................(bad exit = status: 2) > Error! Bad return status for module build on kernel: = 3.19.8-100.fc20.x86_64 (x86_64) > Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more = information. > warning: %post(dkms-openafs-1.6.10-2.fc20.x86_64) scriptlet failed, = exit status 10 > Non-fatal POSTIN scriptlet failure in rpm package = dkms-openafs-1.6.10-2.fc20.x86_64 > Installing : openafs-docs-1.6.10-2.fc20.x86_64 = = 4/5 > Installing : openafs-krb5-1.6.10-2.fc20.x86_64 = = 5/5 > Verifying : openafs-docs-1.6.10-2.fc20.x86_64 = = 1/5 > Verifying : dkms-openafs-1.6.10-2.fc20.x86_64 = = 2/5 > Verifying : openafs-krb5-1.6.10-2.fc20.x86_64 = = 3/5 > Verifying : openafs-client-1.6.10-2.fc20.x86_64 = = 4/5 > Verifying : openafs-1.6.10-2.fc20.x86_64 = = 5/5 >=20 > Installed: > dkms-openafs.x86_64 0:1.6.10-2.fc20 openafs.x86_64 0:1.6.10-2.fc20 = openafs-client.x86_64 0:1.6.10-2.fc20 openafs-docs.x86_64 = 0:1.6.10-2.fc20 openafs-krb5.x86_64 0:1.6.10-2.fc20 >=20 > Complete! >=20 >=20 >=20 > The Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for = more information: >=20 > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_cbqueue.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_cell.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_chunk.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_conn.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.o > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c: In function =E2=80=98afs_CheckRootVolume=E2=80= =99: > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:403:24: error: =E2=80=98struct dentry=E2=80=99 = has no member named =E2=80=98d_alias=E2=80=99 > list_del_init(&dp->d_alias); > ^ > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:404:19: error: =E2=80=98struct dentry=E2=80=99 = has no member named =E2=80=98d_alias=E2=80=99 > list_add(&dp->d_alias, &(AFSTOV(vcp)->i_dentry)); > ^ > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:404:7: warning: passing argument 2 of = =E2=80=98list_add=E2=80=99 from incompatible pointer type [enabled by = default] > list_add(&dp->d_alias, &(AFSTOV(vcp)->i_dentry)); > ^ > In file included from include/linux/wait.h:6:0, > from = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/afs/sysincludes.h:124, > from = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:19: > include/linux/list.h:61:20: note: expected =E2=80=98struct list_head = *=E2=80=99 but argument is of type =E2=80=98struct hlist_head *=E2=80=99 > static inline void list_add(struct list_head *new, struct list_head = *head) > ^ > make[4]: *** = [/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.f= c20.x86_64-SP/afs_daemons.o] Error 1 > make[3]: *** = [_module_/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19= .8-100.fc20.x86_64-SP] Error 2 > make[3]: Leaving directory `/usr/src/kernels/3.19.8-100.fc20.x86_64' > FAILURE: make exit code 2 > make[2]: *** [openafs.ko] Error 1 > make[2]: Leaving directory = `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.f= c20.x86_64-SP' > make[1]: *** [linux_compdirs] Error 2 > make[1]: Leaving directory = `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs' > make: *** [all] Error 2 From tcreedon@easystreet.net Mon Jun 22 15:09:42 2015 From: tcreedon@easystreet.net (Ted Creedon) Date: Mon, 22 Jun 2015 07:09:42 -0700 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> References: <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> <5586E874.2090606@your-file-system.com> <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> Message-ID: --001a1138132245a77305191bd3c7 Content-Type: text/plain; charset=UTF-8 EG OSX has a memory leak that requires weekly rebooting (per apple support) On Sunday, June 21, 2015, Harald Barth wrote: > > > I do not believe that the OpenAFS mailing lists are an appropriate forum > > to discuss AuriStor. My response to Michael provided details on > > AuriStor because I felt it was necessary in order to properly answer the > > implied questions. > > What I've learned so far from AuriStor it looks like it could be a > replacement for OpenAFS on the platforms it's available. And it can > more as Jeff tells us. If that strategy is good advertising depends > on "cultural background". > > > The question of "supported platforms" is an interesting one because it > > is very unclear what it means for OpenAFS to "support" a platform. What > > are the criteria? Is it sufficient to say that if you can build OpenAFS > > on the OS and hardware architecture that it is "supported"? > > Sorry, "supported" was probably a bad choice of word. But I don't know > if "availabe" or "runable" or "it builds it ships" would be better. > > > I am quite sure there are other criteria that could be added to the mix. > > I know that you take "supported" very seriously. I would be happy if > other software vendors (which are not into file systems) would do that > as well. > > > * Linux > > . Red Hat Enterprise Linux > > (YFSI is a Red Hat Technology Partner) > > . Fedora > > . Debian > > . Ubuntu > > * Microsoft Windows > > * Apple OSX and iOS > > * Oracle Solaris > > * IBM AIX > > * Android > > > > Servers are supported everywhere but on Windows, iOS and Android but the > > performance varies significantly based upon the OS release, processor > > architecture, and underlying hardware so there are combinations that we > > recommend and those we do not. > > > > The failure to list an OS family or Linux distribution does not imply > > that YFSI will not support AuriStor on that platform. It only implies > > that there has been insufficient customer interest to this point for > > YFSI to expend the necessary resources on development, testing and > > certification (where applicable.) > > Thanks for the list. I guess on "the main HW" which is amd64 for most > of the OSes above. Both at work and privately I run OpenAFS on > platforms that are not on the list and even in the future will not > have much "customer interest". > > > In the end software development has to be a partnership between those > > that build and those that deploy. If those that deploy do not fund > > those that build there will not be sufficient development hours and > > talent to build the solutions those that deploy require. > > I see that this partnership has stopped working in many places. It > makes me sad. > > > P.S. My apologies for the long reply. > > You don't need to apologise. > > Harald. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --001a1138132245a77305191bd3c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable EG OSX has a memory leak that requires weekly rebooting (per apple support)=

On Sunday, June 21, 2015, Harald Barth <haba@kth.se> wrote:

> I do not believe that the OpenAFS mailing lists are an appropriate for= um
> to discuss AuriStor.=C2=A0 My response to Michael provided details on<= br> > AuriStor because I felt it was necessary in order to properly answer t= he
> implied questions.

What I've learned so far from AuriStor it looks like it could be a
replacement for OpenAFS on the platforms it's available. And it can
more as Jeff tells us. If that strategy is good advertising depends
on "cultural background".

> The question of "supported platforms" is an interesting one = because it
> is very unclear what it means for OpenAFS to "support" a pla= tform.=C2=A0 What
> are the criteria?=C2=A0 Is it sufficient to say that if you can build = OpenAFS
> on the OS and hardware architecture that it is "supported"?<= br>
Sorry, "supported" was probably a bad choice of word. But I don&#= 39;t know
if "availabe" or "runable" or "it builds it ships&= quot; would be better.

> I am quite sure there are other criteria that could be added to the mi= x.

I know that you take "supported" very seriously. I would be happy= if
other software vendors (which are not into file systems) would do that
as well.

>=C2=A0 * Linux
>=C2=A0 =C2=A0 . Red Hat Enterprise Linux
>=C2=A0 =C2=A0 =C2=A0 (YFSI is a Red Hat Technology Partner)
>=C2=A0 =C2=A0 . Fedora
>=C2=A0 =C2=A0 . Debian
>=C2=A0 =C2=A0 . Ubuntu
>=C2=A0 * Microsoft Windows
>=C2=A0 * Apple OSX and iOS
>=C2=A0 * Oracle Solaris
>=C2=A0 * IBM AIX
>=C2=A0 * Android
>
> Servers are supported everywhere but on Windows, iOS and Android but t= he
> performance varies significantly based upon the OS release, processor<= br> > architecture, and underlying hardware so there are combinations that w= e
> recommend and those we do not.
>
> The failure to list an OS family or Linux distribution does not imply<= br> > that YFSI will not support AuriStor on that platform.=C2=A0 It only im= plies
> that there has been insufficient customer interest to this point for > YFSI to expend the necessary resources on development, testing and
> certification (where applicable.)

Thanks for the list. I guess on "the main HW" which is amd64 for = most
of the OSes above. Both at work and privately I run OpenAFS on
platforms that are not on the list and even in the future will not
have much "customer interest".

> In the end software development has to be a partnership between those<= br> > that build and those that deploy.=C2=A0 If those that deploy do not fu= nd
> those that build there will not be sufficient development hours and > talent to build the solutions those that deploy require.

I see that this partnership has stopped working in many places. It
makes me sad.

> P.S. My apologies for the long reply.

You don't need to apologise.

Harald.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--001a1138132245a77305191bd3c7-- From shadow@gmail.com Mon Jun 22 15:12:52 2015 From: shadow@gmail.com (Daria Brashear) Date: Mon, 22 Jun 2015 10:12:52 -0400 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: References: <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> <5586E874.2090606@your-file-system.com> <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> Message-ID: --089e013a08509321ea05191bde20 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 10:09 AM, Ted Creedon wrote: > EG OSX has a memory leak that requires weekly rebooting (per apple support) > > > Details? Cuz uh, I'm not rebooting weekly and... > On Sunday, June 21, 2015, Harald Barth wrote: > >> >> > I do not believe that the OpenAFS mailing lists are an appropriate forum >> > to discuss AuriStor. My response to Michael provided details on >> > AuriStor because I felt it was necessary in order to properly answer the >> > implied questions. >> >> What I've learned so far from AuriStor it looks like it could be a >> replacement for OpenAFS on the platforms it's available. And it can >> more as Jeff tells us. If that strategy is good advertising depends >> on "cultural background". >> >> > The question of "supported platforms" is an interesting one because it >> > is very unclear what it means for OpenAFS to "support" a platform. What >> > are the criteria? Is it sufficient to say that if you can build OpenAFS >> > on the OS and hardware architecture that it is "supported"? >> >> Sorry, "supported" was probably a bad choice of word. But I don't know >> if "availabe" or "runable" or "it builds it ships" would be better. >> >> > I am quite sure there are other criteria that could be added to the mix. >> >> I know that you take "supported" very seriously. I would be happy if >> other software vendors (which are not into file systems) would do that >> as well. >> >> > * Linux >> > . Red Hat Enterprise Linux >> > (YFSI is a Red Hat Technology Partner) >> > . Fedora >> > . Debian >> > . Ubuntu >> > * Microsoft Windows >> > * Apple OSX and iOS >> > * Oracle Solaris >> > * IBM AIX >> > * Android >> > >> > Servers are supported everywhere but on Windows, iOS and Android but the >> > performance varies significantly based upon the OS release, processor >> > architecture, and underlying hardware so there are combinations that we >> > recommend and those we do not. >> > >> > The failure to list an OS family or Linux distribution does not imply >> > that YFSI will not support AuriStor on that platform. It only implies >> > that there has been insufficient customer interest to this point for >> > YFSI to expend the necessary resources on development, testing and >> > certification (where applicable.) >> >> Thanks for the list. I guess on "the main HW" which is amd64 for most >> of the OSes above. Both at work and privately I run OpenAFS on >> platforms that are not on the list and even in the future will not >> have much "customer interest". >> >> > In the end software development has to be a partnership between those >> > that build and those that deploy. If those that deploy do not fund >> > those that build there will not be sufficient development hours and >> > talent to build the solutions those that deploy require. >> >> I see that this partnership has stopped working in many places. It >> makes me sad. >> >> > P.S. My apologies for the long reply. >> >> You don't need to apologise. >> >> Harald. >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > -- D --089e013a08509321ea05191bde20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 22, 2015 at 10:09 AM, Ted Creedon <tcreedon@easystreet.n= et> wrote:
EG OSX has a mem= ory leak that requires weekly rebooting (per apple support)



Details? Cuz uh, I'm not rebooting weekly and...
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Su= nday, June 21, 2015, Harald Barth <haba@kth.se> wrote:
> I do not believe that the OpenAFS mailing lists are an appropriate for= um
> to discuss AuriStor.=C2=A0 My response to Michael provided details on<= br> > AuriStor because I felt it was necessary in order to properly answer t= he
> implied questions.

What I've learned so far from AuriStor it looks like it could be a
replacement for OpenAFS on the platforms it's available. And it can
more as Jeff tells us. If that strategy is good advertising depends
on "cultural background".

> The question of "supported platforms" is an interesting one = because it
> is very unclear what it means for OpenAFS to "support" a pla= tform.=C2=A0 What
> are the criteria?=C2=A0 Is it sufficient to say that if you can build = OpenAFS
> on the OS and hardware architecture that it is "supported"?<= br>
Sorry, "supported" was probably a bad choice of word. But I don&#= 39;t know
if "availabe" or "runable" or "it builds it ships&= quot; would be better.

> I am quite sure there are other criteria that could be added to the mi= x.

I know that you take "supported" very seriously. I would be happy= if
other software vendors (which are not into file systems) would do that
as well.

>=C2=A0 * Linux
>=C2=A0 =C2=A0 . Red Hat Enterprise Linux
>=C2=A0 =C2=A0 =C2=A0 (YFSI is a Red Hat Technology Partner)
>=C2=A0 =C2=A0 . Fedora
>=C2=A0 =C2=A0 . Debian
>=C2=A0 =C2=A0 . Ubuntu
>=C2=A0 * Microsoft Windows
>=C2=A0 * Apple OSX and iOS
>=C2=A0 * Oracle Solaris
>=C2=A0 * IBM AIX
>=C2=A0 * Android
>
> Servers are supported everywhere but on Windows, iOS and Android but t= he
> performance varies significantly based upon the OS release, processor<= br> > architecture, and underlying hardware so there are combinations that w= e
> recommend and those we do not.
>
> The failure to list an OS family or Linux distribution does not imply<= br> > that YFSI will not support AuriStor on that platform.=C2=A0 It only im= plies
> that there has been insufficient customer interest to this point for > YFSI to expend the necessary resources on development, testing and
> certification (where applicable.)

Thanks for the list. I guess on "the main HW" which is amd64 for = most
of the OSes above. Both at work and privately I run OpenAFS on
platforms that are not on the list and even in the future will not
have much "customer interest".

> In the end software development has to be a partnership between those<= br> > that build and those that deploy.=C2=A0 If those that deploy do not fu= nd
> those that build there will not be sufficient development hours and > talent to build the solutions those that deploy require.

I see that this partnership has stopped working in many places. It
makes me sad.

> P.S. My apologies for the long reply.

You don't need to apologise.

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



--
D
--089e013a08509321ea05191bde20-- From ballbery@sinenomine.net Mon Jun 22 15:16:57 2015 From: ballbery@sinenomine.net (Brandon Allbery) Date: Mon, 22 Jun 2015 14:16:57 +0000 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: References: <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> <5586E874.2090606@your-file-system.com> <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> Message-ID: <1434982616.26282.2.camel@vikktakkht> T24gTW9uLCAyMDE1LTA2LTIyIGF0IDEwOjEyIC0wNDAwLCBEYXJpYSBCcmFzaGVhciB3cm90ZToN Cj4gDQo+IE9uIE1vbiwgSnVuIDIyLCAyMDE1IGF0IDEwOjA5IEFNLCBUZWQgQ3JlZWRvbg0KPiA8 dGNyZWVkb25AZWFzeXN0cmVldC5uZXQ+IHdyb3RlOg0KPiAgICAgICAgIEVHIE9TWCBoYXMgYSBt ZW1vcnkgbGVhayB0aGF0IHJlcXVpcmVzIHdlZWtseSByZWJvb3RpbmcgKHBlcg0KPiAgICAgICAg IGFwcGxlIHN1cHBvcnQpDQoNCg0KPiBEZXRhaWxzPyBDdXogdWgsIEknbSBub3QgcmVib290aW5n IHdlZWtseSBhbmQuLi4NCj4gDQoNCkkndmUgYmVlbiByZWJvb3Rpbmcgd2Vla2x5IGZvciBlc3Nl bnRpYWxseSB0aGUgZW50aXJlIHRpbWUgSSd2ZSB1c2VkIE9TDQpYIChiYWNrIHRvIFRpZ2VyIG9u IFBQQykgYmVjYXVzZSBvZiB2YXJpb3VzIG1lbW9yeSBsZWFrcyB0aGF0IGJlY29tZQ0KZXZpZGVu dCBhcyBzbG93bmVzcyBhbmQgZmFpbHVyZSBvZiBzb21lIHNlcnZpY2VzIGFmdGVyIGFib3V0IGEg d2VlayBvZg0Kb3BlcmF0aW9uLiBJIGFtIG5vdCBzdXJlIHRoaXMgaXMgd2hhdCBUZWQgaXMgZ2V0 dGluZyBhdCwgdGhvdWdoLg0KDQooR3JhbnRpbmcgdGhhdCBteSBub3JtYWwgdXNlIG9mIHByZXR0 eSBtdWNoIGFueSBzeXN0ZW0gaXMgbGlrZWx5IHRvIGJlDQpyZWdhcmRlZCBieSBvdGhlcnMgYXMg YSBzdHJlc3MgdGVzdC4gOikNCg0KLS0gDQpicmFuZG9uIHMgYWxsYmVyeSBrZjhuaCAgICAgICAg ICAgICAgICAgICAgICAgICAgIHNpbmUgbm9taW5lIGFzc29jaWF0ZXMNCmFsbGJlcnkuYkBnbWFp bC5jb20gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiYWxsYmVyeUBzaW5lbm9taW5lLm5l dA0KdW5peCBvcGVuYWZzIGtlcmJlcm9zIGluZnJhc3RydWN0dXJlIHhtb25hZCAgICAgICAgaHR0 cDovL3NpbmVub21pbmUubmV0DQo= From tcreedon@easystreet.net Mon Jun 22 15:47:19 2015 From: tcreedon@easystreet.net (Ted Creedon) Date: Mon, 22 Jun 2015 07:47:19 -0700 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: <1434982616.26282.2.camel@vikktakkht> References: <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> <5586E874.2090606@your-file-system.com> <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> <1434982616.26282.2.camel@vikktakkht> Message-ID: --047d7b6d8718cf617705191c5984 Content-Type: text/plain; charset=UTF-8 My daughter's system - a light user- requires weekly rebooting - same scenario as Brandon's. FYI When SUN migrated from SUN OS to SV5 R4 1,000 fatal bugs were discovered & fixed. The only problem I have with Linux is the constant upgrading & kernel module recompiling. What Linux needs is a MS driver compatibility mode. Tedc On Mon, Jun 22, 2015 at 7:16 AM, Brandon Allbery wrote: > On Mon, 2015-06-22 at 10:12 -0400, Daria Brashear wrote: > > > > On Mon, Jun 22, 2015 at 10:09 AM, Ted Creedon > > wrote: > > EG OSX has a memory leak that requires weekly rebooting (per > > apple support) > > > > Details? Cuz uh, I'm not rebooting weekly and... > > > > I've been rebooting weekly for essentially the entire time I've used OS > X (back to Tiger on PPC) because of various memory leaks that become > evident as slowness and failure of some services after about a week of > operation. I am not sure this is what Ted is getting at, though. > > (Granting that my normal use of pretty much any system is likely to be > regarded by others as a stress test. :) > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix openafs kerberos infrastructure xmonad http://sinenomine.net > --047d7b6d8718cf617705191c5984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My daughter's system - a light use= r- requires weekly rebooting - same scenario as Brandon's.

FYI When SUN migrated from SUN OS to SV5 R4 1,000 fatal bugs were discover= ed & fixed.

The only problem I have with Linux is the cons= tant upgrading & kernel module recompiling.

What Linux nee= ds is a MS driver compatibility mode.

Tedc

On Mon, Jun 22, 2015 at 7:1= 6 AM, Brandon Allbery <ballbery@sinenomine.net> wrote:=
On Mon, 2015-06-22 at 1= 0:12 -0400, Daria Brashear wrote:
>
> On Mon, Jun 22, 2015 at 10:09 AM, Ted Creedon
> <tcreedon@easystreet.net= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EG OSX has a memory leak that require= s weekly rebooting (per
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apple support)


> Details? Cuz uh, I'm not rebooting weekly and...
>

I've been rebooting weekly for essentially the entire time I'= ;ve used OS
X (back to Tiger on PPC) because of various memory leaks that become
evident as slowness and failure of some services after about a week of
operation. I am not sure this is what Ted is getting at, though.

(Granting that my normal use of pretty much any system is likely to be
regarded by others as a stress test. :)

--
brandon s allbery kf8nh=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sine nomine associates
allbery.b@gmail.com=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ballbery@sinen= omine.net
unix openafs kerberos infrastructure xmonad=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://s= inenomine.net

--047d7b6d8718cf617705191c5984-- From andreas.ladanyi@kit.edu Mon Jun 22 16:12:05 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Mon, 22 Jun 2015 17:12:05 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: References: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> Message-ID: <558825C5.7000205@kit.edu> This is a cryptographically signed message in MIME format. --------------ms030909080802090303080809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> >> On Fedora 20: >> I add a yum repository file which points to the 1.6.10 rpm Fedora 20 p= ackages at openafs.org >> >> yum install produce the following output with some errors and bad exit= : > 1.6.10 is too old for that kernel, you need at least 1.6.11. NB F20 is = EOL. ok. Thank you. Iam wondering because on openafs.org i could download 1.6.10 packages for Fedora 20. > > Best, > Stephan > --------------ms030909080802090303080809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP+jCC BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9 YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs 6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2 LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23 NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF hTCCBG2gAwIBAgIHGG3Jfo2QSjANBgkqhkiG9w0BAQsFADCBvzELMAkGA1UEBhMCREUxGzAZ BgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQK EyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVj aCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkB FgpjYUBraXQuZWR1MB4XDTE0MTAyNzEzNDMxMFoXDTE3MTAyNjEzNDMxMFowUzELMAkGA1UE BhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEYMBYG A1UEAxMPQW5kcmVhcyBMYWRhbnlpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tL0UuEE0MQWYP5MZOt+SBBDmGHZDf99xUzsFwyxvBaoS3TBZC/hul8ylNsOTrOvNbdJFOPTB izqfYQGf+JIxAgPomyG4jomQvMXhKXcf/obhf5lj2eBN0np/wLktMvFvj+HIEBh38/1o3ZXE SV4aMhvNW9VO116K0fh3/7TElksZ95zNj77js/JoEMQB8mGw27hw5u8VOKrDEWuzTBu4M7Vg MdzNrYi+m3AiYv1m110i6rJ4otbThGRfcEbDHwqfONfminidzyS4aHpNyO7U98xmn360m8qs q3smEn7XRGRgVlpzu7lNuJ8AvKZGPrM4OJ1Rhgxo5enuS1XVw29IBwIDAQABo4IB7zCCAesw QAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwIwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsG AQQBga0hgiwBAQQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRSBxcWWTqn7d35eE0sUlWSXfPOizAfBgNVHSMEGDAW gBQfdGX0mh169jHp32EbcysNbdAzSTAiBgNVHREEGzAZgRdhbmRyZWFzLmxhZGFueWlAa2l0 LmVkdTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2Ev cHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYB BQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDANBgkqhkiG9w0BAQsFAAOCAQEALmsJ+qKYuD1TTYxYAYcOUc7Pw3SBI+PX941ze1n2 coAeuXY2Ldd2lrjyirS8eHuPCZihmbVlMe/26WqBwDLN/vk7FC5c0aatidQz6MoquWJWnHSj 1XlB/AOv9aD4tKLHURw7ejFvY3imott/vrLJrt2WjYvPaMvwAoZKgTY2bXEZQjWYnGJRthuK 1OG4CFJlQphREiewuqzjCxABnC3Rmo7BWy/yGeMGSkMsTg+uhOwv8568KtJE3z4uTWtN1w0d T1uI1/uJ5jrsyoodUg/q31lGGgtrmElCwrHJSk+6Hp6KCXilzY9d/N/CQXkHnNLu6aDgc8gX n9Y/cLepRKKZvzCCBZQwggR8oAMCAQICBxev928jIukwDQYJKoZIhvcNAQELBQAwWjELMAkG A1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA4MzFaFw0xOTA3 MDkyMzU5MDBaMIG/MQswCQYDVQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJn MRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2Yg VGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5idWNoIENlbnRyZSBmb3IgQ29tcHV0aW5nMQ8w DQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEWCmNhQGtpdC5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDMsqiKiaKAQVEpL20dPB0IejTRPrajRK7mwwXpqBo/APNN 8IPtcb16pITtb5wQAaeVPvu8YA+bi5U3Dm/xeFBayQQcvUAp04cwm/nqhvveCMOpvC41qgiq K/ZSsDQlIre78zQDgndK9IjQmFdv8XCvLR0h8N5hl4L8H2NBfY9eJ1BIPZ3eZD6tAMPYkBw7 mJzs9wPDVU6V6Uws4kEwmSUGBEw7Avp8p0DdrLwJgFd1dRyUXvwA+oncv+hzdBLQCDj5RNac deDRUuEmalJPxeLw/KcUs/2FMGwhiuCB9+1fW3G0JgPDTTSgbRS6l9faL7kJ99pUcElvws9x 4/s0kT9zAgMBAAGjggH3MIIB8zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIB BjARBgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFB90ZfSaHXr2MenfYRtzKw1t0DNJMB8G A1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCmNhQGtpdC5lZHUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggr BgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNl cnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9i YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBADoW Jv/UVyB9nfsoym9xKp8a7sOLa4XSPU/xrKF4Dp3UdlKdzDK2JvzCziF50SiH54ZuKbsKUa6Y XwHiWHO7tsUW2+r6cnbf6FGcvylyeOtetQsoKvB2bMhEG0fn1B4+9k5IuXJpcQSHiKZhRa/l qNWO95hKHvhtUO8dlTYtlTaSEmv6RAcfw2JcYKiB2GC97h3YpwimDC15sfzwYdnhTdSXF54C VPgwHPL85cR/YI7KlQtjvI6yz14mma7ffYN6W7UBDPPc/5emiYIgxbwEBFZ5orfkvPtfeJUu T3FI7RBmE8mPl/betefdZzqF1F357emrpuGH9gZbJp98SgruQqgxggSCMIIEfgIBATCByzCB vzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJ S2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kx JzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lU LUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMAkGBSsOAwIaBQCgggKL MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyMjE1MTIw NVowIwYJKoZIhvcNAQkEMRYEFCFMa0W2aZ4lSkf1IqS8JOcJbuTDMGwGCSqGSIb3DQEJDzFf MF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdwGCSsGAQQBgjcQ BDGBzjCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzES MBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRl Y2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0G A1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMIHeBgsq hkiG9w0BCRACCzGBzqCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0 dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1 dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+ jZBKMA0GCSqGSIb3DQEBAQUABIIBACF5dHC/KGLJkdYWgNFWxY07FPBNsrRg7IjAzSnnNYDt Fb4fydOx5Qw2tDauZGIC3mHvrT63zzDWlM3jlwW3q+yBqp8mjQ5RzfAAuh9L2J+2+52HXAWo o7wLJ2Cn1MmkQ9OAkfBqwwczlBBTgMPrS18KkcGSGOMe9UGxPs0Ixo447f4dpzHfP6TThBC1 7/lBgR/tleZcsRS/rfidQzz7UfTe50Rdqyvw/bm71R3Y0Cs5mKmCt6WnqwUVFnq1Z2z5va0B AE0RgIEhOIkw4PhrJ6jTtults5cwP/FDfXrCB2INXJBq53oGo3uwUERtHace19gKjjz1rbGT CpUl4vuHnsYAAAAAAAA= --------------ms030909080802090303080809-- From drosih@rpi.edu Mon Jun 22 18:25:31 2015 From: drosih@rpi.edu (Garance A Drosehn) Date: Mon, 22 Jun 2015 13:25:31 -0400 Subject: [OpenAFS] OpenAFS still in development? In-Reply-To: References: <55858911.4040207@your-file-system.com> <20150621.105538.392933186214179715.haba@habook.pdc.kth.se> <5586E874.2090606@your-file-system.com> <20150622.060209.2076223686156593711.haba@habook.pdc.kth.se> Message-ID: Hmm. I have multiple macs running (between here in the office and at home), and on average I go something like 40-60 days before I have to reboot. And the most frequent reason for a reboot is that Apple has released an update which forces me to reboot. My Mac at home sees fairly light and simple use, but the one here in my office is loaded up with quite a lot of different things running, and running all the time. It may be significant that I haven't installed Yosemite yet (partially due to OpenAFS installer questions, but mainly because I haven't had the time). And I know several of my friends keep their macs running for long stretches between reboots. Not all of them, but most of them. You mention "per apple support". Do you have a link to a knowledge-base article or some other web page which mentions what issue you're running into? It might be helpful to know for my friends who do seem to need to reboot every week or two. -- garance alistair drosehn On 22 Jun 2015, at 10:09, Ted Creedon wrote: > > EG OSX has a memory leak that requires weekly rebooting (per apple > support) > From andreas.ladanyi@kit.edu Thu Jun 25 10:02:09 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Thu, 25 Jun 2015 11:02:09 +0200 Subject: [OpenAFS] bos server instances doesnt come up Message-ID: <558BC391.4080404@kit.edu> This is a cryptographically signed message in MIME format. --------------ms020303050608070806080805 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, i installed Openafs 1.6.11.1. The pt / vl / bu instances dont come up. bos status FQDN server -noauth bos: running unauthenticated Instance buserver, temporarily disabled, stopped for too many errors, currently starting up. Instance ptserver, temporarily disabled, stopped for too many errors, currently starting up. Instance vlserver, temporarily disabled, stopped for too many errors, currently starting up. Boslog: =3D=3D=3D=3D The executables which are missed in the filesystem are available. Thu Jun 25 10:52:36 2015: BNODE 'vlserver' repeatedly failed to start, perhaps missing executable. Thu Jun 25 10:52:36 2015: vlserver will retry start in 32 seconds Thu Jun 25 10:52:40 2015: buserver started pid 72469: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72470: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72471: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72472: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72473: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72474: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72475: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72476: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72477: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72478: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72479: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: buserver started pid 72480: /usr/afs/bin/buserv= er Thu Jun 25 10:52:40 2015: buserver exited with code 255 Thu Jun 25 10:52:40 2015: BNODE 'buserver' repeatedly failed to start, perhaps missing executable. Thu Jun 25 10:52:40 2015: buserver will retry start in 60 seconds Thu Jun 25 10:53:00 2015: ptserver started pid 72481: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72482: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72483: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72484: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72485: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72486: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72487: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72488: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72489: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72490: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72491: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: ptserver started pid 72492: /usr/afs/bin/ptserv= er Thu Jun 25 10:53:00 2015: ptserver exited with code 2 Thu Jun 25 10:53:00 2015: BNODE 'ptserver' repeatedly failed to start, perhaps missing executable. Thu Jun 25 10:53:00 2015: ptserver will retry start in 60 seconds Thu Jun 25 10:53:09 2015: vlserver started pid 72493: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72494: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72495: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72496: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72497: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72498: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72499: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72500: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72501: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72502: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72503: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: vlserver started pid 72504: /usr/afs/bin/vlserv= er Thu Jun 25 10:53:09 2015: vlserver exited with code 2 Thu Jun 25 10:53:09 2015: BNODE 'vlserver' repeatedly failed to start, perhaps missing executable. PtLog: =3D=3D=3D=3D ptserver: file not found when processing dbase Ubik init failed ptserver: running unauthenticated VLLog: =3D=3D=3D=3D=3D vlserver: Ubik init failed: file not found when processing dbase /usr/afs/etc/CellServDB: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >cellname #Cell name IP of the OpenAFS server #FQDN of the OpenAFS server /usr/afs/etc/ThisCell: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cellname Any ideas whats going wrong ? regards, Andy --------------ms020303050608070806080805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP+jCC BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9 YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs 6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2 LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23 NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF hTCCBG2gAwIBAgIHGG3Jfo2QSjANBgkqhkiG9w0BAQsFADCBvzELMAkGA1UEBhMCREUxGzAZ BgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQK EyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVj aCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkB FgpjYUBraXQuZWR1MB4XDTE0MTAyNzEzNDMxMFoXDTE3MTAyNjEzNDMxMFowUzELMAkGA1UE BhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEYMBYG A1UEAxMPQW5kcmVhcyBMYWRhbnlpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tL0UuEE0MQWYP5MZOt+SBBDmGHZDf99xUzsFwyxvBaoS3TBZC/hul8ylNsOTrOvNbdJFOPTB izqfYQGf+JIxAgPomyG4jomQvMXhKXcf/obhf5lj2eBN0np/wLktMvFvj+HIEBh38/1o3ZXE SV4aMhvNW9VO116K0fh3/7TElksZ95zNj77js/JoEMQB8mGw27hw5u8VOKrDEWuzTBu4M7Vg MdzNrYi+m3AiYv1m110i6rJ4otbThGRfcEbDHwqfONfminidzyS4aHpNyO7U98xmn360m8qs q3smEn7XRGRgVlpzu7lNuJ8AvKZGPrM4OJ1Rhgxo5enuS1XVw29IBwIDAQABo4IB7zCCAesw QAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwIwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsG AQQBga0hgiwBAQQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRSBxcWWTqn7d35eE0sUlWSXfPOizAfBgNVHSMEGDAW gBQfdGX0mh169jHp32EbcysNbdAzSTAiBgNVHREEGzAZgRdhbmRyZWFzLmxhZGFueWlAa2l0 LmVkdTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2Ev cHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYB BQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDANBgkqhkiG9w0BAQsFAAOCAQEALmsJ+qKYuD1TTYxYAYcOUc7Pw3SBI+PX941ze1n2 coAeuXY2Ldd2lrjyirS8eHuPCZihmbVlMe/26WqBwDLN/vk7FC5c0aatidQz6MoquWJWnHSj 1XlB/AOv9aD4tKLHURw7ejFvY3imott/vrLJrt2WjYvPaMvwAoZKgTY2bXEZQjWYnGJRthuK 1OG4CFJlQphREiewuqzjCxABnC3Rmo7BWy/yGeMGSkMsTg+uhOwv8568KtJE3z4uTWtN1w0d T1uI1/uJ5jrsyoodUg/q31lGGgtrmElCwrHJSk+6Hp6KCXilzY9d/N/CQXkHnNLu6aDgc8gX n9Y/cLepRKKZvzCCBZQwggR8oAMCAQICBxev928jIukwDQYJKoZIhvcNAQELBQAwWjELMAkG A1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA4MzFaFw0xOTA3 MDkyMzU5MDBaMIG/MQswCQYDVQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJn MRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2Yg VGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5idWNoIENlbnRyZSBmb3IgQ29tcHV0aW5nMQ8w DQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEWCmNhQGtpdC5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDMsqiKiaKAQVEpL20dPB0IejTRPrajRK7mwwXpqBo/APNN 8IPtcb16pITtb5wQAaeVPvu8YA+bi5U3Dm/xeFBayQQcvUAp04cwm/nqhvveCMOpvC41qgiq K/ZSsDQlIre78zQDgndK9IjQmFdv8XCvLR0h8N5hl4L8H2NBfY9eJ1BIPZ3eZD6tAMPYkBw7 mJzs9wPDVU6V6Uws4kEwmSUGBEw7Avp8p0DdrLwJgFd1dRyUXvwA+oncv+hzdBLQCDj5RNac deDRUuEmalJPxeLw/KcUs/2FMGwhiuCB9+1fW3G0JgPDTTSgbRS6l9faL7kJ99pUcElvws9x 4/s0kT9zAgMBAAGjggH3MIIB8zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIB BjARBgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFB90ZfSaHXr2MenfYRtzKw1t0DNJMB8G A1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCmNhQGtpdC5lZHUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggr BgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNl cnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9i YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBADoW Jv/UVyB9nfsoym9xKp8a7sOLa4XSPU/xrKF4Dp3UdlKdzDK2JvzCziF50SiH54ZuKbsKUa6Y XwHiWHO7tsUW2+r6cnbf6FGcvylyeOtetQsoKvB2bMhEG0fn1B4+9k5IuXJpcQSHiKZhRa/l qNWO95hKHvhtUO8dlTYtlTaSEmv6RAcfw2JcYKiB2GC97h3YpwimDC15sfzwYdnhTdSXF54C VPgwHPL85cR/YI7KlQtjvI6yz14mma7ffYN6W7UBDPPc/5emiYIgxbwEBFZ5orfkvPtfeJUu T3FI7RBmE8mPl/betefdZzqF1F357emrpuGH9gZbJp98SgruQqgxggSCMIIEfgIBATCByzCB vzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJ S2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kx JzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lU LUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMAkGBSsOAwIaBQCgggKL MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyNTA5MDIw OVowIwYJKoZIhvcNAQkEMRYEFMwDeXHh9QejtpBT7Gu70GpBKXZyMGwGCSqGSIb3DQEJDzFf MF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdwGCSsGAQQBgjcQ BDGBzjCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzES MBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRl Y2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0G A1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMIHeBgsq hkiG9w0BCRACCzGBzqCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0 dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1 dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+ jZBKMA0GCSqGSIb3DQEBAQUABIIBACMEPDDSGaWKxHV0EDNWFfBMjB3i2iIFoO1EtaLmAh6U l+Zo+/0t85JkvP0w/xF9+B2xLRyzrsbP59VC3woEUBZtqSk3Z2L2+XqnPOTCtmTD28jfxr6y FAvxX1rAKQSgcpmVPzCmXiuFHbVGSGFY1LMDQYXFmkER+QSKNCKZoY6N05fLTNPiYzcDjo7O +v2ZN4YFLnuJ/Jg0HQtOhwsODx1ZY74NPRse42LqxXG6XaHu177XkChrpkarjj5cBfYeBrG6 +Wc4h85kscO4F1O9oHSba5sAIlJlDqHYUPjNq4Z0pWTutsDavBYUISpP1zkrEiqD1W4OzfOO EHHfUGdHSh8AAAAAAAA= --------------ms020303050608070806080805-- From jaltman@your-file-system.com Thu Jun 25 12:34:14 2015 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Thu, 25 Jun 2015 07:34:14 -0400 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <558BC391.4080404@kit.edu> References: <558BC391.4080404@kit.edu> Message-ID: <558BE736.9010001@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms070007030906050808010405 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/25/2015 5:02 AM, Andreas Ladanyi wrote: > PtLog: > =3D=3D=3D=3D >=20 > ptserver: file not found when processing dbase Ubik init failed > ptserver: running unauthenticated >=20 > VLLog: > =3D=3D=3D=3D=3D >=20 > vlserver: Ubik init failed: file not found when processing dbase >=20 The database file cannot be created or opened. How was OpenAFS installed and on which OS/version? Jeffrey Altman --------------ms070007030906050808010405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhAW xDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMzg2MTAyMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCteTFLbuPm2vx85lH2 Y6LHdMIqcKQPN9m4XYVTe0L8ZvMvnJ1YQ720ET52CF18RYdTc4to92+ffdmjWlBedK4YtLam htsUkJ6WL3krwNVTYfeej0wgF9kVQ2FI8XTNngxnJ2CRkQX4Z9/1TI4wTkSNcAw5T0Y2HKM9 4p7wAJOefl+3oPwxXn338w8T7LsfwS9FOADZ8uRItv/J7S8BJEP0XtjZZlBoSyqQ4qxl5PtI uybHVdwoo2PlK8LxU6r8Vcje1+OXmc5VoCBlXiYDWHl/wSDtZEWR6431/az1Z45n1AHHber2 G+Ijb0nF4RLiiFMkyJl3qx+46wqcqWrjrRxDAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFBUlv/9jizZz4uwaFtPzwdX6FsqwMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBAJIvoMatM56/QjaVAlEUbeWZNOPkwuiC gaaekWJi1h33fAVfdF+WZqh7dF4hBNalyPuxRcyZX7HxuPyBc3ajDCqew9MlmCJ3Cm4Co3fZ Yh50OX4jnem2RmpHeKbJW6zUjZcAGqV6DPMl04kgrI2whJX7729HoRyUPwZS7CZSRFZO147X 2+/JogDYKffa/+q5AwgrHYvdECHxc3Iz9KnHSmit+DhWS9t+XxE0gHr3sW7zwcQ/GYyrJ3s3 VdWHTjM+3iGFeTOI06h1aBgFR/+8fTmuZXZz9+OdWVar0Crt9bn0cFN3u00Q6YAyjYhRnbXy zYVIOS4oJmRoK79p/xodeDUxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBbEMEm4oBwlVrtv5MmH C8QwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNjI1MTEzNDE0WjAjBgkqhkiG9w0BCQQxFgQUwk9PiwjQH/3jTN5elvZyLZWs ++gwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQFsQwSbigHCVWu2/kyYcLxDCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAWxDBJuKAcJVa7b+TJhwvEMA0GCSqGSIb3DQEB AQUABIIBAIa9gaKkbxHKCZiURB05vje+yNfvB/O0IrrYiDm6mqp8ifE9SyM2TyEhekW23Dc1 oldNho2ESzO4IHLONOKHiH44V5YbuZ1ZOye5VhrqJacT4WIqiszD6qbg7lJCt10sljvrZMDx 0J+M7dnoWb9fVJ+DNjtej/31FcP0XYT5aueWxmDIfoFhjbBqrjtHmx4ZqpHK1b7FIC0Vgs8n 8aspQml1bpGH4SaDuY56t5a2W7H5tM0wRkth4MBOIkH3lIHoSFdUII7MGnCQ09jJHm5PkARb FezaKah1AcgjVu62zV129a2gIDqMKkZykI35v14mYYBZVqubV+x15NAFzm5QRbsAAAAAAAA= --------------ms070007030906050808010405-- From andreas.ladanyi@kit.edu Thu Jun 25 12:56:14 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Thu, 25 Jun 2015 13:56:14 +0200 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <558BC391.4080404@kit.edu> References: <558BC391.4080404@kit.edu> Message-ID: <558BEC5E.5070702@kit.edu> This is a cryptographically signed message in MIME format. --------------ms070300060506020901010008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If i start the bosserver with the command: /usr/afs/bin/bosserver -noauth & then creating the instances with: bos create instance -noauth now works. Before that i tried to use the systemd afs server script which makes trouble when creating instances with bos command like described below. > Hi, > > i installed Openafs 1.6.11.1. The pt / vl / bu instances dont come up. > > bos status FQDN server -noauth > bos: running unauthenticated > Instance buserver, temporarily disabled, stopped for too many errors, > currently starting up. > Instance ptserver, temporarily disabled, stopped for too many errors, > currently starting up. > Instance vlserver, temporarily disabled, stopped for too many errors, > currently starting up. > > Boslog: > =3D=3D=3D=3D > > The executables which are missed in the filesystem are available. > > > > Thu Jun 25 10:52:36 2015: BNODE 'vlserver' repeatedly failed to start, > perhaps missing executable. > Thu Jun 25 10:52:36 2015: vlserver will retry start in 32 seconds > Thu Jun 25 10:52:40 2015: buserver started pid 72469: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72470: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72471: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72472: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72473: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72474: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72475: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72476: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72477: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72478: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72479: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: buserver started pid 72480: /usr/afs/bin/buse= rver > Thu Jun 25 10:52:40 2015: buserver exited with code 255 > Thu Jun 25 10:52:40 2015: BNODE 'buserver' repeatedly failed to start, > perhaps missing executable. > Thu Jun 25 10:52:40 2015: buserver will retry start in 60 seconds > Thu Jun 25 10:53:00 2015: ptserver started pid 72481: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72482: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72483: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72484: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72485: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72486: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72487: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72488: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72489: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72490: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72491: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: ptserver started pid 72492: /usr/afs/bin/ptse= rver > Thu Jun 25 10:53:00 2015: ptserver exited with code 2 > Thu Jun 25 10:53:00 2015: BNODE 'ptserver' repeatedly failed to start, > perhaps missing executable. > Thu Jun 25 10:53:00 2015: ptserver will retry start in 60 seconds > Thu Jun 25 10:53:09 2015: vlserver started pid 72493: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72494: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72495: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72496: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72497: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72498: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72499: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72500: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72501: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72502: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72503: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: vlserver started pid 72504: /usr/afs/bin/vlse= rver > Thu Jun 25 10:53:09 2015: vlserver exited with code 2 > Thu Jun 25 10:53:09 2015: BNODE 'vlserver' repeatedly failed to start, > perhaps missing executable. > > PtLog: > =3D=3D=3D=3D > > ptserver: file not found when processing dbase Ubik init failed > ptserver: running unauthenticated > > VLLog: > =3D=3D=3D=3D=3D > > vlserver: Ubik init failed: file not found when processing dbase > > > /usr/afs/etc/CellServDB: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> cellname #Cell name > IP of the OpenAFS server #FQDN of the OpenAFS server > > /usr/afs/etc/ThisCell: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > cellname > > > > Any ideas whats going wrong ? > > regards, > Andy > --=20 Karlsruher Institut f=C3=BCr Technologie (KIT) Fakult=C3=A4t f=C3=BCr Informatik ATIS =E2=80=93 Abteilung Technische Infrastruktur Dipl.-Ing. Andreas Ladanyi - Systemadministrator - Am Fasanengarten 5, Geb=C3=A4ude 50.34, Raum 013 76131 Karlsruhe Telefon: +49 721 608 - 4 3663 Fax: +49 721 608 - 4 6699 E-Mail: andreas.ladanyi@kit.edu www.atis.informatik.kit.edu www.kit.edu KIT - Universit=C3=A4t des Landes Baden-W=C3=BCrttemberg und nationales F= orschungszentrum in der Helmholtz-Gemeinschaft Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert. --------------ms070300060506020901010008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP+jCC BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9 YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs 6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2 LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23 NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF hTCCBG2gAwIBAgIHGG3Jfo2QSjANBgkqhkiG9w0BAQsFADCBvzELMAkGA1UEBhMCREUxGzAZ BgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQK EyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVj aCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkB FgpjYUBraXQuZWR1MB4XDTE0MTAyNzEzNDMxMFoXDTE3MTAyNjEzNDMxMFowUzELMAkGA1UE BhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEYMBYG A1UEAxMPQW5kcmVhcyBMYWRhbnlpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tL0UuEE0MQWYP5MZOt+SBBDmGHZDf99xUzsFwyxvBaoS3TBZC/hul8ylNsOTrOvNbdJFOPTB izqfYQGf+JIxAgPomyG4jomQvMXhKXcf/obhf5lj2eBN0np/wLktMvFvj+HIEBh38/1o3ZXE SV4aMhvNW9VO116K0fh3/7TElksZ95zNj77js/JoEMQB8mGw27hw5u8VOKrDEWuzTBu4M7Vg MdzNrYi+m3AiYv1m110i6rJ4otbThGRfcEbDHwqfONfminidzyS4aHpNyO7U98xmn360m8qs q3smEn7XRGRgVlpzu7lNuJ8AvKZGPrM4OJ1Rhgxo5enuS1XVw29IBwIDAQABo4IB7zCCAesw QAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwIwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsG AQQBga0hgiwBAQQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRSBxcWWTqn7d35eE0sUlWSXfPOizAfBgNVHSMEGDAW gBQfdGX0mh169jHp32EbcysNbdAzSTAiBgNVHREEGzAZgRdhbmRyZWFzLmxhZGFueWlAa2l0 LmVkdTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2Ev cHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYB BQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDANBgkqhkiG9w0BAQsFAAOCAQEALmsJ+qKYuD1TTYxYAYcOUc7Pw3SBI+PX941ze1n2 coAeuXY2Ldd2lrjyirS8eHuPCZihmbVlMe/26WqBwDLN/vk7FC5c0aatidQz6MoquWJWnHSj 1XlB/AOv9aD4tKLHURw7ejFvY3imott/vrLJrt2WjYvPaMvwAoZKgTY2bXEZQjWYnGJRthuK 1OG4CFJlQphREiewuqzjCxABnC3Rmo7BWy/yGeMGSkMsTg+uhOwv8568KtJE3z4uTWtN1w0d T1uI1/uJ5jrsyoodUg/q31lGGgtrmElCwrHJSk+6Hp6KCXilzY9d/N/CQXkHnNLu6aDgc8gX n9Y/cLepRKKZvzCCBZQwggR8oAMCAQICBxev928jIukwDQYJKoZIhvcNAQELBQAwWjELMAkG A1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA4MzFaFw0xOTA3 MDkyMzU5MDBaMIG/MQswCQYDVQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJn MRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2Yg VGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5idWNoIENlbnRyZSBmb3IgQ29tcHV0aW5nMQ8w DQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEWCmNhQGtpdC5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDMsqiKiaKAQVEpL20dPB0IejTRPrajRK7mwwXpqBo/APNN 8IPtcb16pITtb5wQAaeVPvu8YA+bi5U3Dm/xeFBayQQcvUAp04cwm/nqhvveCMOpvC41qgiq K/ZSsDQlIre78zQDgndK9IjQmFdv8XCvLR0h8N5hl4L8H2NBfY9eJ1BIPZ3eZD6tAMPYkBw7 mJzs9wPDVU6V6Uws4kEwmSUGBEw7Avp8p0DdrLwJgFd1dRyUXvwA+oncv+hzdBLQCDj5RNac deDRUuEmalJPxeLw/KcUs/2FMGwhiuCB9+1fW3G0JgPDTTSgbRS6l9faL7kJ99pUcElvws9x 4/s0kT9zAgMBAAGjggH3MIIB8zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIB BjARBgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFB90ZfSaHXr2MenfYRtzKw1t0DNJMB8G A1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCmNhQGtpdC5lZHUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggr BgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNl cnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9i YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBADoW Jv/UVyB9nfsoym9xKp8a7sOLa4XSPU/xrKF4Dp3UdlKdzDK2JvzCziF50SiH54ZuKbsKUa6Y XwHiWHO7tsUW2+r6cnbf6FGcvylyeOtetQsoKvB2bMhEG0fn1B4+9k5IuXJpcQSHiKZhRa/l qNWO95hKHvhtUO8dlTYtlTaSEmv6RAcfw2JcYKiB2GC97h3YpwimDC15sfzwYdnhTdSXF54C VPgwHPL85cR/YI7KlQtjvI6yz14mma7ffYN6W7UBDPPc/5emiYIgxbwEBFZ5orfkvPtfeJUu T3FI7RBmE8mPl/betefdZzqF1F357emrpuGH9gZbJp98SgruQqgxggSCMIIEfgIBATCByzCB vzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJ S2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kx JzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lU LUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMAkGBSsOAwIaBQCgggKL MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyNTExNTYx NFowIwYJKoZIhvcNAQkEMRYEFCht2sFA8pVM/h/3ymvmzHqsYgyjMGwGCSqGSIb3DQEJDzFf MF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdwGCSsGAQQBgjcQ BDGBzjCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzES MBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRl Y2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0G A1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMIHeBgsq hkiG9w0BCRACCzGBzqCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0 dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1 dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+ jZBKMA0GCSqGSIb3DQEBAQUABIIBAIBE76mSd82wt9OPf2nfJzBuHIdB9rC+c/XuJ3+ESIeu cxsOG2AWwQresik/9V7B+1Vutzg3jXu5Idwk4/ihz5nj2Qcj4iUm5iOv0JNYSwCUpPxCb6OP ALg/VMmdAH6QoPov9HYe9m1QteFNnEyq+USpK8+Mroiv4Yxj3VI6m+SeE/GUhxZDYmZMKxPS aKSk/azyJ4HKkTkkY5B/Ltxw8dfPTJTQdr2Wt9SxXhH38o0yYNPPa2t9WvfVEflJtK9y7cXB 3QUnfxzg7ZLy+FFgLciw0i0AOaStJx3Nb5eoiN7kMst2SV8KfE+XWYfNM4gWK6xZdOvbFy3o Fhi9uzmjih4AAAAAAAA= --------------ms070300060506020901010008-- From stephan.wiesand@desy.de Thu Jun 25 13:10:50 2015 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Thu, 25 Jun 2015 14:10:50 +0200 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <558BEC5E.5070702@kit.edu> References: <558BC391.4080404@kit.edu> <558BEC5E.5070702@kit.edu> Message-ID: <8DE8D09A-D916-4A36-989D-6A73993752FF@desy.de> If you'd answer Jeffrey's questions we could tell you to disable = SELinux. > On 25 Jun 2015, at 13:56, Andreas Ladanyi = wrote: >=20 > If i start the bosserver with the command: >=20 > /usr/afs/bin/bosserver -noauth & >=20 > then creating the instances with: >=20 > bos create instance -noauth now works. >=20 > Before that i tried to use the systemd afs server script which makes > trouble when creating instances with bos command like described below. >=20 >> Hi, >>=20 >> i installed Openafs 1.6.11.1. The pt / vl / bu instances dont come = up. >>=20 >> bos status FQDN server -noauth >> bos: running unauthenticated >> Instance buserver, temporarily disabled, stopped for too many errors, >> currently starting up. >> Instance ptserver, temporarily disabled, stopped for too many errors, >> currently starting up. >> Instance vlserver, temporarily disabled, stopped for too many errors, >> currently starting up. >>=20 >> Boslog: >> =3D=3D=3D=3D >>=20 >> The executables which are missed in the filesystem are available. >>=20 >>=20 >>=20 >> Thu Jun 25 10:52:36 2015: BNODE 'vlserver' repeatedly failed to = start, >> perhaps missing executable. >> Thu Jun 25 10:52:36 2015: vlserver will retry start in 32 seconds >> Thu Jun 25 10:52:40 2015: buserver started pid 72469: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72470: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72471: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72472: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72473: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72474: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72475: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72476: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72477: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72478: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72479: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: buserver started pid 72480: = /usr/afs/bin/buserver >> Thu Jun 25 10:52:40 2015: buserver exited with code 255 >> Thu Jun 25 10:52:40 2015: BNODE 'buserver' repeatedly failed to = start, >> perhaps missing executable. >> Thu Jun 25 10:52:40 2015: buserver will retry start in 60 seconds >> Thu Jun 25 10:53:00 2015: ptserver started pid 72481: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72482: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72483: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72484: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72485: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72486: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72487: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72488: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72489: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72490: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72491: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: ptserver started pid 72492: = /usr/afs/bin/ptserver >> Thu Jun 25 10:53:00 2015: ptserver exited with code 2 >> Thu Jun 25 10:53:00 2015: BNODE 'ptserver' repeatedly failed to = start, >> perhaps missing executable. >> Thu Jun 25 10:53:00 2015: ptserver will retry start in 60 seconds >> Thu Jun 25 10:53:09 2015: vlserver started pid 72493: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72494: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72495: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72496: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72497: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72498: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72499: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72500: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72501: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72502: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72503: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: vlserver started pid 72504: = /usr/afs/bin/vlserver >> Thu Jun 25 10:53:09 2015: vlserver exited with code 2 >> Thu Jun 25 10:53:09 2015: BNODE 'vlserver' repeatedly failed to = start, >> perhaps missing executable. >>=20 >> PtLog: >> =3D=3D=3D=3D >>=20 >> ptserver: file not found when processing dbase Ubik init failed >> ptserver: running unauthenticated >>=20 >> VLLog: >> =3D=3D=3D=3D=3D >>=20 >> vlserver: Ubik init failed: file not found when processing dbase >>=20 >>=20 >> /usr/afs/etc/CellServDB: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>> cellname #Cell name >> IP of the OpenAFS server #FQDN of the OpenAFS server >>=20 >> /usr/afs/etc/ThisCell: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> cellname >>=20 >>=20 >>=20 >> Any ideas whats going wrong ? >>=20 >> regards, >> Andy >>=20 From andreas.ladanyi@kit.edu Thu Jun 25 13:13:20 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Thu, 25 Jun 2015 14:13:20 +0200 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <558BE736.9010001@your-file-system.com> References: <558BC391.4080404@kit.edu> <558BE736.9010001@your-file-system.com> Message-ID: <558BF060.7010401@kit.edu> This is a cryptographically signed message in MIME format. --------------ms000002020102040506090207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jeffrey, i use the description OpenAFS Quick Start Guide for Unix. At this time i have done the steps at http://docs.openafs.org/QuickStartUnix/index.html#HDRWQ52.html I tried to start the bos server with the systemd script. I think at this state it wasnt a good idea. > On 6/25/2015 5:02 AM, Andreas Ladanyi wrote: > >> PtLog: >> =3D=3D=3D=3D >> >> ptserver: file not found when processing dbase Ubik init failed >> ptserver: running unauthenticated >> >> VLLog: >> =3D=3D=3D=3D=3D >> >> vlserver: Ubik init failed: file not found when processing dbase >> > The database file cannot be created or opened. > > How was OpenAFS installed and on which OS/version? with the openafs srpm package from the openafs website. I built my own binary rpms from this srpm package and installed it. The OS is centos 7. > > Jeffrey Altman > > > --------------ms000002020102040506090207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP+jCC BNUwggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRww GgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIx MjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9 YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2Q RdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/B CaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7Pb D8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs 6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJ ei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGt IYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2 LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5o dHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/D stU1gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTu IfJ1AuxSPtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23 NQIZz/U5RFhjpyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnY C8aEHwTG6x7on321e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIF hTCCBG2gAwIBAgIHGG3Jfo2QSjANBgkqhkiG9w0BAQsFADCBvzELMAkGA1UEBhMCREUxGzAZ BgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQK EyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVj aCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkB FgpjYUBraXQuZWR1MB4XDTE0MTAyNzEzNDMxMFoXDTE3MTAyNjEzNDMxMFowUzELMAkGA1UE BhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEYMBYG A1UEAxMPQW5kcmVhcyBMYWRhbnlpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tL0UuEE0MQWYP5MZOt+SBBDmGHZDf99xUzsFwyxvBaoS3TBZC/hul8ylNsOTrOvNbdJFOPTB izqfYQGf+JIxAgPomyG4jomQvMXhKXcf/obhf5lj2eBN0np/wLktMvFvj+HIEBh38/1o3ZXE SV4aMhvNW9VO116K0fh3/7TElksZ95zNj77js/JoEMQB8mGw27hw5u8VOKrDEWuzTBu4M7Vg MdzNrYi+m3AiYv1m110i6rJ4otbThGRfcEbDHwqfONfminidzyS4aHpNyO7U98xmn360m8qs q3smEn7XRGRgVlpzu7lNuJ8AvKZGPrM4OJ1Rhgxo5enuS1XVw29IBwIDAQABo4IB7zCCAesw QAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwIwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsG AQQBga0hgiwBAQQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRSBxcWWTqn7d35eE0sUlWSXfPOizAfBgNVHSMEGDAW gBQfdGX0mh169jHp32EbcysNbdAzSTAiBgNVHREEGzAZgRdhbmRyZWFzLmxhZGFueWlAa2l0 LmVkdTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2Ev cHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYB BQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDANBgkqhkiG9w0BAQsFAAOCAQEALmsJ+qKYuD1TTYxYAYcOUc7Pw3SBI+PX941ze1n2 coAeuXY2Ldd2lrjyirS8eHuPCZihmbVlMe/26WqBwDLN/vk7FC5c0aatidQz6MoquWJWnHSj 1XlB/AOv9aD4tKLHURw7ejFvY3imott/vrLJrt2WjYvPaMvwAoZKgTY2bXEZQjWYnGJRthuK 1OG4CFJlQphREiewuqzjCxABnC3Rmo7BWy/yGeMGSkMsTg+uhOwv8568KtJE3z4uTWtN1w0d T1uI1/uJ5jrsyoodUg/q31lGGgtrmElCwrHJSk+6Hp6KCXilzY9d/N/CQXkHnNLu6aDgc8gX n9Y/cLepRKKZvzCCBZQwggR8oAMCAQICBxev928jIukwDQYJKoZIhvcNAQELBQAwWjELMAkG A1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA4MzFaFw0xOTA3 MDkyMzU5MDBaMIG/MQswCQYDVQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJn MRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2Yg VGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5idWNoIENlbnRyZSBmb3IgQ29tcHV0aW5nMQ8w DQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEWCmNhQGtpdC5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDMsqiKiaKAQVEpL20dPB0IejTRPrajRK7mwwXpqBo/APNN 8IPtcb16pITtb5wQAaeVPvu8YA+bi5U3Dm/xeFBayQQcvUAp04cwm/nqhvveCMOpvC41qgiq K/ZSsDQlIre78zQDgndK9IjQmFdv8XCvLR0h8N5hl4L8H2NBfY9eJ1BIPZ3eZD6tAMPYkBw7 mJzs9wPDVU6V6Uws4kEwmSUGBEw7Avp8p0DdrLwJgFd1dRyUXvwA+oncv+hzdBLQCDj5RNac deDRUuEmalJPxeLw/KcUs/2FMGwhiuCB9+1fW3G0JgPDTTSgbRS6l9faL7kJ99pUcElvws9x 4/s0kT9zAgMBAAGjggH3MIIB8zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIB BjARBgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFB90ZfSaHXr2MenfYRtzKw1t0DNJMB8G A1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCmNhQGtpdC5lZHUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggr BgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNl cnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9i YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBADoW Jv/UVyB9nfsoym9xKp8a7sOLa4XSPU/xrKF4Dp3UdlKdzDK2JvzCziF50SiH54ZuKbsKUa6Y XwHiWHO7tsUW2+r6cnbf6FGcvylyeOtetQsoKvB2bMhEG0fn1B4+9k5IuXJpcQSHiKZhRa/l qNWO95hKHvhtUO8dlTYtlTaSEmv6RAcfw2JcYKiB2GC97h3YpwimDC15sfzwYdnhTdSXF54C VPgwHPL85cR/YI7KlQtjvI6yz14mma7ffYN6W7UBDPPc/5emiYIgxbwEBFZ5orfkvPtfeJUu T3FI7RBmE8mPl/betefdZzqF1F357emrpuGH9gZbJp98SgruQqgxggSCMIIEfgIBATCByzCB vzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJ S2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kx JzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lU LUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMAkGBSsOAwIaBQCgggKL MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyNTEyMTMy MFowIwYJKoZIhvcNAQkEMRYEFOSMEvhdC19sq9SujYVcADIWDROqMGwGCSqGSIb3DQEJDzFf MF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdwGCSsGAQQBgjcQ BDGBzjCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzES MBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRl Y2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0G A1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMIHeBgsq hkiG9w0BCRACCzGBzqCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0 dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1 dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+ jZBKMA0GCSqGSIb3DQEBAQUABIIBAHCvy3MJQwJv4ytYNcWdSE2HK101AQin1byPD/xSIFb3 eAE59BAieHCQ5aXP1oyT2OUl2SrWGuGr6qIO3Jqlo4BAhVucgV28JcTp0a9UQko2PNGDZMDG I1wI4Bz/cJ3dvY88cCDx0IiKqgdoW1JGecWCs7JuBdpuRkURJ6J8uL0qMWoa4hmoIvDA2lUL K6bjwj0bNONBuKp2/hZTqyHy+WL+ZyQO+7503wgTVeMokHvx+qQjdfqQuYXvYXYDSoLJzeur OotNvy9/p8DeFYtgv6FUlFIcNJot8h/1OvEeJMN+1j4HMYCK51Q8ZaSfSQpkralHPOyyeGJb vTTi4G9hIs0AAAAAAAA= --------------ms000002020102040506090207-- From ladanyi@ira.uka.de Mon Jun 22 14:15:48 2015 From: ladanyi@ira.uka.de (ladanyi@ira.uka.de) Date: Mon, 22 Jun 2015 15:15:48 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install Message-ID: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> This message is in MIME format. --=_FDbUEDiAoGHbe9w9GlDjuA1 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Stephan, >> >> I used this now, but an yum-builddep of this srpm package tells me that >> the package: kernel-devel-x86_64 =3D 2.6.18-404.el5 is needed but not >> found on centos 7. centos 7 ist working with 3.10. > > yum-builddep is looking at the wrong info when used on srpms. Install or > unpack the srpm and run "yum-builddep openafs.spec" instead. On Centos 7: yum-builddep openafs.spec works. rpmbuild -ba openafs.spec exits with 0. I got my rpm packages. On Fedora 20: I add a yum repository file which points to the 1.6.10 rpm Fedora 20 packages at openafs.org yum install produce the following output with some errors and bad exit: Running transaction Installing : openafs-1.6.10-2.fc20.x86_64 1/5 Installing : openafs-client-1.6.10-2.fc20.x86_64 2/5 Installing : dkms-openafs-1.6.10-2.fc20.x86_64 3/5 Error! DKMS tree already contains: openafs-1.6.10-2.fc20 You cannot add the same module/version combo more than once. Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area...(bad exit status: 2) ./configure --with-linux-kernel-headers=3D/lib/modules/3.19.8-100.fc20.x86_64/build --with-linux-kernel-packaging && make && case 3.19.8-100.fc20.x86_64 in 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv src/libafs/MODLOAD-*/openafs.ko . ;; esac....................................................(bad exit status: 2) Error! Bad return status for module build on kernel: 3.19.8-100.fc20.x86_64 (x86_64) Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more information. Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area...(bad exit status: 2) ./configure --with-linux-kernel-headers=3D/lib/modules/3.19.8-100.fc20.x86_64/build --with-linux-kernel-packaging && make && case 3.19.8-100.fc20.x86_64 in 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv src/libafs/MODLOAD-*/openafs.ko . ;; esac.....................................................(bad exit status: 2) Error! Bad return status for module build on kernel: 3.19.8-100.fc20.x86_64 (x86_64) Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more information. warning: %post(dkms-openafs-1.6.10-2.fc20.x86_64) scriptlet failed, exit status 10 Non-fatal POSTIN scriptlet failure in rpm package dkms-openafs-1.6.10-2.fc20.x86_64 Installing : openafs-docs-1.6.10-2.fc20.x86_64 4/5 Installing : openafs-krb5-1.6.10-2.fc20.x86_64 5/5 Verifying : openafs-docs-1.6.10-2.fc20.x86_64 1/5 Verifying : dkms-openafs-1.6.10-2.fc20.x86_64 2/5 Verifying : openafs-krb5-1.6.10-2.fc20.x86_64 3/5 Verifying : openafs-client-1.6.10-2.fc20.x86_64 4/5 Verifying : openafs-1.6.10-2.fc20.x86_64 5/5 Installed: dkms-openafs.x86_64 0:1.6.10-2.fc20 openafs.x86_64 0:1.6.10-2.fc20 openafs-client.x86_64 0:1.6.10-2.fc20 openafs-docs.x86_64 0:1.6.10-2.fc20 openafs-krb5.x86_64 0:1.6.10-2.fc20 Complete! The Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more information: CC [M] /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_cbqueue.o CC [M] /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_cell.o CC [M] /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_chunk.o CC [M] /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_conn.o CC [M] /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_daemons.o /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_daemons.c: In function =E2=80=98afs_CheckRootVolume=E2=80=99: /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_daemons.c:403:24: error: =E2=80=98struct dentry=E2=80=99 ha= s no member named =E2=80=98d_alias=E2=80=99 list_del_init(&dp->d_alias); ^ /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_daemons.c:404:19: error: =E2=80=98struct dentry=E2=80=99 ha= s no member named =E2=80=98d_alias=E2=80=99 list_add(&dp->d_alias, &(AFSTOV(vcp)->i_dentry)); ^ /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_daemons.c:404:7: warning: passing argument 2 of =E2=80=98li= st_add=E2=80=99 from incompatible pointer type [enabled by default] list_add(&dp->d_alias, &(AFSTOV(vcp)->i_dentry)); ^ In file included from include/linux/wait.h:6:0, from /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/afs/sysincludes.h:124, from /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc2= 0.x86_64-SP/afs_daemons.c:19: include/linux/list.h:61:20: note: expected =E2=80=98struct list_head *=E2= =80=99 but argument is of type =E2=80=98struct hlist_head *=E2=80=99 static inline void list_add(struct list_head *new, struct list_head *head= ) ^ make[4]: *** [/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.o] Error 1 make[3]: *** [_module_/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.= 8-100.fc20.x86_64-SP] Error 2 make[3]: Leaving directory `/usr/src/kernels/3.19.8-100.fc20.x86_64' FAILURE: make exit code 2 make[2]: *** [openafs.ko] Error 1 make[2]: Leaving directory `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP' make[1]: *** [linux_compdirs] Error 2 make[1]: Leaving directory `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs' make: *** [all] Error 2 > Best, Stephan regards, Andreas --=_FDbUEDiAoGHbe9w9GlDjuA1 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; size=5306; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP+jCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFhTCCBG2gAwIBAgIHGG3J fo2QSjANBgkqhkiG9w0BAQsFADCBvzELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0 dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRl IG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEP MA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1MB4XDTE0MTAyNzEzNDMx MFoXDTE3MTAyNjEzNDMxMFowUzELMAkGA1UEBhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0 aXR1dGUgb2YgVGVjaG5vbG9neTEYMBYGA1UEAxMPQW5kcmVhcyBMYWRhbnlpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtL0UuEE0MQWYP5MZOt+SBBDmGHZDf99xUzsFwyxvBaoS3TBZ C/hul8ylNsOTrOvNbdJFOPTBizqfYQGf+JIxAgPomyG4jomQvMXhKXcf/obhf5lj2eBN0np/wLkt MvFvj+HIEBh38/1o3ZXESV4aMhvNW9VO116K0fh3/7TElksZ95zNj77js/JoEMQB8mGw27hw5u8V OKrDEWuzTBu4M7VgMdzNrYi+m3AiYv1m110i6rJ4otbThGRfcEbDHwqfONfminidzyS4aHpNyO7U 98xmn360m8qsq3smEn7XRGRgVlpzu7lNuJ8AvKZGPrM4OJ1Rhgxo5enuS1XVw29IBwIDAQABo4IB 7zCCAeswQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwIwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRSBxcWWTqn7d35eE0sUlWSXfPOizAfBgNVHSMEGDAWgBQf dGX0mh169jHp32EbcysNbdAzSTAiBgNVHREEGzAZgRdhbmRyZWFzLmxhZGFueWlAa2l0LmVkdTB3 BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2EvcHViL2NybC9jYWNy bC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZu LmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAy LnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOC AQEALmsJ+qKYuD1TTYxYAYcOUc7Pw3SBI+PX941ze1n2coAeuXY2Ldd2lrjyirS8eHuPCZihmbVl Me/26WqBwDLN/vk7FC5c0aatidQz6MoquWJWnHSj1XlB/AOv9aD4tKLHURw7ejFvY3imott/vrLJ rt2WjYvPaMvwAoZKgTY2bXEZQjWYnGJRthuK1OG4CFJlQphREiewuqzjCxABnC3Rmo7BWy/yGeMG SkMsTg+uhOwv8568KtJE3z4uTWtN1w0dT1uI1/uJ5jrsyoodUg/q31lGGgtrmElCwrHJSk+6Hp6K CXilzY9d/N/CQXkHnNLu6aDgc8gXn9Y/cLepRKKZvzCCBZQwggR8oAMCAQICBxev928jIukwDQYJ KoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsT B0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUx NDA4MzFaFw0xOTA3MDkyMzU5MDBaMIG/MQswCQYDVQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3Vl cnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1 dGUgb2YgVGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5idWNoIENlbnRyZSBmb3IgQ29tcHV0aW5n MQ8wDQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEWCmNhQGtpdC5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDMsqiKiaKAQVEpL20dPB0IejTRPrajRK7mwwXpqBo/APNN8IPt cb16pITtb5wQAaeVPvu8YA+bi5U3Dm/xeFBayQQcvUAp04cwm/nqhvveCMOpvC41qgiqK/ZSsDQl Ire78zQDgndK9IjQmFdv8XCvLR0h8N5hl4L8H2NBfY9eJ1BIPZ3eZD6tAMPYkBw7mJzs9wPDVU6V 6Uws4kEwmSUGBEw7Avp8p0DdrLwJgFd1dRyUXvwA+oncv+hzdBLQCDj5RNacdeDRUuEmalJPxeLw /KcUs/2FMGwhiuCB9+1fW3G0JgPDTTSgbRS6l9faL7kJ99pUcElvws9x4/s0kT9zAgMBAAGjggH3 MIIB8zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjARBgNVHSAECjAIMAYGBFUd IAAwHQYDVR0OBBYEFB90ZfSaHXr2MenfYRtzKw1t0DNJMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7 Eyn38QpwPt5kMBUGA1UdEQQOMAyBCmNhQGtpdC5lZHUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5 hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3Js MIHXBggrBgEFBQcBAQSByjCBxzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9P Q1NQLVNlcnZlci9PQ1NQMEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQELBQADggEBADoWJv/UVyB9nfsoym9xKp8a7sOLa4XSPU/xrKF4Dp3UdlKdzDK2JvzCziF50SiH 54ZuKbsKUa6YXwHiWHO7tsUW2+r6cnbf6FGcvylyeOtetQsoKvB2bMhEG0fn1B4+9k5IuXJpcQSH iKZhRa/lqNWO95hKHvhtUO8dlTYtlTaSEmv6RAcfw2JcYKiB2GC97h3YpwimDC15sfzwYdnhTdSX F54CVPgwHPL85cR/YI7KlQtjvI6yz14mma7ffYN6W7UBDPPc/5emiYIgxbwEBFZ5orfkvPtfeJUu T3FI7RBmE8mPl/betefdZzqF1F357emrpuGH9gZbJp98SgruQqgxggSCMIIEfgIBATCByzCBvzEL MAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNy dWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsT HlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZI hvcNAQkBFgpjYUBraXQuZWR1AgcYbcl+jZBKMAkGBSsOAwIaBQCgggKLMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyMjEyNTgyN1owIwYJKoZIhvcNAQkEMRYE FMgAQbdZR67/gwbxa89DhhxcaQ/EMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgdwGCSsGAQQBgjcQBDGBzjCByzCBvzELMAkGA1UEBhMCREUxGzAZ BgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFL YXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50 cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQu ZWR1AgcYbcl+jZBKMIHeBgsqhkiG9w0BCRACCzGBzqCByzCBvzELMAkGA1UEBhMCREUxGzAZBgNV BAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhlMSowKAYDVQQKEyFLYXJs c3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0ZWluYnVjaCBDZW50cmUg Zm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcNAQkBFgpjYUBraXQuZWR1 AgcYbcl+jZBKMA0GCSqGSIb3DQEBAQUABIIBAHBQL58jUjGSAf5oKYL8EPrab6agtSz5Q38SvrvE isR3ndjoemEeqbDdwFgBuKDB7PRw+BxxGVw36W4XRe13E/fEpQF18HyqwxjdN8NLiPOIIN7Bohfy dwuzqqtokNNlQGL75HeM/QP+TYlk6OkWfZlbi3Cu9L4SwCdWZ+d/g+2wHCsFLnT5zciaz41VUx8u POrB6UE1tqxTZtg73PShz3hrtG/6F9A2v1tcj4BZfp98S2GS+PbmHLe7237AWmsHpPxYRvSsKPNJ mo/3QD6wxdv2tbKoQP4bsdTa6qBSztgxE4j40fQyGJVKuz8YeJtoX92AWu6cbUv7FOMiAVzKV9gA AAAAAAA= --=_FDbUEDiAoGHbe9w9GlDjuA1-- From bertrand.noel.88@gmail.com Fri Jun 26 10:20:24 2015 From: bertrand.noel.88@gmail.com (Bertrand NOEL) Date: Fri, 26 Jun 2015 11:20:24 +0200 Subject: [OpenAFS] OpenAFS client in LXC containers Message-ID: --14dae9cc9c7e2e40ba051968414e Content-Type: text/plain; charset=UTF-8 Hello, I am working on using OpenAFS client in LXC containers. I managed to have OpenAFS client work in one LXC container. I went with loading the kernel module on host, and installing OpenAFS client on container. Here is detailed info on what I did: - I installed OpenAFS kernel module on host (CentOS 7.1) / kmod-openafs v1.6.9 - I create a CentOS 7.1 LXC container, - and install OpenAFS client in this container (openafs-client openafs-krb5 krb5-workstation) - systemd script to start openafs-client does not fit because it tries to load the kernel module, which is not possible by default in my container. So I start by myself afsd service (/usr/vice/etc/afsd) - It's working fine, and I can access AFS shares I have 2 problems: 1) When I terminate my container, and create a new one, and do the exact same procedure, starting afsd gets stuck when trying to fork background processes. I can see that these processes go into zombie state. 2) When I keep my container, and create a second one along, and do the same installation. Starting afsd fails with the following error: afsd: Error calling AFSOP_CACHEINODE: not configured I have seen that it comes when trying to run multiple openafs client on the same machine. Which is what I am trying to do, but I was expecting that it would work in containers, because afsd is a userspace process, and containers are namespaced. Bertrand --14dae9cc9c7e2e40ba051968414e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
I am working on using OpenAFS client in LXC con= tainers.


I managed to have OpenAFS = client work in one LXC container. I went with loading the kernel module on = host, and installing=C2=A0OpenAFS=C2=A0client on container.
Here = is detailed info on what I did:
- I installed OpenAFS kernel modu= le on host (CentOS 7.1) / kmod-openafs v1.6.9
- I create a CentOS= 7.1 LXC container,
- and install OpenAFS client in this containe= r (openafs-client=C2=A0openafs-krb5=C2=A0krb5-workstation)
- syst= emd script to start openafs-client does not fit because it tries to load th= e kernel module, which is not possible by default in my container. So I sta= rt by myself afsd service (/usr/vice/etc/afsd)
- It's working= fine, and I can access AFS shares


= I have 2 problems:

1) When I terminate my containe= r, and create a new one, and do the exact same procedure, starting afsd get= s stuck when trying to fork background processes. I can see that these proc= esses go into zombie state.

2) When I keep my cont= ainer, and create a second one along, and do the same installation. Startin= g afsd fails with the following error:
afsd: Error calling AFSOP_= CACHEINODE: not configured
I have seen that it comes when try= ing to run multiple openafs client on the same machine. Which is what I am = trying to do, but I was expecting that it would work in containers, because= afsd is a userspace process, and containers are namespaced.

=

Bertrand

--14dae9cc9c7e2e40ba051968414e-- From cg2v@andrew.cmu.edu Mon Jun 29 17:31:09 2015 From: cg2v@andrew.cmu.edu (Chaskiel Grundman) Date: Mon, 29 Jun 2015 12:31:09 -0400 Subject: [OpenAFS] OpenAFS client in LXC containers In-Reply-To: References: Message-ID: > afsd is a userspace process, and Not quite true... afsd used to provide a process context for kernel threads to run in, but doesn't even do that anymore. The only userspace part of afsd is the DNS lookup mechanism. > containers are namespaced. If only that were completely true.... In any event, depending on your actual end goal, there's an easy answer to this: run openafs on the host, and put an afs entry in lxc.mount.entry: lxc.mount.entry = /afs /var/lib/lxc//rootfs/afs none defaults,bind 0 0 Then install openafs-client in your container, but *don't* enable or run the startup script. fs commands and authentication will work transparently. The only disadvantage to this that I can see is that the the host and the host's networking will be used to make afs requests, and so if the host is not on the network, or you need to be able to identify which guest is making which requests, then this won't work. From andreas.ladanyi@kit.edu Mon Jun 29 18:20:48 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Mon, 29 Jun 2015 19:20:48 +0200 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <558BF060.7010401@kit.edu> References: <558BC391.4080404@kit.edu> <558BE736.9010001@your-file-system.com> <558BF060.7010401@kit.edu> Message-ID: <55917E70.2050505@kit.edu> Hi, ok, the problem isnt gone. If i start the bos server: /usr/afs/bin/bosserver -noauth & bos status tells me the instances are running normally. If i start the openafs-server with the systemd scripts: ================================= enafs-server.service - OpenAFS Server Service Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; enabled) Active: active (running) since Mon 2015-06-29 18:58:56 CEST; 1min 37s ago Process: 3481 ExecStop=/usr/bin/bos shutdown localhost -wait -localauth (code=exited, status=0/SUCCESS) Main PID: 3490 (bosserver) CGroup: /system.slice/openafs-server.service └─3490 /usr/afs/bin/bosserver -nofork Jun 29 18:58:56 i44fs1.info.uni-karlsruhe.de systemd[1]: Starting OpenAFS Server Service... Jun 29 18:58:56 i44fs1.info.uni-karlsruhe.de systemd[1]: Started OpenAFS Server Service. But bos status tells me: =============== Instance vlserver, temporarily disabled, stopped for too many errors, currently starting up. Instance ptserver, temporarily disabled, stopped for too many errors, currently starting up. Instance dafs, temporarily disabled, stopped for too many errors, currently shutdown. Auxiliary status is: file server shut down. I get the PtLog and VLLog error messages with the ubik errors: PtLog: ==== ptserver: file not found when processing dbase Ubik init failed ptserver: running unauthenticated VLLog: ===== vlserver: Ubik init failed: file not found when processing dbase Andy > Hi Jeffrey, > > i use the description OpenAFS Quick Start Guide for Unix. At this time > i have done the steps at > http://docs.openafs.org/QuickStartUnix/index.html#HDRWQ52.html > > I tried to start the bos server with the systemd script. I think at this > state it wasnt a good idea. >> On 6/25/2015 5:02 AM, Andreas Ladanyi wrote: >> >>> PtLog: >>> ==== >>> >>> ptserver: file not found when processing dbase Ubik init failed >>> ptserver: running unauthenticated >>> >>> VLLog: >>> ===== >>> >>> vlserver: Ubik init failed: file not found when processing dbase >>> >> The database file cannot be created or opened. >> >> How was OpenAFS installed and on which OS/version? > with the openafs srpm package from the openafs website. I built my own > binary rpms from this srpm package and installed it. The OS is centos 7. >> Jeffrey Altman >> >> >> > From stephan.wiesand@desy.de Mon Jun 29 19:36:27 2015 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Mon, 29 Jun 2015 20:36:27 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> References: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> Message-ID: <451554A1-D19A-45DC-AC2C-997B065C3B50@desy.de> On Jun 22, 2015, at 15:15 , ladanyi@ira.uka.de wrote: >>> I used this now, but an yum-builddep of this srpm package tells me = that >>> the package: kernel-devel-x86_64 =3D 2.6.18-404.el5 is needed but = not >>> found on centos 7. centos 7 ist working with 3.10. >>=20 >> yum-builddep is looking at the wrong info when used on srpms. Install = or >> unpack the srpm and run "yum-builddep openafs.spec" instead. >=20 > On Centos 7: > yum-builddep openafs.spec works. > rpmbuild -ba openafs.spec exits with 0. I got my rpm packages. >=20 > On Fedora 20: > I add a yum repository file which points to the 1.6.10 rpm Fedora 20 = packages at openafs.org >=20 > yum install produce the following output with some errors and bad = exit: Once again: 1.6.10 is too old for the latest F20 kernels. It's not going = to work. Do what you did on EL7 but use at least 1.6.11 (and preferably 1.6.12 = which was released last friday). =20 Best, Stephan > Running transaction > Installing : openafs-1.6.10-2.fc20.x86_64 = = 1/5 > Installing : openafs-client-1.6.10-2.fc20.x86_64 = = 2/5 > Installing : dkms-openafs-1.6.10-2.fc20.x86_64 = = 3/5 > Error! DKMS tree already contains: openafs-1.6.10-2.fc20 > You cannot add the same module/version combo more than once. >=20 > Kernel preparation unnecessary for this kernel. Skipping... >=20 > Building module: > cleaning build area...(bad exit status: 2) > ./configure = --with-linux-kernel-headers=3D/lib/modules/3.19.8-100.fc20.x86_64/build = --with-linux-kernel-packaging && make && case 3.19.8-100.fc20.x86_64 in = 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv = src/libafs/MODLOAD-*/openafs.ko . ;; = esac....................................................(bad exit = status: 2) > Error! Bad return status for module build on kernel: = 3.19.8-100.fc20.x86_64 (x86_64) > Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more = information. >=20 > Kernel preparation unnecessary for this kernel. Skipping... >=20 > Building module: > cleaning build area...(bad exit status: 2) > ./configure = --with-linux-kernel-headers=3D/lib/modules/3.19.8-100.fc20.x86_64/build = --with-linux-kernel-packaging && make && case 3.19.8-100.fc20.x86_64 in = 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv = src/libafs/MODLOAD-*/openafs.ko . ;; = esac.....................................................(bad exit = status: 2) > Error! Bad return status for module build on kernel: = 3.19.8-100.fc20.x86_64 (x86_64) > Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more = information. > warning: %post(dkms-openafs-1.6.10-2.fc20.x86_64) scriptlet failed, = exit status 10 > Non-fatal POSTIN scriptlet failure in rpm package = dkms-openafs-1.6.10-2.fc20.x86_64 > Installing : openafs-docs-1.6.10-2.fc20.x86_64 = = 4/5 > Installing : openafs-krb5-1.6.10-2.fc20.x86_64 = = 5/5 > Verifying : openafs-docs-1.6.10-2.fc20.x86_64 = = 1/5 > Verifying : dkms-openafs-1.6.10-2.fc20.x86_64 = = 2/5 > Verifying : openafs-krb5-1.6.10-2.fc20.x86_64 = = 3/5 > Verifying : openafs-client-1.6.10-2.fc20.x86_64 = = 4/5 > Verifying : openafs-1.6.10-2.fc20.x86_64 = = 5/5 >=20 > Installed: > dkms-openafs.x86_64 0:1.6.10-2.fc20 openafs.x86_64 0:1.6.10-2.fc20 = openafs-client.x86_64 0:1.6.10-2.fc20 openafs-docs.x86_64 = 0:1.6.10-2.fc20 openafs-krb5.x86_64 0:1.6.10-2.fc20 >=20 > Complete! >=20 >=20 >=20 > The Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for = more information: >=20 > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_cbqueue.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_cell.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_chunk.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_conn.o > CC [M] = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.o > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c: In function =91afs_CheckRootVolume=92: > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:403:24: error: =91struct dentry=92 has no = member named =91d_alias=92 > list_del_init(&dp->d_alias); > ^ > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:404:19: error: =91struct dentry=92 has no = member named =91d_alias=92 > list_add(&dp->d_alias, &(AFSTOV(vcp)->i_dentry)); > ^ > = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:404:7: warning: passing argument 2 of = =91list_add=92 from incompatible pointer type [enabled by default] > list_add(&dp->d_alias, &(AFSTOV(vcp)->i_dentry)); > ^ > In file included from include/linux/wait.h:6:0, > from = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/afs/sysincludes.h:124, > from = /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc= 20.x86_64-SP/afs_daemons.c:19: > include/linux/list.h:61:20: note: expected =91struct list_head *=92 = but argument is of type =91struct hlist_head *=92 > static inline void list_add(struct list_head *new, struct list_head = *head) > ^ > make[4]: *** = [/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.f= c20.x86_64-SP/afs_daemons.o] Error 1 > make[3]: *** = [_module_/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19= .8-100.fc20.x86_64-SP] Error 2 > make[3]: Leaving directory `/usr/src/kernels/3.19.8-100.fc20.x86_64' > FAILURE: make exit code 2 > make[2]: *** [openafs.ko] Error 1 > make[2]: Leaving directory = `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.f= c20.x86_64-SP' > make[1]: *** [linux_compdirs] Error 2 > make[1]: Leaving directory = `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs' > make: *** [all] Error 2 >=20 >=20 >> Best, Stephan >=20 > regards, > Andreas >=20 > --=20 Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From stephan.wiesand@desy.de Mon Jun 29 19:40:01 2015 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Mon, 29 Jun 2015 20:40:01 +0200 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <55917E70.2050505@kit.edu> References: <558BC391.4080404@kit.edu> <558BE736.9010001@your-file-system.com> <558BF060.7010401@kit.edu> <55917E70.2050505@kit.edu> Message-ID: <09AB8C9B-1365-491A-B492-69644BB77FEF@desy.de> Please answer Jeffrey's questions, and we may be able to help. = Alternatively, trust in my intuition and grep my previous mails for = "SELinux". Stephan On Jun 29, 2015, at 19:20 , Andreas Ladanyi wrote: > Hi, >=20 > ok, the problem isnt gone. >=20 > If i start the bos server: >=20 > /usr/afs/bin/bosserver -noauth & >=20 > bos status tells me the instances are running normally. >=20 >=20 > If i start the openafs-server with the systemd scripts: > =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 > enafs-server.service - OpenAFS Server Service > Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; = enabled) > Active: active (running) since Mon 2015-06-29 18:58:56 CEST; 1min = 37s ago > Process: 3481 ExecStop=3D/usr/bin/bos shutdown localhost -wait = -localauth (code=3Dexited, status=3D0/SUCCESS) > Main PID: 3490 (bosserver) > CGroup: /system.slice/openafs-server.service > =E2=94=94=E2=94=803490 /usr/afs/bin/bosserver -nofork >=20 > Jun 29 18:58:56 i44fs1.info.uni-karlsruhe.de systemd[1]: Starting = OpenAFS Server Service... > Jun 29 18:58:56 i44fs1.info.uni-karlsruhe.de systemd[1]: Started = OpenAFS Server Service. >=20 >=20 > But bos status tells me: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Instance vlserver, temporarily disabled, stopped for too many errors, = currently starting up. > Instance ptserver, temporarily disabled, stopped for too many errors, = currently starting up. > Instance dafs, temporarily disabled, stopped for too many errors, = currently shutdown. > Auxiliary status is: file server shut down. >=20 >=20 > I get the PtLog and VLLog error messages with the ubik errors: >=20 > PtLog: > =3D=3D=3D=3D >=20 > ptserver: file not found when processing dbase Ubik init failed > ptserver: running unauthenticated >=20 >=20 > VLLog: > =3D=3D=3D=3D=3D >=20 > vlserver: Ubik init failed: file not found when processing dbase >=20 >=20 >=20 > Andy >=20 >=20 >=20 >> Hi Jeffrey, >>=20 >> i use the description OpenAFS Quick Start Guide for Unix. At this = time >> i have done the steps at >> http://docs.openafs.org/QuickStartUnix/index.html#HDRWQ52.html >>=20 >> I tried to start the bos server with the systemd script. I think at = this >> state it wasnt a good idea. >>> On 6/25/2015 5:02 AM, Andreas Ladanyi wrote: >>>=20 >>>> PtLog: >>>> =3D=3D=3D=3D >>>>=20 >>>> ptserver: file not found when processing dbase Ubik init failed >>>> ptserver: running unauthenticated >>>>=20 >>>> VLLog: >>>> =3D=3D=3D=3D=3D >>>>=20 >>>> vlserver: Ubik init failed: file not found when processing dbase >>>>=20 >>> The database file cannot be created or opened. >>>=20 >>> How was OpenAFS installed and on which OS/version? >> with the openafs srpm package from the openafs website. I built my = own >> binary rpms from this srpm package and installed it. The OS is centos = 7. >>> Jeffrey Altman --=20 Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From andreas.ladanyi@kit.edu Mon Jun 29 20:17:12 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Mon, 29 Jun 2015 21:17:12 +0200 Subject: [OpenAFS] bos server instances doesnt come up In-Reply-To: <09AB8C9B-1365-491A-B492-69644BB77FEF@desy.de> References: <558BC391.4080404@kit.edu> <558BE736.9010001@your-file-system.com> <558BF060.7010401@kit.edu> <55917E70.2050505@kit.edu> <09AB8C9B-1365-491A-B492-69644BB77FEF@desy.de> Message-ID: <559199B8.2040308@kit.edu> > Please answer Jeffrey's questions, and we may be able to help. I answered Jeffreys questions: > How was OpenAFS installed and on which OS/version? I use the openafs 1.6.11.1 srpm package from the openafs website. I built my own binary rpms from this srpm package and installed it. The OS is centos 7. > Alternatively, trust in my intuition and grep my previous mails for "SELinux". I trust you and this problem is solved by setting SELinux=permissive. Iam crying. Thanks a lot, Andy From andreas.ladanyi@kit.edu Mon Jun 29 20:23:15 2015 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Mon, 29 Jun 2015 21:23:15 +0200 Subject: [OpenAFS] Uninstall OpenAFS after make install In-Reply-To: <451554A1-D19A-45DC-AC2C-997B065C3B50@desy.de> References: <20150622151548.Horde.nGDhOieU6YgcY8XVE7n8SA2@webmail.informatik.kit.edu> <451554A1-D19A-45DC-AC2C-997B065C3B50@desy.de> Message-ID: <55919B23.4030006@kit.edu> >> On Centos 7: >> yum-builddep openafs.spec works. >> rpmbuild -ba openafs.spec exits with 0. I got my rpm packages. >> >> On Fedora 20: >> I add a yum repository file which points to the 1.6.10 rpm Fedora 20 packages at openafs.org >> >> yum install produce the following output with some errors and bad exit: > Once again: 1.6.10 is too old for the latest F20 kernels. It's not going to work. > > Do what you did on EL7 but use at least 1.6.11 (and preferably 1.6.12 which was released last friday). The problem was solved in the past. All is fine :-) Thank you, Andy > > Best, > Stephan > From semanticphilosopher@gmail.com Tue Jun 30 08:33:53 2015 From: semanticphilosopher@gmail.com (Neil Davies) Date: Tue, 30 Jun 2015 08:33:53 +0100 Subject: [OpenAFS] OpenAFS client in LXC containers In-Reply-To: References: Message-ID: <9F1492B6-21A7-4F7A-8F61-9403530376CA@gmail.com> This approach has worked fine for us for several years now. Note there is an isolation issue - if you grab tokens for UID 1000 = inside a container A, then all UID 1000 in all the other containers have tokens. You can run processes within PAG within the container, but sometimes = (for certain daemon process scenarios) that doesn=92t quite cut it. On 29 Jun 2015, at 17:31, Chaskiel Grundman wrote: >> afsd is a userspace process, and > Not quite true... afsd used to provide a process context for kernel > threads to run in, but doesn't even do that anymore. The only = userspace > part of afsd is the DNS lookup mechanism. >=20 >> containers are namespaced. > If only that were completely true.... >=20 >=20 > In any event, depending on your actual end goal, there's an easy = answer to > this: run openafs on the host, and put an afs entry in = lxc.mount.entry: >=20 > lxc.mount.entry =3D /afs /var/lib/lxc//rootfs/afs none = defaults,bind 0 0 >=20 > Then install openafs-client in your container, but *don't* enable or > run the startup script. fs commands and authentication will work > transparently. >=20 > The only disadvantage to this that I can see is that the the host and = the > host's networking will be used to make afs requests, and so if the = host > is not on the network, or you need to be able to identify which guest = is > making which requests, then this won't work. >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info