This has been stagnating in an OpenAFS bug report for quite a while, it needs to be added to the tree. See the attached.
Created attachment 51256 [details] openafs-1.3.77.ebuild
Created attachment 52791 [details, diff] showcase of the rc-script deficiencies showing when trying to use 2.6 kernels or ext3 Are we supposed to use the afs initscript already in the tree (for kernel 2.4)? It doesn't work for me, not in the least because modules for linux 2.6 have a .ko extension, and also because I use ext3 instead of ext2, which is unrecognized as valid by the script. I've attached a diff, but only as indication where I think the problems are. This is in no way at all an attempt for a clean fix. This seems a showstopper for me, as the most important reason I see to upgrade to openafs 1.3.x is linux 2.6 support.
Hi, I'd like to help bring this forward to 2.6 kernels... but don't really know where to start. In my specific case, I'd also like to help bring support for amd64. I figure the way to start is to attempt... so based on your 1.3.77 ebuild I run into problems. I think the problem is likely related the the machine architecture needing to be specified, probably the variable sys_name in the ebuild. But I don't know how to change it or what it should become. Suggestions would be appreciated. root@mymachine afs # /etc/init.d/afs start * Starting AFS services... /sbin/runscript.sh: line 304: /usr/vice/etc/modload/libafs-2.6.9-gentoo-r14.ko: Permission denied root@mymachine afs # /etc/init.d/afs stop * Stopping AFS services... umount: /afs: not mounted root@mymachine afs # ls -l /usr/vice/etc/modload/libafs-2.6.9-gentoo-r14.ko -rw-r--r-- 1 root root 795022 Mar 25 10:47 /usr/vice/etc/modload/libafs-2.6.9-gentoo-r14.ko root@mymachine afs # chmod 777 /usr/vice/etc/modload/libafs-2.6.9-gentoo-r14.ko root@mymachine afs # /etc/init.d/afs start * Starting AFS services... /sbin/runscript.sh: line 304: /usr/vice/etc/modload/libafs-2.6.9-gentoo-r14.ko: cannot execute binary file root@mymachine afs # /etc/init.d/afs stop * Stopping AFS services... umount: /afs: not mounted root@mymachine afs # insmod /usr/vice/etc/modload/libafs-2.6.9-gentoo-r14.ko [At this point it locks and I have to Control-C my way out.]
Created attachment 55560 [details] Updated ebuild Newer versions of openafs-1.3 seem broken when it comes to building the kernel module. This ebuild compiles without problems for me.
Created attachment 55561 [details] Init-script for both (2.4/2.6) kernels. This init-script fixes the issues with 2.6 kernels as stated above. It works with both (2.4 and 2.6) kernel series. It's rather messy scripted but works for the time being. Is anybody working on bringing openafs-1.3 to the portage tree? Openafs in Gentoo seems quite broken for some time. I would like to have proper openafs support in Gentoo and I'm willing to help.
Created attachment 57711 [details] New ebuilds and rc-scripts for OpenAFS I have worked to get OpenAFS (which seemed very broken) working on Gentoo. I incorporated some work found here in bugzilla, but completely rewrited the rc-script. I have chosen to split-up the kernel module from the rest. People who upgrade their kernel can easily get openAFS working again.
This is not an enhancement, this is a bug. The version of OpenAFS in the portage tree will not compile with a 2.6 kernel, and Linux 2.6.11 is the kernel in the stable gentoo-sources package. It looks like an ebuild and rc-scripts have been made. Please integrate OpenAFS 1.3.82 into the portage tree.
Two remarks on this ebuild: firstly: $ lsmod | grep libafs libafs 585568 3 $ ls /usr/vice/etc/modload libafs-2.6.11-gentoo-r8.mp.ko => init-script uses first for "stop" (with rmmod), second for "start" (insmod), which is all correct. But when using restart it reuses $LIBAFS detected during stop for start, thus failing to reload the kernel module Secondly, I don't think it's really clean to overwrite the configuration (ThisCell, CellServDB) every time openafs is upgraded, maybe a "doenvd" could be handy? Slightly tweaked previously existing script: CONFIG_PROTECT="/usr/vice/etc" PATH=/usr/afsws/bin ROOTPATH=/usr/afsws/bin:/usr/afs/bin Unfortunately, with this I get errors like: Automerging trivial changes in: CellServDB mv: `/etc/afs/._cfg0000_CellServDB' and `/etc/afs/CellServDB' are the same file (trying to merge soft-links) which I don't know directly how to fix
Created attachment 60772 [details] Version bump and other changes to ebuild I liked the 1.3.82 overlays as they were pretty clean compared with some of the other ebuilds out there, but they were lacking some things that I needed. So these ebuilds are more than just a version bump, I've added some additional flexability: * will now install client binaries and libraries * updated to use the toolchain-funcs eclass instead of gcc eclass * uses the pam eclass to handle pam module installation * added a doc flag to install man pages * added a transarc-paths use flag if you prefer to keep the old style installation paths. Otherwise the default installation paths are used. * changed the krb5 use flag to krb4, because that's what it actually is.
openafs-kernel-1.3.84 collides with com_err, which is a requirement of e2fsprogs. >>> extracting openafs-kernel-1.3.84 * checking 37 files for package collisions existing file /usr/bin/compile_et is not owned by this package * spent 0.0047070980072 seconds checking for file collision ~ # equery belongs /usr/bin/compile_et [ Searching for file(s) /usr/bin/compile_et in *... ] sys-libs/com_err-1.37 (/usr/bin/compile_et) ~ # equery depends com_err [ Searching for packages depending on com_err... ] sys-fs/e2fsprogs-1.37-r1
openafs-1.3.84 collides with com_err and mit-krb5. >>> extracting openafs-1.3.84 * checking 380 files for package collisions existing file /usr/bin/compile_et is not owned by this package existing file /usr/bin/kpasswd is not owned by this package existing file /usr/share/man/man1/kpasswd.1.gz is not owned by this package * spent 0.0510401725769 seconds checking for file collisions ~ # equery belongs /usr/bin/kpasswd [ Searching for file(s) /usr/bin/kpasswd in *... ] app-crypt/mit-krb5-1.4-r1 (/usr/bin/kpasswd) USE flags for openafs are: -debug +doc -krb4 +pam -transarc-paths
Why is the openafs-kernel ebuild polluted with echo's? Are those debug statements? Why on earth do people need the development files of openafs?? Does anything usefull depend on it??
OpenAFS needs a developer to take up maintenance.
OpenAFS 1.3.85 is released. (In reply to comment #13) > OpenAFS needs a developer to take up maintenance. How would one go about becoming a developer for openafs?
It's described here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2
Created attachment 63438 [details] net-fs overlay with openafs 1.3.84 and 1.3.85 Contains my overlay of openafs/openafs-kernel 1.3.84 and 1.3.85. 1.3.85 contains (hackish) fixes for: * not colliding with com_err * not colliding with mit-krb5 I'm using the server successfully with 2.6.10-gentoo-r6 (there's never a good time to upgrade) and the client sucessfully on various kernels including 2.6.12-gentoo-r4. Running the client on a bunch of x86 and amd64 installations (and win32 of course) with no problems so far. I think the hardmask for openafs-1.3 in x86 is kind of dated at this point.
Hi, I just saw your ebuild and I think you should run ./configure instead of econf so that the configure is not run with Gentoo's default --prefix and other arguments. What about the Dutch comments. ;) I don't the the libafs.map file installed. Honestly said, why don't you follow the official procedure and do: cd root.client/usr/vice/etc tar cvf - . | (cd /usr/vice/etc; tar xfp -) Regarding the client part, when user asks to get the stuff in standard TransArc path, why do you do this then: dosbin ${S}/src/afsd/afsd and similar with user binaries? See, this I have done since IBM AFS 3.6 and I believe this is the golden standard here, using transarc paths and installing all files with correct permissions (the comment lines juts point me what I have to do when doing first install on the machine): AFS 3.6 on Linux make dest # chdir into proper subdirectory containing the binaries under dest/ mkdir /usr/vice mkdir /usr/vice/etc cd root.client/usr/vice/etc tar cvf - . | (cd /usr/vice/etc; tar xfp -) # cp -p afs.rc /etc/rc.d/init.d/afs # cd /etc/rc3.d # ln -s ../init.d/afs S99afs # cd ../rc0.d # ln -s ../init.d/afs K01afs # cp /usr/vice/etc/afs.conf /etc/sysconfig/afs /etc/rc.d/init.d/afs start # mkdir /vicepa # echo "/dev/disk /vicepa ext2 defaults 0 2">> /etc/fstab echo "natur.cuni.cz" > /usr/vice/etc/ThisCell # echo "/usr/vice/etc/CellServDB" # mkdir /usr/vice/cache # echo "/afs:/usr/vice/cache:50000" > /usr/vice/etc/cacheinfo cp ../../../../lib/pam_afs.krb.so.1 /lib/security cd /lib/security vim /etc/sysconfig/afs ln -s pam_afs.krb.so.1 pam_afs.so # echo "auth sufficient /lib/security/pam_afs.so try_first_pass ignore_root" >> /etc/pam.d/login #ln -s /afs/cellname/@sys/usr/afsws /usr/afsws cd ../../../../root.server/usr/afs tar cvf - . | (cd /usr/afs; tar xfp -)
At least the 1.3.85 ebuild don't configure with --enable-largefile-fileserver support, --enable-transarc-paths and other flags. The sed(1) hackery looks scary and is not necessary. I _highly_ recommend installing openafs _only_ into transarc paths (that means no option!). You avoind com_err problems, you get third-party packages detect afs easily, because _if_ they have at least minimal support for afs, they they look into standard places for headers, libs, binaries. And sadly, mostly there is very very limited support for openafs, so nothing will find it when relocated. Please, don't cause users headaches, the DOCUMENTATION refers explicitly about TRANSARC paths ... Are you going to update the documentation? Oh no, please don't say the Gentoo guide on openafs is a "documentation". I really mean http://www.openafs.org/doc/index.htm which is the most complete. Some updates are in http://grand.central.org/twiki/bin/view/AFSLore/WebHome. Do not forget, there is no Gentoo openafs maintainer. So, DON'T install outside /usr/vice, /usr/afs and /usr/afsws. Yes, /usr/afsws should contain the files produced under the dest/ directory per specific architecture. AFS has tools to update binaries on remote machines using one binary source! And yes, cacheinfo, CellServDB and ThisCell should never be touched by any upgrade. I suggest improving ebuilds proposed either here or those originally writte by Geerte with my ebuilds under bug #69649(which install into correct locations, but do not have split the server/client parts which I like in Gerte's ebuilds).
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. It'd be great if the new ebuilds could be tested. Collisions should be fixed, FHS has been assumed as the guideline for choice of installation paths. Any remarks are very much appreciated
I version bump'ed the 1.3.85 ebuild locally to 1.3.86 and gave them a whirl. You've already noticed the one patch no longer being applicable. The other things I see off the bat: * /usr/share/man/man1/kpasswd.1.gz conflicts with app-crypt/mit-krb5 * /etc/init.d/afs and /etc/conf.d/afs: conf.d has the OPTIONS="AUTOMATIC" line set by default, but no longer has a default "CACHESIZE." Yet in the init.d, $CACHESIZE is used in comparisons without validating it has been set, causing bash warning to be printed when doing a /etc/init.d/afs start. Other than that, thanks! I don't have to maintain my overlays so much anymore!
I tried the 1.3.85 ebuilds and got it working once I figured out how to make it behave nicely with MIT Krb5, especially key file setup. However, I would like to support comment #18: Please install into TransARC paths. Any piece of documentation out there on the net refers to these paths and software with AFS support (like findutils) assumes AFS libs are in /usr/afsws/lib.
In opposition to comments 18/21, I much prefer my AFS installation in an FHS type layout. I really dislike when a program decides that it should install something into my usr directory in a seperate sub-directory. It is also the default installtion for the OpenAFS build. If people really like their TransArc paths, I would suggest making it a USE flag that defaults to FHS. The only reason that documentation out there refers to the old paths is that it hasn't been updated in years.
In opposition to comments 18/21, I much prefer my AFS installation in an FHS type layout. I really dislike when a program decides that it should install something into my usr directory in a seperate sub-directory. It is also the default installtion for the OpenAFS build. If people really like their TransARC paths, I would suggest making it a USE flag that defaults to FHS. One of the reasons that most documentation out there refers to the old paths is that it hasn't been updated in years.
I'd like to support #23. A documentation update is really needed, and it will surely happen, but at the moment I think gathering information on how the new ebuilds work for people (who, admittedly, currently need to have some insight in paths to use the available documentation) is prioritary. Afterwards all this can be included in a newer version of the gentoo openafs documentation. I'm not looking forward to some kind of "transarc use-flag". I'm not even convinced it's feasible (or worthwhile) to do such a thing.
Please check bug #100837 for an updated (1.3.87) ebuild. It should fix the remarks in comment #20.
Marking as fixed because an ebuild for linux-2.6 on many architectures is now available. Problems with the new ebuilds should be communicated through new bugreports.
Michael, please realize you _wish_ to have openafs installed in FHS location just to have thing 'conforming' to you own yes. The reason why it should be installed in transarc paths is the fact that there are filename clashes, that there is a built-in system to upgrade AFS binaries remotely on other machines what requires afs-admin privs and not local root privs. Same applies to the system to fetch/recycle logfiles. And these are just few I found to off my head. That's the real difference. I'll keep installing my own machines the old, traditional and tested way. Maybe you don't hit problem in FHS places as long as you don't use more afs features and don't read docs. It's you decision. You should have first read the docs, understand whats going on and then say that it is possible to install into non-transarc paths. I don't believe anybody has the time to collect more examples what will break when FHS is followed.
(In reply to comment #27) > Michael, please realize you _wish_ to have openafs installed in FHS location > just to have thing 'conforming' to you own yes. The reason why it should be [...snip...] > is possible to install into non-transarc paths. I don't believe anybody has the > time to collect more examples what will break when FHS is followed. Which brings me back to my original point. Make it a USE flag. Even default it to using transarc paths if you want. It is most definitely possible (see my old ebuilds I submitted, starting with comment #9). Gentoo is about choices, etc. I have a fully functional AFS cell using many of the features you talked about. I set it up using documentation from IBM, OpenAFS, and Gentoo. The fact that things were not in /usr/afs did not phase me. By using which, grep, equery files, etc., I was able to find everything I was looking for and still use the documentation. I have found it's much easier to support users who are familiar with their Gentoo systems but not familiar with AFS if I can point them to locations where Gentoo normally puts things (i.e. /etc/openafs, /etc/conf.d/afs, /var/cache/openafs, /var/lib/openafs, etc.). If I was maintaining some legacy AFS cell I might opt for transarc paths. But in this case I wasn't. And everything I needed worked. And I was more comfortable using FHS paths. Which was my choice. Which is why I use Gentoo. Which is why if we're going to go with transarc paths, it should be a USE flag (comment #23).
I'd be perfectly happy with that USE flag, sure. So you say you use `bos getlog' and `bos install' without problems? Interresting. ;)
(In reply to comment #29) > So you say you use `bos getlog' and `bos install' without problems? Yes.
Tested it as well, both "bos getlog" and "bos install" seem to work properly. I needed to patch openafs to get "bos getlog" to work with relative paths, but that patch has been submitted upstream and is included in the proposed ebuild in bug #100837. Those who don't want to patch can simply install openafs-legacy, which fixes the problem by letting openafs find the files through soft-links. I see less and less hurdles in the FHS path usage. If you find out something that works with the transarc paths but not the FHS paths, please report a bug. Most problems have turned out to be fixable. And finally, about this "choose transarc" USE flag. I don't want the gentoo developer community to banish me :) If we create it, we'd have to support both path conventions in all ebuilds that use afs, and just looking at how we would do this for findutils made me shiver. And that application only has 10 lines of code that refer to afs. (Side note: afs support in find will probably be dropped, as it wasn't working even currently, and because upstream has dropped support. If someone has a fix, feel free to share it)
Sorry Michael, I just found this on http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap3 --quote-- The location in which to install a program's files should not depend on the presence or absence of specific USE variables. --end quote-- I think everything in this document can be seen as gentoo policy, so the USE-flag idea will probably never see any daylight. Any real bugs caused by the choice of FHS-layout are welcome as always.
(In reply to comment #32) > Sorry Michael Hey, don't apologize to me! I prefer the FHS paths... :)
