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)