live wire
▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel
upstreambeat.ai
guidePLATFORM

A rootless Quadlet path for .NET 10 services on RHEL for IBM Power

IBM’s walkthrough turns a ppc64le ASP.NET Core image into a user-scoped systemd service, but persistence, boot behavior and single-host limits remain platform decisions.

Rootless Quadlet service on IBM Power: container packaging on one side, systemd-managed host operations on the other.
AI-generated illustration
By The News Desk· Oct 7, 2026the quick take — two AI hosts go live when you do

IBM has published a concrete path for running a .NET 10 ASP.NET Core service on Red Hat Enterprise Linux for IBM Power without writing a Dockerfile or operating the container as root. The pattern uses the .NET SDK to build an OCI image, Podman to run it and a Quadlet file to generate a user-level systemd service.

The useful part for platform teams is not the sample endpoint. It is the handoff between application packaging and host operations: the application reports readiness through Microsoft.Extensions.Hosting.Systemd, while systemd owns startup, restart and journal collection.

Check the Power and RHEL baseline first

IBM’s tested prerequisites are specific: RHEL 9.7 or later or RHEL 10.1 or later on ppc64le, a valid RHEL subscription, Podman 4.4 or later, cgroup v2, access to registry.access.redhat.com and NuGet, and an available host port for the service. The walkthrough installs dotnet-sdk-10.0 and Podman from RHEL repositories and tells operators to verify both the machine architecture and Podman’s reported cgroup version before proceeding.

The project pins Microsoft.Extensions.Hosting.Systemd 10.0.10 and selects Red Hat’s .NET 10 ASP.NET base image. dotnet publish /t:PublishContainer then creates localhost/systemd-demo-service:latest for the rhel.9-ppc64le runtime identifier. That local tag is convenient for the demonstration, but a production pipeline should replace latest with an immutable version or digest and decide how images are promoted to each Power host.

Put the service in the user systemd boundary

For rootless operation, the Quadlet file lives under ~/.config/containers/systemd/. Its container section maps port 8080, sets the ASP.NET listener and enables Notify=true; its service section uses Restart=always, a five-second restart delay and a 900-second startup timeout. Reloading the user systemd manager generates and starts the corresponding .service unit.

The boot boundary matters. A rootless user service normally starts only after that user logs in. IBM therefore enables systemd lingering with loginctl, allowing the user manager and service to start during boot without an interactive session. That is an administrative policy choice: platform teams should create a dedicated service account, control who may enable lingering and manage the unit through that identity rather than a developer’s personal account.

Treat persistence and resilience separately

The sample persists the Quadlet definition and retains logs in the user journal, but it declares no Podman volume. Any application state written only inside the container is therefore outside the demonstrated persistence model. Stateful services need explicit host or named-volume mounts, ownership and SELinux-label decisions, plus backup and restore procedures.

The restart test proves host-local process recovery: killing the container causes systemd to recreate it. It does not provide node failover, replica management, rolling deployment or traffic health routing. The /health endpoint is checked manually; the supplied unit does not use it to decide whether a running but unhealthy process should restart. For a single RHEL-on-Power host, that may be an intentionally small operational footprint. For a shared platform or higher availability target, the same image should move behind a registry and an orchestrated deployment model with declared storage, probes and rollout policy.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk