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.**_
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 defaults: profile: localhost_4000 localhost: 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 USERNAME FULL NAME EMAIL ADDRESS admin Gort Administrator admin@gort
As you can see, there’s just one:
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 NAME gort:manage_commands gort:manage_groups gort:manage_roles gort:manage_users
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
$ 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