[OpenAFS-devel] OpenAFS on *BSD platforms

[Marcus Watts]

jtoy@mac.com sent:
> =A9=F3Saturday, Jul 13, 2002, 06:58  PM, Harald Barth =BCg=A1G
> 
> >
> >> Hello, I have written to the people supposedly handling the code for
> >> OpenAFS on OpenBSD, but have never received a reply.
> >
> > OpenAFS has a IBM license. Not popular with the OpenBSD guys what I
> > understand. But they could send a reply...
> >
> > There is some progress to get Arla working again on OpenBSD. If you
> > want a client, that might help you. Ask about the status on the
> > arla-drinkers mailing list if you are curious.
> >
> > Harald.
> >
> 
> The Arla client is included in the source tree with OpenBSD, but I =20
> would like to use my OpenBSD server as my OpenAFS server, since I have=20=
> 
> about 200 Gigs.
> I don't think that the license has anything to do with OpenBSD and=20
> OpenAFS, but  that is just my guess.  NetBSD and FreeBSD use the same=20
> kind of license as OpenBSD.

The OpenAFS ("IPL") license is mostly compatible with *bsd, so better
than GPL.  It is however a lot harder to read & understand.  If I
remember right, the main issue has to do with software patents, not an
issue for most folks.  It is certainly way better than NPL (mozilla) or
whatever Apple is using with Darwin.

OpenBSD does not support kernel threads.  That is going to put it at a
performance disadvantage compared to linux when serving files, because
it's not going to be able to make more than one disk request at a
time.  This won't be *as* important if you have one big drive rather
than lots of small drives, but it will still be an issue (sorting disk
requests to optimize disk seek access doesn't help if there's never
more than one request to sort.) Linux, solaris, and I think freebsd
support kernel threads; so should have an advantage here.

OpenBSD comes with heimdal, which does k5.  AFS only supports k4.
Heimdal supports some form of 5 to 4 ticket conversion, but you'll
still have to deal with getting a keyfile for afs, you probably won't
find it practical to run fakeka or use the afs string to key function,
etc.  You could instead run kaserver, but that won't play as nicely
with any hypothetical openbsd clients.  Pretty much any openbsd code
that knows about afs (including openssh) is going to have porting
issues going to the transarc afs api.

If you *only* want to use openbsd as a server, in some sense, your
problems are simplier.  You can ignore all the login/openssh issues for
instance.  You don't have to get the cache manager running, but you do
need to figure out something to do about inode access (for the
fileserver) [I think somebody was doing work to make the kernel hacks
unnecessary?], and you might want to write code to make an AFS ticket
in a K4 ticket file look like an afs cache manager token.  Kernel
threads won't be as important for db servers - just make sure you have
enough memory to cache the databases.  The linux i386 code to switch
threads ought to be close to right for openbsd.  If you build things in
this order,
	config pinstall util des comerr cmd lwp rx rxgen fsint sys ubik
	rxkad audit auth ptserver afs kauth log libacl dir vol vfsck
	vlserver volser bozo finale viced
*in theory* you should end up with working copies of bos/bosserver,
vos/volser, fileserver, ptserver, etc.  You may have to do a lot of
hand-configuration, makefile hacking, etc., to make this come out
right, and vol/vfsck/volser/viced are going to depend greatly on how
you solve the inode interface issue.

				-Marcus Watts
				UM ITCS Umich Systems Group