Page History

Ignition Default Installation Directories

The default directories for each operating system are listed below. 

Windows

C:\Program Files\Inductive Automation\Ignition

MacOS

/usr/local/ignition

Linux

/usr/local/bin/ignition

MacOS and Linux Installation Directory

Mac and Linux installations contain a ignition.sh file and ignition-util.sh file, which both contain some configuration parameters for the installation. Modifying these files is not advised, unless directed to by a member of our support team. Instead, an ignition.shconf file, which is also located in the installation directory, should be used instead. 

Additionally, during installation on Mac and Linux, the installer will create a sudoer file at installationDirectory/etc/sudoers.d/99-<serviceName>, with the service name being Ignition-Gateway by default. This ensures the Gateway can be restarted without an interactive login. In most cases, the sudoer file does not need to be modified or maintained. However, more information can be found in the ignition-util.sh file in the installation directory. 

Quick Start Configuration

Once the installation process has finished, you'll be redirected to the Gateway Webpage. From there you'll be asked to opt into the Quick Start configuration, which makes several configuration changes to the system. Quick Start can only be enabled upon a new installation.

The following changes are made once Quick Start is enabled:

• Creates an internal SQLite database connection.
• Configures a device connection to a Programmable Device Simulator instance, and adds Tags from the simulator into a Tag provider. 
• Configures an internal alarm journal.
• Creates a sample project. 

Start or Stop Ignition

After installing with the Installer, Ignition will have a service representing it on the operating system. By default Ignition will start when the system starts, but you can manually start and stop the system with the following terminal commands:

Windows

The examples below assume "Ignition" is the service named used during installation (which also happens to be the default service name). You may need to modify the examples below using your system's service name. 

net start Ignition
net stop Ignition

Mac

/usr/local/ignition/ignition.sh start
/usr/local/ignition/ignition.sh stop
/usr/local/ignition/ignition.sh restart

Linux

The examples below use the default installation directory

/usr/local/bin/ignition/ignition.sh start
/usr/local/bin/ignition/ignition.sh stop
/usr/local/bin/ignition/ignition.sh restart

Upgrade Ignition

Upgrading Ignition is as easy as running the installer. When you run the installer from the same directory as a previous install, our installers are able to detect that Ignition is already installed. If Ignition is already installed, the installer will ask if you would like to proceed with the upgrade. A wizard takes you through the upgrade in a similar workflow as installation workflow. 

Before completing the upgrade process, it is strongly advised to take a gateway backup of your system first. 

Ignition installers can be used to upgrade any edition of Ignition (i.e., Edge, Maker, or Standard) with the exception of ARM as that will require a zip installer for upgrading. 

During the upgrade process, the Gateway will have to restart, so make sure to account for downtime when upgrading. 

When you upgrade Ignition, you'll also be given the option to update any additional modules you currently have installed, including Third-Party modules.  On the Select Modules screen, there is a tab for the modules included in your version of Ignition, and a tab for Additional Modules you may be using.  Under the Action column, you can choose to upgrade or remove the module or leave it unchanged.

Updating License for an Upgrade

If you are updating from one major version to the next (i.e, upgrading from version 8.0.# to version 8.1.#) , you will need an updated license. You can do this before upgrading so there is no unlicensed time after the upgrade.

1. Let us know.
   You can reach Inductive Automation by phone at (800) 266-7798.
   Some Major upgrades include new modules or have modified the functionality of pre-existing modules. If your license needs to be updated, call us and we can guide you through it. If you are updating from one version to the next, or from 7.0.0 all the way to the latest version, we can talk you though what is different and what new functionality is available. See the New in this Version page for more specifics about what was updated in the various versions.
   
   
2. Reload your license. 
   Once your license is updated in our system, go to your Config section of the Gateway webpage, and click System > Licensing. Click on the Update License icon .
   For for a detailed guide on reloading a license, see updating a License on this page. If you are coming from an older version, the Gateway may look different. Don't worry, all this functionality is still there, but you may have to un-activate then re-activate instead if the Update License button is missing.

Upgrading a Redundant Pair

There are a few extra things to consider when upgrading a redundant pair of Gateways. When performing the upgrade locally, we recommend upgrading the Master first. This allows the Backup to take over when the Master is down for an upgrade, and the Master can resume operations when it comes back online. At this point the Backup can be upgraded without interruption. The same considerations mentioned above should also be applied to the redundant pair, but you only need a Gateway Backup file from the Master Ignition Gateway.

If the upgrade will be performed remotely using the Enterprise Administration Module, then the Backup Gateway should be upgraded first. This allows the EAM controller to manually tell clients/sessions to communicate with the newly upgraded Backup Gateway, even though the Master will be a different version, allowing time to upgrade the Master.

Depending on what version you are upgrading, you may have to choose between a few different upgrade method options to determine what will work best for your needs. If upgrading version 8.1.0-8.1.16, following the recommended process above will still successfully upgrade your system, but you'll need to manually resume Master control and take down the Backup. Based on how you resume your Master control, you may have duplicated data from the slight overlap of having both Gateways up or experience downtime when taking the Backup down before bringing the Master back up. Alternatively, you can use the following procedure to upgrade without disrupting your redundancy setup: 

1. Navigate to Status > System > Redundancy on your Master Gateway. 
2. Select Force Failover to set your Backup as your active Gateway.
3. Navigate to Config > System > Redundancy on your Master Gateway.
4. Adjust the Startup Connection Allowance setting to a large number. This will allow the Master to sit in the undecided state and not become active after being upgraded. Note the original value so you can reset it at the end of this process. 
   
   
   
   
5. Upgrade and start your Master Gateway.
6. Wait for the Master to fully initialize and become ready to take back over. 
7. Shut down your Backup Gateway. 
8. Navigate to Config > System > Redundancy on your Master Gateway.
9. Change the Mode setting to Independent. 
10. Change the Startup Connection Allowance setting to 0.
11. Select Save Changes.
12. Select Confirm. 
13. Now, change the Mode setting back to Master.
14. Select Save Changes.
15. Select Confirm.
16. Upgrade your Backup Gateway. 
17. After the upgrade is complete, verify your Backup Gateway is connected and your redundancy is active. 
18. Navigate to Config > System > Redundancy on your Master Gateway. 
19. Return the Startup Connection Allowance setting to the original value. 

Reset the Password

To reset the main password for the user with full privileges, use the Gateway Command-line Utility (gwcmd) utility.  The 'gwcmd' utility triggers system commissioning, and prompts the user to reset the username and password for the main user (with full privileges) after the Gateway restarts.  Linux and Mac OS platforms also use the 'gwcmd' utility for password reset. For more information, see the Gateway Command-line Utility - gwcmd page.

Uninstall Ignition

To uninstall Ignition, run the uninstaller file. This file can be found in the main Ignition installation directory, for example:

C:\Program Files\Inductive Automation\Ignition\Uninstall.exe

/usr/local/ignition/Uninstall.app

/usr/local/bin/ignition/Uninstall.run

Verify that Ignition Software is Genuine

Code signing is applied to installers to help the OS prevent the installer from being run if it has been tampered with.  Notarization is an additional step on macOS that works with Apple’s systems to validate that the software has undergone their malicious code scanning.

Windows

View verification of the digital signature on Ignition’s installer on Windows in the User Account Control popup when running the installer. It can also be viewed in the Digital Signatures section of the file Properties dialog. 

1. Right-click on the installer and select Properties.
2. Under the Digital Signatures tab, select the signature from the Signature list and click Details.
   
3. If the text "This digital signature is OK" appears under the General tab, the installer is genuine and has not been manipulated.
   

MacOS

On macOS, verification of the digital signature of the Ignition installer can be done using the `codesign` utility from the terminal:

codesign -dvv <path to mounted installer.app file>

Linux

Linux does not support a standardized certificate verification method. Linux users should verify that the download is authentic by comparing the hash of their file to the Inductive Automation website.

Verify the Download is Authentic by Hash Comparison

The Ignition automated build process writes a precalculated fingerprint (hash) to the download site allowing users to verify the authenticity of the download file. On the Downloads page, click sha-256 to view the hash for your selected installer file. You may also copy this hash to your clipboard for comparison.

A SHA256 hash of the downloaded installer package can be compared to the values on the website with terminal commands such as:

Get-FileHash path\to\installer

sha256sum /path/to/installer

Verify an Ignition Module Download is Authentic - Advanced

Ignition modules are collections of files and resources that are loaded and run by the Ignition Platform.  Inductive Automation publishes a number of modules and third-party authors can also create modules through the Ignition Module SDK.  In order to help verify file integrity of these modules, code signing is applied to ensure that the contained files and resources within the module package have not been tampered with.

Verification of a given Ignition module’s code signatures is handled automatically by the platform.  The following manual verification steps (requires

`openssl`

openssl) are listed below to provide a fuller understanding of the mechanisms at play:

1. Extract the .modl file as a zip file into a working directory.

2. Observe the contained

`certificates

1. certificates.

p7b`

1. p7b file which is a PKCS#7 package containing the certificate chain used for generating the signatures for each of the files within the .modl package.

2. Observe the contained

`signatures

1. signatures.

properties` file

1. properties file.  Each line contains a path to a file within the .modl package and a base64-encoded signature for the file.
2. Extract the public key

`signingPublicKey

1. `signingPublicKey.

pem`

1. pem from the

`certificates

1. certificates.

p7b`

1. p7b file with the following steps:
   openssl

1. pkcs7

1. -outform

1. PEM

1. -in

1. certificates.p7b

1. -print_certs

1. >

1. certificates.cer
   openssl

1. x509

1. -pubkey

1. -noout

1. -in

1. certificates.cer

1. >

1. signingPublicKey.pem
2. Decode the base64 content for a given file (from

`signatures

1. signatures.

properties`

1. properties) into a signature file, e.g.

`signature

1. signature.

sign`

1. sign.
2. Verify the signature of the file with the following:
   openssl

1. dgst

1. -sha256

1. -verify

1. signingPublicKey.pem

1. -signature

1. signature.sign

1. <file

1. from

1. .modl>
2. Observe a “Verified OK” message indicating that the signature from

`signatures

1. signatures.

properties`

1. properties for the respective file is correct.