Troubleshooting · Banno Docs

Kibana

Testing a site locally
User can’t login
Site won’t load
ATM locator blue map
ATM locator referrer not allowed
Remove a site

Testing a site locally

Bring up the docker images docker-compose up -d while in the root directory of the banno-cms repository.

Set up the institution for the site in your local environment’s postgres banno_all

   insert into institution ("institution_id", "name") values ('d1fb3090-2d06-11e2-81c1-0800200c9a66', 'Demo Banno');
   insert into institutions_applications values ('d1fb3090-2d06-11e2-81c1-0800200c9a66', '3453aa91-8905-4c50-8613-5a71ebf7da1e', 3);
   insert into institutions_applications values ('d1fb3090-2d06-11e2-81c1-0800200c9a66', '7ae92401-2480-4940-b967-604c9711150c', 3);

The above will create the institution record and link the History and CMS applications to the institution. That should be all that is necessary as long as you have enterprise-authz-sync running. It’ll take care of the rest after a couple of minutes.

https://dev.banno.com/a/cms/api/site/dev.banno.com/migrate - go here once things are loaded (will prompt for login if you aren’t already logged in)
1. Fill out the form (site url of the site you want to bring down locally, your credentials, and a 2fa Authy code from the non-development account same as staging/uat/prod)
2. Click Migrate CMS Website to current environment and then answer yes to the two prompts
3. Wait for the download to complete, will take several minutes depending on how many assets the site has.
Continuation - repeat steps from the migration step as needed
If you want to be able to access the website outside of the platform app or with the legacy cms
1. Add one of the site’s domains (from the domains list in the institution config for the site) to the load balancer routing (https://github.com/Banno/docker-compose/load-balancer/cms/http.json)
```
{
  "backendId": "cms:http",
  "route": {
    "host": "newhorizonbank.dev.banno.com"
  }
},
```
2. Then restart haproxy
```
docker-compose kill haproxy
docker-compose up -d
```
If you want to develop locally:
- Legacy CMS
  1. docker-compose up -d
  2. sbt "project banno-cms" run
- Platform CMS
  1. docker-compose up -d
  2. sbt "project platform-cms" run
Caveats/Troubleshooting
1. If you are receiving a 400 response from login attempts, you may need to stop and restart the enterprise-authz-sync container.
  1. docker-compose stop enterprise-authz-sync
  2. docker-compose start enterprise-authz-sync
2. If the migration errors out for some reason part way through it you’ll need to clear the failed institution out of the cms mongo dbs
  1. First option is to nuke the dbs and restart:
    1. docker-compose kill mongodb cms
    2. docker-compose up -d
    3. And then proceed to attempt the migration again
  2. If you’re comfortable with working with Mongo you can just drop the offending data
    1. In the mongo shell use <migrated site's databasename>
    2. db.dropDatabase()
    3. use banno_cms
    4. db.institution.remove({databaseName: "<migrated site's databaseName>"})
    5. And then proceed to attempt the migration again

This falls more under Sentry/Enterprise Auth anymore but may come in CMS related requests.

Check to see if the user is locked out
1. Go to /a/settings/<institution short id>/users and find the user in question. If they are locked out a red lock icon will display on the right hand side of the user listing for them.
2. Select the user and on the left hand side an Unlock link should appear.
3. Click the link to unlock the user.
Check to see if ALL users are locked out
1. Go to /a/cms/api/site/<site domain>/settings/site.
2. If users are locked out there will be a button labeled Unlock towards the bottom of the page. It will say Lock if it is currently unlocked.
3. Click the button to unlock all users.
Check to see that the user has at least some privileges
1. Go to /a/settings/<institution short id>/users and select the user in question.
2. In the pane on the right hand side it will show what groups the user belongs to.
3. Privileges granted to the user based on the groups they belong to are listed below that.
4. Edit the groups the user belongs to as needed.
Check to see if there is an IP login restriction in place
- Go to /a/cms/api/site/<site domain>.
- Look for the loginIpRange value and check if it’s set to null or not.
- If it isn’t null then verify whether or not the value needs adjusted depending on where the user is attempting to log in from.

Site won’t load

On occasion a site can throw a Play error page (big red banner across the top of the page) if something is out of whack. There’s a couple items that can be checked quick before resorting to diving into the logs.

Go to /a/cms/<institution short id>/site-settings/templates and check that there is an entry flagged as Active. Activate an existing entry there or contact one of the webdevs or ops to try and hunt down why the site has their template deactivated.
Go to /a/cms/api/site/<site domain> and verify that the databaseName matches one of the Mongo database names.
It may be a syntax error with one of the page templates. Go to /a/cms/<institution short id>/site-settings/templates to download the current active template. You’ll probably need to find the error in the logs to find which template is problematic unless you’ve got a good idea which one it is already.
Go log diving with the error code presented on the error page to see what else might be up.

ATM locator blue map

If the site’s atm locator is presenting a blue map (default coordinates 0,0 land you in the Atlantic off the coast of Africa) there’s something wrong with the Google API key in most cases. In either case, check the Javascript console log to determine which issue it is.

ATM locator referrer not allowed

If there’s a message along the lines of a referrer not allowed then the domain may not be added to the api key’s domain whitelist in the Google developers console. Contact the project coordinator or support person reporting the issue and have them work with the client to get that updated.

Remove a site

On occasion there may be a need to remove a site and its database completely from the application. In most cases this is usually to help clear things out so the site can be set back up from scratch on UAT. This process should probably not ever be used on production unless the site is being retired.

Steps:

Make sure you have the database name for the site. It can be found on /a/cms/api/site/<site domain> as the databaseName field.

Institutions are stored in the banno_cms database in mongo. You will need mongo-connect to access the databases on staging or UAT. You will need to work with the ops team if you need to do this on prod.

mongo-connect connect -e <staging|uat> -r <team name>

There is a collection that stores all of the institution configs, we’ll need to remove the site’s record from that

use banno_cms

Run the following command to make sure you’re targeting what you expect

db.institution.find({ databaseName : "www_sitename_com" })

And if the result set looks correct change ‘find’ to ‘remove’

db.institution.remove({ databaseName : "www_sitename_com" })

And now the institution record is gone and the domain will no longer resolve to a database within CMS

To remove all content for a given site so that we’re starting from a clean database

use www_sitename_com

db.dropDatabase()