On Sat, 26 Feb 2005, Jaroslaw Polok wrote: > Troy Dawson wrote: >> Howdy, >> Has anyone gotten an openafs src.rpm for openafs 1.3.79. I figured you and/or Jarek would be working on it, so I was planning to ask the same question today before I'd start. I did get a manual installation of a 1.3.79 client going on my SL4 test system without any hassles. Whether it's stable and doesn't clobber my data remains to be seen... The configure options I used were ./configure --with-afs-sysname=i386_linux26 \ --enable-bos-restricted-mode \ --enable-bos-new-config \ --enable-largefile-fileserver \ --enable-supergroups \ --enable-fast-restart \ --enable-bitmap-later \ --with-linux-kernel-headers=/lib/modules/`uname -r`/build \ --enable-transarc-paths Any objections to making this the default for SL4's openafs packages? > Not yet... but I'm looking at it today. > .. so we'll see soon how it worked out. Anything to build on yet? If you both stop working on this, let me know and I'll see what I can come up with. > On the same subject: > > - the wget check shall be really removed : it hurts people > (in case sbdy has 7000/tcp closed on firewall for > example: as we do at CERN..) > - in addition this does not check for: > - that replying server is AFS server > - that replying server is AFS DB server > > working check would be: > > /usr/sbin/rxdebug $SERVER -port 7002 -version 2>&1 > /dev/null > if [ $? -eq 0 ]; then > echo "OK!" > fi > > (yes we've tried on 7000 before: but 7000 is only > afs3-fileserver: AFS DB servers do not need to run it > , but they must run afs3-prserver on 7002) While this works, it incurs a 20 seconds timeout per server. My guess that changing "#define TIMEOUT 20" in rxdebug.c to some smaller value would help turned out not to be correct. But at least the rxdebug from 1.3 works on 64bit (BTW, is there an ETA for 40rolling/x86_64 ?). Anyway, this only hurts people not using dynroot ;-) > - the -dynroot shall really be disabled in default > package: it also breaks things for people It is enabled in the default configuration as shipped with openafs-1.3. It only breaks things for sites relying on something in their root.afs volume. Such sites will typically have configuration management systems - like quattor - that allow changing this setting just like they probably do for dozens to hundreds of others. And if it's just symlinks what they have in root.afs, they can still use dynroot and substitute those symlinks with cell aliases (even if they don't point to a cell mount). I really don't care too much since all my clients will be installed with a "perl -pi -e 's/^ENABLE_DYNROOT=.*/ENABLE_DYNROOT=on/' /etc/sysconfig/afs" line in %post, but individuals or smaller sites with little AFS experience will typically have less trouble if dynroot is the default. My 2c. Speaking of default options: How about -nosettime ? > (yes, I know theres SL_afs_nodynroot package: > but I would REALLY prefer if dynroot is disabled > by default and then a SL_afs_dynroot package is > provided for those who need it...) > > Side note: we on CERN site avoid as much as we can > propagating such config changes via RPMS: we rather > use our own config mechanism based on Quattor > (http://quattor.cern.ch) to propagate changes. > [the RPM containing 'profile' for the machine - > which is site dependent - is updated regularily > and it runs configuration components to perform > changes when needed]. Although I agree they're no replacement for something like Quattor, I happen to like those tweak RPMs. And for changing files that come in packages, using triggers gives you the shortest time window between update/installation of the package and your customization. It also avoids having to run the same tests over and over again. > this way framework and component packages > are not updated (unless improved/bug-fixed): only > a single profile package gets updated (once per month > or even less frequently in our case) > > > I would be happy to discuss details of this solution > if anybody is interested .. How do you generate the profiles and change the templates content? Having to do this with a text editor is one thing that still puts me off. Do you have something like a CLI or a GUI to change a template entry which will then trigger recompilation of all affected profiles and the generation of that profile package for each client that needs it? Cheers, Stephan -- ---------------------------------------------------- | Stephan Wiesand | | | | | | DESY - DV - | phone +49 33762 7 7370 | | Platanenallee 6 | fax +49 33762 7 7216 | | 15738 Zeuthen | | | Germany | | ----------------------------------------------------