Planet

Subscribe to the RSS feed of this planet! RSS
grote's picture
Tue, 2014-07-22 11:35

With development still in full swing, we are getting closer to a feature freeze and a first beta version of Kolab.org 3.3. In the last weeks, we already shared some details about the new features that will be part of this upcoming Kolab.org version. There will be improved Folder Management and a Calendar Quickview as well as Notes and Accessibility improvements. Now it is time to present two more exciting features that will be part of Kolab.org 3.3.

Pease keep in mind that work is not yet done and that this is only a sneak preview. We hope to have something packaged and ready for you to try out soon!

Email Tags

Tags are little labels that you can attach to objects to categorize them or to find them quicker. We introduced tags with our task module and are now expanding the concept to emails.

You can add tags to email messages and remove them again. The tags can have different colors and are shown prominently in the message list. In the bottom left corner, below the folder list, there is now a tag cloud where you can select tags, so only emails with those tags are shown.

For those interested in the technical details of the the tag implementation, there is a discussion on our format mailing list. In short: A tag is a Kolab Configuration Object of the type 'relation' that stores all tag information and the relation to certain messages. We also considered using IMAP flags, but decided against it for now.

In the future, the new 'kolab_tags' plugin might provide tag handling capabilities to all other plugins that can make use of tags such as calendar, tasklist, notes, etc. The format was already designed in a way that allows for storing relations between any object type.

Resource Management

With Kolab you can also manage resources like cars, presenters or meeting rooms in your organization. People can book resources themselves, if they are available. This ensures that no two groups want to use a meeting room at the same time.

To make this easier, we added a dedicated resource selection dialog as you can see on the right. The new dialog allows you to search and browse through the available resources. It displays additional information and attributes for the individual resources as well as an availability calendar based on the free-busy data published for the given resource.

The automated processing of iTip messages (invitations) to resources was refactored and now supports the fully automated resource booking and updating through the iTip protocol. It wil also be possible to define a booking policy for the resources that for example automatically accepts or refuses booking based on certain criteria.

Multiple resource of the same kind can be organized in resource collections (e.g. company cars). If someone wants to book "a car", she books the resource collection for her appointment. The Wallace module then allocates a concrete resource from that collection and delegates the booking to the next available resource. The delegation is reflected in the iTip replies and the updated user calendar.

 

There will be many various small improvements to the webclient and under the hood, but we will leave it to you to discover those on your own. This means that this will be the last feature presentation. We hope you enjoyed it!


roundcube's picture
Sun, 2014-07-20 09:00

This is the second service release to update the stable version 1.0. It contains some bug fixes and improvements we considered important for the long term support branch of Roundcube.

It’s considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from roundcube.net/download, see the full changelog here.

Please do backup before updating!


grote's picture
Tue, 2014-07-15 16:28

Last time, we already talked about some new features that are coming with Kolab.org 3.3. Now, we will show you more features we are currently working on. Like last time, this is still work in progress. It is not ready and not packaged for you to try out just yet.

Still, there's more features to come and another post will follow soon. Stay tuned and monitor this channel for more updates.

Notes

Often you just want to note something down real quick. Today, we often use computers for that to have our notes available on all our devices everywhere and searchable.

Currently, it is only possible to work with notes using the Kolab Desktop Client. With Kolab.org 3.3 you will also be able to work with these notes in the webclient. As with all things Kolab, you can also have multiple notebooks and share them with people. The screenshot on the right shows the current state of development and as you can see it already uses the new folder management in the bottom left corner.

The notes are automatically synchronized with the Kolab Desktop Client and you will also be able to synchronize them to your mobile devices via the ActiveSync protocol.

Notes can be tagged just like tasks and they can have rich-text content including graphics. They can be printed right from the webclient and also sent via email.

In the email view, you can add little notes to emails. It will be possible to view and edit your notes before appending them to email messages. If you have notes linked with an email, they are listed at the top of the email preview, like you can see here:

Accessibility improvements

We reviewed and improved our entire web client regarding the accessibility for people that require assistive technologies. The user interface can now be fully operated with the keyboard and has support for screen readers as well as voice output as suggested by the  WCAG 2.0 Guidelines and ​WAI ARIA standards.

As an example, for the email view you are now able to tab through all the button elements, operate the message list and the popup menus. Once the message list gains focus, the arrow keys move the cursor while <space> selects the row and <enter> opens the message. A descriptive block explaining the list navigation was added to the page, so screen readers can pick it up.

All these improvements will make it a lot easier for people that require assistive technologies to use the Kolab webclient. They will also benefit the millions of Roundcube users out there as we strictly bring all our modifications back to the upstream communities.

We hope you enjoyed this quick tour through some of the new Kolab features and are excited about what we will reveal next time.


grote's picture
Wed, 2014-07-09 16:04

The last Kolab.org release was at Valentine's day. So according to our release schedule, the next version should be ready in August. In the past months, we have not been very good at keeping you updated about what we are working on. This is going to change now, because we have made good progress and now finally have something to show.

Please keep in mind that what you are going to see is still work in progress. It is not ready and not packaged for you to try out just yet. Think of it as a first sneak preview of what is going to be Kolab.org 3.3. More will follow. Stay tuned and monitor this channel for more updates.

Folder Management

Internally, all address books, calendars, task lists, etc. are folders. So far, we did not hide that fact well from users. When you wanted to show a folder that you were not subscribed to, you had to go through the folder management that listed all folders equally.

Say hi to the new folder management mechanism we came up with! With Kolab's new folder navigation, shared calendars, address books and task lists can be searched and subscribed to directly from within the respective view. The search box allows you to find "folders" that are shared with you. Searches are also expanded to LDAP, so that search results show folders grouped by matching users. When selecting a "folder" from the search results, your selection can be temporary and affect only the current session or permanently if you always want to see that calendar for example.

Some users spread their events over many calendars (one per team for example) and you might not be interested in the distinction they made. So you have the option to show a "virtual user calendar" that represents an aggregated view on "a user's calendar" and that can be subscribed to as well.

Calendar Quickview

The calendar got a quickview mode which allows you to open an undistorted view on a single calendar without unchecking all other calendars from the main view.

When opening the quickview for a "virtual user calendar" (see above), the calendar view displays events from all calendars of that user you have access to. Additionally, it also shows time blocks from anonymized free/busy information where you only know that the user is unavailable during these times.

Together with the new folder navigation, this new feature makes it even more easy to quickly check whether a certain workmate is available for a phone call or lunch.

We hope you enjoyed this quick tour through two of Kolab's new features and are excited for what more is going to come.


Tue, 2014-07-08 00:00

I have spent some time this weekend investigating SSL certificate-based authentication and implementing it in Kolab web-based user interface.

This topic is very interesting, but definitely too broad to be briefly described in a single blog post, so do not look at it as complete solution, but treat it only as a proof of concept.

Table of contents

Certification Authority

Apache

Kolab - Web-based user interface

Notes

Prepare Certification Authority

At first you need to create Certification Authority on an off-line, and secured system.

I have already created required shell scripts (miniature-octo-ca) to ease the whole operation, so just clone the following repository and move it to the CA system.

$ git clone https://github.com/milosz/miniature-octo-ca.git
Cloning into 'miniature-octo-ca'...
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 10 (delta 2), reused 10 (delta 2)
Unpacking objects: 100% (10/10), done.

Please remember to change working directory before executing any available shell script.

$ cd miniature-octo-ca

Configure Certification Authority

The next step is to configure CA by using common-ca-settings.sh configuration file.

$ vi common-ca-settings.sh 
#!/bin/sh
# common CA settings 

# simple protection - every script can be executed only from current directory
if [ "$(pwd)" != "$(dirname $(readlink -f  $0))" ]; then
  echo "Do not run CA scripts from outside of $(dirname $(readlink -f  $0)) directory"
  exit
fi

# ensure proper permissions by setting umask
umask 077

# kolab secret
# use 'openssl rand -hex 16' command to generate it
kolab_secret="d2d97d097eedb397edea79f52b56ea74"

# key length
key_length=4096

# certificates directory
cert_directory="root-ca"

# number of days to certify the certificate
cert_validfor=3650        # root   certificate
client_cert_validfor=365  # client certificate
server_cert_validfor=365  # server certificate

# default certificate settings
cert_country="PL"
cert_organization="example.org"
cert_state="state"
cert_city="city"
cert_name="example.org CA"
cert_unit="Certificate Authority"
cert_email=""

# certificate number
if [ -f "${cert_directory}/serial" ]; then
  serial=$(cat ${cert_directory}/serial)
fi

You need to modify kolab_secret variable, as it will be used as a key to encrypt/decrypt user password, and common certificate settings to match your setup.

Initialize Certification Authority

Execute prepare_ca.sh shell script to build initial configuration and directory layout.

$ sh prepare_ca.sh 

You can inspect generated OpenSSL configuration (openssl.cnf file) and tune it a bit.

Create root certificate

Execute create_ca.sh shell script to create root certificate and private key.

$ sh create_ca.sh 
Root certificate (private key) password: Generating a 4096 bit RSA private key
............................................................................++
.........................++
writing new private key to 'root-ca/ca/root-key.pem'
-----
No value provided for Subject Attribute emailAddress, skipped

Root certificate and private key will be stored inside root-ca/ca/ directory.

$ ls root-ca/ca/
root-cert.pem  root-key.pem

Create server certificate

Execute add_server.sh shell script to create new server certificate.

$ sh add_server.sh 
Server name (eg. mail.example.com): mail.example.org
Email: admin@example.org
Root certificate (private key) password: 
Server certificate (private key) password: 
Generating a 4096 bit RSA private key
.........++++++
...................++++++
writing new private key to 'root-ca/private/01.pem'
-----
Using configuration from openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Jul  6 12:51:12 2014 GMT
            Not After : Jul  6 12:51:12 2015 GMT
        Subject:
            countryName               = PL
            stateOrProvinceName       = state
            organizationName          = example.org
            organizationalUnitName    = Certificate Authority
            commonName                = mail.example.org
            emailAddress              = admin@example.org
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                EA:3E:05:51:EE:C2:90:53:58:91:E8:D5:56:47:15:7D:5A:26:E8:C4
            X509v3 Authority Key Identifier: 
                keyid:A1:41:B0:72:60:29:1A:9B:B1:63:77:53:E7:93:71:1D:02:14:A4:7C

Certificate is to be certified until Jul  6 12:51:12 2015 GMT (365 days)

Write out database with 1 new entries
[..]
Data Base Updated
writing RSA key

Server certificate and private key (with password removed) will be stored inside root-ca/server_certs/ directory.

$ ls root-ca/server_certs/
01.crt  01.pem

Create client certificate

Execute add_client.sh shell script to create new client certificate.

$ sh add_client.sh 
User name (eg. John Doe): Milosz
Email: milosz@example.org
Export password: 
Kolab password: 
Root certificate (private key) password: 
Client certificate (private key) password: Generating a 4096 bit RSA private key
...++++++
.......++++++
writing new private key to 'root-ca/private/02.pem'
-----
Using configuration from openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 2 (0x2)
        Validity
            Not Before: Jul  6 12:57:39 2014 GMT
            Not After : Jul  6 12:57:39 2015 GMT
        Subject:
            countryName               = PL
            stateOrProvinceName       = state
            organizationName          = example.org
            organizationalUnitName    = Certificate Authority
            commonName                = Milosz
            emailAddress              = milosz@example.org
            kolabPasswordEnc          = RX3f071sOYKxwDBhNpDVHA==
            kolabPasswordIV           = 72a1e2086a765204122109382f8d4f5d
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                3B:7A:BF:A5:B8:F4:C9:E0:0D:81:41:0D:EE:27:F4:B5:C3:B0:40:67
            X509v3 Authority Key Identifier: 
                keyid:A1:41:B0:72:60:29:1A:9B:B1:63:77:53:E7:93:71:1D:02:14:A4:7C

Certificate is to be certified until Jul  6 12:57:39 2015 GMT (365 days)

Write out database with 1 new entries
[..]
Data Base Updated

Email field will be used to identify user. Kolab password field is a password, that will be encrypted using kolab_secret key, and stored inside certificate file (alongside the initialization vector).

Certificate will be stored inside root-ca/client_certs/ directory, and protected using specified export password (can be easily imported into browser).

$ ls root-ca/client_certs/
02.p12

Apache - Enable HTTPS protocol

Enable SSL module.

# a2enmod ssl
Enabling module ssl.

Enable default SSL virtual host.

# a2ensite default-ssl 
Enabling site default-ssl.

Disable default (non SSL) virtual host.

# a2dissite default
Site default disabled.

Create simple virtual host listening on port 80, to redirect traffic to the HTTPS protocol.

cat << EOF > /etc/apache2/sites-available/default-rewrite
<VirtualHost *:80>
  ServerName mail.example.org
  Redirect / https://mail.example.org/
</VirtualHost>
EOF

Enable the site created above.

# a2ensite default-rewrite 
Enabling site default-rewrite.

Change protocol used by Kolab Files module.

# sed -i -e "s/http:/https:/" /etc/roundcubemail/kolab_files.inc.php

Restart Apache and test applied modifications.

# service apache2 restart

Apache - Switch to own Certification Authority

Create /etc/apache2/ssl/ directory.

# mkdir /etc/apache2/ssl

Copy root certificate root-cert.pem, server certificate server.crt, and server private key server.key to the directory created in the previous step.

Edit Apache configuration to use uploaded server certificate, and private key.

# sed -i -e "/SSLCACertificateFile/ s/#//;s/ssl.crt\/ca-bundle.crt/ssl\/root-cert.pem/" /etc/apache2/sites-available/default-ssl  
# sed -i -e "/SSLCertificateFile/ s/\/etc\/ssl\/certs\/ssl-cert-snakeoil.pem/\/etc\/apache2\/ssl\/server.crt/" /etc/apache2/sites-available/default-ssl
# sed -i -e "/SSLCertificateKeyFile/ s/\/etc\/ssl\/private\/ssl-cert-snakeoil.key/\/etc\/apache2\/ssl\/server.pem/" /etc/apache2/sites-available/default-ssl

Restart web-server and test applied changes.

# service apache2 restart

Import root certificate root-cert.pem into the browser as Certification Authority, then client certificate.

Alter web-server configuration to require valid client certificate, but allow direct API calls from mail server (omit internal error when using kolab-admin).

# sed -i -e "/\/VirtualHost/i <Location />\nSSLRequireSSL\nSSLVerifyClient require\nSSLVerifyDepth 1\nOrder allow,deny\nallow from all\n</Location>\n\n<Location /kolab-webadmin/api/>\nSSLVerifyClient none\norder deny,allow\ndeny from all\nallow from mail.example.org\n</Location>" /etc/apache2/sites-available/default-ssl  

Restart web-server and test client certificate.

# service apache2 restart

Kolab - Use client certificate to fill username filed

You can use client certificate to fill username name inside login form.

to achieve this simple task you need to edit login_form function found in /usr/share/roundcubemail/program/include/rcmail_output_html.php file.

--- /usr/share/roundcubemail/program/include/rcmail_output_html.php.orig	2014-07-06 16:24:08.005325038 +0200
+++ /usr/share/roundcubemail/program/include/rcmail_output_html.php	2014-07-06 16:40:54.429360653 +0200
@@ -1551,40 +1551,47 @@
     protected function login_form($attrib)
     {
         $default_host = $this->config->get('default_host');
         $autocomplete = (int) $this->config->get('login_autocomplete');
 
         $_SESSION['temp'] = true;
 
         // save original url
         $url = rcube_utils::get_input_value('_url', rcube_utils::INPUT_POST);
         if (empty($url) && !preg_match('/_(task|action)=logout/', $_SERVER['QUERY_STRING']))
             $url = $_SERVER['QUERY_STRING'];
 
         // Disable autocapitalization on iPad/iPhone (#1488609)
         $attrib['autocapitalize'] = 'off';
 
+        $email="";
+        if ($_SERVER["HTTPS"] == "on" &&  $_SERVER["SSL_CLIENT_VERIFY"] == "SUCCESS") {
+          if (preg_match('/\/emailAddress=([^\/]*)\//',$_SERVER['SSL_CLIENT_S_DN'],$matches)) {
+            $email=$matches[1];
+          }
+        }
+
         // set atocomplete attribute
         $user_attrib = $autocomplete > 0 ? array() : array('autocomplete' => 'off');
         $host_attrib = $autocomplete > 0 ? array() : array('autocomplete' => 'off');
         $pass_attrib = $autocomplete > 1 ? array() : array('autocomplete' => 'off');
 
         $input_task   = new html_hiddenfield(array('name' => '_task', 'value' => 'login'));
         $input_action = new html_hiddenfield(array('name' => '_action', 'value' => 'login'));
         $input_tzone  = new html_hiddenfield(array('name' => '_timezone', 'id' => 'rcmlogintz', 'value' => '_default_'));
         $input_url    = new html_hiddenfield(array('name' => '_url', 'id' => 'rcmloginurl', 'value' => $url));
-        $input_user   = new html_inputfield(array('name' => '_user', 'id' => 'rcmloginuser', 'required' => 'required')
+        $input_user   = new html_inputfield(array('name' => '_user', 'id' => 'rcmloginuser', 'required' => 'required', 'value' => $email)
             + $attrib + $user_attrib);
         $input_pass   = new html_passwordfield(array('name' => '_pass', 'id' => 'rcmloginpwd', 'required' => 'required')
             + $attrib + $pass_attrib);
         $input_host   = null;
 
         if (is_array($default_host) && count($default_host) > 1) {
             $input_host = new html_select(array('name' => '_host', 'id' => 'rcmloginhost'));
 
             foreach ($default_host as $key => $value) {
                 if (!is_array($value)) {
                     $input_host->add($value, (is_numeric($key) ? $value : $key));
                 }
                 else {
                     $input_host = null;
                     break;

Use client certificate to login user

Generated client certificate already contains encrypted password (using kolab_secret key) and initialization vector, so you can use them to automatically login user using /usr/share/roundcubemail/index.php file.

--- /usr/share/roundcubemail/index.php.orig	2014-07-06 18:32:40.830414058 +0200
+++ /usr/share/roundcubemail/index.php	2014-07-06 18:37:07.462423513 +0200
@@ -88,17 +88,26 @@
 $RCMAIL->action = $startup['action'];
 
 // try to log in
-if ($RCMAIL->task == 'login' && $RCMAIL->action == 'login') {
-    $request_valid = $_SESSION['temp'] && $RCMAIL->check_request(rcube_utils::INPUT_POST, 'login');
+if ($RCMAIL->task == 'login' && $_SERVER["HTTPS"] == "on" &&  $_SERVER["SSL_CLIENT_VERIFY"] == "SUCCESS") {
+    $request_valid = 1; 
+    if (preg_match('/\/emailAddress=([^\/]*)\//',$_SERVER['SSL_CLIENT_S_DN'],$matches)) {
+      $email=$matches[1];
+    }
+    if (preg_match('/\/1.2.3.4.5.6.7.1=([^\/]*)/',$_SERVER['SSL_CLIENT_S_DN'],$matches)) {
+      $pass=$matches[1];
+    }
+    if (preg_match('/\/1.2.3.4.5.6.7.2=([^\/]*)/',$_SERVER['SSL_CLIENT_S_DN'],$matches)) {
+      $iv=$matches[1];
+    }
+    $pass=rtrim(openssl_decrypt(base64_decode($pass),'aes-128-cbc', hex2bin("d2d97d097eedb397edea79f52b56ea74"), true,hex2bin($iv)));
 
     // purge the session in case of new login when a session already exists 
     $RCMAIL->kill_session();
 
     $auth = $RCMAIL->plugins->exec_hook('authenticate', array(
         'host' => $RCMAIL->autoselect_host(),
-        'user' => trim(rcube_utils::get_input_value('_user', rcube_utils::INPUT_POST)),
-        'pass' => rcube_utils::get_input_value('_pass', rcube_utils::INPUT_POST, true,
-            $RCMAIL->config->get('password_charset', 'ISO-8859-1')),
+        'user' => $email,
+        'pass' => $pass,
         'cookiecheck' => true,
         'valid'       => $request_valid,
     ));

Future improvements

kolab_secret can be stored using Roundcube configuration file, and login form can be modified further to remove input fields, and include more information, .

There should be no problem to add shell script to generate CRL.

PHP code could be simplified a bit.

Please inspect shell scripts to get the idea of additional certificate parameters.


Sun, 2014-06-22 00:00

After a longer period of time I have decided to install Kolab and use it as personal information manager. Installation process went as expected up to the point where setup process tried to install Roundcube database and failed miserably.

Source of the problem

The problem can be easily identified by the error messages returned by the setup process.

Follow the example below to see MySQL errors at the very end.

# setup-kolab 

Please supply a password for the LDAP administrator user 'admin', used to login
to the graphical console of 389 Directory server.

Administrator password [Sii79iQyU3gkHN3]: 

Please supply a password for the LDAP Directory Manager user, which is the
administrator user you will be using to at least initially log in to the Web
Admin, and that Kolab uses to perform administrative tasks.

Directory Manager password [nNQAwQVnSDRzSUq]: 

Please choose the system user and group the service should use to run under.
These should be existing, unprivileged, local system POSIX accounts with no
shell.

User [dirsrv]: 
Group [dirsrv]: 

This setup procedure plans to set up Kolab Groupware for the following domain
name space. This domain name is obtained from the reverse DNS entry on your
network interface. Please confirm this is the appropriate domain name space.

sleeplessbeastie.eu [Y/n]: 

The standard root dn we composed for you follows. Please confirm this is the root
dn you wish to use.

dc=sleeplessbeastie,dc=eu [Y/n]: 

Setup is now going to set up the 389 Directory Server. This may take a little
while (during which period there is no output and no progress indication).

[..]

Please supply a Cyrus Administrator password. This password is used by Kolab to
execute administrative tasks in Cyrus IMAP. You may also need the password
yourself to troubleshoot Cyrus IMAP and/or perform other administrative tasks
against Cyrus IMAP directly.

Cyrus Administrator password [qolmP-8qsQAiPRe]: 

Please supply a Kolab Service account password. This account is used by various
services such as Postfix, and Roundcube, as anonymous binds to the LDAP server
will not be allowed.

Kolab Service password [yp48IyJvn8rd12H]: 

[..]

What MySQL server are we setting up?
 - 1: Existing MySQL server (with root password already set).
 - 2: New MySQL server (needs to be initialized).
Choice: 1

Please supply the root password for MySQL, so we can set up user accounts for
other components that use MySQL.

MySQL root password: 

Please supply a password for the MySQL user 'kolab'. This password will be used
by Kolab services, such as the Web Administration Panel.

MySQL kolab password [LAOv8Gmn2l1Gs-G]: 

Please supply the timezone PHP should be using. You have to use a Continent or
Country / City locality name like 'Europe/Berlin', but not just 'CEST'.

Timezone ID [UTC]: 

Please supply a password for the MySQL user 'roundcube'. This password will be
used by the Roundcube webmail interface.

MySQL roundcube password [yP7R_m4wJVcNiDW]: 
ERROR 1005 (HY000) at line 9: Can't create table 'roundcube.kolab_alarms' (errno: 150)
ERROR 1146 (42S02) at line 179: Table 'roundcube.system' doesn't exist

[..]

These errors are generated due to the following code inside /usr/share/pyshared/pykolab/setup/setup_roundcube.py file.

    schema_files = []
    for root, directories, filenames in os.walk('/usr/share/doc/'):
        for directory in directories:
            if directory.startswith("roundcubemail"):
                for root, directories, filenames in os.walk(os.path.join(root, directory)):
                    for filename in filenames:
                        if filename.startswith('mysql.initial') and filename.endswith('.sql'):
                            schema_filepath = os.path.join(root,filename)
                            if not schema_filepath in schema_files:
                                schema_files.append(schema_filepath)

                break
        break

I assume that its goal is to recursively find every mysql.initial*.sql file inside /usr/share/doc/roundcubemail*/ directories.

Finding the solution

First approach - Problem identification

Copy the earlier mentioned code to the disctinct script and slightly modify it to output additional information.

$ cat first_code_check.py 
import os

schema_files = []
for root, directories, filenames in os.walk('/usr/share/doc/'):
  for directory in directories:
    if directory.startswith("roundcubemail"):
      print "-> " + directory + " (" + root + ")"
      for root, directories, filenames in os.walk(os.path.join(root, directory)):
        for filename in filenames:
          print "   \ " + filename
          if filename.startswith('mysql.initial') and filename.endswith('.sql'):
            schema_filepath = os.path.join(root,filename)
            if not schema_filepath in schema_files:
              schema_files.append(schema_filepath)

It is easy to notice the problem after the script execution - the root variable inside third for loop is messing with future iterations.

$ python first_code_check.py 
-> roundcubemail-plugins-kolab (/usr/share/doc/)
   \ changelog.Debian.gz
   \ copyright
-> roundcubemail-plugin-threadingasdefault (/usr/share/doc/roundcubemail-plugins-kolab)
-> roundcubemail (/usr/share/doc/roundcubemail-plugins-kolab)

Second approach - Python script

The most obious fix is to rename second occurence of the root variable.

$ cat second_code_check.py 
import os

schema_files = []
for root, directories, filenames in os.walk('/usr/share/doc/'):
  for directory in directories:
    if directory.startswith("roundcubemail"):
      print "-> " + directory + "(" + root + ")"
      for nested_root, directories, filenames in os.walk(os.path.join(root, directory)):
        for filename in filenames:
          print "   \ " + filename
          if filename.startswith('mysql.initial') and filename.endswith('.sql'):
            schema_filepath = os.path.join(nested_root,filename)
            if not schema_filepath in schema_files:
              schema_files.append(schema_filepath)
              print "     ! added schema file"

Simple test reveals that it works as expected.

$ python second_code_check.py
-> roundcubemail-plugins-kolab(/usr/share/doc/)
   \ changelog.Debian.gz
   \ copyright
-> roundcubemail-plugin-threadingasdefault(/usr/share/doc/)
   \ changelog.Debian.gz
   \ copyright
-> roundcubemail(/usr/share/doc/)
   \ mysql.initial.sql
    ! added schema file
   \ mssql.initial.sql
   \ README.md
   \ sqlite.initial.sql
   \ changelog.Debian.gz
   \ copyright
   \ postgres.initial.sql
-> roundcubemail-plugin-contextmenu(/usr/share/doc/)
   \ changelog.gz
   \ changelog.Debian.gz
   \ copyright

Second approach - Path

--- /usr/share/pyshared/pykolab/setup/setup_roundcube.py.orig	2014-06-21 18:43:40.975058719 +0200
+++ /usr/share/pyshared/pykolab/setup/setup_roundcube.py	2014-06-21 19:12:46.957149746 +0200
@@ -139,16 +139,13 @@
     for root, directories, filenames in os.walk('/usr/share/doc/'):
         for directory in directories:
             if directory.startswith("roundcubemail"):
-                for root, directories, filenames in os.walk(os.path.join(root, directory)):
+                for nested_root, directories, filenames in os.walk(os.path.join(root, directory)):
                     for filename in filenames:
                         if filename.startswith('mysql.initial') and filename.endswith('.sql'):
-                            schema_filepath = os.path.join(root,filename)
+                            schema_filepath = os.path.join(nested_root,filename)
                             if not schema_filepath in schema_files:
                                 schema_files.append(schema_filepath)
 
-                break
-        break
-
     if os.path.isdir('/usr/share/roundcubemail'):
         rcpath = '/usr/share/roundcubemail/'
     elif os.path.isdir('/usr/share/roundcube'):

Third approach - Python script

This could be simplified a bit by replacing problematic os.walk call.

$ cat third_code_check.py 
import os
import fnmatch

schema_files = []
for root, directories, filenames in os.walk('/usr/share/doc/'):
  for directory in directories:
    if directory.startswith("roundcubemail"):
      print "-> " + directory + "(" + root + ")"
      for filename in os.listdir(os.path.join(root, directory)):
        if fnmatch.fnmatch(filename, 'mysql.initial*.sql'):
          schema_filepath = os.path.join(root,directory,filename)
          if not schema_filepath in schema_files:
            schema_files.append(schema_filepath)
            print "  \ " + filename
$ python third_code_check.py 
-> roundcubemail-plugins-kolab (/usr/share/doc/)
-> roundcubemail-plugin-threadingasdefault (/usr/share/doc/)
-> roundcubemail (/usr/share/doc/)
  \ mysql.initial.sql
-> roundcubemail-plugin-contextmenu (/usr/share/doc/)

Third approach - Patch

--- /usr/share/pyshared/pykolab/setup/setup_roundcube.py.orig	2014-06-21 18:43:40.975058719 +0200
+++ /usr/share/pyshared/pykolab/setup/setup_roundcube.py	2014-06-21 19:43:14.235162418 +0200
@@ -20,6 +20,7 @@
 from Cheetah.Template import Template
 import hashlib
 import os
+import fnmatch
 import random
 import re
 import subprocess
@@ -139,15 +140,11 @@
     for root, directories, filenames in os.walk('/usr/share/doc/'):
         for directory in directories:
             if directory.startswith("roundcubemail"):
-                for root, directories, filenames in os.walk(os.path.join(root, directory)):
-                    for filename in filenames:
-                        if filename.startswith('mysql.initial') and filename.endswith('.sql'):
-                            schema_filepath = os.path.join(root,filename)
-                            if not schema_filepath in schema_files:
-                                schema_files.append(schema_filepath)
-
-                break
-        break
+                for filename in os.listdir(os.path.join(root, directory)):
+                    if fnmatch.fnmatch(filename, 'mysql.initial*.sql'):
+                        schema_filepath = os.path.join(root,directory,filename)
+                        if not schema_filepath in schema_files:
+                            schema_files.append(schema_filepath)
 
     if os.path.isdir('/usr/share/roundcubemail'):
         rcpath = '/usr/share/roundcubemail/'

Fourth approach - Python script

This code can be simplified further by not reading directories recursively.

$ cat fourth_code_check.py
import os
import fnmatch
import glob

schema_files = []
for directory in glob.glob('/usr/share/doc/roundcubemail*'):
  print "-> " + directory
  for filename in os.listdir(directory):
    if fnmatch.fnmatch(filename, 'mysql.initial*.sql'):
      schema_filepath = os.path.join(directory,filename)
      if not schema_filepath in schema_files:
        schema_files.append(schema_filepath)
        print "  \ " + filename
$ python fourth_code_check.py 
-> roundcubemail-plugins-kolab (/usr/share/doc/)
-> roundcubemail-plugin-threadingasdefault (/usr/share/doc/)
-> roundcubemail (/usr/share/doc/)
  \ mysql.initial.sql
-> roundcubemail-plugin-contextmenu (/usr/share/doc/)

Fourth approach - Patch

--- /usr/share/pyshared/pykolab/setup/setup_roundcube.py.orig	2014-06-21 18:43:40.975058719 +0200
+++ /usr/share/pyshared/pykolab/setup/setup_roundcube.py	2014-06-21 19:59:42.380040035 +0200
@@ -20,6 +20,8 @@
 from Cheetah.Template import Template
 import hashlib
 import os
+import glob
+import fnmatch
 import random
 import re
 import subprocess
@@ -136,18 +138,12 @@
             fp.close()
 
     schema_files = []
-    for root, directories, filenames in os.walk('/usr/share/doc/'):
-        for directory in directories:
-            if directory.startswith("roundcubemail"):
-                for root, directories, filenames in os.walk(os.path.join(root, directory)):
-                    for filename in filenames:
-                        if filename.startswith('mysql.initial') and filename.endswith('.sql'):
-                            schema_filepath = os.path.join(root,filename)
-                            if not schema_filepath in schema_files:
-                                schema_files.append(schema_filepath)
-
-                break
-        break
+    for directory in glob.glob('/usr/share/doc/roundcubemail*'):
+        for filename in os.listdir(directory):
+            if fnmatch.fnmatch(filename, 'mysql.initial*.sql'):
+                schema_filepath = os.path.join(directory,filename)
+                if not schema_filepath in schema_files:
+                    schema_files.append(schema_filepath)
 
     if os.path.isdir('/usr/share/roundcubemail'):
         rcpath = '/usr/share/roundcubemail/'

Ending notes

I am not a Python developer. I wrote about this issue as it was an interesting way to learn about directory traversal and file filtering implemented in Python language.

It is up to you to decide which solution is appropriate for you - for more recent information please read the official bug report.


mollekopf's picture
Wed, 2014-05-21 12:40

Wouldn’t it be great if Kontact would allow you to select a set of folders you’re interested in, that setting would automatically be respected by all your devices and you’d still be able to control for each individual folder whether it should be visible and available offline?

I’ll line out a system that allows you to achieve just that in a groupware environment. I’ll take Kolab and calendar folders as example, but the concept applies to all groupware systems and is just as well applicable to email or other groupware content.

User Scenarios

  •  Anna has access to hundreds of shared calendars, but she usually only uses a few selected ones. She therefore only has a subset of the available calendars enabled, that are shown to her in the calendar selection dialog, available for offline usage and also get synchronized to her mobile phone. If she realizes she no longer requires a calendar, she simply disables it and it disappears from the Kontact, the Webclient and her phone.
  • Joe works with a small team that shares their calendars with him. Usually he only uses the shared team-calendar, but sometimes he wants to quickly check if they are in the office before calling them, and he’s often doing this in the train with unreliable internet connection. He therefore disables the team member’s calendars but still enables synchronization for them. This hides the calendars from all his devices, but he still can quickly enable them on his laptop while being offline.
  • Fred has a mailing list folder that he always reads on his mobile, but never on his laptop. He keeps the folder enabled, but hides it on his laptop so his folder list isn’t unnecessarily cluttered.

What these scenarios tell us is that we need a flexible mechanism to specify the folders we want to see and the folders we want synchronized. Additionally we want, in today’s world where we have multiple devices, to synchronize the selection of folders that are important to us. It is likely I’d like to see the calendar I have just enabled in Kontact also on my phone. However, we always want to keep the possibility to alter that default setting on specific devices.

Current State

If you’re using a Kolab Server, you can use IMAP subscriptions to control what folders you want to see on your devices. Kontact currently respects that setting in that it makes all folders visible and available for offline usage. Additionally you have local subscriptions to disable certain folders (so they are not downloaded or displayed) on a specific device. That is not very flexible though, and personally I ended up having pretty much all folders enabled that I ever used, leading to cluttered folder selections and lot’s of bandwith and storage space used to keep everything available offline.

To change the subscription state, KMail offers to open the IMAP-subscription dialog which allows to toggle the subscription state of individual folders. This works, but is not well integrated (it’s a separate dialog), and is also not well integrable since it’s IMAP specific.

Because the solution is not well integrated, it tends to be rather static in my experience. I tend to subscribe to all folders that I ever use, which results in a very long and cluttered folder-list.

A new integrated subscription system

What would be much better, is if the back-end could provide a default setting that is synchronized to the server, and we could quickly enable or disable folders as we require them. Additionally we can override the default settings for each individual folder to optimize our setup as required.

To make the system more flexible, while not unnecessarily complex, we need a per folder setting that allows to override a backend provided default value. Additionally we need an interface for applications to alter the subscription state through Akonadi (instead of bypassing it). This allows for a well integrated solution that doesn’t rely on a separate, IMAP-specific dialog.

Each folder requires the following settings:

  • An enabled/disabled state that provides the default value for synchronizing and displaying a folder.
  • An explicit preference to synchronize a folder.
  • An explicit preference to make a folder visible.

A folder is visible if:

  • There is an explicit preference that the folder is visible.
  • There is no explicit preference on visibility and the folder is enabled.

A folder is synchronized if:

  • There is an explicit preference that the folder is synchronized.
  • There is no explicit preference on synchronization and the folder is enabled.

The resource-backend can synchronize the enabled/disabled state which should give a default experience as expected. Additionally it is possible to override that default state using the explicit preference on a per folder level.

User Interaction

By default you would be working with the enabled/disabled state, that is synchronized by the resource backend. If you enable a folder it becomes visible and synchronized, if you disable it, it becomes invisible and not synchronized. For the enabled/disabled state we can build a very easy user interface, as it is a single boolean state, that we can integrate into the primary UI.

Because the enabled/disabled state is synchronized, an enabled calendar will automatically appear on your MyKolab.com web interface and your mobile. One click, and you’re all set.

Mockup of folder sync properties

Example mockup of folder sync properties

In the advanced settings, you can then override visibility and synchronization preference at will as a local-only setting, giving you full flexibility. This can be hidden in a properties dialog, so it doesn’t clutter the primary UI.

This makes the default usecase very simple to use (you either want a folder or you don’t want it), while we keep full flexibility in overriding the default behaviour.

IMAP Synchronization

The IMAP resource will synchronize the enabled/disabled state with IMAP subscriptions if you have subscriptions enabled in the resource. This way we can use the enabled/disabled state as interface to change the subscriptions, and don’t have to use a separate dialog to toggle that state.

Interaction with existing mechanisms

This mechanism can probably replace local subscriptions eventually. However, in order not to break existing setups I plan to leave local subscriptions working as they currently are.

Conclusion

By implementing this proposal we get the required flexibility to make sure the resources of our machine are optimally used, while different clients still interact with each other as expected. Additionally we gain a uniform interface to enable/disable a collection that can be synchronized by backends (e.g. using the IMAP subscription state). This will allow applications to nicely integrate this setting, and should therefore make this feature a lot easier to use and overall more agile.

New doors are opened as this will enable us to do on-demand loading of folders. By having the complete folder list available locally (but disabled by default and thus hidden), we can use the collections to load their content temporarily and on-demand. Want to quickly look at that shared calendar you don’t have enabled? Simply search for it and have a quick look, the data is synchronized on-demand and the folder is as quickly gone as you found it, once it is no longer required. This will diminish the requirement to have folders constantly clutter your folder list even further.

So, what do you think?


roundcube's picture
Sun, 2014-05-11 09:00

This is the first service release to update the stable version 1.0. It contains some important bug fixes and improvements, mainly a fix for the unintentional redirect from the compose page in Google Chrome which started to happen after a recent Chrome update.

It’s considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from roundcube.net/download, see the full changelog here.

Please note that the update includes a small database schema change so make sure you run the update script.


DSP3's picture
Mon, 2014-05-05 15:43

Kolab is an excellent open source messaging and collaboration suite, the installation of which I discussed in a previous post.

Currently, there is one feature missing from the Kolab suite and that is the ability to send instant messages (IM) between authenticated Kolab users or even outside of the domain. This is where ejabbered comes in. The following is a summary of how you can integrate ejabberd into a Kolab system running on CentOS 6.5

As Kolab is already installed, there is no need to add the EPEL repository used to host the ejabbered .rpm installer. Installation is as simple as:

sudo yum install ejabberd

Ejabbered is written in Erlang and is configured by editing /etc/ejabbered/ejabberd.cfg

sudo nano /etc/ejabberd/ejabberd.cfg

Search for the following code and edit accordingly:

%%{auth_method, internal}.

change to

{auth_method, ldap}.

Search for the remaining lines of code ('ctrl' + 'w' in nano) and change them to fit your environment:

{ldap_servers, ["localhost"]}.
{ldap_port, 389}.
{ldap_rootdn, "cn=Directory Manager"}.
{ldap_password, "the_password_you_set_during_kolab_install_for_ldap"}.
{ldap_filter, "(objectClass=mailrecipient)"}.
{ldap_uids, [{"alias", "%u@%d"}]}.
{acl, admin, {user, "admin", "yourdomain.org"}}.
{hosts, ["yourdomain.org"]}.
{ldap_base, "ou=People,dc=yourdomain,dc=org"}.

Save the file by ctrl 'x' and then pressing 'y' (yes) and enter.
Start ejabberd service

sudo service ejabberd start

Add ejabberd as a service to start at boot

chkconfig ejabberd on

Update iptables

sudo iptables -I INPUT -ptcp --dport 5280 -j ACCEPT
sudo iptables -I INPUT -ptcp --dport 5222 -j ACCEPT
sudo service iptables save
sudo service iptables restart

You should now be able to login with your IM client such as Jitsi or Pidgin. As ejabberd is set to use ldap_uids with 'alias' you can login with an alias instead of firstname.lastname@yourdaomain.org

You now have an excellent communication and collaboration system. Voice, video, email, IM, calendar, address book, file share. Source code freely available, so adapt to your requirements.

Original credit goes to Andreas Cordes for assistance with ldap authentication with ejabberd.


Mon, 2014-05-05 11:57

This week, Kolab.org will be presented at two conferences. The first one will show how Kolab can be a secure privacy asylum in a post-Snowden world. It will highlight Kolab's security architecture and show how you can run Kolab on a Rasperry Pi for yourself or in full blown datacenter for millions of users. The presentation will happen in Berlin at Linuxtag on Thursday May 8 on Stage B at 18:30.

If you can not afford the entry to Linuxtag, you will be happy to find out that there is free entry at 18:00 right before the Kolab.org presentation.

The second presentation takes place in Porto Alegre, Brazil at the International Free Software forum (FISL). This year's motto is Security and Privacy: Free Software in the struggle against Espionage. This topic would of course not be complete without Kolab. So our community manager Torsten will give a general introduction into Kolab, it's architecture and community. He will also motivate people to join our still lonely Portuguese community mailing list.

The talk will take place on Saturday May 10 in room 40T at 15:00. If you happen to be at FISL, make sure not to miss it.


Andreas Cordes's picture
Sun, 2014-05-04 00:15

Since now I'm using +Kolab on my +Raspberry Pi  for 100 days.

Syncroton (Active-Sync) is working like a charme, access to my files via WebDav is also working.
After changing the webserver from +Apache  to +Nginx the performance in using roundcube is now ok and after the logrotate during midnight I had no sync problems any more with my mobile.
Power consumption is below 3W so it costs only about 7€ per year (0,60€ per month) which is really cheap. Ok you have to add 1€ per month for the domain if you use +regfish for the domain. 
A few days ago I exported all my contacts hosted on the google server and imported them into Kolab. 
So if you don't like to let google know the phone number from your grandma and so on it's up to you to change this and get your own groupware on your server at your home :-)
BTW you can do a lot of other things with your Raspberry Pi.
Greetz

DSP3's picture
Sun, 2014-04-27 21:41

Communication, collaboration and dissemination of ideas is an important part of learning and I happen to believe that learning to build systems that enhance communication leads to a better understanding of the whole communication process, especially in this age of all things connected, all the time. Kolab is a collection of a number of mature open source projects, which enables you to build a very powerful communication platform whilst maintaining full control of the system. The installation, configuration and management can be delegated to individuals or groups within the learning environment and this system can scale from a small user base such as a single class to a whole institution. Big thank you to the Kolab community for such a great product!

This post will document installing and configuring Kolab 3.2 on CentOS 6.5 Kolab is a collection of opensource projects packaged together to make a unified system. I have a lot of experience with the many parts that make Kolab - Roundcube, Postfix, Cyrus etc and Kolab strives to bring them all together into one manageable install with a central web administration interface for the directory server (LDAP) used for domain and user management.

For installation I mainly followed 2 different guides, here (English) and here (German). Many thanks to them!

Firstly and most importantly, your server needs to have correctly configured DNS and MX records. Without these, nothing will work. Secondly, you need to have your server hostname set correctly. I would also highly recommend setting up on a freshly installed and updated CentOS system.

[user@kolab ~]$ hostname -f
kolab.dsp3.org

My server resolves to kolab.dsp3.org When the kolab installer runs, it will check to see that your hostname is resolvable by public DNS. I have reverse DNS set to resolve back to the domain from which I will be sending email. In this case @dsp3.org You should check "/etc/sysconfig/network" and "/etc/hosts" before you begin installation to save yourself a lot of headaches later on.

[user@kolab ~]$ nano /etc/sysconfig/network
HOSTNAME="kolab.dsp3.org"
[user@kolab ~]$ nano /etc/hosts
94.156.77.58 kolab.dsp3.org  kolab

My server IP address 94.156.77.58 resolves to kolab.dsp3.org with a machine host called kolab.

If everything is set, we can begin the installation. Firstly, install the Redhat EPEL repositories (x86_64) for 64 bit systems and then install the repo's needed for the Kolab packages.

[user@kolab ~]$ sudo -i
[sudo] password for user:
[root@kolab ~]# cd /tmp
[root@kolab tmp]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@kolab tmp]# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
[root@kolab tmp]# rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm
[root@kolab tmp]# rm -rf remi-release-6*.rpm epel-release-6*.rpm
[root@kolab tmp]# yum update
[root@kolab tmp]# cd /etc/yum.repos.d/
[root@kolab yum.repos.d]# wget http://obs.kolabsys.com:82/Kolab:/3.2/CentOS_6/Kolab:3.2.repo
[root@kolab yum.repos.d]# wget http://obs.kolabsys.com:82/Kolab:/3.2:/Updates/CentOS_6/Kolab:3.2:Updates.repo
[root@kolab yum.repos.d]# yum install kolab

There is a bug in the current installer for CentOS, so a small edit is required before completing setup.

[root@kolab yum.repos.d]# nano /usr/lib/python2.6/site-packages/pykolab/setup/setup_mta.py

Find the following code:

if os.path.isdir('/etc/amavisd'):
        fp = open('/etc/amavisd/amavisd.conf', 'w')
    elif os.path.isdir('/etc/amavis'):
        fp = open('/etc/amavis/amavisd.conf', 'w')
        fp.write(t.__str__())
        fp.close()

and replace it with the following:

if os.path.isdir('/etc/amavisd'):
        fp = open('/etc/amavisd/amavisd.conf', 'w')
        fp.write(t.__str__())
        fp.close()
    elif os.path.isdir('/etc/amavis'):
        fp = open('/etc/amavis/amavisd.conf', 'w')
        fp.write(t.__str__())
        fp.close()

The installer may have displayed an error regarding missing pykolab.log which can be fixed with the following:

[root@kolab yum.repos.d]# chown root:root /var/log/kolab/pykolab.log

Now we can run the setup script:

[root@kolab yum.repos.d]# setup-kolab

Go ahead and follow the onscreen prompts, either accepting the passwords generated for each part (and noting them down for future reference!) or supplying your own. The most important part to pay attention to is as follows:

This setup procedure plans to set up Kolab Groupware for the following domain name space. This domain name is obtained from the reverse DNS entry on your network interface. Please confirm this is the appropriate domain name space.

dsp3.org [Y/n]: y

The standard root dn we composed for you follows. Please confirm this is the root
dn you wish to use.

dc=dsp3,dc=org [Y/n]: y

Please ensure this matches the primary domain from which your users will be sending mail from (the part after '@').

Congratulations. You are almost finished. There was one final gotcha that I encountered, which can be fixed by editing the config.inc.php file found in /etc/roundcubemail/

[root@kolab yum.repos.d]# nano /etc/roundcubemail/config.inc.php

Find the following section:

// Plugins
$config['plugins'] = array(

and comment out the section on 'kolab_files' so that it looks like this:

 // 'kolab_files',

This will disable Chwala, the new file storage componenet which didn't work for me in my environment. Save and restart apache.

service httpd restart

Open a browser and navigate to your domain adding /kolab-webadmin to the end of the url. You should be presented with this:

kolab-webadmin

You must login with the credential you supplied during setup. You are now ready to add users

Finally, I would recommend having a look at securing your Kolab server

In a later post, I will describe the setup of ejabbered and how to integrate it with the Kolab ldap server.


Andreas Cordes's picture
Thu, 2014-04-17 15:32

Hello,

yesterday I needed the functionality of storing files in +Kolab.

I found out that this does not work on my installation.

This is a known bug in cyrus.

https://lists.kolabsys.com/pipermail/packaging-commits/2012-November/007932.html
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3754

Raspbian does not have an updated package :-( so I started the compile issue again but now for a raspbian package.

To do the changes I downloaded the package cyrus-imapd and tried to compile like I did for all the +Kolab packages. But that didn't fix the error because I had to modify imap/message.c.

Ok, googling showed me that I have to use the right method with quilt.

So here are the instructions

apt-get -y source cyrus-imapd
apt-get -y build-dep cyrus-imapd
cd cyrus-imapd-2.4-2.4.16
quilt push -a
quilt new failed_asserting_during_append
quilt add imap/message.c

Edit the file imap/message.c. In line 389 add the line:

message_guid_generate(&(*body)->guid, msg.base, msg.len);

And continue with the following commands

quilt refresh
debuild -us -uc -b

and now go for coffee break :-)

After less than 2 hours you can install the new package.


cd ..
dpkg -i cyrus-imapd-2.4_2.4.16-4+deb7u1_all.deb 

To get the indexes working on the existing files you have to reconstruct the mailboxes with the following command:

cyrreconstruct -C /etc/imapd.conf -fr 'user/name/Files@domain'

You can also mount the files in Windows. For me only the command line is working. So click on Start->run (or press Windows-R) and enter the following command:

net use x: https://example.com/iRony/files/ YourPasswordGoesHere /user:primary.email@example.com

The impatient people can you use my prebuild package on my APT-Repo

deb http://kolab-deb.zion-contro.org / 

greetz


Andreas Cordes's picture
Sat, 2014-04-12 22:29

Hello,

I create a new page with my nginx config to cover all changes and mods which I've done on my Raspberry Pi.

The instructions are based on http://kolab.org/blog/grote/2013/07/08/using-kolab-3-nginx and https://docs.kolab.org/howtos/nginx-webserver.html.

So feel free to leave any comments and to get your Kolab running on your Pi with a bit more performance.

More tuning tips are welcome. :-)

greetz


Andreas Cordes's picture
Sat, 2014-04-12 01:30

Now I got it.

I'm using converse.js.

Following the instructions on http://permalink.gmane.org/gmane.comp.kde.kolab.devel/12092  I got it.

Well, not only following the instructions but also to setup some more things:

First of all the config from the plugin. The main parts are

$config['converse_xmpp_bosh_prebind_url']= function($args) {
        return 'http://127.0.0.1:5280/http-bind';
};
$config['converse_xmpp_bosh_url']= function($args) {
        return '/http-bind';
};
$config['converse_xmpp_hostname']= function($args) {
        list($user,$host) = explode('@', $args['user']);
        return $host;
};
$config['converse_xmpp_username']= function($args) {
        list($user,$host) = explode('@', $args['user']);
        return $user;
};

Please check the variable name. It is in the config.inc.php from the plugin by default $rcmail_config, but the roundcubemail from kolab sources/binaries uses $config, so please change it :-)

To have the BOSH-Url available in roundcubemail, you have to redirect domain/http-bind to server:5280/htt-bind. My nginx config looks like this:
location /http-bind {
            proxy_pass  http://localhost:5280/http-bind;
            proxy_set_header Host $host;
            proxy_buffering off;
            tcp_nodelay on;
        }

And now the ejabberd.cfg. When you install ejabberd and connect it to kolab-ldap, binding also seems to work (domain:5280/http-bind) but it doesn't. You need explicitly to activate it in the "modules"-section!
I forgot this and struggled around nearly 4 hours to find the error.
So the changes in modules section are
  {mod_shared_roster,[
                {'ldap_base', 'ou=People,dc=example,dc=com'},
                {'ldap_rfilter', '(objectClass=kolabinetorgperson)'},
                {'ldap_memberattr', 'uid'},
                {'ldap_userdesc', 'cn'},
                {'ldap_filter', '(objectClass=kolabinetorgperson)'},
                {'ldap_useruid', 'uid'}
        ]},
  {mod_http_bind,[]}

greetz 


Andreas Cordes's picture
Tue, 2014-04-08 18:05

Hi,

my eJabberd server is now up and running and I can receive messages and send messages.

My next step is to setup the chat functionality in roundcubemail so you can send messages through a Jabber client or roundcubemail. :-)

I had to find the correct settings for my domain and the client to get it to work. So it's necessary to have proper DNS records for your domain and the services jabber is running on.

You must have a A/CNAME record for your domain (no wildcard, -> "nslookup domain.com" should work) and 3 SRV records for your domain where you setup your jabber server where all the clients and servers have to connect to.

Also you should use SASL for authentication purpose.

I prefer to have my domain as the jabber ID and not a subdomain.

greetz


roundcube's picture
Mon, 2014-04-07 23:44

We’re very proud to announce the stable version 1.0 of Roundcube Webmail. After more than 8 years since the project was published, we feel confident to name it one-dot-oh. From the last stable version we added to following new features:

  • Cleaned up the configuration into a single file
  • Importing email messages and contact group assignments
  • Advanced LDAP address book functionality
  • A toggle to switch between HTML and plaintext view
  • Save drafts in local storage for recovery
  • Canned responses to save and recall boilerplate texts
  • Improved keyboard navigation in messages list
  • Optimized UI to work on tablet devices
  • Attachment reminder plugin

And mainly we were busy cleaning up the codebase, fixing a lot of bugs, making it more stable and writing more documentation.

With this release, we’d also like to introduce the Roundcube plugins repository at plugins.roundcube.net. This central platform should help you find the right plugins for your Roundcube installation and makes it simple to keep them up-to-date. The installation and update mechanism is based on Composer and Packagist.

We’d also like to encourage plugin developers to publish their plugins on this platform. Please read the instructions how to prepare your plugin for publishing.

After lots of testing and collecting your feedback, this version is considered stable and we recommend to update all productive installations of Roundcube.

Download the fresh webmail and framework packages from roundcube.net/download

Read the full list of changes here: trac.roundcube.net/wiki/Changelog

WARNING: when upgrading from <= 0.9 the old configuration files named main.inc.php and db.inc.php are now deprecated and should be replaced with one single config.inc.php file. Run the ./bin/update.sh script to get this conversion done or manually merge the files. NOTE: the new config.inc.php should only contain options that differ from the ones listed in defaults.inc.php.


Andreas Cordes's picture
Mon, 2014-03-31 10:07
Hi,

yesterday I started to implement a chat into Kolab.
I decided to use an XMPP Server connected to the Kolab-Ldap and decided to use eJabberD.
Installation was quite simple and the connection to Kolab-Ldap as well.
Download and install with the following command:

apt-get install ejabberd

and follow the instructions.
Here are my specific parameter for the auth against Kolab-LDAP (the other remain as they are):
%%{auth_method, internal}.
{auth_method, ldap}.
{ldap_servers, ["localhost"]}.
{ldap_port, 389}.
{ldap_rootdn, "cn=Directory Manager"}.
{ldap_password, "DontEvenThinkAboutIt"}.
{ldap_filter, "(objectClass=mailrecipient)"}.
{ldap_uids, [{"mail", "%u@%d"}]}.
{acl, admin, {user, "admin", "zion-control.org"}}.
{hosts, ["zion-control.org"]}.
{ldap_base, "ou=People,dc=zion-control,dc=org"}.

It's not necessary to register user in eJabberd, just create one in your kolab-webadmin.

If you want to check your eJabberD, go to :

http://youraddress:5280/admin

and login with your full mail address and password which you use for Kolab.

Next part would be to have an IM in roundcube...

greets


Timotheus Pokorra's picture
Wed, 2014-03-26 22:50

This describes how to install a docker image of Kolab.

Please note: this is not meant to be for production use. The main purpose is to provide an easy way for demonstration of features and for product validation.

This installation has not been tested a lot, and could still use some fine tuning. This is just a demonstration of what could be done with Docker for Kolab.

Preparing for Docker
I am using a Jiffybox provided by DomainFactory for downloading a Docker container for Kolab 3.1 running on CentOS 6.

I have installed Ubuntu 12.04 LTS on a Jiffybox.
I am therefore following Docker Installation instructions for Ubuntu for the installation instructions:

Install a kernel that is required by Docker:

sudo apt-get update
sudo apt-get install linux-image-generic-lts-raring linux-headers-generic-lts-raring

After that, in the admin website of JiffyBox, select the custom kernel Bootmanager 64 Bit (pvgrub64); see also the german JiffyBox FAQ. Then restart your JiffyBox.

After the restart, uname -a should show something like:

Linux j89610.servers.jiffybox.net 3.8.0-37-generic #53~precise1-Ubuntu SMP Wed Feb 19 21:37:54 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Now install docker:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
 
sudo sh -c "echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
 
sudo apt-get update
sudo apt-get install lxc-docker

Install container
The image for the container is available here:
https://index.docker.io/u/tpokorra/kolab31_centos6/
If you want to know how this image was created, read my other blog post http://www.pokorra.de/2014/03/building-a-docker-container-for-kolab-on-jiffybox.

To install this image, you need to type in this command:

docker pull  tpokorra/kolab31_centos6

You can create a container from this image and run it:

MYAPP=$(sudo docker run --name centos6_kolab31 -p 443:443 -h kolab31.test.example.org -d -t -i tpokorra/kolab31_centos6)

(-P should work instead of -p 443:443 and use the ports defined by EXPOSE in Dockerfile, but that does not work for me at the moment…)

You can see all your containers:

docker ps -a

You now have to attach to the container, and inside the container start the services:

docker attach $MYAPP
  /root/start.sh

Somehow it should work to start the services automatically at startup, but I did not get it to work with CMD or ENTRYPOINT.

To stop the container, type exit on the container’s console, or run from outside:

docker stop $MYAPP

To delete the container:

docker rm $MYAPP

You can reach the Kolab Webadmin on this URL:
https://localhost/kolab-webadmin. Login with user: cn=Directory Manager, password: test

The Webmail interface is available here:
https://localhost/roundcubemail.


Timotheus Pokorra's picture
Wed, 2014-03-26 22:50

Preparation
I am using a Jiffybox provided by DomainFactory for building a Docker container for Kolab 3.1 running on CentOS 6.

I have installed Ubuntu 12.04 LTS on a Jiffybox.
I am therefore following Docker Installation instructions for Ubuntu for the installation instructions:

Install a kernel that is required by Docker:

sudo apt-get update
sudo apt-get install linux-image-generic-lts-raring linux-headers-generic-lts-raring

After that, in the admin website of JiffyBox, select the custom kernel Bootmanager 64 Bit (pvgrub64); see also the german JiffyBox FAQ. Then restart your JiffyBox.

After the restart, uname -a should show something like:

Linux j89610.servers.jiffybox.net 3.8.0-37-generic #53~precise1-Ubuntu SMP Wed Feb 19 21:37:54 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Now install docker:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
 
sudo sh -c "echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
 
sudo apt-get update
sudo apt-get install lxc-docker

Create a Docker image
I realised that if I would install Kolab in one go, the image would become too big to upload to https://index.docker.io.
Therefore I have created a Dockerfile which has several steps for downloading and installing various packages. For a detailed description of a Dockerfile, see the Dockerfile Reference

My Dockerfile looks like this:

FROM centos
RUN mv /etc/localtime /etc/localtime.old; ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime
RUN echo "NAME=kolab31.test.example.org" > /etc/sysconfig/network; echo "kolab31.test.example.org" > /proc/sys/kernel/hostname
RUN chmod a+w /dev/shm
WORKDIR /root
RUN wget -O master.tar.gz https://github.com/tpokorra/kolab3_tbits_scripts/archive/master.tar.gz; tar xzf master.tar.gz; rm master.tar.gz
WORKDIR /root/kolab3_tbits_scripts-master/kolab3.1
RUN sed -i -e "s/^yum -y install kolab.*/#yum -y install kolab/" reinstallCentOS.sh
RUN echo "y" | ./reinstallCentOS.sh CentOS_6
# split yum -y install kolab into several steps,
# to keep the revisions small enough to avoid problems with uploading the image
RUN yum -y install php-kolabformat
RUN yum -y install mysql-server
RUN yum -y install kolab-cli
RUN yum -y install kolab-imap
RUN yum -y install 389-ds-base
RUN yum -y install java-1.6.0-openjdk
RUN yum -y install libgcj
RUN yum -y install kolab-ldap
RUN yum -y install kolab-webadmin
RUN yum -y install iRony
RUN yum -y install wallace
RUN yum -y install kolab-webclient
RUN yum -y install postfix
RUN yum -y install clamd
RUN yum -y install kolab-mta
RUN yum -y install qt-x11
RUN yum -y install libkolab
RUN yum -y install kolab patch unzip
# prepare for setup kolab
RUN ./initSetupKolabPatches.sh
# we cannot run setup-kolab here, because the hostname is no FQDN
# RUN setup-kolab --default --timezone=Europe/Brussels --directory-manager-pwd=test
# allow connections on port 443 (https)
EXPOSE 443
# TODO: allow IMAP as well
 
#CMD ["/sbin/init"]

This command will build a container with the instructions from the Dockerfile in the current directory. When the instructions have been successful, an image with the name tpokorra/kolab31_centos6 will be created, and the container will be deleted:

sudo docker build -t tpokorra/kolab31_centos6 .

You can see all your local images with this command:

sudo docker images

To finish the container, we need to run setup-kolab, this time we define a hostname as a parameter:

MYAPP=$(sudo docker run --name centos6_kolab31 -h kolab31.test.example.org -d -t -i tpokorra/kolab31_centos6 /bin/bash)
docker attach $MYAPP
# run inside the container:
  echo `hostname -f` > /proc/sys/kernel/hostname
  setup-kolab --default --timezone=Europe/Brussels --directory-manager-pwd=test
  ./initSSL.sh
  cat > /root/start.sh << EOF
#!/bin/bash
service httpd start
service mysqld start
service dirsrv start
service cyrus-imapd start
sleep 10
service kolabd start
service kolab-saslauthd start
EOF
  chmod a+x /root/start.sh
  service kolabd stop
  service dirsrv stop
  service cyrus-imapd stop
  service mysqld stop
  service httpd stop
  exit

Typing exit inside the container will stop the container.

Now you commit this last manual change:

docker commit $MYAPP tpokorra/kolab31_centos6
# delete the container
docker rm $MYAPP

You can push this image to https://index.docker.io:

#create a new account, or login with existing account:
sudo docker login
sudo docker push tpokorra/kolab31_centos6

You can now see the image available here: https://index.docker.io/u/tpokorra/kolab31_centos6/

See this post Installing Demo Version of Kolab 3.1 with Docker about how to install this image on the same or a different machine, for demo and validation purposes.

Current status: There are still some things not working fine, and I have not tested everything.
But this should be a good starting point for other people as well, to help with a good demo installation of Kolab on Docker.


Staffe's picture
Wed, 2014-03-26 21:13

Es kann viele Gründe geben, Konzerne wie Microsoft, Apple oder Google zu meiden. Wer sich dazu entschließt, aber trotzdem auf Bequemlichkeiten der “Cloud” nicht verzichten will und seine Daten aber möglichst selbst unter Kontrolle haben möchte, ist mit einem gemieteten VPS oder root-Server gut beraten. Um zu einem passablen Ergebnis zu kommen, muss aber viel installiert und konfiguriert werden. Wer sich davon nicht zurückschrecken lässt, sollte zumindest ein paar Stunden Zeit einplanen. Dieses Tutorial soll helfen, die größten Probleme zu umschiffen und dem frisch gebackenen (oder auch teilweise erfahrenen Server-Admin) stundenlange Sucherei im Internet zu ersparen.
kolab
Zur eingesetzten Software: Als Betriebssystem habe ich mich für das aktuelle CentOS 6.5 entschieden. Mit der Kolab Groupware, ein auf Roundcube aufgesetztes Webinterface, installieren wir eine moderne Web-UI inklusive Mailserver (IMAP,POP3,SMTP,Spam- und Virenfilter), Adressbuch, Kalender, Aufgaben und Active Sync (Push-Mail). Als Daten-Cloud kommt ownCloud zum Einsatz und als “Schmankerl” installieren wir noch den Plex Media Server.  Die komplette Software ist kostenlos und zum größten Teil Open Source.

      1. Vorwort
      2. Voraussetzungen
      3. EPEL-Repository und Systemupdate
      4. FTP-Server
      5. Kolab Groupware
      6. ownCloud + Kolab-Integration
      7. Plex Media Server
      8. SSL / HTTPS Verschlüsselung

1. Vorwort:
Im gesamten Tutorial gehe ich davon aus, dass euer Server eine feste IP-Adresse besitzt und über die hypothetische Domain example.com erreichbar ist. Diese Domain soll, wie der Name schon sagt, als Beispiel dienen. Passwörter, Domains und IPs müsst ihr selbstverständlich euren Daten nach anpassen.

2. Voraussetzungen:
Die beste Ausgangsposition ist ein frisch installiertes CentOS 6.5 64bit. Wer dieses Tutorial auf ein bereits konfiguriertes System anwenden will, kann Probleme mit bereits existierenden Datenbanken, inkompatiblen Diensten und/oder inkompatiblen Paketen kriegen. Desweiteren sollten die LAMP-Server (Apache/httpd, MySQL, PHP) bereits installiert und gestartet sein (auf Autostart beim Booten achten). Wir benötigen natürlich volle root-RechteSELinux und Firewall (iptables) bitte während der gesamten Installation deaktivieren. Diese können dann später entsprechend der laufenden Dienste angepasst werden.
Sind alle Voraussetzungen erfüllt, können wir loslegen:

3. EPEL-Repository und Systemupdate:
Einige von uns benötigte Pakete sind nicht in den Standard-Paket-Quellen von CentOS enthalten. Dafür benötigen wir das EPEL-Repository:

# cd /tmp
# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
# rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm
# rm -rf remi-release-6*.rpm epel-release-6*.rpm

Wenn nicht schon geschehen, aktualisieren wir alle Pakete des Systems:

# yum update

Sollte bei den Updates ein neuer Kernel dabei gewesen sein, muss CentOS neu gestartet werden:

# reboot

4. FTP-Server
Um ggf. Dateien und Verzeichnisse auf den Server zu schieben, sollte ein FTP-Server installiert werden. Wer andere Möglichkeiten zum Datentransfer hat, kann diesen Punkt überspringen.

# yum install vsftpd
# chkconfig vsftpd on
# nano /etc/vsftpd/vsftpd.conf

In der vsftpd.conf folgende Zeilen ändern, bzw. durch Entfernen des ‘#’ aktivieren:

anonymous_enable=NO
ascii_upload_enable=YES
ascii_download_enable=YES
ftp_banner=Deine Willkommensnachricht hier.

Danach können wir den FTP-Server starten.

# service vsftpd start

Mit Ausnahme von root kann jetzt jeder bereits angelegte Benutzer mit seinem Standard-Passwort über FTP auf sein Home-Verzeichnis zugreifen. Ist noch kein Benutzer vorhanden, muss noch einer mit den gewünschten Attributen angelegt werden. Einen einfachen Benutzer mit Shell und Login-Möglichkeit erstellen wir mit

# useradd benutzer
# passwd benutzer

Die über FTP hochzulandende Daten lassen sich dann im Verzeichnis /home/benutzer/ speichern und von da aus an den gewünschten Ort verschieben.

5. Kolab Groupware
Der eigentlich wichtigste und schwierigste Teil in diesem Tutorial. Kolab beinhaltet unter anderem unsere E-Mail und Synchronisierungs-Dienste und stellt uns zudem noch chice Weboberflächen für Administration und Benutzung zur Verfügung. Die Installation hat mich einiges an Zeit gekostet, da ich keine Möglichkeit gefunden habe, bei einer fehlerhaften Konfiguration Kolab nach Ausführen des Setup-Scripts wieder automatisiert zu entfernen. Wenn ihr euch aber genau an folgende Anleitung hält, sollte alles glatt laufen.

Kolab nimmt es sehr genau mit dem eingetragenen Hostnamen und der Domain und setzt einen “Fully Qualified Domain Name” (FQDN) voraus. Die richtigen Einstellungen erhalten wir indem wir zwei Dateien editieren. Achtet darauf, dass ihr die Adressen entsprechend anpasst.

# nano /etc/sysconfig/network

Folgendes editieren, bzw. hinzufügen:

HOSTNAME= server.example.com

In diesem Fall ist ‘server’ der Host und ‘example.com’ die Domain. Die Benennung des Hosts ist wichtig und kann beispielsweise auch ‘kolab’ oder ‘cloud’ heißen. In diesem Tutorial verwende ich aber durchgehend ‘server’ als Host. Als nächstes passen wir die /etc/hosts Datei an:

# nano /etc/hosts

Hier muss eure feste IP, der Hostname und der Host eingetragen, bzw editiert werden.

12.345.678.32  server.example.com  server

Dann noch den Befehl hostname ausführen und den Rechner neu starten.

# hostname server.example.com
# reboot

Nach dem Neustart bereiten wir die MySQL-Datenbank vor. Wichtig ist, dass kein Passwort für den MySQL-Nutzer root gesetzt ist. Dieses legen wir erst im Laufe des Kolab-Setup-Assistenten fest. Ob ein Passwort gesetzt ist, kontrollieren wir ganz einfach indem wir versuchen uns in die Datenbank einzuloggen:

# mysql -u root

Wenn wir uns mit diesem Befehl erfolgreich anmelden können ist alles in Ordnung und wir können uns mit

> quit

wieder ausloggen. Falls die Anmeldung nicht klappt und wir eine Access Denied Fehlermeldung bekommen, müssen wir das Passwort zurücksetzen. Anmerkung: Bei Den Anführungszeichen in PASSWORD(”) handelt es sich um zwei einzelne Anführungszeichen (‘) und kein doppeltes (“). Am Besten kopiert ihr euch die Zeile, dann kann nichts passieren ;)

# mysql -u root -p
//Passwort eingeben
> SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(”);
> quit

Im nächsten Schritt legen wir für Kolab ein Repository an…

# cd /etc/yum.repos.d/
# wget http://obs.kolabsys.com:82/Kolab:/3.2/CentOS_6/Kolab:3.2.repo
# wget http://obs.kolabsys.com:82/Kolab:/3.2:/Updates/CentOS_6/Kolab:3.2:Updates.repo

… und installieren die Pakete:

# yum install kolab

Sind die Pakete installiert, müssen wir vor dem Ausführen des Setup-Assistenten von Kolab, unbedingt noch ein paar Zeilen einer Python-Datei überprüfen. Die aktuelle Version (3.2) enthält einen unscheinbaren aber ziemlich fatalen Bug, den es zu beheben gilt. Tun wir das nicht, lässt sich der amavisd service (Spam- und Virenfilter) nicht starten und wir können keine Mails empfangen. (Fehlermeldung: Start amavisd: drop_priv: No such username: [FAILED])

# nano /usr/lib/python2.6/site-packages/pykolab/setup/setup_mta.py

In der Datei die Sektion mit der Anfangszeile

if os.path.isdir(‘/etc/amavisd’):

suchen und falls nötig folgende Zeilen

if os.path.isdir(‘/etc/amavisd’):
fp = open(‘/etc/amavisd/amavisd.conf’, ‘w’)
elif os.path.isdir(‘/etc/amavis’):
fp = open(‘/etc/amavis/amavisd.conf’, ‘w’)
fp.write(t.__str__())
fp.close()

abändern in

if os.path.isdir(‘/etc/amavisd’):
fp = open(‘/etc/amavisd/amavisd.conf’, ‘w’)
fp.write(t.__str__())
fp.close()
elif os.path.isdir(‘/etc/amavis’):
fp = open(‘/etc/amavis/amavisd.conf’, ‘w’)
fp.write(t.__str__())
fp.close()

Danach die Datei speichern und den Editor wieder verlassen.

Um einer weiteren Fehlermeldung vorzubeugen (ERROR Could not change permissions on /var/log/kolab/pykolab.log) ändern wir noch schnell die Berechtigungen der Datei pykolab.log. Falls die Datei noch nicht existiert, einfach mit leerem Inhalt anlegen.

# chown root:root /var/log/kolab/pykolab.log

Wurde alles oben Beschriebene befolgt, kann endlich das Konfigurations-Script gestartet werden:

# setup-kolab

Ihr könnt fast alle Standardeinstellungen belassen, das einzige was manuell festgelegt werden muss, ist die Zeitzone (“Europe/Berlin”). Das ganze sieht dann in etwa so aus (Passwörter unkenntlich gemacht):

Please supply a password for the LDAP administrator user ‘admin’, used to login
to the graphical console of 389 Directory server.

Administrator password [xxxxxxxxx]:

Please supply a password for the LDAP Directory Manager user, which is the
administrator user you will be using to at least initially log in to the Web
Admin, and that Kolab uses to perform administrative tasks.

Directory Manager password [xxxxxxxxx]:

Please choose the system user and group the service should use to run under.
These should be existing, unprivileged, local system POSIX accounts with no
shell.

User [nobody]:
Group [nobody]:

This setup procedure plans to set up Kolab Groupware for the following domain
name space. This domain name is obtained from the reverse DNS entry on your
network interface. Please confirm this is the appropriate domain name space.

example.com [Y/n]: y

The standard root dn we composed for you follows. Please confirm this is the root
dn you wish to use.

dc=example,dc=com [Y/n]: y

Setup is now going to set up the 389 Directory Server. This may take a little
while (during which period there is no output and no progress indication).

Shutting down dirsrv:
server… [ OK ]
Starting dirsrv:
server… [ OK ]

Please supply a Cyrus Administrator password. This password is used by Kolab to
execute administrative tasks in Cyrus IMAP. You may also need the password
yourself to troubleshoot Cyrus IMAP and/or perform other administrative tasks
against Cyrus IMAP directly.

Cyrus Administrator password [xxxxxxxxx]:

Please supply a Kolab Service account password. This account is used by various
services such as Postfix, and Roundcube, as anonymous binds to the LDAP server
will not be allowed.

Kolab Service password [xxxxxxxxx]:
Shutting down postfix: [ OK ]
Starting postfix: [ OK ]
Shutting down amavisd: The amavisd daemon is apparently not running, no PID file /var/run/amavisd/amavisd.pid
[FAILED]

Starting amavisd: [ OK ]

Stopping clamd.amavisd: [FAILED]
Starting clamd.amavisd:
LibClamAV Warning: **************************************************
LibClamAV Warning: *** The virus database is older than 7 days! ***
LibClamAV Warning: *** Please update it as soon as possible. ***
LibClamAV Warning: **************************************************
[ OK ]
Stopping wallaced: [FAILED]
Starting wallaced: [ OK ]
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]

Please supply a root password for MySQL. This password will be the administrative
user for this MySQL server, and it should be kept a secret. After this setup
process has completed, Kolab is going to discard and forget about this password,
but you will need it for administrative tasks in MySQL.

MySQL root password [xxxxxxxxx]:

Please supply a password for the MySQL user ‘kolab’. This password will be used
by Kolab services, such as the Web Administration Panel.

MySQL kolab password [xxxxxxxxx]:

Please supply the timezone PHP should be using. You have to use a Continent or
Country / City locality name like ‘Europe/Berlin’, but not just ‘CEST’.

Timezone ID [UTC]: Europe/Berlin

Please supply a password for the MySQL user ’roundcube’. This password will be
used by the Roundcube webmail interface.

MySQL roundcube password [xxxxxxxxx]:
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
Stopping kolab-saslauthd: [FAILED]
Starting kolab-saslauthd: [ OK ]
Shutting down cyrus-imapd: [FAILED]
Starting cyrus-imapd: [ OK ]
Stopping kolabd: [FAILED]
Starting kolabd: [ OK ]

Die [FAILED]-Meldungen stellen in obigem Fall kein Problem dar. Es ist normal, dass ein Dienst nicht gestoppt werden kann wenn dieser noch gar nicht läuft.

Kopiert euch unbedingt eure Ausgabe des Skriptes und speichert diese in eine (sichere) Datei ab, da gerade einige wichtige Passwörter festgelegt wurden.

Geschafft!  Hat alles geklappt können wir den Kolab-Admin-Panel unter der Adresse http://example.com/kolab-webadmin aufrufen und uns mit dem Nutzer “cn=Directory Manager” anmelden. Das zugehörige Passwort wurde vorher festgelegt und ist in der Ausgabe einsehbar.
kolab1
Unter “Benutzer” legen wir unseren ersten Kolab-User an. Hier können E-Mail-Adressen, Passwort, Speicherplatz usw. festgelegt werden.
kolab2
Der gerade erstellte Nutzer kann sich dann unter http://example.com/roundcubemail in sein Webmail-Konto einloggen und gleich mal den E-Mail Ein- und Ausgansserver testen.
kolab3
E-Mails, Adressbuch, Kalender und Aufgaben können über einen integrierten ActiveSync Server gesynct werden. Die URL dazu lautet http://example.com/Microsoft-Active-Sync Die Einrichtung auf dem Smartphone klappte bei mir sofort.
Screenshot_2014-03-26-22-39-59
Wer wie ich das Webverzeichnis umbenennen will (bspw. in activesync statt Microsoft-Active-Sync), muss noch eine Datei anpassen und den ScriptAlias ändern:

# nano /etc/httpd/conf.d/kolab-syncroton.conf

Der ScriptAlias ist wie folgt anzupassen:

ScriptAlias /activesync /usr/share/kolab-syncroton/index.php

Ein

# service httpd restart

übernimmt die Einstellungen. Im nächsten Schritt installieren wir ownCloud und integrieren diese in die Kolab Webmail-GUI.

6. ownCloud + Kolab-Integration
Die ownCloud Pakete sind zwar im EPEL-Repository enthalten, diese sind aber ziemlich veraltet. Um ownCloud in der aktuellen Version 6 zu installieren legen wir ein neues Repository an:

# cd /etc/yum.repos.d
# wget http://download.opensuse.org/repositories/isv:ownCloud:community/CentOS_CentOS-6/isv:ownCloud:community.repo

Diesmal können wir gleich mit der Installation loslegen.

# yum install owncloud

Danach wieder mal den http-server neu starten:

# service httpd restart

Die Grundkonfiguration starten wir indem wir die URL http://example.com/owncloud aufrufen. Dort legen wir erst einmal unser Administratoren-Konto an. Falls eine Integration von ownCloud in die Kolab-Weboberfläche gewünscht ist, müssen wir die selben Login Daten (Name und Passwort) wie bei Kolab verwenden. Danach wählen wir die Option “Fortgeschritten” und als Datenbank MySQL. Als Datenbank-Benutzer tragen wir “root” ein. Das Datenbank-Passwort wurde, wenn nicht manuell eingegeben, vom Kolab-Setup-Assistenten generiert und ist in der (hoffentlich) von euch abgespeicherten Datei zu finden. Als Datenbank-Name legen wir “ownclouddb” (ohne Anführungszeichen) fest. Diese wird dann automatisch erstellt. bei Datenbank-Host tragen wir noch localhost ein und wenn alles korrekt ausgefüllt ist, schließen wir die Installation ab.

Unsere DatenCloud können wir jetzt weiter unter http://example.com/owncloud nutzen. Es wäre aber schön, wenn wir von der Kolab-Oberfläche direkt auf unsere Daten zugreifen könnten. Das ist mithilfe eines Plugins möglich. Die Entwickler weisen zwar daraufhin, dass das ganze noch experimentell ist und noch nicht für den Produktiveinsatz gedacht ist, bis auf das Plugin-eigene Theme hat aber bei mir bis jetzt alles wunderbar geklappt:
kolabowncloud
Das Plugin ist zwar in Kolab schon vorhanden (noch nicht aktiviert), aber mit der vorinstallierten Version wollte es bei mir irgendwie nicht klappen. Deswegen löschen wir den vorhandenen Plugin-Ordner und ersetzen ihn mit einer neueren Version. Die offizielle, aktuelle Version findet ihr hier. Alternativ habe ich das Plugin für euch in eine zip gepackt

# rm -Rf /usr/share/roundcubemail/plugins/owncloud
# unzip owncloud.zip /usr/share/roundcubemail/plugins/

Bevor wir das Plugin konfigurieren und aktivieren, müssen wir in der ownCloud-Weboberfläche im Adminbereich die App “LDAP user and group backend” aktivieren und einrichten. Dazu brauchen wir wieder das Passwort vom “cn=Directory Manager” (siehe Screenshots)
owncloud1
owncloud2
Wenn das grüne Lämpchen leuchtet, müssten die Einstellungen korrekt sein ;) Danach machen wir uns ein wenig an den config-Dateien zu schaffen. Dazu bitte aus den Weboberflächen von ownCloud und Kolab ausloggen.

# nano /usr/share/roundcubemail/config/config.inc.php

Im Plugins array der Datei das plugin ‘owncloud’ hinzufügen. Bei der Gelegenheit kommentieren wir gleich das Plugin ‘kolab_files’ aus, da dieses nach erfolgreicher Installation nicht mehr benötigt wird.

// Plugins
$config['plugins'] = array(
‘kolab_auth’,
‘acl’,
‘archive’,
‘calendar’,
‘jqueryui’,
‘kolab_activesync’,
‘kolab_addressbook’,
‘kolab_config’,
‘kolab_delegation’,
//’kolab_files’,
‘kolab_folders’,
‘libkolab’,
‘libcalendaring’,
‘managesieve’,
‘newmail_notifier’,
‘odfviewer’,
‘password’,
‘redundant_attachments’,
‘tasklist’,
‘threading_as_default’,
// contextmenu must be after kolab_addressbook (#444)
‘contextmenu’,
‘owncloud’,
);

Das Plugin ist jetzt aktiviert, aber noch nicht konfiguriert. Dazu müssen wir noch ein paar Dateien kopieren und zwei config-Dateien anpassen.

# cd /usr/share/roundcubemail/plugins/owncloud/copy_to_owncloud
# cp -R * /var/www/html/owncloud/
# cd /usr/share/roundcubemail/plugins/owncloud/
# cp config.inc.php.dist config.inc.php
# nano config.inc.php

Die Datei config.inc.php muss wie folgt angepasst werden (Fettschrift):

<?php

// ownCloud URL
$rcmail_config['owncloud_url'] = ‘http://example.com/owncloud‘;

// authentication exchange secret
// has to be the same as the value for ‘kolabsecret’ in owncloud config
$rcmail_config['owncloud_secret'] = ‘sdfxs2d3‘;

Statt “sdfx2d3″ bitte eine eigene, beliebige Zeichenfolge festlegen. Weiter gehts mit

# nano /var/www/html/owncloud/config/config.php

Dort müssen wir im config array noch folgendes hinzufügen:

‘kolaburl’ => ‘http://example.com/roundcubemail‘,
‘kolabsecret’ => ‘sdfx2d3‘,

Dabei ist darauf zu achten, dass der Wert bei ‘kolabsecret’ mit dem Wert von ‘owncloud_secret’ aus der vorigen Datei übereinstimmt. Danach folgt wieder ein

service httpd restart

um die Einstellungen zu übernehmen. Wir müssen uns jetzt noch kurz in die ownCloud Weboberfläche unter http://example.com/owncloud einloggen. Dort sollte unter Apps nun die Kolab_Auth App aufgeführt sein. Diese aktivieren wir und loggen uns wieder aus.

Das wars auch schon. In der Kolab-Oberfläche (http://example.com/roundcubemail) sollten wir jetzt über den Reiter “Dateien” Zugriff auf unsere Daten-Cloud haben. Zusätzlich können noch die ownCloud Apps “Calender” und “Contacts” deaktiviert werden, Kalender und Kontakte haben wir bereits in der Kolab-Übersicht.

7. Plex Media Server
Wer auf seinem Server viel Speicherplatz zur Verfügung hat, für den bietet es sich an einen Medien Server zu installieren. Mein Favorit in diesem Bereich ist der Plex Media Server. Die Installation ist verhältnismäßig einfach. Dieses mal müssen wir auch keine config-files editieren ;)

# cd /tmp
# wget http://downloads.plexapp.com/plex-media-server/0.9.9.7.429-f80a8d6/plexmediaserver-0.9.9.7.429-f80a8d6.x86_64.rpm
# yum localinstall plexmediaserver-0.9.9.7*

# rm -rf plexmediaserver-0.9.9.7*
# /etc/init.d/plexmediaserver start

Zum Konfigurieren über den (lokalen) Webbrowser folgende URL aufrufen: http://localhost:32400/manage und den Setup Assistenten starten. Da wir aber (wahrscheinlich) auf einen entfernten Rechner ohne grafische Oberfläche zugreifen, müssen wir uns noch mittels

# ssh root@example.com -L 32400:localhost:32400

einloggen, dann können wir die oben genannte URL auch lokal auf der Client-Seite aufrufen. Damit der Plex Media Server für uns auch von überall aus nutzbar ist, müssen wir einen (kostenlosen) myPlex Account anlegen. Alle weiteren Einstellungen können im Setup-Assistenten konfiguriert werden (selbsterklärend). Möglicherweise weist der Assistent auf einen Fehler hin:

Es gab ein Problem beim Herstellen der Verbindung mit deinem Server

Diese kann aber getrost ignoriert werden. Zumindest bei meiner Installation funktioniert trotzdem alles tadellos. Nachdem der Assistent durch ist, können wir uns unter http://example.com:32400/web/ mit underem myPlex Account einloggen.

8. SSL / HTTPS Verschlüsselung
Eine HTTPS-Verschlüsselung ist natürlich kein Muss. Ein anständiger Server sollte aber auch eine verschlüsselte Verbindung anbieten können. Wir brauchen dazu allerdings ein Zertifikat, das wir uns a) selbst erstellen, b) von einem kostenlosen Dienst erstellen lassen oder c) von einem kostenpflichtigen Dienst erstellen lassen. Für welche Option ihr euch letztendlich entscheidet liegt bei euch. Da ich meinen VPS bis zu diesem Zeitpunkt ausschließlich allein verwende, rentiert sich es nicht für ein Zertifikat zu zahlen. Erstellen wir uns unser Zertifikat selbst, erhält jeder zukünftige Besucher des Servers eine dicke Warnmeldung bevor er die Seite betreten kann. Es gibt aber kostenlose Zertifizierungsstellen, die auch von einigen (aber eben nicht allen) Browsern und Geräten unterstützt werden. Ich habe mich also für die Option b) und somit für den Mittelweg entschieden und mir ein Zertifikat von caCert geholt.

Bevor wir aber überhaupt etwas tun können, sollten wir erstmal openssl und mod_ssl installieren:

# yum install openssl mod_ssl

Eine Anleitung wie ihr an das Zertifikat kommt, lasse ich hier mal aus, die gibts im Internet wie Sand am Meer. Ich persönlich bin nach der, nebenbei sehr guten und leicht verständlichen, Anleitung meines Blogger-Kollegen Thomas Leister vorgegangen. Die ist zwar generell für Ubuntu gedacht, bis zum Punkt “Zertifikat in Apache übernehmen” ist die Vorgehensweise aber die selbe.

Haben wir uns ein Zertifikat geholt und dieses mitsamt den Keys in den entsprechenden Verzeichnissen abgelegt, müssen in der httpd.conf noch ein paar Änderungen durchgeführt werden.

# nano /etc/httpd/conf/httpd.conf

Wir suchen folgende Zeile und kommentieren diese aus:

NameVirtualHost *:80

Am Ende der Datei fügen wir zwei virtuelle Hosts hinzu. Somit ist eine verschlüsselte sowie eine unverschlüsselte Verbindung zum Server möglich.

<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName example.com
</VirtualHost>

<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName example.com
SSLEngine on
SSLCertificateKeyFile /etc/myssl/private/key.pem
SSLCertificateFile /etc/myssl/public/cert.pem
</VirtualHost>

Die Domain und die Verzeichnispfade müsst ihr natürlich wieder anpassen. Einige Zeilen der ssl.conf müssen ebenfalls editiert werden:

# nano /etc/httpd/conf.d/ssl.conf

Hier wieder Pfad und Dateinamen anpassen und ggf. durch Entfernen des ‘#’ aktivieren.

SSLCertificateFile /etc/myssl/public/cert.pem
SSLCertificateKeyFile /etc/myssl/private/key.pem

Nach einem Neustart des httpd service ist unser Server von nun auch unter https://example.com erreichbar.

# service httpd restart

In unserem Fall sind wir aber noch nicht fertig. Damit Kolab und dessen Plugins das https-Protokoll fehlerfrei verwenden können, müssen wir noch ein paar Befehle in die Kommandozeile tippen:

# sed -i -e ‘/kolab_ssl/d’ /etc/roundcubemail/libkolab.inc.php
# sed -i -e ‘s/http:/https:/’ /etc/roundcubemail/kolab_files.inc.php
# sed -i -e ‘/^?>/d’ /etc/roundcubemail/config.inc.php

#cat >> /etc/roundcubemail/config.inc.php << EOF
\$config['kolab_http_request'] = array(
‘ssl_verify_peer’ => true,
‘ssl_verify_host’ => true,
‘ssl_cafile’ => ‘/etc/pki/tls/certs/ca-bundle.crt’
);
EOF

# cat >> /etc/roundcubemail/config.inc.php << EOF
# caldav/webdav
\$config['calendar_caldav_url'] = “https://server.example.com/iRony/calendars/%u/%i”;
\$config['kolab_addressbook_carddav_url'] = ‘https://server.example.com/iRony/addressbooks/%u/%i’;
EOF

Soviel zu Kolab. Bleibt nur noch die (Nach-)Konfiguration von IMAP Server (Cyrus), SMTP-Server (Postfix) und Directory Server ;). Bevor ich das aber jetzt alles aufliste, verlinke ich lieber gleich zum entsprechenden Bereich des offiziellen Kolab-Howtos.

Das wars! Es bleiben natürlich Kleinigkeiten wie die Konfiguration der Mobilgeräte, Neu-Anlegen bzw. Importieren von Kontakt-, Mail- und Kalenderdaten, möglicherweise die Einrichtung von Sub-Domains (wie z.B. cloud.example.com), Weiterleitungen und so weiter und so fort. Der größte und schwierigste Teil der Arbeit dürfte aber hinter uns liegen.

Ich hoffe, ich konnte den ein oder anderen mit diesem Tutorial weiter helfen. Da es doch etwas lang geworden ist, werde ich hier und da mal Anpassungen machen und vielleicht auch neue Punkte hinzufügen. Kritik und Beanstandungen in den Kommentaren (falls ich mich wo vertan haben sollte) sind ausdrücklich erwünscht :)

The post Mit dem eigenen (VPS/Root-)Server weg von Google: Centos 6.5 + Kolab 3.2 + Owncloud 6 + Plex appeared first on immersia.de.


grote's picture
Wed, 2014-03-26 17:18

Today is Document Freedom Day which started out for documents in the OOXML days, but now is much more generally about Open Standards. This is a great opportunity to show you how Kolab uses Open Standards all the way down to the storage layer.

Since Kolab is a lot about email, it uses SMTP (RFC 821) and IMAP (RFC 1730) to send and store emails which is by itself not overly exciting since at least in the free world, most email software does that. But Kolab goes further and uses IMAP as a NoSQL storage engine and therefore gets all the scalability, ACLs and sharing from IMAP for free. It uses the IMAP METADATA Extension (RFC 5464) to storage other content and even configuration in IMAP folders. Since Kolab is a Groupware Solution, it stores contacts, events and tasks in there. Of course, it does so using Open Standards as well. Contacts are stored in the xCard (RFC 6351) format and tasks as well as events are stored in the xCal (RFC 6321) format. All those objects are then encapsulated in a MIME message according to RFC 2822.

The advantage of that is that your personal data is not scattered all over the place, but in one central IMAP database which you can easily back up (e.g. with offlineimap) or move to another server (e.g. with imapsync). The new version of Kolab supports file storage and the default is to store them in IMAP as well.

Unfortunately, not every IMAP client understands the METADATA extension and displays the other data as you would like. Therefore, Kolab offers other protocols to access that data. For your calendars, Kolab uses CalDAV (RFC 4791). Address book with contacts can be synchronized using CardDAV (RFC 6352) and files are available via WebDAV (RFC 2518).

For a proper groupware it is important that you can invite people to events or assign them tasks even if those people are using other systems on other servers. To achieve this, Kolab uses iTIP (RFC 5546) invitations and sometimes has to implement workarounds, because other clients are not respecting the standard fully. Unfortunately, this is a problem Kolab faces with all standards that are for inter-operating with other software.

To make sure all those different standards interact well together in one system and to be able to further enhance the functionality, the Kolab community uses a defined KEP process. KEP is short for Kolab Enhancement Proposal and works similar to Python’s PEP or XMPP’s XEP.

Happy Document Freedom Day! :)


Wed, 2014-03-26 08:00

Introduction

Kolab Sys has been putting a lot of effort
into developing
various components to provide a turn key enterprise communication
platform. Unfortunately for me,
they seem to be more of a CentOS / RedHat shop. Also, I'm not an
enterprise.

Paul Boddie has been doing lots of work trying adapt the Kolab Sys
packages for Debian.
See Minimal Kolab and
Kolab, Debian, LDAP and XMPP
for example.

For me the Kolab packages made too many assumptions about what my
environment should
look like -- that it should be using 389-ds, Cyrus IMAP, MySQL, Postfix,
and Apache-mod-php.

However I've been a long time Debian user so I've been running OpenLDAP,
Dovecot, and as a Python
programmer I've been using apache2-mpm-worker and mod-wsgi and didn't
want to switch to
apache2-mpm-prefork.

After seeing Paul's posts about the Kolab
setup-kolab,
dependency tree and then seeing Kolab from Source.
I had the idea, what if instead of trying to install all of Kolab and
use setup-kolab, I tried
to install Kolab piecemeal and manually configure just those components for my
environment?

One question I have is how many of the Kolab components do you need to
be running before you can be considered to be running "Kolab"?

Kolab 0

The most minimal way to get started with Kolab, is to run an IMAP server
and use KDEPIM
with libkolab and libkolabxml linked in. With that (and some
configuration in akonadi) you can store contacts
and calendar information on your IMAP server and access it from other
KDEPIM clients on other computers.

I configured this using akonadiconsole. On the agents tab I picked Add
a new agent, if the kolab format
libraries were installed Kolab should be listed in the popup list of agents.
Once its added you may need to tell it to create Kolab Folders.

On my dovecot it created folders named ~/Maildir/.INBOX.Calendar,
~/Maildir/.INBOX.Contacts and a few others.
putting the folders into an .INBOX folder is a bit suboptimal, but I can
put up with it.

KolabDroid

Having ones calendar and contacts synchronized between your phone and
your computer is really convienent.

The thing that would've been simplest to setup is
KolabDroid, an android application
that tries to do the synchronization like KDEPIM does over IMAP.
Although it warned that it would
eat all my data. It did manage to load all of my contacts from my mail
server to my phone pretty reliably. The
calendar however was a different story. I think in the worst case some
events appeared in the wrong week. (Or I really failed at reading).

Moving toward Kolab

I could try to fix KolabDroid, but in addition to not wanting to set up
an android development
environment, I thought it would be better to try and test the packaging
for the official Kolab components providing synchronization via WebDav.

I started to install roundcube, roundcube-plugins-kolab, chwala and
irony via git checkout method but
ended up with a mess of symlinks and scattered configuration files and
so decided to try to use
packages.

A piece of Kolab

For my goal of syncing my calendar and contacts I need iRony
and its dependencies.

  • php-kolab, php-kolabformat
  • Roundcube
  • Roundcube-plugins-kolab
  • Chwala
  • iRony

There's several sources for those components. See Paul's review of
repositories
for more information.
For the packages I built, mostly I imported KolabSys's
OBS packages and
in some cases merged in Paul's versions.

Dovecot 2.2.10 had enough metadata support for my tests, so I was able
to avoid having to build the dovecot-metadata
package.

PHP Kolab

I needed the updated php-kolab components I grabbed the source packages
from obs using

dget http://obs.kolabsys.com:82/Kolab:/3.1/Debian_7.0/libkolab_0.5.0-0~kolab3.dsc
dget http://obs.kolabsys.com:82/Kolab:/3.1/Debian_7.0/libkolabxml_1.0.1-0~kolab2.dsc

extracted them, and rebuilt them, using debuild

Roundcubemail

I pushed the git-buildpackage repository I used for roundcubemail.
In this case I used the older 1.0 version of roundcube instead of
Kolab's 1.1 version. Since I imported both versions
into my repository I had to make a topic branch diane-1.0 that contains
my changes to work with php-fpm.

That is enabled by this patch,
which lets me satisfy the php requirement with php5-fpm.

To configure it for PostgreSQL I followed along the roundcube
documentation
which was edit /etc/roundcubemail/config.inc.php and set:

$config['db_dsnw'] = 'pgsql://roundcube:password/roundcubeemail'

I went through a complex process of creating the database as the
postgres super-user, then creating the roundcube user,
and then manually changing the ownership of all the tables and sequences
using:

alter table X owner to roundcube;
alter sequence X owner to roundcube;

It might be a reasonable solution to create the roundcube user with the
permission to create a database.

Roundcube-plugins-kolab

Effectively I just used the KolabSys OBS
package.
Though I did import it into my git repository and built my own
.deb from that. (using the diane-3.1 branch as the master for gbp).

I had to do more manual configuration here.

edit /etc/roundcubemail/calendar.inc.php to change
$rcmail_config['calendar_driver'] from "database" to
"kolab".

in /etc/roundcubemail/kolab_auth_addressbook.php configure
kolab_auth_addressbook.

$rcmail_config['kolab_auth_addressbook'] = Array(
     'name'                      => 'Kolab Auth',
     'hosts'                     => Array('localhost'),
     'port'                      => 389,
     'use_tls'                   => false,
     'user_specific'             => false,
     'base_dn'                   => 'ou=People,dc=example,dc=org',
     'bind_dn'                   => 'uid=kolab-service,ou=Special Users,dc=example,dc=org',
     'bind_pass'                 => 'password',
     'writable'                  => false,
     'ldap_version'              => 3,       // using LDAPv3
     'fieldmap'                  => Array(
             'name'              => 'displayname',
             'email'             => 'mail',
             'email:alias'       => 'alias',
             'role'              => 'nsroledn',
         ),
     'sort'                      => 'displayname',
     'scope'                     => 'sub',
     'filter'                    => '(objectClass=*)',
     'fuzzy_search'              => true,
     'sizelimit'                 => '0',
     'timelimit'                 => '0',
     'groups'                    => Array(
             'base_dn'           => 'ou=Groups,dc=example,dc=org',
             'filter'            => '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))',
             'object_classes'    => Array('top', 'groupOfUniqueNames'),
             'member_attr'       => 'uniqueMember',
         ),
);

I decided to change the default kolab_auth_filter to just be against
inetOrgPerson and not kolabInetOrgPerson,
as I wasn't ready to work on importing the kolabInetOrgPerson schema.

so:

$rcmail_config['kolab_auth_filter'] = '(&(objectClass=kolabInetOrgPerson)(|(uid=%u)(mail=%fu)(alias=%fu)))';

changed into:

$rcmail_config['kolab_auth_filter'] = '(&(objectClass=inetOrgPerson)(|(uid=%u)(mail=%fu)(alias=%fu)))';

It looks like I replaced the ldap_authentication.php from the package with a version I
had copied from a system setup the official setup-kolab way.

    // The id of the LDAP address book (which refers to the rcmail_config['ldap_public'])
// or complete addressbook definition array.
$config['kolab_auth_addressbook'] = Array(
    'name'                      => 'Kolab Auth',
    'hosts'                     => Array('localhost'),
    'port'                      => 389,
    'use_tls'                   => false,
    'user_specific'             => false,
    'base_dn'                   => 'ou=People,dc=example,dc=org',
    'bind_dn'                   => 'uid=kolab-service,ou=Special Users,dc=example,dc=org',
    'bind_pass'                 => 'password',
    'writable'                  => false,
    'ldap_version'              => 3,       // using LDAPv3
    'fieldmap'                  => Array(
            'name'              => 'displayname',
            'email'             => 'mail',
            'email:alias'       => 'alias',
            'role'              => 'nsroledn',
        ),
    'sort'                      => 'displayname',
    'scope'                     => 'sub',
    'filter'                    => '(objectClass=*)',
    'fuzzy_search'              => true,
    'sizelimit'                 => '0',
    'timelimit'                 => '0',
    'groups'                    => Array(
            'base_dn'           => 'ou=Groups,dc=example,dc=org',
            'filter'            => '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))',
            'object_classes'    => Array('top', 'groupOfUniqueNames'),
            'member_attr'       => 'uniqueMember',
        ),
);
// This will overwrite defined filter
$config['kolab_auth_filter'] = '(&' . '(objectclass=inetorgperson)' . '(|(uid=%u)(mail=%fu)(alias=%fu)))';

// Use this fields (from fieldmap configuration) to get authentication ID
$config['kolab_auth_login'] = 'email';

// Use this fields (from fieldmap configuration) for default identity
$config['kolab_auth_name']  = 'name';
$config['kolab_auth_alias'] = 'alias';
$config['kolab_auth_email'] = 'email';

if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) {

    // Login and password of the admin user. Enables "Login As" feature.
    $config['kolab_auth_admin_login']    = 'cyrus-admin';
    $config['kolab_auth_admin_password'] = 'password';

    $config['kolab_auth_auditlog'] = true;
}

// Administrative role field (from fieldmap configuration) which must be filled with
// specified value which adds privilege to login as another user.
$config['kolab_auth_role']       = 'role';
$config['kolab_auth_role_value'] = 'cn=kolab-admin,dc=example,dc=org';

// Administrative group name to which user must be assigned to
// which adds privilege to login as another user.
$config['kolab_auth_group'] = 'Kolab Helpdesk';

if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . '/' . basename(__FILE__))) {
    include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . '/' . basename(__FILE__));
}

The kolab auth components really want a working LDAP server, so I set up
OpenLDAP and created a very minimal directory
using an LDIF file similar to this one. Kolab has a "Special Users" tree
for some of its administrative users, in
addition to the normal People and Group trees.

The LDIF file below provides a very minimal configuration
The real 389-ds tree includes many other rules defining
access control conventions. I suspect higher level
Kolab components will depend on 389-ds for its specific
ACI syntax.

dn: dc=example,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.org
dc: example
structuralObjectClass: organization

dn: cn=admin,dc=example,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: base64-password
structuralObjectClass: organizationalRole

dn: ou=Special Users,dc=example,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Special Users
description: Special Administrative Accounts
structuralObjectClass: organizationalUnit

dn: uid=kolab-service,ou=Special Users,dc=example,dc=org
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
uid: kolab-service
givenName: Kolab
sn: Service
cn: Kolab Service
userPassword:: base64-password
structuralObjectClass: inetOrgPerson

dn: ou=People,dc=example,dc=org
objectClass: top
objectClass: organizationalUnit
ou: People
structuralObjectClass: organizationalUnit

dn: ou=Groups,dc=example,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Groups
structuralObjectClass: organizationalUnit

dn: uid=user,ou=People,dc=example,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
givenName: User
sn: User
cn: User User
preferredLanguage: en_US
structuralObjectClass: inetOrgPerson
uid: user
userPassword:: base64-password

Also the libkolab plugin needs some database configuration and there
isn't a shipping postgres version. I commited an
updated version

I chose to use Postres' XML type in my schema, this later
caused trouble, as I had a really old contact
whose data wasn't invalid XML. It turns out that Postgre
actually validates the XML being loaded into it.

Chwala

The default chwala package includes .htaccess files to configure the php environment and so depends
on apache2-mod-php. Changing to php5-fpm caused a variety of problems as without mod-php apache can't
parse the php specific configuration options in the .htaccess files.

Thankfully php >= 5.3 provided at least one solution in that it can read .user.ini files (at least when
running under fastcgi.) So I just renamed the .htaccess files to .user.ini and was good to go.

In /etc/roundcubeemail/kolab_files.inc.php I changed kolab_files_url to:

``$rcmail_config['kolab_files_url'] = 'https://<hostname>/chwala/';``

Make sure <hostname> is the name you're using to connect to roundcube. I first tried localhost and the roundcube
files UI wouldn't work. Once I changed it to my real hostname, it suddenly started working.

Here's my chwala package repository

iRony

The final component is iRony. I didn't need to do any special configuration once I had
all the previous components configured. Although I did modify the package slightly to
not require mod-php.

iRony repository

Conclusion

Once all that was configured I installed DAVdroid from F-Droid, and
pointed it at:

https://<hostname>/iRony/

and synced my contacts & calendars.

There's still many things not tested. I haven't made any attempt to use shared
folders, I don't have any of Kolab's anti-spam software, I don't even know
if the pykolab library will work in this environment yet.

While I was setting things up I did discover that I didn't enable activesync,
I think that requires the kolab-syncotron component. If one is interested in
that protocol instead of CalDAV/CardDAV you might want to investigate installing
it.

If you have any questions you can find me on twitter @alienghic or freenode/OFTC as detrout.


Andreas Cordes's picture
Thu, 2014-03-13 21:54

Today I played a little with the apache config to improve my performance using apache.

I noticed that my vHost setup was not working so I fixed this at first.  After a while I was wondering that I didn't receive any mail since then... Ok, something is now "kaputt" :-)

Now I had a look at the config of kolab in the apache sites-enabled directory. Kolab adds some entries in this directory, but thos "may" work for vHosts but not for my setup.

Simply moving the kolab-syncroton from sites-available to conf.d solved the problem for me.

Not the best, may be, but it's working.

greets


Andreas Cordes's picture
Tue, 2014-03-11 23:31

Hi,

first of all I wish to say thanks for your feedback on my posts :-)

So now the groupware is up and running and the next steps are planned already (XMPP = Chat/Messaging, OwnCloud).

The roundcube web frontend is a bit slow for daily work, and it reconnects to the imap server very often.

Sending mails from my own domain (dynamic IP) uses a smart host (mailjet, costs less and 200 mails/day are free :-)) and receiving mails also takes sometime because of Spam/Virus detection.

So the next parts are also performance improving.

Some topics to check are

memory usage (count of server process fro IMAP, Apache ...)
Proxy for roundcube connection to IMAP
deactivating Virus/Spam detection and use some header/body checks instead (not for production use of course)

If you have more cheats and hints to increase the performance, that would be nice.

greets