Why GBase 8a Installs and Upgrades Take So Long on a Laptop VM — and the Fix

In a production environment, a GBase 8a cluster installation or upgrade usually completes in under 10 minutes. However, on a laptop virtual machine, the same operation can drag on for 15 to 20 minutes or more. After ruling out hardware performance differences, we traced the bottleneck to SSH connection delays caused by GSSAPIAuthentication and UseDNS settings in the SSH daemon.

Investigation

While examining the gcinstall.log file, we noticed that steps like environment checking and file distribution took disproportionately longer on the VM. A manual SSH test revealed a noticeable delay. Using ssh -v pinpointed exactly where the connection was hanging — the GSSAPI authentication phase.

[gbase@gbase_rh7_003 gcinstall]$ ssh -v 2001::103
...
debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Next authentication method: publickey

The SSH client attempted GSSAPI authentication, but since no Kerberos credentials were present, it waited for a timeout before falling back to public key authentication. In a cluster installation, where hundreds of inter‑node SSH calls are made, these waiting periods accumulate and dramatically extend the total elapsed time.

Root Cause

The default SSH server configuration typically has GSSAPIAuthentication and UseDNS enabled. GSSAPI introduces unnecessary DNS lookups and timeout retries when Kerberos is absent. UseDNS forces the server to perform a reverse DNS lookup on the client IP, adding further latency.

Solutions

Option 1: Modify the SSH server configuration (recommended)

Edit /etc/ssh/sshd_config and add or change these lines:

GSSAPIAuthentication no
UseDNS no

Then restart the SSH daemon:

systemctl restart sshd

Option 2: Bypass GSSAPI on the client side

If you cannot modify the server configuration, pass an option to ssh, scp, or the installer:

ssh -o GSSAPIAuthentication=no user@host

For GBase 8a scripts, you can also add the following to your SSH client configuration (~/.ssh/config or /etc/ssh/ssh_config):

Host *
    GSSAPIAuthentication no

Results

After disabling GSSAPI authentication, the upgrade time on the same laptop VM dropped from 27 minutes to only 6 minutes. All the extra waiting caused by authentication negotiation was eliminated. If you ever encounter similar SSH‑induced slowness in a gbase database environment — whether on VMs or even on slower physical networks — applying this fix can save you a significant amount of time during deployments and maintenance.