On Thu, 31 Jan 2008, Derrick Brashear wrote:
On Jan 31, 2008 1:42 PM, <[EMAIL PROTECTED]> wrote:
[...]
He's probably using the SL RPMs. Gaurav, if that's true, this
discussion should be taken over to the scientific-linux-users list
since the init script has been quite different from the one in the
openafs.org packages for a while. We'll send you back here once we've
sorted out the issues specific to SL ;-) And just to be sure: This is
not a recommendation not to grab and use the EL4 packages from
openafs.org instead of the ones coming with SL. But whichever you use,
it would be best to address the corresponding mailing list first with
these questions.
fhs instead of transarc, i guess, is the difference?
No. Except for the default cache location (which we changed between SL3
and SL4 three years ago), we're still using transarc paths. The main
difference is probably backward compatibility: If a site had a procedure
to set up and configure an AFS client years ago (say, 2003), that same
procedure should still work with SL 5.1 and OpenAFS 1.4.6 today. For
example, we split the init scripts into client/server when we moved from
SL4 to SL5, following the example of the openafs.org packages. But the
client script is still called afs, and not "afs-client" or
"openafs-client", and the client's sysconfig file is still there, and
it's still called "afs", and all the old options are still there and have
the same meaning as far as they concern the client only.
There are other differences. Since SL releases and OpenAFS releases rarely
line up, it often seems expedient to pull some of the CVS patches into an
SL release. It's probably much like what Russ does for debian (although
he's quite possibly much better in choosing the right ones). And
there's a hack in the init script (introduced before I first looked into
it) that will prevent the client form starting if it can't contact any of
the DB servers in the client's native cell, even in dynroot mode. Some of
the messages in Gaurav's report most likely came from that mechanism.
I try to keep the SL packages in line with the openafs.org ones as much as
possible. But backward compatibility, especially within major SL releases,
is really important to some of the sites using SL - in particular those
with hundreds to thousands of clients.
Of course, Gaurav probably couldn't possibly care less, setting up his
first derver.
--
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
