VDTConfigure

VDTConfigure - helpful functions for VDT configure scripts


SYNOPSIS

    use VDTConfigure "Package-Name";
    my $contents = &slurp("filename");
    &safe_write($contents, "filename");
    &post_install_log("some instructions...");


DESCRIPTION

Lately we have been working to make our configuration scripts more uniform and avoid duplication of code. The functions in this library are generally useful for installing and configuring software. Most also try to be as careful as possible. All functions return undef on failure.


METHODS

slurp(filename)

Read the whole file into a scalar

safe_write(filename, contents[, skip_registration])

Atomically writes the given contents to the given filename. If the file already exists, the existing version is saved as a backup and the changes are saved as a reverse diff in 'vdt/etc/package_data/<package>.configdiff'.

post_install_log(comments, nowrap)

Write to the VDT post-install log. This is intended to document necessary post-install steps and decisions made during the install process that the user may want to be aware of. If nowrap is set to true, this method will not use the wordwrap feature.

start_mysql

Start a VDT MySQL server (if it is not already running) and return the UNIX socket it can be contacted through. Looks for a running server by looking for a pid file in $ENV{VDT_LOCATION}/mysql/var. If a server is started it will not be listening on TCP/IP so you must contact it via the socket.

stop_mysql

Shut down a MySQL server started by start_mysql.

old_mysqldump

Run mysqldump from an OLD_VDT_LOCATION, setting up the environment properly.

rand_pass

Generate a reasonably random password

set_system_logfile

Sets the location for the output of commands executed by failsafe_system (and system, which calls failsafe_system). The default location is \$VDT_LOCATION/vdt-install.log. If this subroutine is called with no argument, the default is restored.

system

VDTConfigure overrides the default system() to redirect output to the install log and provide error checking. If you really want to use the normal system() just call CORE::system() or failsafe_system() instead.

failsafe_system

VDTConfigure overrides the default system() to redirect output to the install log and provide error checking. This version just provides logging.

vdt_install_log(comments)

Write to the VDT install log. This is intended to document debugging information we might want in order to fix a VDT install.

get_hostname

Returns the machine's fully qualified hostname. It was inspired by a similar function in Condor's condor_configure script.

get_ipaddress(host)

Given a hostname, we return an ip address This is abstracted out into a separate function so that we can support different ways on different platforms

start_tomcat(version, vdt_location)

Start Tomcat for the particular version and vdt location

stop_tomcat(version)

Tomcat is tricky to shut down. If it has not fully started up the init script will exit non-zero if you try to shut it down.

restart_tomcat(version, vdt_location)

In keeping consistent with the previous behavior, this function will try to stop Tomcat, and then regardless if it was able to stop Tomcat or not, it will start it back up

restart_condor()

Issue a restart command to Condor if it is running

check_ports(port1, [port2 ...])

Checks to see if the port is open for a service to run. If not, returns a string suitable for putting in an error message.

add_uninstall_command(cmd)

Adds a command to the uninstall script for this package.

select_user(default_for_root)

Returns the name of the user who is expected to run related processes. If the current user is not root, then this function returns the current user name. If the current user is root, then this function returns the first function argument (taken to be the name of a user), if that user exists on the system, or 'daemon' otherwise.

rotate_logs(full path to log files)

Adds selected files to the vdt logrotation setup.

mysql_port()

Returns the TCP/IP port on which MySQL is listening for the current installation.

mysql_socket()

Returns the UNIX socket on which MySQL is listening for the current installation.

mysql_datadir()

Returns the full path to the MySQL data directory. Each database is a subdirectory off of this path.

mysql_has_root_password

Returns whether MySQL has a root password set. Returns 1 for true, 0 for false, or undef if it cannot figure out what is going on with MySQL.

mysql_jdbc_copy

Copies the MySQL JDBC jar file to the specified directory

target - the directory to copy the jar file to

get_password_from_user

Gets a password from the user from standard input. This function assumes that the user has been prompted already. The code is derived from a Perl Cookbook item -- it doesn't echo the user's keystrokes back to standard output.

install_webapp_tomcat

Installs the given webapp into Tomcat, including the given context file, if provided. If the webapp looks like a WAR file, unpacks it; fixes ownership, removes any bcprov JAR file, copies the unpacked webapp directory into Tomcat, copies the context file, if given, into the correct location in Tomcat.

webapp_path - Full path to the webapp directory or WAR file

context_path - Full path to the context XML file --OR-- the basename of the webaapp directory to create in Tomcat

version - Tomcat version (4, 5, whatever) to install in.

make_init_header

Sorry attempt to generalize the construction of init script headers. This will probably need to be revisited as we move onto other platforms.

check_certificate

Checks a X.509 certificate file in PEM format (i.e., *cert.pem or *key.pem) to see if it exists and is usable. Returns 1 if the file is good, 0 otherwise.

which

This acts like the which command-line tool. It returns a string that is the full path to an executable with a name given by the first agument. If nothing can be found, the return value is the empty string.

create_vomsdir(dir)

Some packages require a dummy vomsdir directory to have at least 1 file in it This function can be passed a path to create or it will use the default If they are not root, thus unable to create the directory, we will post a message in the post-install README

bc_provider_copy

Copies the BouncyCastle Provider jar file to the specified directory

target - the directory to copy the jar file to jdk_version - the jdk_version of the file to look for (1.6 etc)

vdt_file_copy

A simple function that searches for the newest file in a source directory based on a pattern and copies it into a target directory If there is already a file that matches the pattern in the target directory, then we will not copy a new one

source - the directory to search for a file matching the pattern target - the directory to copy the file to pattern - the file name pattern to search for package - the package name (used for error messages)

vdt_version

Takes a VDT location as a parameter. Presumably it is not the current VDT location, but an old one.

Returns the string that describes the VDT version at that location, or the empty sting if there was a problem finding it.

component_version

Takes a VDT location as the first parameter. Presumably it is not the current VDT location, but an old one.

Takes a component name as the second parameter. These are the names that you find in the VDT version database. They are usually in all caps, and not meant to be pretty for users. Like CERTS for the certificates package.

Returns two values: the string describing the version and whether or not it appears to have been installed (0/1). The string is always returned if the component could be part of the VDT, because that information is always there, even if it is not installed.

compare_versions

Given two version strings, version_left and version_right, this function returns one of the following values:

1, if version_left is newer than version_right -1, if version_right is newer than version_left 0, if the two versions are considered equal

The function assumes that version strings are composed of equal numbers of numeric components separated by dots. To be on the safe side, characters besides digits and dots are removed before the comparison. Thus, version strings like ``2.0.0p0'' and ``2.0.0p4'' are considered equal.

get_process_info

Given a pid, returns information on that pid:

change_jndi_parameter

Purpose: Change a parameter value in a JNDI file.

Notes

- Will not add a paramter that is not already there.

- Built on simply search and replace. Likely problems include the same parameter name being used multiple times in the same JNDI file (only the first instance will be modified), or unusual XML syntax that causes the pattern match to fail.

Input

1. A valid JNDI file

2. Paramater name.

3. New value

Returns: Updated JNDI file. Will return an unmodified file if the old parameter can not be found.