[OpenAFS] Is OpenAFS appropriate?

[Stephen Bosch]

Derek Atkins wrote:
> Hi,
> 
> Stephen Bosch <posting@vodacomm.ca> writes:
> 
> 
>>Well, I've been hammering away at our first ever OpenAFS install for
>>about four full days now, and there is some good news and some bad
>>news.
> 
> 
> Four days!?!?  The last time I installed a cell from scratch
> (which was a few months ago) I got it all up and running in
> about an hour.  That included the PAM modules to get login
> working.  OTOH you didn't say what OS your server is running....

Please be fair. This is not just a "cell from scratch", this is also 
"administrator from scratch." No previous experience with AFS; no 
previous *exposure* to AFS, and no buddies with any of these either. 
Also, no cheating -- nothing done without a full understanding of *what* 
I was doing.

In my defence, too, most of that four days was spent reading the 
documentation, which is such a mess of self-referencing hyperlinks that 
if you don't force yourself to ignore them and read sequentially, you 
can easily miss vital points. I feel like Mozart's retarded brother 
trying to teach himself piano.

The documents do have a very "proprietary Unix" flavour to them -- this 
was built on a Linux server running kernel 2.4.24. My first attempts at 
building used the "standard" paths, but I soon realized that I would be 
better off sticking as closely to a typical AFS installation as possible 
and forced myself to work with the Transarc paths. Only then did things 
start to make more sense (and work, for that matter).

>>It is also bad news that as yet I am still doing the client work on
>>the single file server (just no point in installing a client on
>>another machine until I'm comfortable enough with this).
>  
> This isn't necessarily a bad thing.  It's definitely a good bootstrap
> step.

Okay, that's a relief. I did it deliberately, I'm trying to keep things 
as simple as possible.

>>It has taken me so very long to get this far. I've read a lot of
>>documentation. I don't know how much it is sticking. The learning
>>curve is steep.
>  
> True, it's a bit steep.  I'd suggest you take an AFS class to put it
> all into perspective, because once you understand the fundamentals
> it's really easy.  Also, once you get the cell up and running the
> day-to-day admin is pretty easy.  Basically you just need to create
> new accounts, create new volumes, configure (and run) backups, and
> balance servers.  Periodically you'll need to update the software.

I wish I could say I had the *time* for an AFS class -- to say nothing 
of the funds for a proper one.

> I don't know the size of your company, but a single person can handle
> this part-time for a small company.

We're really small -- just a firm of three people right now, but we 
anticipate growing by the fall. This is an exercise in forward thought 
and planning. Also, we figured it would be a good skill to learn. 
Personally I think distributed file systems are the way of the future.

>>First of all, this seems really very convoluted. It takes a lot to
>>confuse me, but I'll concede, this has me pretty confused. The
>>documentation is in classic IBM style -- comprehensive, yes, but
>>arcane, often ambiguous, and written in the sort of technical style
>>I'd forgotten even existed. Anyway, convoluted and confusing is bad,
>>especially when it comes to something as important as data
>>integrity. What if something goes sideways? What of our data? If it's
>>this confusing, is it really such a good idea for us to be trusting
>>our company data to it? How much time are we going to be spending
>>administering this? We simply don't have the full time resources to
>>dedicate to it.
> 
> 
> See above.  Once you understand AFS's architecture it's a LOT easier.
> An AFS course would probably help you significantly.  Once you
> understand the basics it becomes much less convoluted and complicated.
> Seriously.

The thing is, I think I understand the architecture, but like with any 
newcomer, there is a big difference between my conceptual understanding 
of what is happening and the detailed operational knowledge needed to 
execute tasks.

> There are a few known failure modes and it's extremely rare for
> anything to "fail sideways".

Here's the concern, probably typical of a noob -- "what if something 
goes wrong, and we lose our AFS infrastructure, but still have our 
partitions?" Is the data gone? How hard would it be for us to get it back?

>>Does OpenAFS have a real future? I know there are a fair number of
>>folks using it, but I really do think it has to get a whole lot
>>*simpler* to administer, for lack of a better word. I'll say it --
>>these last four days have been some of the most brutal days as a
>>sysadmin I've spent. Somebody talked about bleeding from the eyes... I
>>can relate.
> 
> Yes, I certainly think it has a real future.  IBM may stop shipping
> it, but that should just allow OpenAFS to continue on unleashed.
> Significant progress was made to AFS once it was released a few years
> ago.  There is a large amount of public support for the code.  It's
> not going away any time soon.

I'd like to see the docs get friendlier, and (being an open source 
advocate) I'd like to see the directions and support for *BSD and Linux 
improve too. Of course, provided I can learn enough, I'd be willing to 
contribute.

> IMHO, yes, it's worth the effort.  Again, you may want to get someone
> to teach you the basics to make the curve a bit easier.

Well, as I said, it's running, so it's not that bad... but I do have a 
lot of questions, and I'd love to be able to ask them here.

I did spend a lot of time reading the documentation because I wanted to 
fundamentally understand what was going on, and I also didn't want to 
pester the list with a bunch of questions that are adequately answered 
in the documentation... but I think I am at the point where I do need to 
ask some of those questions.

Stephen Bosch