Poking SFS through a Linkys Router/Cable-modem

>Poking SFS through a Linkys Router/Cable-modem

Following some comments on the SFS mailing list (particularly from Mark and Roger), I was able to get my home machine to export SFS through my Linksys router and cable-modem. Here's my attempt at a 'How-To' ...

Router Config:
The Linksys router has a web-based control panel for configuring the services and altering the operation of the router. The router always shows up at 192.168.1.1 from the internal network. It can serve out DHCP, but if you power-cycle several machines (as in your laptop and desktop), it seems to hand out 192.168.1.100 first, regardless of what the client was assigned previously. To make life easier, I set up my Linux desktop machine to have a fixed address, at 192.168.1.4.

Note that there is a configuration page for DHCP which allows you to set a range on the DHCP addresses. By default, this starts at 192.168.1.100 and allows 50 clients. So assign your desktop machine something below that range so it doesn't interfere with other machines that may need DHCP.

Next, you have to make sure that TCP port 4 is forwarded to your server. This is in the "Advanced" configuration tab, under "Forwarding". You just click to enable the ports you want, click on what IP to forward them to (192.168.1.4, or whatever your server is fixed at).

Server Config, Part 1:
If you don't know what your "outside" address is, you can check on the "Status" page of the router's control panel. You can use "dig -x" to find out what your "outside" name is. Put this into the /etc/sfs/sfssd_config file:

Server user-xyz.cable.foobar.com
 Release *
  Service 1 sfsrwsd
  Service 2 sfsauthd
#  Service 3 rexd

In this case, I also turned off "rex" remote execution.

Server Config, Part 2:
We also need to configure the "sfsrw" (read-write) server, this is done through the /etc/sfs/sfsrwsd_config file:

Hostname user-xyz.cable.foobar.com
Export /var/sfs/root /
Export /data /data

In this case, I'm only exporting one directory which is mounted on my desktop as /data, it will show up as /sfs/user-xyz.cable.foobar.com/data to the outside world.

Authentication Server:
The last part of the server we need to configure is the authenication server. This is done through the /etc/sfs/sfsauthd_config file:

Hostname user-xyz.cable.foobar.com
Userfile -update -passwd -create -pub=sfs_users.pub sfs_users

The file actually has lots of useful comments in it, but those are the only two un-commented lines in it right now.

Starting the Server:
Ok, one last thing before we start the server, we have to generate the keys. I think if you do this before now, you may end up with parts of SFS thinking the server is '192.168.1.4' and other parts thinking it is called 'user-xyz.cable.foobar.com' ... and your sfs clients will think someone is spoofing you.

sfskey gen -P /etc/sfs/sfs_host_key

Now, I think you can start the server. On Linux:

service sfssd start

Client Config:
The clients just work! I didn't need to change or add anything to the configuration files to get the clients working. Just the usual:

sfskey register

while logged into the server, and then:

sfskey login user@user-xyz.cable.foobar.com

from any remote client. I also found that from my laptop, I could also connect with:

sfskey login user@192.168.1.4

and this would put in the same virtual directory, /sfs/user-xyz.cable.foobar.com/.

Initially, I was having problems with the clients choking and saying that the server was being spoofed or that the server name didn't match the authenticated name. You may need to kill the sfsagent to get rid of any old keys you may have had (use "sfskey kill").

last updated on 9 March 2004, by John Pormann, Duke University (john-dot-pormann-at-duke-dot-edu)