Web links for SOGo:
SOGo turns out to mean Scalable Open Groupware .org
.
One possibility for testing SOGo is the ZEG Virtual Appliance
.
This is a pre-stuffed image, available for Virtualbox or VMWare. It includes
SOGo, Funambol, and all required infrastructure: PostgreSQL, OpenLDAP, Cyrus
(IMAP), Postfix and Apache. Since I'm a masochist, I'm going to compile it
natively.
The SOGo download page has a source tarball, RPMs for RHEL5 and CentOS-5 (32 and 64 bit), deb packages for Debian (Lenny/5.0 and Squeeze/6.0) and Ubuntu (Intrepid/8.10, Karmic/9.10, Lucid/10.04), and the Funambol SOGo Connector. The SuSE Build Service does not have it. Nor does Packman. I will be installing the tarball, and perhaps later I will hack the spec file for use on SuSE. This will be SOGo-1.3.5a.tar.gz dated 2011-01-27. Dependency on SOPE (same version, same source). Download size is 3.4Mb and 2.2Mb (compressed).
Prerequisites.
They always inflate the requirements. Quantities separated by slashes are for testing or for production.
These are described in the installation guide.
Showing only the ones installed in the previous step.
home directoryis /var/lib/pgsql.
home directoryis /var/run/dovecot. Its various sockets go here as well as the PID file.
Apparently does not need configuration. But the gdomap daemon has to be started at boot time.
Apparently does not need configuration. But the memcached daemon has to be started at boot time.
On the SOGo website look under Support - FAQ - Compilation. These dependencies are listed:
The standard procedure:
./configure --prefix=/usr/local/SOPE --enable-debug --disable-strip
The FAQ page recommends turning on debugging. There are no
other optional features for this package.
It says that SOPE does not automatically look beyond /usr and /usr/local for resources; if you install in an arbitrary path, source GNUstep.sh before executing the program. Presumably they mean /usr/share/GNUstep/Makefiles/GNUstep.sh .
The other odd message from .configure was failed to link
optional library: mysqlclient
and it didn't say anything about
pgsql.
Make and make install seemed to go OK.
It was willing to install in prefix /usr/local; this was the default prefix. SOPE ended up in these directories:
Re-done with --prefix=/usr/local/SOPE: it installed most stuff in the prefix except for these header files:
Same procedure:
./configure --enable-debug --disable-strip
The FAQ page recommends turning on debugging. In fact,
./configure has it on by default. There are no
other optional features for this package. It did not want to
have --prefix=/usr/local (says not a GNUstep root) even though
this is indicated as the default prefix. Neither would it swallow
/usr/local/SOGo like SOPE would. It actually used
/usr/Local as the prefix, so it says. However, the content ended
up in /usr/local.
I hacked ./configure to turn the prefix rejection into a warning. Instead try setting GNUSTEP_INSTALLATION_DIR to the desired prefix.
Make and make install seemed to go OK with the default prefix. The content (1273 files) ended up in:
Compilation needs -I/usr/local/SOPE/include.
I tried recompiling it with --prefix=/usr/local/SOGo. It had a great deal of trouble to find its internal libraries, and I never did get it to link everything.
I have two issues here. First, if I compile with --prefix=/usr/local it installs about 1700 files and it's going to be a pain if I ever want to uninstall it. Second, for configuration management I sync /usr/local from the master site, and that means SOGo/SOPE will end up on every other host, which I don't want. If I can compile RPMs then rpm will handle the uninstall issue, and there is no need to install it on irrelevant hosts.
The TGZ for SOGo has a spec file but SOPE doesn't. However, see this advice:
http://www.mail-archive.com/users@sogo.nu/msg03779.html from Fabrice Durand (2011-02-07) referring to source RPMs in http://www.sogo.nu/files/downloads/SOGo/RHEL5/SRPMS/.
http://www.mail-archive.com/users@sogo.nu/msg03781.html, responding to a specific query about SuSE, gives a reference to FC11 SRPMs from a different site: SOPE-4.9 and SOGo-1.3.5a. Plus details for jiggering the spec files.
Later (2011-02-11 I think) he created SuSE spec files and srpms. I sent my hacked spec files to him for comparison.
I Downloaded the FC11 SRPMs (5.5Mb compressed).
rpm -i {sope,sogo]-$VERS.rpm
Following instructions, in /usr/src/packages/SPECS I edited sope.spec and sogo.spec as follows:
%define dist_suffix fc11changing to suse112 (sope 1 place)
zypper install mysql-devel.
rpmbuild -ba ./sope.spec (capture the output with |& tee /tmp/sope.log)
SOPE will go into prefix /usr/Local, so it says. The stuff really has --prefix=/usr, e.g. /usr/lib/libNGStreams.so.4.9.57 and lots of friends. At least it's an RPM so you can find and remove it if you don't like it. These RPMs were built (in /usr/src/packages/RPMS/i586) (total size 4.4Mb compressed):
Install at least these packages which you just built. If you put the RPMs in your enterprise repository, the devel packages should drag in the underlying functional packages and their dependencies.
rpmbuild -ba ./sogo.spec (capture the output with |& tee /tmp/sogo.log).
SOGo builds. These RPMs are produced (in /usr/src/packages/RPMS/i586 ) (total size 3.2Mb compressed):
Install them (not the devel packages); if you put them in your enterprise repository, the keystone packages are the four SOGo items.
/etc/init.d/sogod is not LSB compliant; on a LSB distro like openSUSE you'll have to edit the script with Provides, Required-Start, etc. **** provide script here.
/etc/apache2/conf.d/SOGo.conf will use mod_proxy to hand off PIM requests to SOGo on localhost port 20000. I needed to make these adjustments to the file:
It was in /etc/httpd/conf.d/SOGo.conf because I didn't jigger sogo.spec to put it in the right place.
Look for yourhostname
and change to the FQDN of your
server (2 places in RequestHeader of the proxy to SOGo on port 20000).
If you are using Apache authentication, uncomment the relevant sections. We should set up mod_auth_ldap and mod_auth_kerb (Kerberos), and have SOGo cue from the Apache proxy, but I'm going to start with native auth to reduce the number of possible screwups.
You need to edit /etc/sysconfig/apache2 , the APACHE_MODULES
variable. Make sure you are loading mod_alias, mod_headers, mod_proxy
and mod_rewrite. Also any modules needed for authentication, if turned
on. Normally you omit mod_
in the list.
You need to reload Apache to get the added modules and SOGo.conf.
Do /etc/init.d/apache2 reload
.
Returning to the SOGo Installation and Configuration Guide:
Create the home directory of the sogo user. I put mine in /var/lib/sogo. Probably the group is irrelevant but I put my user in primary group mail, and I'll set that group for the homedir also. It's going to have a file containing the database password, so I'm setting the mode to 700.
Make sure you know your LDAP parameters. The values shown are the typical values from the Installation Guide. You end up setting them in the LDAP member of the SOGoUserSources list.
The identification name of the LDAP repository.Not sure what this means. Probably it's just an identifier to be used in error messages.
uidis normally the name of this attribute.
gecosis what it's called in UNIX (POSIX schema); other schemata like Windows Active Directory may call it
cnfor Common Name.
su
to the sogo user. You will need to specify the shell
explicitly, i.e. su -s /bin/sh sogo
. Use the command
defaults
that
comes with gnustep-base to set configuration values. The command line
format is
defaults write sogod $Key "$Value"
Go through the Installation Guide, the Configuration section, and set the needed parameters. See the previous section on LDAP for a more user-friendly explanation of the LDAP parameters. I made a script to preserve the variable settings in case I have to do it over. **** Show script
You also need to create the sogo user and the sogo database. The Installation Guide (page 20) has the procedure; however, I don't think it's wise to use such a lameass password. I created a random password but changed the punctuation to just hyphens and dots. I wanted to use ident auth on UNIX domain sockets, but SOGo is set up to potentially use a trans-net database server, which means it's going to do a TCP connection to localhost, on which ident doesn't do anything. So we have to do the password thing, and to put the password in the configuration file. Hiss, boo. I should ask in the forum whether an alternate form of the URL will make it use the UNIX domain socket.
Turning it on: The Installation Guide tells you to start daemons in this order: SOGo (sogod), Apache, memcached. This seems kind of backward. Anyway, for initial startup I'll do SOGo first, then Apache. Memcached is already running, as is the GNUstep daemon gdomap (not mentioned in the Installation Guide).
sogod starts, doesn't die, and attaches to port 20000. Initial errors or suspicious messages are:
products: Contacts, ContactsUI, SchedulerUI, Appointments, MainUI, MailerUI, Mailer, MailPartViewers, PreferencesUI, AdministrationUI, CommonUI.
Apache successfully reloads its configuration including the SOGo hacks. Basically it forwards everything under /SOGo to the daemon.
Accessing that directory as https://otter.mine.nu/SOGo/ : Apache
complains: No protocol handler was valid for the URL /SOGo/. If
you are using a DSO version of mod_proxy, make sure the proxy
submodules are included in the configuration using LoadModule.
I'd better find out what submodules it wants.
We're doing a reverse proxy. ProxyRequests is turned off.
Since we're handling HTTP/S requests, we need mod_proxy_http .
That done, a request to the above URL elicits a login form. But it's lameass: logo image and Javascript are missing.
Complaint: the language is not pre-filled as English; I thought I set that as a default.
When you hit Connect, a reply comes back very fast but the
page content is not replaced. Similarly for the About
link.
Log file: could not load bundles: /usr/local/lib/GNUstep/WOxElemBuilders-4.9/SOGoElements.wox /usr/local/lib/sope-4.9/wox-builders/WEExtensions.wox /usr/local/lib/sope-4.9/wox-builders/WOExtensions.wox Deleted /usr/local/lib/GNUstep and /usr/local/lib/sope-4.9, but login form is still inert.
Apache complains: client denied by server configuration: /usr/lib/GNUstep/SOGo/WebServerResources/PasswordPolicy.js , referer: https://otter.mine.nu/SOGo/ The cure was, in /etc/apache2/conf.d/SOGo.conf , after the three Alias directives, to add this stanza allowing the webserver to send out the referent files:
<Directory /usr/lib/GNUstep/SOGo/WebServerResources>
Order allow,deny
Allow from all
</Directory>
Now the login form is nicely formatted, with the logo
image, but I don't get logged in. After about 2 minutes it
shows 502 bad gateway
. Log file complaint #1: timeout
reading the status line from the remote server (SOGo on 20000).
Log file complaint #2:
proxy: ap_get_scoreboard_lb(0) failed in child 8399 for worker
http://127.0.0.1:20000/SOGo. This can't be good. Community
consensus is that when mod_proxy is first added, you need to
shut down and restart the server; reload (graceful restart)
is not enough. When I did that the scoreboard errors went
away. But I still get the timeout.
/var/log/sogo/sogo.log doesn't look good. When the login request comes in, WOWatchDogChild kills the child process and starts a new one. Startup looks reasonable. It then does these requests:
Posted on users@sogo.nu. The cure: in .GNUstepDefault set SOGoIMAPServer to imaps://localhost:993 not just localhost:993.
Tidbit: client CalDAV setting is https://sogoserver.domainname.com:443/dav/UserID/ ; CardDAV would be just https://sogoserver.domainname.com:443 . The first one works on an iPhone-3 but not iPhone-4. I can't tell if the guy is saying that the CardDAV one does or doesn't work. Someone else says, you need to offer CardDAV on port 8843. On iPhone you can override the port for CalDAV but not CardDAV. Also a more correct CalDAV URL is https://sogoserver.domainname.com/SOGo/dav/UserID .
The next problem: works fine on Jacinth, but Simba has autofs and the hosts directory is /net. It looks for /*/bundle-info.plist and silently doesn't find it in all of the normal toplevel directories. But autofs could potentially mount a filesystem on the host bundle-info.plist, so it creates a directory where the mount points could be put. Sogod opens this directory and maps it, but seeking in this file returns EINVAL (duh), killing sogod.
This was reported as a bug in SOGo. As an extremely kludgey workaround, I changed the permissions of /net to sogo:root 0075. Thus root (being in group root) still has permission to write on the directory, but sogo is locked out and can't open the bogus plist file.
Twice so far I've forgotten to edit one or another of the LDAP parameters. Most recently, I copied the configuration from home to work, but used home's baseDN, and of course the work LDAP server returned nothing, and the user was considered to have an incorrect loginID or password.