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          |                                |
  ----------------------------------------------------