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?
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
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
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
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.
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
(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.
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 52.52.32.221
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.
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.
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
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
So I don’t know. I still suspect a mishandling of network traffic somewhere