Skip to content

User Gateways

Jude Nelson edited this page Feb 12, 2014 · 4 revisions

Overview

User Gateways (UGs) are application-facing Syndicate end-points that run on client devices. They let you read and write data and metadata in your Volumes, as well as cache it for other UGs in the same Volume.

There are four UG implementations: a FUSE filesystem, an HTTP object store, a client library (supports C, C++ and Python), and a Hadoop connector.

Prerequisites

Before creating and using UGs, you will need to have created a Volume on your MS.

Creating a UG

Before running a UG, you need to provision one with syntool.py via the create_gateway command. You will need to create one UG for each user and device that will access the Volume.

For example, to create a UG called my-syndicate for user [email protected] to access Volume ExperimentData from node10.princeton.vicci.org:33333, run the following command:

$ syntool.py create_gateway [email protected] \
                            ExperimentData \
                            UG my-syndicate \
                            node10.princeton.vicci.org 33333

You will be prompted for your Syndicate password, as well as a private key password.

Remarks

If you want to allow [email protected] to access ExperimentData from a set of different hosts, you will have to create a separate UG for each host. As such, it can be a good idea to chose UG names that include the host and port (e.g. my-syndicate-node1-port1, my-syndicate-node2-port2, etc.) to make it easy to remember the gateway name for a particular host.

While running, the UG must authenticate itself to the other Gateways and MS. It does so with a per-UG private key, with which it signs messages. By default, syntool.py automatically generates a 4096-bit RSA private key for the UG, encrypts it with your private key password, and gives the MS the public key and the encrypted private key. The UG will automatically download and decrypt the private key, if it cannot find one locally. This saves you the hassle of doing key management yourself, but requires you to pick a very good password.

Using the FUSE filesystem

The FUSE filesystem syndicatefs takes the following arguments, in addition to any FUSE command-line options you want. The first non-option argument is the mountpoint.

  • -m [MS URL]: Your MS's URL
  • -u [username]: Your OpenID username
  • -p [password]: Your OpenID password
  • -v [volume name]: The Volume name
  • -g [gateway name]: The UG's name on the MS (that you gave with syntool.py)
  • -P [port number]: The port to listen on
  • -G [private key]: The path to the UG private key
  • -K [private key password]: The decryption password for the UG private key
  • -V [public key]: (optional) The path to the Volume's public key
  • -f: (optional) run in the foreground
  • -F: (optional) (DANGEROUS) do not flush pending writes on exit

For example, the following command (passwords omitted) will mount the Volume called "Experiments" on /mnt/syndicate, using the MS at https://syndicate-metadata.appspot.com. It will use the account "[email protected]" and the given password to authenticate to the MS.

$ ./syndicatefs -m https://syndicate-metadata.appspot.com \
                -u [email protected] \
                -p ******** \
                -v Experiments \
                -g my-syndicate \
                -K ***** \
                /mnt/syndicate

Key-Based Authentication

You are free to supply the private key manually, if you don't want to have Syndicate manage your keys for you. To do so, you will need to pass gateway_public_key= to syntool.py. The value must refer to the path on disk where your already-generated 4096-bit RSA public key resides. You are responsible for getting the private key to the right host, and giving it to the UG via the -G switch. If you want syntool.py to generate the private key for you, pass MAKE_SIGNING_KEY instead of a path (the resulting key will be in $HOME/.syndicate/gateway_keys/).

Notes for PlanetLab/VICCI/OpenCloud users

The MS used by PlanetLab, VICCI, and OpenCloud is federated with an OpenID server running on VICCI. This means you can pass your VICCI username and password as the above OpenID credentials (these will be the same as your PlanetLab credentials, since VICCI and PlanetLab are federated).