Push and pull network filesystems with ccgfs

The CC Network Filesystem (ccgfs) lets you mount filesystems over the network using either the push or pull model for connections. Most network filesystems use the pull model, where the client mounts a network share and all connections originate from the client. Using the push model for network shares means that all connections originate from the server. The push model has advantages when you want a machine on your network demilitarized zone (DMZ) to access a file server through a firewall.

If you wanted to use NFS to allow a client on your DMZ access to a network share on serverX, which is not in the DMZ, you would have to allow connections from the DMZ to serverX. Using the push model, the network connections would originate from serverX to the client in the DMZ.

There are no packages of ccgfs in the Fedora, openSUSE, or Ubuntu repositories. I’ll build from source using version 0.7.4 of ccgfs on a 64-bit Fedora 9 machine. The main ccgfs dependency that you probably don’t have installed already is libHX, for which packages are included in Ubuntu Hardy, openSUSE 11, and the Fedora 9 repository. You need version 1.25 or later of libHX to build the latest version of ccgfs; if the version included in your distribution is too old, you can build libHX from source using the normal ./configure; make; sudo make install process. One potential snag in building your own libHX is that you have to export PKG_CONFIG_PATH to include /usr/local when building ccgfs as shown below.

ccgfs is a FUSE filesystem, so you need to have the FUSE development packages installed before attempting the build. On Fedora 9 and openSUSE 11 this is fuse-devel, and on Ubuntu Hardy it’s libfuse-dev. Other dependencies that you probably already have installed include libattr, libxml2, and libssl.

The commands to build and install ccgfs are shown below. Because ccgfs includes an init.d script and looks for configuration files in sysconfdir, I have specified that that be /etc instead of the default /usr/local/etc. Likewise, I used the global /var directory by including the localstatedir option when running configure.

$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
$ tar xjvf /FromWeb/ccgfs-0.74.tar.bz2
$ cd ./ccgfs-*
$ ./configure --sysconfdir=/etc --localstatedir=/var
$ make
$ sudo make install

Once ccgfs is installed you should be set to connect. To make the connection example a little clearer I’ll assume that the machine you want to export the filesystem from is called serverX and the client machine on which you want to mount the filesystem is called clientY. The path to the filesystem you want to export on serverX is /export, and you would like to mount that path at /import on clientY.

On serverX you will want to create the configuration file /etc/ccgfs-super.xml as shown below. The most interesting part is the <s> line, which contains the command that gets things started. The -s parameter is the path on serverX that you want to export, and the -m parameter is how to connect to the clientY machine and where you want to mount the filesystem on it. You can also take advantage of the Host entries in your ~/.ssh/config file in the -m parameter. For example, if you need to manually select an identity file or connect using a different port, you can configure such a Host entry in your ~/.ssh/config and use it in ccgfs-super.xml.

# cat /etc/ccgfs-super.xml 
<?xml version="1.0" encoding="utf-8" ?>
<ccgfs-super>
<kill-margin>5</kill-margin>
<restart-wait>10</restart-wait>
<s>ccgfs-ssh-push -s /export -m root@clientY:/import</s>
</ccgfs-super>

The init.d file that is installed along with ccgfs uses commands such as checkproc and startproc; they can be found on openSUSE machines but not Fedora ones. On a Fedora 9 machine you can replace the openSUSE-specific commands with versions from the functions file to start the daemon as shown in the below modifications. Once you have the init.d file set up on serverX for your Linux distribution of choice, starting the ccgfs-super service on serverX should allow clientY to access /export on serverX.

# vi /etc/init.d/ccgfs-super
...
. /etc/init.d/functions
...
case "$1" in
    (start)
        [ -n "$verbose" ] && echo -n "Starting ccgfs-super";
#       checkproc "$daemon_bin" && echo " (already running)";
#       startproc -sp "$pid_file" -- 
#               "$daemon_bin" -f "$config_file" -p "$pid_file";
        daemon "$daemon_bin" -f "$config_file" -p "$pid_file";
        rc_status -v;

# /etc/init.d/ccgfs-super start

Because the filesystem is using the push model, it is not necessary to issue any commands on clientY to mount the filesystem. Everything is configured and started on the serverX machine.

ccgfs uses SSH to authenticate with remote machines. For push filesystems, authentication happens from the server that is exporting the filesystem to the client that is mounting it. All connections happen from the file server to the client. This gives an added layer of security if you want to access a filesystem from a DMZ machine, because no machines in the DMZ need to be authorized to make connections or authenticate with the server. A machine in the DMZ needs to only allow connections from the file server it uses.

Using the push model to export filesystems moves configuration of both the server and client onto the server machine. From the client’s perspective, files can be stored and read from a path on the filesystem just as they can from any other path.