mgrpxy should automatically deploy systemid from httpd.yaml to volume during proxy setup

[ajaykumarmandapati]

Summary

The mgrpxy start command does not automatically extract and deploy the systemid certificate from httpd.yaml to the uyuni-proxy-systemid volume, requiring manual intervention to make proxy authentication work. This makes proxy deployment error-prone and non-intuitive.

Environment

• Uyuni Version: 2026.01
• uyuni-tools Version: (check with mgrpxy --version)
• OS: openSUSE Leap 15.6
• Deployment Method: Podman (containerized)
• Configuration Method: spacecmd proxy_container_config_generate_cert

Steps to Reproduce

1. Generate proxy configuration using spacecmd:

   podman exec uyuni-server spacecmd proxy_container_config_generate_cert -- \
     proxy.example.com \
     master.example.com \
     2048 \
     admin@example.com \
     -o /tmp/config.tar.gz

2. Transfer config.tar.gz to proxy host and extract:

   scp config.tar.gz root@proxy-host:/root/
   ssh root@proxy-host
   cd /root
   tar -xzf config.tar.gz

3. Ensure systemid volume mount is configured:

   cat /etc/systemd/system/uyuni-proxy-httpd.service.d/systemid-mount.conf
   # Contains: Environment="HTTPD_EXTRA_CONF=-v uyuni-proxy-systemid:/etc/sysconfig/rhn"

4. Start proxy containers:

   mgrpxy start

5. Test proxy authentication:

   curl -sSk -I https://proxy.example.com/rhn/manager/download/debian-12-amd64-uyuni-client/Packages

Expected Behavior

• mgrpxy start should:

  1. Read the httpd.yaml file in the current directory
  2. Extract the system_id field value (XML certificate)
  3. Write it to the uyuni-proxy-systemid volume at /systemid
  4. Start the containers with the systemid already deployed
  5. Proxy authentication should work immediately

• The proxy should successfully authenticate with the master and return HTTP/1.1 403 Forbidden (or 200 with proper client credentials)

Actual Behavior

• mgrpxy start starts containers but does not deploy the systemid from httpd.yaml
• The uyuni-proxy-systemid volume remains empty or contains an old systemid
• Proxy authentication fails with HTTP/1.1 500 Internal Server Error
• Master logs show: Checksum check failed: <old-checksum> != <new-checksum>
• Proxy httpd logs show: socket.timeout: The read operation timed out during server.proxy.login()

Manual Workaround Required

Users must manually extract and deploy the systemid:

# Extract systemid from httpd.yaml
grep 'system_id:' /root/httpd.yaml | \
    sed 's/^[[:space:]]*system_id:[[:space:]]*//' > /tmp/systemid.xml

# Deploy to volume
VOLUME_PATH=$(podman volume inspect uyuni-proxy-systemid --format '{{.Mountpoint}}')
mkdir -p "$VOLUME_PATH"
cp /tmp/systemid.xml "$VOLUME_PATH/systemid"

# Restart httpd container
podman restart uyuni-proxy-httpd

Impact

• User Experience: Confusing and error-prone deployment process
• Documentation Gap: Not documented in official guides that this manual step is required
• Production Risk: Easy to miss this step, leading to non-functional proxies
• Update Complexity: Every proxy configuration update requires manual systemid extraction

Root Cause Analysis

The mgrpxy tool:

1. Reads config.yaml, httpd.yaml, and ssh.yaml to configure containers
2. Uses httpd.yaml to set environment variables and mount volumes
3. Does NOT extract the system_id field from httpd.yaml and write it to the filesystem/volume
4. Assumes the systemid already exists in the volume (which is not true for new deployments or updates)

The httpd.yaml contains the systemid in this format:

httpd:
    system_id: <?xml version="1.0"?><params><param><value><struct>...

But this value is never written to /etc/sysconfig/rhn/systemid in the container.

Proposed Solution

Enhance mgrpxy start to automatically deploy the systemid:

Option 1: Deploy During Container Start (Recommended)

Modify mgrpxy start to:

1. Check if httpd.yaml exists in the current directory
2. Extract the system_id field value
3. Get the uyuni-proxy-systemid volume mount point
4. Write the systemid to <volume-path>/systemid
5. Proceed with normal container startup

Option 2: Add Explicit Command

Add a new command: mgrpxy deploy-systemid that users can run before mgrpxy start:

mgrpxy deploy-systemid /root/httpd.yaml
mgrpxy start

Option 3: Init Container

Use a podman init container that runs before httpd starts and extracts/deploys the systemid from the yaml configuration.

Additional Context

Related Issues:

• Proxy systemid must be in a persistent volume for authentication to work
• The volume mount is configured via systemd override: HTTPD_EXTRA_CONF=-v uyuni-proxy-systemid:/etc/sysconfig/rhn
• This issue affects both new proxy deployments and proxy configuration updates

Documentation References:

• Containerized Uyuni Proxy Setup
• The official documentation does not mention the need to manually extract and deploy the systemid

Affected Commands:

• mgrpxy start
• mgrpxy install (if it also doesn't handle systemid deployment)

Additional Information

Workaround Script

We've created an automated deployment script that handles this:

#!/bin/bash
# Automated proxy configuration deployment
# This is what mgrpxy should do automatically

CONFIG_ARCHIVE="${1:-/root/config.tar.gz}"
TEMP_DIR=$(mktemp -d)
tar -xzf "$CONFIG_ARCHIVE" -C "$TEMP_DIR"

# Extract systemid from httpd.yaml
grep 'system_id:' "$TEMP_DIR/httpd.yaml" | \
    sed 's/^[[:space:]]*system_id:[[:space:]]*//' > "$TEMP_DIR/systemid.xml"

# Deploy to volume
VOLUME_PATH=$(podman volume inspect uyuni-proxy-systemid --format '{{.Mountpoint}}')
mkdir -p "$VOLUME_PATH"
cp "$TEMP_DIR/systemid.xml" "$VOLUME_PATH/systemid"

# Move config files
cp "$TEMP_DIR"/*.yaml /root/

# Start containers
cd /root
mgrpxy start

[aaannz]

Why do you have custom volume for the systemid file?

Systemid file is mounted as a secret. I suppose this might be a race between volume mount and secret mount.

[ajaykumarmandapati]

Thanks for the quick response @aaannz!

You're right to question the custom volume approach. We implemented this based on trial and error since the official documentation doesn't explain how systemid deployment works.

Our Setup

We're using the volume mount because:

1. Official docs don't mention systemid handling: The containerized proxy setup documentation only covers:

   • Generate config with spacecmd proxy_container_config_generate_cert
   • Transfer config.tar.gz to proxy host
   • Run mgrpxy start

   There's no mention of systemid, secrets, or how authentication is configured.

2. Trial and error led us to volumes: When we ran mgrpxy start after extracting config.tar.gz, proxy authentication failed with:

   • Master logs: Checksum check failed
   • Proxy logs: socket.timeout during server.proxy.login()

   We discovered the systemid in httpd.yaml and manually deployed it to make authentication work.

Questions

1. How should systemid be deployed? Should mgrpxy automatically:

   • Extract systemid from httpd.yaml?
   • Create a Podman secret from it?
   • Mount it to the httpd container?

2. What's the correct workflow? After extracting config.tar.gz, what additional steps (if any) are needed before mgrpxy start?

3. Is this a documentation gap? Should the official docs explain:

   • How systemid gets from httpd.yaml into the running container?
   • Whether users need to create secrets manually?
   • The expected secret/volume structure?

4. Race condition? You mentioned a potential race between volume mount and secret mount. Can you elaborate on:

   • How mgrpxy expects to mount systemid as a secret?
   • What might be conflicting with our volume approach?

Our Workaround

For reference, here's what we're currently doing (which works but feels hacky):

# Extract systemid from httpd.yaml
grep 'system_id:' /root/httpd.yaml | \
    sed 's/^[[:space:]]*system_id:[[:space:]]*//' > /tmp/systemid.xml

# Deploy to volume
VOLUME_PATH=$(podman volume inspect uyuni-proxy-systemid --format '{{.Mountpoint}}')
mkdir -p "$VOLUME_PATH"
cp /tmp/systemid.xml "$VOLUME_PATH/systemid"

# Start containers
mgrpxy start

Environment Details

• Uyuni Version: 2026.01
• OS: openSUSE Leap 15.6
• Deployment: Podman (not Kubernetes)
• Configuration: spacecmd proxy_container_config_generate_cert with self-signed certs
• Proxy registered: Yes, proxy host is registered as a Salt minion to the master

We're happy to test the proper secret-based approach if you can point us to documentation or examples. We want to do this the right way!