Scope

Best Practice: Recommended Steps

Step 1: Installing JobScheduler through setup on a Linux environment

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:

  1. Only one file has to be compressed for the afterwards transfer to the Solaris machine where the real installation is intended
  2. No symlinks are needed for folders logs or data.

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 next 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:

  1. scheduler-engine-doc
  2. 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 folder lib
    • Replace the application scheduler by the generated one under the folder bin
  • Within the folder bin:
    • Adapt to Solaris syntax the file jobscheduler_environment_variables.sh
    • Check the syntax for the start script jobscheduler.sh
  • 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
  • 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:

  1. Use the setup to update JobScheduler on the Linux machine
  2. Write a script that would delete the folders as indicated on Step 1: Installing JobScheduler through setup
  3. Use the same script to carry out any action done in Step 3: Configuration after compiling sources
  4. 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
    1. you have a template on a Linux machine
    2. moreover, the modified files are not overwritten when unpacking the tarball file on the Solaris machine
  • No labels