***********************WARNING************************************************ One of the biggest problems in using postgres is its lack of security. As released in version 3.1, there was a problem with postgres security that greatly affected its utility for use in a production ticket system, assuming you are at all concerned with the security and the integrity of your ticket database. This problem was definitely present in postgres installed on SUN workstations, and possibly other system as well. Although security in postgres is minimal by design, the security mechanism that was in place did not work. Virtually any user, from any remote host with the postgres "monitor" installed, could access the database and make changes as long as the name of the database and the host/port where it is located are known. A patch file is included here that helps a little with this problem. It modifies ~postgres/src/support/postmaster.c and should be applied against that file. The patch incorporates a "hosts.postgres" file that defines exactly which hosts may access the postgres database. Any access from hosts other than those listed in the hosts.postgres file will be denied. It is still very easy to fool postgres to think you are a valid postgres user if the user is on one of the allowed hosts. To get around this, the trouble ticket commands, and the postgres commands, might be restricted with proper group permissions. Doing this means that only those in the ticket group can access the tickets, unless another script is created that will only allow viewing the tickets. This could be accomplished by taking the scripts and taking out all but the display / list functions and setting group id to allow postgres access, or modifying the finger daemon such as was done for the NEARnet trouble ticket system. There is also a problem with locking tickets when they are being updated. Postgres locking is done via transaction blocks rather than setting specific locks on individual tickets. Because the implementation involves a main shell script which calls a C program to fetch the ticket fields, resulting in two separate processes accessing the database, the transaction block mechanism does not work. This would be solved if the system were all one process (as might be the case with a C coded X Window interface). The shell lock mechanism from the nntp software has been borrowed to solve this locking problem. It should be noted that a new version of postgres is due out by the end of the summer, although security will still be minimal. ***********************WARNING************************************************