puppetlabs / pupperware

Container fun time lives here.
Other
183 stars 67 forks source link

(maint) Supply Postgres ssl files absolutely #255

Closed Iristyle closed 3 years ago

Iristyle commented 3 years ago
jpartlow commented 3 years ago

This passes, but I don't think it makes use of the pe-postgres.yml. Locally, using this with pe-bolt-vanagon fails to stand up postgres:

FATAL:  could not load server certificate file "${SSLDIR}/certs/server.crt": No such file or directory        
LOG:  database system is shut down                   
FATAL:  could not load server certificate file "${SSLDIR}/certs/server.crt": No such file or directory
LOG:  database system is shut down  

Possibly because of an escaping issue in how the entrypoint script is handling the args.

The same pr but with the full paths typed out worked for me.

Iristyle commented 3 years ago

Yeah @jpartlow I think that I'm going to move pupperware-commercial repo into pupperware tomorrow so that we get validation against both FOSS and PE with PRs to this repo. I don't see a compelling reason to have pupperware-commercial be its own repo anymore (barring a check for any secrets) -- having it separate is a hindrance.

Iristyle commented 3 years ago

Not quite right yet...

2021-04-09 04:27:15.183 UTC [1] FATAL:  private key file "/var/lib/postgresql/data/certs/private_keys/server.key" has group or world access
2021-04-09 04:27:15.183 UTC [1] DETAIL:  File must have permissions u=rw (0600) or less if owned by the database user, or permissions u=rw,g=r (0640) or less if owned by root.
jpartlow commented 3 years ago

Hmm, that's odd; I wasn't hitting that. That's going to be tricky though. Whatever is generating the certs has to get the permissions right before the entrypoint begins.

jpartlow commented 3 years ago

Given that the pdb port had been set to map 8080 to the host, I'm not sure why check_report was failing. The logs did look as though pdb had come up, orchestrator had waited on it before issuing the node run, and the agent completed after pdb was up, and should therefore have produced a report. But I guess Net::HTTP timed out trying to reach pdb for the query? Unless there's something about the Travis env that is more restrictive.

Iristyle commented 3 years ago

@jpartlow I'm pretty sure it's because the PE version of PDB isn't accepting non-SSL connections, right?

That last commit adds a call to client tools to do the retrieval instead. As long as that works, I'll get this cleaned up and merged 🤞🏻