[Bug-11615] Gateway Status Reported as RUNNING during Commissioning phase


Build: 8.0.0-beta0 (b2018111102)

Observed Behavior

When a fresh installation first starts, the http://localhost:8088/StatusPing (which I noticed moved from /main/StatusPing, which is fine) returns {"state": "RUNNING"} during the commissioning phase (where initial password and port settings are configured). Once commissioning is completed, it then goes through the expected STARTING and then finally RUNNING states.

Expected Behavior

During commissioning phase, the StatusPing should return {"state":"COMMISSIONING"}. This will help HEATHCHECK configurations in a Dockerfile avoid marking the container as healthy versus starting.

Steps to Reproduce

  1. Install Ignition
  2. Bring up gateway webpage link which will take you to the commissioning page.
  3. Check the output of the StatusPing endpoint before you finish the commissioning configuration. Observe the state of “RUNNING” even though gateway services are still offline, pending initial configuration.

Thanks! Let me know if I can provide any other helpful information.


This will help my commissioning script too. It’d be nice to have a way to preload the commissioning questions…

This is a great suggestion. I have created a ticket for it and hope to be able to get to this soon.

Jonathan C

1 Like

@pturmel Just to be clear, you mean a way to start the gateway without having to go through commissioning? There is a way to do this by providing the correct fields in the gateway.xml file. The additional fields required for commissioning are:

<entry key="commissioning.connections.useSsl">false</entry>
<entry key="commissioning.eulaSetup.accepted">true</entry>
<entry key="commissioning.eulaSetup.eula">xGbbq17t4B6YSsE5vbs5IqJeSGoLM5v7sUfILWRweXc=</entry>
<entry key="commissioning.authSetup.username">admin</entry>
<entry key="commissioning.authSetup.password">[30EF27E7]1c3de5974927bad77da0d241c030727619b70fcdb3a8377f33ec2c7e162eb678=</entry>```

This tells the gateway to startup pre-commissioned with the username 'admin' and the password 'password' (though this isn't recommended, you can supply your own salted sha256 password here as well)

Note: the ```commissioning.eulaSetup.eula``` field may need to be updated between release of ignition if there are any changes to our EULA.

I will also let our training department to update our docs about this as well.

Jonathan C
1 Like

@jcoffman This is great info. I’m very interested in any of these types of artifacts that relate to automated provisioning of gateways. They will greatly enhance my efforts on the Docker-based solution I’ve been maintaining. Is there a place in the Ignition Docs that we can squirrel away some of these golden nuggets?

@kcollins Currently no, though I am reaching out to our training department to add this information. Keep your eyes peeled and I am sure more information will make it into our documentation soon.


This is precisely what I was hoping for! Thanks!

1 Like

Hmmm. I’m not getting the same hash from ‘password’ salted with 30ef27e7.

$ echo -en "\x30\xef\x27\xe7password" |sha256sum
$ echo -en "\xe7\x27\xef\x30password" |sha256sum
$ echo -en "password\x30\xef\x27\xe7" |sha256sum
$ echo -en "password\xe7\x27\xef\x30" |sha256sum

Are y’all padding the salt?

kevin@Kevins-2018-MacBook-Pro ~> echo -en 'password30EF27E7' | shasum -a 256
1c3de5974927bad77da0d241c030727619b70fcdb3a8377f33ec2c7e162eb678  -

Tricky. Salt looks like hex but isn’t.

@jcoffman, Do you know if Bug 11615 is still in the pipeline? I noticed that the release version still shows {"state":"RUNNING"} on initial start. Is there a good way to know that the gateway is in limbo?

@kcollins Yeah it definitely is. We are a bit swamped with other issues and tickets right now that are higher priority. Once those get wrapped up we will get to this ticket, I wouldn’t expect 8.0.2, but shortly thereafter as long as nothing more pressing comes up.

Alright, no worries… One thing that might help me in the meantime though, if I may ask, how do you compute the hash for the EULA acceptance? I’ve tried a couple things against the License.txt that ends up in the install directory but can’t come up with a match. If I could do this then I could at least automate the commissioning process based on some default environment variables in the Dockerfile (including a random generated password option that could be output to console on first-launch). Any guidance? Thank you for anything you might be able to offer up.

I think I might have found something that will get me by for the health checks. Debatably, perhaps this is enough altogether, although I think we could probably benefit from having both the Web Server Status and the Gateway Status included in the StatusPing JSON:



I’m trying to get the auto-commissioning to function by injecting the specified keys into the gateway.xml_clean (which is copied to gateway.xml on first-launch). The gateway remains in needs commissioning state. I can’t find any related log output hinting at it making attempts to parse/process those commissioning.* entries there. Any insights? I’d love to get this working!

Also, I still need information on how to compute the commissioning.eulaSetup.eula hash, perhaps that is the reason it isn’t working?


Actually, I think I’ve found a solution involving just doing some strategic HTTP POSTs in the interim… So no rush on any other insights. :grinning:

I took a quick peek at the commissioning code and I can at least tell you the EULA hash is the Base64 encoding of the bytes of the SHA256 hash of the EULA contents.

What might be tricky is it looks like there’s a couple variations of EULA contents that can be read or displayed and I don’t which variation ends up getting hashed.