1.3.86 is released
audit-patch has been applied upstream ignoring this patch, clean build on amd64, alpha and x86 confirmed remember to fix line 146 in init-script, and to do a keepdir /etc/openafs (don't clash with the FHS-transition code)
Created attachment 65971 [details] New proposed openafs 1.3.87 ebuild
Created attachment 65972 [details] New accompagnying file archive New openafs-1.3.87 ebuild proposal, together with the previously attached ebuild-file. The openafs-kernel ebuild should just be bumped without any changes. Check the changelog for more information.
Created attachment 65978 [details] New proposed openafs 1.3.87 ebuild small incremental changes wrt the previous version: correct kpasswd-manual page renaming, and usage of keepdir instead of dodir
Created attachment 66295 [details] New proposed openafs 1.3.87 ebuild In short, adds BOSSERVER_OPTIONS configuration option, fixes directory permissions, allows relative path "bos getlog" commands, fixes CACHESIZE=AUTOMATIC.
Created attachment 66297 [details] For the record, the accompagnying patchset Should download automatically
Created attachment 67210 [details] openafs-1.4.0_rc2 proposed ebuild
Created attachment 67211 [details] openafs-1.4.0_rc2 proposed kernel module-ebuild
Created attachment 67212 [details] For the record, the accompagnying patchset (will download automatically) The new openafs-1.4.0_rc2 has seperate init-scripts for client and server. Thus, you will need to run rc-update again to start afs automatically at boot-time. (This eliminates the ENABLE_SERVER etc. variables in the afs config file, which is btw now renamed from /etc/conf.d/afs to /etc/conf.d/afs-client) Have fun!
Concerning the Kerberos warning: At least for me it works fine so far, using the pam_krb5 ebuild from bug #103406 and MIT Kerberos. What about making this a dependency if both pam and kerberos USE flags are set?
I too have tested kerberos in the meanwhile, but without pam_krb5 and with heimdal instead if mit-krb5. So I guess the warning can be deprecated. About the dependency: As I see it, pam_krb5 doesn't necessarily have something to do with openafs. It is perfectly possible to use krb5 for authentication with the pam-module, without ever touching afs. (Please correct me if I'm wrong) Furthermore, I agree that if pam_krb5 would be part of a kerberos package, that it'd have to be enabled by the pam use-flag. Otherwise, it wouldn't be available to the user at all. Making kerberos depend on pam_krb5 if pam is enabled, would be like saying that kerberos doesn't work on a pam-supporting system without that module. Maybe it's a good idea to mention this module in the gentoo openafs-documentation instead?
A word or two in the docs would be OK. My reasoning behind making it a dependency was to ease installation. Just "emerge openafs" and get what is needed according to USE flags. About the relation to openafs: The 2.1.8 version can also get afs tokens in a pure krb5 environment, no need for pam_openafs_session. About the rc2 ebuilds: They work fine for me, but if the config is now in /etc/conf.d/afs-client, there shouldn't be server related stuff in it. This should then go to /etc/conf.d/afs-server. Another thing is kernel sources: At least the 1.3.x kernel ebuild wont build against 2.6.13 kernel sources. So there should be an additional check in those ebuilds. OTOH, I don't know wether 1.4.x requires kernel sources >=2.6.13 or still builds fine with earlier kernel sources.
Docs: still postponing, but I prefer postponing to updating documentation when the target is still moving. People who like writing documentation better than I do are of course welcome to submit their work :) Your remark on /etc/conf.d/afs-client was very correct. The version that's coming to portage soon will fix this. The kernel sources: I've run openafs-1.4-rc2 on kernels 2.4.21-alpha-r17, 2.6.11-gentoo-r8, 2.6.12-gentoo-r9 and 2.6.13-gentoo. I think deprecating 1.3.x is the best option here. Very valuable input, thank you!
Fixed. openafs-1.4.0_rc2 now in portage
