[OpenAFS] Deploying OpenAFS on a working server ?

[Matthew Weigel]

Madhusudan Singh said:

>> Second, as I understand it Kerberos (which OpenAFS uses) is a 'shared
>> secret' authentication mechanism, meaning kaserver (or whatever) needs
>> access to the unencrypted passwords: thus /etc/passwd would not provide
>> everything required. You would have to migrate users over.
>
> Hmm. This could raise some hackles, but I guess it cannot be helped.
>
> Second question - isn't storing passwords unencrypted a serious security
> weakness ? I speak as someone who does not know a whole lot about
> kerberos.

It's why you don't want to have users on your Kerberos server (including
OpenAFS's built-in kaserver).  See the bottom of
http://www.oit.duke.edu/~rob/kerberos/kerbasnds.html -

"The entire authentication system depends on the trustability of the
KDC(s), so anyone who can compromise system security on a KDC system can
theoretically compromise the authentication of all users of systems
depending on the KDC."

On the other hand... this is true everywhere else too.  Password stores
are a security hole :-)

> Aha. This is a little more complicated than the simple client connects to
> the openafs server directly.

An openafs client will connect to the openafs server directly; however,
your current server (or any system that provides non-AFS services) will be
an openafs client in addition to being whatever else it is.

> Now, if the openafs client needs to run on a different server (to which
> users connect via ssh), two questions arise :
>
> 1. Can windows users (who could not be bothered with the internal details)
> mount their directories as drives on their machines ?

Yes, Windows can be an OpenAFS client, so that it has access to the disk
space on the OpenAFS server.  (see more below)

> 2. If there are issues with kernel 2.6, running this client on a second
> machine (which I have and is going to be running a mail server and a
> webserver) could be a problem. One possible "bright" spot is that the
> second
> server is not running linux but FreeBSD 5.3-RELEASE. However, the hard
> disk
> space on that machine is severely limited (about 10Gs) for any non web/
> non
> mail task (I just partitioned it that way).

First, see the other message regarding workarounds and "maybe"s
surrounding 2.6.

Second, I'm not entirely clear on what you mean here.  On a machine
serving as an openafs client, disk space for things in AFS (like,
presumably, home directories) is not required - it resides on the AFS
server.

> Hmm. Well, my idea was to run the openafs server on the fastest machine
> that I have.

Disk I/O and system bandwidth matter more.  Save the powerful CPU for
where users (or computations) are done.

> Let us say I have two machines (both with their FQDNs) A and B.
>
> A is a "slow" machine with less memory that has to run a webserver and a
> mailserver. It runs FreeBSD 5.3-RELEASE (as I indicated earlier). It also
> has very little hard disk space left over for users.
>
> B is a "fast" machine with a lot of memory that has to run a zope server
> (that
> the webserver above connects to), has a lot of hard disk space (I listed
> it
> in my initial email) and will also be used for running intensive
> computations. This is what I was planning to deploy my openafs server on.

I would say either

0- accept the security risks of running potentially exploitable network
services on your openafs server and run the openafs server on A (with at
least some added disk space, if not an upgraded disk subsystem)
1- migrate mail and web to B and use A as your AFS server, or
2- add machine C for $<=1k to be an AFS server.

(0) is easy, but involves some security risk (can you run mail/web chroot?
 do you have a good grasp of the security issues around running a web or
mail server?), and might be a performance bottleneck (but probably not if
you can run mail and web on the same system anyway).
(1) would be good if mail/web traffic would not significantly impact the
resources available for intensive computations.
(2) would be good otherwise, or if you want to stick with FreeBSD for mail
and web services, or any time (1) is not attractive.

>> To put that all together, my recommendation would be to
>> 1- leave things on that server as they are for now; budget time and
>> money for a second server (focusing and nothing but disks), and
>> configure that as an OpenAFS server;
>
> Hmm.
>
>> 2- set up your current server as an OpenAFS client;
>
> Ok. So, the where the files are stored is the client. And a second machine
> (say A above) serves as the openafs authentication server.

No, the files are stored on the server.  I know you want to use the disk
space on B for openafs, but it is not (or should not) happen when there
are users on B.

I'm sorry I was unclear on this.  Also, just to be clear, these numbered
things are steps - first you buy a new system to run the openafs server,
then you configure B to be a client, then you migrate users to Kerberos,
then you have a flag day for moving users into AFS space.

>> 3- create Kerberos principals for all users and slowly get them all to
>> set their Kerberos passwords;
>
> On B I presume.

Where ever your Kerberos server (presumably openafs' kaserver) is running
- a system where users don't log in.
-- 
 Matthew Weigel
 hacker
 unique@idempot.net