Restore openssl in Slurm runtime images

[Copilot]

Summary

The previous refactor dropped openssl from the runtime debug package set on the assumption it was pulled in transitively. It isn't reliably present, so re-add it explicitly.

• Add openssl back to the debug install line in all six runtime Dockerfiles: 25.05, 25.11, and master across ubuntu24.04 and rockylinux9.

Breaking Changes

None.

Testing Notes

Build the affected flavors via docker buildx bake and confirm openssl is present in the final runtime image.

Additional Context

Companion fix to the s2n shared-script refactor in the prior commit on this branch.

Original prompt

Create a pull request in repository vantagecompute/slurm-containers based on branch feat/tls_s2n_v2_sync_with_main.

Goal:

• Remove now-redundant package-install changes whose only purpose was adding openssl to image runtime/debug package lists, since the rebased mainline branch already accounts for OpenSSL in the container builds.
• Refactor the current s2n build logic so it is more generic and centralized in the build process, and can be consumed by each image build rather than being embedded in a single image-specific Dockerfile.

Context:

• The current PR branch feat/tls_s2n_v2_sync_with_main is a rebase-on-main branch.
• There is custom s2n-related logic currently present in the repo, including image-specific build/install steps for s2n-tls and Slurm packaging integration.
• We want to preserve the actual s2n TLS enablement while dropping redundant OpenSSL package additions from our custom delta.

Requested changes:

1. Identify and remove the custom apt/dnf package-install edits that add openssl where those edits are now redundant with main.
2. Introduce a centralized/generic mechanism for building or provisioning s2n-tls that can be shared across the relevant image builds.
3. Update image builds to consume that centralized s2n mechanism instead of duplicating image-specific logic.
4. Keep the resulting implementation aligned with the existing repository build patterns and Docker build structure.
5. Ensure the branch still builds cleanly after the refactor.

Implementation guidance:

• Prefer a reusable script, shared build stage, or other centralized mechanism already idiomatic for this repository.
• Minimize unrelated changes.
• Preserve support for the Slurm TLS s2n plugin; do not remove required --with-s2n or runtime library handling unless replaced with an equivalent centralized approach.
• The PR should target branch feat/tls_s2n_v2_sync_with_main.

Deliverable:

• Open a pull request with the refactor and cleanup above.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: possibly it is that we dont need our feat/tls_s2n_v2 to add openssl anymore because the slurm containers main branch now accounts for that - we are using this pr to rebase on main, what custom bits can we drop now that the containers build include openssl ?

Assistant: Yes — the main thing you can likely drop from feat/tls_s2n_v2 now is any custom OpenSSL installation/bootstrap logic, because this PR already rebases onto a mainline that adds openssl to the container runtime/debug packages across the images.

What I see in PR #1:

• openssl is now added directly in upstream container Dockerfiles for:
  • schedmd/slurm/25.05/rockylinux9/Dockerfile
  • schedmd/slurm/25.05/ubuntu24.04/Dockerfile
  • schedmd/slurm/25.11/rockylinux9/Dockerfile
  • schedmd/slurm/25.11/ubuntu24.04/Dockerfile
  • schedmd/slurm/master/rockylinux9/Dockerfile
  • schedmd/slurm/master/ubuntu24.04/Dockerfile
• So if your branch was separately adding openssl packages in those images, that part is now redundant.

What probably can be dropped from your custom branch:

1. Any apt-get install openssl / dnf install openssl additions

   • If they were only there to make the runtime image have the openssl CLI/libs available, main now covers that.

2. Any duplicate runtime-only OpenSSL dependency wiring

   • e.g. helper snippets/comments/checks whose only purpose was “ensure openssl exists in the container”.

3. Any image flavor/version-specific OpenSSL deltas

   • If you had separate edits for 25.05, 25.11, master, Ubuntu, Rocky, those should be rechecked because upstream now applies them broadly.

What you probably should not drop just because OpenSSL is present:

1. s2n-tls build/install logic

   • In schedmd/slurm/25.11/ubuntu24.04/Dockerfile, this PR still contains custom logic to:
     • install libssl-dev, cmake, git
     • clone and build aws/s2n-tls
     • install libs2n.so
     • patch debian/rules with --with-s2n=/usr/local
     • add the dh_shlibdeps override
     • copy libs2n.so* into the runtime image
   • That is not replaced merely by adding openssl.

2. Anything specifically needed for tls_s2n.so

   • OpenSSL being present does not mean Slurm is now built with s2n plugin support automatically.
   • If your branch adds the actual configure/build/package integration for s2n, keep that unless main added equivalent --with-s2n support.

3. Non-OpenSSL customizations

   • sssd-client additions
   • priority=1 supervisor changes
   • workflow changes
   • registry/version rebasing changes
   • removal of dbus.ini
   • these are unrelated to OpenSSL and need independent review.

My practical recommendation:

• Compare your feat/tls_s2n_v2 branch against this rule:
  • Drop changes whose only effect is “install openssl in image”.
  • Keep changes required to **build Slurm wi...

This pull request was created from Copilot chat.