Linux.com

Background

OGo is an ambitious project seeking to provide many of the functions that are not currently available in most Open Source groupware solutions. To quote the press release: "OGo software will enable users to share calendar, address book and e-mail information; they can communicate via instant messaging, share folders, exchange documents, track changes, share a whiteboard, and browse the Web all at the same time -- all upon open Internet standards and without paying or managing cumbersome licensing fees."

The press release also quotes Gary Frederick, leader of the OpenOffice.org Groupware Project, as saying, "Just to be perfectly clear, this is an MS Exchange replacement. OGo is important because it's the missing link in the open source software stack. It's the end of a decade-long effort to map all the key infrastructure and standard desktop applications to free software."

OGo uses the code of Skyrix 4.1 Groupware Server, a product of the German firm Skyrix Software AG. This commercial product has seven years of development behind it, so OGo should be able to take advantage of the product's maturity.

Installation

I was eager to try OGo myself. Since this is the first release of the software, I was prepared to perform manual configuration to get everything installed properly. The Web site for the project promises that improved installation processes will be available shortly. Frankly, I'd settle for a complete installation process. Following the information on the Web pages does not produce a working system, at least as of July 12.

First, I downloaded a tarball of the appropriate kits to install. Since I was installing it on a Red Hat 9 box, I downloaded the 20MB tarball of RPMs. Unpacking the tarball yielded an impressive 48 RPMs. Thankfully, you only need to install 27 of them to get started; the rest are mostly development kits.

The OGo Web site outlines the order in which to install the kits. The instructions refer to a kit called "opengroupware-libxmlsaxdriver," which apparently should read "pengroupware-xml-libxmlsaxdriver." Other than that, installation was painless and uneventful, even if it took a while to cut and paste the 27 RPM file names in the prescribed order.

Next, I started up the PostgreSQL service and dutifully followed the configuration instructions, making the noted adjustments for the fact I was installing from RPMs (yes, the software installs to different locations on an RPM-based system than on a Debian system, so you have to make sure you adjust the directory trees in the instructions accordingly). One change I had to make was that I could not create the database as root on Red Hat. I had to "su postgres" (the default PostgreSQL username used by Red Hat) in order to create the database and user properly. I also had to create a user called "ogo" and do "su ogo" before I could access the database properly.

Then, when it came time to use the "Defaults" tool to configure the OGo server, I found that the utility's directory was missing from my PATH. Poking around, I found that I needed to execute source /opt/opengroupware.org/OpenGroupware.org.sh to make the environment variables correct.

I tried to set up the Web server so I could use the Web-based administration interface. However, the syntax for executing the OpenGroupware server was incorrect on the Web page. I had to adjust the executable's location to ./OpenGroupware.woa/ix86/linux-gnu/gnu-fd-nil/OpenGroupware instead of ./OpenGroupware.woa/linux-gnu/gnu-fd-nil/OpenGroupware as listed in the instructions.

I also found that the connector currently works only for Apache 1.3, not for Apache 2.x, which is found in Red Hat 9. If you need to install the software on Red Hat 9, you have to make sure that the older Apache server is installed. For testing, though, it is possible to run the OpenGroupware.org server in standalone mode.

To install the Apache connector, you need to manually compile some of the software to match your Apache version using a fairly lengthy set of instructions on the Web page. Unfortunately, I never got that far, since I couldn't get the standalone OGo server software to run well enough to justify the effort to interface it with Apache.

The information given about linking the server to a PostgreSQL database was thin at best. The original instructions were missing several steps, many of which were eventually posted to the mailing list in the form of a FAQ. Unfortunately, I was early enough in the loop that I found myself facing many of the problems before their solutions made their way into the FAQ.

To get the link to PostgreSQL to work, I had to perform a number of tasks which were not in any installation document at the time. I had to edit /var/lib/pgsql/data/postgresql.conf and set tcpip_socket = true to allow network connections to the database. I then had to issue the following commands to point OGo to PostgreSQL:

Defaults write NSGlobalDomain LSAdaptor PostgreSQL72
Defaults write NSGlobalDomain LSModelName OpenGroupware.org_PostgreSQL
Defaults write NSGlobalDomain NGBundlePath /opt/opengroupware.org/Library/OpenGroupware.org/

Then, as root, I had to edit /var/lib/pgsql/data/pg_hba.conf to include:

host     all         all         127.0.0.1         255.255.255.0     trust

so that PostgreSQL would accept connections from the local node.

But, lo and behold, the server started getting write errors when it tried to save information to its directory structure. So I had to:

chown opengroupware.skyrix ../WOApps

to make the directory tree accessible to server.

Next, as the user "opengroupware," I had to remove the empty directory ~OpenGroupware.woa/WebServerResources and create a link:

ln -s /opt/opengroupware.org/WebServerResources/ OpenGroupware.woa/

I could then access the OGo administrator interface using the URL http://localhost:20000/.

However, many things remained non-functional. For instance, all the links on the page assume node names of "wo" and "x," so to make things usable, I had to add these two node names to /etc/hosts, pointing them both to the localhost.

I also had to go back and create a documents directory, /opt/opengroupware.org/documents, and point the Web server to the new location:

Defaults write NSGlobalDomain LSAttachmentPath /opt/opengroupware.org/documents

Unfortunately, I soon found that I had at least a half dozen more problems by the time I got the server to limp along in standalone mode. Some links wouldn't work, the server would bomb after you visited a few screens, and it seemed to forget data entered last time and then rediscover it again. There was almost no information present on how to configure client software to access the server, and the instructions for compiling the Apache connector looked like a potential minefield.

At this point, I decided to cut my losses and quit. I had spent several hours learning, poking, and debugging, trying to compensate for the pitiful lack of documentation (and don't even think about referring to the commercial product documents; the commercial product has an installer so none of these issues arise there). I decided my time would be better spent looking at it again when it has usable installation instructions.

The long and short of it

The bottom line is this: the software may be mature, but the installation and configuration of the software is still pre-alpha. Without these necessary pieces, the code is currently useless to anyone but developers. As I write this on July 12, it is not ready for corporate users to download and test.

However, if the configuration portion is the only major work to be done, this situation could change dramatically within the month. The mailing lists seem active with users fighting the same battles I was fighting, and the project team was slowly growing a FAQ to deal with the questions as they arose.

It seems clear that the project team never bothered to do an installation on a pristine machine and simply write down the steps needed to do the job. Following the steps listed on the Web page results in software which is not even remotely functional. For a supposedly mature piece of software, it would seem that even a cumbersome step-by-step installation guide using PostgreSQL, the one database which everyone has, would have been an obvious document to release with the code. I can only hope that such a document will be developed quickly.

There is an important lesson to be learned here. It's one thing to announce the formation of a project and the release of code; it's another to announce that the software that will change the industry has arrived. Announcement of the project would have been greeted warmly, but there is no way anyone can claim that the software released on July 10 is actually usable by organizations. I wouldn't want to be in the shoes of someone who actually read the press release and downloaded the software with hopes of using the software in business. Someone like that might be slow to touch the project again after finding that the press release promises don't match the reality.

From what I could see of the software, OGo could be the most important new Open Source project of the year -- provided it can deliver on its promises. If all that is really missing here is installation and configuration information, the software might be usable by organizations in a few weeks. When the installation process is complete, I intend to revisit this software. Until that point, I don't recommend that organizations bother with a download for evaluation purposes. Developers and alpha-testers who want a hand in putting together a working solution should get involved and monitor the mailing lists carefully.

Russell Pavlicek is a consultant and author dealing with Linux in business. He is a panelist on The Linux Show weekly webcast, and is a contributor to a number of Linux Web sites. He formerly wrote the Open Source column for InfoWorld magazine.

Share    Print    Comments