Using Jupyter, we have a way to query all desired addresses to find out how much SQL storage space is remaining.
I want to do something similar but what I want to do is find out the ignition version installed on every single gateway.
Is this info stored in a place where it can be accessed with an external script?
Motivation for doing this: is that use of the expression function “runScript” which we use in SSO is version dependent. Assessing what version of Ignition is installed everywhere as part of bringing the entire fleet up to SSO so that password and level access is manageable over 100’s of gateways.
You can make an HTTP request to http://${gatewayAddress}/main/system/gwinfo and parse the results - that should work on just about every Ignition version released in the last 5 years. If you know everything is going to be 8.0+, you can drop the main/ in the path, but it’s required for 7.9 and previous versions.
@PGriffith this worked perfectly from Jupyter, thanks for the tip.
We are now waiting on feature 2155 to be released so we have a sustainable way to manage idp certificates.
At present they have to be renewed once a year so we will have a lot of manual updating to do until we can use a single entity ID and manage all SSO sites from one single IDP cert.
Another note is that we are using “runScript” from the IDP attribute mapping to call a script in order to process the SAML response (extract specific AD group names). I’m not a fan of this and I really wish I had a way to write python script (not expressions) in the gateway.
There are so many links in the SSO authentication chain I’m always fearful that if one of them should break we’ll be locked out. For example if someone changes or deletes the gateway scripting project name, it’s all over.
Thanks,
Nick
@PGriffith sorry for asking more questions on this but is there a way to access the number of client sessions via HTTP call? or better yet is there some documentation which lists all the call paths to get information from a gateway?
Thanks,
Nick
You can look in the network logs when on the appropriate status page - all of our status pages since 7.9 are ‘modern’ stateless frontend + polling network requests to the backend. The tricky part is that all of those status routes require authentication, and we don’t have an easy way to programatically authenticate with the gateway - so you’ll have to issue the right calls to our login form and hold on to the JSESSION token you receive in the response, if I remember right.
This sounds like the kind of problem that would appeal to our Sales Engineering department, for what it’s worth - and they may already have some of the code you need written.
I will have a look around. What I’m trying to do is figure out how well each site is being used and if we do some actions to help improve adoption, have a way to measure the outcome.
