stating assumptions here prior to testing, perhaps for discussion about intent vs behavior
- it appears default
core resource.json files don't contain UUIDs
- it appears manually duplicating resource definitions across deployment modes in in Web UI generates unique UUIDs
- but perhaps with no author/timestamp/signature
- presumably identical UUIDs across deployment modes are fine (e.g. copy a mode in the file system)
- unsure if gateway will modify on startup/scan
- presumably omitting UUIDs from resource definitions is fine
- unsure if gateway will generate on startup/scan
- i generally like to track resource.json since they're useful for author/timestamp/signature (e.g., when a resource is "saved" with no changes) but perhaps they're less useful in deployment modes
longstanding curiousity - why is lastModificationSignature not lastModification.signature (guessing just historical precedent)
Which resources are you not seeing with UUIDs? Every named resource should be getting a UUID on creation.
Correct.
The UUID attribute is not related to the signature tracking/last modification stuff.
Between deployment modes is probably fine, but I wouldn't recommend it. Each resource in each location (across deployment modes) should have a unique UUID.
It depends on exactly which resource type. Different subsystems "opt in" to whether they care about the UUID; the only thing the UUID is used for at present is to track renames more intelligently, because some things need to care about that.
For instance, if you rename an internal historian, that means a file on disk that contains stored history needs to get moved. Without the UUID matching on both sides, we would see the rename as though my-old-historian got deleted and a brand new my-new-historian got created. Per the documentation on the NamedResourceHandler that does the bookkeeping automatically, if you don't have a UUID key on a resource that cares about renames, then your resource is just ignored and treated as if it doesn't exist. And no attempt will be made to modify your resource to add a UUID key until something else in the system touches it.
You should still track resource.json files, even though the lastModificationSignature is a perennial annoyance. Anything else is not 'safe'.
1 Like
core/ignition/system-properties/resource.json
core/ignition/security-properties/resource.json
core/ignition/security-levels/resource.json
(i happen to be overriding these, haven't looked elsewhere)
FWIW, identical uuids seem much more likely when using the external mode, as that basically requires a manual copy/paste from somewhere
1 Like
Those are fine - they're not 'named' resources, so there's no way to "re" name them. Thus, no UUID.
Yeah, that's fair. But again, probably not a problem in practice - nothing inside Ignition can update external.
1 Like
ah i see your point (singleton?), but they do get UUIDs when overridden/duplicated into custom deployment modes
Got it, yeah, that's probably just a minor bug in the duplicate logic.
1 Like
well, unsure if i should create a new thread, but it also appears impossible to deploy a "fresh" gateway directly into a custom deployment mode without an automated password reset being performed (and temp IDP/user sources being created)
I suppose i get that the gateway needs to be 'commissioned' in order to create the 'default' IDP/User source in core but i had hoped the username/password env vars would do that, even though I'm never "booting" into core.
Commissioning is about more than just the username/password, it's also where we present the EULA. If you pinky-swear to have reviewed it on another machine it's possible to bypass it:
We're still going to always create the username/password you seed in via env variable into core as far as I know.
1 Like
well, I "accept" the EULA via env var as well, but i see your point about commissioning.json
I guess my question/comment is more specifically - it appears 'booting' the docker image directly into a predefined custom deployment mode (or expecting core to inherit predefined user-source/IDP from external) doesn't work (a password reset is triggered that creates the temp user source/idp in core and nukes the custom user sources/IDPs (overwrites my custom mode's security-properties/config.json)
if this is (or will/is intended to be) a supported use case (without first booting into core) - it doesn't appear to work now.
environment: &ignition-env
ACCEPT_IGNITION_EULA: "${ACCEPT_IGNITION_EULA:-Y}"
GATEWAY_ADMIN_USERNAME: "${GATEWAY_ADMIN_USERNAME:-admin}"
GATEWAY_ADMIN_PASSWORD_FILE: "/run/secrets/gateway-admin-password"
IGNITION_EDITION: "${IGNITION_EDITION:-standard}" # standard, edge, maker
DISABLE_QUICKSTART: "${DISABLE_QUICKSTART:-true}" # true or false
TZ: "${TZ:-America/Chicago}" # set timezone, e.g., America/Chicago
# CUSTOM environment variable to specify deployment mode, used in ignition-init.sh to set Ignition config mode dynamically instead of hardcoding it in the command (below)
# will be officially supported in future docker images - https://forum.inductiveautomation.com/t/disable-devices-in-gateway-startup-script-v8-3-0/111599/10?u=hunterdg)
DEPLOYMENT_MODE: "${DEPLOYMENT_MODE:-}"
guess it boils down to - this behavior appears to be different if deployment mode is specified/external mode is configured - (does a password reset) vs not (puts it in core.default)
(i was hoping to NOT have to source control core - or stage a commissioning.json for that matter)
Okay, yeah, this is a thing I recently helped clarify for someone from Sepasoft.
Basically, it boils down to this:
When you provide a username and password via environment variable, we have to store that somewhere. What we chose to do is put them in core/ignition/security-properties.
In principle, if you seed a commissioning.json that says you've already commissioned and accepted the EULA and you have a valid admin user in external/ignition/security-properties (or whatever file) and you are not passing admin credentials via env variable,
then I would expect you to not have to commission.
If that's not working (and you can boil it down to an SSCCE) I'd appreciate it if you could send it in to support and we can see if there's some way we can iron things out. But in general, from what I remember when this last came up:
You can either preconfigure system login via external or via the environment variables. It's trying to do both that gets you into trouble.
2 Likes
if I don't pass env vars, it lets me manually commission, but kicks off a password reset anyway (and doesn't create core/ignition/security-properties.json)
I assume the commissioning.json will work, just 
thanks for the feedback 
1 Like
Wait, there's a EULA when you commission a gateway??? I thought there were only "Next" buttons?
4 Likes
