Blogs

How to fix error when moving events between calendars

Recently, I noticed "Failed to save changes" error when tried to move events between distinct calendars.
After a short investigation I found that this bug is already fixed, but not packaged for an easy upgrade, so I will shortly describe how to apply fix for Debian Wheezy and Kolab 3.3.

The above-mentioned bug is already fixed in roundcubemail-plugins-kolab repository.
You can jump directly to the a3d5f717 commit and read details.

Quick Remedy

We need to replace calendar and libkolab plugins.

Download code from already fixed roundcubemail-plugins-kolab repository to /tmp temporary directory.

# cd /tmp
# wget http://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Rename mentioned roundcubemail plugins directories that will be replaced in next step.

# mv /usr/share/roundcubemail/plugins/{calendar,calendar.before_fix}
# mv /usr/share/roundcubemail/plugins/{libkolab,libkolab.before_fix}

Extract both plugins from downloaded archive.

# tar xvfz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545/plugins/{calendar,libkolab} --strip-components 2

Install and configure plugins.

# mv {calendar,libkolab} /usr/share/roundcubemail/plugins/
# ln -s /etc/roundcubemail/calendar.inc.php /usr/share/roundcubemail/plugins/calendar/config.inc.php
# ln -s /etc/roundcubemail/libkolab.inc.php /usr/share/roundcubemail/plugins/libkolab/config.inc.php

Remove downloaded archive.

# rm roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Simple and easy.

How to fix error when moving events to between calendars

Recently, I noticed "Failed to save changes" error when tried to move events between distinct calendars.
After a short investigation I found that this bug is already fixed, but not packaged for an easy upgrade, so I will shortly describe how to apply fix for Debian Wheezy and Kolab 3.3.

The above-mentioned bug is already fixed in roundcubemail-plugins-kolab repository.
You can jump directly to the a3d5f717 commit and read details.

Quick Remedy

We need to replace calendar, and libkolab plugins.

Download code from already fixed roundcubemail-plugins-kolab repository to /tmp temporary directory.

# cd /tmp
# wget http://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Rename mentioned roundcubemail plugins directories that will be replaced in next step.

# mv /usr/share/roundcubemail/plugins/{calendar,calendar.before_fix}
# mv /usr/share/roundcubemail/plugins/{libkolab,libkolab.before_fix}

Extract both plugins from downloaded archive.

# tar xvfz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545/plugins/{calendar,libkolab} --strip-components 2

Install and configure plugins.

# mv {calendar,libkolab} /usr/share/roundcubemail/plugins/
# ln -s /etc/roundcubemail/calendar.inc.php /usr/share/roundcubemail/plugins/calendar/config.inc.php
# ln -s /etc/roundcubemail/libkolab.inc.php /usr/share/roundcubemail/plugins/libkolab/config.inc.php

Remove downloaded archive.

# rm roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Simple and easy.

Kolab 3.2 for Gentoo is ready to rumble

Just in time for the official Kolab 3.3 release, our Gentoo packages for Kolab 3.2 became stable and ready to use. This will clear the way for the upcoming release of Kolab 3.3 for Gentoo. Altough this release won't bring any major changes, it prepares the ground for upcoming developments and new features in Kolab 3.3. Further, with Kolab 3.2 we introduced an upgrade path between Kolab releases for Gentoo and we will try our best to keep updates as consistent and comfortable as possible.

Aaron Seigo's picture

Joining Kolab Systems

I've been a long time fan of Kolab, the free software collaboration and groupware system. I have recommended it, and even helped deploy it a few times, since it launched some ten years ago. I used it back then with KDE's Kontact, and still do to this day.

Kolab interested me because it had the opportunity to join such key free software products as LibreOffice (then Open Office) and Firefox in terms of importance and usage. Think about it: in a professional setting (business, government or educational) what key software tools are universally required? Certainly among them are tools to read and edit office documents; a world-class web browser; and collaboration software (email, calendaring, contacts, resource booking, notes, task lists, file sharing ...). The first two were increasingly well covered, but that last one? Not so much.

And then Kolab walked on to the stage and held out the promise of completing the trifecta.
However, there were years in between then and now when it was less obvious to me that Kolab had a glowing future. It was an amazing early-stage product that filled a huge gap in the free software stack, but development seemed to slow up and promotion was extremely limited. This felt like a small tragedy.

So when I heard that Kolab Systems was launching back in 2010 as a company centered around Kolab, I was excited: Could this be a vehicle which tows Kolab forward towards success? Could this new company propel Kolab effectively into the market which is currently the domain of proprietary products? Only time would tell ... I knew the founders personally, and figured that if anyone could pull this off it would be them. I also knew that they would work with freedom and upstream communities as priorities.

Four years later and Kolab Systems has indeed been successful in bringing Kolab significantly forward technologically and in adoption. Today Kolab is more reliable and has a spectacular set of features, thanks to the solid engineering team that has come together with the help and support of Kolab Systems.

roundcube's picture

Our Wish List for Encryption Browser Extensions

PGP encryption is one of the most frequently requested features for Roundcube and for good reasons more and more people start caring about end-to-end encryption in their everyday communication. But unfortunately webmail applications currently can’t fully participate in this game and doing PGP encryption right in web-based applications isn’t a simple task. Although there are ways and even some basic implementations, all of them have their pros and cons. And yet the ultimate solution is still missing.

Browser extensions to the rescue

In our opinion, the way to go is with a browser extension to do the important work and guard the keys. A crucial point is to keep the encryption component under the user’s full control which in the browser and http world can only be provided with a native browser plugin. And the good news is, there are working extensions available today. The most prominent one probably is Mailvelope which detects encrypted message bodies in various webmail applications and also hooks into the message composition to send signed and encrypted email messages with your favorite webmail app. Plus another very promising tool for end-to-end encryption is coming our way: p≡p. A browser extension is at least planned in the longer term. And even Google just started their own project with the recently announced end-to-end Chrome extension.

That’s a good start indeed. However, the encryption capabilities of those extensions only cover the message body but leave out attachments or even pgp/mime messages. Mostly because there extension has limited knowledge about webmail app and there’s no interaction between the web app and the extension. On the other side, the webmail app isn’t aware of the encryption features available in the user’s browser and therefore suppresses certain parts of a message like signatures. A direct interaction between the webmail and the encryption extension could help adding the missing pieces like encrypted attachment upload and message signing. All we need to do is to introduce the two components to each others.

Timotheus Pokorra's picture

Proxy for Kolab yum and apt-get repositories

On the Kolab IRC we have had some issues with apt-get talking about connection failed etc.

So I updated the blogpost from last year: http://www.pokorra.de/2013/10/downloading-from-obs-repo-via-php-proxy-file/

The port of the Kolab Systems OBS is now port 80, so there is not really a need for a proxy anymore. But perhaps it helps for debugging the apt-get commands.

I have extended the scripts to work for apt-get on Debian/Ubuntu as well, the original script was for yum only it seems.

I have setup a small php script on a server somewhere on the Internet.

In my sample configuration, I use a Debian server with Lighttpd and PHP.

Install:

apt-get install lighttpd spawn-fcgi php5-curl php5-cgi

changes to /etc/lighttpd/lighttpd.conf:

server.modules = (
        [...]
        "mod_fastcgi",
        "mod_rewrite",
)
 
fastcgi.server = ( ".php" => ((
                     "bin-path" => "/usr/bin/php5-cgi",
                     "socket" => "/tmp/php.socket",
                     "max-procs" => 2,
                     "bin-environment" => (
                       "PHP_FCGI_CHILDREN" => "16",
                       "PHP_FCGI_MAX_REQUESTS" => "10000"
                     ),
                     "bin-copy-environment" => (
                       "PATH", "SHELL", "USER"
                     ),
                     "broken-scriptfilename" => "enable"
                 )))
 
url.rewrite-once = (
    "^/obs\.kolabsys\.com/index.php" => "$0",
    "^/obs\.kolabsys\.com/(.*)" => "/obs.kolabsys.com/index.php?page=$1"
)

and in /var/www/obs.kolabsys.com/index.php:

How to monitor Kolab processes

I have been using self hosted Kolab Groupware everyday for quite a while now.
Therefore the need arose to monitor process activity and system resources using Monit utility.

Table of contents

Couple of words about monit

monit is a simple and robust utility for monitoring and automatic maintenance, which is supported on Linux, BSD and OS X.

Software installation

Debian Wheezy currently provides Monit 5.4.

To install it execute command:

$ sudo apt-get install monit

Monit daemon will be started at the boot time. Alternatively you can use standard System V init scripts to manage service.

mollekopf's picture

Putting the code where it belongs

I have been working on better ways to write asynchronous code. In this post I’m going to analyze one of our current tools, KJob, in how it helps us writing asynchronous code and what is missing. I’m then going to present my prototype solution to address these problems.

KJob

In KDE we have the KJob class to wrap asynchronous operations. KJob gives us a framework for progress and error reporting, a uniform start method, and by subclassing it we can easily write our own reusable asynchronus operations. Such an asynchronous operation typically takes a couple of arguments, and returns a result.

A KJob, in it’s simplest form, is the asynchronous equivalent of a function call:

int doSomething(int argument) {
    return getNumber(argument);
}
struct DoSomething : public KJob {
    KJob(int argument): mArgument(argument){}

    void start() {
        KJob *job = getNumberAsync(mArgument);
        connect(job, SIGNAL(result(KJob*)), this, SLOT(onJobDone(KJob*)));
        job->start();
    }

    int mResult;
    int mArgument;

private slots:
    void onJobDone(KJob *job) {
        mResult = job->result;
        emitResult();
    }
};

What you’ll notice immediately that this involves a lot of boilerplate code. It also introduces a lot of complexity in a seemingly trivial task. This is partially because we have to create a class when we actually wanted a function, and partially because we have to use class members to replace variables on the stack, that we don’t have available during an asynchronous operation.

So while KJob gives us a tool to wrap asynchronous operations in a way that they become reusable, it comes at the cost of quite a bit of boilerplate code. It also means that what can be written synchronously in a simple function, requires a class when writing the same code asynchronously.

Inversion of Control

A typical operation is of course slightly more complex than doSomething, and often consists of several (asynchronous) operations itself.

What in imperative code looks like this:

int doSomethingComplex(int argument) {
    return operation2(operation1(argument));
}

…results in an asynchronous operation that is scattered over multiple result handlers somewhat like this:

roundcube's picture

Update 1.0.3 released

We’re proud to announce the next service release to 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!

tobru's picture

CASino with Kolab LDAP backend


Contents

CASino is an easy to use Single Sign On (SSO) web application written in Ruby”

It supports different authentication backends, one of it is LDAP. It works very well with the
LDAP backend of Kolab. Just put the following configuration snippet into
your config/cas.yml:

production:
  authenticators:
    kolab:
      authenticator: 'LDAP'
      options:
        host: 'localhost'
        port: 389
        base: 'ou=People,dc=mydomain,dc=tld'
        username_attribute: 'uid'
        admin_user: 'uid=kolab-service,ou=Special Users,dc=mydomain,dc=tld'
        admin_password: 'mykolabservicepassword'
        extra_attributes:
          email: 'mail'
          fullname: 'uid'

You are now able to sign in using your Kolab uid and manage SSO users with the nice
Kolab Webadmin LDAP frontend.