The
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 to make the environment
/opt/opengroupware.org/OpenGroupware.org.sh
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.
Category:
- Open Source
