Loading post…
Red HatJohn SpinksTutorial
Manage RHEL with MCP servers and Red Hat Lightspeed
Summary
The post details a hands-on lab from Red Hat Summit 2026 that demonstrated managing Red Hat Enterprise Linux using three Model Context Protocol (MCP) servers connected to a single goose client. The MCP servers for Red Hat Lightspeed, Red Hat Satellite, and RHEL each require different authentication: a Hybrid Cloud Console service account, a registry.redhat.io login with a CA bundle and personal access token, and pre-configured SSH keys respectively. Installation is straightforward using Podman containers for Lightspeed and Satellite, and uv for the RHEL server. The author tested about a dozen models and found MiniMax M2 effective, but had to switch to Claude Opus 4.6 when a shared Vertex AI token limit was exceeded during the lab. Key takeaways include that authentication is the most complex part, model choice significantly impacts behavior and cost, and capacity limits must be considered for multi-user environments.
Context
Managing Red Hat Enterprise Linux infrastructure using natural language queries through Model Context Protocol (MCP) servers connected to Red Hat Lightspeed, Red Hat Satellite, and RHEL hosts, orchestrated via the goose client.
Approach / What changed
Deploy three MCP servers on a single RHEL 10.1 host: Red Hat Lightspeed MCP (Podman container, Hybrid Cloud Console service account), Red Hat Satellite MCP (Podman container, registry.redhat.io login, CA bundle, personal access token), and RHEL MCP (uv installation, SSH keys). Configure the goose client with stdio extensions for each server and select a model (e.g., MiniMax M2 or Claude Opus 4.6). Use guarded command execution for the RHEL server.
Takeaways
Authentication is the most complex part of setting up MCP servers, with each server requiring different credentials: Hybrid Cloud Console service account for Lightspeed, registry.redhat.io login and personal access token for Satellite, and pre-configured SSH keys for RHEL.
Model selection significantly impacts behavior and cost; MiniMax M2 was effective but Claude Opus 4.6 provided deeper analysis at nearly 10x the cost per token and longer response times.
Capacity limits (token-per-minute and API budgets) are a concern for multi-user environments; a setup that works for 12 people can fail for 60 due to shared model consumption.
FAQ
What authentication is needed for each MCP server?
Red Hat Lightspeed requires a Hybrid Cloud Console service account with appropriate roles. Red Hat Satellite requires a registry.redhat.io login, the Satellite CA bundle, and a personal access token. RHEL requires working SSH keys to all target hosts.
How do you configure the goose client to use multiple MCP servers?
Edit the ~/.config/goose/config.yaml file to add a separate extension section for each MCP server, specifying the stdio type and the command to run the server (e.g., Podman run for Lightspeed and Satellite, uv run for RHEL). Also set the model and provider API key.
What model was used in the lab and why was it changed?
The author tested about a dozen models and initially chose MiniMax M2. However, during the first full lab session, a shared Vertex AI token limit was exceeded, so they switched to Claude Opus 4.6, which was more expensive and slower but worked within the available capacity.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.