Incident Logs
2024-09-25
https://tuftswork.atlassian.net/browse/DSDW-703
2024-09-18
https://tuftswork.atlassian.net/browse/DSDW-700
2024-07-01
https://tuftswork.atlassian.net/browse/DSDW-628
2024-03-22
https://tuftswork.atlassian.net/browse/DSDW-552
2023-06-01
https://tuftswork.atlassian.net/browse/DSDW-246
2023-05-30
https://tuftswork.atlassian.net/browse/DSDW-243
2023-05-26
https://tuftswork.atlassian.net/browse/DSDW-242
2023-05-24
https://tuftswork.atlassian.net/browse/DSDW-239
2023-05-19
https://tuftswork.atlassian.net/browse/DSDW-238
2023-04-18
Status: Resolved
Reported: 2023-04-18 16:08:00 EST
Resolved: 04-21-2023 15:43:17 EST
See https://tuftswork.atlassian.net/browse/DSDW-225
2023-04-13
Status: RESOlved
Reported: 2023-04-12 08:32:00 EST
Resolved: 2023-04-13 09:17:00 EST
Checklist
Writeup
John Klein reported authentication issues with Denodo dev via SSO and LDAP. Upon investigation, it wasn’t possible to use LDAP authentication with any Denodo server except solution manager.
SSH into solution manager works as expected, but all other VDP servers took a while to SSH into, and did not prompt for Duo.
David installed tailscale across all Denodo servers except solution manager as a means of connecting to our database in us-east-1. After turning off tailscale (tailscale down
) across the denodo servers, Duo/LDAP connectivity was restored. David is going to test tailscale only on stage going forward, until he is confident it's able to work in dev and prod.
The specifics around the tailscale issue was that the denodo servers were not migrated to a new, functioning tailnet, and remained in a tailnet that was no longer functioning, hence the connectivity issues.
2023-04-12
Status: RESOlved
Reported: 2023-04-12 09:12:00 EST
Resolved: 2023-04-12 14:53:00 EST
Writeup
Users were having issues connecting to the Denodo dev server. It was discovered that the certs, which were deployed in 2022-01-09, had expired. New certs were copied onto the Denodo servers by certbot, which would expire on 2022-06-09, but had not been deployed since automation had not yet been finalized. The new certs were deployed using the automation scripts that had been developed and the SSL connectivity issues were resolved.
Noticing that the certs were out of date on solution manager as well, the same process was followed there, but it became apparent that the web container for the web apps was no longer running both on solution manager and dev.
This led to the discovery that the SSL password file that the web container (Apache Tomcat) uses requires specific permissions, which were being violated by a step in the certification deployment automation that gave read/write access to the denod
user group.
The link below provides details:
Enabling HTTPS in the Embedded Apache Tomcat — Installation Guide
The certificate scripts were updated to ensure the appropriate permissions were set, and the deployment process was re-run on the solution manager and dev servers, after which the web apps were available again.