File Sharing Virtual Machine

Overview

The first step to being able to usefully share files is to have some files to share.

This guide is going to use the example that there is a website to be shared. Furthermore, this website will have “read-only” data, so there is no need to update any of the data on the website. (Any updates will be done separate from this “file sharing” process.)

There is nothing very significant about this decision of having the sample data be a website. The biggest impact is just that the sample directories will

There are multiple ways that this can be performed. For example, creating a brand new website can be one option. If this new network is built on computer equipment that can access some already-existing data, then that already-existing data may be more interesting (and perhaps also quicker) to access.

Address

This guide will provide details about setting up a fileserver that other machines can access for read-only access. System address plan has this at .65. (According to the same plan, another file server may already be running at .57 (which used to be .53 with an earlier version of the plan), which allows full (“read/write”) access. The key difference is that .57 is providing the ability to write, while .65 may be read-only.)

Having (virtual) hardware

See: creating and configuring a “child image”.

Accessing files
Overview: goal/agenda

Before a directory of files may be shared, that directory must be located. If there is existing data, identify where that data is.

The directory that will be shared should be on the local system. If the directory is on a remote system, determine where those files are.

This guide is designed around a scenario where data is known to be available from a remote resource that is already sharing files. People who are following this guide as part of a classroom environment should check the list of instructions for details on where files are being stored.

Steps to perform

First, try to make sure that routing is working. Using ICMP is often a good way to test this (via ping).

SMB Access

Using Server Message Block to access files...

Overview of some options

usmb on FUSE discussion indicates that usmb (see OpenPorts.se page on usmb may not be reliable (yet?)... A reply also mentions gvfs-smb (apparently related to GNOME virtual filesystem).

Forum post: Windows file sharing notes two tools, one of which is “samba”... “but there is no "mounting" capability for OpenBSD clients, which are limited to using the smbclient tool for file transfers, instead.” So, the alternative is: Sharity-Light.

(Samba's GPL license may be a factor of why there may have been little effort to work more fully with Samba's software, as noted by forum thread (post #21).)

So, the recommended solution (at this time) is to use Sharity-Light for mounting the drive. However, if you're looking for another way to simply verify that a directory is being successfully shared, Samba's client might be able to pull that off a bit easier.

Using Samba
Accessing SMB via Samba
Sharity-Light
Using Sharity-Light
Using NFS
Overview: About random TCP usage

This guide is going to open up a lot of TCP ports to make NFS work. That might seem quite insecure, and there are certainly other possible approaches. However, some of those approaches may not be recommended, as discussed further by this commentary: RPC Security Through TCP Port Control.

Firewall Handling

As described by RPC Security Through TCP Port Control, there are various approaches but this guide opens up lots of TCP ports. (For resources about using other approaches, see the text that was just hyperlinked.)

Firewall rules for the system that will be mounting

Know the IP address of the NFS server.

On the system that will be mounting the shares:

OpenBSD PF
cpytobak /etc/pf.conf
echo \# Permit TCP range that NFS may use| sudo -n tee -a /etc/pf.conf
echo pass out quick proto tcp from self to { 2001:db8:6::226 198.51.100.226 } \\| sudo -n tee -a /etc/pf.conf
echo \\tport 0:65535 modulate state| sudo -n tee -a /etc/pf.conf
echo \# Permit UDP range that NFS may use| sudo -n tee -a /etc/pf.conf
echo pass out quick proto udp from self to { 2001:db8:6::226 198.51.100.226 } \\| sudo -n tee -a /etc/pf.conf
echo \\tport 0:65535 keep state| sudo -n tee -a /etc/pf.conf
echo ${VISUAL}
sudoedit /etc/pf.conf

Make sure to customize the IP addresses. If all looks well, proceed.

sudo pfctl -nf /etc/pf.conf
echo ${?}
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf
Rules for the firewall “virtual machine”

Know the IP address of the NFS server.

On the system that is serving as a firewall:

OpenBSD PF
cpytobak /etc/pf.conf
echo \# Permit UDP and TCP ranges that NFS may use| sudo -n tee -a /etc/pf.conf
echo pass in quick on \$vmSvrs_if proto udp \\| sudo -n tee -a /etc/pf.conf
echo \\tfrom { 2001:db8:1::65 198.51.100.65 } \\| sudo -n tee -a /etc/pf.conf
echo \\tto { 2001:db8:6::226 198.51.100.226 } port 0:65535 keep state| sudo -n tee -a /etc/pf.conf
echo pass out quick on \{ $extern_nics \} proto udp \\| sudo -n tee -a /etc/pf.conf
echo \\tfrom { 2001:db8:1::65 198.51.100.65 } \\| sudo -n tee -a /etc/pf.conf
echo \\tto { 2001:db8:6::226 198.51.100.226 } port 0:65535 keep state| sudo -n tee -a /etc/pf.conf
echo pass in quick on \$vmSvrs_if proto tcp \\| sudo -n tee -a /etc/pf.conf
echo \\tfrom { 2001:db8:1::65 198.51.100.65 } \\| sudo -n tee -a /etc/pf.conf
echo \\tto { 2001:db8:6::226 198.51.100.226 } port 0:65535 keep state| sudo -n tee -a /etc/pf.conf
echo \\t# Do use \"keep state\"\; Do NOT use \"modulate state\" on TCP here!| sudo -n tee -a /etc/pf.conf
echo pass out quick on \{ \$extern_nics \} proto tcp \\| sudo -n tee -a /etc/pf.conf
echo \\tfrom { 2001:db8:1::65 198.51.100.65 } \\| sudo -n tee -a /etc/pf.conf
echo \\tto { 2001:db8:6::226 198.51.100.226 } port 0:65535 keep state| sudo -n tee -a /etc/pf.conf
echo \\t# Do use \"keep state\"\; Do NOT use \"modulate state\" on TCP here!| sudo -n tee -a /etc/pf.conf
echo ${VISUAL}
sudoedit /etc/pf.conf

Make sure to customize the IP addresses. If all looks well, proceed.

sudo pfctl -nf /etc/pf.conf
echo ${?}
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf
Testing Firewall Rules

Mounting is one option. However, if firewall rules block traffic, then the mounting may not succeed. As a general practice, having unsuccessful mounts is... less than ideal. (In the case of using Sharity-Light and killing off a process, such behaviors have been known to cause some problems.) Instead, another option that may be nicer is to use another available command that shows the available mount point(s) without going through the client-side changes of making a full mount.

show-mount -a 198.51.100.65

If that does work, there might still be some firewall issues. Basically, all that tested was Port Mapper (UDP port 111) and TCP, but other UDP packets are needed as well.

However, that can work with less traffic being passed, so if that doesn't work, that may be a better way to keep testing the connection until (at least) that works. Another test that may be useful, if the previous test isn't working, is to try the following, which can help to verify just the Port Mapper (UDP port 111) portion of the communications.

rpc-info -p 198.51.100.65
Mounting (single time)
sudo mkdir /srv/sample/
sudo mount -t nfs -o rw,nodev,nosuid,noauto remotesys:/fullPath/sample/subdir /srv/sample/
echo ${?}
ls -l /srv/sample/
Unmounting

When done:

sudo umount /srv/sample/
Re-used mounts

For mount points that will be re-used:

cpytobak /etc/fstab
echo remotesys:/fullPath/sample/subdir /srv/sample/ nfs rw,nodev,nosuid,noauto 0 0| sudo -n tee -a /etc/fstab
sudo mount /srv/sample/
echo ${?}
ls -l /srv/sample/
Sharing files
Sharing with SMB

See: sharing with Samba

Auto-start an SMB server

Currently some info at:

Sharing with NFS

Be warned: “No file-level security” (described by: NFS)

(Incomplete section... more updated needed...) Comments about re-exporting (“daisy chaining”) http://blog.e-shell.org/227 http://daemonforums.org/showthread.php?t=7528#post45958 http://www.openbsd.org/faq/faq6.html#NFS