On Thu, Aug 11, 2005 at 01:52:07PM -0400, [EMAIL PROTECTED] wrote: > I've never really understood the definition of "Enterprise-class" > either. I think it means being extremely scalable, the ability to > span across multiple servers in multiple locations (geographically), > and the ability for multiple other systems to communicate with each > other. Am I wrong on this? What is the exact definition of > "Enterprise-class"?
I struggled a bit with this too. When naming my cryptographic filesystem, I had to find some way to differentiate between it and its predecessor, Cryptfs. In the grand tradition of modern technology, I decided to put a letter in front of it. So then I narrowed my options down to xCryptfs (Extended Cryptfs), iCryptfs (too Mac-like, and I couldn't think of a good word that starts with 'i'), or eCryptfs (Enterprise Cryptfs). Hmmmmm. After thinking for a while about the design goals and the target for the filesystem, I figured that ``Enterprise'' wasn't a bad fit (see p. 209): http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf When deploying technology for an enterprise environment, there are certain assumptions that one can make in terms of requirements and resources. For example, there is likely to be an IT department. There are also likely to be a large number of systems that require a consistent set of policies among them. Hence, you have the components for a framework of some sort -- technologies like Kerberos, LDAP, or PKI come to mind. My filesystem is designed to be able to leverage such a framework in order to provide functionality that enables corporate policy while utilizing corporate PKI in such a way so as to be completely transparent to the employees who are using the filesystem (only the IT folks will ever have to be bothered with the details). If that ain't ``Enterprise'', I don't know what is. I elaborate in my paper; go ahead and read it and let me know what you think. For those who really have some time to kill, my OLS paper from last year focuses on ``enterprise'' requirements and is the predecessor for this year's paper. I did a compare-and-contrast among all of the various crypto filesystems that were out there at the time (it's a bit outdated now; several filesystems -- i.e., EncFS -- have adopted some of my suggestions since then) and discusses how they fit into enterprise environments: http://halcrow.us/~mhalcrow/ols2004.pdf Of course, I will be the first to say that ``Enterprise'' refers to intended deployment target based on its set of features more than anything. It still has several months before I would say that it is as robust as, say, dm-crypt. But then again, it does comprise 14,000 lines of code, 8,000 of which are in the kernel. That's going to take a little while to fully test and debug across all platforms (x86, x86-64, PPC, PPC64, s390, s390x, ...). Developers/tested wanted. ;-) http://sourceforge.net/projects/ecryptfs Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C 20F5 DB40 8531 6DCA 8769 "This is about humans being human." - Carl Sagan
signature.asc
Description: Digital signature
.-----------------------------------. | This has been a P.L.U.G. mailing. | | Don't Fear the Penguin. | | IRC: #utah at irc.freenode.net | `-----------------------------------'
