Proxify SOGo access with OpenBSD

       476 words, 3 minutes

I used to run all of my services on the same OpenBSD server. Now that I switched to a virtualized environment, I’m on the way to dispatch the services on various virtual machines. As I have issues with the family’s iPhones and the SOGo 1.3.8.1 instance running on my OpenBSD gateway, I think it’s time to switch to an up-to-date version running elsewhere.

Here are the directions to publish a remote SOGo instance, here 1.3.13, with an OpenBSD Apache.

First of all, install your remote SOGo instance and configure it to access every resources dependencies. I won’t go into the SOGo installation process ; because it is really simple and because it is well described here .

My new instance of SOGo will use the same MySQL and LDAP instances as my current one. So I have disabled the local MySQL server. I copied the original /var/sogo/GNUstep/Defaults/.GNUstepDefaults XML configuration file from the previous SOGo instance to the new server. Then edited the parameters to be sure to connect to the remote dependencies.

Configure the SQL back-end

I’m switching from local SQL instance to remote SQL instance. So I had to modify the following parameters:

  -    <string>mysql://user:pass@%2Fvar%2Fwww%2Fmysql%2Fmysql.sock/sogo/sogo_alarms_folder</string>
  +    <string>mysql://user:pass@sql.tumfatig.net:3306/sogo/sogo_alarms_folder</string>
  <key>OCSFolderInfoURL</key>
  -    <string>mysql://user:pass@%2Fvar%2Fwww%2Fmysql%2Fmysql.sock/sogo/sogo_folder_info</string>
  +    <string>mysql://user:pass@sql.tumfatig.net:3306/sogo/sogo_folder_info</string>
  <key>OCSSessionsFolderURL</key>
  -    <string>mysql://user:pass@%2Fvar%2Fwww%2Fmysql%2Fmysql.sock/sogo/sogo_sessions_folder</string>
  +    <string>mysql://user:pass@sql.tumfatig.net:3306/sogo/sogo_sessions_folder</string>
  -    <string>mysql://user:pass@%2Fvar%2Fwww%2Fmysql%2Fmysql.sock/sogo/sogo_user_profile</string>
  +    <string>mysql://user:pass@sql.tumfatig.net:3306/sogo/sogo_user_profile</string>

Then, I had to modify the “c_location”, “c_quick_location” and “c_acl_location” values from every entries of the “sogo_folder_info” table. If you don’t, the SOGo daemon won’t be able to access the appointment and contact informations.

Configure the IMAP backend

Here again, I’m switching from local to remote IMAP server. The configuration parameter to update is:

  <key>SOGoIMAPServer</key>
  -	<string>localhost</string>
  +	<string>imaps://www.tumfatig.net:993</string>

Configure the LDAP backend

I use an LDAP dictionnary, so the reference has to be changed:

  <array>
  	    <dict>
  (...)
   		<key>hostname</key>
  -		<string>localhost</string>
  +		<string>ldap.tumfatig.net</string>

Configure the HTTP server

On the SOGo server, there is an Apache instance that publishes the Web part in HTTP. This server will only be used by the reverse-proxy. It has to publish SOGo as if it was the front-end server it-self:

  # vi /etc/apache2/conf.d/SOGo.conf
  (...)
  ## adjust the following to your configuration
    RequestHeader set "x-webobjects-server-port" "443"
    RequestHeader set "x-webobjects-server-name" "www.tumfatig.net"
    RequestHeader set "x-webobjects-server-url" "https://www.tumfatig.net"
  (...)

Configure the reverse-proxy

The initial Web server was configured to publish the Web resources it-self. Now, it has to be configured to get the data from the SOGo server. The configuration gets really small:

  ProxyPass /SOGo/ http://sogo.tumfatig.net/SOGo/
  ProxyPassReverse /SOGo/ http://sogo.tumfatig.net/SOGo/
  
  ProxyPass /SOGo.woa/ http://sogo.tumfatig.net/SOGo.woa/
  ProxyPassReverse /SOGo.woa/ http://sogo.tumfatig.net/SOGo.woa/

Note that those directives are located in an SSL enabled Virtual Host, so that the public flow is encrypted. But the communication from the reverse-proxy to the SOGo server is not. This is a security issue. In my case, the risk is quite small. But if this is a real issue for you, you may enable SSL on the SOGo server and proxify it using HTTPS.

That’s All Folks!

Related posts: