[OpenAFS] /etc/rc.d/init/afs start does not start afs

[Stephan.Wiesand@desy.de]

On Thu, 31 Jan 2008, Derrick Brashear wrote:

> On Jan 31, 2008 1:42 PM, <Stephan.Wiesand@desy.de> 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