From: "Eric Hague" Subject: IB 6.0.2 super server (binaries) install on RH Linux 7.3 Date: 18 October 2002 18:58 I just finished an InterBase 6.0.2 super server install (from the binaries) on a Red Hat Linux 7.3 server (2.4 kernel). I had some problems along the way, but found solutions. I'm posting my notes here in case it helps somebody else. Note that I'm no expert at either Linux or InterBase, so if you see something I should have done differently feel free to say so. I've included the references I uncovered, so you'll know the reason I did what I did. 1) Download InterBaseSS_LI-V6.0.2.tar (Linux Super Server binaries) from http://mers.com Make a temporary directory (/tmp/install) and put the tar file there. 2) As root user, from within /tmp/install tar -xvf InterBaseSS_LI-V6.0.2.tar 3) Run the install script: ./install -s /tmp/install/InterBaseSS_LI-V6.0.2.tgz This creates the /opt/interbase directory structure. 4) Create a symbolic link to libncurses.so.5.2 named libncurses.so.4 cd /usr/lib ln -s libncurses.so.5.2 libncurses.so.4 This avoids "Can't load library libncurses.so.4" when you start up. The InterBase binaries are expecting an older version of the library. See http://community.borland.com/article/0,1410,28370,00.html 5) Obtain a copy of /usr/lib/libgds.so.1 and redirect /usr/lib/libgds.so (symbolic link) to it instead of libgds.so.0 (which seems to be for the Classic Server instead of the Super Server ??). For details, see http://groups.google.com/groups?selm=3d901414%40newsgroups.borland.com If you don't do this step, you'll get an error when you try to run a command locally from /opt/interbase/bin (like gsec or isql): lock manager error: inconsistent lock table version number; found 114, expected 14 Thanks to Bojidar Alexandrov for covering this (and for libgds.so.1)! cp libgds.so.1 /usr/lib cd /usr/lib chmod a+rwx libgds.so.1 rm libgds.so (incorrectly points to libgds.so.0) ln -s libgds.so.1 libgds.so 6) Edit the /etc/hosts.equiv created by the InterBase install. Change "localhost" to "localhost.localdomain". Without this I got: SERVER/process_packet: connection rejected for root in the interbase.log, and the server failed to start. See: http://community.borland.com/article/0,1410,25343,00.html It was actually the man page (referenced in the above article) that had the key. It suggested that fully-qualified host names are better for security reasons. When I changed that, the problem disappeared. 7) Optionally, create a Linux group called interbase and a user interbase. Make the user a member of the group (start InterBase using this user). 8) I use the following script to start/stop/restart the server: #!/bin/bash # Script to start/stop/restart the InterBase daemon # This script was written for Linux 7.3 case "$1" in start) echo "Starting InterBase (ibserver/ibguard)..." /opt/interbase/bin/ibmgr -start -forever ;; stop) echo "Stopping InterBase (ibserver/ibguard)..." /opt/interbase/bin/ibmgr -shut -password masterkey ;; restart) $0 stop $0 start ;; *) echo "Usage: $0 { start | stop | restart }" exit 1 esac exit 0 9) Start the Interbase daemon as user "interbase". (scriptname) start 10) Verify that the server is running. ps -ae | grep ib netstat -a | grep gds_db 11) Verify functionality of local tools. isql SQL> CONNECT '/opt/interbase/examples/employee.gdb'; SQL> show tables; SQL> quit; One final note regarding the interbase.log file. I get an error: INET/inet_error: connect errno = 111 every time I start the server. I found a note saying that this error is generated because after you execute the start command IBMGR instantaneously attempts to connect to the security database isc4.gdb. This happens so quickly it's before the server is ready to accept connections and it generates the error. IBMGR will try repeatedly to connect to isc4.gdb and usually after a millisecond or two the server will be ready to accept connections so usually the next entry in the log is: /opt/interbase/bin/ibguard: guardian starting bin/ibserver indicating that the server has been successfully started.