GSOC 2019: OpenMRS Atlas 3.1

So, I added

    networks:
      - atlasnet

to the openldap service and put

networks:
  atlasnet:
    name: openmrs-contrib-atlas_default

at the bottom to bridge the openldap service to the atlas network.

Then I updated the PR’s docker-compose.yml with Cintia’s 3.x version. I’ve got

GOOGLE_MAPS_JS_API_KEY={My Google Maps Javascript API Key here}
LDAP_URI=ldap://openldap:3389

And I can confirm the openldap container is on the correct network via docker inspect, the environment variables are set correctly, and openldap is reachable from within the atlas container:

$ docker exec -it openmrs-contrib-atlas_atlas_1 bash
bash-4.4# ping openldap
PING openldap (172.31.0.2): 56 data bytes
64 bytes from 172.31.0.2: seq=0 ttl=64 time=0.140 ms

Once the server is listening, I got to http://localhost:3000 and Atlas loads. I click on the Sign In button and get to the Login screen. I enter credentials admin/admin and the Atlas server dies with this error:

GET /login 304 2.706 ms - -
GET /service-worker.js 404 1.085 ms - 30
uid=admin,ou=users,dc=openmrs,dc=org
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: connect ECONNREFUSED 172.31.0.2:3389
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1191:14)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! openmrs-contrib-atlas-node@0.0.1 start: `node ./bin/www`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the openmrs-contrib-atlas-node@0.0.1 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-06-06T13_09_14_096Z-debug.log

That suggests openldap isn’t listening at 3389, right? So, I check

$ docker ps -f name=ldap
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS                    PORTS                                          NAMES
5088c9c11298        osixia/openldap:1.2.4   "/container/tool/run…"   19 minutes ago      Up 19 minutes (healthy)   0.0.0.0:3389->389/tcp, 0.0.0.0:6636->636/tcp   ldap-stg_openldap_1

The 0.0.0.0:3389->389/tcp does mean that ldap://openldap:3389 is the correct LDAP_URI setting, right? Thinking I’m reading it backwards, I try switching to port 389. Now, when I try logging in as admin/admin, I get

{ InvalidCredentialsError: Invalid Credentials
    at messageCallback (/node_modules/ldapjs/lib/client/client.js:1419:45)
    at Parser.onMessage (/node_modules/ldapjs/lib/client/client.js:1089:14)
    at emitOne (events.js:116:13)
    at Parser.emit (events.js:211:7)
    at Parser.write (/node_modules/ldapjs/lib/messages/parser.js:111:8)
    at Socket.onData (/node_modules/ldapjs/lib/client/client.js:1076:22)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11) lde_message: 'Invalid Credentials', lde_dn: null }

And the UI shows a pretty little Invalid Credentials error message, which seems more promising. So, I don’t know the admin credentials, but…

It works logging in with credentials test/test!

So, it looks like the LDAP_URI for docker-compose should be port 389 and I still manage to read docker port settings backwards. :slight_smile:

1 Like