Ignition 8.1 Commissioning Automation

Ignition
1

Has anyone been able to use a custom hash for the commissioning file when installing 8.1? Currently we use the modifications outlined here: ZIP File Installations - Ignition User Manual 8.1 - Ignition Documentation.

{
  "isCommissioned": "COMMISSIONING",
  "connections.useSsl": "false",
  "eulaSetup.accepted": "true",
  "eulaSetup.eula": "TuLW3I1yHBlo9kuqbxz5cDFPf5H4/zqSpbO93Tk7Hco=",
  "authSetup.username": "admin",
  "authSetup.password": "[e811cfc7]fc3b28ad5f73331c94790129f0931437ac31d59376b0e4b15df580a8841ba165"
}

This sets the password to the default, which is great, but I was looking to put our custom password in there instead.

2

@Kevin.Collins reverse-engineered it (before he was hired) and has a bash snippet available that he uses in his docker images.

3 Likes
3

I’ll add that you can use the same environment variables within a regular installation that you’d use for auto-commissioning a Docker container. Setting these vars will satisfy commissioning and continue with Gateway startup automatically:

  • IGNITION_EDITION=standard
  • GATEWAY_ADMIN_PASSWORD=password
  • ACCEPT_IGNITION_EULA=Y
  • GATEWAY_DEFAULT_PORTS=true

Alternatively, you can also specify all the individual ports:

  • GATEWAY_HTTP_PORT=8088
  • GATEWAY_HTTPS_PORT=8043
  • GATEWAY_GAN_PORT=8060

A couple other bonus tips:

  • You can also specify GATEWAY_ADMIN_PASSWORD_FILE=/path/to/file where the contents of the file feed the environment variable.
  • The final value of GATEWAY_ADMIN_PASSWORD (whether directly or by file) can also be a salted hash (created using the code Paul posted above) instead of an explicit password.

Seeding the commissioning file directly is also perfectly valid, but I wanted to mention this in the event that it wasn’t known that these particular environment variables were actually integrated into the platform itself for 8.1.9+ (and not just part of our Docker image entrypoint logic).

1 Like
4

Thanks for all the tips. We're not using Docker images, which is why we opted to seed the commissioning file. I did try to seed the commissioning file on an upgrade of 7.9 to 8.1, with the admin password. A temp user source, like when resetting the password using the gwcmd was created with the new admin user.

The GitHub repo was great and it's very helpful to be able to input our own hash in this way during commissioning to automate some of this. This didn't help much in the upgrade of 7.9 to 8.1 though because of the mentioned temp user source that was created.

5

IIRC, you shouldn't need to define a password during commissioning on an upgrade from 7.9 to 8.x (and doing so will perform a password reset, as you note).

6

Yes. That’s correct. No need to enter a new user/password into there.

The EULA does make a return though, which is what we were able to skip through on initial deployment by seeding the commissioning.json file.

I was looking to see if there was a way to skip the EULA in the same way. I had tested this without setting up the user and password in the commissioning file, and a new user was requested in the EULA prompt also. The provided Github repo solution uses curl and basically accepts the EULA that way.

7

Ahhh, I see.. Yes, it would be easiest to just add the ACCEPT_IGNITION_EULA=Y var to your environment then.. If you're on Linux, see an example below for updating the systemd override file with additional environment variables:

https://asciinema.org/a/KnHcZHFOxr5cPNkOR4BkEPnNO

1 Like
8

I put together a quick video to demonstrate an installation and then upgrade from Ignition 7.9.20 to Ignition 8.1.18 with the systemd overrides. Along the way I add some audio insight–hopefully this helps with folks who might be interested in this solution for helping automate upgrades.

forum-61034.mp4

1 Like
9

Another supplement here, this script can be used to generate a salted SHA256 hash of a password for direct use within GATEWAY_ADMIN_PASSWORD environment variable or the commissioning.json file:

2 Likes
10

Hmm. Doesn't seem to work with executable installers. I was hoping to switch away from the zip installs.

11

Is your expectation/wish that these environment variables will be discovered by the executable installer and applied to the underlying service configuration as part of the installation?

12

Yes. Particularly for unattended installs. I'm working up an auto-install for netboot/minimal ISO kits.

13

Gotcha.. I could see that being handy..

14

Succeeded with a work-around using a SystemD drop-in. Just before invoking the installer, my script has this:

mkdir -p /etc/systemd/system/ignition.service.d
cat >/etc/systemd/system/ignition.service.d/override.conf <<EOF
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_RAW
Environment=ACCEPT_IGNITION_EULA=Y
Environment=GATEWAY_ADMIN_USERNAME=someUserName
Environment=GATEWAY_ADMIN_PASSWORD=somePassword
Environment=IGNITION_EDITION=edge
Environment=GATEWAY_HTTP_PORT=80
Environment=GATEWAY_HTTPS_PORT=443
Environment=GATEWAY_GAN_PORT=8060
EOF

The installer launches like so:

useradd -c "Ignition Service" -U -m -G dialout ignition
"./$installer" -- unattended=text logLevel=debug user=ignition serviceName=ignition location=/usr/share/ignition

After the installer completes, I have this in the script:

cat >/etc/systemd/system/ignition.service.d/override.conf <<EOF
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_RAW
EOF

systemctl daemon-reload

This booted all the way up into Edge on ports 80 & 443 while running non-root. (:

Edit: I messed up the password hash somehow. But a plain password works.

2 Likes
15

Nice. Yeah, I suppose there is nothing wrong with pre-loading the systemd service overrides to have the env vars be there when the installer starts up the service.

The gist I linked above (here) should help you generate a valid hash for the env var.