Creating UNIX Process Servers (Advanced)
Installing the platform agent manually requires you to choose a port, an instance name and a security mode beforehand. If you do not run the installation script with a privileged user, do not forget to run the root.sh
file, located in the current working directory, to complete the installation.
Prerequisites
- A running Redwood Server system
- A supported UNIX server with appropriate access to the server (including root password).
- A character set of which data can be converted to UTF-8 using the
I18N
tools is required, for exampleen_US.UTF-8
orISO-8859-15
. This character set needs to be set in the environment of thescheduler
startup script; you useLANG
orLC_ALL
environment variables to set the locale and thus the character set. The agent will useI18N
tools to convert the data encoded in the character set to UTF-8 to communicate with the central Redwood Server.LC_ALL
overridesLANG
as well as all the otherLC_
environment variables. - I18N tools (for character set conversion)
- The Korn shell, ksh or pdksh, needs to be installed if you are going to run KSH processes. The shell is available by default on most UNIX platforms, and is often the default shell. Not all Linux have ksh installed by default. There is an open source implementation usually known as
pdksh
that can be installed on most distributions.- The ksh binary must reside in
/bin/ksh
or you will have to create a symbolic link called/bin/ksh
pointing at it. - On Linux, the
zsh
shell also provides/bin/ksh
but its implementation is not POSIX compatible and may not be used.
- The ksh binary must reside in
- A Security Option. When you install a UNIX platform agent that will run processes as multiple users, you will need to decide what security option you would like to use. Redwood recommends you read the Choosing a User Switching Security Option through and discuss it with your system, network and security administration teams before installing.
- If you need support for other UNIX flavors (such as FreeBSD), please contact Redwood Support Services for more information.
note
If you are running Linux and are unsure of the installed glibc version, you can execute /lib/libc.so.6
in a terminal. Note that on some 64-bit Linux distributions the file might be located in /lib64/libc.so.6
(Suse/RedHat) or /lib/x86_64-linux-gnu/libc.so.6
(Debian/Ubuntu).
note
You must install the Redwood Server platform agent on a local file system; SAN file systems might be considered local, when they are mounted as iSCSI, for example.
You will encounter the following error message, when ksh
is not installed on your system in /bin/ksh
in the log of a KSH job:
error 2023-09-28 12:33:30,811 WST [14188-Main tid=4188101184] opsys.job
- Cannot execute Redwood Job 3281 '/home/user/jobs/3281/run_KSH': No such file or directory
Character Sets
Computer systems have been adapted more and more to support localization; this can be seen by the ever-increasing use of UTF-8 character sets which allow applications to support a great number of glyphs outside the US English or Latin alphabets. Redwood Server has been designed to run on systems in many geographical locations, so Redwood Server uses the UTF-8 character set internally. Platform agents communicate with the central Redwood Server so have to be able to convert data to UTF-8 prior to sending it. On UNIX, the I18N package provides tools for converting data from one character set to another; Redwood Server relies on this functionality to convert data to the UTF-8 character set.
You must specify the correct locale in use on your system in the environment of the platform agent. Redwood Server will assume the character set is ISO-8859-15
if the locale has not been correctly specified in the environment.
The following list contains some that are considered incorrect locales:
<empty>, <not_set>, 646, C, ANSI_X3.4_1968, POSIX, US-ASCII, ASCII
note
Setting an incorrect locale in the environment of the platform agent will potentially cause garbled text.
To inspect your current character set perform the following:
$ locale charmap
Procedure
The procedure consists of two steps:
- Installing the platform agent on the machine that needs to run processes.
- Configuring the process server in the repository.
Redwood recommends that you install and start the platform agent on the machine that you want to run processes first, and then configure the process server, however you can do these steps in any order.
Pre-Installation Tasks
Redwood recommends that you create a new account and group to contain the platform agent that satisfies your local naming requirements.
This documentation uses the account redwood and group redwood.
- Create the account:
groupadd redwood
. - Create the account:
useradd -g redwood -s /bin/ksh redwood
. - Create the home directory of the user:
mkdir /home/redwood
. - Change ownership of the directories:
chown redwood:redwood /home/redwood
. - Set the password for the account:
passwd redwood
. - Login as redwood:
su - redwood
orlogin redwood
.
Download the Software
- Log in to Redwood Server.
- Navigate to "Environment > Process Servers".
- Download the appropriate file for the platform you want to run processes on and copy it to your server:
- Select the OS family (Linux or UNIX, Windows, VMS).
- Specify a hostname; Redwood the hostname must be resolvable from the central Redwood Server, it is recommended to specify the FQDN of the remote server. For agent initiated connections.
Installation
- Run the installation shell script for your platform.
- Choose an installation location, like
/home/redwood/
, hit y to create the directory. - Choose an instance name.
- Choose a port the platform agent will use.
- Choose the security option.
- Choose if the platform agent should run at system startup, requires either
SysV init
startup script support orsystemd
(GNU/Linux, only). - Choose if you want to update the platform agent automatically, when the central Redwood Server is updated. The central Redwood Server will check the version at every startup and if they differ, the central Redwood Server will push the new platform agent software to the host and have it installed automatically.
Further platform independent configuration instructions can be found in the Configuring Platform Agents section.
Starting the platform agent at startup
Starting the platform agent at system startup is recommended. How this is done largely depends on your platform. If your platform supports SysV init or systemd.
If the installer was unable to configure automatic startup, you need to include the command corresponding to your security option in your system startup scripts.
Creating the Process Server
The installer creates a Process server automatically by contacting the server at the provided address during the installation procedure. If this fails or you want to do this yourself, follow the following steps.
- Navigate to "Environment > Process Servers".
- Choose Create from the context-menu.
- Fill in the values below.
Automatic updating
The UNIX platform agent supports Automatic Updating.
If the network processor is started by the platform agent the agent is capable of being updated automatically. The administrator can control whether auto-update should be performed by creating or removing the ${InstallDir}/etc/startup/${instance}/autoupdate
directory.
Renaming the Agent
This is not recommended and should only be carried out by platform experts, as the exact steps depend on your platform and configuration:
- Linux with systemd:
- Stop instance
sudo sysemctl stop scheduler@${instance}
. - Copy the
${install_dir}/net/instance/${instance}
to${install_dir}/net/instance/${new_instance}
. - Copy the systemd unit file
/etc/systemd/system/scheduler.service.wants/scheduler@${instance}.service
to/etc/systemd/system/scheduler.service.wants/scheduler@${new_instance}.service
. - Start instance
sudo sysemctl start scheduler@${new_instance}
, if all works as expected, delete/etc/systemd/system/scheduler.service.wants/scheduler@${instance}.service
.
- Stop instance
- Solaris with SMF:
- Stop and set
${instance}
service to maintenance mode (important, it will restart if not in maintenance mode). - Copy the
${install_dir}/net/instance/${instance}
to${install_dir}/net/instance/${new_instance}
. - Start instance
${new_instance}
.
- Stop and set
- Generic Sysv Init:
- Stop instance
scheduler stop-instance ${instance}
. - Copy the
${install_dir}/net/instance/${instance}
to${install_dir}/net/instance/${new_instance}
. - Start instance using
scheduler start-instance ${new_instance}
, if all works as expected, delete${install_dir}/net/instance/${instance}
.
- Stop instance
Removing the Software
There is no automated process for removing the software. However, the following will remove everything associated with the software:
- Find the install directory of the software you want to remove, this is ${InstallDir}.
- Stop all instances running in this directory.
- Remove the installation directory ${InstallDir}.
- Check
/etc/init.d/
,/etc/rc.d/init.d
,/sbin/init.d
,/sbin/rc3.d
,/etc/systemd/system/scheduler.service
, or/Library/LaunchDaemons
(depending on the UNIX variety). If it contains ascheduler
script or scheduler.service unit (systemd), edit it and remove the ${InstallDir} path from the line in the beginning of the scripts containingPATHS=
. If you have no remaining installations of the platform agent on this machine, remove the script entirely.
Values
The necessary configuration Data required to configure a UNIX process server is available in the UNIX Process Server Configuration Data section of the documentation.
See Also
- Using the Wizard to Create Process Servers
- Configuring Load Balancing on Platform Agents
- Automatically Updating Platform Agents
- Securing Communications for Platform Agents and System Tools
- Creating a Monitoring Platform Agent
- Monitoring External Systems with Platform Agents
- Creating a Monitor Check
- Reversing Network Connections to Platform Agents
- Platform Agent Registry Entries