Nixes Tool Set
Nixes provides a set of bash scripts to install, maintain, control and monitor applications on PlanetLab. It bootstraps the nodes with yum and lets the user install rpms from the PlanetLab distribution. Nixes was designed with simplicity and performance in mind. The tool is based on tree components: the scripts, a configuration file and a repository (public web directory) hosting your application.
All the tools take as argument a list of nodes, i.e. a list of fully qualified Internet addresses.
All the tools use public/private key authentication to log on the remote nodes via ssh. You specify the private key to use in the configuration file. If you protect the key with a password, you also need to add the key to an authentication agent (see the man page for ssh-agent and ssh-add).
- plsetup node-list
It bootstraps the vserver with yum, gzip and java
- plinstallrpm "rpms" node-list
It installs all the rpms on all the nodes, dependencies are resolved automatically (rpms must be part of the redhat distribution)
- pldeploy node-list
It deploys any file structure to the nodes
- plcmd command node-listIt executes any set of commands on all the nodes.
command refers to an environment variable containing the script to execute
It can be specified in the .nixesrc (see CONFIGURATION)
All the tools work in parallel with by default 30 threads. DO NOT START SEVERAL TOOLS IN PARALLEL YOURSELF. You will run into problems with the logs.
All tools write a log file per node basis in the directory specified by your TMP environment variable. You will only be notified about success, which means no error code returned. See the log for more detail if a failure happens.
The .nixesrc resides in the user's home directory and contains the configuration for all the tools. Some are shared same are only used in some scripts. The plcmd script supports custom options, which specify a script for an action.
- IDENTITY - the private key identity used to log on remote nodes
- SLICE - the slice name i.e. northwestern_02
- BOOSTRAP - the location of the bootstrap script (http/ftp)
- BASE - the base location of the files to deploy (http/ftp)
- FILES - files to deploy (located at BASE) including directory structure
- FILESBIN - executables to deploy (located at BASE) including directory structure
- <IDENT> - any identifier <IDENT> containing a shell script
The options may also be specified in your environment, as they share the same namespace as options specified in .nixesrc.
The bootstrapping process downloads a file to the nodes and executes it. The bootstrap script installs yum, a rpm installer/updater. It allows you to install any rpm by invoking 'yum -y install XYZ', where XYZ refers to a rpm package name (i.e. gcc). The rpms to install are specified at the top of the bootstrap.sh script. If you need to add your custom rpms not found on redhat mirrors, this is the way to go. See the file for further details.
The script also installs java on the nodes. Due to the licensing of java, you need to download the j2sdk from Sun yourself and host it on a public available server (only you know about). DON'T FORGET TO UPDATE THE LOCATION OF THE RPM IN THE BOOTSTRAP SCRIPT.
The rpm installation uses yum, which is installed during the bootstrap process.
The deployment script is fully configured within .nixesrc in your home directory. You need to specify a public available server, where you host your release. You need also to specify the file structure of you release. There is no recursive download option available. See the previous .nixesrc example script for details. Make sure all the files are available on the server as you specify in the script.
You can execute any script or command on all the nodes in parallel. In the .nixesrc example are two commands specified -- START and STOP. STOP specifies only one command to execute, whereas START specifies two on several lines. Follow this scheme for any custom commands. If the return code is 255, then the control script will echo the output of the command to stdout.
The scripts are written in bash. The scheduling is static interleaved and might not be the best choice. Further version may introduce dynamic scheduling.