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

kcollins · November 12, 2018, 3:35am

Environment

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

Install Ignition
Bring up gateway webpage link which will take you to the commissioning page.
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.

pturmel · November 12, 2018, 12:05pm

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

jcoffman · November 12, 2018, 4:44pm

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

Thanks!
Jonathan C

jcoffman · November 12, 2018, 5:46pm

@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.

Thanks!
Jonathan C

kcollins · November 12, 2018, 6:08pm

@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?

jcoffman · November 12, 2018, 6:27pm

@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.

pturmel · November 13, 2018, 3:16am

This is precisely what I was hoping for! Thanks!

pturmel · November 14, 2018, 4:32pm

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

$ echo -en "\x30\xef\x27\xe7password" |sha256sum
4ef31ca84f092ed9fb6440f741bd47586a7c4eb44c6b6083d6db168ce42db8d0
$ echo -en "\xe7\x27\xef\x30password" |sha256sum
7536efd23e9a7564ac5884a05545bdbc9c8cc5ea0c92033b8061ccaef7b9686e
$ echo -en "password\x30\xef\x27\xe7" |sha256sum
b6eb3af4df52b7dd0eca6ea53d7e00027323fd0797bc282349b87ad77e6926e6
$ echo -en "password\xe7\x27\xef\x30" |sha256sum
02aa1b0a707985a9f282228fc0f53d06eda8a385b204c25227b01998fe825b97

Are y’all padding the salt?

Kevin.Herron · November 14, 2018, 4:46pm

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

pturmel · November 14, 2018, 4:47pm

Tricky. Salt looks like hex but isn’t.

kcollins · April 22, 2019, 10:37pm

@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?

jcoffman · April 22, 2019, 11:04pm

@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.

kcollins · April 22, 2019, 11:47pm

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.

kcollins · April 23, 2019, 1:16pm

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:
14%20AM

Thanks!

kcollins · April 27, 2019, 4:36pm

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?

Thanks!

kcollins · April 27, 2019, 5:06pm

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.

Kevin.Herron · April 27, 2019, 5:18pm

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.