Latest is 1.3.64(>=2.5 kernel support added), latest stable is 1.2.11 (only <=2.4 kernels supported). Can we bump this? Last time it was touched was April 28th by agriffis.
I have just compiled successfully openafs-snap-2004-06-12 against the development-sources-2.6.6. I am running client only but so far it has been working without a problem. Did not seem to work with gentoo-dev-sources-2.6.5-r1 though
Well I got openafs-1.3.71 to build with 2.6.8-gentoo-r3, but only without an ebuild. It seems that portage exports the ARCH env var, which screws up one of the makefiles (using x86 instead of i386). I don't know if it actually RUNS though (plus it does generate warnings). I think I'll give it another shot.
The initscripts don't seem to like the new versions. You'll need to check for .ko vs. .o files and the ksyms thing. I was able to get the client running with two commands (keep in mind I already had it configured from when I was using openafs 1.2.x and linux 2.4.x). # insmod /usr/vice/etc/modload/libafs-2.6.8-gentoo-r3.ko # afsd That seems to load it. # umount /afs # rmmod libafs That seems to unload it. http://www.coe.uncc.edu/~danderse/www/openafs-1.3.71.ebuild That's the ebuild I used. I actually put it on that web site using openafs-1.3.71. Some of the lines changed include: env -u ARCH make CC="$(gcc-getCC)" MT_CC="$(gcc-getCC)" || die make local sys_name=$(sed -n 's/s%@AFS_SYSNAME@%\(.*\)%g/\1/p' config.status) || die sys_name env -u ARCH make dest || die dest Failing to unset ARCH screws it up.
The ebuild above works for 1.3.73 also.
Created attachment 43760 [details] Ebuild for OpenAFS 1.3.74 This ebuild fixes OpenAFS's use flags, fixes all but pam_afs.krb.so.1 not being built PIC, and actually builds OpenAFS on linux 2.6. Unfortunately, pam_afs.krb.so.1 pulls in archives from directories used to build executables and I don't know whether the Gentoo policy on no PIC executables (unless PIEs are needed for grsecurity and the like) overrides PIC libs in this case. I favored no PIC executables unless the user manually adds -fPIC to the CFLAGS in this case.
Created attachment 43762 [details, diff] Fix for PIC issue in previous ebuild Sorry about the quick update -- but after getting the PIC policy explained to me, I realized that I should post an update on this one. This makes everything in OpenAFS get built with -fPIC.
Also, to use this you will need to add =net-fs/openafs-1.3* to your /etc/portage/package.unmask until that gets removed from /usr/portage/profile/package.mask.
Created attachment 43900 [details] Final update to 1.3.74 ebuild Well, thanks to some suggestions from SpanKY, there's a fix in here for an absolute symlink that should have been absolute and the env.d file should now be shipped as a ${FILESDIR} file instead of dynamically created.
Created attachment 43901 [details] Accompanying file for files/ dir for 1.3.74 ebuild
It's not clear based on the comments here whether this ebuild works on one or some or all architectures. The ebuild itself has keywords indicating support for ppc, but my experience is that without some patches to the 1.3.74 sources, it won't compile for sysname ppc_linux26. I assembled some diffs for doing that: http://www.gnosys.us/openafs-ppc_linux26.ebuild.tar.gz HTH. As a related comment/question, has anyone working on this issue done any work on getting MIT Kerberos 5 integrated with OpenAFS in Gentoo? Code does exist for doing this (see ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/afs-krb5-2.0.tar.gz), but I'm having real difficulty building it. I did it once for x86 architecture, but can't seem to reproduce those results on ppc right now. It's worth noting that if anyone tries building those sources, I was only able to get aklog and asetkey to build. The rest of the make failed (it's rather out of date I think). But I think that aklog is all that's really needed; perhaps asetkey also. aklog does the job of obtaining AFS tokens based upon pre-existing Kerberos tickets. It would be really, REALLY nice if, just like I do for MIT Kerberos 5 on Gentoo, I could just emerge openafs AND some sort of mitkrb5-openafs ebuild that accomplished the integration. I think pretty much everyone is moving or has moved away from OpenAFS as a source of authentication in favor of Kerberos (perhaps either MIT or Heimdal), and having an aklog executable is key for this.
Sorry for the double-post. Mike Frysinger says that AD Rutledge is the person to talk to about this stuff. If you would like some help with this I'd be glad to be a part of it. I've been administering MIT Kerberos on x86 (Linux and Windows) for about a year and a half as well as OpenAFS since February on x86 (SuSE and Gentoo) and just now started doing so with ppc_linux too.
We just moved to openafs-1.3.77 on our Opteron SLES9 systems, and it is working likea charm. We had issues with 1.3.74 on 64-bit platforms, but so far 1.3.77 has worked great for us. Might want to give it a try (or check for newer... right before christmas they rolled 3 or 4 versions in a week)
This ebuild fails to compile with 2.6.10. The problem has been discussed on the openafs mailing list (https://lists.openafs.org/pipermail/openafs-info/2004-November/015448.html), but without resolution.
Can we please get a time estimate on when this updated ebuild will be commited to Portage? It's quite frustrating to see OpenAFS sitting here in neglect; are more maintainers needed for this package?
bump
See bug #82075
OpenAFS needs a developer to take up maintenance.
Per question #11 from Kevin: afs-krb5 is for openafs + MIT KRB5 integrations. There are some issues with aklog not working well. See openafs-devel list for more info. It's a lot easier to use heimdal with openafs. The kerberos5 support is fine and kauth(1) available with heimdal is all one actually needs.
Although the 1.3.74 openafs is too old and definitely uninterreting, I'd not something about the ebuild 2004-11-13 19:41 PDT as it has some design problems: SHLIB_CFLAGS="-fPIC" econf \ --prefix=/usr/afsws/ \ --enable-transarc-paths \ --enable-namei-fileserver \ --enable-largefile-fileserver \ $(use_enable pam) \ $(use_enable debug) || die econf ./configure should be instead of econf because econf enforces --prefix --with-info-path --with-man-path etc. /usr/afsws was historically used _just_ as a repository of AFS binaries and sources. It typically contained root.client/, root.server, include/, lib/, man/, bin/ if I rememeber right. I would have to look into the original IBM AFS documentation hanging at www.openafs.org. all theirs thick manual have somewhere in the beginning description of the distribution layout. What is important that /usr/afs/bin/bosserver is a better/faster replacement to inetd daemon, used to control other afs related daemons (running on the AFS server" machines). There are command switches of them to for example fetch AFS logfiles from any remote AFS server (if you have the right afs token), you can restart remotely those daemons, you can shutdown the daemons, run fsck on some partition and fire the daemons up again ... you can upgrade afs binaries. Yes, it reads the data from /usr/afsws and overwrites binaries on remote server. Therefore, don't think you can shuffle binaries around and place whatever you think under /usr/afsws. openafs should be installed into the transarc paths (/usr/afs/, /usr/afsws, /usr/vice) and that should not be an option, but imperative. Otherwise, expect even bugreport like - I cannot fetch BosLog, SalvagerLog from remote server. The trick with unsetting ARCH variable was recently still a must to get openafs compiled under gentoo, so keep in mind this for future: env -u ARCH make CC="$(gcc-getCC)" MT_CC="$(gcc-getCC)" || die make
New ebuilds for openafs 1.2.13 (stable) and 1.3.85 (experimental) are available for testing. According to openafs-ml, 1.3.85 is currently undergoing testing so it can become 1.4rc. The provided 1.3.85 ebuild is supposed to give the support for openafs on 2.6 kernels, as asked in this bug report. It'd be great if this ebuild could be tested.
Testing ebuild that supports linux 2.6 on several architectures is now in portage. It will remain marked as "testing" until normal rules for keywording as stable apply.
