After I got the test.efs setup done with 1.4.12, I immediately wanted to
rebuild it all with 1.5.77, since there are some key features in the 1.5.*
code that EFS is going to leverage. In particular, I plan to require the
newer "fs mkmount" syntax that let's me avoid creating temporary volume
mounts (man, do I wish I had that back when I wrote AFS/VMS...)
This has been a LOT of work, and not everything's automated yet, but here's
what I've accomplished. In Jerry's boot.efs environment, I built
openafs/core/1.5.77-build001, and managed to get a complete build of the
user-mode binaries, but I built with --disable-kernel-module for that
release. The goal is to use openafs/core/* releases for the servers I'll be
building, but that comes later (I have a really sick idea for leveraging
/efs/boot, but as usual, I digress...)
In order to build the test.efs setup, I needed a set of 1.5.77 rpms.
Building the rpms is a little tricky. First, you have to build the srpm,
and then you use that srpm to build the binary rpms. This is partially
automated in openafs/rpms/1.5.77-build001, but I quickly learned that you
have to build a kmod-openafs-* binary rpm for EVERY SINGLE kernel patch
level. Simon Wilkerson wrote a script that mass-produces these, but I
haven't figure out how it works yet. The stuff in the install tree in
openafs/rpms is what was built automatically, but it only includes the
kmod-openafs rpm for the kernel version that is used on the compile servers.
As soon as I tried to use that kernel rpm on MY CentOS 5.4 machines, I
discovered that Jerry's setup runs:
2.6.18-164.el5
but mine are running:
2.6.18-164.15.1.el5
This required building another kmod-openafs rpm for that specific kernel.
What that means is that the simple approach I took for openafs/rpms will not
work. This is why Simon wrote the script he did, and I will need to figure
out how to setup the build environment, which mostly involves collecting all
the kernel-devel-* rpms needed to populate /usr/src/kernels with the right
directories. I'll know more when I dig into it.
In order to make the test.efs environment reproducible, which is my
immediate goal, I've uploaded the rpms I'm working with to:
ftp-osl.osuosl.org:~openefs/data/packages/openafs/1.5.77/$platform
The $platform values are x86-32.rhel.5 and x86-64.rhel.5 of course. This
will be an entirely different effort for Debian/Ubuntu (although that will
probably be much easier, since Russ Allbery owns that code, and he does a
fantastic job of managing OpenAFS for at least Debian), and the other OSes,
as well of course.
The setup process for getting test.efs configured is significantly more
complicated now. For one thing, in order to NOT require everyone else to
setup AFS, I've decoupled the setup into a separate script. For another
thing, you have to run it twice, and it costs you another pair of reboots,
too.
There's lots of todo items for test.efs still, and I'm nailing these one by
one. I do NOT make any PAM changes at all, so authentication is still
manual, but since the test suite automated this, it's just the human users
who have to deal with it for now.
Next, I'm going to start extending efs-core and laying the framework for the
OpenAFS support. One nice thing is that I will be able to use the same
test.efs setup to test AFS and non-AFS, so I will be able to make sure that
basic NFS support doesn't break.
I said I'd have the test.efs done by the end of this week -- mission
accomplished.
By the end of NEXT week, I'm hoping to know a lot more about how efs-core
has to change in order to support both.
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
