Hi Stephan,
These are very good idea's.  I am making the changes on the spec file as 
I write this, so if I say 'done', then I've made the changes.

Stephan Wiesand wrote:
> Dear Troy (and other AFS package developers),
> 
> First, it looks as though the LC_ALL fix from Jarek did not make it into 
> the package (since the file afs.rc.linux-1.2.11 in the modified tarball 
> is not what gets installed).
> 
*slaps forehead*  Uggg ... thanks
Actually, I think I'm going to pull this out and make it a Source, just 
like ThisCell, and the others.  That way it's easy to edit, without 
messing with the tar ball.  I could remake it a patch, like it was 
originally, but we've made just so many changes that I think having it 
completely out of the tarball is the way to go.

> Once at it, I have a couple of proposals for changes/enhancements.
> I'll gladly provide a modified spec featuring whatever will be accepted:
> 
> - Shouldn't the default afsd options be changed from the spec instead
>   of in the tarball ?
> 

Umm ... in reading this.  Did I just say the same thing you proposed? 
If I did, then yes, I think this is a good idea.
Done

> - Shouldn't /etc/sysconfig/afs be %config(noreplace)?
> 
Good point.
Done

One the same topic, what about moving /etc/sysconfig/afs out to be a 
Source as well, instead of messing with the tarball.

> - Shouldn't we go for 1.2.13? I think there's at least one fix for
>   deadlocks on SMP clients in there.
> 

Part of me says yes, part of me says no.
The yes part says, that's a great idea, we'll get the latest and all 
it's fixes.
The no part of me says - We've got alot of patches in it for building, 
and we just got the X86_64 aklog bug fixed.  It's stable on alot of 
machines.  I'm not sure I want to mess with it.

So while I like the idea, I would really like to have more testing.  I 
don't feel comfortable that we would have enough time to test it good 
before S.L. 3.0.4 comes out.
How about we get 3.0.4 out and then get to work on this?

> - Shouldn't openafs-client require wget, since that's used in the
>   init script?
> 

Done

On a similar note.  Do you have any ideas one a better way for this. 
Jarek brought up the point that wget is doing a tcp ping, while AFS 
really is using UDP.  So if someone set's up their firewall to just do 
udp, this is still going to fail.

> - There are two fileserver implementations: The one installed by default
>   which is using pthreads, and one using LWP (AFS' "lightweight process"
>   implementation) which is built (in src/viced) but not installed by
>   default.
> 
>   The former one is supposed to be a bit faster, but rumour says the
>   latter one may be a bit more stable (all I know for sure is that we
>   are using the LWP version on our linux file servers, and it *is*
>   stable - I haven't tried the pthreaded one yet).
> 
>   I propose to package both of them (as fileserver.{pt|lwp}) and make
>   fileserver a link (to fileserver.pt, for backward compatibility).
> 
> - The following configure options are foreseen to be activated in the
>   spec, but they're all off, and I think they should be on:
> 
>   --enable-bitmap-later
> 
>      This delays vnode bitmap creation by the fileserver until a volume
>      is accessed the first time, instead of creating them all when the
>      volumes are attached (during fileserver startup). I think most
>      sites are using this on their fileservers nowadays.
> 
>   --enable-fast-restart
> 
>      This does not change the default fileserver behaviour in any way,
>      but allows adding -DontSalvage to the salvager options for an fs
>      instance. Corrupted volumes will be taken offline upon attach, to
>      be salvaged manually later on.
> 
>   --enable-bos-restricted-mode
> 
>      Again, this just adds a runtime option but does not affect default
>      behaviour.
> 
> - The following configure options are not foreseen to be activated in the
>   spec, but I think they should, and they should be on:
> 
>   --enable-full-vos-listvol-switch
> 
>      Adds a "-format" switch to the "vos listvol" and "vos examine"
>      commands (complete & parseable output). I really need this...
> 
>   --enable-bos-new-config
> 
>      I haven't used this yet, but I may want to eventually (bosserver
>      will read BosConfig.new upon restart, if it exists).
> 

See above talking about not enough testing time for 3.0.4.
This is something that you will need to send to me the spec file, and 
changes.  You clearly know what your doing, and I would probrubly mess 
things up.

> - The "livesys" executable should at least be packaged. Probably the
>   "sys" executable should be replaced by a (hard) link to livesys.
> 

You'll have to send me the changes to let me know what you mean.

> - The %pre script in openafs-compat will rm-rf /usr/afsws if it exists,
>   and I think it shouldn't do that.
> 

Agreed,
Done

> - There's a number of additional tools for tuning, debugging and recovery.
>   Most of them are built during a normal "make", but not installed by
>   "make dest". A few have to be built explicitly.
> 
>   I propose collecting these in /usr/afs/debug and packaging them into
>   a new "openafs-debug" package. Most of us will hopefully never need
>   it, but once you do it's not the time for finding out how to get to
>   them.
> 

Sure,
Can you send me the changes for the spec file.  I don't know if the 
changes will make it in to 3.0.4, but we can try.

> And by the way, I recently learned about "cell aliases". These are meant
> to act like symlinks like "/afs/openafs.org -> oao" in root.afs, so sites
> relying on such a link for their cell can use dynroot. It's getting 
> better: this allows emulating arbitrary symlinks (there may be some 
> limits, but everything I tried worked). These aliases are set with
> "fs newalias", or read from /usr/vice/etc/CellAlias (contains lines in
> the form "<target> <alias>", like "fnal.gov/common/usr usr).
> 
> Hence my last proposal is adding such a file, with some comments 
> explaining how to use it.
> 

Oh ... that's what those cell alias's are.  I'd been starting to see 
those when looking at 1.3.xx and wasn't sure what they were.
Very good idea
Done

(If you can think of better wording than I have in there, let me know. 
It's basically your wording.)

> I know this looks like a lot of changes, but the only one that actually
> changes default behaviour affects fileservers only (is anyone using the
> SL server packages for production servers yet?).
> 
> Cheers,
>     Stephan
> 

Thanks
Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________