6. Bootstrapping Gort

Since interactions with Gort require a user account, you’ll need to bootstrap your system before you can do anything interesting with it. This process will create the necessary administrator role and user group, as well as create the first user account and place it into that administrator group. At this point, you can interact with Gort as this first privileged user in order to create other user accounts (to which you can also grant administrative access, if you like), install bundles, and perform other tasks.

The canonical way to do this is to use the gort bootstrap command:

$ gort bootstrap --allow-insecure https://localhost:4000
User "admin" created and credentials appended to gort config.

Note the existence of the --allow-insecure flag. This allows you to communicate with the Gort API across an unencrypted connection, which is commonly the case when you’re testing locally. _**This state should never, ever be used in production.**_

The gort bootstrap command is idempotent: subsequent calls will return an error message, but the Gort system itself will remain unaffected.

If you take a look in ~/.gort/profile, you’ll begin to see what just happened.

$ cat ~/.gort/profile

    profile: localhost_4000
    url: https://localhost:4000
    password: cZO5E4i8+T6vVRO8m4EvYEyGI2fn86iZ
    user: admin
    allow_insecure: true

Here, we can see that a user named admin has been created for us on the Gort controller. A password has also been generated for this user. Now, whenever we run any gort commands from this machine, these credentials will be used by default to make authenticated API calls.

Gort’s REST API is guarded by Gort’s authorization system, which means that the admin user must have permissions to access the API somehow. As detailed in Permissions and Rules, permissions must be attached to a user somehow through a combination of roles and groups. As you can probably guess, the bootstrapping process handles all this. Let’s use gort to examine what has been done.

First, let’s just check which users exist.

$ gort user list
admin     Gort Administrator  admin@gort

As you can see, there’s just one: admin.

Now let’s examine the core permissions of the Gort system. These govern fine-grained access to the various REST API endpoints and chat commands.

$ gort permission list

That’s a lot of permissions. Gort helps us out by creating an admin role to collect them all together.

$ gort role info admin
Name         admin
Permissions  manage_commands, manage_groups, manage_permissions, manage_roles, manage_users
Groups       admin

Finally, we have a group that is also named admin with the admin user as its sole member. This group is granted the admin role.

$ gort group info admin
Name   admin
Users  admin
Roles  admin

Though the Gort admin user is named “admin”, there’s nothing particularly special about that name. As this tour of the bootstrapping process has shown us, the admin user functions as an administrator, able to perform any task in the Gort system only because it resides in a group that has been granted all the core permissions. Any user in this group would have the same capabilities.

This also shows how to make any Gort user an administrator by adding them to the admin group.