Automating GBase Database Pre-Installation Checks: A Practical 18-Check Bash Workflow

gha_preinstall -i A already performs 18 pre-installation checks for GBase Database(GBase 8c). So why build a custom Bash script?

Because the official tool identifies which checks are Abnormal, but it does not automatically give you a convenient side-by-side comparison of three hosts.

A common deployment mistake is to check the first machine carefully, assume the other two have identical configurations, and proceed with installation. That assumption is often where cluster deployment problems begin.

This tutorial shows how to build a lightweight GBase Database pre-installation validation workflow using Bash. It combines local environment checks, the official 18-check validation tool, and cross-host log comparison.

The workflow has three steps:

1. Collect environment information on every host.
2. Run the official GBase Database pre-installation checks.
3. Collect and compare the results across all hosts.

Step 1: Create a Local Environment Check Script

Start by creating a script named precheck.sh on each host.

The script collects basic operating system, kernel, network, memory, resource limit, firewall, SELinux, disk, and port information.

#!/bin/bash

H=$(hostname)
OUT="/tmp/gbase8c_precheck_${H}.log"

{
  echo "== host: $H =="

  echo "-- OS --"
  head -n 2 /etc/os-release

  echo "-- kernel --"
  uname -r

  echo "-- hostname resolution --"
  getent hosts "$H"

  echo "-- swap --"
  swapon --show

  echo "-- THP --"
  cat /sys/kernel/mm/transparent_hugepage/enabled

  echo "-- scheduler --"
  cat /sys/block/sda/queue/scheduler

  echo "-- resource limits --"
  ulimit -n
  ulimit -u

  echo "-- firewall --"
  systemctl is-active firewalld

  echo "-- SELinux --"
  sestatus | head -n 1

  echo "-- disk --"
  df -h /home/gbase

  echo "-- listening ports --"
  ss -tlnp | grep -E ':(20001|2379|6666|5432|15432|15433|20010)([[:space:]]|$)' || true

} | tee "$OUT"

echo "Local check log: $OUT"

A few implementation details are worth noting:

• hostname identifies the current host in the output.
• getent hosts checks whether the hostname can be resolved through the configured name service.
• THP output helps identify differences in Transparent Huge Pages configuration.
• ulimit captures the current shell's resource limits.
• ss identifies listening services that may conflict with planned database ports.

The example uses /dev/sda and /home/gbase as deployment assumptions. Adjust these paths to match the actual storage device and installation layout.

Step 2: Run the Official GBase Database Checks

Local environment information is useful, but it does not replace the official validation tool.

Run gha_preinstall on each host using the same cluster configuration:

cd /home/gbase/gbase_package/script/

OUT="/tmp/gbase8c_precheck_$(hostname).log"

./gha_preinstall -i A \
  -f /home/gbase/gbase.yml | tee -a "$OUT"

This appends the official GBase Database pre-installation check results to the corresponding host log.

The distinction is important:

• The custom script collects environment details.
• gha_preinstall -i A provides the official validation results.

Together, they provide more useful evidence than either output alone.

Step 3: Collect and Compare Results Across Hosts

Once precheck.sh is available on all three hosts, execute it remotely and collect the output on a central machine.

For example:

mkdir -p /tmp/logs

for h in node1 node2 node3; do
  ssh "$h" "bash /tmp/precheck.sh"
  scp "$h:/tmp/gbase8c_precheck_${h}.log" \
      "/tmp/logs/${h}.log"
done

This collects the local environment logs.

The official check output can also be retrieved from each host:

for h in node1 node2 node3; do
  scp "$h:/tmp/gbase8c_precheck_${h}.log" \
      "/tmp/logs/${h}.log"
done

If the logs are already collected, compare the official validation results:

grep -H "Abnormal" /tmp/logs/*.log

For a more detailed comparison, review the corresponding sections in each host's log rather than relying exclusively on the Abnormal count.

The objective is to identify both individual host differences and configuration problems shared by every host.

Step 4: Understand the Two Types of Problems

Cross-host comparison usually reveals two different categories of issues.

Case 1: A Single-Host Outlier

For example:

Host	THP configuration
node1	never
node2	never
node3	always

Only node3 has an inconsistent THP setting.

This is exactly the type of issue that can be missed when engineers inspect one machine and assume the others match.

Case 2: A Collective Configuration Error

Consider another example:

Host	Swap status
node1	Enabled
node2	Enabled
node3	Enabled

All three hosts have the same configuration, but consistency does not automatically mean correctness.

This is potentially more dangerous because a simple diff shows no differences.

The solution is to compare every host against the deployment standard, not just against its neighbors.

Consistency and compliance are two different things. Both must be verified.

Step 5: Make Environment Validation Repeatable

Automating GBase Database pre-installation checks provides two additional benefits.

First: Repeatability.

The same script can be reused for:

• Initial cluster installation.
• Adding or replacing hosts.
• Cluster expansion.
• Reinstallation after environment changes.

This reduces dependence on individual engineers remembering every check.

Second: Delivery Evidence.

The collected logs can be attached to the deployment record.

Instead of simply reporting that environment checks were completed, the delivery team can provide actual results for every host.

This makes technical reviews and responsibility handovers much easier.

Important: A Script Collects Information, Not Deployment Decisions

One final caution: the custom script should not automatically determine whether an environment is qualified for deployment.

For example, the required swap configuration and ulimit -n values may depend on the GBase Database deployment layout, workload, and applicable version-specific requirements.

The 18 official checks provide a validation baseline, but additional environment checks may still be necessary.

The purpose of automation is to make information collection consistent and repeatable—not to replace engineering judgment.

A reliable GBase Database deployment starts with three habits: check every host, compare every result, and verify every value against the deployment standard.

That is how 18 pre-installation checks become a repeatable operational process rather than a memory test.