Distributing Software

Besides performing jobs with its own API, a second major function of Openvenus is distributing software. The software currently supports Solaris packages, Linux packages in RPM format, and tarballs. Before you can distribute software, you need to check it into the Openvenus server. After that, the system lists, installs, or deletes the packages on request.

Maintaining the configuration files provides a constant source of work. If you modify a service on a server, you often need to let a few hundred clients on the network know. Openvenus manages a repository for such configuration files; hosts can be added to groups with the same configuration files, such as files specific to Solaris or Linux.

To edit the configuration files, you need to check out the file, change it, and check it back in again. Because the repository includes version control, configuration rollbacks are possible. Version control also applies to methods.

The ovpdistfile command then distributes the file to a client group. Openvenus batches the jobs if individual clients in the group list are unavailable, and multiple packages and methods can be combined into a meta-package to allow Openvenus to distribute consistent bundles. The API also provides a separate function that downloads the files to the client when the method is executed. This feature is especially useful when a service has not just one but several configuration files that always need changing together. All actions are logged by Openvenus so admins can keep track of who did what and when.

API for Methods

Methods use the API to access the framework. Bash scripts are the default for Openvenus, but other languages are also permissible, as long as they support the #! mechanism. More specifically, Openvenus accepts scripts in the format

#! **<Interpreter>: <Program>

This method even works on Windows systems that do not understand #! natively.

Scripts that run under the framework can reference a set of environmental variables that are internal to Openvenus. Additionally, admins can pass in their own environmental variables via a configuration statement. The API description identifies a number of utility functions, such as those for installing packages or accessing Openvenus information. Speaking of descriptions: The Openvenus documentation is acceptable as a reference but does not necessarily make it easy to get started.

Conclusions

In large networks with various operating systems in use, scVenus and its lean, free software descendant Openvenus really come into their own. One advantage of Openvenus is its support for fairly ancient operating systems, ranging back to SunOS  4, which was deprecated by Sun in the mid-1990s.

The central master runs commands and scripts and distributes software and configuration files. Administrators can group clients; Openvenus also automatically identifies the architecture and operating system. Because many features are based on scripts, they are easy to understand and designed to let the administrator customize and expand. Openvenus also comes with pretty minimal dependencies. For example, a Ruby installation, as required by Puppet, is not needed.

Other frameworks impress with more features and a large community that offers prebuilt recipes for standard tasks. The function of the one-developer show Openvenus, by contrast, is something that admins can understand. Former scVenus users who still have customized scripts and want to continue using them can look forward to the biggest benefits from Openvenus.