I'm starting to use a lot of Ignition Edge Panel systems in lieu of traditional HMI's, and to keep the cost competitive I need to automate as many parts of the setup as possible - given that a traditional HMI comes basically set up and ready to go out of the box, the engineering time to install and configure a PC is something I need to minimise. I have a batch file which I already use to set up the Windows configuration the way I want it, now I would like to add the "download and install Ignition" bit to it.
I've found the documentation on command line installs which gives me a brief run down and some of the flags I can use.
I've found this forum post which gives details on an additional flag to use to specify Edge edition
And I've found this older forum post which talks about using an options file to specify which modules I want to install.
But I can't find any official documentation on the latter two.
Ultimately what I want to end up with is a script that does the following. Items in standard text I have under control already, I just need to work out the ones in bold:
Downloads the latest version of Ignition
Runs the installer more or less silently (I will probably use a minimal progress bar)
Installs Perspective, Allen-Bradley drivers and the other mission critical modules but nothing else
Selects Edge edition
Configures the firewall
Starts the gateway service
Can anyone help me out with links to documentation I've not been able to find, or more details on things like the options file?
The scripts in a docker image are probably the best resource for the remaining pieces you need. Just be aware that the typical base for such fully-automated installs is Linux, not Windows.
I've not used Docker; I come from an electrical background, not a software one, and I'm the most technical/software-savvy person in my company. We're a small outfit.
And yes, I agree that Linux would be better if it were an option. For reasons unimportant to this question, that's not something I can entertain for most of my applications, unfortunately.
Regardless of where the scripts reside (or what OS I'm running them on), I still need to find the documentation for what I'm trying to do.
I have done all this before, the first thing you do is ditch Windows. Windows doesn't belong on embedded systems, and companies making non-IT people do embedded platform integration with insecure software platform that are not designed for the task is just plain stupid.
I didn't say to use docker, but that its scripts are your best resource for finding the stuff you need. Whatever platform you do.
That makes using Linux even more important, as your odds of producing a reliable, secure system goes way up. If you don't have a huge IT department creating your custom Windows deployment tools, and maintaining security on whatever you end up with, you are [expletive]ed.
Strongly disagree. If you cannot do this properly (and it sounds like you cannot), consider hiring an outside provider to help.
Not everything is formally documented. The docker implementations are effectively documentation, as Linux bash scripts are human-readable.
You're missing the point. I could absolutely use Linux, but if I did, the client would hire someone other than me to do it on Windows. I appreciate your perspective, and I don't disagree, but my client base is clearly quite different to yours, and right now my issue is "where is the documentation for scripting Ignition installs" not "why do I have to do this on Windows instead of Linux".
Thanks! I've had a read through that page and the thing that I'm not quite sure about is the description for the GATEWAY_MODULES_ENABLED flag...
A comma-delimited set of built-in and third party fully-qualified module identifiers that whitelist modules and restrict them from being uninstalled.
...so does that mean if I add GATEWAY_MODULES_ENABLED="allen-bradley-drivers,logix-driver,opc-ua,perspective" to my install batch file it will only install those modules? It doesn't really read that way. Or is this something more specific to Docker instances where all the modules are installed and it just flags which ones are in use so that they get preserved and can't inadvertently be uninstalled? Again, I have only a rudimentary understanding of what Docker is and how it works, picked up by working alongside IT departments. I've never had the opportunity to dive into it myself so my understanding is pretty patchy and unreliable.
The GATEWAY_MODULES_ENABLED environment variable is only meaningful to a starting/running Ignition Gateway (i.e. it is not known to the installer). While typically leveraged in a Docker context, it is actually part of the Ignition platform and will also work in other OS's such as Windows. However, setting up environment variables for Windows services is not very straightforward.
This forum post shows the Windows Registry modifications for a given service definition and how to define environment variables.
This docs page shows what identifiers can be used in that comma-delimited list. As mentioned there, if you're on Ignition 8.1.x, there are separate "legacy" identifiers that must be used.
As of Ignition 8.3.x, there are new platform environment variables ACCEPT_MODULE_LICENSES and ACCEPT_MODULE_CERTS that can be used to programmatically accept licenses/certs for third-party modules. You must use the fully-qualified module identifier[s] in these.
Is it expected when module identifiers have capitals that the gateway skips over accepting licenses/certs for that module? In other words is it required for module identifiers to be all lowercase?
In general, there is no requirement that module identifiers are all lowercase.
When you're specifying modules by id in these environment variables I would expect it to be case-sensitive, requiring you to use the module id as defined by the module and documented wherever you're seeing an id.
I ended up using the Edge ZIP installer, and scripting a deletion of the non-required modules as @Chris_Bingham suggested.
I'm fine with doing the "accept EULA and run through initial gateway commissioning" bit manually, I just didn't want a user to be in the situation of having to remember which modules we use for our specific setup and then end up with unlicensed modules showing warnings in the gateway.