Hi > 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? I used the above in the test build: seem OK (to me... but I;m not using/managing AFS servers myself ..) > Anything to build on yet? I tried out test build on Fedora Core 3: shall be close enough .. > If you both stop working on this, let me know and I'll see what I can > come up with. I think Iĺl stop now until next week: If you feel like looking at it (see my previous email): maybe you could see why openafs-krb5-2.0 did not built ? >> 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. Per dead server: as there are in average 3 per cell: in worst case this is 40 seconds delay (if all are dead the startup of AFS will hang anyway .. I think ) > > Anyway, this only hurts people not using dynroot ;-) > well, this is our case (CERN actually does not even have approp. DNS record on internal DNS anymore since a while ...) >> - 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. OK. > 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. Indeed ... (except that there is always a huge users population who installs the thing then doesn followup config recipe: which does not prevent them from calling support, of course ;-)) > 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). Good point: forgot about that. > but individuals or smaller sites with > little AFS experience > will typically have less trouble if dynroot is the default. My 2c. You convinced me (but not our site AFS support people ;-)) > Speaking of default options: How about -nosettime ? As it can happily coexist with your system ntp time synchronization: I do not see it as a problem: - for people who do not have NTP I believe it is actually useful (to avoid unpleasent surprises when ´clock skew detected´) - yes: the implementation in openafs (is it still the case in 1.3 ?) is little bit brain-dead (adjusting by 2second intervals .... when user set year wrong on his system may take some time ;-)) - I think I would prefer to leave it for now. > 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. And causes angry user support calls in style: who the hell changed MY setting on MY SYSTEM ? , right ? ;-) My opinion about triggers is that while these are nice feature .. I would try avoiding them as much as possible: just for the ´transparency´ towards end-user... (but thats my 2c of course) > > How do you generate the profiles and change the templates content? profiles: by running panc compiler (we have it as self-contained RPM too) templates: text editor ... > 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? unfortunately no CLI/GUI for that so far (maybe later this year ?) recompilation of profiles is quite easy: via includes (and inheritance) panc pulls necessary source files and recompiles the profile, from that building an RPM is a question of simple script. If you are interested please check our lcm-profile and edg-panc packages on http://linuxsoft.cern.ch/repository/ Jarek (@Home)