On Nov 8, 2004, at 2:50 PM, Mike Burns wrote:
Greetings,
At Penn State we eventually (next 18 months or so) need to migrate away
from DCE/DFS and to something else. OpenAFS is one of the choices we're
considering for replacing DCE/DFS. We used AFS before we moved to DCE/DFS
and have been testing OpenAFS a little since last fall. There are some
features that we're used to having in DCE/DFS that work differently or are
currently missing from OpenAFS. I'm hoping to receive some comments on
the status of these features - development is in progress, not in
progress, not likely, easy to implement, difficult, whatever. Some of
these already appear in the Project List on openafs.org but it appears to
be a little out of date and I'd like to hear the current status.
- Native Kerberos 5 and support for multiple strong (better than single DES) encryption types. I've used the migration toolkit patch to get K5 support, but would rather not have to do that each time we upgrade to a new version of OpenAFS.
Jeffrey Altman already informed me that this will be worked on at the AFS Hackathon next month and make it into OpenAFS 2.0, but that it would not be stable enough for the 1.4 release. There may not be anything more to add to this.. Is there a projected timeframe for the release of 1.4 and 2.0?
If Jeffrey says so ... :-) We'll see.
- A secure RPC / packet privacy. This should be solved by above, right?
We'd like to enforce packet privacy for secure file service on the file
server side like in DCE/DFS and not rely on the client admin to remember
to enable it.
- AFS/NFS translator for any one of Solaris, AIX or Linux. I tried it on
Solaris 9 and encountered knfs issues as per bugid 1480. Does it work
well on any of these three platforms now?
I had it running for a rather short period of time on AIX and nobody complained but it was more of a nice backup access to the system than real use and therefor consider it "untested".
You can still run a userspace NFS-server on Linux (I did that one, too). It's a little bit slower but it works. If you use that as a main access to your system consider installing AFS clients.
I know, this is less difficult to say than to do.
- UBIK best host algorithm rather than lowest IP#.
Who is best?? Who gets the veto??
Lowest IP is just one of many solutions, actually one that's already there.
- File level ACLs.
We had this talk before. I don't know anything about any project regarding this topic.
We'll get a lot of trouble in OpenAFS with that but maybe it's a good topic for the Hackathon, too.
- Volume names longer than 22/31 characters.
Is this a "must have" or just a "want to"... ???
- Faster fileserver process start up and stop times. This has improved
greatly from when we used to use AFS, but can still be slow for large
number of volumes on a server. At some point after 10K-40K volumes are on
a (Solaris 9) server start/stop times can jump from less than 30 seconds
to a handful of minutes and even 10-20 minutes. We'll have a minimum of
160K volumes. We probably have enough file servers now to stay around
10K volumes per server, but if we decide to use .backup volumes that
number will double and we may hit the performance inflection point.
In your tests, did you use the --fastrestart switch on configure??
- Incremental file level backups. I haven't looked into this with
OpenAFS. We've always used IBM's TSM which supported backing up/restoring
ACLs for files and directories with DFS and AFS. Do any backup products
support this for OpenAFS or would we have to back up an entire volume at a
time?
That depends on what you want to backup and when. I think we don't have the resources to compete with TSM.
Do we actually want to??
You cannot do a filelevel incremental backup when your atomic units of the system are volumes unless you use AFS as a normal filesystem and backup it like any other filesystem by use of the client. Maybe somebody comes up with a clever idea on this one. You can backup your partition for example from the fileserver or something like that.
Horst
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
