CONCEPTS:

Prior to start tinkering with Bora Applications, we need to get familiar with a few concepts:

Bora applications are completely decoupled from the underlying engine, Bora. These applications are written to Bora Application API as proof of concept that the Bora Builder environment is sufficient, efficient, and most importantly, works. We needed to uncover potential deficiencies of Bora –if any-, and to accomplish that there was no better way than putting ourselves right into the shoes of an application developer.

Once again, this document and the application-specific notions it is about to spill is not embedded in the underlying engine, Bora. These applications could have been designed even upside-down; the engine Bora would not give a dolly. Bora itself does not care what the applications running on top are all about. Now before delving into the applications, let's start with Bora first:

SYSTEM ACCOUNTS:

In installation time the Bora Builder configures two new user accounts into the host machine; one as a DBA (database administrator) account, and one for the Bora admin; although the two can be the same. (It may seem inconvenience to you, however we would still recommended to keep them separate). During the installation the suggested name for the DBA account is 'postgres', and for the Bora admin it is 'evince'. However these names might have been changed by the installer.

Some versions of Linux comes already installed with a 'postgres' user account, in which case we recommend you to choose a different login for the DBA account. It is not too difficult to install Bora Builder in a way that it shares a pre-existing 'postgres' account in the system, --if there is one--. Of course you need to know what you are doing to be able to do so. For anyone with a little understanding of Unix administration that should be a straightforward chore; regardless, we recommend you not to, since we have no way of judging your Unix proficiency.

A more troublesome scenario occurs when Linux configuration boots a preinstalled PostgreSQL database during startup. Of course that was a O/S installation choice at the time, and if we assume the individual installing Linux knew exactly what he/she was doing and decided to install PostgreSQL knowingly, then we can also assume that he/she still has the same PostgreSQL proficiency and knows how to handle multiple PostgreSQL instances. Well, at least that is what we are hoping :-)

If you are not sure of postgreSQL instances running on your system, do a 'ps -ef' to view the process table, and see if there is a 'postmaster' process there. If there is, you can shut down that process with an interrupt signal, as in:

Bora installation tries to detect already running postgreSQL instances and shuts them down. It, then, boots Bora Builder's own postmaster. You may verify this by checking the owner of the postmaster process after the installation. The owner should be the DBA account Bora installed.

Even though you may be successful in installing Bora and get it running the first time, next time around when you reboot the machine you may get in trouble again. That is because the very first time, installation itself took care of such multiple postgreSQL problems. After rebooting the machine, the old instance of postgreSQL may be rebooted once again as part of O/S boot procedure.

Don't despair; this is a problem anytime you install a new server and if there are other servers in your system (of the same kind or different) attempting to listen on the same port number as yours.

Bora Builder's postgreSQL listens on the port number 5432 by default, and uses the database 'boraapps'. If you have an old postgreSQL instance in the system, and indeed using it and want to keep it around along with the new one Bora Builder has just installed, then you are already postgreSQL-literate and well-equipped to solve a port conflict. Otherwise just shut down the old instance with an interrupt signal as explained above, and try to locate to source of the problem. That is the problem of having a postgreSQL instance popping up out of the blue every time you reboot the machine, chewing up your system resources, and conflicting with Bora Builder postgreSQL. The source of the problem is likely hidden somewhere in /etc/rc.d/inSomeFileHere, --although it might be slightly different in different variations of Linux--, that keeps booting 'postmaster' during startup. A grep for 'postmaster' on all the files in that directory will give you the source of the problem; as in:

Once you find the offending line, comment it out and put this problem behind once and for all.

HINT: If you find the postmaster invocation in a file that starts with a character 'S', say, "/etc/rc.d/rc3.d/S80postgres", the first character 'S' indicates "start", the number '80' is the invocation order, and the '3' in the directory name "rc3.d" indicates the init level, as in: "in init level 3, start postgres". That file is likely a symbolic link to "/etc/rc.d/init.d/postgres". (Similarly a link start with a character 'K' would indicate a 'kill' request at that init level.) In that case simply renaming the link would prevent the invocation of postgreSQL.

Although very unlikely, some Linux configurations may also boot postgreSQL engine as a process named 'postgres'; that is the postgreSQL backend in single-user mode. (We are yet to see such a setup). This is probably a faulty configuration, since 'postgres' is intended to be used by a DBA for debugging only. Bora Builder does not look for this unlikely instance of postgres process in the process table during installation. Make sure such a process does not become a source of problems if your system boots one by default. In can be eliminated the same way as explained above.