Labsco
uyuni-project logo

Uyuni

โ˜… 12

from uyuni-project

A server to interact with the Uyuni Server API for infrastructure and configuration management.

๐Ÿ”ฅ๐Ÿ”ฅ๐Ÿ”ฅโœ“ VerifiedAccount requiredAdvanced setup

Uyuni MCP Server

The Uyuni MCP Server is a Model Context Protocol (MCP) server implementation that bridges the gap between Large Language Models (LLMs) and the Uyuni configuration and infrastructure management solution.

This project allows AI agents or MCP-compliant clients (such as Gemini CLI or Claude Desktop) to securely interact with your Uyuni server. The Uyuni MCP server enables users to manage their Linux infrastructure using natural language. Instead of navigating the web UI or writing complex API scripts, you can simply ask your AI assistant to perform tasks like getting system details, checking for updates, or scheduling maintenance.

Key Capabilities This server exposes a suite of tools that allow LLMs to:

  • Inspect Infrastructure: Retrieve lists of active systems and view system information.
  • Manage Updates: Identify systems with pending security updates or CVEs and schedule patch applications.
  • Execute Actions: Schedule patches, system updates and reboots.

It is designed to be run as a container remotely (HTTP) or locally (stdio), offering a streamlined way to integrate AI-driven automation into your system administration workflows.

Table of Contents

Tool List

  • list_systems: Fetches a list of active systems from the Uyuni server, returning their names and IDs.
  • get_system_details: Gets details of the specified system.
  • get_system_event_history: Gets the event/action history of the specified system.
  • get_system_event_details: Gets the details of the event associated with the especified server and event ID.
  • find_systems_by_name: Lists systems that match the provided hostname.
  • find_systems_by_ip: Lists systems that match the provided IP address.
  • get_system_updates: Checks if a specific system has pending updates (relevant errata).
  • summarize_system_updates: Returns low-token summary counts for pending updates of a specific system (optional advisory_types filter).
  • query_system_updates: Returns paginated pending updates for a specific system with optional CVE expansion and optional advisory_types filter.
  • check_all_systems_for_updates: Checks all active systems for pending updates.
  • summarize_fleet_updates: Returns low-token paginated summary of systems with pending updates.
  • list_systems_needing_update_for_cve: Finds systems requiring a security update for a specific CVE identifier.
  • list_systems_needing_reboot: Fetches a list of systems from the Uyuni server that require a reboot.
  • get_unscheduled_errata: Lists applicable and unscheduled patches for a system.
  • list_activation_keys: Retrieves a list of available activation keys for bootstrapping new systems.
  • list_all_scheduled_actions: Fetches a list of all scheduled, in-progress, completed, or failed actions.
  • list_system_groups: Fetches a list of system groups from the Uyuni server.
  • list_group_systems: Lists the systems in a system group.
  • schedule_pending_updates_to_system: Checks for pending updates on a system, schedules all of them to be applied.
  • schedule_specific_update: Schedules a specific update (erratum) to be applied to a system.
  • add_system: Bootstraps and registers a new system with Uyuni using an activation key.
  • remove_system: Decommissions and removes a system from Uyuni management.
  • schedule_system_reboot: Schedules a reboot for a specified system.
  • cancel_action: Cancels a previously scheduled action, such as an update or reboot.
  • create_system_group: Creates a new system group in Uyuni.
  • add_systems_to_group: Adds systems to a system group.
  • remove_systems_from_group: Removes systems from a system group.

Security

OAuth 2.0

When running the server in HTTP mode (UYUNI_MCP_TRANSPORT=http), it is strongly recommended to secure it with an authentication layer. The server includes support for OAuth 2.0 to authenticate client requests. To enable it, set the UYUNI_AUTH_SERVER environment variable to your identity provider's URL.

Configuring an Identity Provider

Uyuni must be configured to trust the same identity provider as the MCP server. When UYUNI_AUTH_SERVER is set, the MCP server forwards the user's bearer token to Uyuni at POST /manager/api/oidcLogin.

Configure Uyuni in rhn.conf:

web.oidc.enabled = true
web.oidc.idp.issuer = https://auth.example.com

If you want to set the JWKS endpoint explicitly, add:

web.oidc.idp.jwks_path = /realms/your-realm/protocol/openid-connect/certs

If web.oidc.idp.jwks_path is left unset, Uyuni resolves it from the issuer's /.well-known/openid-configuration document.

Uyuni also validates the expected audience and the username claim. The defaults introduced by Uyuni are:

web.oidc.jwt.audience = uyuni-server
web.oidc.jwt.username_claim = preferred_username

Notes:

  • web.oidc.idp.issuer must match the token iss claim exactly.
  • The forwarded token must include a sub claim.
  • web.oidc.jwt.username_claim must point to a claim whose value matches an existing active Uyuni username.
  • The forwarded token must include both audiences required by this integration: mcp-server-uyuni for the MCP server and uyuni-server for Uyuni.
  • If you change web.oidc.jwt.audience in Uyuni, your identity provider must issue the matching audience value.

After updating rhn.conf, restart the relevant Uyuni services according to your deployment procedure, then verify that:

  • the token issuer matches web.oidc.idp.issuer
  • the token audience includes uyuni-server
  • the token contains preferred_username or your configured username claim
  • the username from that claim already exists in Uyuni

Best Practices

Follow these practices to harden your deployment.

Principle of Least Privilege

The Uyuni user configured via UYUNI_USER should have the minimum set of permissions required to perform its tasks. Avoid using highly privileged accounts like admin. See "Role-Based Access Control" in Uyuni documentation to fine-tune permissions.

Enable Write Actions Cautiously

Enabling state-changing tools with UYUNI_MCP_WRITE_TOOLS_ENABLED=true poses a significant risk. Only enable this in trusted environments and when all other security measures, such as authentication and HTTPS, are in place.

Secure Secrets

Avoid hardcoding secrets like passwords (UYUNI_PASS) or SSH keys (UYUNI_SSH_PRIV_KEY) in your configuration files, especially if they are checked into version control. Use a secrets management system (e.g., HashiCorp Vault, cloud provider secret stores) or inject them as environment variables at runtime. Ensure configuration files containing secrets (like uyuni-config.env) are not committed to Git.

Production Logging

For production environments, configure structured logging to a file for monitoring and auditing:

  • Set UYUNI_MCP_LOG_FILE_PATH to a secure location (e.g., /var/log/mcp-server-uyuni.log).
  • Set UYUNI_MCP_LOG_LEVEL to INFO or WARNING. Regularly review logs for unusual or unauthorized activity.

Feedback

We would love to hear from you! Any idea you want to discuss or share, please do so at https://github.com/uyuni-project/uyuni/discussions/10562

If you encounter any bug, be so kind to open a new bug report at https://github.com/uyuni-project/mcp-server-uyuni/issues/new?type=bug

Thanks in advance from the Uyuni team!

Disclaimer

This is an open-source project provided "AS IS" without any warranty, express or implied. Use at your own risk. For full details, please refer to the License section.