Blogs

Andreas Cordes's picture

Migration to "Cubietruck" finished

Hi,

due to a new job since the beginning of the year and moving to a new country I was a bit stressed. In addition to this, my provider changed from IPv4 to IPv6 at a DSLite line.

So my port forwarding is no longer working and I had to organize all the stuff to get access to my mails again :-). Well, that's a disadvantage of my solution but I hope this will be solved somehow.

So my script to install Kolab on my truck:

export RELEASE=3.3
export RELEASEDIR=kolab_3.3_src
mkdir -p /mnt/kolab/$RELEASEDIR
mkdir -p /mnt/kolab/kolab_${RELEASE}_deb
echo "deb-src http://obs.kolabsys.com:82/Kolab:/$RELEASE/Debian_7.0/ ./" > /etc/apt/sources.list.d/kolab.list
echo "deb-src http://obs.kolabsys.com:82/Kolab:/$RELEASE:/Updates/Debian_7.0/ ./" >> /etc/apt/sources.list.d/kolab.list
#echo "deb http://kolab-deb.zion-control.org /" >> /etc/apt/sources.list.d/kolab.list
echo "Package: *" >  /etc/apt/preferences.d/kolab
echo "Pin: origin obs.kolabsys.com" >>  /etc/apt/preferences.d/kolab
echo "Pin-Priority: 501" >>  /etc/apt/preferences.d/kolab
wget -qO - http://obs.kolabsys.com:82/Kolab:/$RELEASE/Debian_7.0/Release.key | apt-key add -
wget -qO - http://obs.kolabsys.com:82/Kolab:/$RELEASE:/Updates/Debian_7.0/Release.key | apt-key add -
aptitude update
cd /mnt/kolab/$RELEASEDIR
echo Get debian sources
roundcube's picture

Security update 1.0.5 released

We just published a security update to the stable version 1.0.
Beside a recently reported Cross-Site-Scripting vulnerability,
this release also contains some bug fixes and improvements we
found 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!

greve's picture

Key Update

I’m a fossil, apparently. My oldest PGP key dates back to 1997, so around the time when GnuPG just got started – and I switched to it early. Over the years I’ve been working a lot with GnuPG, which perhaps isn’t surprising. Werner Koch has been one of the co-founders of the Free Software Foundation Europe (FSFE) and so we share quite a bit of a long and interesting history together. I was always proud of the work he did – and together with Bernhard Reiter and others was doing what I could to try and support GnuPG when most people did not seem to understand how essential it truly was – and even many security experts declared proprietary encryption technology acceptable. Bernhard was also crucial to start the more than 10 year track record of Kolab development supporting GnuPG over the years. And especially the usability of GnuPG has always been something I’ve advocated for. As the now famous video by Edward Snowden demonstrated, this unfortunately continued to be an unsolved problem but hopefully will be solved “real soon now.”

 

Aaron Seigo's picture

Kolab Summit, openSuse Conference keynote

I spent the middle of this week at the Univention Summit in Bremen where I presented on Kolab in the open cloud appliances track. While there, we unveiled the first parts of the new corporate identity for Kolab Systems. Over the coming weeks, we will be rolling this new identity out across the various Kolab websites, services and informational materials.

The new look provides a very nice punctuation point for the beginning of 2015 and hints at our evolving focus. A new version of Kolab is nigh, and we have an intriguing roadmap to follow from there. In addition, MyKolab is going to be upgraded to this new version of Kolab bringing new features with it and will simultaneously get a beautiful new skin reflecting the new branding position as well as a shift in name from MyKolab to Kolab Now.

Even more exciting is that we will be holding the very first Kolab Summit at The Hague on May 2-3. The openSUSE Conference will also be underway at the same time in The Hague as well, so there will be lots of opportunities to mix and mingle with both Kolab and openSUSE participants and users. In fact, I'll be dashing over the openSUSE Conference to deliver a keynote presentation.

This is just the start of what is going to be a busy and fruitful 2015 ...

Andreas Cordes's picture

Repository updated for Raspberry Pi and migration to Cubietruck started

Hello,

currently my +Raspberry Pi compiles the packages to the latest version available. (Update from 01.01.2015)
In the next couple of weeks I'm going to migrate from +Raspberry Pi  to my new Cubietruck. I decided to upgrade to a new SBC because the Cubietruck has more power (2 GB Ram instead of 512MB, ARMv7 instead ARMv6 a.s.o.)
For the Cubietruck I decided to go the debootsrap way for a debian image and followed these instructions :
After that I had an amazing fast boot sequence on my "truck". :-) 
I had to fix an  issue on my host because the module "binfmt_misc" was not integrated in my kernel which I compiled myself.
The main difference beetween Raspberry Pi and the Cubietruck is the CPU.
Debian is available for ARMv7 CPUs as "armhf" and for ARMv6 CPUs as "armel" (soft float). The difference is the performance. If you use "armel" on the Raspberry Pi you will loose lots of performance, that's why the guys from Raspbian created their own repository for ARMv6 and "hard float". They compiled nearly every package for the Pi and I did that for the +Kolab packages.
The debian-armhf repository does not contain all of the packages which are necessary for the Kolab installation so my "truck" is compiling all the stuff as well. :-)
Greetz
Andreas

Updating Kolab 3.1 or 3.2 to 3.3

I have recently updated my Kolab Groupware install from version 3.2 to version 3.3, there are not a ton of new features but I wanted to see if this would be a huge process or go fairly quickly.

First of all, take a backup. Really take a backup. You never know what your going to blow up with Kolab updates. Sometime they work great, and they are getting better. Just do it. At the very least backup your IMAP store. If you are like me at all and have your IMAP mounted over NFS, stop the Cyrus service and unmount the IMAP store.

Also, I am using CentOS 6 this guide will be based on that, the fixes at the end might apply though if you are not running CentOS 6.

Here is what I did, also I will list a few things I did to fix some issues.

Backup the server. I use VMWare ESX so I made a snapshot.

Stop the Cyrus Server.
service cyrus-imapd stop

I unmounted the IMAP store since I use NFS.
umount /var/spool/imap

Follow this guide (I will copy it’s content below, possibly with some differences).
https://docs.kolab.org/administrator-guide/upgrading-from-kolab-3.1-to-3.3.html

Update your CentOS Installation

# cd /etc/yum.repos.d/
# rm Kolab*.repo
# wget http://obs.kolabsys.com/repositories/Kolab:/3.3/CentOS_6/Kolab:3.3.repo
# wget http://obs.kolabsys.com/repositories/Kolab:/3.3:/Updates/CentOS_6/Kolab:3.3:Updates.repo
# yum update

FILE TO EDIT: /etc/kolab/kolab.conf
Replace example.org with your LDAP and installation primary domain name.

[ldap]
sharedfolder_acl_entry_attribute = acl
modifytimestamp_format = %Y%m%d%H%M%SZ

[kolab_smtp_access_policy]
delegate_sender_header = True
alias_sender_header = True
sender_header = True
xsender_header = True
cache_uri = <copy and paste mysql uri from the kolab_wap section>

[wallace]
modules = resources, invitationpolicy, footer
kolab_invitation_policy = ACT_ACCEPT_IF_NO_CONFLICT:example.org, ACT_MANUAL

If you’re planning to make use of wallace please make sure wallace is enabled to start using chkconfig on RHEL/Centos or /etc/default/wallace on debian.

A Note on Kolab and Debian Packaging

I thought it might be helpful if I wrote a quick note about my previous work on Debian packaging and Kolab. As my blog can attest, I have written a few articles about packaging and the effort required to make Kolab somewhat more amenable to a convenient and properly functioning installation on Debian systems. Unfortunately, perhaps due to a degree of overambition and perhaps due to me being unable to deliver a convincing and/or palatable set of modifications to achieve these goals, no progress was made over the year or so I spent looking at the situation. I personally do not feel that there was enough of a productive dialogue about aligning these goals with those of the core developers of Kolab, and despite a certain level of interest from others, I no longer have the motivation to keep working on this problem.

Occasionally, I receive mails from people who have read about my experiments with Debian packaging or certain elements of Kolab configuration that became part of the packaging work. This message is intended to communicate that I am no longer working on such things. Getting Kolab to work with other mail transport/delivery/storage systems or other directory systems is not particularly difficult for those with enough experience (and I am a good example of someone who has been able to gain that experience relatively quickly), but integrating this into setup-kolab in an acceptable fashion ultimately proved to be an unrealisable goal.

Other people will presumably continue their work packaging various Kolab libraries for Debian, and some of these lower-level packages may even arrive in the stable release of Debian fairly soon, perhaps even delivering a recent version of those libraries. I do not, however, see any progress on getting other packages into Debian proper. I continue to have the opinion that this unfortunate situation will limit wider adoption of the Kolab technologies and does nobody but the proprietary competition any good.

mollekopf's picture

On Domain Models and Layers in kdepim

In our current kdepim code we use some classes throughout the codebase. I’m going to line out the problems with that and propose how we can do better.

The Application Domain

Each application has a “domain” it was created for. KOrganizer has for instance the calendar domain, and kmail the email domain, and each of those domains can be described with domain objects, which make up the domain model. The domain model of an application is essential, because it is what defines how we can represent the problems of that domain. If Korganizer didn’t have a domain model with attendees to events, we wouldn’t have any way to represent attendees internally, and thus couldn’t develop a feature based on that.

The logic implementing the functionality on top of those domain objects is the domain logic. It implements for instance what has to happen if we remove an event from a calendar, or how we can calculate all occurrences of a recurring event.

In the calendaring domain we use KCalCore to provide many of those domain objects and a large part of the domain logic. KCalCore::Event for instance, represents an event, can hold all necessary data of that event, and has the domain logic directly built-in to calculate recurrences.
Since it is a public library, it provides domain-objects and the domain-logic for all calendaring applications, which is awesome, right? Only if you use it right.

KCalCore

KCalCore provides additionally to the containers and the calendaring logic also serialization to the iCalendar format, which is also why it more or less tries to adhere to the iCalendar RFC, for both representation an interpretation of calendaring data. This is of course very useful for applications that deal with that, and there’s nothing particularly wrong with it. One could argue that serialization and interpretation of calendaring data should be split up, but since both is described by the same RFC I think it makes a lot of sense to keep the implementations together.

Coupling

A problem arises when classes like KCalCore::Event are used as domain objects, and interface for the storage layer, and as actual storage format, which is precisely what we do in kdepim.

roundcube's picture

Update 1.0.4 released

We’re proud to announce the next service release to the stable version 1.0.
It contains a security fix along with some bug fixes and improvements for
the long term support branch of Roundcube. The most important ones are:

  • Security: Fix possible CSRF attacks to some address book operations
    as well as to the ACL and Managesieve plugins.
  • Fix attachments encoded in TNEF containers (from Outlook)
  • Fix compatibility with PHP 5.2

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!

Timotheus Pokorra's picture

Kolab/Roundcube with Nginx IMAP Proxy on CentOS6

I have shown in the last article Kolab/Roundcube with Squirrelmail’s IMAPProxy on CentOS6 how to easily configure an IMAPProxy for Roundcube, and explained the reasons for an IMAP Proxy as well.

Because I did investigate the Nginx IMAP Proxy as well, and got it to work after some workarounds, I want to share it here as well.

stunnel
With Nginx I had this problem: I was not able to connect to the Cyrus IMAP if /etc/imapd.conf had the line allowplaintext: no. The error you get in /var/log/nginx/error.log is: Login only available under a layer
I did not want to change it to allowplaintext: yes

See also this discussion on ServerFault: Can nginx be an mail proxy for a backend server that does not accept cleartext logins?

The solution is to use stunnel.

On CentOS6, you can run yum install stunnel. Unfortunately, there seems to be no init script installed, so that you can run it as a service.

I have taken the script from the source tar.gz file from stunnel, and saved it as /etc/init.d/stunnel: