Gwcmd -p/-r is not causing the gateway to produce the "create new user" prompt

Ignition
1

TLDR:

gwcmd -p/-r is not causing the gateway to produce the "create new user" prompt.

Details:

Gateway Version: 8.1.28

I've inherited a gateway instance but the previous owner was unable to provide login credentials.

I tried using the gwcmd -p/-r in an attempt to create a temporary admin user source but it doesn't appear to be working.

After running the commands, the console indicates that "Password has been reset" but after the -r part of the process I do not get a "Gateway needs to be commissioned" output.

If someone has run these commands in the past without deleting the temp user source will that prevent this from working?

Refreshing the gateway web app in the browser just brings me to the normal home screen without the expected prompt to create new user credentials.

I've made a backup of this gateway instance with gwcmd and I see there are a couple of older instance backups available.

Attempting to restore one of these from the gwcmd -s command doesn't appear to have any tangible effect either. The shell just hangs after warning that all data will be overwritten. (How long should a 15MB restore typically take with average hardware?)

I'm running the shell as administrator.

I learned from a different forum thread that deleting the "config.idb" file and projects folder should reset the gateway to a more or less clean userless state but without projects.

Is it not possible to restore projects to a gateway instance with some file management? Are project files associated/encoded in a way to only work with their original gateway instance some how? Maybe manifest files that are non trivial to recreate.

Anyway, given the procedures partaken, are there steps I'm missing or is this instance effectively inaccessible?

2

From memory, it doesn’t reinstate it to commissioning stage, it simply creates a temp user profile with default admin/password

1 Like
3

Thanks for your reply,

I attempted to login with what the documentation shows as the default login (“admin/password”) but this is unsuccessful.

Note that the gwcmd documentation for 8.1 specifically discusses the commissioning procedure for creating the credentials for a temp user upon password reset.

However, I agree with your correlation between the lack of “Commissioning” nomenclature during the use of gwcmd and the reasonable expectation that it might be directly modifying the default user instead of invoking the commissioning mechanism.

4

Since ~a long time ago, the way the "reset" command works is by:

  1. Creating a new user source. If one named temp already exists, a numeric suffix is added until a unique one can be created.
  2. Forcing the gateway to use that user source for login to the configuration settings.
  3. Forcing commissioning so that that user source gets an initial login added to it.

If that didn't happen, it means something went wrong somewhere in the process. I'd recommend contacting support. There's no 'harm' in running reset multiple times, other than that you're going to end up with additional temp user sources.

(For 8.1) Deleting config.idb, the projects directory, and the commissioning.json file will more or less 'reset' the gateway, with some minor exceptions such as the persistent UUID file used for gateway network connections.

In 8.3 things are more complicated, but not dramatically so.

It is absolutely possible to restore projects directly from the filesystem; on system startup that's the only source of truth. You can take the entire directory underneath the projects/ folder that represents a project on one gateway and duplicate it to another gateway and it will show up as a project (either the next time you restart, or after 5 minutes when the next project scan occurs). Whether everything within the project will work is a different question (because of implicit reliance on certain named connections and the like), but it will absolutely restore as a 'real' project on the new gateway.

5

Thanks for all that information Paul,

On the note of the malfunctioning password reset process I’ll contact support at my next opportunity.

Resetting the gateway and copying the projects back to it might be a decent avenue if I can recreate all the missing dependencies of the projects. Named queries might take some reverse engineering of the scripts or objects, if there are any.

Your mentioning the commissioning.json file caused me to research it and came across the “zip file installation” documentation.

Would there be any harm modifying from “COMMISSIONED” to “COMMISSIONING” in an effort to perhaps trigger the missing component of the gwcmd password reset? Would adding the “admin” user and its password hash be necessary as well?

Again, thanks for elaborating on the functionality of some of these components and opening up these new troubleshooting avenues.

6

Try just deleting the commissioning.json file. That'll retrigger commissioning and intelligently decide which steps to retake.

7

TLDR: Deleting the commissioning file in conjunction with the gwcmd -p/-r successfully got the gateway to proceed with the temporary user mechanism.

Details:

Deleted the commissioning file and restarted the gateway.

It asked to agree to the eula and then asked to continue with commissioning.

After a brief period it brought up the home page as usual. Logging in with admin/password was not successful.

Next I tried deleting the commissioning file, then running gwcmd -p/-r.

This caused the gateway to bring up the create user prompt.

Once it finished starting up I was able to log in with this new user.

I can now address the user issue and restore the server.

Notes:

The security configuration [Designer Authentication Strategy] is set to “Classic” (may or may not be relevant)

There are 2 user roles [default, opcua-module, temp]

There are 2 Identity providers [default, temp]

Once we’ve decided what to do with the existing users in “default” we’ll delete the “temp” provider.

Thanks for your help Paul,

Let me know if there’s anything else you want to know.