SOGo Installation Guide
SOGo Installation Guide
7
Installation and Configuration Guide
Copyright © 2008-2013 Inverse inc. (http://inverse.ca)
Permission is granted to copy, distribute and/or modify this document under the terms of the
GNU Free Documentation License, Version 1.2 or any later version published by the Free
Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
Chapter 2 Introduction 4
Architecture 5
Chapter 4 Installation 9
Software Downloads 9
Software Installation 9
Chapter 5 Configuration 10
GNUstep Environment Overview 10
Preferences Hierarchy 11
General Preferences 12
Authentication using LDAP 18
LDAP Attributes Indexing 24
LDAP Attributes Mapping 24
Authenticating using C.A.S. 25
Authenticating using SAML2 27
Database Configuration 27
Authentication using SQL 29
SMTP Server Configuration 31
IMAP Server Configuration 32
Web Interface Configuration 34
SOGo Configuration Summary 38
Multi-domains Configuration 39
Apache Configuration 42
Starting Services 42
Cronjob — EMail reminders 43
Cronjob — Vacation messages expiration 43
Chapter 7 Funambol 46
Chapter 9 Upgrading 53
This guide will walk you through the installation and configuration of the SOGo solution. It also
covers the installation and configuration of Funambol – the middleware used to synchronize
mobile devices with SOGo.
The instructions are based on version 2.0.7 of SOGo, and version 10.0 of Funambol.
2 Introduction
SOGo is a free and modern scalable groupware server. It offers shared calendars, address books,
and emails through your favourite Web browser and by using a native client such as Mozilla
Thunderbird and Lightning.
SOGo is standard-compliant. It supports CalDAV, CardDAV, GroupDAV, iMIP and iTIP and
reuses existing IMAP, SMTP and database servers - making the solution easy to deploy and
interoperable with many applications.
SOGo features :
❏ Scalable architecture suitable for deployments from dozens to many thousands of users
❏ Rich Web-based interface that shares the look and feel, the features and the data of Mozilla
Thunderbird and Lightning
❏ Improved integration with Mozilla Thunderbird and Lightning by using the SOGo Connector
and the SOGo Integrator
❏ Two-way synchronization support with any SyncML-capable devices (BlackBerry, Palm,
Windows CE, etc.) by using the Funambol SOGo Connector
Architecture
Standard protocols such as CalDAV, CardDAV, GroupDAV, HTTP, IMAP and SMTP are used to
communicate with the SOGo platform or its sub-components. Mobile devices supporting the
SyncML standard use the Funambol middleware to synchronize information.
To install and configure the native Microsoft Outlook compatibility layer, please refer to the
SOGo Native Microsoft Outlook Configuration Guide.
3 System Requirements
Assumptions
In this guide, we assume that all those components are running on the same server (i.e.,
“localhost” or “127.0.0.1”) that SOGo will be installed on.
The following table provides recommendations for the required components, together with
version numbers :
More recent versions of the software mentioned above can also be used.
The following table provides hardware recommendations for the server, desktops and mobile
devices :
Production
• Intel, AMD or PowerPC CPU 3 GHz
• 2048 MB of RAM
• 10 GB of disk space (excluding the mail store)
Desktop General
• Intel, AMD, or PowerPC CPU 1.5 GHz
• 1024x768 monitor resolution
• 512 MB of RAM
• 128 Kbps or higher network connection
Microsoft Windows
• Microsoft Windows XP SP2 or Vista
Apple Mac OS X
• Apple Mac OS X 10.2 or later
Linux
• Your favourite GNU/Linux distribution
Mobile Device Any mobile device which supports the SyncML 1.0 or 1.1 standard.
Recommended
• Palm OS based devices with Synthesis SyncML Client
• Research In Motion (RIM) BlackBerry devices with Funambol client
• Microsoft Windows Mobile PocketPC or SmartPhone with the
Funambol client
The following 32-bit and 64-bit operating systems are currently supported by SOGo :
Make sure the required components are started automatically at boot time and that they are
running before proceeding with the SOGo configuration. Also make sure that you can install
additional packages from your standard distribution. For example, if you are using Red Hat
Enterprise Linux 5, you have to be subscribed to the Red Hat Network before continuing with
the SOGo software installation.
For installation instructions on Debian and Ubuntu, please refer directly to the SOGo website at
http://www.sogo.nu. Under the downloads section, you will find links for installation steps for
Debian and Ubuntu.
Note that once the SOGo packages are installed under Debian and Ubuntu, this guide can be
followed in order to fully configure SOGo.
4 Installation
This section will guide you through the installation of SOGo together with its dependencies. The
steps described here apply to an RPM-based installation for a Red Hat or CentOS distribution.
Software Downloads
SOGo can be installed using the yum utility. To do so, first create the
/etc/yum.repos.d/inverse.repo configuration file with the following content :
[SOGo]
name=Inverse SOGo Repository
baseurl=http://inverse.ca/downloads/SOGo/RHEL6/$basearch
gpgcheck=0
Some of the softwares on which SOGo depends are available from the repository of RepoForge
(previously known as RPMforge). To add RepoForge to your packages sources, download and
install the appropriate RPM package from http://packages.sw.be/rpmforge-release/. Also make
sure you enabled the “rpmforge-extras” repository.
Software Installation
Once the yum configuration file has been created, you are now ready to install SOGo and its
dependencies. To do so, proceed with the following command :
This will install SOGo and its dependencies such as GNUstep, the SOPE packages and
memcached. Once the base packages are installed, you need to install the proper database
connector suitable for your environment. You need to install sope49-gdl1-postgresql for the
PostgreSQL database system, sope49-gdl1-mysql for MySQL or sope49-gdl1-oracle for
Oracle. The installation command will thus look like this :
Once completed, SOGo will be fully installed on your server. You are now ready to configure it.
5 Configuration
In this section, you'll learn how to configure SOGo to use your existing LDAP, SMTP and
database servers. As previously mentioned, we assume that those components run on the same
server on which SOGo is being installed. If this is not the case, please adjust the configuration
parameters to reflect those changes.
SOGo makes use of the GNUstep environment. GNUstep is a free software implementation of
the OpenStep specification which provides many facilities for building all types of server and
desktop applications. Among those facilities, there is a configuration API similar to the "Registry"
paradigm in Microsoft Windows. In OpenSTEP, GNUstep and MacOS X, these are called the
"user defaults".
In SOGo, the user's applications settings are stored in /etc/sogo/sogo.conf. You can use
your favourite text editor to modify the file.
The sogo.conf file is a serialized property list. This simple format encapsulates four basic data
types: arrays, dictionaries (or hashes), strings and numbers. Numbers are represented as-is,
except for booleans which can take the unquoted values “YES” and “NO”. Strings are not
mandatorily quoted, but doing so will avoid you many problems. A dictionary is a sequence of
key and value pairs separated in their middle with a “=” sign. It starts with a “{“ and ends with a
corresponding “}”. Each value definition in a dictionary ends with a semicolon. An array is a
chain of values starting with “(“ and ending with “)”, where the values are separated with a “,”.
Also, the file generally follows a C-style indentation for clarity but this indentation is not
required, only recommended.
Preferences Hierarchy
SOGo supports domain names segregation, meaning that you can separate multiple groups of
users within one installation of SOGo. A user associated to a domain is limited to access only
the users data from the same domain. Consequently, the configuration parameters of SOGo are
defined on three levels:
Each level inherits the preferences of the parent level. Therefore, domain preferences define the
defaults values of the user preferences, and the system preferences define the default values of
all domains preferences. Both system and domains preferences are defined in the
/etc/sogo/sogo.conf, while the users preferences are configurable by the user and stored in
SOGo's database.
To identify the level in which each parameter can be defined, we use the following
abbreviations in the tables of this document :
Remember that the hierarchy paradigm allow the default value of a parameter to be defined at a
parent level.
General Preferences
The following table describes the general parameters that can be set :
• Hungarian
• Italian
• Russian
• Spanish
• Swedish
• Welsh
D SOGoNotifyOnPersonalModifications Parameter used to set whether SOGo sends or
not email receipts when someone changes
his/her own calendar. Possible values are :
• YES – to send notifications
• NO – to not send notifications
Defaults to NO when unset. User can
overwrite this from the calendar properties
window.
D SOGoNotifyOnExternalModifications Parameter used to set whether SOGo sends or
not email receipts when a modification is
being done to his/her own calendar by
someone else. Possible values are :
• YES – to send notifications
• NO – to not send notifications
Defaults to NO when unset. User can
overwrite this from the calendar properties
window.
D SOGoLDAPContactInfoAttribute Parameter used to specify an LDAP attribute
that should be displayed when auto-
completing user searches.
D SOGoiPhoneForceAllDayTransparency When set to YES, this will force all-day events
sent over by iPhone OS based devices to be
transparent. This means that the all-day events
will not be considered during freebusy
lookups. Defaults to NO when unset.
S SOGoEnablePublicAccess Parameter used to allow or not your users to
share publicly (ie., requiring not
authentication) their calendars and address
books.
Possible values are :
• YES – to allow them
• NO – to prevent them from doing so
Defaults to NO when unset.
S SOGoPasswordChangeEnabled Parameter used to allow or not users to change
their passwords from SOGo.
Possible values are :
• YES – to allow them
• NO – to prevent them from doing so
Defaults to NO when unset.
S SOGoSupportedLanguages Parameter used to configure which languages
are available from SOGo's Web interface.
SOGo can use a LDAP server to authenticate users and, if desired, to provide global address
books. SOGo can also use an SQL backend for this purpose (see the section Authentication
using SQL later in this document). Insert the following text into your configuration file to
configure an authentication and global address book using an LDAP directory server :
SOGoUserSources = (
{
type = ldap;
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
IMAPHostFieldName = mailHost;
baseDN = "ou=users,dc=acme,dc=com";
bindDN = "uid=sogo,ou=users,dc=acme,dc=com";
bindPassword = qwerty;
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = "ldap://127.0.0.1:389";
id = public;
isAddressBook = YES;
}
);
In our example, we use a LDAP server running on the same host where SOGo is being installed.
You can also, using the filter attribute, restrict the results to match various criteria. For example,
you could define, in your .GNUstepDefaults file, the following filter to return only entries
belonging to the organization Inverse with a mail address and not inactive:
Since LDAP sources can serve as user repositories for authentication as well as address books,
you can specify the following for each source to make them appear in the address book
module:
For certain LDAP sources, SOGo also supports indirect binds for user authentication. Here is an
example :
SOGoUserSources = (
{
type = ldap;
CNFieldName = cn;
IDFieldName = cn;
UIDFieldName = sAMAccountName;
baseDN = "cn=Users,dc=acme,dc=com";
bindDN = "cn=sogo,cn=Users,dc=acme,dc=com";
bindFields = (sAMAccountName);
bindPassword = qwerty;
canAuthenticate = YES;
displayName = "Active Directory";
hostname = ldap://10.0.0.1:389;
id = directory;
isAddressBook = YES;
}
);
In this example, SOGo will use an indirect bind by first determining the user DN. That value is
found by doing a search on the fields specified in bindFields. Most of the time, there will be
only one field but it is possible to specify more in the form of an array (for example,
bindFields = (sAMAccountName, cn) ). When using multiple fields, only one of the fields
needs to match the login name. In the above example, when a user logs in, the login will be
checked against the sAMAccountName entry in all the user cards, and once this card is found,
the user DN of this card will be used for checking the user's password.
Finally, SOGo supports LDAP-based groups. Groups must be defined like any other
authentication sources (ie., canAuthenticate must be set to YES and a group must have a valid
email address). In order for SOGo to determine if a specific LDAP entry is a group, SOGo will
look for one of the following objectClass attributes :
❏ group
❏ groupOfNames
❏ groupOfUniqueNames
❏ posixGroup
You can set ACLs based on group membership and invite a group to a meeting (and the group
will be decomposed to its list of members upon save by SOGo). You can also control the
visibility of the group from the list of shared address books or during mail autocompletion by
setting the isAddressBook parameter to YES or NO. The following LDAP entry shows how a
typical group is defined :
dn: cn=inverse,ou=groups,dc=inverse,dc=ca
objectClass: groupOfUniqueNames
objectClass: top
objectClass: extensibleObject
uniqueMember: uid=alice,ou=users,dc=inverse,dc=ca
uniqueMember: uid=bernard,ou=users,dc=inverse,dc=ca
uniqueMember: uid=bob,ou=users,dc=inverse,dc=ca
cn: inverse
structuralObjectClass: groupOfUniqueNames
mail: [email protected]
The corresponding SOGoUserSources entry to handle groups like this one would be :
{
type = ldap;
CNFieldName = cn;
IDFieldName = cn;
UIDFieldName = cn;
baseDN = "ou=groups,dc=inverse,dc=ca”;
bindDN = "cn=sogo,ou=services,dc=inverse,dc=ca";
bindPassword = zot;
canAuthenticate = YES;
displayName = “Inverse Groups”;
hostname = ldap://127.0.0.1:389;
id = inverse_groups;
isAddressBook = YES;
}
The following table describes the possible parameters related to a LDAP source :
D SOGoUserSources Parameter used to set the LDAP and/or SQL sources used
for authentication and global address books. Multiple
sources can be specified as an array of dictionaries. A
dictionary that defines an LDAP source can contain the
following values:
type the type of this user source, set to ldap for an LDAP
source
id the identification name of the LDAP repository. This must
be unique – even when using multiple domains.
CNFieldName the field that returns the complete name
IDFieldName the field that starts a user DN if bindFields is not used.
This field must be unique across the entire SOGo domain
UIDFieldName the field that returns the login name of a user.
The returned value must be unique across the whole
SOGo installation since it is used to identify the user in
the folder_info database table.
server
bindPassword its password
bindAsCurrentUser if set to YES, SOGo will always keep binding to the LDAP
server using the DN of the currently authenticated user. If
bindFields is set, bindDN and bindPassword will still be
required to find the proper DN of the user.
bindFields (optional) an array of fields to use when doing indirect binds
hostname a space-delimited list of LDAP URLs or LDAP hostnames.
LDAP URLs are specified in RFC 4516 and have the
following general format:
scheme://host:port/DN?attributes?scope?
filter?extensions
Note that SOGo doesn't currently support DN,
attributes, scope and filter in such URLs. Using
them may have undefined side effects.
URLs examples:
ldap://127.0.0.1:3389 ldaps://127.0.0.1
ldap://127.0.0.1/????!StartTLS
port(deprecated) port number of the LDAP server.
A non-default port should be part of the ldap URL in the
hostname parameter.
encryption (deprecated) either SSL or STARTTLS
SSL should be specified as 'ldaps://' in the LDAP URL.
STARTTLS should be specified as a LDAP Extension in
the LDAP URL (ex: ldap://127.0.0.1/????!
StartTLS)
userPasswordAlgorithm The algorithm used for password encryption when
changing passwords without Password Policies enabled.
Possible values are: none, plain, crypt, md5, md5-crypt,
smd5, cram-md5 and sha, sha256, sha512 and
its ssha (e.g. ssha or ssha256) variants (plus setting of the
encoding with ".b64" or ".hex").
For a more detailed description see
http://wiki.dovecot.org/Authentication/PasswordSchemes.
The following parameters can be defined along the other keys of each entry of the
SOGoUserSources, but can also defined at the domain and/or system levels :
To ensure proper performance of the SOGo application, the following LDAP attributes must be
fully indexed :
❏ givenName
❏ cn
❏ mail
❏ sn
Please refer to the documentation of the software you use in order to index those attributes.
Some LDAP attributes are mapped to contacts attributes in the SOGo UI. The table below list
most of them. It is possible to override these by using the mapping configuration parameter.
For example, if the LDAP schema uses the fax attribute to store the fax number, one could map
it to the facsimiletelephonenumber attribute like this:
mapping = {
};
Name
First givenName
Last sn
DisplayName displayName or cn or givenName + sn
Nickname mozillanickname
Internet
Email mail
Secondary email mozillasecondemail
ScreenName nsaimid
Phones
Work telephoneNumber
Home homephone
Mobile mobile
Fax facsimiletelephonenumber
Pager pager
Home
Address mozillahomestreet + mozillahomestreet2
City mozillahomelocalityname
State/Province mozillahomestate
Zip/Postal Code mozillahomepostalcode
Country mozillahomecountryname
Web page mozillahomeurl
Work
Title title
Department ou
Address street + mozillaworkstreet2
City l
State/Province st
Zip/Postal code postalCode
Web page mozillaworkurl
Other
Birthday birthyear-birthmonth-birthday
Note description
SOGo natively supports C.A.S. authentication. For activating C.A.S. authentication you need
first to make sure that the SOGoAuthenticationType setting is set to “cas” and that the
SOGoCASServiceURL setting is configured appropriately.
The tricky part shows up when using SOGo as a frontend interface to an IMAP server as this
imposes constraints needed by the C.A.S. protocol to ensure secure communication between
the different services. Failing to take those precautions will prevent users from accessing their
mails, while still granting basic authentication to SOGo itself.
The first constraint is that the amount of workers that SOGo uses must be higher than 1 in
order to enable the C.A.S. service to perform some validation requests during IMAP
authentication. A single worker alone would not, by definition, be able to respond to the C.A.S.
requests while treating the user request that required the triggering of those requests. You must
therefore configure the WOWorkersCount setting appropriately.
The second constraint is that the SOGo service must be accessible and accessed via https.
Moreover, the certificate used by the SOGo server has to be recognized and trusted by the
C.A.S. service. In the case of a certificate issued by a third-party authority, there should be
nothing to worry about. In the case of a self-signed certificate, the certificate must be registered
in the trusted keystore of the C.A.S. application. The procedure to achieve this can be
summarized as importing the certificate in the proper “keystore” using the keytool utility and
specifying the path for that keystore to the Tomcat instance which provides the C.A.S. service.
This is done by tweaking the javax.net.ssl.trustStore setting, either in the
catalina.properties file or in the command-line parameters. On debian, the SOGo certificate can
also be added to the truststore as follows:
The certificate used by the CAS server must also be trusted by SOGo. In case of a self-signed
certificate, this means exporting tomcat's certificate using the keytool utility, converting it to
PEM format and appending it to the ca-certificates.crt file. (The name and location of that file
differs between distributions). Basically:
If any of those constraints is not satisfied, the webmail interface of SOGo will display an empty
email account. Unfortunately, SOGo has no possibility to detect which one is the cause of the
problem. The only indicators are log messages that at least pinpoint the symptoms:
Such an error will show up during authentication of the user to SOGo. It happens when the
authentication service has accepted the user authentication ticket but has not returned a “Proxy
Granting Ticket”.
This error indicate that an attempt was made to retrieve an authentication ticket for a third-party
service such as IMAP or sieve. Most of the time, this happens as a consequence to the problem
described above. To troubleshoot these issues, one should be tailing cas.log, pam logs and sogo
logs.
Currently, SOGo will ask for a CAS ticket using the same CAS service name for both IMAP and
Sieve. When CASifying sieve, this means that the -s parameter of pam_cas should be the
same for both IMAP and Sieve, otherwise the CAS server will complain :
Finally, when using imapproxy to speed up the imap accesses, the SOGoIMAPCASServiceName
should be set to the actual imap service name expected by pam_cas, otherwise it will fail to
authenticate incoming connection properly.
SOGo natively supports SAML2 authentication. Please refer to the documentation of your
identity provider and the SAML2 configuration keys that are listed above for proper setup. Once
a SOGo instance is configured properly, the metadata for that instance can be retrieved from
http://<hostname>/SOGo/saml2-metadata for registration with the identity provider.
In order to relay authentication information to your IMAP server and if you make use of the
CrudeSAML SASL plugin, you need to make sure that “NGImap4AuthMechanism” is configured
to use the SAML mechanism. If you make use of the CrudeSAML PAM plugin, this value may be
left empty.
Database Configuration
SOGo requires a relational database system in order to store appointments, tasks and contacts
information. It also uses the database system to store personal preferences of SOGo users. In this
guide, we assume you use PostgreSQL so commands provided the create the database are
related to this application. However, other database servers are supported, such as MySQL and
Oracle.
First, make sure that your PostgreSQL server has TCP/IP connections support enabled.
Create the database user and schema using the following commands :
su – postgres
createuser --no-superuser --no-createdb –-no-createrole \
–-encrypted --pwprompt sogo
(specify “sogo” as password)
createdb -O sogo sogo
You should then adjust the access rights to the database. To do so, modify the configuration file
/var/lib/pgsql/data/pg_hba.conf in order to add the following line at the very beginning
of the file:
Once added, restart the PostgreSQL database service. Then, modify the SOGo configuration file
(/etc/sogo/sogo.conf) to reflect your database settings :
SOGoProfileURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
OCSFolderInfoURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
D SOGoProfileURL Parameter used to set the database URL so that SOGo can
retrieve user profiles.
For MySQL, set the database URL to something like :
mysql://sogo:sogo@localhost:3306/sogo/sogo_user_p
rofile
D OCSFolderInfoURL Parameter used to set the database URL so that SOGo can
retrieve the location of user folders (address books and
calendars)
For Oracle, set the database URL to something like :
oracle://sogo:sogo@localhost:1526/sogo/sogo_folde
r_info
D OCSSessionsFolderURL Parameter used to set the database URL so that SOGo can
store and retrieve secured user sessions information. For
PostgreSQL, the database URL could be set to something
like :
postgresql://sogo:sogo@localhost:5432/sogo/sogo_s
essions_folder
D OCSEMailAlarmsFolderURL Parameter used to set the database URL for email-based
alarms (that can be set on events and tasks). This parameter is
relevant only if SOGoEnableEMailAlarms is set to YES. For
PostgreSQL, the database URL could be set to something
like :
postgresql://sogo:sogo@localhost:5432/sogo/sogo_a
larms_folder
If you're using MySQL, make sure in your my.cnf file you have :
[mysqld]
...
character_set_server=utf8
character_set_client=utf8
[client]
default-character-set=utf8
[mysql]
default-character-set=utf8
and when you create the SOGo database, you correctly specify the charset :
SOGo can use a SQL-based database server for authentication. The configuration is very similar
to LDAP-based authentication.
The following table describes all the possible parameters related to a SQL source :
D SOGoUserSources Parameter used to set the SQL and/or LDAP sources used for
authentication and global address books. Multiple sources can
be specified as an array of dictionaries. A dictionary that
defines a SQL source can contain the following values :
type the type of this user source, set to sql for a SQL source
id the identification name of the SQL repository. This must be
unique – even when using multiple domains.
viewURL database URL of the view used by SOGo. The view expects
columns to be present. Required columns are :
• c_uid : will be used for authentication – it's a username
or [email protected]
• c_name : will be used to uniquely identify entries – which
can be identical to c_uid
• c_password : password of the user, plain text, crypt, md5
or sha encoded
• c_cn : the user's common name
• mail : the user's email address
Other columns can exist and will actually be mapped
automatically if they have the same name as popular LDAP
attributes (such as givenName, sn, department, title,
telephoneNumber, etc.)
userPasswordAlgorithm The default algorithm used for password encryption when
changing passwords.
Possible values are: none, plain, crypt, md5, md5-crypt,
smd5, cram-md5, ldap-md5, and sha, sha256, sha512 and
its ssha (e.g. ssha or ssha256) variants. Passwords can have
the scheme prepended in the form
{scheme}encryptedPass.
If no scheme is given, userPasswordAlgorithm is used
instead. The schemes listed above follow the algorithms
described in
http://wiki.dovecot.org/Authentication/PasswordSchemes.
Note that cram-md5 is not actually using cram-md5 (due to
the lack of challenge-response mechanism), its
just saving the intermediate MD5 context as Dovecot stores
in its database.
prependPasswordScheme The default behaviour is to store newly set passwords
without the scheme (default: prependPasswordScheme =
NO) .
This can be overridden by setting prependPasswordScheme
to YES and will result in passwords stored as
{scheme}encryptedPass.
canAuthenticate if set to YES, this SQL source is used for authentication
isAddressBook if set to YES, this SQL source is used as a shared address
book (with read-only access)
authenticationFilter a filter that limits which users can authenticate from this
(optional) source
displayName (optional) if set as an address book, the human identification name of
the SQL repository
LoginFieldNames (optional) an array of fields that specifies the column names that
contain valid authentication usernames (defaults to c_uid
when unset)
MailFieldNames (optional) an array of fields that specifies the column names that hold
additional email addresses (beside the mail column) for
each user
IMAPHostFieldName the field that returns the IMAP hostname for the user
(optional)
IMAPLoginFieldName the field that returns the IMAP login name for the user
(optional) (defaults to c_uid when unset)
SieveHostFieldName the field that returns the Sieve hostname for the user
(optional)
KindFieldName (optional) if set, SOGo will try to determine if the value of the field
corresponds to either “group”, “location” or “thing”. If
that's the case, SOGo will consider the returned entry to be
a resource.
MultipleBookingsFieldNam The value of this field is the maximum number of
e (optional) concurrent events to which a resource can be part of at any
point in time.
SOGoUserSources =
(
{
type = sql;
id = directory;
viewURL = "postgresql://sogo:[email protected]:5432/sogo/sogo_view";
canAuthenticate = YES;
isAddressBook = YES;
userPasswordAlgorithm = md5;
}
);
SOGo makes use of a SMTP server to send emails from the Web interface, iMIP/iTIP messages
and various notifications.
SOGo requires an IMAP server in order to let users consult their email messages, manage their
folders and more.
The following additional parameters only affect the Web interface behaviour of SOGo.
(not currently editable in Web interface) the columns from the SOGo webmail interface.
The parameter is an array, for example :
SOGoMailListViewColumnsOrder =
(Flagged, Attachment, Priority, From,
Subject, Unread, Date, Size);
D SOGoVacationEnabled Parameter used to activate the edition from the
preferences window of a vacation message.
Requires Sieve script support on the IMAP host.
Defaults to NO when unset.
• once_per_hour
Defaults to manually when unset.
D SOGoMailAuxiliaryUserAccountsEnabled Parameter used to activate the auxiliary IMAP
accounts in SOGo. When set to YES, users can
add other IMAP accounts that will be visible
from the SOGo Webmail interface.
Defaults to NO when unset.
U SOGoDefaultCalendar Parameter used to specify which calendar is
used when creating an event or a task. Possible
values are :
• selected
• personal
• first
Defaults to selected when unset.
U SOGoDayStartTime The hour at which the day starts (0 through 12).
Defaults to 8 when unset.
U SOGoDayEndTime The hour at which the day ends (12 through
23).
Defaults to 18 when unset.
U SOGoFirstDayOfWeek The day at which the week starts in the week
and month views (0 through 6). 0 indicates
Sunday.
Defaults to 0 when unset.
U SOGoFirstWeekOfYear Parameter used to defined how is identified the
first week of the year. Possible values are :
• January1
• First4DayWeek
• FirstFullWeek
Defaults to January1 when unset.
U SOGoTimeFormat The format used to display time in the timeline
of the day and week views. Please refer to the
documentation for the date command or the
strftime C function for the list of available
format sequence.
Defaults to %H:%M.
U SOGoCalendarCategories Parameter used to define the categories that can
be associated to events. This parameter is an
array of arbitrary strings.
Defaults to a list that depends on the language.
U SOGoCalendarDefaultCategoryColor Parameter used to define the default colour of
categories.
Defaults to #F0F0F0 when unset.
U SOGoCalendarEventsDefaultClassification Parameter used to defined the default
classification for new events. Possible values
are :
• PUBLIC
• CONFIDENTIAL
• PRIVATE
Defaults to PUBLIC when unset.
U SOGoCalendarTasksDefaultClassification Parameter used to defined the default
classification for new tasks. Possible values
are :
• PUBLIC
• CONFIDENTIAL
• PRIVATE
Defaults to PUBLIC when unset.
D SOGoFreeBusyDefaultInterval The number of days to include in the free busy
information. The parameter is an array of two
numbers, the first being the number of days
prior to the current day and the second being
the number of days following the current day.
Defaults to (7, 7) when unset.
U SOGoBusyOffHours Parameter used to specify if off-hours should be
automatically added to the free-busy
information. Off hours included weekends and
periods covered between SOGoDayEndTime
and SOGoDayStartTime.
Defaults to NO when unset.
U SOGoMailMessageForwarding The method the message is to be forwarded.
Possible values are :
• inline
• attached
Defaults to inline when unset.
U SOGoMailCustomFullName The string to use as full name when composing
an email, if SOGoMailCustomFromEnabled is
set in the user's domain defaults. When unset,
the full name specified in the user sources for
the user is used instead.
U SOGoMailCustomEmail The string to use as email address when
composing an email, if
SOGoMailCustomFromEnabled is set in the
user's domain defaults. When unset, the email
specified in the user sources for the user is used
instead.
U SOGoMailReplyPlacement The reply placement with respect to the quoted
message. Possible values are :
• above
• below
Defaults to below.
U SOGoMailReplyTo The email address to use in the “reply-to”
header field when the user sends a message.
Ignored when empty.
The complete SOGo configuration file /etc/sogo/sogo.conf should look like this :
{
SOGoProfileURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
OCSFolderInfoURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
SOGoAppointmentSendEMailNotifications = YES;
SOGoCalendarDefaultRoles = (
PublicViewer,
ConfidentialDAndTViewer
);
SOGoLanguage = English;
SOGoMailDomain = acme.com;
SOGoDraftsFolderName = Drafts;
SOGoIMAPServer = localhost;
SOGoUserSources = (
{
type = ldap;
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
baseDN = "ou=users,dc=acme,dc=com";
bindDN = "uid=sogo,ou=users,dc=acme,dc=com";
bindPassword = qwerty;
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = localhost;
id = public;
isAddressBook = YES;
port = 389;
}
);
SOGoMailingMechanism = smtp;
SOGoSMTPServer = 127.0.0.1;
SOGoSentFolderName = Sent;
SOGoTimeZone = America/Montreal;
SOGoTrashFolderName = Trash;
}
Multi-domains Configuration
If you want your installation to isolate two groups of users, you must define a distinct
authentication source for each domain. Following is the same configuration that now includes
two domains (acme.com and coyote.com) :
{
SOGoProfileURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
OCSFolderInfoURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
SOGoAppointmentSendEMailNotifications = YES;
SOGoCalendarDefaultRoles = (
PublicViewer,
ConfidentialDAndTViewer
);
SOGoLanguage = English;
SOGoMailingMechanism = smtp;
SOGoSMTPServer = 127.0.0.1;
SOGoSentFolderName = Sent;
SOGoTimeZone = America/Montreal;
SOGoTrashFolderName = Trash;
SOGoIMAPServer = localhost;
domains = {
acme = {
SOGoMailDomain = acme.com;
SOGoDraftsFolderName = Drafts;
SOGoUserSources = (
{
type = ldap;
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
baseDN = "ou=users,dc=acme,dc=com";
bindDN = "uid=sogo,ou=users,dc=acme,dc=com";
bindPassword = qwerty;
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = localhost;
id = public_acme;
isAddressBook = YES;
port = 389;
}
);
};
coyote = {
SOGoMailDomain = coyote.com;
SOGoIMAPServer = imap.coyote.com;
SOGoUserSources = (
{
type = ldap;
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
baseDN = "ou=users,dc=coyote,dc=com";
bindDN = "uid=sogo,ou=users,dc=coyote,dc=com";
bindPassword = qwerty;
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = localhost;
id = public_coyote;
isAddressBook = YES;
port = 389;
}
);
};
};
}
The following additional parameters only affect SOGo when using multiple domains.
Apache Configuration
Upon SOGo installation, a default configuration file is created which is suitable for most
configurations.
You must also configure the following parameters in the SOGo configuration file for Apache in
order to have a working installation :
You may consider enabling SSL on top of this current installation to secure access to your SOGo
installation.
You might also have to adjust the configuration if you have SELinux enabled.
The default configuration will use mod_proxy and mod_headers to relay requests to the sogod
parent process. This is suitable for small to medium deployments.
Starting Services
Once SOGo if fully installed and configured, start the services using the following command :
You may verify using the chkconfig command that the SOGo service is automatically started
at boot time. Restart the Apache service since modules and configuration files were added :
Finally, you should also make sure that the memcached service is started and that it is also
automatically started at boot time.
SOGo allows you to set email-based reminders for events and tasks. To enable this, you must
enable the SOGoEnableEMailAlarms preference and set the OCSEMailAlarmsFolderURL
preference accordingly.
Once you've correctly set those two preferences, you must create a cronjob that will run under
the “sogo” user. This cronjob should be run every minute.
A commented out example should have been installed in /etc/cron.d/sogo, to enable it,
simply uncomment it.
* * * * * /usr/sbin/sogo-ealarms-notify
When vacation messages are enabled (see the parameter “SOGoVacationEnabled”), users can
set an expiration date to messages auto-reply. For this feature to work, you must run a cronjob
under the “sogo” user.
A commented out example should have been installed in /etc/cron.d/sogo. To enable it, set
the authname and authpassword parameters to the credentials of a sieve administrator and
uncomment it.
First, create the SOGo administrative account in your LDAP server. The following LDIF file
(sogo.ldif) can be used as an example :
dn: uid=sogo,ou=users,dc=acme,dc=com
objectClass: top
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
uid: sogo
cn: SOGo Administrator
mail: [email protected]
sn: Administrator
givenName: SOGo
Load the LDIF file inside your LDAP server using the following command :
Finally, set the password (to the value “qwerty”) of the SOGo administrative account using the
following command :
SOGo uses LDAP directories to authenticate users. Use the following LDIF file (jdoe.ldif) as
an example to create a SOGo user account :
dn: uid=jdoe,ou=users,dc=acme,dc=com
objectClass: top
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
uid: jdoe
cn: John Doe
mail: [email protected]
sn: Doe
givenName: John
Load the LDIF file inside your LDAP server using the following command :
Finally, set the password (to the value “qwerty”) of the SOGo administrative account using the
following command :
As an alternative to using command-line tools, you can also use LDAP editors such as Luma or
Apache Directory Studio to make your work easier. These GUI utilities can make use of
templates to create and pre-configure typical user accounts or any standardized LDAP record,
along with the correct object classes, fields and default values.
7 Funambol
The Funambol middleware allows you to synchronize mobile devices with SOGo through the
use of the Funambol SOGo Connector. The connector allows any SyncML enabled devices to
fully synchronize contacts, events and tasks with SOGo.
First of all, install and configure Funambol v10.0.3 – which can be found from
http://sourceforge.net/projects/funambol/files/bundle/v10/. We suppose Funambol was installed
in /opt/Funambol.
/opt/Funambol/bin/funambol.sh stop
/opt/Funambol/tools/tomcat/lib/
The Funambol SOGo Connector currently supports only MySQL, Oracle and PostgreSQL. You
can download the jar file for PostgreSQL from http://jdbc.postgresql.org/. For Oracle, please
refer to the following site :
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc_10201.html and
download the ojdbc14.jar file. For MySQL, please refer to the following site :
http://dev.mysql.com/usingmysql/java/
/opt/Funambol/tools/tomcat/lib/
/opt/Funambol/ds-server/modules
/opt/Funambol/bin/funambol start
Next, install the Funambol SOGo Connector within Funambol server by issuing the following
commands :
cd /opt/Funambol/
./bin/install-modules
Then, configure the data sources for SOGo. To do so, start the Funambol Administration Tool
using the following command :
/opt/Funambol/admin/bin/funamboladmin
Log in.
Go in Modules > sogo > FunambolSOGoConnector > SOGo SyncSource and add a source for
each data type you would like to synchronize. For example, to synchronize an address book,
you would specify:
You can then do the same (and specify the same database connection information) for events
and tasks using sogo-cal and sogo-todo as sync source names and URI.
If you want to auto-create Funambol user accounts for every users that can authenticate to
SOGo, you can use the SOGoOfficer to do so. From the Funambol Administration Tool, in
"Server Settings", set the Officer to the following value :
ca/inverse/sogo/security/SOGoOfficer.xml
/opt/Funambol/config/ca/inverse/sogo/security/SOGoOfficer.xml
change the host property to the host name value of your SOGo server. Change the port property
to the port value of your sogod daemon. No server restart is required. In our example, the file
would look like :
8 Using SOGo
To acces the SOGo Web Interface, point your Web browser, which is running from the same
server where SOGo was installed, to the following URL : http://localhost/SOGo
Log in using the “jdoe” user and the “qwerty” password. The underlying database tables will
automatically be created by SOGo.
Alternatively, you can access SOGo with a GroupDAV and a CalDAV client. A typical well-
integrated setup is to use Mozilla Thunderbird and Mozilla Lightning along with Inverse's SOGo
Connector plug in to synchronize your address books and the Inverse's SOGo Integrator plug in
to provide a complete integration of the features of SOGo into Thunderbird and Lightning. Refer
to the documentation of Thunderbird to configure an initial IMAP account pointing to your
SOGo server and using the user name and password mentioned above.
With the SOGo Integrator plug in, your calendars and address books will be automatically
discovered when you login in Thunderbird. This plug in can also propagate specific extensions
and default user settings among your site. However, be aware that in order to use the SOGo
Integrator plug in, you will need to repackage it with specific modifications. Please refer to the
documentation published online:
http://www.sogo.nu/downloads/documentation.html.
If you only use the SOGo Connector plug in, you can still easily access your data.
❏ Click on OK.
Apple iCal
To configure it so it works with SOGo, create a new account and specify, as the Account URL,
an URL such as :
http://localhost/SOGo/dav/jdoe/
Apple AddressBook
Since Mac OS X 10.6 (Snow Leopard), Apple AddressBook can be configured to use SOGo.
In order to make this work, you must add a new virtual host in your Apache configuration file to
listen on port 8800 and handle requests coming from iOS devices.
<VirtualHost *:8800>
RewriteEngine Off
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:20000/SOGo/dav/ interpolate
ProxyPass /SOGo http://127.0.0.1:20000/SOGo interpolate
ProxyPass / http://127.0.0.1:20000/SOGo/dav/ interpolate
<Location />
Order allow,deny
Allow from all
</Location>
<Proxy http://127.0.0.1:20000>
RequestHeader set "x-webobjects-server-port" "8800"
RequestHeader set "x-webobjects-server-name" "acme.com:8800"
RequestHeader set "x-webobjects-server-url" "http://acme.com:8800"
RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
AddDefaultCharset UTF-8
</Proxy>
ErrorLog /var/log/apache2/ab-error.log
CustomLog /var/log/apache2/ab-access.log combined
</VirtualHost>
This configuration is also required if you want to configure a CardDAV account on a Apple iOS
device (version 4.0 and later).
You can synchronize contacts, events and tasks from SOGo with any mobile devices that
support SyncML.
Your Funambol server needs to be accessible from outside of your internal network as
synchronization happens over the air (“OTA”).
Once you've made your server visible from the Internet, please specify the following URL in
your SyncML client:
http://<external IP address>:8080/funambol/ds
The user name / password is the same as the one you can use to log in SOGo.
For more details on mobile devices, such as Apple iPhone, please refer to the SOGo Mobile
Devices – Installation and Configuration guide available from http://www.sogo.nu.
9 Upgrading
This section describes what needs to be done when upgrading to the current version of SOGo
from the previous release.
2.0.5
The configuration is now stored in /etc/sogo/sogo.conf. Perform the following commands as
root to migrate your previous user defaults:
2.0.4
The parameter SOGoForceIMAPLoginWithEmail is now deprecated and is replaced by
SOGoForceExternalLoginWithEmail (which extends the functionality to SMTP
authentication). Update your configuration if you use this parameter.
The sogo user is now a system user. For new installs, this means that “su - sogo“ won't work
anymore. Please use “sudo -u sogo <cmd>” instead. If used in scripts from cronjobs,
requiretty must be disabled in sudoers.
1.3.17
Run the shell script sql-update-1.3.16_to_1.3.17.sh or sql-update-
1.3.16_to_1.3.17-mysql.sh (if you use MySQL).
This will grow the “cycle info” field of calendar tables to a larger size.
1.3.12
Once you have updated and restarted SOGo, run the shell script sql-update-
1.3.11_to_1.3.12.sh or sql-update-1.3.11_to_1.3.12-mysql.sh (if you use
MySQL).
This will grow the “content” field of calendar and addressbook tables to a larger size and fix
the primary key of the session table.
1.3.9
For Red Hat-based distributions, version 1.23 of GNUstep will be installed. Since the location
of the Web resources changes, the Apache configuration file (SOGo.conf) has been adapted.
Verify your Apache configuration if you have customized this file.
10 Additional Information
For more information, please consult the online FAQs (Frequently Asked Questions) :
http://www.sogo.nu/english/support/faq.html
You can also read the mailing archives or post your questions to it. For details, see :
https://inverse.ca/sogo/lists
Inverse (http://inverse.ca) offers professional services around SOGo and Funambol to help
organizations deploy the solution and migrate from their legacy systems.