Derek:
Hmm. I ended up rebuilding all the RPMs from the openafs site in the past
year because there were no x86_64 packages.
That's because I have no x86_64 hardware, and vmware doesn't emulate x86_64.
We need to start a collection and get you some money and/or x86_64
hardware. Seriously, you are suffering :)
If people already are running kaserver and are going to convert to krb5,
they will probably need the whole kit. I figured I might as well provide
it, but in a separate package. Otherwise people will just have to build it
anyway, and they won't have the openafs source tree available like we do
when the RPM is being built.
True.. I just didn't want to go through the hastle of getting afs2k5db to
build. i don't recall why I didn't build/ship fakeka.
I think it's worthwhile to provide it, although if we actually wanted to
make like easier for people converting from kaserver to krb5, we should
also write some new documentation.
When I packaged it, I used the same kerberos stuff that comes with RHEL 4
so that everything matched up.
But since you make the kernel packages their own RPMs it looks fairly easy
to handle.
Yep. That was a design goal of the 1.4 RPM. This way you can actually
*JUST*
build a kernel module via rpmbuild. Just supply a target and it'll build a
kernel module for the running kernel (at least on x86). It makes it VERY
easy
to build a new kernel module without having to rebuild all of AFS.
Yes.
The main reason why I didn't like this in the past, was that Red Hat used
to ship multiple kernel packages that had conflicting files:
kernel-.i386 kernel-.i586 kernel-.i686
all installed into the same /lib/modules/version directory.
I like to keep the package load on all machines the same where possible.
The old scheme was a pain in the ass, because you couldn't install all
possible AFS modules on a single machine in the actual kernel paths, etc.
Now that Red Hat has wisely decided to simplify and only support one
'arch' for its kernel RPMs, this isn't an issue.
I've pondered which to do.. The "2b always" can potentially be an issue. I
figure that this is something I can change for, say, 1.4.1.
Hmm. I guess I'd suggest packaging the OpenAFS aklog since it's more up to
date.
It would be nice if aklog could figure out whether or not a server
supports 2b somehow...
I'm also guessing that the -authlibs package in your RPMs will not install
properly, due to the ABI naming problem with the shared libraries on Linux.
I included Russ's patch to fix this:
http://rt.central.org/rt/Ticket/Display.html?id=18767
Yes, I know about this bug.. And it's been mentioned on the list.. I
actually
only include these packages because you did. I could just remove them
totally... My preference is that this patch get included in the main distro.
If the gatekeepers are not willing to apply this patch then they must have
their reasons. (Or they're being lazy, but I'd prefer to believe they have
reasons).
I guess they are afraid of the people who have already built software
linked against the libraries with inconsistent SONAME?
In my opinion I think this patch either has to be applied, or the shared
libraries should not be packaged in the RPM. Otherwise they get built with
inconsistent naming compared to all the other libraries on a redhat system.
Fair enough. I'm willing to remove the authlibs packages from the RPMs.
I'd go ahead and do that (remove the shlibs entirely) if you're
uncomfortable with adding the patch. Since you will be effectively
defining OpenAFS on redhat, though, you could probably defend throwing the
patch in since anyone who builds against OpenAFS on redhat would use your
stuff.
The shared library interface for OpenAFS doesn't seem to be too well
specified anyway, and as I noted in my spec file comments, it isn't used
by anything inside OpenAFS.
I think the preferred way to do most things you'd need those libraries for
is GSSAPI and PAM. (granted, the necessary pieces for _that_ to work have
only come together very recently, but it does work)
(non-multiprocess server access to AFS is the only thing I can think of
that would need to set tokens in a hurry)
I'll try to take a look at your packages when I have time this weekend or
next week. Unfortunately we just deployed 700 machines with 1.4.0-rc1 and
my RPMs, so I won't get an opportunity to upgrade them for a while.
Thanks. Any patches would be appreciated. The one outstanding issue I have
right now is that even though the module is named openafs.ko, lsmod reports
it
as libafs. So even tho "modprobe openafs" works, "modprobe -r openafs" does
not. This means the openafs-client initscript doesn't completely stop the
client -- or at least it doesn't properly remove the module.
If anyone has any hints about why this occurs, or how to rename the module,
I'd
appreciate the hints!
I think it's getting set by the kbuild makefile magic in linux-2.6.
e.g., when the module gets built in:
src/libafs/MODLOAD-x.y.z
the script 'make_kbuild_makefile.pl' generates a kbuild makefile:
src/libafs/MODLOAD-x.y.z/Makefile
which contains the line:
obj-m := libafs.o
and then the kbuild stuff magically parses this and knows that the module
is called 'libafs'.
I think the script in question that handles this is:
/path/to/kernel/source/scripts/Makefile.modpost
I'm guessing that if you change the AFS scripts and makefiles to generate
openafs.o instead of libafs.o, it will do what you want. Otherwise, maybe
find a way to specify KBUILD_MODNAME to the kernel makefiles/scripts?
PS: Thanks for your original work! It was very useful. Between you and
David
Howells I used a lot of ideas for the updated packaging system.
no problem. We needed to deploy RHEL4 by the fall, so we needed to build
openafs 1.3.x.
I'm looking forward to bumming off your work again in the future... :)
-Chris
[EMAIL PROTECTED]
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
