/
Incident Logs

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

Confirm Duo/Shiboleth/LDAP is working
SSH into Denodo servers
Create ticket/ask Marv to investigate/power cycle all Denodo servers (except solution manager)
See if tailscale is an issue
Restart denodo on all servers

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.

 

Related content