Linux Virtual Machine Ignition Installation Checklist

Apr 24

by Adrienne Harvey, Systems Engineer

Recently, a Corso Systems customer had a very specific challenge which needed to work at scale. They contracted us to make them a custom application to help them quickly scan and collect product data from thousands of pallets and over one million serial numbers. Since we made their application with Ignition, their IT team prepared a Linux VM (virtual machine) where we could install Ignition, our custom Ignition application, and a Postgresql database. They wanted to keep everything together and chose to have us put the database on the VM as well. Beyond setting up the VM, their IT team would be hands off, and we wanted to be sure to get the installation up and running as quickly as possible without needing them to intervene.

Unfortunately, before this experience I had run into a fairly serious permissions issue on my practice server VM server when first installing Ignition Maker Edition a few weeks before. And while Ignition Maker Edition was successfully running on my server, it was because I’d forced the issue with some regrettable chown-related choices with some large and inconvenient repercussions. So, while I had actually done a very similar command line installation and Ignition was indeed running on that server, I wanted to get this done the right way the first time for our customer. I reached out to Senior Systems Engineer–and fellow Build-a-Thon 2023 teammate–William Bohn for his advice and to help me build a checklist to make it all happen smoothly on site.

An Ignition Installation Checklist

I do really love a checklist - if they’re good enough for pilots and surgeons, then I want one too! And while this example checklist is somewhat specific to the situation I described above, it could be a starting point for any number of specialized checklists to use or to use in training.

1. SSH into the VM and verify that the server stats are what we need—and are at or above what Ignition will require to run

2. Check for existing Ignition installations or other software which may conflict with your new Ignition installation. If the VM is new, you can likely skip this step.

3. (This step was specific to our customer’s request, you may wish to connect to a database that’s already running somewhere else - in that case, skip this step as we’ll add that database connection in Ignition later. On my cloud VPS server running IgnitionMakerEdition, the database connections are to a couple of MySQL databases running on an otherwise underutilized legacy webhosting account!) Install Postgresql database, making sure to correctly allocate the database and database users during the process.

4. IMPORTANT STEP: Create a system user which will run Ignition. This is where I’d run into trouble on my IgnitionMakerEdition Cloud VPS server installation, and where William’s expert advice came in handy:

sudo useradd -r ignition

His explanation below suddenly made everything make sense. I’d used adduser on my server out of habit! PalmForehead!

“useradd is the lower level utility compared to adduser. Super confusing. You want to use the lower level for the -r flag, which creates a no-login (system) user”

5. Download the Ignition installer to the VM. Before time I had found the correct installer on the Inductive Automation website, then gave a referrer to download it directly to the VM

curl -fsSOL --referer <insert full link to the Ignition installer of your choice>

6. Make that Installer executable, so you can run it (use the actual filename of the installer that you downloaded instead - the command below is just an example):

chmod a+x ignition-8.1.37-linux-64-installer.run

7. Install Ignition, and include that system user. If you don’t add this, it’s not a big deal, the installer will ask you to specify a user in that case. (Related documentation from Inductive Automation)

./ignition-8.1.37y-linux-64-installer.run -- user=ignition

Follow the installation prompts and make the choices appropriate for your installation. A successful “shortcut” choice I made on my IgnitionMakerEdition server was to choose a custom install. I only included the modules I knew I would be using so that I wouldn’t need to remove them later after licensing. For example, MakerEdition doesn’t use the Vision Module for example, so I skipped installing it from the beginning. Similarly, our Ignition application for the customer was built with the Perspective Module, so we also did not need to install the Vision Module (or other modules they both didn’t need–and which would have required extra licensing such as the Enterprise Resource Management module).

8. Start the Ignition Gateway! For Linux (or Mac) the command is below - but please consult the Inductive Automation’s documentation first, especially if you are running Windows.

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

9. Open your web browser and navigate your VM’s IP address plus port 8088 to access your newly installed Ignition Gateway. For example it might be something like http://10.0.0.10:8088

10. Apply the appropriate Ignition license

11. Apply custom branding (this particular customer’s employees were not familiar with Ignition, and I wanted to make sure that we applied their branding to their gateway which would then appear on their application login screens to reduce confusion. Another great example of the #IgnitionEffect is that users don’t necessarily even need to know that their application is made with Ignition to use it effectively!

12. Create the users, roles, etc. as necessary for the project or to fulfill the customers’ needs.

13. In this situation I then installed our most recent, fully tested and prepared Project Export via the Gateway.

14. Open a Designer and make any last minute checks, changes, and/or run any queries you need for preparing your project. In our case, I only needed to run the incredibly useful Project Initialization Script that Senior Systems Engineer, Tommy Fahlgren wrote as a one-step way to complete the database setup for this project. After I ran this script in the Script Console, the necessary queries set up and populated the database tables that the project needed.

15. Test the project by logging in as a user on one of the dedicated laptops the customer wanted to use. In this case, I also needed to adjust the Windows Display Settings. Often, Windows will be set to display at 150% by default and not 100%, so don’t panic if your views/pages (especially if you used coordinate containers) suddenly look big and weird on a customers’ laptop—even if you’ve built your views specifically sized for the specs they gave you for their displays!

16. High five your customers’ team, then if necessary, teach the appropriate parties how to add users, take gateway backups, etc.