Hi Stephan and Jarek,
Thank you thank you.
I have compiled openafs-1.3.79-3.SL.src.rpm and it looks like it works
for the most part. I think I agree with Stephan on making a spec file
that is just for the 2.6 kernel. It makes for a cleaner spec file.
I am currently testing on a single cpu machine. I can startup, read,
write. I cannot shutdown. It's getting stuck on the umount /afs. I'm
looking into this more.
I like Jarek's fix to get rid of wget from the startup script. I
haven't tried it against the whole CellServDB, but it's worked on all
the machine's I have tried it against thus far.
I have tried the aklog, and it seems to work.
Yes, the new kernel modules do seem to build faster.
Oh, for x86_64, the rebuild is not going as cleanly as the i386 rebuild
did. Hopefully we'll have it by the end of the week.
I've been building the openafs on a CentOS x86_64 build, and found that
the openafs-SL-krb5-configure-amd64.patch isn't going in a cleanly as is
needed. It's basically getting wiped out somewhere along the way,
though it LOOKS like it's there after doing an rpmbuild -bp.
I'm a little concerned about the AUTO being on for the cache. I know
alot of folks here at Fermi don't have /usr/vice/cache as a seperate
partition, especially on the desktop machines. This basically turns AFS
off for them until they edit the file.
So I'm really wondering just how many people really do use a separate
parittion for their afs cache.
On a related note, just how much disk will AUTO take?
If we move the cache to /var/cache (which I think is logical), I often
have /var on it's own partition, but that's so my log files don't fill
things up. If afs grabs the whole partition, then my log files start
getting starved.
Troy
Stephan Wiesand wrote:
> 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
>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/CSS CSI Group
__________________________________________________
|
