.dockerignore | ||
.gitignore | ||
docker-compose.yml | ||
Dockerfile | ||
LICENSE.TXT | ||
nginx.conf | ||
README.md | ||
sogo.default.conf | ||
SOGoInstallationGuide.pdf |
What is SOGo ?
SOGo (formerly named Scalable OpenGroupware.org) is an open source collaborative software (groupware) server with a focus on simplicity and scalability. It is developed in Objective-C using PostgreSQL, Apache, and IMAP.
SOGo provides collaboration for Mozilla Thunderbird/Lightning, Microsoft Outlook, Apple iCal/iPhone and BlackBerry client users. Its features include the ability to share calendars, address books and e-mail using an open source, cross-platform environment. The Funambol middleware and the Funambol SOGo Connector allow SyncML clients to synchronize contacts, events and tasks.
SOGo supports standard groupware capabilities including CalDAV, CalDAV auto-scheduling, CardDAV, WebDAV Sync, WebDAV ACLs, and iCalendar.
Microsoft Outlook support is provided through an OpenChange storage provider to remove the MAPI dependency for sharing address books, calendars and e-mails. Native connectivity to Microsoft Outlook allows SOGo to emulate a Microsoft Exchange server to Outlook clients.
(source : Wikipedia contributors, "SOGo," Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=SOGo&oldid=731475399 (accessed August 5, 2016). )
Use with care and contribute to Inverse Inc
This image is in use in a organization of 80 people, without any known problem (except when we migrated from 2.3 to 3.2, see above).
Since July 2016, Inverse Inc. ask for some support to provide debian packages. This should help them to increase their investments in SOGo. If you can afford this, you should consider getting support on Inverse Inc.
How to use this image
This image requires :
- a working IMAP and SMTP server (not provided under docker container) ;
- a postgresql / mysql database ;
- memcached ;
- some way to authenticate user: LDAP, SQL table, ... (see the docs)
- a configuration file
This container only execute the sogod
process, taking into account the best practice "running one process per container".
In order to run it You should create an adapt a config file to your needs, using the docs. This file should be recorded into the container as /etc/sogo/sogo.conf
.
Using the command line
TO BE DONE
Using docker-compose
This is a docker-compose.yml
file you could adapt to launch this image :
version: '2'
services:
sogo:
# if you prefer building by yourself
build:
context: .
args:
# replace by your desired version
version: x.x.x
# if you prefer using a pre-built image (replace by your desired version)
# image: julienfastre/sogo:x.x
links:
- db
volumes:
# replace by your own file
- /path/to/your/file/sogo.conf:/etc/sogo/sogo.conf
db:
image: postgres:9.5
# for debug purpose only: reach the database from outside
#ports:
# - "5432"
memcached:
image: memcached:1.4-alpine
nginx:
image: nginx
links:
- sogo
volumes_from:
- sogo:ro
ports:
- "8080:80"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
You should then be able to reach sogo on http://localhost:8080/SOGo.
Warning after login, the redirection does not work and you will reach http://localhost/SOGo/ instead of http://localhost:8080/SOGo/. Simply add the missing port part.
How to build this image
The parameter version
is required to build this image.
Example of how to build this image :
# download sources
$ git clone https://framagit.org/julienfastre/docker-sogo.git
$ cd docker-sogo
# launch the build using the version 3.1.5
$ docker build --build-arg version=3.1.5 .
migrating from 2.3 to 3.1|3.2 using docker-compose
The assets (css, js, ...) are contained in a volume. Those assets are completely different from version 2.3 to version 3.1 and 3.2. If you used docker-compose
and migrated from 2.3 to 3.2, you have to remove the volume containing those assets, to let a clean place for the asset for the new version.