I have received a few helpful tips yesterday after my failed attempt to install EnterpriseDB Advanced Server on Debian lenny. The most useful was to run
sudo ./edb-linux-x86_82xx.bin -console -extractall
to extract the archive without additional setup. I was a bit disturbed to notice that this installed the entire software under /opt/EnterpriseDB/8.2/ world-writable. I was able to "ldd initdb" enough until I had set the required symlinks libssl.so.4 and libcrypto.so.4 and installed the missing packages related to termcap from Debian sarge (oldstable).After that I removed the directory /opt/EnterpriseDB/ and restarted the installer, but the installer was convinced I still had EDB installed and aborted. I had no idea what was wrong, because the old installation directory was surely gone. After a bunch of experimenting, stracing, and file searching I found a new directory /root/InstallShield/ that apparently contained an hsqldb database that stores the ultimate truth about what is really installed. Once you blow that away, you can start the installation again, and this time it actually ran to the end.
The installation layout looks like this from the top:
$ ls -l /opt/EnterpriseDB/8.2/
insgesamt 88
-rwxr--r-- 1 enterprisedb edb 2467 2007-07-18 14:09 BrowserLauncher.class*
drwxr-xr-x 5 enterprisedb edb 4096 2007-07-18 14:10 connectors/
drwx------ 13 enterprisedb edb 4096 2007-07-18 14:10 data/
drwxr-xr-x 7 enterprisedb edb 4096 2007-07-18 14:09 dbserver/
drwxr-xr-x 5 enterprisedb edb 4096 2007-07-18 14:10 devstudio/
-rwxr-xr-x 1 enterprisedb edb 101 2007-07-18 14:10 devstudio_desktop_launcher.sh*
drwxr-xr-x 2 enterprisedb edb 4096 2007-07-18 14:10 doc/
-rwxr-xr-x 1 enterprisedb edb 3116 2007-04-17 20:19 edbDynatune_multiOS.sh*
drwxr-xr-x 2 enterprisedb edb 4096 2007-07-18 14:09 icons/
drwxr-xr-x 2 enterprisedb edb 4096 2007-07-18 14:10 install_logs/
drwxr-xr-x 6 enterprisedb edb 4096 2007-07-18 14:09 jre1.5/
drwxr-xr-x 5 enterprisedb edb 4096 2007-07-18 14:09 mgmtsvr/
-rwxr-xr-x 1 enterprisedb edb 157 2007-07-18 14:09 mgmtsvr_desktop_launcher.sh*
drwxr-xr-x 4 enterprisedb edb 4096 2007-07-18 14:10 rpconsole/
-rwxr-xr-x 1 enterprisedb edb 95 2007-07-18 14:10 rpconsole_desktop_launcher.sh*
drwxr-xr-x 2 enterprisedb edb 4096 2007-07-18 14:09 samples/
-rwxr-xr-x 1 enterprisedb edb 4114 2007-07-18 14:10 serviceControl.sh*
drwxr-xr-x 2 enterprisedb edb 4096 2007-07-18 14:10 snmpd/
drwxr-xr-x 2 root root 4096 2007-07-18 14:10 _uninst/
drwxr-xr-x 3 enterprisedb edb 4096 2007-07-18 14:09 updateagent/
drwxr-xr-x 2 enterprisedb edb 4096 2007-07-18 14:10 updates/
Fortunately, the files are no longer world writable, but I can't help but suspect that there might be a window during the installation process where they are. But the installer sets up all files executable, even if they are just README files. Actually, some of the ones you might want to execute are set to owner-only executable. It's quite a mess. Careful observers will also note in the above output that the program files are owned by user enterprisedb, which also owns the server process – a blatant security violation.
In the directory dbserver/ you will find the usual PostgreSQL installation with some binaries renamed to have an edb- prefix (e.g., edb-psql). The directory devstudio/ contains the "Developer Studio", a frontend application that looks a bit like pgAdmin but is evidently written in Java and includes remnants of Red Hat's old Visual Explain tool. This application is under the GPL and you can get the source code on the EnterpriseDB web site. The mgmtsvr/ is the "DBA Management Server", which opens a browser to a local server and complains about an invalid certificate. I couldn't log in with any of the obvious accounts, so I didn't look further. Is one supposed to add all these directories to the PATH by the way?
The directory doc/ contains the documentation, which is a 800-some page PDF that is obviously based on the PostgreSQL and Slony-I documentations but does not contain the required copyright notice and license statements. In fact, I couldn't find any license statements about the included open-source products in the installation. (Maybe I didn't look right, but "rgrep CALIFORNIA ." ought to return something, I think.)
The installation also installs an init script in /etc/init.d/ to manage starting and stopping the server. Unfortunately, this is set up to stop the service in run level 2 by default, which is the default on Debian, so you need some manual fixup there. Logging from the server goes to syslog by default.
A few people asked me yesterday about what the dynatune setting does. Well, actually it sets a parameter edb_dynatune in postgresql.conf to a value between 0 and 100 that tells how many percent of your resources you want to dedicate to the database system. After that it supposedly takes care of the rest. There is a mysterious "postgres: edb dynatune" process hanging around, which probably has something to do with it. I could see that the shared buffers are apparently adjusted depending on the dynatune setting, but the EDB license prevents me from telling more, so you will have to check that yourself.
The recent thread on pgsql-advocacy raised a few questions about how PostgreSQL compliance can be maintained while having Oracle compatibility, in particular regarding the pecular null vs. empty string handling that Oracle famously has. Well, that is not present at all; it works exactly like PostgreSQL and exactly not like Oracle. Further quick checking found a number of obvious Oracle-compatibility extensions such as additional available functions, a "dual" table, varchar2, switches for date styles, and what not. But now that I have checked the null handling, my doubts that this is really not that compatible after all were confirmed.
Now, how to uninstall this ...
Posts
