When should/if you update Designer Launcher?

When you do an upgrade of a gateway, when/if should you re-download the designer launcher via the “Get Designer” button on the gateway page? Should it be done for every upgrade? Just on major version changes? After looking through all the change logs and finding designer related issues?

And a related question, can designers etc become incompatible with the gateway they talk to?

The 8.1 installation documentation doesn’t seem to mention this aspect.

This is prompted by me just upgrading my test gateway from 8.1.0 to 8.1.1 I don’t expect to have an issue myself, but I want to be able to knowledgebly inform my clients down the road.

Unpatched software is one of the biggest attack vectors and one of the easiest to protect against. My advice is to update any time there is an update available

The Ignition docs say

Best Practice
It’s good practice to download and install the Designer Launcher every time you install a new release of Ignition. The Designer Launcher is a separate application and is not part of an Ignition release, so it’s important not to have an outdated Designer Launcher shortcut residing on your desktop

I would like to see the Ignition launcher have an auto-updater or at least check for updates

Me too :grimacing:


As of 8.0.13’s bundled client/designer launcher, you’ll get a prompt if you connect to a gateway that’s got a significantly different version of the launcher available. Not quite auto-updates, but pretty good.

In general - if you can launch a designer at all, you don’t need to care about versioning. The designer launcher is just that - a launcher - it doesn’t actually contain any of the required logic for the designer itself. That’s always fetched from the target gateway, so the launchers can be pretty much version agnostic (outside of major changes to how client/designer launch works, like what was required between 7.9 and 8.0).

That aside, they only get better, so there’s certainly no harm in updating :slight_smile:


if you can launch a designer at all, you don’t need to care about versioning

Until the point when someone finds an exploit and you didn’t apply the patch since it’s just a launcher. There’s certainly less risk of an exploit with a smaller codebase but running out-of-date software is generally bad practice and I think particularly egregious in this case since updating the designer launcher is minimal risk to your production environment

Remember when you could bypass the Windows login screen? Not quite apples to apples but that was good times :sweat_smile:

Where in the docs is that quoted text from? To my chagrin, when I went looking for it I discovered:

Upgrading Launchers

Whenever an Application is launched from a Launcher, the Launcher will check to see if it needs an update. If the Gateway containing launched application is several revisions ahead of the Launcher, the Launcher will provide a popup notifying you that an update is available.

However manual upgrades can be performed. Simply download and run a new launcher installer from a more recent Ignition Gateway. During installation, simply set the installation directory to the same directory as the old launcher.

I think ultimately the issue is that of communication. Once a project gets above a certain size you will have different people controlling the gateway software installations vs those who are building the application. So there is always the chance (ok 100% certainty) that one group doesn’t talk to the other about what version of software is in use. Thus is makes sense to automatically minimize the friction by getting the computers to do what they do best - talk to each other.

1 Like

My test gateway is running on Ubuntu (just to see how Ignition handles linux) and this morning Ubuntu told me that there were new updates available. After doing said updates (1) I could no longer open the Inductive website in Firefox (2) Thus Ubuntu stopped me from downloading some software called Ignition HMI, that’s apparently full of exploitable holes :laughing:

(1) As after all, I want to run an up to date system and not be open to exploits.

(2) I can browse various other websites, but not the Inductive site. Apparently this sort of behavior is well known, but nothing I saw after searching actually solved my problem.

I could no longer open the Inductive website in Firefox

I’m unable to reproduce this behavior on 18.04. Do you get a successful nslookup? Does the SSL certificate info look right? Any errors?

As after all, I want to run an up to date system and not be open to exploits

Ubuntu is a step in the right direction then! At least we have a package manager for everything else lol

This is on 20.04.1 LTS updated as of today. Firefox 84.0.2 (64 bit). Running in a VM under Windows 10
I just loaded youtube.com and www.wikipedia.org from firefox within this system, but I can’t get to support.mozilla.com
But I’ve also had the firefox crash reporter pop up a few times today.
nslookup works for inductiveautomation.com and returns
But I can’t ping it. Firefox fails to load, but it will redirect from the http:// to the https:// url of the site before dying.

Interestingly on windows and mac when I enter it gets redirected to https://inductiveautomation.com/maintenance?host=

Which pops up:

Scheduled Website Down Time

Please be aware that this Friday (7/19) there will be scheduled downtime from 6PM – 7PM PDT. Several online services will be unavailable during this time.

The following services will be unavailable:

  • Login Functionality

  • License Activation

  • Training Tests

  • ICC Virtual Ticket Sales

  • Training Class Sales

  • Integrator Account

  • Support Portal

But I can get to the correct inductive site via 2 other systems (windows and mac) so I know it’s just the Ubuntu system. My guess is something was screwed up with the update, but as this is a test system I don’t really care too much about that aspect.

It’s definitely local to your system.

I run 20.04 as my primary (bare metal) operating system. Updated yesterday. No problems.

Huh, if I had to guess what you run it would have been Debian + KDE. :man_shrugging:

I should be more precise: Kubuntu 20.04 is my workstation core. On a System76 Oryx Pro. (:

1 Like

Oh I know it’s me. And that it was working perfectly fine before I did that update :angry:

1 Like

I can’t ping it

They probably have ICMP traffic disabled, which is not uncommon (and even disabled by default in AWS)

Firefox fails to load, but it will redirect from the http:// to the https:// url of the site before dying

That’s a function of Inductive’s web server. The http:// is a 301 redirect to https://, which is the way it should be set up imo–there’s no excuse not to force SSL

I would run curl https://inductiveautomation.com in the terminal to narrow it down to a system-wide or Firefox-only issue

Which says to me that at least some part fo my network connectivity is working.

End result:

$ curl https://inductiveautomation.com
curl: (7) Failed to connect to inductiveautomation.com port 443: No route to host

try dig inductiveautomation.com.

Which is sort of what I was getting with nslookup

; <<>> DiG 9.16.1-Ubuntu <<>> inductiveautomation.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55781
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 65494
;inductiveautomation.com. IN A

inductiveautomation.com. 791 IN A

;; Query time: 0 msec
;; WHEN: Thu Jan 21 15:02:58 MST 2021
;; MSG SIZE rcvd: 68

No route on the default SSL port. You’ve got a firewall/routing issue

Run sudo iptables --list to make sure you don’t have any rules set on that machine then I’d start looking at how your other network devices are handling that traffic

Yeah it succeeds nslookup and goes forward with the 301 redirect, dig won’t tell us anything new in this case. You could curl the http://inductiveautomation.com and I bet it spits out the 301

Although I am curious how something like wiki is working since it’s also a 301 to https

edit: and the maintenance website works over https :thinking: So I don’t know. I still suspect a mishandling of network traffic somewhere