Posted by: Administrator
on December 04, 2004 04:19 AM
With the very real security concerns mentioned here I'd like to point out 2 possibles.
1. SHFS <A HREF="http://shfs.sourceforge.net/" title="sourceforge.net">http://shfs.sourceforge.net/</a sourceforge.net> is a remote file system that basically feels like NFS from an adminstrative viewpoint, but since it is operation over SSH (openSSH or SSH) it has the advantages of, a secure connection and the ability to work with key pairs to limit liability as far as password security problems go. I've also had a lot of luck with it in that it also can survive intermittent drops and improper disconnects very well. (Just like ssh does)
Reads and writes are seemless and allow for inclusion in fstab for auto mount/umount at boot/shutdown or for simplified mount commands if you choose to use it on demand.
One other nice part is that it is now part of the 2.6 kernel and modules are also available for inclusion in 2.4. It can also be built without requiring a full kernel rebuild. In fact since the product includes the ability to do a make (rpm deb tgz) it's very simple to create and distribute it out to any number of systems on your network.
Personally the longest "distance" I've used it is between California and Michigan in the US. At that distance (and given that both ends where broadband one an ISP the other a Cable Modem) I found the speed to be reasonable, for reeds and writes. Using it on a LAN and without invoking any kind of compression I've found it to be about 90% of local disk write speed. It can be used to run executables. So I have been able to use it as a Home dir, install OOo to that dir and have a user launch it without a problem.
Missing attributes. No Local Cache. If you aren't connected you lose access to an application running from an shfs mounted directory. It cannot handle conflicts, in respect to a situation where 2 people "check out" a file at the same time and then write back. It's a case of he who writes back last wins. Great for single user directorys of data files. All work is syncronous just as it would be on a local drive. If you loose connectivity you won't be able to easily "save" a file for later write back.
The Second is a correction/ introduction of sorts. Where as Intermezzo did start as a result of the incompleteness and problems with Coda. It's real roots go into the Andrews File System. Now that CMU and IBM have turned it Open Source, and with the tremendous amount of work done by the developers. <A HREF="http://openafs.org/" title="openafs.org">http://openafs.org/</a openafs.org> It has also been included in the 2.6 kernel.
This FS has excellent security, in that it uses kerbos for encryption. Near local speed once connected (I've seen it used by Stanford Linear Accelerator Personel from Italy connected back to the US in California) It is able to also use any of a number of authentication protocols to ensure that ONLY those you want get connected. Since Once a file or application is "launched" it is cached locally You are able to continue your work even though the connectivity is gone and then once you re-connect it is able to handle Conflicts/Mergers/etc.
Andrews has an excelent ability to handle file locking and merger (Two people check a file out, the second one to write back does so merged. Similar in nature to the way CVS handles mergers (though not exactly the same, I'm trying to paint a mental picture not create a technical paper.)
The biggest "downside" to Andrews is initial setup. However once it's up and running it's nearly trivial for someone to sit down at a box. Setup their "environement" and get to work.
It also has the ability to do disconnects. Meaning that you can be working on a project at location A, disconnect, then move to location B and reconnect without missing a beat.
Both of these projects are actively being developed. I know openAFS is being used by a number of very large corporations as well as major Universities (Stanford for one.) as such improvements and growth is very strong with both, and both in present form are more than sufficiently reliable for deployment and use for even the most delicate situations. If the Linear Accelerator people can rely on it for use to work with experiments that take years to setup and run just once then it's got to be solid enough for anyone.
Learn about Linux
Download Linux
Get Linux help
In addition.
Posted by: Administrator on December 04, 2004 04:19 AM1. SHFS <A HREF="http://shfs.sourceforge.net/" title="sourceforge.net">http://shfs.sourceforge.net/</a sourceforge.net> is a remote file system that basically feels like NFS from an adminstrative viewpoint, but since it is operation over SSH (openSSH or SSH) it has the advantages of, a secure connection and the ability to work with key pairs to limit liability as far as password security problems go. I've also had a lot of luck with it in that it also can survive intermittent drops and improper disconnects very well. (Just like ssh does)
Reads and writes are seemless and allow for inclusion in fstab for auto mount/umount at boot/shutdown or for simplified mount commands if you choose to use it on demand.
One other nice part is that it is now part of the 2.6 kernel and modules are also available for inclusion in 2.4. It can also be built without requiring a full kernel rebuild. In fact since the product includes the ability to do a make (rpm deb tgz) it's very simple to create and distribute it out to any number of systems on your network.
Personally the longest "distance" I've used it is between California and Michigan in the US. At that distance (and given that both ends where broadband one an ISP the other a Cable Modem) I found the speed to be reasonable, for reeds and writes. Using it on a LAN and without invoking any kind of compression I've found it to be about 90% of local disk write speed. It can be used to run executables. So I have been able to use it as a Home dir, install OOo to that dir and have a user launch it without a problem.
Missing attributes. No Local Cache. If you aren't connected you lose access to an application running from an shfs mounted directory. It cannot handle conflicts, in respect to a situation where 2 people "check out" a file at the same time and then write back. It's a case of he who writes back last wins. Great for single user directorys of data files. All work is syncronous just as it would be on a local drive. If you loose connectivity you won't be able to easily "save" a file for later write back.
The Second is a correction/ introduction of sorts. Where as Intermezzo did start as a result of the incompleteness and problems with Coda. It's real roots go into the Andrews File System. Now that CMU and IBM have turned it Open Source, and with the tremendous amount of work done by the developers. <A HREF="http://openafs.org/" title="openafs.org">http://openafs.org/</a openafs.org> It has also been included in the 2.6 kernel.
This FS has excellent security, in that it uses kerbos for encryption. Near local speed once connected (I've seen it used by Stanford Linear Accelerator Personel from Italy connected back to the US in California) It is able to also use any of a number of authentication protocols to ensure that ONLY those you want get connected. Since Once a file or application is "launched" it is cached locally You are able to continue your work even though the connectivity is gone and then once you re-connect it is able to handle Conflicts/Mergers/etc.
Andrews has an excelent ability to handle file locking and merger (Two people check a file out, the second one to write back does so merged. Similar in nature to the way CVS handles mergers (though not exactly the same, I'm trying to paint a mental picture not create a technical paper.)
The biggest "downside" to Andrews is initial setup. However once it's up and running it's nearly trivial for someone to sit down at a box. Setup their "environement" and get to work.
It also has the ability to do disconnects. Meaning that you can be working on a project at location A, disconnect, then move to location B and reconnect without missing a beat.
Both of these projects are actively being developed. I know openAFS is being used by a number of very large corporations as well as major Universities (Stanford for one.) as such improvements and growth is very strong with both, and both in present form are more than sufficiently reliable for deployment and use for even the most delicate situations. If the Linear Accelerator people can rely on it for use to work with experiments that take years to setup and run just once then it's got to be solid enough for anyone.
#