Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace dig with getent hosts in 10-wait-for-hosts.sh #100

Open
nicodarge opened this issue Jan 28, 2025 · 1 comment
Open

Replace dig with getent hosts in 10-wait-for-hosts.sh #100

nicodarge opened this issue Jan 28, 2025 · 1 comment

Comments

@nicodarge
Copy link

nicodarge commented Jan 28, 2025

Hello,

I encountered an issue when deploying PuppetDB using docker run. The current script 10-wait-for-hosts.sh uses dig for DNS resolution, which is causing problems in my environment. Using dig prevents the use of /etc/hosts and directly queries DNS servers. I propose modifying the script to use getent hosts instead, which checks /etc/hosts before querying DNS servers, thereby improving reliability. I have no idea if it's a requirement to use dig. In any case, the command getent hosts is available in the container.

Here is the modified code :

#!/bin/sh

set -e

# Wait on hosts to become available before proceeding
#
#
# Optional environment variables:
#   PUPPETDB_WAITFORHOST_SECONDS     Number of seconds to wait for DNS names of
#                                    Postgres and Puppetserver to resolve, defaults to 30
#   PUPPETDB_WAITFORHEALTH_SECONDS   Number of seconds to wait for health
#                                    checks of Puppetserver to succeed, defaults to 360
#                                    to match puppetserver healthcheck max wait
#   PUPPETDB_WAITFORPOSTGRES_SECONDS Additional number of seconds to wait on Postgres,
#                                    after PuppetServer is healthy, defaults to 60
#   PUPPETDB_POSTGRES_HOSTNAME       Specified in Dockerfile, defaults to postgres
#   PUPPETSERVER_HOSTNAME            DNS name of puppetserver to wait on, defaults to puppet


msg() {
    echo "($0) $1"
}

error() {
    msg "Error: $1"
    exit 1
}

wait_for_host_name_resolution() {
  /wtfc.sh --timeout="${2}" --interval=1 --progress "getent hosts $1"
  # additionally log the DNS lookup information for diagnostic purposes
  NAME_RESOLVED=$?
  getent hosts $1
  if [ $NAME_RESOLVED -ne 0 ]; then
    error "dependent service at $1 cannot be resolved or contacted"
  fi
}

wait_for_host_port() {
  # -v verbose -w connect / final net read timeout -z scan and don't send data
  /wtfc.sh --timeout=${3} --interval=1 --progress "nc -v -w 1 -z '${1}' ${2}"
  if [ $? -ne 0 ]; then
    error "host $1:$2 does not appear to be listening"
  fi
}

PUPPETDB_WAITFORHOST_SECONDS=${PUPPETDB_WAITFORHOST_SECONDS:-30}
PUPPETDB_WAITFORPOSTGRES_SECONDS=${PUPPETDB_WAITFORPOSTGRES_SECONDS:-60}
PUPPETDB_WAITFORHEALTH_SECONDS=${PUPPETDB_WAITFORHEALTH_SECONDS:-360}
PUPPETDB_POSTGRES_HOSTNAME="${PUPPETDB_POSTGRES_HOSTNAME:-postgres}"
PUPPETSERVER_HOSTNAME="${PUPPETSERVER_HOSTNAME:-puppet}"
PUPPETSERVER_PORT="${PUPPETSERVER_PORT:-8140}"

# wait for postgres DNS
wait_for_host_name_resolution $PUPPETDB_POSTGRES_HOSTNAME $PUPPETDB_WAITFORHOST_SECONDS

# wait for puppetserver DNS, then healthcheck
if [ "$USE_PUPPETSERVER" = true ]; then
  wait_for_host_name_resolution $PUPPETSERVER_HOSTNAME $PUPPETDB_WAITFORHOST_SECONDS
  HEALTH_COMMAND="curl --silent --fail --insecure 'https://${PUPPETSERVER_HOSTNAME}:"${PUPPETSERVER_PORT}"/status/v1/simple' | grep -q '^running$'"
fi

if [ -n "$HEALTH_COMMAND" ]; then
  /wtfc.sh --timeout=$PUPPETDB_WAITFORHEALTH_SECONDS --interval=1 --progress "$HEALTH_COMMAND"
  if [ $? -ne 0 ]; then
    error "Required health check failed"
  fi
fi

# wait for postgres
wait_for_host_port $PUPPETDB_POSTGRES_HOSTNAME "${PUPPETDB_POSTGRES_PORT:-5432}" $PUPPETDB_WAITFORPOSTGRES_SECONDS

I hope this change can be reviewed and merged to address the issue. I would have liked to open a pull request directly, but I didn't have the permissions to create a branch.

Thank you !

@rwaffen
Copy link
Member

rwaffen commented Jan 31, 2025

can you please reopen this issue in https://github.com/OpenVoxProject/container-openvoxdb ? we are going to deprecate this repo. sadly i cannot move this issue over to this repo, because it belongs to another org.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants