DEV Community: mmllllzcn

GBase Database Environment Pre-Check Script: One Command Before Installation

mmllllzcn — Fri, 04 Sep 2026 02:01:35 +0000

Before installing GBase Database(GBase 8s) on Linux, checking the server environment can save a lot of troubleshooting time.

In practice, many installation failures are not caused by the database package itself. Missing dependencies, insufficient memory, incorrect permissions, unavailable ports, and unsuitable kernel parameters can all cause problems during installation or instance creation.

This tutorial provides a simple GBase Database environment pre-check script that checks the main server requirements before you start the installation.

What Does the Script Check?

The script checks seven areas:

Operating system
CPU, memory, and disk space
Required packages
Database ports
gbasedbt user
Directory permissions
Kernel parameters

The goal is not to replace the official installation requirements. Instead, it provides a quick first-level check before installing GBase Database.

Full Pre-Check Script

Save the following as gbase_precheck.sh:

#!/bin/bash

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

PASS=0
WARN=0
FAIL=0

check() {
    local desc="$1"
    local cmd="$2"

    if eval "$cmd" >/dev/null 2>&1; then
        echo -e "${GREEN}[PASS]${NC} $desc"
        ((PASS++))
    else
        echo -e "${RED}[FAIL]${NC} $desc"
        ((FAIL++))
    fi
}

check_warn() {
    local desc="$1"
    local cmd="$2"

    if eval "$cmd" >/dev/null 2>&1; then
        echo -e "${GREEN}[PASS]${NC} $desc"
        ((PASS++))
    else
        echo -e "${YELLOW}[WARN]${NC} $desc"
        ((WARN++))
    fi
}

echo "=========================================="
echo "  GBase Database Environment Pre-Check"
echo "=========================================="

echo ""
echo "=== 1. Operating System ==="
check "CentOS or Red Hat detected" \
    "grep -Eqi 'CentOS|Red Hat' /etc/redhat-release"

check_warn "Kernel version >= 3.10" \
    "uname -r | awk -F. '{if (\$1 >= 3 && \$2 >= 10) exit 0; exit 1}'"

echo ""
echo "=== 2. Hardware Resources ==="

check_warn "Memory >= 4GB" \
    "free -g | awk '/Mem:/{if (\$2 >= 4) exit 0; exit 1}'"

check_warn "CPU >= 2 cores" \
    "test \$(nproc) -ge 2"

check_warn "Disk space >= 100GB" \
    "df -BG /opt | awk 'NR==2{gsub(\"G\",\"\"); if (\$4 >= 100) exit 0; exit 1}'"

echo ""
echo "=== 3. Dependency Packages ==="

for pkg in unzip libaio libgcc libstdc++ ncurses-devel; do
    check "$pkg installed" "rpm -q $pkg"
done

echo ""
echo "=== 4. Port Check ==="

for port in 9088 9089 19088; do
    check_warn "Port $port available" \
        "! ss -lnt | awk '{print \$4}' | grep -qE ':${port}$'"
done

echo ""
echo "=== 5. User Check ==="

check "gbasedbt user exists" "id gbasedbt"

echo ""
echo "=== 6. Directory Check ==="

check "/opt/GBASE is writable" \
    "test -d /opt/GBASE && test -w /opt/GBASE"

check_warn "/tmp space >= 10GB" \
    "df -BG /tmp | awk 'NR==2{gsub(\"G\",\"\"); if (\$4 >= 10) exit 0; exit 1}'"

echo ""
echo "=== 7. Kernel Parameters ==="

check_warn "Semaphore values meet baseline" \
    "awk '{if (\$1 >= 250 && \$2 >= 1024000 && \$3 >= 100 && \$4 >= 128) exit 0; exit 1}' /proc/sys/kernel/sem"

echo ""
echo "=========================================="
echo "  Results: PASS=$PASS  WARN=$WARN  FAIL=$FAIL"
echo "=========================================="

if [ $FAIL -gt 0 ]; then
    echo -e "${RED}$FAIL critical issue(s) found.${NC}"
    echo "Please review them before installing GBase Database."
    exit 1
elif [ $WARN -gt 0 ]; then
    echo -e "${YELLOW}$WARN warning(s) found.${NC}"
    echo "Review the warnings before installation."
    exit 0
else
    echo -e "${GREEN}All checks passed. Environment is ready.${NC}"
    exit 0
fi

How to Run It

Make the script executable:

chmod +x gbase_precheck.sh

Then run it:

sudo bash gbase_precheck.sh

A successful environment might produce output like:

==========================================
  GBase Database Environment Pre-Check
==========================================

=== 1. Operating System ===
[PASS] CentOS or Red Hat detected
[PASS] Kernel version >= 3.10

=== 2. Hardware Resources ===
[PASS] Memory >= 4GB
[PASS] CPU >= 2 cores
[PASS] Disk space >= 100GB

=== 3. Dependency Packages ===
[PASS] unzip installed
[PASS] libaio installed
[PASS] libgcc installed
[PASS] libstdc++ installed
[PASS] ncurses-devel installed

=== 4. Port Check ===
[PASS] Port 9088 available
[PASS] Port 9089 available
[PASS] Port 19088 available

==========================================
  Results: PASS=11  WARN=0  FAIL=0
==========================================

All checks passed. Environment is ready.

If a required package is missing or a critical check fails, the script returns a non-zero exit code. That makes it useful not only for manual checks but also for automated deployment workflows.

Why Run a Pre-Check?

A pre-check separates environment problems from database installation problems.

For example, if ncurses-devel is missing, fixing the package dependency first is much easier than troubleshooting an installation failure later.

The same applies to:

Insufficient memory
Insufficient disk space
Missing gbasedbt user
Port conflicts
Incorrect directory permissions
Kernel configuration issues

Running one small script before installation gives you a much clearer starting point.

Integrate It with Ansible

If you are deploying GBase Database to multiple servers, the same script can be integrated into an Ansible workflow:

- name: GBase Database Environment Pre-Check
  hosts: gbase_servers

  tasks:
    - name: Upload pre-check script
      copy:
        src: gbase_precheck.sh
        dest: /tmp/gbase_precheck.sh
        mode: '0755'

    - name: Run pre-check
      command: bash /tmp/gbase_precheck.sh
      register: result

    - name: Display results
      debug:
        var: result.stdout_lines

This allows you to validate the target servers before starting a batch GBase Database installation.

Final Thoughts

A few minutes of environment validation can prevent hours of installation troubleshooting.

The recommended workflow is:

Pre-check the server → Fix environment issues → Install GBase Database → Create the instance → Verify the database.

The script above is intended as a practical baseline rather than a replacement for version-specific GBase Database(GBase 8s) installation requirements. Always compare the checks with the requirements of the specific GBase Database release you are deploying.

For repeated deployments, combining this pre-check with Ansible can turn the manual installation process into a more consistent and repeatable workflow.

GBase Database Instance Creation: A Complete Step-by-Step Walkthrough

mmllllzcn — Fri, 04 Sep 2026 01:58:31 +0000

Installing GBase Database(GBase 8s) software is only the first step. The database becomes usable after an instance is created, configured, and started.

This guide provides a practical GBase Database instance creation walkthrough for a standalone Linux environment. It covers instance initialization, automatic configuration, instance verification, database connectivity, and a simple SQL test.

Prerequisites

Before creating a GBase Database(GBase 8s) instance, make sure:

GBase Database software is installed.
The gbasedbt operating system user is available.
The installation directory is accessible to gbasedbt.
Required system dependencies are installed.
The server has sufficient disk space and memory.

If you have followed the standard GBase Database installation process, the initialization script will handle the required environment and instance configuration.

Step 1: Plan Your Instance Parameters

Before starting instance creation, determine the basic parameters for your server:

Instance name: gbase01
IP address: 192.168.1.100
Port: 9088
Data directory: /opt/GBASE/gbase_data
Character set: zh_CN.utf8

The actual values should match your server, network, storage, and application requirements.

Planning these parameters first helps avoid configuration conflicts during initialization.

Step 2: Run the GBase Database Initialization Script

Switch to the gbasedbt user:

su - gbasedbt

Then run the initialization script:

cd $GBASEDBTDIR/etc
sh GBaseInit_gbasedbt.sh

The initialization script guides you through the GBase Database instance creation process and automatically performs the required configuration.

Depending on the installation package and selected options, the script handles items such as:

Instance name
Network address and port
Database locale
Instance configuration
SQLHOSTS configuration
Data directories
Database instance startup

This means you do not need to manually create the onconfig file, edit SQLHOSTS, configure every environment variable, or run a separate instance initialization command.

Once the initialization script completes successfully, the GBase Database instance is already started.

Step 3: Verify the Generated Configuration

After the initialization script finishes, verify that the required environment variables are available:

echo $GBASEDBTDIR
echo $GBASEDBTSERVER
echo $ONCONFIG
echo $GBASEDBTSQLHOSTS

You can also inspect the generated configuration files:

cd $GBASEDBTDIR/etc
ls -l onconfig*

Check the SQLHOSTS configuration:

cat $GBASEDBTSQLHOSTS

The instance name, network address, and port should correspond to the values selected during the initialization process.

Step 4: Verify the GBase Database Instance

Because the initialization script has already started the instance, the next step is simply to check its status.

Run:

onstat -

A successfully initialized GBase Database instance should report an online status.

You can also check whether the configured database port is listening:

netstat -tlnp | grep 9088

Replace 9088 with the port configured during instance creation.

Step 5: Test Database Connectivity

Use dbaccess to verify that the database connection works:

dbaccess sysmaster -

Run a simple SQL statement:

SELECT 1;

If the query returns 1, the GBase Database(GBase 8s) instance is accepting database connections.

Step 6: Create a Simple Test Database

Now create a small test database and table:

CREATE DATABASE test_db;

DATABASE test_db;

CREATE TABLE test_table (
    id INT,
    name VARCHAR(50)
);

INSERT INTO test_table VALUES (1, 'GBase');

SELECT * FROM test_table;

The result should look similar to:

id     name
1      GBase

This simple test confirms that the GBase Database instance can create databases and tables, insert data, and execute queries successfully.

Common Issues

Port Conflict

If the selected database port is already occupied, choose another available port during instance configuration.

You can check whether a port is in use with:

netstat -tlnp | grep 9088

Permission Errors

Make sure the gbasedbt user has the required permissions for the GBase Database installation and data directories.

For example:

chown -R gbasedbt:gbasedbt /opt/GBASE/gbase_data

Connection Problems

If dbaccess cannot connect, check:

Instance status with onstat -
Environment variables
SQLHOSTS configuration
Server IP address and port
Firewall settings

Locale Problems

If applications display unexpected characters, verify that the database and client locale settings match the requirements of your application.

Final Thoughts

Creating an instance is the step that turns GBase Database(GBase 8s) from installed software into a running database system.

With the provided initialization script, the workflow is straightforward:

Plan → Run GBaseInit_gbasedbt.sh → Verify configuration → Check instance status → Test connectivity → Create a test database.

The important point is that the initialization script does more than generate configuration files. It completes the instance setup and starts the database, so there is no need to manually run another oninit -ivy command afterward.

If you are familiar with Informix, the overall workflow will look familiar. Once you understand the instance initialization process, you can standardize it for repeatable GBase Database deployments and later automate the workflow with tools such as Ansible.

Complete Guide to GBase Database Command-Line Installation on CentOS

mmllllzcn — Fri, 04 Sep 2026 01:53:09 +0000

Installing GBase Database(GBase 8s) from the command line is a practical approach for Linux servers, SSH-based deployment, and automated database provisioning.

This guide walks through the complete GBase Database installation process on CentOS 7/8, from system preparation and package installation to automatic instance configuration and verification.

System Requirements

Before installing GBase Database(GBase 8s), prepare a CentOS server with sufficient resources:

Item	Minimum	Recommended
OS	CentOS 7+	CentOS 7.9/8.5
Memory	4 GB	64 GB
CPU	2 cores	8+ cores
Disk	100 GB	500 GB SSD
User	root / gbasedbt	gbasedbt for runtime

Step 1: Install Dependencies

Install the packages required by GBase Database:

yum install -y unzip libaio libgcc libstdc++ ncurses-devel \
    pam* jdk java-1.8.0-openjdk

Verify the key packages:

rpm -q unzip libaio libstdc++

Step 2: Create the GBase Database User

Create a dedicated gbasedbt operating system user for running the database instance:

useradd -m -d /home/gbasedbt -s /bin/bash gbasedbt
passwd gbasedbt

mkdir -p /opt/GBASE/gbase
chown -R gbasedbt:gbasedbt /opt/GBASE

For production environments, follow your organization's password and account security policies.

Step 3: Extract the Installation Package

Upload the GBase Database(GBase 8s) installation package to the server and extract it:

cd /opt
tar -xzf GBase8sV3.3_2.0_x86_64.tar.gz
ls GBase8s/

Make sure the extracted directory contains the installation program before continuing.

Step 4: Install GBase Database from the Command Line

Start the console installer:

cd /opt/GBase8s
./ids_install

For a typical installation, select:

What type of installation do you want?
  1) Typical
  2) Compact
  3) Custom

Please enter a number [1]: 1

Specify the installation directory:

Specify installation directory:

If the instance will be created separately, select the option not to create a server instance during software installation.

Step 5: Run the GBase Database Initialization Script

This is where the installation becomes much simpler.

You do not need to manually configure environment variables, create the onconfig file, configure sqlhosts, select the database port, or initialize the instance one command at a time.

Switch to the gbasedbt user:

su - gbasedbt

Then run the initialization script:

cd /opt/GBASE/gbase/etc/
sh GBaseInit_gbasedbt.sh

The script guides you through the required configuration and automatically performs the necessary setup for the GBase Database instance.

Depending on the installation package and configuration, the script handles the relevant environment, instance, network, locale, and database initialization settings.

This means the overall workflow is much simpler than manually creating and maintaining every configuration file.

Step 6: Verify the GBase Database Installation

After the initialization script completes, verify that the environment and database instance are ready.

Check the main environment variables:

echo $GBASEDBTDIR
echo $GBASEDBTSERVER
echo $ONCONFIG
echo $GBASEDBTSQLHOSTS

Then check the database instance:

onstat -

The instance should report an online status when initialization has completed successfully.

You can also test database connectivity with:

dbaccess sysmaster -

For a simple SQL test:

CREATE DATABASE test_db;

CREATE TABLE test_t (
    id INT,
    name VARCHAR(50)
);

INSERT INTO test_t VALUES (1, 'Hello GBase');

SELECT * FROM test_t;

If the database and SQL operations work correctly, the GBase Database installation is ready for use.

Installation Verification Checklist

For repeatable deployments, basic verification can also be automated:

echo "=== GBase Database Installation Verification ==="

echo -n "1. oninit exists: "
[ -f "$GBASEDBTDIR/bin/oninit" ] && echo "PASS" || echo "FAIL"

echo -n "2. Instance status: "
onstat - 2>/dev/null | grep -q "On-Line" && echo "PASS" || echo "FAIL"

echo -n "3. SQLHOSTS configuration: "
[ -f "$GBASEDBTSQLHOSTS" ] && echo "PASS" || echo "FAIL"

Final Thoughts

The command-line installation process for GBase Database(GBase 8s) is straightforward when you use the provided initialization script.

The key workflow is:

Install dependencies → Create the gbasedbt user → Install GBase Database → Run GBaseInit_gbasedbt.sh → Verify the instance.

The initialization script removes much of the manual configuration work, making the installation process easier to reproduce on remote Linux servers.

Once you are comfortable with this workflow, you can further automate GBase Database deployment with tools such as Ansible for repeatable server provisioning and environment setup.

TIL: What Does `oninit -ivy` Mean in GBase Database?

mmllllzcn — Thu, 03 Sep 2026 02:36:43 +0000

If you have installed GBase Database(GBase 8s), you have probably seen this command:

oninit -ivy

It is commonly used when initializing and starting a GBase 8s instance. But what do -i, -v, and -y actually mean?

Understanding these options makes it much easier to troubleshoot GBase Database startup problems.

What Does `oninit -ivy` Mean?

The basic command format is:

oninit [options]

The three options in oninit -ivy have different purposes:

Option	Meaning	Purpose
`-i`	Initialize	Initializes the database server and creates the initial database storage structures when required
`-v`	Verbose	Displays more detailed information during startup
`-y`	Yes	Automatically answers yes to prompts

So:

oninit -ivy

essentially means initialize, show verbose output, and automatically confirm prompts.

When Should You Use `-i`?

The -i option is associated with initializing the database server. It should not be treated as a normal option for every restart.

For example, during initial instance setup:

oninit -ivy

After the instance has already been initialized, routine startup normally does not require -i.

For example:

oninit -vy

The exact startup procedure can depend on how your GBase Database environment was created and configured, so avoid repeatedly using initialization options on an existing production instance unless the procedure specifically requires it.

What Does `-v` Do?

-v enables verbose startup output.

This is particularly useful when troubleshooting GBase Database startup failures, because you can get more information about where the startup process is stopping.

For troubleshooting:

oninit -v

You can also combine it with other options:

oninit -vy

When diagnosing a problem, verbose output is often more useful than simply checking whether the command returned successfully.

What Does `-y` Do?

-y automatically answers yes to prompts that would otherwise require interactive confirmation.

This makes it useful for scripted or automated startup procedures:

oninit -ivy

However, -y should be used carefully. Automatically confirming a destructive or initialization-related operation is not something you want to do blindly on an existing production instance.

Routine Stop and Restart

A common workflow is to stop the instance and then start it again.

For example:

onmode -ky
oninit -vy

The important distinction is that onmode -ky stops the database server, while oninit starts it again. The -i option is not normally part of a routine restart.

Always verify the instance state after startup:

onstat -

Checking Startup Logs

If GBase Database does not start as expected, check the server messages and online log.

For example:

tail -f $GBASEDBTDIR/tmp/online.log

You can also use:

onstat -m

Depending on the failure, you may see messages related to configuration, shared memory, storage, permissions, or network connectivity.

Typical problems include:

Cannot find onconfig file
Cannot bind to port
Not enough shared memory
Permission denied

The exact error message is usually more useful than the fact that oninit simply failed.

A Simple GBase Database Startup Checklist

When troubleshooting a GBase 8s startup failure, check these items in order:

1. Check the Environment

echo $GBASEDBTDIR
echo $GBASEDBTSERVER
echo $ONCONFIG
echo $GBASEDBTSQLHOSTS

Make sure the variables point to the correct installation, instance, configuration, and sqlhosts files.

2. Check the Configuration

ls $GBASEDBTDIR/etc/$ONCONFIG

If the file cannot be found, fix the environment or configuration path before trying to start the instance again.

3. Check the Instance Status

onstat -

This tells you whether the GBase Database server is online and provides basic instance information.

4. Check the Server Messages

onstat -m

For more detailed information, inspect the online log:

tail -50 $GBASEDBTDIR/tmp/online.log

Don't Treat `oninit -ivy` as a Magic Command

One common mistake is to memorize:

oninit -ivy

without understanding what it does.

The important part is knowing when initialization is appropriate and when a normal startup is enough.

A useful mental model is:

-i → initialization
-v → verbose startup information
-y → automatically answer yes

For routine operations, avoid adding initialization options simply because they were used during the first setup.

Key Takeaway

oninit -ivy is a familiar command for GBase Database(GBase 8s) administrators, but each option has a specific purpose.

Understanding -i, -v, and -y helps you choose the right startup command and makes troubleshooting much easier.

When GBase Database fails to start, don't immediately rerun oninit -ivy. First check the environment variables, onconfig, instance status, server messages, and online log.

That small habit can turn a frustrating GBase 8s startup failure into a much faster diagnosis.

TIL: GBase Database Silent Installation with bundle.properties

mmllllzcn — Thu, 03 Sep 2026 02:34:20 +0000

When deploying GBase Database(GBase 8s) across multiple servers, silent installation can save a lot of repetitive manual work. Instead of answering installation prompts on every machine, you can define the installation settings in a bundle.properties file and reuse the same template.

Here is a practical GBase Database silent installation guide covering the command, commonly used parameters, batch deployment, and post-installation checks.

Silent Installation Command

After preparing your bundle.properties file, run:

sh ids_install -i silent -f bundle.properties

For automated deployments, keep the properties file together with the installation package and validate it before starting the installation.

Core bundle.properties Parameters

A basic configuration may look like this:

USER_INSTALL_DIR=/opt/GBASE/gbase
CHOSEN_INSTALL_SET=TYPICAL
CHOSEN_INSTALL_FEATURE=2

INSTANCE_NAME=gbase01
SERVER_NUM=1
PORT_NUM=9088

DB_LOCALE=zh_CN.utf8
CLIENT_LOCALE=zh_CN.utf8

The exact available parameters can vary by GBase Database(GBase 8s) version and installation package, so treat the vendor-provided bundle.properties template or installation documentation as the authoritative reference.

Installation Configuration

Common installation-related settings include:

USER_INSTALL_DIR=/opt/GBASE/gbase
USER_INSTALL_LANGUAGE=zh
USER_ACCEPT_LICENSE=YES

USER_INSTALL_DIR defines the target installation directory.

Before deployment, make sure the parent filesystem has enough capacity and that the installation user has the required permissions.

Instance Configuration

Instance-related settings may include:

INSTANCE_NAME=gbase01
PORT_NUM=9088

DB_LOCALE=zh_CN.utf8
CLIENT_LOCALE=zh_CN.utf8

If your installation package supports parameters for data and log locations, configure them according to the specific version and deployment architecture.

For example:

DATALOCALE=/opt/GBASE/gbase_data
LOGDIR=/opt/GBASE/gbase_logs

Do not assume that every parameter is supported by every GBase 8s installer version. Validate the parameter names against the bundle.properties generated or supplied for your release.

Advanced Installation Options

Some installation packages also provide additional options for logging or optional components, for example:

CONSOLE_LOG_LEVEL=2
INSTALL_DEV_LIB=NO
INSTALL_JDBC=YES

These options should also be checked against the installer version before being included in a reusable deployment template.

Batch Deployment Example

Once the silent installation has been tested on one server, the same package and configuration can be deployed to multiple machines.

Using SSH keys is preferable to putting passwords directly into a deployment script:

#!/bin/bash

SERVERS=("192.168.1.101" "192.168.1.102" "192.168.1.103")
REMOTE_USER="gbase"

for server in "${SERVERS[@]}"; do
    echo "=== Deploying GBase Database to $server ==="

    scp gbase8s.tar.gz bundle.properties \
        "${REMOTE_USER}@${server}:/opt/"

    ssh "${REMOTE_USER}@${server}" << 'EOF'
cd /opt
tar -xzf gbase8s.tar.gz
cd gbase8s

sh ids_install -i silent -f /opt/bundle.properties
EOF

    if [ $? -eq 0 ]; then
        echo "=== $server installation completed ==="
    else
        echo "=== $server installation failed ==="
    fi
done

For production automation, add pre-checks for disk space, memory, required packages, ports, users, permissions, and existing GBase Database instances before starting the installation.

Verify the Installation

After the silent installation finishes, verify that the main executable exists:

ls /opt/GBASE/gbase/bin/oninit

Then check the instance status:

onstat -

You should also verify the environment variables and configuration files used by the instance:

echo $GBASEDBTDIR
echo $GBASEDBTSERVER
echo $ONCONFIG
echo $GBASEDBTSQLHOSTS

A successful installer exit code does not necessarily mean the database instance is ready for production. Always perform a basic startup and connectivity test.

Why Silent Installation Matters

For a single GBase Database installation, console mode is usually sufficient. For tens or hundreds of servers, however, manually answering installation prompts becomes slow and error-prone.

A standardized bundle.properties template provides several advantages:

Repeatable installations
Consistent directory and instance configuration
Easier batch deployment
Reduced manual input
Better integration with automation and CI/CD workflows

Silent installation can also be useful when building standardized VM or container images, provided that the licensing, initialization, networking, and runtime requirements of the target GBase 8s environment are handled separately.

Key Takeaway

The bundle.properties file is one of the most useful pieces of an automated GBase Database(GBase 8s) deployment workflow.

But don't treat it as a universal configuration file. Parameter names and supported options can vary between GBase 8s releases. Build your template from the installation package for the specific version you are deploying, test it on a clean server, and only then reuse it for batch deployment.

One tested silent-install template can eliminate dozens of repetitive installation steps—and make GBase Database deployment much more predictable.

TIL: Insufficient /tmp Space Causes GBase Database Installation Failure

mmllllzcn — Thu, 03 Sep 2026 02:31:40 +0000

Today I ran into a common but easy-to-miss GBase Database(GBase 8s) installation problem. The installer stopped with No space left on device, even though the target disk still had tens of gigabytes available. The real bottleneck was not /opt or the main disk—it was the /tmp filesystem used during installation.

The Symptoms

During a GBase Database installation:

./ids_install

the installer suddenly terminated with an error similar to:

ERROR: Failed to extract files. Disk may be full.

I checked the main installation filesystem:

df -h /opt

and found plenty of free space.

The confusing part was that the GBase 8s installation still reported that the disk was full.

The Root Cause: Check /tmp

The GBase Database(GBase 8s) installer may use /tmp for temporary extraction and installation files. Therefore, having enough free space on the target installation directory does not necessarily mean that the installer has enough temporary storage.

The first checks should be:

df -h /tmp
du -sh /tmp/ids_install* 2>/dev/null

Also check the filesystem behind /tmp:

df -h /tmp
df -i /tmp

The second command is important because No space left on device can also occur when a filesystem runs out of inodes, even when df -h still shows available capacity.

Solution 1: Clean Up Temporary Files

If /tmp is genuinely full, identify large files first:

du -sh /tmp/* 2>/dev/null | sort -rh | head -20

Remove only files that you have verified are safe to delete.

For example:

find /tmp -name "ids_install*" -mtime +1 -delete

Avoid blindly deleting everything under /tmp, especially on a production server where other applications may be using temporary files.

Solution 2: Provide a Larger Temporary Directory

For a GBase Database installation that requires more temporary space, using a dedicated filesystem or directory can be a cleaner approach.

For example:

mkdir -p /opt/tmp
chmod 1777 /opt/tmp

export TMPDIR=/opt/tmp

./ids_install -i console

Before starting the installation, verify that the new location has sufficient capacity:

df -h /opt/tmp
echo $TMPDIR

Using a dedicated temporary directory also makes it easier to monitor installation-related files during troubleshooting.

Solution 3: Increase the Available Space for /tmp

If /tmp is backed by a small filesystem or tmpfs, increasing its capacity may be appropriate depending on your server configuration.

First inspect the current setup:

df -h /tmp
mount | grep ' /tmp '

Then resize or reconfigure /tmp according to your operating system and deployment standards.

I would not recommend blindly running a new mount -t tmpfs ... /tmp on a production system. Changing the /tmp mount can affect existing processes and may require additional configuration to survive a reboot.

Pre-Installation Check for GBase Database

A simple pre-check can catch many installation problems before running the GBase 8s installer:

#!/bin/bash

echo "=== Disk Space Check ==="
echo "/tmp: $(df -h /tmp | tail -1 | awk '{print $4}') available"
echo "/opt: $(df -h /opt | tail -1 | awk '{print $4}') available"
echo "HOME: $(df -h ~ | tail -1 | awk '{print $4}') available"

echo ""
echo "=== Inode Check ==="
df -i /tmp

echo ""
echo "=== Memory Check ==="
free -h

echo ""
echo "=== Dependency Package Check ==="
for pkg in unzip libaio libgcc libstdc++ ncurses-devel; do
    rpm -q "$pkg" &>/dev/null \
        && echo "[OK] $pkg" \
        || echo "[MISSING] $pkg"
done

Why This Matters in Batch Deployments

This problem becomes more noticeable when deploying GBase Database(GBase 8s) across multiple servers.

A machine may have plenty of capacity on /opt, while /tmp has a much smaller limit. During simultaneous installations, temporary extraction files can consume that space quickly.

A successful GBase Database installation therefore requires more than checking the final installation directory. You should verify temporary storage, filesystem capacity, inode availability, memory, and required packages before starting the installer.

Key Takeaway

When GBase Database(GBase 8s) installation fails with:

No space left on device

don't look only at the target installation directory.

Check these first:

/tmp available space
/tmp inode usage
TMPDIR configuration
Temporary installation files
Required system packages
Available memory

The lesson: sufficient disk space for GBase Database does not always mean sufficient temporary space for the GBase 8s installer.

TIL: Fixing “Cannot Find onconfig File” in GBase Database

mmllllzcn — Thu, 03 Sep 2026 02:18:38 +0000

Today I helped troubleshoot a GBase Database(GBase 8s) instance that failed to start. The error looked like a missing configuration file, but the real problem was incorrect environment variables. If oninit -ivy appears to do nothing and the log reports Cannot find onconfig file, checking your environment variables should be one of the first steps.

The Symptoms

After running:

oninit -ivy

there was no visible output, and the GBase Database instance did not start.

Checking the online log showed:

GBASERMT Cannot find onconfig file

At first, this looks like an onconfig file problem. However, the file was actually present. The issue was that GBase Database could not locate it through the configured environment.

The Root Cause

GBase Database(GBase 8s) uses several environment variables to locate its installation directory, instance configuration, and connectivity files.

A typical environment looks like this:

export GBASEDBTDIR=/opt/GBASE/gbase
export GBASEDBTSERVER=gbase01
export ONCONFIG=onconfig.gbase01
export GBASEDBTSQLHOSTS=$GBASEDBTDIR/etc/sqlhosts.gbase01
export DB_LOCALE=zh_CN.utf8
export CLIENT_LOCALE=zh_CN.utf8
export GL_USEGLU=1

After modifying the environment, reload it:

source ~/.bash_profile

Then verify the critical variables:

echo $GBASEDBTDIR
echo $GBASEDBTSERVER
echo $ONCONFIG
echo $GBASEDBTSQLHOSTS

Common GBase Database Configuration Mistakes

1. GBASEDBTDIR Points to the Wrong Directory

A common mistake is accidentally adding an extra directory level:

export GBASEDBTDIR=/opt/GBASE/gbase/gbase

when the actual installation directory is:

export GBASEDBTDIR=/opt/GBASE/gbase

Check whether the GBase Database executable exists:

ls $GBASEDBTDIR/bin/oninit

If oninit cannot be found, fix GBASEDBTDIR first.

2. ONCONFIG Does Not Match the Configuration File

Check the available configuration files:

ls $GBASEDBTDIR/etc/onconfig.*

Then make sure ONCONFIG matches the actual filename:

export ONCONFIG=onconfig.gbase01

The filename and the ONCONFIG value must correspond.

3. GBASEDBTSQLHOSTS Points to a Missing File

Check the configured sqlhosts path:

echo $GBASEDBTSQLHOSTS
cat $GBASEDBTSQLHOSTS

If the file does not exist, verify the intended location and create or restore the correct sqlhosts configuration.

For example:

cat > $GBASEDBTSQLHOSTS <<EOF
gbase01 onsoctcp 192.168.1.100 9088
EOF

Use the actual hostname, protocol, IP address, and port for your environment rather than copying these values directly.

Quick Diagnostic Script

When troubleshooting a GBase Database startup problem, this simple script can quickly identify missing variables and files:

#!/bin/bash

echo "=== Environment Variable Check ==="
echo "GBASEDBTDIR: ${GBASEDBTDIR:-[NOT SET]}"
echo "GBASEDBTSERVER: ${GBASEDBTSERVER:-[NOT SET]}"
echo "ONCONFIG: ${ONCONFIG:-[NOT SET]}"
echo "GBASEDBTSQLHOSTS: ${GBASEDBTSQLHOSTS:-[NOT SET]}"

echo ""
echo "=== Critical File Check ==="
[ -f "$GBASEDBTDIR/bin/oninit" ] \
  && echo "[OK] oninit exists" \
  || echo "[ERROR] oninit missing"

[ -f "$GBASEDBTDIR/etc/$ONCONFIG" ] \
  && echo "[OK] onconfig exists" \
  || echo "[ERROR] onconfig missing"

[ -f "$GBASEDBTSQLHOSTS" ] \
  && echo "[OK] sqlhosts exists" \
  || echo "[ERROR] sqlhosts missing"

The Key Lesson

When GBase Database fails to start with an onconfig-related error, do not immediately assume that the configuration file is corrupted or missing.

Check these first:

Is GBASEDBTDIR correct?
Does $GBASEDBTDIR/bin/oninit exist?
Does ONCONFIG match the actual configuration filename?
Does $GBASEDBTSQLHOSTS point to the correct file?
Have you reloaded the environment after making changes?

If you have worked with Informix-style database administration before, these environment variables will look familiar. For repeatable deployments, putting them into a dedicated environment script can also reduce startup and configuration errors.

Bottom line: many GBase Database startup failures are not caused by the database engine itself. Sometimes, the problem is simply that the instance does not know where to find its own configuration.

TIL: Four Key Configurations Inside the GBase Database `onconfig` File

mmllllzcn — Wed, 02 Sep 2026 05:31:50 +0000

Many people install GBase Database(GBase 8s), start the instance, and never open the onconfig file again.

I took a closer look at it recently and found four configuration areas that are especially important for database performance, memory management, and logging.

If you're learning GBase Database administration, understanding these parameters is a good place to start.

What Is `onconfig`?

onconfig is the core configuration file for a GBase Database(GBase 8s) instance.

It contains instance-level parameters that control areas such as memory, buffer pools, logical logging, connections, and other database behavior.

The typical naming convention is:

onconfig.<instance_name>

You can locate the configuration files with:

ls $GBASEDBTDIR/etc/onconfig.*

Four Parameters Worth Checking

1. BUFFERPOOL — Database Buffer Pool

BUFFERPOOL controls how data pages are cached in shared memory.

A larger buffer pool can reduce disk I/O for workloads that repeatedly access the same data, but it also consumes more memory.

The important point is that buffer pool configuration should be based on the workload and available system memory rather than a universal fixed value.

For environments using different dbspace page sizes, buffer pool configuration also needs to account for those page sizes.

2. LOGSIZE — Logical Log Size

LOGSIZE specifies the size of each logical log file.

Logical logs are important for transaction processing and recovery, so the appropriate size depends on workload characteristics, especially transaction volume and logging activity.

One important detail: changing LOGSIZE affects newly created logical log files. Existing logical log files do not automatically change size.

This means LOGSIZE should be considered together with LOGFILES, rather than tuned in isolation.

3. LOGFILES — Number of Logical Log Files

LOGFILES specifies the number of logical log files.

Together, LOGSIZE and LOGFILES determine the amount of logical log space available to the database.

For a write-intensive OLTP workload, insufficient logical log capacity can become a problem as transaction volume increases.

When reviewing GBase Database logging configuration, look at these parameters together with actual log usage and transaction behavior instead of applying a generic "larger is always better" rule.

4. SHMTOTAL — Total Shared Memory

SHMTOTAL specifies the total amount of shared memory that the database server can use.

This parameter is particularly important when planning memory usage on a production server shared with other applications.

A value of 0 can indicate that no specific shared-memory limit is imposed, depending on the database configuration.

Setting a fixed limit requires careful planning. If the database needs more memory than the configured limit allows, some operations can fail.

For that reason, SHMTOTAL should be considered together with the other memory-related configuration parameters and the physical memory available on the server.

How to View the Configuration

You can inspect the active GBase Database configuration with:

onstat -g config

To find a specific parameter:

onstat -g config | grep BUFFERPOOL

You can also inspect the relevant onconfig file directly:

cat $GBASEDBTDIR/etc/onconfig.<instance_name>

Checking the active configuration is especially useful during troubleshooting because the configuration file and the currently running instance should be considered separately.

How Should You Modify `onconfig`?

Not every onconfig parameter can be changed in the same way.

Some parameters support dynamic changes, while others require modifying the configuration file and restarting the database instance.

For parameters that support dynamic modification, GBase 8s provides administrative commands such as:

onmode -wf parameter=value

For parameters that require a restart, modify the appropriate onconfig file and restart the instance according to your operational procedure.

Always verify the parameter's dynamic configuration support before changing it. The exact behavior can depend on the parameter and GBase 8s version.

A Better GBase Database Tuning Approach

There is no universal onconfig template that works for every GBase Database(GBase 8s) deployment.

A better approach is:

Understand the workload.
Check available system resources.
Review the current configuration.
Identify the actual bottleneck.
Change one important parameter at a time.
Monitor the result.
Document the change.

For OLTP systems, pay particular attention to buffer pool usage, logical log activity, transaction volume, and memory consumption.

For other workloads, the important parameters and tuning priorities may be different.

The Takeaway

The GBase Database(GBase 8s) onconfig file is the control center of the database instance.

You don't need to memorize every parameter. But after installation, it is worth understanding the settings that directly affect your workload.

Start with these four:

BUFFERPOOL — data page caching
LOGSIZE — logical log file size
LOGFILES — number of logical log files
SHMTOTAL — total shared memory

Understanding these parameters can make GBase Database troubleshooting much easier—and help you make configuration changes based on actual workload behavior rather than guesswork.

TIL: Check Port 9088 Before Installing GBase Database

mmllllzcn — Wed, 02 Sep 2026 05:23:42 +0000

Last week, I helped a team troubleshoot a GBase Database(GBase 8s) installation failure. The logs repeatedly reported:

Cannot bind to port 9088

The reason was simple: port 9088 was already being used by another process.

It was a good reminder that checking the database port before installing GBase Database can save a lot of unnecessary troubleshooting.

Why Port 9088 Matters

In this GBase Database(GBase 8s) deployment, 9088 is the database service listening port.

During installation and instance initialization, GBase 8s needs to bind the configured port. If another process is already listening on that port, the database instance cannot bind to it and may fail to start.

Before installation, check whether 9088 is available.

One-Command Port Check

On Linux, use ss to check the port:

ss -ltnp | grep ":9088 "

If the command returns something like:

LISTEN 0 128 0.0.0.0:9088 0.0.0.0:* users:(("nginx",pid=1234))

port 9088 is already occupied.

If there is no output, the port is likely available.

On systems where ss is not available, you can use:

netstat -tlnp | grep 9088

What to Do If 9088 Is Occupied

First, identify which process is using the port:

ss -ltnp | grep ":9088 "

Do not immediately run kill -9. First determine whether the process is required by the system or another application.

If it is an unnecessary service, stop it using the appropriate service manager:

systemctl stop <service>

Then verify that port 9088 has been released:

ss -ltnp | grep ":9088 "

If another application must continue using 9088, you can configure GBase Database(GBase 8s) to use another available port.

Keep the Port Configuration Consistent

If you change the GBase Database port, make sure the server configuration and client connection configuration use the same port.

For example, if the database service is changed to 9098, the corresponding sqlhosts entry should use 9098:

gbase01 onsoctcp 192.168.1.100 9098

If the server listens on 9098 but the client still tries to connect to 9088, the connection will fail.

This is a common point to check when troubleshooting GBase Database connectivity.

Check the Firewall Too

A free port does not automatically mean that clients can reach it.

If remote clients need to connect to GBase Database through TCP port 9088, check the server firewall:

firewall-cmd --list-ports

If your security policy allows it, add the required port:

firewall-cmd --add-port=9088/tcp --permanent
firewall-cmd --reload

There is usually no need to disable the entire firewall just to make the database accessible. Opening only the required port is a better approach.

A Simple Pre-Installation Checklist

Before installing GBase Database(GBase 8s), check:

Is port 9088 already in use?
Which process owns the port?
Is the port configured consistently in the database and sqlhosts?
Can remote clients reach the port through the firewall?

The Takeaway

A GBase Database installation problem does not always come from the database itself. Sometimes, a single occupied port is enough to stop the instance from starting.

Before installing GBase Database(GBase 8s), spend a few seconds checking port 9088. It can save you hours of troubleshooting later.

TIL: The Wrong Character Set in GBase Database Can Turn Chinese Into `????`

mmllllzcn — Wed, 02 Sep 2026 05:17:56 +0000

I recently troubleshot a GBase Database(GBase 8s) character set issue: the database was running normally and connections worked, but Chinese data appeared as ???? after insertion. The root cause was simple—the wrong character set had been selected during installation.

This is an easy mistake to make when setting up GBase Database for the first time.

Reproducing the Problem

During the GBase Database(GBase 8s) installation, I accepted the default settings, leaving the locale as:

en_US.8859-1

The database itself worked normally. But after creating a table and inserting Chinese text:

CREATE TABLE test_cn (
    id INT,
    name VARCHAR(100)
);

INSERT INTO test_cn VALUES (1, '测试数据');

SELECT * FROM test_cn;

The result was:

id  name
1   ????

The database was Online. The SQL was valid. The problem was the character set configuration.

Why `en_US.8859-1` Causes Problems

en_US.8859-1 uses ISO 8859-1, which is designed primarily for Western European characters. It does not provide the character coverage required for Chinese text.

In GBase Database(GBase 8s), locale settings affect how character data is handled between the database, client, and application.

Two important environment variables are:

Variable	Purpose	Example
`DB_LOCALE`	Database locale and character set	`zh_CN.utf8`
`CLIENT_LOCALE`	Client-side locale and character set	`zh_CN.utf8`

For a Chinese UTF-8 environment, keeping these settings consistent helps avoid unexpected character conversion problems.

How to Configure the Character Set

Method 1: Set It During Installation

This is the simplest approach.

During the GBase Database(GBase 8s) installation and instance initialization process, select the appropriate locale instead of accepting the default:

zh_CN.utf8

Choosing the correct locale from the beginning is much easier than dealing with character conversion problems after production data has been loaded.

Method 2: Check the GBase Database Environment

If the instance has already been installed, check the GBase Database environment profile.

For example:

vi /home/gbasedbt/profile.gbase01

Look for the locale-related environment variables:

export DB_LOCALE=zh_CN.utf8
export CLIENT_LOCALE=zh_CN.utf8

The exact values should match your application's character set requirements.

After changing the environment variables, reload the profile before testing:

source /home/gbasedbt/profile.gbase01

Then verify the active values:

echo $DB_LOCALE
echo $CLIENT_LOCALE

You can also check the GBase Database environment with:

onstat -g env | grep LOCALE

The important point is to check the environment profile, rather than looking for these variables in the onconfig file.

UTF-8 or GBK?

GBase Database(GBase 8s) supports multiple character sets, so the right choice depends on your application and existing data.

For new applications that need multilingual support, UTF-8 is generally the safer choice because it provides broad character coverage and works well across modern applications and systems.

GBK can still make sense for legacy Chinese-only environments where existing applications and data already depend on it.

The key is consistency across the database, client, application, and data.

The Takeaway

A GBase Database instance can be completely healthy while Chinese text is still displayed as ????.

When troubleshooting character encoding in GBase Database(GBase 8s), check:

DB_LOCALE
CLIENT_LOCALE
The database locale
Application/client encoding
Existing data encoding

Don't blindly accept the default locale during installation. If your GBase Database environment needs Chinese or multilingual data, make the character set decision before loading production data. A small configuration choice at installation time can prevent a much bigger migration problem later.

TIL: Why `localhost` Can Break Your GBase Database sqlhosts Configuration

mmllllzcn — Wed, 02 Sep 2026 03:57:22 +0000

I was helping a colleague troubleshoot a GBase Database(GBase 8s) connection failure today and found a common configuration pitfall: using localhost in the sqlhosts file.

If your GBase Database instance is already On-Line but dbaccess still returns Can't connect to database server (25574), the sqlhosts configuration is one of the first things to check.

The Problem

After configuring GBase Database(GBase 8s), the instance looks healthy:

onstat -

But connecting with dbaccess fails:

Can't connect to database server (25574)

One possible cause is an incorrect server address in sqlhosts:

gbase01 onsoctcp localhost 9088

It looks harmless, especially when the database server and client are on the same machine. But localhost can introduce protocol and address-resolution problems that are easy to overlook.

Why `localhost` Can Cause Problems

The sqlhosts file tells GBase Database(GBase 8s) how clients should communicate with a database server.

For TCP/IP connections, onsoctcp should point to a valid network address or hostname. Using localhost forces the connection toward the local loopback interface rather than the server's normal network address.

This becomes especially problematic when:

The client connects remotely
The server is bound to a specific network interface
/etc/hosts resolves the hostname unexpectedly
Firewall or network rules restrict loopback traffic

In other words, the database can be On-Line while the client still cannot reach it.

Recommended sqlhosts Configuration

Instead of localhost, use the server's actual IP address:

gbase01 onsoctcp 192.168.1.100 9088

Or use a hostname that resolves correctly:

gbase01 onsoctcp gbase-server-01 9088

Then verify the hostname:

getent hosts gbase-server-01

This simple check can save a lot of troubleshooting time when configuring GBase Database.

How to Troubleshoot GBase Database Connections

First, check the active environment configuration:

onstat -g env | grep sqlhosts

Then verify whether the database port is listening:

netstat -tlnp | grep 9088

If you see:

127.0.0.1:9088

the service is listening only on the loopback interface. A remote client will not be able to connect through that address.

If the port is listening on the server's network interface, continue checking firewall rules, hostname resolution, the sqlhosts entry, and the client connection parameters.

GBase Database sqlhosts: A Simple Rule

For GBase Database(GBase 8s) deployments, sqlhosts deserves attention during initial configuration and troubleshooting.

A practical rule is:

Use onsoctcp with a reachable IP address or correctly resolved hostname instead of relying on localhost.

A database being On-Line does not automatically mean that every client connection path is correctly configured.

If you're learning GBase Database(GBase 8s) administration, understanding sqlhosts, network protocols, ports, and hostname resolution is a good place to start.

Rollback Plan Template: Make Database Cutover Safe

mmllllzcn — Fri, 28 Aug 2026 01:40:10 +0000

A database migration without a tested rollback plan is a risk waiting to surface.

Before moving production traffic to GBase Database or any other target, define the exit strategy in advance.

1. Define Rollback Triggers

Use measurable conditions, not opinions:

Dual-write data difference > 0 for N minutes
P95 latency exceeds baseline by 10% for M minutes
Error rate exceeds the predefined threshold
Replication or data consistency checks fail

2. Define Rollback Steps

A practical rollback plan should include:

Freeze writes on the new system
Route application traffic back to the source
Verify reverse synchronization
Confirm transaction completeness
Resume normal traffic only after validation

3. Assign Ownership & Timing

Every rollback step needs:

A named owner
A defined time budget
A clear success condition

The complete database migration rollback process must fit inside the maintenance window.

4. Rehearse Before Go-Live

A rollback plan that has never been tested is only documentation.

Run a full drill before the GBase Database cutover. Record the actual recovery time and fix any step that exceeds the target.

Rule: If the rollback drill exceeds the maintenance window, change the plan—not the clock.

💬 Does your database migration checklist include a timed rollback rehearsal?

DEV Community: mmllllzcn

GBase Database Environment Pre-Check Script: One Command Before Installation

What Does the Script Check?

Full Pre-Check Script

How to Run It

Why Run a Pre-Check?

Integrate It with Ansible

Final Thoughts

GBase Database Instance Creation: A Complete Step-by-Step Walkthrough

Prerequisites

Step 1: Plan Your Instance Parameters

Step 2: Run the GBase Database Initialization Script

Step 3: Verify the Generated Configuration

Step 4: Verify the GBase Database Instance

Step 5: Test Database Connectivity

Step 6: Create a Simple Test Database

Common Issues

Port Conflict

Permission Errors

Connection Problems

Locale Problems

Final Thoughts

Complete Guide to GBase Database Command-Line Installation on CentOS

System Requirements

Step 1: Install Dependencies

Step 2: Create the GBase Database User

Step 3: Extract the Installation Package

Step 4: Install GBase Database from the Command Line

Step 5: Run the GBase Database Initialization Script

Step 6: Verify the GBase Database Installation

Installation Verification Checklist

Final Thoughts

TIL: What Does `oninit -ivy` Mean in GBase Database?

What Does oninit -ivy Mean?

When Should You Use -i?

What Does -v Do?

What Does -y Do?

Routine Stop and Restart

Checking Startup Logs

A Simple GBase Database Startup Checklist

1. Check the Environment

2. Check the Configuration

3. Check the Instance Status

4. Check the Server Messages

Don't Treat oninit -ivy as a Magic Command

Key Takeaway

TIL: GBase Database Silent Installation with bundle.properties

Silent Installation Command

Core bundle.properties Parameters

Installation Configuration

Instance Configuration

Advanced Installation Options

Batch Deployment Example

Verify the Installation

Why Silent Installation Matters

Key Takeaway

TIL: Insufficient /tmp Space Causes GBase Database Installation Failure

The Symptoms

The Root Cause: Check /tmp

Solution 1: Clean Up Temporary Files

Solution 2: Provide a Larger Temporary Directory

Solution 3: Increase the Available Space for /tmp

Pre-Installation Check for GBase Database

Why This Matters in Batch Deployments

Key Takeaway

TIL: Fixing “Cannot Find onconfig File” in GBase Database

The Symptoms

The Root Cause

Common GBase Database Configuration Mistakes

1. GBASEDBTDIR Points to the Wrong Directory

2. ONCONFIG Does Not Match the Configuration File

3. GBASEDBTSQLHOSTS Points to a Missing File

Quick Diagnostic Script

The Key Lesson

TIL: Four Key Configurations Inside the GBase Database `onconfig` File

What Is onconfig?

Four Parameters Worth Checking

1. BUFFERPOOL — Database Buffer Pool

2. LOGSIZE — Logical Log Size

3. LOGFILES — Number of Logical Log Files

What Does `oninit -ivy` Mean?

When Should You Use `-i`?

What Does `-v` Do?

What Does `-y` Do?

Don't Treat `oninit -ivy` as a Magic Command

What Is `onconfig`?

How Should You Modify `onconfig`?

Why `en_US.8859-1` Causes Problems

Why `localhost` Can Cause Problems