On 25/10/07 22:05, Wayne Betts wrote:
In the distant past, I used to add several ACCEPT rules for afs in
ipchains or iptables when using openafs clients. But somewhere in time
I stopped doing this (not conciously -- it just slipped my mind when
making my checklist at some point), yet I've never noticed a problem
while using the default iptables rules that end with a default REJECT in
my SL installations. I've gotten a couple bits of different advice from
individuals and the web (for instance: http://help.unc.edu/?id=5513 )
indicating that I need firewall rules in place, but they don't all seem
to quite match up and I'm not familiar enough with afs and/or kerberos
communications to know what's really necessary.
So, first the short question: should I be adding firewall rules when
using SL 3/4/5 with the SL openafs-client packages?
If yes, then a medium (?) question: what rules should I add?
If you are just collecting answers:
We open up port 7001/udp into the client, supposedly the AFS cache
manager sits there and will occasionally receive callbacks from the AFS
servers. Other communications should be handled by the default
"ESTABLISHED,RELATED" logic.
Long (?) question: How can I demonstrate a failure if I don't have the
firewall rules in place? A related question -- why haven't I noticed a
problem before?
Just guessing (ask the Openafs gurus for details), but failure to
contact a client (cache) should trigger some timeout-based protocol to
establish who has the "correct" version, i.e. more overhead, and the
occasional lost update.
