Summary: Before installing GBase Database(GBase 8a), verify the Linux environment on every cluster node. These six pre-installation checks cover OS compatibility, disk capacity, network ports, kernel settings, dependencies, and Python runtime configuration.
A database installer can automate deployment, but it cannot guarantee that every server has the correct operating system configuration.
When deploying GBase Database(GBase 8a), a mismatch in the Python interpreter, a missing dependency, an occupied port, or an inconsistent kernel setting can delay installation or cause problems when cluster services start.
I use the following six checks before deployment. On a small three-node cluster, the initial inspection can take around ten minutes, depending on the environment.
The key rule is simple: run every check on every node, not just the first server.
1. Check the Operating System and Hostname
Start by confirming the OS release, kernel version, and hostname.
cat /etc/redhat-release
uname -r
hostname
hostname | wc -c
For virtual machines, check whether the CPU exposes the rdtscp instruction if it is required by your target GBase Database version:
grep -m1 -o rdtscp /proc/cpuinfo
Verify that all nodes use a supported and consistent OS and kernel configuration. The hostname should comply with the product's documented length restrictions; for the environment covered by this checklist, the target is fewer than 46 characters.
Do not assume that two machines running the same Linux distribution are identical. Minor-version differences, virtual CPU settings, and kernel configurations can affect deployment.
2. Check Disk Space, Inodes, and Swap
Insufficient disk space is easy to notice. Insufficient inodes can be less obvious, especially when a workload creates a large number of small files.
Inspect the filesystem containing the installation directory and review available memory and swap:
df -h /opt
df -i /opt
free -h
Check the target filesystem against the requirements of your specific GBase Database release.
For the environment described here, the planning baseline includes:
At least 1 GB of available installation space
Approximately 300 MB for metadata, plus additional operational headroom
Sufficient free inodes for the expected file workload
A filesystem type supported by the target OS and product version
The exact filesystem, free-space, inode, and swap requirements must be verified against the applicable installation manual. For example, older RHEL releases and newer releases may have different recommended filesystem configurations.
Why check inodes? A filesystem can have free storage capacity while running out of available inodes. When that happens, creating files may fail even though df -h appears healthy.
Correcting a filesystem layout after deployment can be much more disruptive than validating it beforehand.
3. Check Network Connectivity and Required Ports
GBase Database(GBase 8a) uses different ports for cluster components. Confirm the required port list during planning, before installation begins.
Commonly referenced ports include:
| Component | Port |
|---|---|
| GCluster | 5258 |
| GNode | 5050 |
| GCware | 5918, 5919 |
| syncServer | 5288 |
| GCRecover | 6268 |
Confirm these values against the configuration and documentation for your release. Also check any additional ports required by the selected deployment topology.
To inspect TCP ports currently listening on a node:
ss -tlnp
To check whether the ports above appear in the local listening socket table:
for p in 5258 5050 5918 5919 5288 6268; do
if ss -H -ltn "sport = :$p" | grep -q .; then
echo "LISTENING $p"
else
echo "NOT LISTENING $p"
fi
done
Important: NOT LISTENING does not prove that a port is available for installation. A service could bind to it later, and UDP sockets are not covered by this TCP check. Review existing services, configured port reservations, firewall rules, and connectivity between nodes as well.
4. Check Kernel Settings and Process Limits
System settings can affect database deployment and cluster service startup.
Start by inspecting the current configuration:
ulimit -v
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/block/sda/queue/scheduler
systemctl show -p DefaultTasksMax
Check the following against the target GBase Database release:
Virtual memory limits for the installation and database users
Transparent Huge Pages (THP) configuration
I/O scheduler settings for the actual data devices
Systemd task limits
For environments requiring THP to be disabled, the expected output from the THP check typically marks never as the active setting in square brackets:
always madvise [never]
The scheduler command above uses /dev/sda as an example. If your data devices use different names, inspect the actual devices instead.
If your deployment guide requires DefaultTasksMax=infinity, configure it in the appropriate systemd configuration file:
DefaultTasksMax=infinity
Then apply the change using the procedure supported by your OS, for example:
systemctl daemon-reexec
systemctl show -p DefaultTasksMax
Recheck the effective value afterward.
Avoid applying settings blindly across different Linux distributions. The supported values and recommended configuration should come from the installation guide for your GBase Database version.
5. Verify Required Dependency Packages
Missing system packages can cause deployment scripts or service-management commands to fail.
For RPM-based systems, inspect the following dependencies:
rpm -q psmisc libcgroup python2
This command reports whether the packages are installed in the RPM database.
psmiscprovides utilities such askillall.libcgroupprovides cgroup-related functionality where required by the product and OS.python2provides the Python 2 runtime where required by the installer.
A missing package should be resolved before deployment, but package availability and names differ across OS versions. Confirm the dependencies specified by your GBase Database installation package.
Do not assume that a package available on one Linux release is present under the same name on another.
6. Verify the Default Python Interpreter
Python runtime compatibility is one of the most important pre-installation checks for some GBase Database(GBase 8a) releases.
An installer written for Python 2 may fail if the default python command resolves to Python 3. Having Python 2 installed is not sufficient if the installation scripts invoke a different interpreter.
Check the command resolution:
which python
python --version
Run these commands under both the root account and the intended database installation account, such as gbase.
Compare the results and confirm that the installer will use the expected interpreter.
On CentOS 8 or RHEL 8 environments, Python 2 may need to be installed separately, depending on the OS image and available repositories. Package names and supported runtime options should be verified for the target platform.
Do not change the system-wide Python configuration without checking its impact on OS utilities and other applications. If the installer supports an explicit interpreter or a documented runtime setup, follow that procedure.
Run the Environment Configuration Script
After the six checks pass, use the environment configuration procedure documented for your GBase Database release.
For versions whose installation guide specifies this command, the syntax may look like:
cd gcinstall
python SetSysEnv.py --dbaUser=gbase --installPrefix=/opt/gbase
Confirm the script location, supported arguments, Python runtime, and installation prefix before executing it.
SetSysEnv.py helps apply a consistent environment configuration. It does not replace manual verification of the Python interpreter, dependency packages, node connectivity, or system prerequisites.
Do not treat a successful script run as proof that every node is ready.
Save the Results for Every Node
The final step is to retain evidence.
Run the checks on every machine and save the output with the corresponding node inventory. For example:
mkdir -p ~/gbase-precheck
{
date
hostname
cat /etc/redhat-release
uname -r
python --version 2>&1
rpm -q psmisc libcgroup python2
df -h /opt
df -i /opt
free -h
systemctl show -p DefaultTasksMax
} > ~/gbase-precheck/precheck-$(hostname).txt 2>&1
This sample captures a useful subset of the checks. Add the port, THP, scheduler, and connectivity results required by your deployment process.
The record gives the team a baseline for troubleshooting, expansion, and future upgrades. When a new node joins the cluster, engineers can compare its environment against the existing configuration instead of repeating the investigation from scratch.
Final Thoughts
Reliable GBase Database deployment starts before the installer runs.
Check the OS, disk and inode capacity, ports, kernel settings, dependencies, and Python interpreter on every node. Validate the exact thresholds against your product version, and retain the results so the checks can be repeated later.
Ten minutes of structured verification can prevent hours of avoidable troubleshooting. More importantly, it turns pre-installation checks from an individual engineer's habit into a repeatable deployment process.
How does your team validate Linux prerequisites before deploying GBase Database(GBase 8a)? Do you run a standard pre-check script on every node, or verify the environment manually during installation?
Top comments (0)