[OpenAFS] using openafs client to server web pages

[Jeffrey Hutzelman]

On Friday, July 14, 2006 05:19:46 PM -0700 David Bear <David.Bear@asu.edu> 
wrote:

> On Fri, Jul 14, 2006 at 07:21:35AM -0700, ted creedon wrote:
>> Look at the NetInfo file. Here Openafs looks at 10.1.1.193 as well as the
>> external IP address.
>>
>> NetInfo would listen on all of:
>>
>> 198.168.10.5
>> 198.168.10.6
>> 198.168.10.7
>> 198.168.10.8
>
> Yes, I've heard of the netinfo file. But I don't know where it is.

That's going to depend on how your bits were configured.  In general, it's 
going to be in the same place as the relevant CellServDB and ThisCell 
files.  Ted gave you an answer that would be correct if you were trying to 
configure a fileserver built with Transarc-style paths, but you're 
configuring an AFS client, not a server, and the OpenAFS packages for most 
major Linux distributions use FHS-style paths.

Of course, the NetInfo file is also not the answer you're looking for.  It 
controls what addresses are advertised by a client or server, but not which 
interfaces or addresses will be used to originate traffic -- that's 
controlled by your operating system's network stack.  In fact, it doesn't 
even control on which interfaces you _receive_ traffic - Rx binds a socket 
to INADDR_ANY and will accept traffic received on any interface.

There is an option (-rxbind) which changes this behavior, so that only the 
single, specific interface identified by applying NetInfo and NetRestrict 
will be used.  With this option, Rx binds a socket to that single address, 
so that only traffic destined to that address will be processed, and all 
outbound traffic will originate from that address.  This only works if, 
after applying NetInfo and NetRestrict, there is _exactly one_ address 
left.  Otherwise, it has no effect.


But that wasn't your question.  We'd save an awful lot of time and 
confusion here if certain individuals would stop leading people on wild 
goose chases with their wrong answers.


Your original question had to do with whether the OpenAFS client would talk 
to the fileserver using a source address based on which virtual web server 
receieved the request that resulted in trying to fetch a file.  Russ gave 
you the correct answer to this one, which is "no".  When the web server 
opens a file, the filesystem has no way to tell why it is opening the file, 
let alone details about the origin of a request the server is processing.

The way to handle this is to grant the server machine access to all of the 
files you want to serve from any of those virtual hosts, and then control 
which pages are accessible from which virtual servers in the web server 
configuration.

If the web server had multiple _physical_ interfaces, you might want to 
restrict it to using only one for AFS by using a combination of NetInfo and 
the -rxbind switch.  However, with _virtual_ interfaces, that's not 
necessary - current OS's will always use the "real" address for outgoing 
traffic, rather than one of the virtual ones.  Of course, you could also 
always just put multiple IP addresses into the group you're using.



Finally, let me make a plug for not using address-based ACL's.  Besides 
being terribly insecure, AFS IP-address-based ACL's are also quite flaky, 
and some of the problems are not easily solved.  If you're using AFS to 
store static web pages which are accessible through a public web server, 
why not just make the pages readable to system:anyuser and be done with it?

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA