This is a mini HOWTO on installing sfs as a server and as a client. I wrote this page just because I had a hard time finding the correct commands to issue, and I gathered there might be others interrested in this 'guide'. I assume you already have a working kernel with NFSv3 support active, either as module or compiled in, if not, fix that first. The server needs NFSv3 server support, the clients need NFSv3 client support.

On the server:

	# apt-get install sfs-server
	# cd /etc/sfs
	# sfskey gen -P sfs_host_key

This installs the sfs-server software, and generates a unique host key that SFS will use to encrypt the connections with.
Next you have to tell SFS what filesystems you'd like to export to each virtual path. This is done with the /etc/sfs/sfsrwsd_config file. First you specify a local path on the servers harddrive, then you specify a virtual path that your SFS users will see when they mount your SFS server:

	Export /this/dir/becomes/sfs/root/              /
	Export /another/fs/dir/is/subdir/in/sfs/root    /subdir

Now you stil have to tell the local NFS server that it should export those filesystems to the localhost by editing /etc/exports and putting in every filesystem you specified in sfsrwsd_config with the appropirate options:

	/this/dir/becomes/sfs/root/             localhost(ro,sync)
	/another/fs/dir/is/subdir/in/sfs/root/  localhost(ro,sync)

'localhost' tells it to only allow localhost access to this exported filesystem, the 'ro' stands for read only, and the 'sync' is a default flag that manages dataflow. Done? Okay! Then you have to restart all involved services:

	# /etc/init.d/nfs-kernel-server restart
	# /etc/init.d/nfs-common restart
	# /etc/init.d/sfs-server restart

And your /var/log/syslog should show messages like:

	sfssd: listening on TCP port 4
	sfsauthd: serving @host.domain.tld,kshgjkse6f676d54t0gusdblxdu56xd7
	sfsrwsd: serving /sfs/@host.domain.tld,kshgjkse6f676d54t0gusdblxdu56xd7

This means your SFS-server is ready to serve SFS mount requests.

---

Now for the clients:

Each user that wants to access the SFS mounts must have a user-account on the SFS-server machine. Each user must log in to the server and run:

	$ sfskey gen

Provide the correct information. The keyname is usually okay. The password you enter is the password you'll use to mount the SFS server, so make it a good one. After the key has been generated, you have to register yourself with the SFS server by issuing:

	$ sfskey register

The SFS server will prompt for your SFS-key passphrase, and then your shellaccount password. Enter both, and you're through. Now, on your client machine, you can:

	# apt-get install sfs-client
	# sfsagent user@sfsmasterhost.domain.tld

If all goes well, sfsagent will ask for your SFS-key passphrase, and when entered correctly, it will mount the remote SFS server on the local machine in /sfs. Take a look, you should find /sfs/sfsmasterhost.domain.tld as a symlink. Enter that, and your system should blurt out something like 'sfsagent: user@sfsmasterhost.domain.tld!sfsrwcd_1@LOCALHOST: @sfsmasterhost.domain.tld, kshgjkse6f676d54t0gusdblxdu56xd7 (1)'. This means it has mounted the remote filesystem. The random-looky-string-of-data is in fact your encryption key ID, or so was I told. The one I use here, isn't actually the one shown on my system, so don't bother ;)

Now, if you really like this idea, and you set up another SFS server, you'd probably be wondering why 'sfsagent user@anothersfsmasterhost.domain.tld' isn't working. That is a bit weird, but once sfsagent has been started (with the first mounted SFS server), it doesn't need to be started again. You can mount another SFS server next to a currently running SFS mount by issuing:

	$ sfskey add user@anothersfsmasterhost.domain.tld

It will then add the key of the other SFS host to the current 'sfsagent' process, and mount the remote filesystem in /sfs. That is, if your given passphrase is correct!.

---

It's not working? Check your firewall!

THEY told me this is basically what happens:
The server mounts the exported filesystems via NFS, on the localhost.
It then somehow reads and crypts the data, and sends it over tcp-port 4 (yes, a reserved port), to the client machine.
The client machine then unencrypts the data, and mounts that via NFS to localhost.

There. That's basically how it works. :)