Page History

...

This  This document explains the most essential installer features.

...

• With the exception of Open-AudIT, which can be installed on Windows Server or Linux, all Opmantek applications are available for Linux 64-bit systems only.
  Redhat/CentOS6, Debian 7, Ubuntu 10 and newer are supported (basically anything running glibc 2.3 and up).
• The latest versions of our applications can be found at: https://opmantek.com/network-tools-download/
• To run the installer you need superuser/root access on the system in question.
• Please note that as of Feb 2017, all Opmantek applications require that /tmp is mounted with execute permissions (i.e. mounted without  the noexec mount flag).
  See below for an alternate procedure if your /tmp is non-executable.

...

1. The simplest way to achieve this is to type "sh ./opProduct-version.run"
2. You can also modify the permissions of the .run file to indicate that it is executable, then start it directly
   To do so, you'd run "chmod u+x ./opProduct-version.run" followed by "./opProduct-version.run"

...

You can also pass options to the interactive installer component, but these must follow after a "--" delimiting argument:

• MIS9 NMIS9 Compatible OMK Application Installers created on or after 2020-08-18 will include a new option '-D':    Dependency Check Mode  to assist with installation in a disconnected (air-gapped) environment:
  • When run with  Dependency Check Mode  enabled the installer will not perform an install, but write a file containing a list of dependencies to the /tmp/ directory.
    For example, sh ./opCharts-4.1.1.run -- -D  run as a normal user, would start the installer in Dependency Check Mode (-D) and only create a list of dependencies at /tmp/omk_dependency_check_opcharts upon completion.
• If you want to perform a simulation run of the installation, use the -n option: the installer will only print what it would do, what files it would copy and so on, but will not perform any of these steps.
• By default the installer is interactive and will prompt you for decisions and confirmations; If you want to run it in non-interactive batch mode, use the -y option.
  In this case all dialogs and prompts are automatically answered with the default answer (usually 'y').
• The -p preseed-file option, supports a feature for better non-interactive installations: answers to the installer's questions can now be preseeded before the installer is invoked. See Smarter non-interactive installation with Preseeding
• Please note that in non-interactive mode the installer will abort upgrades if critical incompatibilities (e.g. license type) are detected; the option to overrule the installer in such situations is only present when the installer is running interactively.
• Certain installer choices can be preset for non-interactive mode:
  1. Setting the environment variable NO_LOCAL_MONGODB to a non-empty value instructs the installer to not install a local MongoDB server even if none is present.
     Please note that you will have to manually adjust the Opmantek daemon init scripts or systemd unit files after installation, as these express the dependency on a local  local MongoDB installation.
  2. NMIS9 compatible Opmantek Applications released after 13 May 2020 will offer a more comprehensive option '-m f' or '-m F' to instruct the installer to  to skip all MongoDB related instructions completely during the install.
     This option is more comprehensive than environment variable NO_LOCAL_MONGODB.
     NO_LOCAL_MONGODB only prevents install of MongoDB, but does not not skip other MongoDB related instructions that will be executed by the installer.
     Please note that you may have to manually adjust the Opmantek daemon init scripts or systemd unit files after installation, should these express the dependency on a local  local MongoDB installation.

• If you want to install the product into a non-standard directory, you can pass the argument -t <targetdir> to the installer component.
  Please note that you will have to adjust a number of configuration files in this case.
• It is possible to generate more detailed diagnostic output in the installer log file, using the -d option.

...

Product Coexistence, Migration and  and Upgrades

Before installing any Opmantek software components, a thorough check of the existing state of your system will be made to ensure that the new product does integrate correctly with other already existing Opmantek products. This check relies on the software manifests stored in the installation directory (default /usr/local/omk) and the product tarball, and thus won't be fully precise if no manifests exist.

When an installation of older/legacy Opmantek products is detected or if the manifest is missing, then the installer will take a comprehensive backup snapshot of your installation directory first. This is to ensure that you could revert back to the pre-installation state quickly and with minimal downtime, should the installer unexpectedly fail  fail the coexistence check or break existing old applications. Here is an example of the prompts in this situation:

...

• What's this warning about "incorrect checksum detected"?
  This can happen very infrequently,   if you are installing an older Opmantek application on top of newer ones, or if you've made extensive changes to your system's Opmantek files.
  We strive hard to line up our releases properly so that everything meshes cleanly, but every now and then there are minor changes to files that older installer versions aren't quite aware of.
  
  In general this warning dialog is safe to answer with 'yes' and the installer will leave your system in a consistent working state (by replacing the unrecognizable/mismatching file with a known good version from the shipped product).

...

Because Opmantek applications share code and modules wherever  possiblewherever possible, uninstalling a single application is not completely trivial.

...

• Removal of all Opmantek daemon init scripts from /etc/init.d
  This may include init scripts for omkd,   nmisd, opeventsd, opconfigd, nfdump, opflowd.
  You should stop the daemons before removing the init scripts.
• Removal of cron schedules for the Opmantek applications
  This may include files in /etc/cron.d named oae, opaddress, opconfig, opevents,
  opflow, opreports, optrend.
• Removal of all of /usr/local/omk, /var/log/omk, /data/omk
  The latter two may not be present (but will be if your system started  started as an Opmantek Virtual Appliance).
• Cleanup or removal of the Opmantek applications' MongoDB databases
  Unless you are actively using MongoDB you might simply stop the mongod daemon and remove the database files (typically under /var/lib/mongodb or /data/mongodb for the Opmantek VM).