[SHOT-252] fix: Move MSSQL base to RHEL, bump to CU8

[mimartin12]

Moves MSSQL base to mcr.microsoft.com/mssql/rhel/server:2025-CU8-rhel-10 (SQL Server CU5->CU8) for FIPS support on a currently patched RHEL base. Draft: pending DBOps sign-off and FIPS VM re-test.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the MSSQL image base swap from mcr.microsoft.com/mssql/server:2025-CU5-ubuntu-22.04 to mcr.microsoft.com/mssql/rhel/server:2025-CU5-rhel-9.1, the gosu → setpriv privilege-drop replacement in util/MsSql/entrypoint.sh, and the linux/amd64 platform pin in the build matrix. The setpriv --reuid/--regid --init-groups calls are a faithful gosu equivalent (real, effective, and saved UIDs are all set, and supplementary groups are re-initialized rather than inherited from root), and the added export HOME=/home/$USERNAME correctly compensates for gosu having set $HOME on behalf of the target user. The platform pin is consumed correctly by the Set platforms step, and the Build Docker images (MsSql, ./util, linux/amd64) job passes, confirming the new base resolves and mssql-conf still lives at the expected path.

Code Review Details

No new findings this pass. The previously opened question below is still unresolved and remains the main open item, since CI validates only that the image builds — the entrypoint, healthcheck, and backup loop are never exercised on the new base.

• ❓ : Was tzdata confirmed present in the RHEL base? backup-db.sh exports TZ and uses date -d; a missing zoneinfo database silently falls back to UTC rather than failing (existing unresolved thread)
  • util/MsSql/Dockerfile:1

PR Metadata Assessment

• ❓ QUESTION: The description is the unmodified template — no objective or test plan.
  • Worth recording how the image was validated (non-root startup, healthcheck via /opt/mssql-tools18/bin/sqlcmd, backup loop) since CI covers none of it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.29%. Comparing base (b045928) to head (1b9e495).
⚠️ Report is 8 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (b045928) and HEAD (1b9e495). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (b045928)	HEAD (1b9e495)
	2	1

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8239      +/-   ##
==========================================
- Coverage   68.59%   63.29%   -5.30%     
==========================================
  Files        2383     2401      +18     
  Lines      103921   104043     +122     
  Branches     9403     9426      +23     
==========================================
- Hits        71286    65856    -5430     
- Misses      30294    35931    +5637     
+ Partials     2341     2256      -85     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[withinfocus]

Do we have any precedent for RHEL here? Would this be the only usage, anywhere?

[mandreko-bitwarden]

The reasoning for moving from Ubuntu to RHEL is that Ubuntu 22.04 LTS is EOL on April 2027. But this moves the image to a RHEL 9.7 image, which was already EOL in May 2026.

docker run --rm --entrypoint cat mcr.microsoft.com/mssql/rhel/server:2025-CU5-rhel-9.1 /usr/lib/os-release
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
NAME="Red Hat Enterprise Linux"
VERSION="9.7 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.7"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.7 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.7
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.7"

Instead of moving to RHEL, would it be possible to update to a newer Ubuntu version that is still supported, like mcr.microsoft.com/mssql/server:2025-CU8-ubuntu-24.04 which doesn't EOL until May 2029? I'm not sure if we are able to move from CU5 to CU8 or if there'd be issues. I know the main driving factor is for FIPS support, but moving to an EOL OS seems like a worse idea than manually compiling FIPS support on Ubuntu.

As a side note, outside of just knowing that some folks use FIPS support, do we officially support/provide it, or was it just a convenience that it was there for people that needed it? Microsoft considers any Linux installation of MSSQL (including the Docker image) to not be FIPS compliant anyways based on https://learn.microsoft.com/en-us/sql/linux/security/overview?view=sql-server-ver17. Should we invest our time in figuring out how to get Ubuntu 24.04 LTS to not crash due to FIPS, instead of moving from one soon-to-be-EOL OS to an actually-already-EOL OS?

[mimartin12]

Moving this one back to draft, there are also some internal discussions on some paths forward.

[mimartin12]

Do we have any precedent for RHEL here? Would this be the only usage, anywhere?

This would be the first usage of RHEL here, as for using it anywhere else, that would be up for discussion.

[mimartin12]

The reasoning for moving from Ubuntu to RHEL is that Ubuntu 22.04 LTS is EOL on April 2027. But this moves the image to a RHEL 9.7 image, which was already EOL in May 2026.

docker run --rm --entrypoint cat mcr.microsoft.com/mssql/rhel/server:2025-CU5-rhel-9.1 /usr/lib/os-release
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
NAME="Red Hat Enterprise Linux"
VERSION="9.7 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.7"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.7 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.7
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.7"

Instead of moving to RHEL, would it be possible to update to a newer Ubuntu version that is still supported, like mcr.microsoft.com/mssql/server:2025-CU8-ubuntu-24.04 which doesn't EOL until May 2029? I'm not sure if we are able to move from CU5 to CU8 or if there'd be issues. I know the main driving factor is for FIPS support, but moving to an EOL OS seems like a worse idea than manually compiling FIPS support on Ubuntu.

As a side note, outside of just knowing that some folks use FIPS support, do we officially support/provide it, or was it just a convenience that it was there for people that needed it? Microsoft considers any Linux installation of MSSQL (including the Docker image) to not be FIPS compliant anyways based on https://learn.microsoft.com/en-us/sql/linux/security/overview?view=sql-server-ver17. Should we invest our time in figuring out how to get Ubuntu 24.04 LTS to not crash due to FIPS, instead of moving from one soon-to-be-EOL OS to an actually-already-EOL OS?

Yep, it was my bad to choose 9.7. I misinterpreted some of the RedHat docs.

I was expecting this change to be around CU5, but it looks like even the latest RHEL tag for CU5 is also out of patch support, superseded by 10.2 and, of course, Microsoft doesn't publish CU5 with 10.2. More work needs to be done here.

[mandreko-bitwarden]

Yep, it was my bad to choose 9.7. I misinterpreted some of the RedHat docs.

I was expecting this change to be around CU5, but it looks like even the latest RHEL tag for CU5 is also out of patch support, superseded by 10.2 and, of course, Microsoft doesn't publish CU5 with 10.2. More work needs to be done here.

To be fair, the image being named "9.1" but loading "9.7" and RHEL's EOL process is fairly confusing. ;)