Hi Jarek,
On Sat, 26 Feb 2005, Jaroslaw Polok wrote:
> TaDa (or almost ;-)) !
>
> It is there:
>
> /afs/cern.ch/project/linux/dev/afs/openafs-1.3.79-1.SL.src.rpm
I built upon this one.
> I have been able to try it out on Fedora Core 3 (2.6.10-1.760_FC3) at home:
> seems it is working against our cern.ch cell with krbIV.
>
> Problems:
>
> - openafs-krb5 have not been built (compile errors ?) -> I used the same
> package we had in 1.2.11 - IŽll try to have a look at this later ..
> (option krb5support defined as 0 in spec file for now)
I was able to fix this after googling the mailing lists for a while
(see openafs-krb5-SL4.patch). I'm afraid the fixes are specific to SL4
(different krb5 version). The result is in
/afs/ifh.de/user/w/wiesand/public/www/SL4/openafs-1.3.79-2.SL.src.rpm
which also makes it accessible as
http://www-zeuthen.desy.de/~wiesand/SL4/openafs-1.3.79-2.SL.src.rpm
Other than the krb5 fixes there are close to no changes:
- removed wget requirement (no longer used in init script)
- added livesys executable to main package
> - so far it hasn been built on x86_64/ia64/ia32e (but in *theory* it
> shall..): please try on SL 4 ...
I could build the userland packages, but failed to build a kernel module
package (on an SMP system). It would either put the UP module into
2.6.9-5.0.3.ELsmp and the SMP one into 2.6.9-5.0.3.ELsmpsmp. Building
with 'define kernel 2.6.9-5.0.3.EL' made it build packages with the right
names, but the ELsmp one now contained a UP Module...
So I created another release, doing away with all that redhat-buildsys
black magic. After all, they finally got this right and now make
kernel[-smp]-devel packages with everything included one needs for
building modules for a certain kernel, without copying .configs and making
oldconfig for each kernel flavour. These are fairly lean and have no
further requirements, so having them all installed on a build system is
no problem. With this one,
"rpmbuild"
will produse the userland packages (on x86 only;
on x86_64 and ia 64 it should still build a kernel module as
well)
"rpmbuild --target i686"
will produce the kernel module package for the running kernel only
(either SMP or UP, whatever's running)
"rpmbuild --target i686 --define 'kernel 2.6.9-5.0.3.EL'"
will build the kernel module for exactly that kernel
I added a BuildRequires for the right kernel-devel package. The modules
build quite fast (looks like openafs-1.3 disentangled the module and
userland builds way better than 1.2), so I think it's not a disadvantage
to have to run two rpmbuilds for each kernel version.
I think this should work on x86_64 (the ia32e kernels are gone with SL4)
and ia64 as well, but of course I can't check that yet. Anyway, it's
*much* simpler to understand and maintain.
I did successfully test the client packages built from this on SL4, with
the UP and SMP kernels currently available (and the srpms were copied
into my public directory using the SL4 SMP client :).
The srpm is available as
/afs/ifh.de/user/w/wiesand/public/www/SL4/openafs-1.3.79-3.SL.src.rpm
http://www-zeuthen.desy.de/~wiesand/SL4/openafs-1.3.79-3.SL.src.rpm
Once at it, I made a few ;-) additional changes. On top of release 2,
and removing quite a bit of old cruft:
- added optional openafs-debug package with additional tools
- made module name in package & init script libafs instead of openafs,
since that's what the module registers as anyway (modprobe -r openafs
would fail)
- added a patch (101) to fix the CACHESIZE=AUTOMATIC behaviour when the
cache is mounted on some device with a long name
I haven't undone any of your changes (except - naturally - the ones
having to do with the modules build). In particular, dynroot is the
default just as in your package ;-)
> - I havenŽt really checked much ... build *looks* complete ..
> but I could be wrong ;-)
>
> Changes (to 1.2.11):
>
> - removed most of patches (not needed anymore)
> - changed init script to use rxdebug on port 7002 instead of wget on
> 7000
> (yes, as Stephan pointed out: this gives 20 secs timeout
> per dead server: but looking at CellServDB most cells have
> 3 DB servers: if all are dead = 60 seconds timeout = but AFS will
> not run anyway ... so worst case is 40 seconds I would say:
>
> I believe it is acceptable and - this is the solution which really
> checks for AFS DB server - unlike wget )
>
> - little bit of tweaking in spec file: it shall work for 2.4 and 2.6
> kernels builds (not checked!)
Well, that's gone, sorry. Anyway, I think the way kernel sources are
handled are so different between SL3 and SL4 that having a common spec is
more confusing than helpful.
> - options used for configure:
> ./configure --with-afs-sysname=i386_linux26
> --prefix=/usr
> --libdir=/usr/lib
> --bindir=/usr/bin
> --sbindir=/usr/sbin
> --with-linux-kernel-headers=/lib/modules/${kernel}/build
> --enable-redhat-buildsys
> --enable-bitmap-later
> --enable-bos-restricted-mode
> --enable-fast-restart
> --enable-bos-new-config
> --enable-supergroups
> --enable-largefile-fileserver
> --enable-transarc-paths
I kept those, even though I think the --prefix to --sbindir are completely
redundant (since no "make install" is done, but we still copy what's
created by "make dest").
> - CACHESIZE is set to AUTOMATIC in /etc/sysconfig/afs
> (if your cache is not on separate partitions startup
> script will abort and ask you to adjust this setting
> first)
I added a fix (use df -Pk instead of df -k) to this in the init script
(df -k output may have the device on the first line and the sizes on the
second if the device name is long - after a "tail -1" and printing the
second field you start the cache size calculation from "used" instead of
"available").
> Changes that we could consider for production builds:
>
> - move afsd from /usr/vice/etc/ to /usr/sbin/
No objections. But once we touch this, maybe we should rename it
to afsd-`uname -r`, put it into the kernel-module package, and have the
init script start that (and fall back to afsd if it doesn't exist).
The reason why I think this makes sense is that I believe the cache
manager and the kernel module to communicate over an *ABI* (which may
change), while all the other executables and libs communicate through a
*protocol* (which shouldn't change in an incompatible way).
This may make updates much more painless. For example, I believe this way
one could even use the module and cache manager from 1.3 with all the rest
of the client packages coming from 1.2 - and vice versa.
> - move cacheinfo, CellAlias, CellServDB, SuidCells and
> ThisCell from /usr/vice/etc/ to /etc/openafs/
Please, no. We tried this two years ago, and quickly realized in how many
places these paths are hardcoded. I bet the other large sites with some
legacy have the same problem. Even having a link /usr/vice/etc ->
/etc/openafs did not solve it, and I think we don't want to try this
ever again...
> - integrate killafs from /usr/vice/etc/ into /etc/init.d/afs
> - move cache from /usr/vice/etc/cache to /var/cache/openafs/
> (and provide symlink
> /usr/vice/etc/cache -> /var/cache/openafs/
> in openafs-compat package)
No objections. I even think the link is not needed since nothing but the
cache manager is supposed to access the cache.
> I believe the above would be more consistent with filesystem
> layout on linux ... (and it requires just few adjustments
> in spec file , init.d script and /etc/sysconfig/afs script)
> Please tell me what is your opinion on that.
I agree, but /usr/vice/etc is a problem. Really.
> Enjoy (and tell me if it worked for you, please)
Please have a look at and try my release 3 srpm, and let me know what you
think about it.
> Jarek (@Home)
>
Cheers,
Stephan
--
----------------------------------------------------
| Stephan Wiesand | |
| | |
| DESY - DV - | phone +49 33762 7 7370 |
| Platanenallee 6 | fax +49 33762 7 7216 |
| 15738 Zeuthen | |
| Germany | |
----------------------------------------------------
|
