Step 1: Installing JobScheduler through setup
In order to have a folder structure for the later installation of JobScheduler on Solaris (without a setup), it is highly recommended to do a first installation of JobScheduler in a Linux environment. We could do that on Solaris as well, however, errors would be thrown when using the setup, since some commands are not allowed on Solaris but on Linux.
The next recommendation is to install JobScheduler using the same configuration you will use on Solaris, that means:
- Database (server, port, etc)
- JobScheduler ID
- JobScheduler port
- Mail server
- Installation path
- deselect option "launch JobScheduler"
It is also recommended to set SCHEDULER_HOME and SCHEDULER_DATA with the same path, this has a couple of advantages for our procedure:
- Only one file has to be compressed for the afterwards transfer to the Solaris machine where the real installation is intended
- No symlinks are needed for folders
logs
ordata
.
Following files or folders should be modified after the installation was completed succesfully:
- Delete the following libraries within the folder
lib
:libgcc_s.so
libgcc_s.so.1
libsosperlscript.5.18.2.so
libsosperlscript.so
libstdc++.so.6
libstdc++.so.6.0.8
- Delete the following files within the folder
bin
:scheduler_safe.sh
setuid
- Clear the content of the
logs
folder - Delete the folder
Uninstaller
: this will not work on a Solaris environment, since it was not a standard installation and will look for paths it is not going to find.
After having completed that, compress the folder that contains SCHEDULER_HOME and SCHEDULER_DATA and transfer it to the Solaris machine and extract the folder.
Once the folder structure is ready and clean, adjust the rights giving the JobScheduler user the necessary rights for these folders.
Step 2: Compiling JobScheduler sources on a Solaris machine
The third step is compiling the JobScheduler sources on the Solaris machine. This step has to be done following the instructions on the article How to build the JobScheduler Engine and the JobScheduler components from the sources for Solaris.
Only the content of the projects scheduler-engine-doc
and scheduler-engine
will play a role and the sources have to be compiled in this order:
scheduler-engine-doc
scheduler-engine
Step 3: Configuration after compiling sources
Once the JobScheduler sources have been compiled, the following has to be configured:
- From the compiled sources
.\scheduler-engine\engine-setup\target\setup\scheduler.linux-x64\bin
:- Replace library
libjobscheduler-engine.so
by the generated one under the folderlib
- Replace the application
scheduler
by the generated one under the folderbin
- Replace library
- Within the folder bin:
- Adapt to Solaris syntax the file
jobscheduler_environment_variables.sh
- Check the syntax for the start script
jobscheduler.sh
- Adapt to Solaris syntax the file
- Check the configuration for the following files under the folder
config:
factory.ini
- Add mail adresses if required
- Add SMTP server name if required
hibernate.cfg.xml
jetty.xml
scheduler.xml
sos.ini
sos_settings.ini
web.xml
- In case you could not use the same database during the installation on Linux, do the following to create the tables for this JobScheduler:
- Edit
HOSTNAME
value in./db/[dbms]/scheduler_instances_insert.sql
- Execute
./install/scheduler_install_tables.sh
- Edit
- Download SWT from Eclipse site
- Extract the content
- Select the file
swt.jar
- Substitute this file for the one under
./lib/3rd-party/org.eclipse.swt.gtk.linux.x86_64-4.3.jar
Step 4: Updating JobScheduler
A procedure should be implemented for updating JobScheduler in this case. The recommended from our side is the following:
- Use the setup to update JobScheduler on the Linux machine
- Write a script that would delete the folders as indicated on Step 1: Installing JobScheduler through setup
- Use the same script to carry out any action done in Step 3: Configuration after compiling sources
- Use the same script to stamp the files that have been replaced or modified with a "-template" at the end, for example "
factory.ini-template"
. That way- you have a template on a Linux machine
- moreover, the modified files are not overwritten when unpacking the tarball file on the Solaris machine