On Mon, 2 Feb 1998, Quentin Coles wrote:
| I am trying to setup an afs client as a web server and need to know what
| goes into getting this goal accomplished. Do I have to setup an account
| for the machine? Do I have to setup a group with the IP of the webserver
| being a member? Do I need to have the httpd process have a token that
| dosen't expire?
Well, you don't necessarily have to do anything to make a webserver
machine an AFS client. Its only important if you want to have the
webserver machine have privileged access to the filesystem. If you're
doing readonly access to the AFS data, then do nothing besides permit the
web content system:anyuser rl.
If you want to do privileged access (private reads or writes), then I'd
recommend using IP ACLs, as these require no maintenance or other work on
your part, and in general don't break. To do this, create a pts entry for
the IP address of the AFS client machine, add the entry to a group, and
permit that group with the necessary access to your web content.
1. pts create 111.222.111.222
2. pts creategroup machine
3. pts creategroup machine:your.server.name -owner machine
4. pts adduser 111.222.111.222 machine:your.server.name
5. fs setacl -dir /afs/some/path -acl machine:your.server.name rl
system:anyuser none
Note that IP ACLs tend to take a fair amount of time to be recognized by
the fileserver, as the fileserver has to be notified by the ptserver that
there's a new IP ACL group entry it needs to pay special attention to when
authorizing filesystem requests (at least that's how I understand the
process to work). You'll either need to restart the fileserver in
question (I think just the fs process suite needs to be restarted), or
wait a day or so. This is the downside to IP ACLs. :-)
The above example permits only your webserver machine read access to the
web content space. I recommend _not_ permitting the entire web content
tree to be writable by your web server, given that CGI programs and
HTTP servers can be convinced to do things you don't intend unless you're
very careful. If you need to permit a particular directory to be writable
by the web server, do so explicitly.
Another good tactic is to mount your web content volume as your root AFS
volume on this client machine. This somewhat "chroots" the webserver into
your AFS space, preventing the machine from easily accessing data it
doesn't need to see, such as user volumes. You can do this by specifying
the "-rootvol" flag to afsd when your client starts up. This may or may
not work for you, depending on how much of your AFS space your client
machine needs to access. An intruder would have to modify the AFS startup
file and reboot the system in order to gain access to the entire tree. If
there's AFS space available to the machine that's writable, then an
intruder could mount any volume they chose if they knew the name. This
possibility can be minimized by not supplying any of the AFS client
binaries to the machine (fs, vos, pts, etc.)
i.e. /usr/vice/bin/afsd -rootvol some.other.volume $OTHER_FLAGS
If you need to recursively repermit an entire directory tree, you can
use xargs (since fs setacl doesn't work recursively):
find . -type d -print | xargs fs setacl -acl system:anyuser none \
machine:your.server.name rl -dir
I've done a lot of work with AFS and web servers, including putting
together a proposal to run our web hosting service out of AFS. It was
thought to be too expensive, however. :-) I'd be curious to know how
Erols is progressing, and what kind of things you're planning on doing.
My Transarc contacts told me you folks were doing something in this area,
but not much in the way of specifics.
Good luck!
-brian
--
Brian W. Spolarich - ANS Communications - [EMAIL PROTECTED] - 734-214-7311
"Not a whit, we defy augury." - Hamlet, V, ii
