Deployment: Almost there!

Deployment & Development
1

Hey All,

I am testing a LAMP deployment via AWS. I had to make some modifications to the traefik.yml docker compose file in order to to secure my domain. The addition I made is below.

services:
  <the service>:
    ...
    dns:
      - 1.1.1.1
      - 1.0.0.1
    ...

This allowed the traefik container to ping DNS addresses (i.e. letsencrypt.com to get the certificates). See this stack overflow post where I found this solution.

Continuing to the lamp compose file. In the docs, I am using the first compose file without the addition of self hosting the dashboard. After deployment, access to the api domain is secure and successful. Looking at the server logs, it also seemse like my database is initialized successfully.

image
image1287Ă—865 57.3 KB

Unfortunately when I try the database and admin sign in commands I get the following responses…

Command: curl -k https://admin:DB_PASSSWORD_HERE@db.example.com/ (changing the password and domain)
Response: 404 page not found

Command: curl -k https://api.devprechlamp.com/researcher -H 'Authorization: Basic admin:admin'
Response: {"error": "403.no-such-credentials"}

Command: curl -k https://api.devprechlamp.com/researcher -H 'Authorization: Basic admin:<admin password here>'
Response: { "error": "403.no-such-credentials"}

It seems like communication from the server container to the database container is not working. I also checked to see if port 27017 (used by the database provided in the lamp compose file) was in use. Running the command: sudo lsof -i -P -n | grep LISTEN did not show port 27017 in use. So on a second iteration of deployment I added the following to the compose file:

database:
  ...
  ports:
    - "27017:27017"
  ...

After deploying and running the same lsof command, port 27017 was now in use. Unfortunately this did not change the outcome of any of the database/admin commands above.

Is there a final step I’m missing? Does there need to be additional parameters in the lamp compose file? Let me know if you need any more information, happy to help anyway I can! I was reading through the lamp_database logs as well but I don’t know how to decipher any of them.

Thanks in advance,
Steve

2

Are you using portainer?

Maybe the credentials are off. Could you try directly connecting to the mongodb service and changing the admin credentials (encrypted using ROOT_KEY)? You can find the admin credentials in the “credential” collection under the “test” database.

Once you’ve changed it to a new custom encrypted password, try the cURL command again

3

Thanks for the quick reply Carsten! I don’t have portainer installed on this instance. I attempted a quick install but am getting stuck at accessing the portainer login page. In the instructions, it gives you the https://localhost:9443 address to get to the login. I changed localhost to my EC2 instances public ipv4 address but it was just timing out.

Anyways, I skipped this for now and went on to your next suggestion. I SSH’d into the docker container running lamp_database. From there, I was able to read the contents of the credential collection in the test database. In the single object in this collection (server admin) the secret_access_key was set to null. I updated this entry with my generated server admin password. After this I tried the same list of commands in my original post and they unfortunately had the same output as before.

I’m thinking there is a key communication step between lamp_server and lamp_database that is not happening. What are your thoughts on this? My current next steps will be to try and get portainer running so I can see if there’s any blatant container communication errors I guess?

Thanks again!

4

Regarding portainer, please be sure that port 9443 is permitted via security rules in your EC2 instance, and that portainer was installed on that port

The communication issue has been encountered before and is usually fixed by changing the secret_key from “null” to an encrypted password. I recommend choosing something simple like “testpassword” and encrypting it using this javacript:


#!/usr/bin/env node
const PRIVATE_KEY = <ROOT_KEY>

const crypto = require('crypto')
const mode = (process.argv[2] || '')
const input = (process.argv[3] || '')
let output = 'Usage: passcrypt.js <encrypt | decrypt> <string to encrypt or decrypt>'

try {
	if (mode === 'encrypt') {
		let ivl = crypto.randomBytes(16)
		let cipher = crypto.createCipheriv('aes-256-cbc', Buffer.from(PRIVATE_KEY, 'hex'), ivl)
		output = Buffer.concat([
			ivl,
			cipher.update(Buffer.from(input, 'utf16le')), 
			cipher.final()
		]).toString('base64')
	} else if (mode === 'decrypt') {
		let dat = Buffer.from(input, 'base64')
		let cipher = crypto.createDecipheriv('aes-256-cbc', Buffer.from(PRIVATE_KEY, 'hex'), dat.slice(0, 16))
		output = Buffer.concat([
			cipher.update(dat.slice(16)),
			cipher.final()
		]).toString('utf16le')
	}
	console.dir(output)
} catch(e) { 
	console.log('*** ERROR: Could not ' + mode + ' the string. ***')
	process.exit(1) 
}

Of course, replace the ROOT_KEY with the ROOT_KEY as specified in your lamp_server service. Replace the secret_key in the “credential” collection with your encrypted output. Then, you can authenticate using the original password (“testpassword” in the case of the example)

5

Thanks for this! I’m noticing you’re using aes-256 encryption in this code but on the lamp documents we’re using a 64 bit encryption key. Will everything work if I deploy the database with a 256 bit encryption rather than 64?

6

Go with the code I pasted above.

The docs should say openssl -hex 32 thanks for pointing that out

1 Like
7

Perfect that fixed my issue!! I was able to sign into the dashboard and everything just by assigning the ROOT_KEY to a openssl rand -hex 32 output! I didnt have to go into the mongo test database and change anything either.

So just to review, the two changes I had to make from the lamp docs is the following:

1.

traefik.yml:

services:
  <the service>:
    ...
    dns:
      - 1.1.1.1
      - 1.0.0.1
    ...

This first change allowed my api.mydomain.com to become secure. Before doing this I could not access it over https

2.

I changed the ROOT_KEY = openssl rand -hex 32 which allowed my mongo database to communicate with the lamp_server correctly

Is change 1. worth adding to the lamp docs? I’ve spent some time on this (a lot before posting on discourse) but I cant say I’m 100% certain I know this is the only answer to my https problem

1 Like