Skip to content

[Bug]: Puppet CM fails to start when using different ports for CM and CA containers #24

Description

@Kivernitas

Is this a critical security issue?

  • This is not a security issue.

Describe the Bug

Using compile master (CM) and CA containers on different ports (e.g. 8142 for CM and 8140 for CA), CM fails to start due to not getting the correct ca_port number from the 90-ca.sh startup script.
More specifically the --masterport flag in puppet ssl bootstrap command has no effect.

Error: Connection to https://puppetca:8142/puppet-ca/v1 failed, trying next route: Request to https://puppetca:8142/puppet-ca/v1 failed after 0.001 seconds: Failed to open TCP connection to puppetca:8142 (Connection refused - connect(2) for "puppetca" port 8142)

Expected Behavior

Ability to use different ports for CM and CA containers.
The --masterport flag in puppet ssl bootstrap should correctly use the specified port.

Steps to Reproduce

  1. Built image openvoxserver:8.8.0-main to enable set -x on 90-ca.sh for debugging.

  2. docker-compose file used to create the CM and CA containers with different ports:

version: '3.8'

services:
  puppetcm:
    image: openvoxserver_debug:8.8.0
    container_name: puppetcm
    hostname: puppetcm
    environment:
      - OPENVOXSERVER_PORT=8142
      - CA_ENABLED=false
      - CA_HOSTNAME=puppetca
    networks:
      - puppet_network
    restart: unless-stopped

  puppetca:
    image: ghcr.io/openvoxproject/openvoxserver:8.8.0-main
    container_name: puppetca
    hostname: puppetca
    environment:
      - OPENVOXSERVER_PORT=8140
      - CA_HOSTNAME=puppetca
      - CA_PORT=8140
    networks:
      - puppet_network
    restart: unless-stopped

networks:
  puppet_network:
    driver: bridge
  1. Error in the logs:
025-03-06T10:40:57.142818260Z + puppet ssl bootstrap --server=puppetca --masterport=8140
2025-03-06T10:40:57.657213344Z Error: Connection to https://puppetca:8142/puppet-ca/v1 failed, trying next route: Request to https://puppetca:8142/puppet-ca/v1 failed after 0.001 seconds: Failed to open TCP connection to puppetca:8142 (Connection refused - connect(2) for "puppetca" port 8142)
2025-03-06T10:40:57.657229469Z Wrapped exception:
2025-03-06T10:40:57.657230594Z Failed to open TCP connection to puppetca:8142 (Connection refused - connect(2) for "puppetca" port 8142)
2025-03-06T10:40:57.657320010Z Info: Will try again in 120 seconds.

Environment

Version: 8.8.0
Platform: Kubernetes 1.30

Additional Context

A workaround for this is to create an new init script to explicitly set the ca_port in puppet.conf:

#!/bin/bash

set -e

puppet config set ca_port $CA_PORT --section main

This ensures that the CA port is correctly set to 8140, allowing the CM container to start correctly:

2025-03-06T11:19:05.333709555Z + puppet ssl bootstrap --server=puppetca --masterport=8140
2025-03-06T11:19:05.833835291Z Info: Creating a new RSA SSL key for puppetcm
2025-03-06T11:19:06.797105417Z Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
2025-03-06T11:19:06.797729208Z Info: Creating a new SSL certificate request for puppetcm

Relevant log output

Activity

  1. changed the title [-][Bug]: Puppet CM Fails to Start When Using Different Port for CM and CA containers[/-] [+][Bug]: Puppet CM fails to start when using different ports for CM and CA containers[/+] on Mar 6, 2025
  2. dotconfig404 commented on May 22, 2025

    @dotconfig404
    Contributor

    This is similar to my issue where I am trying to set the CA_HOSTNAME while CA_ENABLED is true, but because of reasons (?) these variables are ignored when CA_ENABLED=true.

    From the docs:

    CA_HOSTNAME 	The DNS hostname for the openvoxserver running the CA. Does nothing unless CA_ENABLED=false
    
    Defaults to puppet
    CA_PORT 	The listening port of the CA. Does nothing unless CA_ENABLED=false
    
    Defaults to 8140
    CA_ALLOW_SUBJECT_ALT_NAMES 	Whether or not SSL certificates containing Subject Alternative Names should be signed by the CA. Does nothing unless CA_ENABLED=true.
    
    Defaults to false
    
  3. dotconfig404 commented on May 30, 2025

    @dotconfig404
    Contributor

    dont remember what my issue was exactly, I will check it later, but found out your issue is a bit different.

    turns out masterport is deprecated and gets overridden by the server port setting even when explicitly calling it like this.

    #49

    this should fix the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions