Administrators

If you are an administrator, then you are set with the responsible for installing and maintaining Vsys and associated scripts. You can install Vsys from its source code [#!vsys-source!#] or from a pre-built binary package [#!vsys-bin!#]. If you use the source code, then decompress it and run the following commands as root:

The installation might fail because of missing dependencies. If so, make sure you have the following packages:

ocaml
ocaml-doc
inotify-tools
inotify-tools-devel
kernel-headers

Next, edit the configuration file for vsys: vsys.conf to declare the set of users that are to be given access to vsys.

Each line in the configuration file declares a user (e.g. pl_netflow) and a directory to which the user has access, in which the vsys frontend will be populated. Although vsys will create the the frontend directory if it does not exist, it is recommended that it be created separately independent of vsys.

Vsys can be invoked in two ways: through its initscript, and directly by executing its binary. Have a look at its initscript to see the options available. The main configuration option is the backend, which is the location in which you drop vsys scripts and Access Control Lists (ACL) files, so that they become available to users.

Here is an example of executing vsys:

The failsafe option instructs vsys to never crash. This feature was designed for PlanetLab, on which many critical services require vsys to function. With this option, vsys will try to recover, however serious the error might be. The backend specifies the location at which scripts are dropped (explained below).

Once vsys has been started, the next step is to install the vsys scripts that have been developed for your environment. You may find common vsys scripts on the vsys homepage or elsewhere. Please review the next section for instructions on how vsys scripts are developed. Deploying a new vsys script happens in two steps:

1. First, an ACL file is created in the backend directory to specify the set of users that have access to the script. The name of this ACL file must be in the form $<$ name$>$ .acl, where name is the name of the script to be deployed.

   
   
   

   Here, the users pl_netflow and some_slice are being given access to the script, newscript, which is to be installed. Next, we actually install the script:

   
   
   

   Thus, the newly deployed script has become available in the frontend of the user. Vsys reacts dynamically to such events. To remove a script, you can simply delete the script from the backend. Vsys will remove the corresponding entries from the front ends automatically. Similarly, you can organize the scripts in a directory heirarchy.

   
   
   

If you are administrating a deployment of PlanetLab (MyPLC), then the process is somewhat different. In particular:

• Vsys will come pre-installed as part of the node software, and with a set of common scripts. You might want to check that the latest version of vsys is being used. The latest version can be found at the vsys homepage [#!vsys-homepage!#].
• The /etc/vsys.conf file will be set up and populated by the Node Manager, based on a set of vsys slice attributes. More information on this process can be found in the Node Manager documentation. The Node Manager will also create and manage all required ACLs. A slice attribute can be specified in the PLC gui. Select ``Add a slice attribute'' for the slice that you would like to be able to access vsys. Set the name of the new attribute to 'vsus' and the script to the vsys script.
• The frontend and backend are already defined. The frontend can be found in the /vsys directory of each slice.

  When using vsys on PlanetLab, all scripts are managed by the Node Manager, except for scripts prefixed with the string local_. These scripts are meant for local installation and can be used to give users temporary access to a resource.